Victor, Even Depande and Zeng did propose a HTTP JPEG2000 solution which is documented by Taubman here - http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2758&rep=rep1&type=pdf
Precincts and Tiles are different approaches for data access within J2K, and defining a J2K profile (and an encoder that supports it) for grouping packets that contribute to a particular precinct closely together in the file would improve J2K access over HTTP byte-range requests even more than tile access. I don't necessarily agree that you need index tables to do this within a file, but they wouldn't hurt imo, I have written a commercial JPIP server in the past. For Cloud Optimized Wavelets to work we need J2K encoder/decoders that are designed for this use case and that is non-trivial. Norman On Fri, Sep 7, 2018 at 8:40 AM Even Rouault <[email protected]> wrote: > Victor, > > > > > I'm a jp2000 noob but do you know if windowed reads of remote jp2 data > could > > be optimized in some way? I am curious if we could see a "cloud optimized > > jpeg2000" someday? > > There is the JPIP protocol that was designed for efficient streaming, but > it > requires a dedicated server and client. > > For a pure HTTP file-serving solution, there are different aspects > * For non-tiled JPEG2000, coefficients are spread a bit over the whole > file, > so you may have to seek a lot to get them. I guess some progression orders > might be more favorable (namely PCRL: Position-component-resolution level- > layer) if you want to have efficient subwindowing, but that should be > tested. > * For tiled JPEG2000, the above issue becomes less relevant, but the main > issue is to be able to efficiently locate a tile in the file. For that, > the > optional TLM packet marker should be written in the JPEG2000 file > > Those were theoretical concerns. Now on the practical side, some > implementations might be better than others in making an efficient use of > file > optimizations. For non-tiled JPEG2000, OpenJPEG currently requires > ingesting > the whole codestream in memory (even if since openjpeg 2.3 only a subpart > of > it will be decompressed for windowed reads). And for tiled JPEG2000, it > ignores the TLM marker and browse through the tilepart headers to identify > the > tiles. So work would be needed to improve that. From recollection, Kakadu > does > a good job in those areas. > > An alternative might be to store JPEG2000 blobs as the payload of a tiled > GeoTIFF. There are some software editors that do that, apparently in > slightly > different ways (they might not always put a completely valid JPEG2000 > codestream, not sure) > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com > _______________________________________________ > gdal-dev mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
