#2768 closed defect (worksforme)
JP2KAK writes seemingly unnecessary JPEG2000 pseudo color table
Reported by: | Coatman | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | normal | Keywords: | jp2kak |
Cc: |
Description
I am using the updated GDAL JP2KAK plugin that includes the change made yesterday to line 1562 of jp2kakdataset.cpp.
Starting with the GeoTIF file http://homepage.mac.com/gregcoats/jp2/images/rgbwcmyk01_YeGeo.tif that consists of 8 adjoining 100x100 squares of pure red, green, blue, white, cyan, magenta, yellow, and black, I created three GeoJP2 files using gdal_translate GDAL 1.6.0 with JP2KAK, kdu_compress Kakadu version 6.1.1, and geojasper version 1.3.2. These images are available at http://homepage.mac.com/gregcoats/jp2/images/rgbwcmyk01_YeGeo_JP2KAK.jp2 http://homepage.mac.com/gregcoats/jp2/images/rgbwcmyk01_YeGeo_kakadu.jp2 http://homepage.mac.com/gregcoats/jp2/images/rgbwcmyk01_YeGeo_geojasper.jp2
All three GeoJP2 images are properly displayed by QGIS using the GDAL JP2KAK plugin, Kakadu kdu_show, and Geojasper geojiv.
All three GeoJP2 files were created using reversible compression, and all three GeoJP2 files contain georeferencing info. ls shows that the JP2KAK created file is 1.7 times larger than the Kakadu created and geojasper created .jp2 files.
4645 Jan 6 14:00 rgbwcmyk01_YeGeo_JP2KAK.jp2
2803 Jan 6 14:00 rgbwcmyk01_YeGeo_kakadu.jp2
2751 Jan 6 14:00 rgbwcmyk01_YeGeo_geojasper.jp2
JP2 files are composed of multiple JP2 boxes. When I examined the internal structure of the three GeoJP2 files, I discovered that the JP2KAK created .jp2 contains, after the initial JP2 header box, a JP2 colr box, 1786 bytes long. The Kakadu created GeoJP2, and the geojasper created GeoJP2 do not contain a JP2 colr box. The extra 1786 bytes in the JP2 colr box nicely accounts for the JP2KAK created .jp2 file being larger than the Kakadu created and geojasper created .jp2 files. There is a comment on line 2195 of jp2kakdataset.cpp "Do we want to write a pseudo-color image?" With the example image, Kakadu and Geojasper do not write a pseudo color table, so I do not see the need for, or advantage of JP2KAK writing a pseudo color table to the .jp2 file. But I do not immediately see a harmful consequence to JP2KAK writing the pseudo color table, other than larger file size.
Change History (3)
comment:1 by , 15 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
comment:2 by , 15 years ago
Yes! Thanks. For what I was doing, as you so kindly pointed out, I should have passed to gdal_translate the creation option -co GMLJP2=NO, which creates a .jp2 file essentially the same size as a Kakadu created or a Geojasper created .jp2 file. I am delighted. Thanks.
4645 Jan 6 15:12 rgbwcmyk01_YeGeo_JP2KAK.jp2
2859 Jan 6 15:12 rgbwcmyk01_YeGeo_JP2KAK_GMLJP2=NO.jp2
2803 Jan 6 15:12 rgbwcmyk01_YeGeo_kakadu.jp2
2751 Jan 6 15:12 rgbwcmyk01_YeGeo_geojasper.jp2
comment:3 by , 15 years ago
Now I see more clearly that part of the 45 byte jp2h super box is a 22 byte ihdr box (that defines the image to be 100 rows x 800 columns x 3 colors), and a small 15 byte colr box, followed by a 1786 byte asoc box with GML info. Thanks for helping me.
rgbwcmyk01_YeGeo_JP2KAK.jp2 Box Length in bytes = 12, Box Type = 'jP ' Box Length in bytes = 20, Box Type = 'ftyp' Box Length in bytes = 45, Box Type = 'jp2h' Box Length in bytes = 22, Box Type = 'ihdr' Box Length in bytes = 15, Box Type = 'colr' Box Length in bytes = 1786, Box Type = 'asoc' ...
Greg,
I have reviewed rgbwcmyk01_YeGeo_JP2KAK.jp2 which my dumper shows like this:
Examination with an editor shows that the 1778 byte "asoc" box is a GML coordinate system description, not a color table. There may be a colr box within the jp2h super box but it isn't long and is due to only the call "colour.init( JP2_sRGB_SPACE );"
To avoid creating the GML coordinate system description use the GMLJP2=NO creation option.
I'm closing as I think there is no problem here. Please reopen if you feel otherwise.
Thanks for the good explanation and direct pointers to data demonstrating the issue.