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:12 "RE: 8K chunks for RowsPerStrip?", by Ed Grissom

Upping the size recommendation would make a lot of sense; in these days of 512Mb computers, 8k seems a little bit penny pinching. How about 128k? I don't feel this would give too many problems with the current address space limitations.

I don't think that the virtual memory size staying constant (as mentioned by Max Martinez) is an issue. Anytime you get over the physical memory size, you start having performance problems. Since the typical amount of physical memory has been increasing, I agree with Don that a higher recommendation makes sense.

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.

The real problem is the limitation of 2G file sizes. With printers (including large Format) having heads of 1440 dpi and 2880 coming up, tiff is going to run out of numbers. It would be really good to see chained files to hold the extra data. For this reason, we've not adopted tiff as out archival format buy had to develop our own.

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.

On another note, what applications output data in the tiled format ( and read it). This format makes a lot of sense to me as it allows fast easy access to data for doing such otherwise memory hungry tasks such as rotation.

Our apps deal exclusively with tiled data. They will not read or write untiled data. We provide converter utilities to convert to and from tiled format so that our users can interoperate with other apps that do not do tiling. When writing, users can choose between "single strip", "TIFF spec Recommendation", or "user defined" rows per strip.

(*) section 2, first paragraph, last sentence.

ed grissom
egrissom@ziimaging.com