[gdal-dev] OpenJPEG

[Aaron Boxer]

Hi Even,

I was thinking about your request to decode only a sub-window inside of a
tile.

I don't think this is possible. Because of the serial nature the j2k
decoding,
there is no performance gain to only looking at a sub-window - the whole
tile must be
decoded.  The only small gain is in memory : the final decoded region could
fit
in a smaller memory buffer.  But, the speed will be the same for a tile or
a sub-window.

Cheers,
Aaron


On Sun, Dec 20, 2015 at 5:00 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Aaron,
>
> > I am working on some performance enhancements for OpenJPEG,
> > and I am curious about people's experience using the OpenJPEG driver with
> > GDAL:
> >
> > Does it have all the features you need, if not what is missing?
>
> Being the developer of the driver, I believe it must be close to using the
> available capabilities of OpenJPEG as best as possible. I may have
> overlooked
> some features, so other eyes checking the code are always welcome.
>
> From my point of view what is mainly missing in OpenJPEG (the lib):
> - ability to decode efficiently sub-windows inside a tile (I guess this
> means
> using precincts). This is particuarly true for single-tiled big files
> - reduce memory consumption. I've found that to decode a 2048x2048 tile of
> a
> Sentinel2 product, it takes 600 MB of memory whereas the uncompressed size
> of
> the tile is 8 MB (2048x2048*sizeof(int16)).
> - ability to open files who have more than 2 gigapixels (or 4, I'm not sure
> where the limit is)
> - currently the driver closes and reopen the file each time it reads a
> tile,
> because there are(were?) some instabilities in seeking through arbitrary
> tiles
> (ie reading potentially not in ascending tile order). Would be nice to be
> able
> to avoid that
>
> >
> > Given that it is the slowest J2K library around, what would be acceptable
> > performance in the geo-spatial world?
>
> As fast as possible :-)
>
> > These changes apply to the current master version of OpenJPEG, which will
> > be released shortly.
>
> Were you refering to this PR :
> https://github.com/uclouvain/openjpeg/pull/668
> ?
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20151221/8e9c6402/attachment.html>