2010.06.11 21:36 "[Tiff] Class Y (YCbCr) tiffs with 420 subsampling", by Thomas Richter

2010.06.11 21:36 "[Tiff] Class Y (YCbCr) tiffs with 420 subsampling", by Thomas Richter

Hi folks,

It looks libTIFF has a bug in handling YCbCr subsampled images, specifically with 420 subsampling. I have here an image of 64x64 pixels, 8 bits per component, and thus a total of 64*64+2*32*32 = 6144 bytes + overhead. Yet, libtiff complains that the "StripByteCount" is bogus.

Here is more information on this file:

out.tif:
Magic: 0x4949 <little-endian> Version: 0x2a
Directory 0: offset 8 (0x8) next 0 (0)
ImageWidth (256) LONG (4) 1<64>
ImageLength (257) LONG (4) 1<64>

BitsPerSample (258) SHORT (3) 3<8 8 8>
Compression (259) SHORT (3) 1<1>
Photometric (262) SHORT (3) 1<6>
StripOffsets (273) LONG (4) 1<158>
SamplesPerPixel (277) SHORT (3) 1<3>
RowsPerStrip (278) LONG (4) 1<64>
StripByteCounts (279) LONG (4) 1<6144>
SampleFormat (339) SHORT (3) 3<1 1 1>
YCbCrSubsampling (530) SHORT (3) 2<2 2>

I checked into the tiff directory reader (tif_dirread.c), which again calls TIFFScanlineSize(), which again only divides by the subsampling in X direction, but rather ignores the subsampling in Y direction - hence getting an invalid result.

The image is attached.

Greetings,
        Thomas