<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p><br>did you bench timings using GDAL API & utilities (typically
with gdal_translate) ? The ones indicated in the PR use the
utilities that come which each library, but the integration within
a GDAL driver might have some influence on the timings.</p></blockquote><div><br></div><div>Yes, the timings will definitely be lower with the current driver, as it doesn't take full advantage of some library features</div><div>such as</div><div><br></div><div>1. tile cache</div><div>2. multi-threading across tiles</div><div>3. combination of memory mapping and PLT markers, where parts of</div><div>the codestream that don't need to be decoded are not even read from disk at all.</div><div><br></div><div>There's no reason why JP2Grok can't match the library utilities in performance, once I support</div><div>the above features in the driver.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>What about single threaded usage ?</p></div></blockquote><div><br></div><div>I can certainly benchmark this.</div><div><br></div><div>Aaron</div><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"><div>
<div>Le 03/05/2021 à 16:59, Aaron Boxer a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Folks,
<div><br>
</div>
<div>I would like to draw people's attention once again to the
pending JPEG 2000 driver PR</div>
<div>
<div><a href="https://github.com/OSGeo/gdal/pull/3449" target="_blank">https://github.com/OSGeo/gdal/pull/3449</a><br>
</div>
</div>
<div>which was opened 3 months ago. Since I last posted, the
driver now has an autotest script courtesy of Frank Warmerdam,
and all tests are passing. </div>
<div><br>
</div>
<div>In a nutshell, performance is 2-5 times faster than the
only other viable open source driver, from OpenJPEG, in
several common geospatial work flows. And performance rises by
around 2X if the new HTJ2K entropy coder is used. The AGPL
license will not work for everyone, which is why the driver is
disabled by default.</div>
<div><br>
</div>
<div>We've already discussed this at length in the previous
thread and in the PR, but if you would like to see this new
driver merged, please head over to the PR and give it a thumbs
up. Or, if you don't want this driver merged, please share
your feedback on the PR.</div>
<div><br>
</div>
<div>Kind Regards,</div>
<div>Aaron</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
gdal-dev mailing list
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a>
</pre>
</blockquote>
<pre cols="72">--
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</div>
</blockquote></div></div>