TIFF and LibTiff Mail List Archive


2004.02.09 17:02 "[Tiff] Photoshop 8.0 and libtiff", by Don Ellis
2004.02.09 20:12 "Re: [Tiff] Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.09 20:36 "RE: [Tiff] Photoshop 8.0 and libtiff", by Don Ellis

2004.02.09 20:36 "RE: [Tiff] Photoshop 8.0 and libtiff", by Don Ellis

Your right, the very large images that I have worked on so far have always been uncompressed. This allows me to ignore the strips if I want to. Thanks for the help.

If I get any thing to work in the way of 64 bit, I will try to get my company to allow me to release it, but more than likely I will have to "break the specifications" to get it to work with my application and so it would be useless to the rest of the community.

Thanks for your help!

Cc: Don Ellis; Subject: Re: [Tiff] Photoshop 8.0 and libtiff

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?

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.

The limitation that this only works for uncompressed files is counter-productive. If TIFF is just an archive storage format, rather than the native "working" format, then it makes sense to enable compression so the required file size is smaller (i.e. much more likely to be under 4GB).