2021.12.08 21:55 "Re: [Tiff] Windows - difference in behavior when large RowsPerStrip is specified while writing Uncompressed vs LZW compressed TIFF file", by Bob Friesenhahn

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?

Keeping in mind your recommendation, do you think this behavior should be reported as a libTIFF bug (functionality wise)?

Writing a corrupted file would be a bug. If it is due to libtiff, then a bug which describes how to reproduce it should be opened.

If the request is not possible, then a simple solution is to reject the request based on a codec-dependent limit. A more complex solution is to track down where a counter can overflow and report an error if it is going to overflow. The problem with this (besides the complexity) is that it could take a very long time to find that out.

Writers of TIFF need to take care not to make unreasonable requests and readers of TIFF need to take care to avoid files which make unreasonable requests.

Bob

Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt