Hi Su,
the issue is that the imagecodecs library was able read 65535 IFDs with
libtiff 4.4 but only 65534 IFDs with libtiff 4.5. The library iterates
through the first 65535 IFDs to read image properties and then iterates
over those IFDs again to read the image data. The error occurs when
changing from IFD 65534 (zero based index) to IFD 0 using
TIFFSetDirectory since then the uint16 variable overflows.
I am OK if libtiff only officially supports 65534 IFDs, but I would
expect in that case that `TIFFSetDirectory(tif, 65534)` would fail too. No?
Christoph
On 12/11/2022 12:34 PM, Sulau wrote:
Hi Christoph
Is the actual issue having more than 65534 IFDs in the file or just the error
message when changing from IFD number 65534 to IFD number 0? I understood that
more than 65534 IFDs (even more than 65535) are to be addressed.
Best regards
Su
-----Ursprüngliche Nachricht-----
Von: Tiff [mailto:[email protected]] Im Auftrag von Sulau
Gesendet: Sonntag, 11. Dezember 2022 20:58
An: 'Even Rouault' <[email protected]>; 'Bob Friesenhahn'
<[email protected]>; 'Christoph Gohlke' <[email protected]>
Cc: [email protected]
Betreff: Re: [Tiff] libtiff v4.5.0 release candidate available
Hi,
I had a quick look at it.
Within libitff, the number of directories / directory number is stored in an uint16_t and
the number 65535 was treated as a magic number for a "non-existing directory"!
Thus, libtiff can only handle 65534 directories.
However, many libtiff functions do not depend on the directory number.
Therefore, it is in principle possible to handle TIFF files with more than
65535 IFDs if none of these functions that use the directory number are used.
Like the test file gray.movie.u2.tif containing 65567 pages.
Before version 4.5.0, the existing IFD loop check was ineffective. Therefore,
no warnings occur for test files with more than 65534 directories.
Since the directory number is contained as a uint16_t in public libtiff
interfaces, I see no quick solution at the moment other than to disable the IFD
loop check again.
I will setup a gitlab issue.
Su
-----Ursprüngliche Nachricht-----
Von: Tiff [mailto:[email protected]] Im Auftrag von Even Rouault
Gesendet: Sonntag, 11. Dezember 2022 17:57
An: Bob Friesenhahn <[email protected]>; Christoph Gohlke
<[email protected]>
Cc: [email protected]
Betreff: Re: [Tiff] libtiff v4.5.0 release candidate available
The unfortunate quadratic performance of IFD looping detection is not something new.
I can reproduce it with older libtiff too. We'd probably need the equivalent of
std::set<uint64_t> setOfIFDOffsets to have good performance ...
But it is not time to fix that at release candidate stage. The priority would
be to avoid the regression of the error message when reading the 65535th IFD.
I've CC'ed Su Laus who did work in that area during this dev cycle.
Even
Le 11/12/2022 à 17:37, Bob Friesenhahn a écrit :
"TIFFReadDirectory: Warning, Didn't read next directory due to IFD
looping at offset 0xa7ff1e (11009822) to offset 0x8 (8)."
Error: "Cannot handle more than 65535 TIFF directories"
The test file at
<https://github.com/cgohlke/imagecodecs/blob/master/tests/tiff/gray.m
ovie.u2.tif>
contains 65567 pages.
This test file reveals something else which is concerning. I ran a
profiler on GraphicsMagick while it was reading this file and I see
that 53% of the time is being spent in _TIFFCheckDirNumberAndOffset().
Most of the time is being spent in the code associated with "Check if
offset is already in the list".
I assumed that most of the time would be spent in GraphicsMagick code.
Bob
--
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
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
