[gdal-dev] OpenJPEG

[Even Rouault]

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.

> 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