LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
January 2010
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
Thread
2010.01.14 11:35 "Re: JPEG compression in 3.9.2", by <jcupitt@gmail.com>
I just ran into this problem as well. TIFFReadEncodedStrip() seems to
write beyond the end of it's buffer for subsampled JPEG YCbCr images.
I was able to get it working by adding this case to my reader:
case PHOTOMETRIC_YCBCR:
TIFFSetField( tiff, TIFFTAG_JPEGCOLORMODE, JPEGCOLORMODE_RGB );
parse_rgb8( ...
break;
ie. by asking libjpeg to convert YCbCr to rgb on load. Not a good
solution if you actually want YCbCR of course, but it did fix my
crashes.
John
2009/12/11 Richard Nolde <richard.nolde@cybox.com>:
> Something definitely changed in the 3.9.X JPEG code. I found that some
> of the old libtiffpic sample images cause segfaults for tiffcp, and I
> had to do some workarounds to make tiffcrop handle them at all. Since
> OJEPG compression is now deprecated for writing images, I try to convert
> them to new JPEG compression on the fly but this is not working uniformly.
> Zackthecat and Smalliz come out at half the height they should and the
> colors are way off. The values are probably the subsampled data rather
> than the upsampled data and/or the Cb and Cr only. Quad-jpeg comes out
> OK in my working copy but looks more like a grayscale luminance map in
> the distributed copy. I'm also getting strange results, ie, several
> stripes of color but no image for ycbcr-cat.tif.
>
> tiffcp can no longer handle zackthecat.tif at all and smallliz aborts
> with a complaint about OJPEG not supported for writing (which is why I
> try to convert to new JPEG on the fly in tiffcrop).
>
> I use TIFFReadEncodedStrip/Tile to avoid issues with compression
> algorithms that do not allow random seeks and I found that the
> calculated strip sizes are smaller than you would get by computing
> length * width * spp *bps/8 so I override that when I allocate buffers
> and ask for more data on the read. For the problem images, it only
> brings back the number of bytes that it calculated, which suggests it is
> bringing back the down sampled data without up sampling it for YCbCr.
>
> I fiddled with the JPEG_COLORMODE pseudo-tag at various points when
> writing out the data, not at load time, but it didn't solve the problem
> for these images.
>
> Richard Nolde
> TIffcrop author
>
> Date: Fri, 11 Dec 2009 14:15:39 -0200
>> From: "Antonio Scuri"<scuri@tecgraf.puc-rio.br>
>> Subject: Re: [Tiff] YCbCr
>> To: "'Steve Mills'"<smills@multi-ad.com>, "'tiff list'"
>>
>> As Joris pointed out, you actually get Y Cb and Cr planes. So the first
>> component, that looks red, is infact Y, and indeed has the correct size. But
>> the Cb and Cr planes are downsampled. At least this is what I got here.
>>
>> I use libtiff 3.8.2. I have to comment the code at "tiff_jpeg.c" that does
>> "downsampled_output = TRUE" and add "tif->tif_flags |= TIFF_UPSAMPLED;" so I
>> got all YCbCr planes at normal resolution.
>>
>> When I upgraded to libtiff 3.9.2 my code stop working. Now almost all the
>> samples I have with YCbCr and JPEG compression fail to read. This includes
>> the known quad-jpeg, smallliz and zackthecat.
>>
>> It is the same for libjpeg6 or libjpeg7.
>>
>> I have to investigate the changes between 3.8 and 3.9 to see if I'm not
>> missing anything.
>>
>> BTW, I do use TIFFReadScanline and TIFFReadTile to read the image data.
>> I'm not using the high level functions.
>>
>> Best,
>> scuri
>>
>
> _______________________________________________
> Tiff mailing list: Tiff@lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tiff
> http://www.remotesensing.org/libtiff/
>