2017.08.26 13:56 "[Tiff] Determining use of "w" or "w8" in TIFFOpen", by Paul Hemmer

2017.08.26 15:31 "Re: [Tiff] Determining use of "w" or "w8" in TIFFOpen", by Roger Leigh

On 26/08/2017 13:56, Paul Hemmer wrote:

If I have a buffer of 16bit grayscale data, and a known width and height, I could calculate the size by w*h*2

If that size is greater than 4GB, I should specify "w8" and if less than, I should specify "w" when calling TIFFOpen() in order to get the BigTIFF format when needed.

Yes, but also take care to account for the additional space required by the TIFF header and all IFDs. There's an overhead of 16 bytes per tile or strip using BigTIFF for the offset and size (8 for regular TIFF). And there may be other metadata stored as well.

I use this logic:

https://github.com/ome/ome-files-cpp/blob/master/lib/ome/files/tiff/Util.cpp#L389

Basically, we add an extra 5% to all the pixel data sizes to ensure we will have enough space with some headroom for safety. This means we switch automatically from TIFF to BigTIFF at approximately 3890 MiB, which is already quite large. Or allow the user to manually force one or the other, with warnings when the limit is exceeded.

But what if the of COMPRESSION_LZW would result in a file that is  use

> much smaller than 4GB? I can't know that ahead of time (can I?)  Should

I still use w8 if the uncompressed dimensions more than 4GB?  require

Because it's hard to tell up front just how much space compression will save (if any), I ignore it entirely to be safe. Some image data compresses well, other data very poorly.

I'm finding that I can't simply specify "w8" for all, as those that are less than 4GB end up failing to open.

The 4GB limit is solely due to the offsets being 32-bit for regular TIFF and 64-bit for BigTIFF. You can have a BigTIFF of any size up to 2^64; being less than 2^32 is not a problem. Check that your software can read BigTIFF; it's likely that rather than a problem with the file.

Regards,
Roger