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

[Even Rouault]

On lundi 28 août 2017 19:36:16 CEST N. Farah wrote:
> 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).

Probably in a few weeks

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

There's a basic benchmarking suite here
https://github.com/uclouvain/openjpeg/tree/master/tests/performance
referencing datasets in
https://github.com/uclouvain/openjpeg-data
but it is not necessarily complete.

> 
> 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/F
> > us
> > 
> > ionTutorial-Full.tar.gz>
> > 
> > https://1drv.ms/u/s!AkFDoDHsFe7_hkG1-XDo7UztsPoC<http://data.opengee.org/F
> > u
> > 
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170828/73df5ec1/attachment-0001.html>