LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
January 1999

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

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

1999.01.21 06:12 "Re: Tiff compression mode 6", by Tom Lane

Brian Rothwell <brothwell@c4c.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.