AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
April 2012

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

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



Valid HTML 4.01!



Thread

2012.04.24 16:26 "YCbCr/JPEG issue in 4.0.1", by John Evans
2012.04.24 16:44 "Re: YCbCr/JPEG issue in 4.0.1", by Frank Warmerdam
2012.04.24 19:03 "Re: YCbCr/JPEG issue in 4.0.1", by John Evans
2012.04.24 19:19 "Re: YCbCr/JPEG issue in 4.0.1", by Even Rouault
2012.04.27 15:35 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.04.27 17:07 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.27 18:57 "Re: YCbCr/JPEG issue in 4.0.1", by John Evans
2012.04.28 01:58 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.05.02 09:51 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.05.03 21:58 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.28 09:28 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.28 09:46 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme
2012.04.28 15:10 "Re: YCbCr/JPEG issue in 4.0.1", by Charles Auer
2012.04.28 16:26 "Re: =?windows-1256?q?YCbCr/JPEG_issue_in_4=2E0=2E1=FE?=", by Charles Auer
2012.05.01 12:52 "Re: YCbCr/JPEG issue in 4.0.1", by Joris Van Damme

2012.04.27 18:57 "Re: YCbCr/JPEG issue in 4.0.1", by John Evans

Here's one more twist on this issue.  I created a variant of quad-tile.tif to 
use jpeg compression instead, and the YCbCr subsampling coefficients are 
definitely there, as verified by tiffdump

Example file at http://mexcdf.sourceforge.net/quad-tile.jpg.tif

<snip>
ImageWidth (256) SHORT (3) 1<512>
ImageLength (257) SHORT (3) 1<384>
BitsPerSample (258) SHORT (3) 3<8 8 8>
Compression (259) SHORT (3) 1<7>
Photometric (262) SHORT (3) 1<6>
SamplesPerPixel (277) SHORT (3) 1<3>
PlanarConfig (284) SHORT (3) 1<1>
TileWidth (322) SHORT (3) 1<128>
TileLength (323) SHORT (3) 1<128>
TileOffsets (324) LONG (4) 12<8 1758 3804 6087 8087 9790 11721 13956 16170 
18127 20290 22772>
TileByteCounts (325) LONG (4) 12<1750 2046 2283 2000 1703 1931 2235 2214 1957 
2163 2482 1912>
SampleFormat (339) SHORT (3) 3<1 1 1>
JPEGTables (347) UNDEFINED (7) 574<0xff 0xd8 0xff 0xdb 00 0x43 00 0x8 0x6 0x6 
0x7 0x6 0x5 0x8 0x7 0x7 0x7 0x9 0x9 0x8 0xa 0xc 0x14 0xd ...>
YCbCrSubsampling (530) SHORT (3) 2<2 2>
</snip>

The file can be found at http://mexcdf.sourceforge.net/quad-tile.jpg.tif

As reported before, the RGBA interface reads the TIFF just fine (on both 3.9.5 
and 4.0.1), but TIFFReadEncodedTile reports different results on 3.9.5 and 
4.0.1.  The first three YCbCr "clumps" running down the left hand side of the 
tile as reported by 3.9.5 are as follows (sorry for any bad spacing)

    clump  0:   0   0    2  0  138  139
    clump 32:  0   0    9  6  134  119
    clump 64: 44 40 63 59 230    95

but 4.0.1 reports

    clump  0:   0   0    2  0  138  139
    clump 32:  0   0    0  0      0      0
    clump 64:  0   0    9  6   134  119

and one can see the effect when the tile is visualized, that two rows of zeros 
are interspersed amonst each two valid rows of luminence pixels, and that a 
row of zeros is interspersed in between the valid rows of chrominence pixels.  

The last thing is that a 4.0.1 client reports the "JPEGDecodeRaw: application 
buffer not large enough for all data" warning during the call to 
TIFFReadEncodedTile and returns a -1.  A 3.9.5 client reports all ok, though.

If no objections, I'll file a bug report?