Writing YCbCr JPEG files no longer works

[warmerdam]

Frank,

I have found a problem with the new FW Tools (version 2.0.4):

A process that used to run before (version 1.3.1) now encounters an error. Here is the command used:

gdal_translate -co TILED=YES -co PROFILE=GeoTIFF -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR 
   -co TFW=YES -co JPEG_QUALITY=85 infile.tif outfile.tif

The error I see in the new version is:

0Warning 1: JPEGFixupTagsSubsampling:Unable to auto-correct subsampling values,
likely corrupt JPEG compressed data in first strip/tile; auto-correcting skipped

ERROR 1: Input and output dataset sizes or band counts do not
match in GDALDatasetCopyWholeRaster()

If you need sample data, let me know.

Yusuf

[warmerdam]

I have confirmed this. The problem appears to be related to the overhaul of the GeoTIFF CreateCopy?() method to use GDALDatasetCopyWholeRaster() instead of lower level TIFF entry points. This seems to break down with YCbCr compressed JPEG data which I think gets opened via the RGBA interface.

Two approaches come to mind.

1. Reintroduce a whack of logic in the GeoTIFF CreateCopy?() to handle writing this particular product.

2. Try and improve our ability to open YCbCr datasets in update mode and write to them directly instead of treating them through the RGBA interface.

[warmerdam]

Test suite entries added for this case in trunk (r13657).

Problem fixed by *not* opening YCbCr JPEG files in RGBA mode. Instead we just set JPEGCOLORMODE to RGB unless explicitly disabled. Fixed in trunk (r13658) and 1.5 (r13659).

[warmerdam]

It has become evident that gdaladdo still has problems, primarily because after OpenOffset?() many additional calls are made to SetDirectory?() which reloads the directory (hence clearing the JPEGCOLORMODE) without reapplying the color mode setting.

This is corrected by restructuring the JPEGCOLORMODE setting to be in SetDirectory?() so it is always applied any time the directory is loaded. This is done in trunk (r13771) and 1.5 branch (r13772).

[warmerdam]

OK, this should be alright again.

[warmerdam]

It turns out I needed the JPEGCOLORMODE in OpenOffset?() as well. This was revealed running pure read-only cases in the test suite. Fixed in trunk (r13772) and 1.5 branch (r13773).