<div dir="ltr"><div>Victor, Even</div><div><br></div><div dir="ltr">Depande and Zeng did propose a HTTP JPEG2000 solution which is documented by Taubman here - <a href="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2758&rep=rep1&type=pdf">http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88.2758&rep=rep1&type=pdf</a> <br></div><div dir="ltr"><br></div><div>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.</div><div dir="ltr"><br></div><div>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.</div><div><br></div><div>Norman</div><div dir="ltr"><br></div><div dir="ltr"><br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 7, 2018 at 8:40 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Victor,<br>
<br>
> <br>
> I'm a jp2000 noob but do you know if windowed reads of remote jp2 data could<br>
> be optimized in some way? I am curious if we could see a "cloud optimized<br>
> jpeg2000" someday?<br>
<br>
There is the JPIP protocol that was designed for efficient streaming, but it <br>
requires a dedicated server and client.<br>
<br>
For a pure HTTP file-serving solution, there are different aspects<br>
* For non-tiled JPEG2000, coefficients are spread a bit over the whole file, <br>
so you may have to seek a lot to get them. I guess some progression orders <br>
might be more favorable (namely PCRL: Position-component-resolution level-<br>
layer) if you want to have efficient subwindowing, but that should be tested.<br>
* For tiled JPEG2000, the above issue becomes less relevant, but the main <br>
issue is to be able to efficiently locate a tile in the file. For that, the <br>
optional TLM packet marker should be written in the JPEG2000 file<br>
<br>
Those were theoretical concerns. Now on the practical side, some <br>
implementations might be better than others in making an efficient use of file <br>
optimizations. For non-tiled JPEG2000, OpenJPEG currently requires ingesting <br>
the whole codestream in memory (even if since openjpeg 2.3 only a subpart of <br>
it will be decompressed for windowed reads). And for tiled JPEG2000, it <br>
ignores the TLM marker and browse through the tilepart headers to identify the <br>
tiles. So work would be needed to improve that. From recollection, Kakadu does <br>
a good job in those areas.<br>
<br>
An alternative might be to store JPEG2000 blobs as the payload of a tiled <br>
GeoTIFF. There are some software editors that do that, apparently in slightly <br>
different ways (they might not always put a completely valid JPEG2000 <br>
codestream, not sure)<br>
<br>
Even<br>
<br>
-- <br>
Spatialys - Geospatial professional services<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></blockquote></div>