2001.03.21 15:19 "Wang tiff", by Neil Durant

2001.03.22 23:15 "Re: Wang Tiff", by Tom Lane

I have found that Wang tiff images can be read a number of tiff readers, and there are a number that don't like them at all. There was a lot of commotion on the mailing list about 1 - 2 years ago regarding these tiff images, if there is an archive you can check that.

I'll save you the trouble...

I don't know whether Wang ever corrected any of the errors enumerated below, but this will at least save you some amount of reverse-engineering.

regards, tom lane
organizer, Independent JPEG Group

------- Forwarded Message

Date: Wed, 11 Sep 1996 01:52:58 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: tiff@sgi.com
Subject: Microsoft is pushing old-style TIFF/JPEG

Microsoft is pushing some "Imaging Software for Windows 95" developed by Wang. In fact, they're giving it away free: see http://www.microsoft.com/windows/software/img_us.htm and the associated press release contains some big talk about setting the standards for the document imaging industry.

I don't use W95, but examination of the sample image available from that page told a sad tale. It's TIFF/JPEG, compression tag 6 --- that is, JPEG per TIFF 6.0, not per TIFF Tech Note #2. Actually, it's not even compliant with the unambiguous parts of the TIFF 6.0 spec (details below).

Just to add insult to injury, Microsoft is apparently pushing TIFF/JPEG as a suitable format for black and white fax-type images... at least, that's what this sample file is, and that's what the press release mostly talks about. As best I can tell, this file would've been about a factor of 5 smaller as TIFF G3, and lossless to boot.

If they actually push this software seriously, and achieve any kind of market penetration, we can pretty much kiss goodbye any hope that TIFF Tech Note #2 will become the standard way of storing TIFF/JPEG.

I think I'll go cry in my beer now.

regards, tom lane
organizer, Independent JPEG Group

PS: The 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.

------- End of Forwarded Message