[gdal-dev] OpenJPEG driver

Even Rouault even.rouault at mines-paris.org
Tue May 20 01:54:28 PDT 2014


Selon Guillaume Pasero <guillaume.pasero at c-s.fr>:

> Hi Even,
>
> Le 19/05/2014 20:01, Even Rouault a écrit :
> > Guillaume,
> >
> >> I am using the OpenJPEG driver from GDAL and I noticed some differences
> >> with the behaviour of an other OpenJPEG "driver" that I used before in
> >> the library Orfeo ToolBox. The GDAL driver fails to pass a conformance
> >> test : using the input file "jpeg2000_conf_p1_06.j2k"
> > Are you refering to
> >
>
http://code.google.com/p/openjpeg/source/browse/data/input/conformance/p1_06.j2k
> > ? I see this is a 12 x 12 pixel image ...
> Yes, this is a 12x12 image.
> >
> >> , reading the
> >> resolution level 4 (zero being the original image) , it should produce a
> >> 1x1 image with the pixel value [195, 36, 100].
> >>
> >> The behaviour of GDAL drivers differs on the following points :
> >>
> >>    * The number of overviews detected for a jpeg2000 dataset is limited
> >>      (no overview if its dimensions are both lower than 256). Even if the
> >>      the overviews can be computed by GDAL, it won't use the wavelet
> >>      coefficients for the highest levels, but rather perform the default
> >>      nearest neighbor interpolation.
> > Yes, this is to avoid exposing overviews that are too small and do not make
> > pratical sense. Other JPEG2000 drivers, such as JP2KAK or JP2ECW, have
> similar
> > logic.
> >
> >>    * The size of the overview at level 'n' is computed as : ovr_size =
> >>      raster_size / 2^n , whereas it should be ovr_size = ceil(
> >>      raster_size / float(2^n) )
> >>
> > Hum, any reason to particularly round to the upper value rather than the
> lower
> > value ? The JP2ECW driver does the rounding to the lower value too.
> This rounding to the upper value is done in OpenJpeg (for instance :
> src/lib/openjp2/j2k.c:7648 ). I think it is also used to compute the
> maximum number of resolutions. I am not sure if using a lower-value
> rounding in GDAL driver has an impact on the decompressed images (other
> than a possible crop).
> >
> >> I am using GDAL 1.10.1 and OpenJpeg 2.0.
> >> Is it relevant to report a bug on this topic ?
> > IMHO the test case seems to be a bit too artificial to justify any change,
> > unless there are real world cases where that would cause issues.
> I agree that this is a corner case, and I guess you would like to keep a
> consistent behaviour between the different jpeg2000 drivers. My worry is
> more about the compliance with the standard.

Apart from the issue of the rounding of the overview dimensions, why should we
care much about overviews < 256 pixels ? Why is compliance with the standard so
important on that point, I mean, practically ? Is there a certification of GDAL
under way, where that could be important to get the certification ? If so, you
could still add some configuration option to the driver (that would default to
the current behaviour), that, if set, would expose all levels and make the
compliance tests pass...

> >
> > Even
> >
>
>
> --
> <www.c-s.fr> 	*Guillaume PASERO*
> Ingénieur d'études et développement
> *Business Unit E-SPACE & Geo Information*
> <https://thor.si.c-s.fr/blogs/cs-blogs-business/>*- Département
> APPLICATIONS*
>
> *CS SystÚmes d'Information*
> Parc de la Grande Plaine - 5, Rue Brindejonc des Moulinais - BP 15872
> 31506 Toulouse Cedex 05 - FRANCE
> +33 561 17 64 21 - guillaume.pasero at c-s.fr
>
>




More information about the gdal-dev mailing list