|AWARE [SYSTEMS]||Imaging expertise for the Delphi developer|
|TIFF and LibTiff Mailing List Archive|
LibTiff Mailing List
1999.01.21 06:12 "Re: Tiff compression mode 6", by Tom Lane
Brian Rothwell <email@example.com> writes: > It seems that Kodak/Wang Imaging on PC uses Tiff compression mode 6 > (original 6.0 specification) for JPEG representation. Do you know of > any reference implementations of libtiff that can read/write that > format? The current version only seems to support mode 7 for JPEG > compression. I have read the tech note #2 and realize there would be > limitations/complications in the calling application, but I can live > with those. Well, if you read TTN#2 then you realize that there are serious questions as to what TIFF compression mode 6 actually *is*, and thus asking for a "reference implementation" is rather hopeless. However, it is quite clear that Wang Imaging's files are not any of the possible interpretations of TIFF 6.0 --- they went off in left field somewhere and then stuck a Compression=6 tag on it anyway. (Shades of Microsoft's philosophy: "whatever we feel like doing *is* the standard".) Perhaps you are forced by marketing reasons to read Wang's poor excuse for TIFF/JPEG files, but I beg you not to create any more like them. Attached is an extract from mail I sent to the tiff list on 11-Sep-96. regards, tom lane organizer, Independent JPEG Group ... The [Wang] sample file violates TIFF 6.0 Section 22 in at least three ways: 1. It contains JPEGInterchangeFormat and JPEGInterchangeFormatLength tags, but the file does *not* contain a valid JPEG datastream. In fact these two tags are set to point to an area, just in front of the first strip, that includes only the JPEG header markers (SOI, a COM marker, DQT, SOF0, DHT ... but not SOS for some reason). 2. Even if one ignores the given length and tries to read the rest of the file as JPEG interchange data, one will fail. It appears that at the inter-strip boundaries, the data is padded to byte boundaries without inserting any restart markers. This is a plausible interpretation of 6.0's rather vague description of strip boundary handling, but the result is certainly not a pure JPEG-compatible datastream, so JPEGInterchangeFormat should've been omitted. 3. The first StripOffset pointer points to the SOS marker, not to the start of encoded data, in direct contradiction to p. 103 of the spec. So, totally aside from any hope of TIFF Tech Note #2 compatibility, this file would not even be readable by any arguably correct implementation of the TIFF 6.0 spec. *Sigh*. This is a black day for standards.