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
