Opened 10 years ago

Closed 10 years ago

#5257 closed defect (wontfix)

Differences in JPEG 2000 header between gdal 1.9.2 and 1.8.1

Reported by: bledoux Owned by: warmerdam
Priority: high Milestone:
Component: default Version: 1.9.2
Severity: normal Keywords: JP2, Kakadu
Cc:

Description (last modified by bledoux)

Hello,

When integrating new version of gdal 1.9.2 on our platform, we found the following differences in JPEG 2000 generated files:
diff /tmp/ref.txt /tmp/test_tpl.txt
29c29 < 000001c0 00 00 00 00 00 08 28 61 73 6f 63 00 00 00 11 6c |......(asoc....l|
---
">" 000001c0 00 00 00 00 00 08 28 63 6f 73 61 00 00 00 11 6c |......(cosa....l|

Our previous gdal version was 1.8.1. In both cases (gdal 1.8.1 and 1.9.2) we use kakadu-vs6.3.1

We found the following ticket in your database, which seems to be corrected in 1.9.0 http://trac.osgeo.org/gdal/ticket/4239 The ticket point a correction for big endian system. All our machines are little endian.

My questions:

  • Is the difference should be a side effect of the 4239 correction?
  • Is the difference should be considered as a bug ?
  • Is there any impact of this difference for further processing ?

Thanks in advance for your answers

Change History (5)

comment:1 by bledoux, 10 years ago

Description: modified (diff)

comment:2 by Even Rouault, 10 years ago

Hum, this might be indeed related to #4239. And yes a "cosa" box is definitely a bug.

But the user reporting the issue tested the patch on both big and little-endian systems, and in both cases, the generated file has a correct box name... So this might be a difference in behaviour between Kakadu versions if your version and his version are different ?

Can you edit frmts/jp2kak/jp2kakdataset.cpp and comment/remove the CPL_MSBPTR32( &nBoxType ); around line 1948, and then retry generating a JPEG2000 file.

comment:3 by Even Rouault, 10 years ago

I cannot reproduce the problem with Kakadu 5.2 (on little-endian machine). The string written in the file is "asoc" as expected.

In the case "cosa" is written, the problem might not be seen since by default gdal_translate -of JP2KAK writes both a GMLJP2 box (which uses "asoc", or its wrong variant "cosa") and a GEOJP2 box, which contain the same georeferencing info, but with different format. When reading a JPEG2000 file, if both are found, GDAL will select the GEOJP2 box over the GMLJP2. And if the GMLJP2 is incorrectly generated, it will just keep the GEOJP2. So you shouldn't notice the effect.

You could see the problem however by disabling the GMLJP2 box with : gdal_translate -of JP2KAK src.tif dst.jp2 -co GMLJP2=NO and they trying gdalinfo on dst.jp2

comment:4 by Even Rouault, 10 years ago

Ah: make sure you delete dst.jp2.aux.xml if it is produced by gdal_translate. See http://lists.osgeo.org/pipermail/gdal-dev/2013-October/037185.html

And thinking again about the issue, if it is what I thought, it should also affect GEOJP2 box. So both GMLJP2 and GeoJP2 boxes produced by gdal_translate (without -co GMLJP2=NO) should be corrupted.

comment:5 by bledoux, 10 years ago

Resolution: wontfix
Status: newclosed

The bug can be closed as the issue doesn't come from GDAL but from the way we are using it
We have developped a conversion tool which is based on GDAL but also uses our own routines. The problem comes from one of these routines which had to be updated following the correction of bug 4329.

We use the gdal function CreateAsocBox to create a jp20000 box but, for some reason, use our own function to write it.
Since the correction of bug 4329 affected both creation and writing we needed to update our code to benefit from the correction.
Thanks again for your help.

Note: See TracTickets for help on using tickets.