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
Thread
2009.01.09 19:29 "Re: TIFF standards and technical notes", by Chris Cox
Adobe did officially say "ignore the JPEG spec. in TIFF 6.0 (aka section 22)", repeatedly. That should have been clear even from the TIFF Technotes. There should be no section 22 (Obsolete JPEG) images created at this time. That was obsoleted pretty quickly. The technotes are additions to the standard - they are part of the standard. What we haven't done (for #$%^@#%4 political reasons) is put out TIFF 6.1 with the corrections and additions packaged up on one place. I'm still trying to put out an updated spec., but I get pushback every time I bring it up. Chris On 1/9/09 6:45 AM, "Gary McGath" <gary@hulmail.harvard.edu> wrote: I've written the following draft for a post on my File Formats Blog (http://fileformats.blogspot.com) on the status of JPEG encoding in TIFF. I'd like to run it by the people here for comments before making the post public. I've done a copy from the preview, links to the cited documents which will appear in the post are missing here. TIFF's Catch 22 Section 22 of the TIFF 6.0 specification (PDF), on JPEG compression, has been a subject of ongoing controversy. The problems with it are discussed in Draft Tech Note 2 at remotesensing.org. The major problem cited is that the tags defined in Section 22 require detailed understanding of the JPEG encoding. Even an application which simply modifies tags a TIFF file, without any expectation of decoding JPEG codestreams, must parse the data which JPEG tags refer to in order to preserve it. For example, tag 521, JPEGACTables, points to a list of offsets to Huffman AC tables, whose format is given as follows: 16 BYTES of "BITS", indicating the number of codes of lengths 1 to 16; Up to 256 BYTES of "VALUES", indicating the values associated with those codes, in order of length. There is a similarly incomplete description of tag 520 (JPEGDCTables). This isn't sufficient information to determine the length of the table. The best a JPEG-unaware application can do, if it has to move the table, is to allocate 272 bytes for the copy of an AC table or 33 bytes for a DC table. 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. 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. The basic problem is that Adobe hasn't revised the TIFF specification since 1992. Whatever problems there are with it look as if they'll remain the official standard forever. This is particularly a problem from the standpoint of digital preservation. "Real" TIFF files should follow the standard, not a technical note which (at least in name) is intended for a particular application. But this approach isn't realistic when so many files exist that depend on the Photoshop Notes. It has to be considered part of the specification. JHOVE, by the way, deals with both sets of tags. -- Gary McGath Digital Library Software Engineer Harvard University Library Office for Information Systems http://hul.harvard.edu/~gary/index.html