[gdal-dev] Reading remote jp2k files

[Norman Barker]

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 <even.rouault at spatialys.com>
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
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20180911/f086fe57/attachment.html>