[gdal-dev] OpenJPEG

[Aaron Boxer]

On Mon, Dec 21, 2015 at 5:35 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Le lundi 21 décembre 2015 23:29:14, Aaron Boxer a écrit :
> > 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.
>
> It is obvious it is possible since other J2K libraries can do it. They can
> decode small regions of single tile huge files very quickly. Probably using
> precincts, and TLM markers.
>

Yes, you're right. I was thinking about the code blocks, which can't be
broken up.

This feature would be quite involved: one would have to gather all of the
layers for
all of the code blocks in all of the precincts overlapping that sub-tile,
plus the immediately surrounding precincts, run the inverse entropy coder
to get
the wavelet coefficients, and then do an inverse wavelet transform,
with this incomplete set of coefficients.

I would say this would take a developer about 6 months to get it right.

I don't have time to do this, but perhaps a sponsor could be found in the
geo-spatial
community to support this work.  The performance work I mentioned,
scheduled for 2016,
is being sponsored by people in the archive community.


Cheers,
Aaron




>
> > 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
>
> --
> 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/8fcb0fcc/attachment.html>