[gdal-dev] OpenJPEG driver

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


Mickaël,

> >
> >>   * 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.
>
> The upper method is defined by the JPEG2000 norm (Annex B of the Part1)

ok, and that's what openjpeg use too ? If so, we might have inconsistencies
between the expectations of the GDAL driver when it calls openjpeg API and the
dimensions reported by openjpeg. That might actually remind me of something I
saw at the time where the driver was developed.

>
> >
> >>
> >> 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.
> >
> Yes it is not a real case but it is a conformance data which allow to
> define if a decoder is JPEG decoding compliant. It helps to verify
> that real less complicated case will be handled properly. For example
> we can see that JP2ECW is not compliant about this point.

Yeah, but ultra pedantry compliance testing can lead to less performance or
other issues in real world cases so there's a trade-off to evaluate. The JP2ECW
driver is used happily in production even if it isn't strictly compliant on that
point.

Anyway if you want to provide a well tested patch for the issue related to
overview dimensions, please do so.
As far as reporting overview levels whose dimension is < 256, there's a risk of
consumming more file descriptors than reasonable (see
http://lists.osgeo.org/pipermail/gdal-dev/2014-May/039155.html). Unless you want
to restructure the driver a bit so that all overviews share the same file
descriptor. But I guess some saving/restoring of the position would have to be
implemented, so that you can switch arbitrarily between overviews. I remember
some headaches with openjpeg since it has a tendancy of segfaulting if you don't
reset it properly between requests of blocks made in random order, so I prefered
to assign a file descriptor to each overview level.

Best regards,

Even



More information about the gdal-dev mailing list