AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.02.09 17:02 "[Tiff] Photoshop 8.0 and libtiff", by Don Ellis
[...]
2004.02.09 19:48 "Re: [Tiff] Photoshop 8.0 and libtiff", by Bob Friesenhahn
2004.02.09 19:59 "Re: [Tiff] Photoshop 8.0 and libtiff", by Frank Warmerdam
2004.02.09 20:25 "RE: [Tiff] Photoshop 8.0 and libtiff", by Don Ellis
2004.02.09 20:50 "RE: [Tiff] Photoshop 8.0 and libtiff", by Bob Friesenhahn
[...]

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

Both td_imagewidth and td_imagelength are unsigned 32 bit integers and in the specifications they are also defined this way. So a Tiff image conceivably could be a total of 18 x10 to the 18th pixels. Multiply this by 4 to get four colors and the file size could be huge. Strips, tiles, and most of the other limiting variables are just used to speed things up. For very large files you may have to forgo the use of strips or do some modifications, such as limit a strip to the size of available memory, and modify some pointers to uint64. I see nothing in the code that prevents huge images.

Should I continue to copy tiff@remotesensing.org?

Any thoughts?

Cc: Don Ellis; tiff@remotesensing.org

Subject: Re: [Tiff] Photoshop 8.0 and libtiff

My first thought was, "hey, we already work fine with 4GB files". But upon a bit of review I realize we use unsigned int for toff_t, but a signed int for tsize_t. The comments in tiffio.h mention that tsize_t is int32 and not uint32 because some functions return -1. So, I think that is why uint32 isn't used now.

I do kind of wonder if the code could be changed somehow to use uint32 for tsize_t but recognise 0xffffffff as end-of-file, instead of -1. There couldn't be something 0xffffffff bytes long in a file of 4GB or less anyways since there is always some other overhead.

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?