Ticket #2189 (closed defect: fixed)

Opened 3 months ago

Last modified 3 months ago

Writing YCbCr JPEG files no longer works

Reported by: warmerdam Assigned to: warmerdam
Priority: high Milestone: 1.5.1
Component: GDAL_Raster Version: 1.5.0
Severity: normal Keywords: gtiff geotiff
Cc: ysiddiqui@i3.com

Description

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

Change History

02/01/08 11:23:16 changed by warmerdam

  • status changed from new to assigned.

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.

02/01/08 12:02:30 changed by ysid

  • cc set to ysiddiqui@i3.com.

02/01/08 16:46:55 changed by warmerdam

  • status changed from assigned to closed.
  • resolution set to fixed.

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).

02/13/08 01:24:01 changed by warmerdam

  • status changed from closed to reopened.
  • resolution deleted.

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).

02/13/08 01:25:56 changed by warmerdam

  • status changed from reopened to closed.
  • resolution set to fixed.

OK, this should be alright again.

02/13/08 02:30:05 changed by 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).