[gdal-dev] OpenJPEG driver

SAVINAUD Mickaël mickael.savinaud at c-s.fr
Mon May 19 15:23:25 PDT 2014


Hi Even,

Even Rouault <even.rouault at mines-paris.org> 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 it is. Thie file is a part of the jpeg2000 decoding conformance data.
>
>> , 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.

The upper method is defined by the JPEG2000 norm (Annex B of the Part1)

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

Mickaël
> Even
>
> --
> Geospatial professional services
> http://even.rouault.free.fr/services.html
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the gdal-dev mailing list