On Mon, Dec 21, 2015 at 5:35 PM, Even Rouault <even.roua...@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.roua...@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 >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
