AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2009.01.05 15:59 "[Tiff] TIFF standards and technical notes", by Sheila M. Morrissey
2009.01.06 10:51 "Re: [Tiff] TIFF standards and technical notes", by Gerben Vos
2009.01.06 14:07 "Re: [Tiff] TIFF standards and technical notes", by Sheila M. Morrissey
2009.01.09 14:45 "Re: [Tiff] TIFF standards and technical notes", by Gary McGath
2009.01.09 17:45 "Re: [Tiff] TIFF standards and technical notes", by Tom Lane
2009.01.09 17:56 "Re: [Tiff] TIFF standards and technical notes", by Gary McGath
2009.01.12 10:58 "Re: [Tiff] TIFF standards and technical notes", by Gerben Vos
2009.01.09 19:29 "Re: [Tiff] TIFF standards and technical notes", by Chris Cox
2009.01.12 14:30 "Re: [Tiff] TIFF standards and technical notes", by Gary McGath
2009.01.12 16:50 "Re: [Tiff] TIFF standards and technical notes", by Chris Cox

2009.01.09 17:45 "Re: [Tiff] TIFF standards and technical notes", by Tom Lane

Gary McGath <gary@hulmail.harvard.edu> writes:

> [ concerning the Section 22 mess ]

From a quick reading, it looks to me as if all problems with uncertain sizes for JPEG data blocks can be solved by assuming a maximum length, so the problem may be overstated.

I think you are trivializing the problems with section 22. TTN2 expends quite a bit of space explaining why 22 is so badly broken that it ought to be abandoned. Even if you discount all the arguments why it's misdesigned, the facts on the ground are that it's ambiguous and not compatible with software that doesn't include explicit kluges^H^H^H^H^H^H special cases for the JPEG-specific fields. When we wrote TTN2 there were already multiple mutually-incompatible implementations of section 22, and things didn't get any better afterwards.

What is clear, though, is that there's confusion in the TIFF world on how to handle JPEG compression. Tech Note 2 goes on to recommend an alternate specification. Adobe has adopted this alternative (or something very close to it) in its Photoshop TIFF Technical notes (PDF), but without rescinding Section 22. Undoubtedly there are still Section 22-based TIFF files in use and at least a few still being created.

It's certainly true that Adobe has dropped the ball badly by not releasing a formal update to the spec since 6.0. There's not much anyone outside the company can do about that, though, and the powers-that-be inside the company have made it abundantly clear that they simply don't care.

The point that you need to be making is that Section 22 files are pretty much guaranteed to be incompatible with any implementation other than the specific one that created them. The (relatively few) implementations that are even trying to follow 22 have enough quirks that they fail to interoperate. In some cases this can be blamed on the ambiguities in the spec and in others it can be blamed on people not trying very hard to follow the spec, but the bottom line is they don't manage to read each others' files.

JHOVE, by the way, deals with both sets of tags.

You mean it deals with some one interpretation of the Section 22 tags.

regards, tom lane