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
Thread
2010.04.01 21:52 "Re: TIFFReadScanline and large compressed one-strip files", by Chris Cox
Tom;
Compression ratios improve if you use larger strip sizes.
And on modern machines, 290 Meg is next to nothing.
(some video/3D software likes to write TIFF files as a single tile/strip)
So I can see how such an image might get created.
But LifTIFF should be able to read sub sections of the strip when memory is
limited (say, on embedded devices).
(Photoshop reads subsections as memory allows, down to a single row at a
time, regardless of the strip size)
Chris
On 4/1/10 2:30 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
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