GDALTranslate JPEG12bit Quality not working

[pbe]

Using GDALTranslate - FWTools2.4.2

If I include the -co JPEG_QUALITY=95 parameter then I always get the following error multiple times

GDAL JPEGLib:Missing Huffman code table entry

It would appear that that JPEG_QUALITY can not be defined!

The documentation states that the default value is 75. As the compression factors that I am getting are about 4.4x I doubt that the compression is set to 75%. It appears that it always uses 100.

Is there an issue with defining compression quality with 12bit JPEG or is the parameter not correctly handled?

[warmerdam]

I will dig into this.

[warmerdam]

I have tested translation of the mandril image and I see the following outputs with various qualities:

-rw-r--r-- 1 warmerda warmerda 217080 2009-07-07 15:06 out_60.tif
-rw-r--r-- 1 warmerda warmerda 246342 2009-07-07 15:06 out_75.tif
-rw-r--r-- 1 warmerda warmerda 287327 2009-07-07 15:07 out_85.tif
-rw-r--r-- 1 warmerda warmerda 246342 2009-07-07 15:05 out_default.tif

So it appears to me that the quality parameter is generally working, and the default is 75.

However, with a quality of 90 or 95 I get a similar problem with missing entries in the huffman table. I will continue to dig into why this occurs. I had been fairly confident that the default tables were "spanning" - that is included all entries that might be needed. Apparently I'm wrong!

[warmerdam]

Somewhat uncharacteristically the problem seems to be with the dc rather than the ac tables. It seems there is a dc 13bit code being generated which I did not think was possible.

Furthermore, if I run cjpeg -quality 90 on the mandril image it emits a "Bogus Huffman table definition" error message even though it is computing an optimal huffman table for the particular image.

So I think there is an old issue with high quality 12bit jpeg production with libjpeg.

Continuing to dig.

[warmerdam]

I have determined that cjpeg was only failing because I happened to be running a copy that added one to all the frequency counts, and that this particular code was not done quite right. I have regenerated the dc tables using cjpeg using a quality of 99 and with this generator code:

#ifndef generate_universal_tables
  long total = 0;
  int has_over_15 = 0;
  
  for( i = 0; i < 256; i++ )
  {
      if( freq[i] > 0 )
          printf( "freq[%d] = %d\n", i, freq[i] );
      
      total += freq[i];
      
      if( i > 15 && freq[i] > 0 )
          has_over_15 = 1;
  }
  printf( "total = %d\n", total );
  printf( "has_over_15 = %d\n", has_over_15 );

  for( i = 0; i < 256; i++ )
  {
      if( i < 16 || has_over_15 )
      {
          freq[i] += 1;
      }
  }
#endif

The change is to allow up to 16 values in the dc tables. The tables have been updated upstream in libjpeg, and in GDAL trunk (r17440) and 1.6-esri (r17441). I will rebuild the libjpeg12 package in osgeo4w and regenerate an FWTools build with the changes on monday - the package build is on a system not available till then. I'll leave this open till then.

[warmerdam]

I have updated the OSGeo4W libjpeg12 package, and FWTools with the latest fixes.