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.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
