LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2004
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
2004.02.09 19:59 "Re: Photoshop 8.0 and libtiff", by Frank Warmerdam
Bob Friesenhahn wrote: > 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