[gdal-dev] Reading remote jp2k files

[Even Rouault]

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