2004.02.09 19:59 "Re: [Tiff] Photoshop 8.0 and libtiff", by Frank Warmerdam

I am sure that this change could be accomplished, however, before any steps are taken, the API should be looked at to verify there is any advantage from doing so. 32-bit operating systems commonly reserve 1GB, or 2GB of the process address space for their own use. For example, Windows provides the application with a maximum 2GB of usable address space. This range is handled by the existing signed size type.

If the API provides access to the strip via a single memory allocation, then it will certainly be impossible to access more than a 2GB strip on a typical 32-bit OS. A 64-bit application on a 64-bit OS could deal with this just fine except there would be thrashing if there is not enough RAM.

Improving the API to support iterative access to a strip would be a superior solution. Then an unsigned 32-bit offset type and a signed 32-bit size type would be more than sufficient. Does this iterative interface already exist?

Bob,

Your point is good, but the "trick" is that libtiff already "auto-splits" single strip files into more managable strips under some circumstances (it has to be uncompressed I think). So, it should be practical to work with these large one-strip files as long as they aren't compressed.

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