2012.03.21 12:37 "Re: [Tiff] Unable to read following tiff file", by Joris Van Damme

Frank wrote:

It doesn't
seem well behaved to me.

It is a weird file.

Here's a tag dump (best viewed as HTML).

*Tag**Datatype**Count**Value*NewSubfileType<http://www.awaresystems.be/imaging/tiff/tifftags/newsubfiletype.html> Long10ImageWidth<http://www.awaresystems.be/imaging/tiff/tifftags/imagewidth.html> Long12550ImageLength<http://www.awaresystems.be/imaging/tiff/tifftags/imagelength.html>

Long13300BitsPerSample<http://www.awaresystems.be/imaging/tiff/tifftags/bitspersample.html> Short38, 8, 8Compression<http://www.awaresystems.be/imaging/tiff/tifftags/compression.html> Short1JPEGPhotometricInterpretation<http://www.awaresystems.be/imaging/tiff/tifftags/photometricinterpretation.html>

Short1YCbCrOrientation<http://www.awaresystems.be/imaging/tiff/tifftags/orientation.html> Short1TopLeftSamplesPerPixel<http://www.awaresystems.be/imaging/tiff/tifftags/samplesperpixel.html>

Short13XResolution<http://www.awaresystems.be/imaging/tiff/tifftags/xresolution.html> Rational1300YResolution<http://www.awaresystems.be/imaging/tiff/tifftags/yresolution.html> Rational1300PlanarConfiguration<http://www.awaresystems.be/imaging/tiff/tifftags/planarconfiguration.html> Short1ChunkyResolutionUnit<http://www.awaresystems.be/imaging/tiff/tifftags/resolutionunit.html> Short1InchTileWidth<http://www.awaresystems.be/imaging/tiff/tifftags/tilewidth.html>

Short12550TileLength<http://www.awaresystems.be/imaging/tiff/tifftags/tilelength.html> Short13300TileOffsets<http://www.awaresystems.be/imaging/tiff/tifftags/tileoffsets.html> Long11000TileByteCounts<http://www.awaresystems.be/imaging/tiff/tifftags/tilebytecounts.html> Long1303600JPEGProc<http://www.awaresystems.be/imaging/tiff/tifftags/jpegproc.html> Short1BaselineJPEGInterchangeFormat<http://www.awaresystems.be/imaging/tiff/tifftags/jpeginterchangeformat.html> Long1360JPEGInterchangeFormatLength<http://www.awaresystems.be/imaging/tiff/tifftags/jpeginterchangeformatlength.html> Long1304240JPEGRestartInterval<file:///C:/Users/Joris/Desktop/Nieuw%20tekstdocument.html> Short10Subsampling<http://www.awaresystems.be/imaging/tiff/tifftags/ycbcrsubsampling.html>

Short22, 1SubsamplingPositioning<http://www.awaresystems.be/imaging/tiff/tifftags/ycbcrpositioning.html> Short1CositedReferenceBlackWhite<file:///C:/Users/Joris/Desktop/Nieuw%20tekstdocument.html> Rational60, 255, 128, 255, 128, 255

First thing you'll notice, apart from the odd tile sizes you mentioned already, is the presence of old-style JPEG tags combined with the new-style JPEG compression value of the Compression tag. And the uncommon value for SubsamplingPosition.

The strip data or in this case tile data is part of the JPEGInterchangeFormat stream, judging from the tag values, and that is not atypical of old-style JPEG. In such cases, the strip/tile data typically points to the compressed data portion of the JPEG stream, so, excluding all markers at the start and end of the JPEG stream. However, in this case they both end at the same position. Also, the actual TileOffset value, 1000, is suspicious, as such a nice round number seems to indicate the process of arriving at that number may have been somewhat arbitrary.

Investigating the JPEGInterchangeFormat stream, one does find a seemingly legit though truncates JPEG stream. Marker sequence is SOI, APP0, COM, DQT, DHT, SOF0, SOS, and this is followed by seemingly legit compressed image data. The presence of APP0 and COM markers is not at all correct, as these contain metadata that is useful in a JPEG file context but should not be there in a TIFF file context where all such metadata ought to be contained inside the TIFF IFD. But it is reasonably common nonetheless.

The markers furthermore indicate the presence of 3 channels in the stream, and subsampling values also consistent with what is indicated in the TIFF IFD.

The compressed image data starts at offset 640 in the stream. So, this is indeed offset 1000 in the TIFF file. Therefore, the TileOffsets value is not arbitrary after all, it does point to the start of the compressed image data, as is not uncommon for old-style JPEG, though of course not legit for new-style JPEG.

The compressed data in the stream is prematurely truncated. There are no usual trailing markers in the stream.

The premature truncation does not appear to have originated at TIFF level.

The file size is 304600 bytes, that is consistent with the values of the TIleOffsets, TileByteCounts, and JpegInterchangeFormat tags.

All this leads me to the conclusion that this file is probably a very bad attempt at encapsulating a truncated JPEG file. Done by people that don't read standards and ended up mixing old-style and new-style JPEG stuff in a very creative manner. The JPEG stream COM marker says "LEAD Technologies Inc. V1.01", and we're used to seeing garbadge from LEAD libraries trying to write JPEG-compressed TIFF files, so maybe that's some indication as to who is to blame for this junk.

It is also likely that LibTIFF (or LibTIFF RGBA interface) fails in these circumstances, either because it finds no required table markers at the position pointed to by TilfOffsets, or either because it fails to respond properly the LibJPEG erroring out at premature EOF. It could do better, by using the JPEGInterchangeFormat stream when it fails to find all required data in the Tile stream, and/or by responding more robustly to LibJPEG's error indication near the end of the image data, but it is absolutely not required to do better, as the file is far from legit.

Or maybe LibTIFF RGBA interface fails because it rightly thinks it cannot support the uncommon SubsamplingPosition value when it relies on LibJPEG to do the de-subsampling. In this case it could and should do better by not delegating de-subsampling to LibJPEG, as has always been my point of view because subsampling can actually be combined with any compression mode in TIFF.

Best regards,

Joris Van Damme
AWare Systems