<div dir="ltr"><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Aaron Boxer</b> <span dir="ltr"><<a href="mailto:boxerab@gmail.com">boxerab@gmail.com</a>></span><br>Date: Mon, Dec 21, 2015 at 10:27 AM<br>Subject: Re: [gdal-dev] OpenJPEG<br>To: Julien Malik <<a href="mailto:julien.malik@c-s.fr">julien.malik@c-s.fr</a>><br><br><br><div dir="ltr">Hi Julien,<br><div><div class="gmail_extra"><div class="gmail_quote"><span class=""><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Decoding at preccints level in OpenJPEG would definitely be a great addition.<br></blockquote><div><br></div></span><div>Yes, sounds useful. <br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I believe OpenJPEG performance could also be improved if multi-threading was managed directly inside the lib, since in the current situation OpenJPEG is purely monothreaded.<br>
>From my experience, Kakadu does a great job in keeping all your cores occupied close to 100% during decoding, even when decoding a single tile (so this is probably linked to the capability to manage independent decoding at the precinct level).<br>
In 3 geospatial software I know leverage on OpenJPEG (gdal, orfeo toolbox, and snap) to decode big datasets (think tens or hundreds of thousand pixels in each dimension), multithreading is handled from the user side, by creating a number of independent contexts and run them in separate threads to improve performance.<br>
This means we are all interpreting the codestreams and seeking into them independently, which clearly sounds suboptimal.<br>
I suspect managing multi-threading at a lower level directly inside OpenJPEG could open the doors to much better resource management (cores occupation, reduced I/O, etc...).<br></blockquote><div><br></div><div><br></div></span><div>The pull request I mentioned does use all cores for the computationally intensive part of decoding. Reading through the file is still single threaded. And this can take a good chunk<br></div><div>of time. <br></div><span class=""><div><br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I certainly concur with Even with the "as fast as it can be" :)<br>
Any percent you gain has a direct visible impact when (de)coding huge datasets.<br>
<br></blockquote><div><br></div></span><div>Thanks for the feedback. Good news for OpenJPEG performance : they will be *hiring* a developer next year to focus solely on performance.<br></div><div>If you guys are interested, please check out the OpenJPEG mailing list and you can apply.<br><br></div><div>Also, I would encourage submitting all of these great ideas as issues on the openjpeg github site:<br><br><a href="https://github.com/uclouvain/openjpeg/issues" target="_blank">https://github.com/uclouvain/openjpeg/issues</a><br></div><div><br><br></div><div>Cheers,<br></div><div>Aaron<br></div><div><div class="h5"><div><br>
<br>
On 20/12/2015 11:00, Even Rouault wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Aaron,<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am working on some performance enhancements for OpenJPEG,<br>
and I am curious about people's experience using the OpenJPEG driver with<br>
GDAL:<br>
<br>
Does it have all the features you need, if not what is missing?<br>
</blockquote>
Being the developer of the driver, I believe it must be close to using the<br>
available capabilities of OpenJPEG as best as possible. I may have overlooked<br>
some features, so other eyes checking the code are always welcome.<br>
<br>
 From my point of view what is mainly missing in OpenJPEG (the lib):<br>
- ability to decode efficiently sub-windows inside a tile (I guess this means<br>
using precincts). This is particuarly true for single-tiled big files<br>
- reduce memory consumption. I've found that to decode a 2048x2048 tile of a<br>
Sentinel2 product, it takes 600 MB of memory whereas the uncompressed size of<br>
the tile is 8 MB (2048x2048*sizeof(int16)).<br>
- ability to open files who have more than 2 gigapixels (or 4, I'm not sure<br>
where the limit is)<br>
- currently the driver closes and reopen the file each time it reads a tile,<br>
because there are(were?) some instabilities in seeking through arbitrary tiles<br>
(ie reading potentially not in ascending tile order). Would be nice to be able<br>
to avoid that<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Given that it is the slowest J2K library around, what would be acceptable<br>
performance in the geo-spatial world?<br>
</blockquote>
As fast as possible :-)<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
These changes apply to the current master version of OpenJPEG, which will<br>
be released shortly.<br>
</blockquote>
Were you refering to this PR : <a href="https://github.com/uclouvain/openjpeg/pull/668" rel="noreferrer" target="_blank">https://github.com/uclouvain/openjpeg/pull/668</a><br>
?<br>
<br>
Even<br>
<br>
</blockquote>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div></div></div><br></div></div></div>
</div><br></div>