2000.02.03 01:55 "Re: Microsoft Imaging and Jpeg in TIFF", by Tom Lane

I will tell you some things about Wang TIFF/J images.

One is that they use the "OJPEG" tags JPEGInterchangeFileOffset(TIFFTAG_JPEGIFOFFSET) and JPEGInterchangeFileLength (TIFFTAG_JPEGIFBYTECOUNT). What this is the the beginning of the JPEG stream. Add to this the contents of each strip, raw, and there is the complete JPEG data stream.

Or is it?

I was doing some research as I wasn to extract only a valid JPEG data stream from a Wang TIFF image. So the procedure described above gets what appears to be a JPEG data stream, starting with FF'D8' marker and ending with FF'D9'.

This data stream, even with an attached JFIF header, is not viewable in other regular softwares (browser, PSP) nor valid as a PostScript DCTDecode stream.

It sounds like Wang hasn't fixed any of their fundamental bugs in TIFF/JPEG support (starting with the horribly wrong decision to follow the broken TIFF 6.0 JPEG design in the first place :-().

Attached is an extract from mail I sent to the tiff list on 11-Sep-96. I am guessing that the data you've extracted is unreadable because of point #2.

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.