2021.12.08 22:02 "Re: [Tiff] Windows - difference in behavior when large RowsPerStrip is specified while writing Uncompressed vs LZW compressed TIFF file", by Even Rouault

1. One correction to my previous email. The results that I shared in my last email are from libTIFF version 4.0.0 (an older version). When I tried to use 4.2.0, I didn't get the weird results of RowsPerStrip changing after writing Uncompressed TIFF file on Windows, the LZW compression issue remained the same. However, with 4.2.0 and using Linux, I see the same issue of changed RowsPerStrip when writing uncompressed data. Not sure why this is happening.

See my previous response + regarding the Windows vs Linux difference, might be related to https://gitlab.com/libtiff/libtiff/-/merge_requests/271 that fixed that fact that strip chopping was erroneously disabled for CMake builds

2. In case of LZW compression, as you said there is some 32-bit counter which is not capable of handling this large strip size - could it be different on different platforms? I am not seeing the issue of corrupted file on Linux platform, only on Windows. May be some overflow happening depending on the size of the counter and how that size is interpreted on different platforms?

Looking at the code, I do see a number of usage of long to store number of bytes, which can explain issues on Windows with > 2 GB of data. Could you try https://gitlab.com/libtiff/libtiff/-/merge_requests/279 which should hopefully fix that? (I didn't try it on Windows)

Even

http://www.spatialys.com
My software is free, but my time generally not.