[gdal-dev] OpenJPEG Testers Needed

[Aaron Boxer]

Hi Even,

Thanks so much for testing this.

...


On Wed, Jan 13, 2016 at 2:11 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Le mercredi 13 janvier 2016 18:10:52, Aaron Boxer a écrit :
>
>
> Some feedback:
>
> I've just tested the decode_region branch against the test suite of the
> JP2OpenJPEG driver
> ( https://svn.osgeo.org/gdal/trunk/autotest/gdrivers/jp2openjpeg.py )
> and noticed a regression with respect to lossless encoding:
>
> From autotest/gdrivers directory :
>
> official openjpeg 2.1 (or master branch) :
> $ gdal_translate data/byte.jp2 out.jp2 -of jp2openjpeg -co quality=100 -co
> reversible=yes
>
> decode_region branch:
> $  LD_LIBRARY_PATH=/home/even/tmp/openjpeg/install/lib:$LD_LIBRARY_PATH
> gdal_translate data/byte.jp2 out2.jp2 -of jp2openjpeg -co quality=100 -co
> reversible=yes
>
> Official openjpeg 2.1 (or master branch) outputs give same pixel values as
> the source image :
>
> $ python ../../gdal/swig/python/scripts/gdalcompare.py out.jp2
> data/byte.jp2
> Files differ at the binary level.
> Differences Found: 1
>
> ==> ok: they have same pixel value, the binary differences comes from not
> using the same encoder
>
> But they are tiny differences with decode_region branch
>
> $ python ../../gdal/swig/python/scripts/gdalcompare.py out.jp2 out2.jp2
> Files differ at the binary level.
> Band 1 checksum difference:
>   Golden: 50054
>   New:    49943
>   Pixels Differing: 833
>   Maximum Pixel Difference: 1.0
> Differences Found: 2
>
> The other tests pass
>
> I cannot reproduce directly with opj_compress however.
>

So, are you saying there are actual pixel differences between encoded file
and original?



>
>
> (side node: there's a build issue with old gcc 4.4 :
> In file included from
> /home/even/tmp/openjpeg/src/lib/openjp2/opj_includes.h:194,
>                  from /home/even/tmp/openjpeg/src/lib/openjp2/bio.c:38:
> /home/even/tmp/openjpeg/src/lib/openjp2/region_mgr.h:35: error:
> redefinition of typedef ‘opj_image_t’
> /home/even/tmp/openjpeg/src/lib/openjp2/openjpeg.h:686: note: previous
> declaration of ‘opj_image_t’ was here
> In file included from
> /home/even/tmp/openjpeg/src/lib/openjp2/opj_includes.h:197,
>                  from /home/even/tmp/openjpeg/src/lib/openjp2/bio.c:38:
> /home/even/tmp/openjpeg/src/lib/openjp2/tcd.h:185: error: redefinition of
> typedef ‘opj_tcd_tile_t’
> /home/even/tmp/openjpeg/src/lib/openjp2/region_mgr.h:36: note: previous
> declaration of ‘opj_tcd_tile_t’ was here
> make[2]: *** [src/lib/openjp2/CMakeFiles/openjp2.dir/bio.c.o] Erreur 1
> )
>
> oh, so how does one make a forward struct declaration to make gcc 4.4
happy ?



>
> Testing with 2048x2048 tiled images, with OpenMP enabled, I can see perf
> improvements.
> For example ~2s  (4 vCPU) vs ~3s (openjpeg 2.1) to decode a tile.
>
> Great. So, this is good. What are your system specs, may I ask ?




> With a single tiled 11310x17310 image with which GDAL uses the
> opj_set_decode_area() area,
> I couldn't really see the difference as the memory consumption grows to
> above 2 GB,
> which cause disk trashing on the system on which I test.
>
>
Yes, that makes sense, there is still work to be done, I guess. The wavelet
transform
needs to be modified to be more memory efficient.  What size of decode area
would you
typically want to set on an image of that size ?


Thanks again,
Aaron


Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160113/c9aed95d/attachment.html>