#3259 closed defect (fixed)
GeoTiff driver problem with JPEG Encoded Images
Reported by: | rvisiere | Owned by: | warmerdam |
---|---|---|---|
Priority: | high | Milestone: | 1.7.0 |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | gtiff |
Cc: | chaitanya, Even Rouault |
Description
There's a problem with Jpeg compressed Tiff images and GDAL 1.7 since revision 17563. The Geotiff driver can no longer read some of these images
These images have all the same characteristics :
- GeoTiff Image
- Jpeg Compression
- RGB BitsPerSample 8
- Photometric=YCbCr
- Not Tiled
- Width > 2000 and Height > 2000
- Image OK in any standard Viewer
- No problem with GDAL 1.6.2
A simple command like :
gdal_translate imgpb17.tif img.png -of PNG does not work.
( Windows XP 32b and Linux 64b )
--> There's a lot of warnings : .... Warning 1: imgpb17.tif:fractional scanline not read Warning 1: imgpb17.tif:fractional scanline not read ... More than 1000 errors or warnings have been reported. No more will be reported from now. ..30...40...50...60...70...80...90...100 - done.
and the output image is "black"
As a workaround, I modified the following line in frmts/gtiff/geotiff.cpp
line 4840
if( !TIFFIsTiled(hTIFF)
&& nBitsPerSample == 8 && nBlockYSize == nYSize && nYSize > 2000 && !bTreatAsRGBA )
{
/* bTreatAsSplit = TRUE; */ <---------
}
But it's only a workaround, not a solution
I attach a sample file to reproduce the problem
Attachments (2)
Change History (11)
by , 14 years ago
Attachment: | imgpb17.tif added |
---|
comment:1 by , 14 years ago
comment:2 by , 14 years ago
Cc: | added |
---|
comment:3 by , 14 years ago
I compiled with internal libtiff and no other external lib ( "Default" build Visual Studio 2005 SP1 / Windows XP SP 3 32b )
comment:4 by , 14 years ago
Keywords: | gtiff added |
---|---|
Priority: | normal → high |
Status: | new → assigned |
I have confirmed the problem, and will investigate.
comment:5 by , 14 years ago
Cc: | added |
---|
I believe there is a problem with TIFFReadScanline() and libtiff for jpeg compressed ycbcr imagery (or perhaps more generally).
I will try to dig up the corresponding libtiff ticket, and review if it can be fixed. If not, I'll likely have to disable splitting for ycbcr or jpeg compressed files or something.
comment:7 by , 14 years ago
Frank,
attached a tempative one-line patch that fixes the issue, at least for the way GDAL uses libtiff API. I'm not sure about absolute correctness for other libtiff usage (management of YCbCr subsampling seems to be one of the most tricky part of libtiff.)
The issue seems that tif_scanlinesize is set by TIFFReadDir() and never afterwards. At that time, it doesn't yet know we will read as a RGB buffer instead of raw YCbCr. Hence, according to the default subsampling, tif_scanlinesize is set at that time to width * 1.5. But after requiring reading as RGB buffer with TIFFSetField( hTIFF, TIFFTAG_JPEGCOLORMODE, JPEGCOLORMODE_RGB ), JPEGPreDecode() sets the sp->bytesperline by calling again TIFFScanLine() which now returns width * 3. Thus the later failure in JPEGDecode().
by , 14 years ago
Attachment: | tif_jpeg.c.patch added |
---|
comment:8 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Even's fix was all that was needed to fix this particular case though there turned out to be several issues upstream. All the fixes were incorporated upstream (see 1936) and GDAL svn trunk was updated (r18169).
Thanks for the report, this was a pretty serious problem.
I am quite confident it did not existing in previous versions.
Have you compiled GDAL with internal libtiff or external libtiff ? If external libtiff, which libtiff version is it ?