[gdal-dev] OpenJPEG driver

[Guillaume Pasero]

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.
>
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140520/aa5438c0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo_cs.png
Type: image/png
Size: 19066 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20140520/aa5438c0/attachment-0001.png>