Le 08/12/2021 à 22:39, Nalini Vishnoi a écrit :
Hi Paavo,
Thanks a lot for your response.
I understand that writing a single strip of large size is not
recommended. I will keep that in mind.
However,
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
1.
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.
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
