<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 5:35 PM, 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"><span class="">Le lundi 21 décembre 2015 23:29:14, Aaron Boxer a écrit :<br>
> Hi Even,<br>
><br>
> I was thinking about your request to decode only a sub-window inside of a<br>
> tile.<br>
><br>
> I don't think this is possible. Because of the serial nature the j2k<br>
> decoding,<br>
> there is no performance gain to only looking at a sub-window - the whole<br>
> tile must be<br>
> decoded.<br>
<br>
</span>It is obvious it is possible since other J2K libraries can do it. They can<br>
decode small regions of single tile huge files very quickly. Probably using<br>
precincts, and TLM markers.<br></blockquote><div><br></div><div>Yes, you're right. I was thinking about the code blocks, which can't be broken up.<br><br></div><div>This feature would be quite involved: one would have to gather all of the layers for <br></div><div>all of the code blocks in all of the precincts overlapping that sub-tile,<br>plus the immediately surrounding precincts, run the inverse entropy coder to get<br>the wavelet coefficients, and then do an inverse wavelet transform,<br>with this incomplete set of coefficients.<br><br></div><div>I would say this would take a developer about 6 months to get it right. <br><br></div><div>I don't have time to do this, but perhaps a sponsor could be found in the geo-spatial<br></div><div>community to support this work.  The performance work I mentioned, scheduled for 2016,<br></div><div>is being sponsored by people in the archive community.<br></div><div><br></div><div><br></div><div>Cheers,<br></div><div>Aaron<br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
> The only small gain is in memory : the final decoded region could<br>
> fit<br>
> in a smaller memory buffer.  But, the speed will be the same for a tile or<br>
> a sub-window.<br>
><br>
> Cheers,<br>
> Aaron<br>
><br>
><br>
> On Sun, Dec 20, 2015 at 5:00 AM, Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>><br>
><br>
> wrote:<br>
> > Aaron,<br>
> ><br>
> > > I am working on some performance enhancements for OpenJPEG,<br>
> > > and I am curious about people's experience using the OpenJPEG driver<br>
> > > with GDAL:<br>
> > ><br>
> > > Does it have all the features you need, if not what is missing?<br>
> ><br>
> > Being the developer of the driver, I believe it must be close to using<br>
> > the available capabilities of OpenJPEG as best as possible. I may have<br>
> > 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<br>
> > 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<br>
> > of a<br>
> > Sentinel2 product, it takes 600 MB of memory whereas the uncompressed<br>
> > 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<br>
> > sure where the limit is)<br>
> > - currently the driver closes and reopen the file each time it reads a<br>
> > tile,<br>
> > because there are(were?) some instabilities in seeking through arbitrary<br>
> > tiles<br>
> > (ie reading potentially not in ascending tile order). Would be nice to be<br>
> > able<br>
> > to avoid that<br>
> ><br>
> > > Given that it is the slowest J2K library around, what would be<br>
> > > acceptable performance in the geo-spatial world?<br>
> ><br>
> > As fast as possible :-)<br>
> ><br>
> > > These changes apply to the current master version of OpenJPEG, which<br>
> > > will be released shortly.<br>
> ><br>
> > Were you refering to this PR :<br>
> > <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>
> > --<br>
> > Spatialys - Geospatial professional services<br>
> > <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
<br>
--<br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
</div></div></blockquote></div><br></div></div>