[gdal-dev] Fwd: [OpenJPEG] OpenJPEG 2.2.0 is out ! Faster and safer.

[N. Farah]

Thanks Even for updating the doc and also running some perf testing using those datasets.


The results you get when enabling multi-threading are very interesting: 26.s to 9.9 s. Then using the work in progress you end up with 1s. Basically a 26 times speed improvement.


Is there a timeline for releasing next version of openJpeg (either master or work in progress).


I'm very interested in the performance improvement since they looks promising and may get closer or beat to Kakadu performance.


Are there shared jp2 dataset you're using for performance benchmark ?


Noureddine


________________________________
From: Even Rouault <even.rouault at spatialys.com>
Sent: Monday, August 28, 2017 2:55 PM
To: N. Farah
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] Fwd: [OpenJPEG] OpenJPEG 2.2.0 is out ! Faster and safer.


On lundi 28 août 2017 18:00:03 CEST N. Farah wrote:

> Thanks Even for the quick response. I'll give it a try with setting

> OPJ_NUM_THREADS env variable to 8. Does it need to be used with

> GDAL_NUM_THREADS ? Any url to read about those two env variables ?

>

>



I've added some documentation per

https://trac.osgeo.org/gdal/changeset/39954





> The two dataset i used:

>

> <http://data.opengee.org/FusionTutorial-Full.tar.gz>

>

> https://1drv.ms/u/s!AkFDoDHsFe7_hkBS6GbG4xMqnk6t<http://data.opengee.org/Fus

> ionTutorial-Full.tar.gz>

> https://1drv.ms/u/s!AkFDoDHsFe7_hkG1-XDo7UztsPoC<http://data.opengee.org/Fu

> sionTutorial-Full.tar.gz>



Those images are single-tiled, so the GDAL_NUM_THREADS optimization will not help for them, and current openjpeg versions are super inefficient on those use cases, as GDAL expose a pseudo tiling to avoid a super big tile size, which cause the whole image to be decoded multiple times. I'm currently working on improving subtile decoding, that will substantially improve performance for such images (first steps are already in openjpeg master, next to follow)



I didn't have the patience to convert the whole image, so just took 3 GDAL blocks of 1024x1024

Without threading support, on hot runs:



gdal_translate bluemarble_4km.jp2 out.tif -srcwin 0 0 3072 1024



35.1 s GDAL 2.2 / openjpeg 2.1.2

26.2 s GDAL 2.2 / openjpeg 2.2.0



So I do see an improvement. Not sure why you don't.



Hardware: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz

OS: Ubuntu 16.04, 64bit build





and as a teaser:

3.1 s GDAL 2.2 / openjpeg master

1.5 s GDAL 2.2 / openjpeg (my work-in-progress branch)



With 8 threads:

9.9 s GDAL 2.2 / openjpeg 2.2.0

2.3 s GDAL 2.2 / openjpeg master

0.9 s GDAL 2.2 / openjpeg (my work-in-progress branch)







With usgsLanSat.jp2



gdal_translate usgsLanSat.jp2 out.tif -srcwin 0 0 3072 1024



40.2 s GDAL 2.2 / openjpeg 2.1.2

32.3 s GDAL 2.2 / openjpeg 2.2.0



>

> p.s: i'm using GDAL 2.1.2



GDAL 2.1 or 2.2 should have comparable performances on this, I think



--

Spatialys - Geospatial professional services

http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170828/733d4071/attachment.html>