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 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev