AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2001.04.26 14:40 "8K chunks for RowsPerStrip?", by Michael O'Rourke
2001.04.26 16:13 "RE: 8K chunks for RowsPerStrip?", by Max Martinez
2001.04.26 16:45 "RE: 8K chunks for RowsPerStrip?", by Don Swatman
2001.04.26 18:12 "RE: 8K chunks for RowsPerStrip?", by Ed Grissom
2001.04.26 18:39 "Re: 8K chunks for RowsPerStrip?", by Frank Warmerdam
2001.04.26 16:47 "Re: 8K chunks for RowsPerStrip?", by Bernd Stahlbock
2001.04.26 17:19 "Re: 8K chunks for RowsPerStrip?", by Daniel McCoy
2001.04.26 18:34 "8K chunks for RowsPerStrip?", by Chris Barker
2001.04.26 18:48 "RE: 8K chunks for RowsPerStrip? - Image size limits", by Peter Smith

2001.04.26 18:39 "Re: 8K chunks for RowsPerStrip?", by Frank Warmerdam

We typically recommend 10Meg/strip for our users, and I seen no reason to go below 1Meg/strip for home-user targeted apps. 1 Meg is only 3% of a low end 32Meg machine.

Ed, everybody,

I don't know that an alternate recommendation will mean much. However, in my case I essentially treat strips as odd shaped tiles, and for reasonable performance in my own paging layer it is nice for the strips to be on the order of 128K for a nice granularity.

For compressed images I think somewhere in the 100K to 1MB range gives good performance from compression algorithms, and doesn't make the "quantum" of operation too large for single threaded gui programs trying to maintain some sense of smoothness. It is also important (as pointed out earlier) for applications only wanting to read a window to not compress a whole large file in one strip.

I would also like to point out that in the default build libtiff provides "automatic row chopping" which for uncompressed images make one strip images look like many strip images. This can help applications that try to read a whole strip for large files.

Our current scanner scans gray and color film at ~3500 DPI. For a full 10inchx10inch aerial photo negative, this can be close to 3.5 GB uncompressed for the main image. The TIFF spec limit is 4GB, not 2GB. Read the spec closely (*), offsets are "unsigned". However LibTIFF, and other apps may suffer from the "signed" arguments to fseek() which limit a file to 2GB. On windowsNT/2k, and likely on 64-bit Unixes, the seeking can be done to higher offsets with more advanced APIs.

With appropriate build conditions libtiff can handle up to 4GB files. I think currently only on NT, but it is easy to wire it into 64bit read/write APIs on other platforms as well.

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent