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.movie.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
