2016.03.19 16:37 "Re: [Tiff] Why is TIFFAdvanceDirectory static?", by Bob Friesenhahn
[Cc:ing the list again so that others can be aware of the discussion]
On Sat, 19 Mar 2016, AG wrote:
> Hi Bob,
> Thanks for the quick response.
> I did not need to profile the code because I have two alternate code > paths; one that uses TiffSetDirectory() and LibTIFF and one that
> uses my own TIFF reading code using my own TIFF library which I have > been developing (and patching) over the last 25 years. My own code
> executes the equivalent read in a couple of seconds while LibTIFF > implementation takes minutes to complete. When I stepped through
> the code I immediately saw that my implementation does not discard
> the last read IFD so advancing to the next image in the stack does > not require re-reading all IFDs from the first (as is done by TIFF
> SetDirectory()). For small stacks this is not a problem but > yesterday I heard from a beta tester who was using a stack of ~50k
> frames. When you are in this range, the O(N^2) march of the IFD is > painfully inefficient.
> From the point of view of overall design, TiffSetDirectory() is
> clearly the minimum requirement. I feel that my example makes a > strong case for exposing the API to increment/advance one IFD.
Implemeting an interator style interface or caching some data would help performance but then there is the added consideration of if multiple threads are used or the file is updated by multiple processes. What are the risks of caching this extra file state in memory (which might no longer be correct) and not going back to the original file store?
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/