<div dir="ltr"><div>Hi Even,<br><br></div>Thanks so much for testing this.<br><br>...<br><br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 2:11 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Le mercredi 13 janvier 2016 18:10:52, Aaron Boxer a écrit :<br>
<br>
<br>
</span>Some feedback:<br>
<br>
I've just tested the decode_region branch against the test suite of the JP2OpenJPEG driver<br>
( <a href="https://svn.osgeo.org/gdal/trunk/autotest/gdrivers/jp2openjpeg.py" rel="noreferrer" target="_blank">https://svn.osgeo.org/gdal/trunk/autotest/gdrivers/jp2openjpeg.py</a> )<br>
and noticed a regression with respect to lossless encoding:<br>
<br>
>From autotest/gdrivers directory :<br>
<br>
official openjpeg 2.1 (or master branch) :<br>
$ gdal_translate data/byte.jp2 out.jp2 -of jp2openjpeg -co quality=100 -co reversible=yes<br>
<br>
decode_region branch:<br>
$ 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<br>
<br>
Official openjpeg 2.1 (or master branch) outputs give same pixel values as the source image :<br>
<br>
$ python ../../gdal/swig/python/scripts/gdalcompare.py out.jp2 data/byte.jp2<br>
Files differ at the binary level.<br>
Differences Found: 1<br>
<br>
==> ok: they have same pixel value, the binary differences comes from not using the same encoder<br>
<br>
But they are tiny differences with decode_region branch<br>
<br>
$ python ../../gdal/swig/python/scripts/gdalcompare.py out.jp2 out2.jp2<br>
Files differ at the binary level.<br>
Band 1 checksum difference:<br>
Golden: 50054<br>
New: 49943<br>
Pixels Differing: 833<br>
Maximum Pixel Difference: 1.0<br>
Differences Found: 2<br>
<br>
The other tests pass<br>
<br>
I cannot reproduce directly with opj_compress however.<br></blockquote><div><br></div><div>So, are you saying there are actual pixel differences between encoded file and original? <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
(side node: there's a build issue with old gcc 4.4 :<br>
In file included from /home/even/tmp/openjpeg/src/lib/openjp2/opj_includes.h:194,<br>
from /home/even/tmp/openjpeg/src/lib/openjp2/bio.c:38:<br>
/home/even/tmp/openjpeg/src/lib/openjp2/region_mgr.h:35: error: redefinition of typedef ‘opj_image_t’<br>
/home/even/tmp/openjpeg/src/lib/openjp2/openjpeg.h:686: note: previous declaration of ‘opj_image_t’ was here<br>
In file included from /home/even/tmp/openjpeg/src/lib/openjp2/opj_includes.h:197,<br>
from /home/even/tmp/openjpeg/src/lib/openjp2/bio.c:38:<br>
/home/even/tmp/openjpeg/src/lib/openjp2/tcd.h:185: error: redefinition of typedef ‘opj_tcd_tile_t’<br>
/home/even/tmp/openjpeg/src/lib/openjp2/region_mgr.h:36: note: previous declaration of ‘opj_tcd_tile_t’ was here<br>
make[2]: *** [src/lib/openjp2/CMakeFiles/openjp2.dir/bio.c.o] Erreur 1<br>
)<br>
<br></blockquote><div>oh, so how does one make a forward struct declaration to make gcc 4.4 happy ?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Testing with 2048x2048 tiled images, with OpenMP enabled, I can see perf improvements.<br>
For example ~2s (4 vCPU) vs ~3s (openjpeg 2.1) to decode a tile.<br>
<br></blockquote><div>Great. So, this is good. What are your system specs, may I ask ?<br></div><div><br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With a single tiled 11310x17310 image with which GDAL uses the opj_set_decode_area() area,<br>
I couldn't really see the difference as the memory consumption grows to above 2 GB,<br>
which cause disk trashing on the system on which I test.<br>
<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, that makes sense, there is still work to be done, I guess. The wavelet transform<br></div><div>needs to be modified to be more memory efficient. What size of decode area would you<br></div><div>typically want to set on an image of that size ?<br></div><div><br> <br></div><div>Thanks again,<br></div><div>Aaron<br></div><div><br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Even<br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</font></span></blockquote></div><br></div></div></div></div>