AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2007.01.31 10:53 "[Tiff] Interpreting SubIFDs tag", by mikk
2007.01.31 17:23 "Re: [Tiff] Interpreting SubIFDs tag", by Joris
2007.02.01 09:42 "Re: [Tiff] Interpreting SubIFDs tag", by Gerben Vos
2007.02.01 18:32 "Re: [Tiff] Interpreting SubIFDs tag", by Joris
2007.01.31 19:24 "Re: [Tiff] Interpreting SubIFDs tag", by Phil Harvey
2007.01.31 19:54 "Re: [Tiff] Interpreting SubIFDs tag", by Joris
2007.01.31 22:24 "RE: [Tiff] Interpreting SubIFDs tag", by Grissom, Ed
2007.02.01 18:17 "RE: [Tiff] Interpreting SubIFDs tag", by Phil Harvey
2007.02.01 18:34 "Re: [Tiff] Interpreting SubIFDs tag", by Joris
2007.02.01 18:48 "Re: [Tiff] Interpreting SubIFDs tag", by Phil Harvey
2007.02.01 19:00 "Re: [Tiff] Interpreting SubIFDs tag", by Joris
2007.02.01 19:36 "Re: [Tiff] Interpreting SubIFDs tag", by Phil Harvey
2007.02.01 20:02 "Re: [Tiff] Interpreting SubIFDs tag", by Joris
2007.02.01 15:46 "Re: [Tiff] Interpreting SubIFDs tag", by Phil Harvey

2007.02.01 18:32 "Re: [Tiff] Interpreting SubIFDs tag", by Joris

Gerben,

In fact, sometimes both are combined, and I've come accross files where the same second and third SubIFD gets pointed to in both ways.

It sounds like a bad idea to write such TIFFs.

Of course I do agree.

Many times, when we're seeing bad stuff like this, it's actually an attempt to bend over backwards to service other bad stuff. In this case, I think it likely the writer of these files wanted to service software that regards SubIFDs as an array only and disregards the linking on, and software that goes about it the other way around.

But I do agree this is not good. A writer should use either scheme, not a combination of both. If at all possible, I humbly recommend a writer chooses the linking on scheme, because that is easiest to handle in terms of IFD removal and addition.

It's good that you have some reading code which deals with this in a smart way, but TIFF writers shouldn't expect readers in general to handle this. A TIFF copying program will typically duplicate the IFDs and image data that are pointed to multiple times, and this can grow rather fast as the number of paths to an IFD increases.

It seems that even a 'TIFF copying program', as you call it (though I don't like to even post the hint that such is possible because nearly all attempts do damage to files by interpreting private LONG tags as LONG when they are IFDs and thus producing output that gets the reader that knows that tag into trouble, amongst many other things), needs protection from IFD looping.

IFD looping is when there's a circular reference, IFD A points to next IFD, IFD B, and that in turn points to next IFD, IFD A. Anything that scans through IFDs and doesn't have IFD looping protection, is bound to get caught in an endless loop sooner or later.

Thus, even in a 'TIFF copying program', I recommend the full scheme I proposed earlier, essentially being looking at the array *and* the links on from that, and removing the duplicates as standard part of the IFD looping protection.

Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html