[gdal-dev] decoding consistency between JPEG2000 drivers

[Even Rouault]

Le lundi 12 octobre 2015 16:01:23, Pierre Soille a écrit :
> On 09/10/2015 20:56, Even Rouault wrote:
> > Le vendredi 09 octobre 2015 20:26:34, Pierre Soille a écrit :
> >> Dear GDLALers,
> >> 
> >> recently we tested the following 3 JPEG2000 drivers: JP2ECW, JPEG2000,
> >> and JP2OpenJPEG.  A jp2 file was opened by all three drivers and we
> >> tested whether the decoded image were equal. To our suprise they are
> >> not: theJPEG2000 and JP2OpenJPEG lead to the same decoded image but they
> >> differ from the one obtained with JP2ECW.  Is this a bug in the
> >> implementation of the JP2ECW driver or is there any rationale
> >> explanation?
> > 
> > Pierre,
> > 
> > I don't think the differences come from the GDAL drivers, but rather from
> > differences/bugs/features of the underlying libraries. Regarding JP2ECW,
> > I recall to have observed differences depending if you read component
> > per component or all components together. The version of the JP2 ECW SDK
> > might also have some influence.
> > 
> > Even
> 
> Even,
> 
> thanks for your reply.  The tested version of the JP2 ECW SDK is 3.3.
> Regarding the comment by Jukka, I ran jhove on the jp2 file and got
> (among many other infos) the following:
>     CodingStyleDefault:
>       CodingStyle: 0
>       ProgressionOrder: 0
>       NumberOfLayers: 1
>       MultipleComponentTransformation: 0
>       NumberDecompositionLevels: 5
>       CodeBlockWidth: 4
>       CodeBlockHeight: 4
>       CodeBlockStyle: 0
>       Transformation: 1
> 
> My understanding is that 'Transformation: 1' refers to a lossless
> representation.

Yes, if they have output the values of the SPcod field, 1 means 5-3 reversible.

Alternatively you can use the dump_jp2.py script mentionned at 
https://trac.osgeo.org/gdal/wiki/UserDocs/JPEG2000Utils

Actually, having the 5-3  reverse transformation is a necessary condition for 
lossless conversion, but not a sufficient one : you also need to have enough 
quality layers encoded, but AFAIK that cannot be trivially checked from 
looking at the codestream parameters.

> If this is confirmed, the JP2 ECW SDK driver v.3.3
> should be used with care since it returns values that are not correct.
> Actually, even in the case of lossy compression, I would expect
> different drivers to return exactly the same result (as it happens for
> the JEG2000 and JP2OpenJPEG drivers in our test).

Yes, the ECW SDK v3.3 has a number of more or less known issues. Most of them 
have likely be fixed by later versions (that are binary only)
For completness, I think I've also seen issues where decoding (or perhaps 
encoding? I don't remember) of lossless images with 12 bit depth with openjpeg 
that didn't lead to original values.

> 
> Many thanks,
> 
> Pierre
> 
> >> Thanks a lot in advance,
> >> 
> >> Pierre
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com