2000.05.17 02:40 "LeadTools bad JPEG 7 TIFF compression?", by Brent Foster

We're using LeadTools (version 10.0) for JPEG TIFF writing, and I've noticed a few things that don't seem right.

Saving an 8 bit gray JPEG into a TIFF, I get a TIFF with compression=7, but it includes the tags JPEGProc, JPEGInterchangeFormat, JPEGInterchangeFormatLength, JPEGRestartInterval, JPEGLosslessPredictors and JPEGPointTransforms, and has the single tile pointing part way into the interchange format. My reading of TIFF Tech Note 2 is that the only valid tag for compression=7 is JPEGTables. It looks very much to me like this is a JPEG 6 compressed TIFF with the compression incorrectly set to 7, which violates both the TIFF 6.0 spec and the tech note. Changing the compression back to 6 undoes the damage and returns the TIFF to about as readable as you get using JPEG 6.

In addition, the JPEGInterchangeFormat points to a JPEG stream that fails to contain an EOI marker. According to my reading of the TIFF 6.0 spec and JPEG spec, it must contain one. This could seriously complicate general TIFF copiers because some software (e.g. Wang/Kodak Imaging) writes the wrong value into JPEGInterchangeFormatLength. In order to rewrite a JPEG 6 compressed TIFF containing JPEGInterchangeFormat, you need the correct length. That can be fixed by finding the JPEG EOI marker from the start of the JPEGInterchangeFormat. But now, because LeadTools is missing off the EOI marker, the only safe way to find the correct length of the JPEGInterchangeFormat is to actually parse the JPEG data, variable length codes and all, until the end is reached. Or the copier has to decompress/recompress the image.

Does what I've said sound right? Does anyone that knows a bit more want me to send them an image to confirm it?

Thanks,

Brent Foster