Opened 15 years ago
Closed 15 years ago
#3053 closed defect (fixed)
GDALTranslate JPEG12bit Quality not working
Reported by: | pbe | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | GTiff jpeg12bit |
Cc: |
Description
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?
Change History (5)
comment:1 by , 15 years ago
Keywords: | GTiff jpeg12bit added; GDALTranslate removed |
---|---|
Status: | new → assigned |
Version: | unspecified → svn-trunk |
comment:2 by , 15 years ago
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!
comment:3 by , 15 years ago
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.
comment:4 by , 15 years ago
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.
comment:5 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I have updated the OSGeo4W libjpeg12 package, and FWTools with the latest fixes.
I will dig into this.