<div dir="ltr"><div><div><div><div><div><div><div>Hi Even,<br><br></div>I was thinking about your request to decode only a sub-window inside of a tile.<br></div><br>I don't think this is possible. Because of the serial nature the j2k decoding,<br></div>there is no performance gain to only looking at a sub-window - the whole tile must be<br></div>decoded.  The only small gain is in memory : the final decoded region could fit<br></div>in a smaller memory buffer.  But, the speed will be the same for a tile or a sub-window.<br><br></div>Cheers,<br></div>Aaron<br><div><div><div><div> <br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 20, 2015 at 5:00 AM, 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">Aaron,<br>
<span class=""><br>
> 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>
<br>
</span>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>
<span class=""><br>
><br>
> Given that it is the slowest J2K library around, what would be acceptable<br>
> performance in the geo-spatial world?<br>
<br>
</span>As fast as possible :-)<br>
<span class=""><br>
> These changes apply to the current master version of OpenJPEG, which will<br>
> be released shortly.<br>
<br>
</span>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>
<span class="HOEnZb"><font color="#888888"><br>
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>