Selon Guillaume Pasero <guillaume.pas...@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.pas...@c-s.fr > > _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
