AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
April 2010

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2010.04.01 21:12 "TIFFReadScanline and large compressed one-strip files", by Frank Warmerdam
2010.04.01 21:30 "Re: TIFFReadScanline and large compressed one-strip files", by Tom Lane
2010.04.01 21:52 "Re: TIFFReadScanline and large compressed one-strip files", by Chris Cox
2010.04.01 21:49 "Re: TIFFReadScanline and large compressed one-strip files", by Olivier Paquet
2010.04.02 07:29 "Re: TIFFReadScanline and large compressed one-strip files", by Joris Van Damme
2010.04.02 13:45 "Re: TIFFReadScanline and large compressed one-strip files", by Frank Warmerdam
2010.04.05 13:02 "Re: TIFFReadScanline and large compressed one-strip files", by Edward Lam

2010.04.01 21:30 "Re: TIFFReadScanline and large compressed one-strip files", by Tom Lane

Frank Warmerdam <warmerdam@pobox.com> writes:
> Folks,
> I have an LZW compressed TIFF file of 290MB or so with the whole image
> in one strip.  Reading the file with the TIFFReadScanline() function causes
> the entire 280MB of compressed data to be loaded into memory at the point
> the first scanline is read.

> My client is finding that in some cases on 32bit systems there isn't 290MB
> of contiguous memory available and would like a way avoiding prereading the
> whole strip.

> Does anyone have any suggestions for this?

Whack the file's producer upside the head?  The entire *point* of the
strip/tile mechanism is to limit the amount of data that has to be
slurped in at once.  I can't see why libtiff should be expected to go
to enormous lengths to work around such blind misuse of the format.

			regards, tom lane