AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 2009

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

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

2009.01.09 17:45 "Re: 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