[COG] Tiff and JPEG2000 - COW

[Norman Barker]

Hi Even,

thanks for the comments. I have put some more detail below.


On Fri, May 18, 2018 at 12:58 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Norman,
>
>
>
> > While this work is still experimental, we see a number of clear benefits
> to
>
> > COW over HTTP:
>
> >
>
> > * Progressive in spatial position, resolution and quality
>
>
>
> As far as I understand JPEG2000, the issue is that you can't have at the
> same time fast spatial sub-window access and fast overview access in the
> same file layout. I believe the former is obtained with PCRL
> (Position-Component-Resolution-Layer) progression order (but even with
> that, I believe you'd need several non-contiguous ranges as the precincts
> corresponding to the small overview level are common to several spatial
> regions), and the later with RPCL (Resolution-Position-Component-Layer)
>

I spent a lot of time working with JPIP and in my opinion it comes down to
how you define fast. One contiguous download isn't necessarily fast.
Several small downloads of packets may be faster. Add to that for each zoom
level with COG you are downloading a new tile as opposed to incremental
updates.

However I think there are a narrower subset of use cases for the complexity
of COW vs COG.


>
>
> > * Region of Interest encoding
>
>
>
> Is there a real use case for this ? If so, that could also be done with
> JPEG-in-TIFF. You can use different JPEG quality tables for each TIFF tile.
>

ROI with J2K is sub-tile and tile boundaries with TIFF may cause artifacts.
There are two use cases, obscuration and region enhancement at lower
resolution levels. An example is the display use case of drawing the eye to
a region of an image to zoom in on.

>
>
> >
>
> > The biggest stumbling block with JPEG2000 has always been understanding
> the
>
> > core spec which is very complex.
>
>
>
> Indeed. Having spent several weeks trying to improve OpenJPEG performance
> last summer, this involves huge headaches. Currently one big limitation of
> openjpeg regarding to what you mention above is that the lib needs to
> ingest the whole codestream of a JPEG2000 tile (so the whole file for a
> single-tiled JPEG2000 file). This could perhaps be enhanced, but this is a
> non trivial work. But this would have to be done since COW without an open
> source implementation wouldn't get much traction.
>
>
>
> To check quickly if COW is something that has a potential, I'd suggest you
> try with the GDAL JP2KAK driver and /vsicurl/ and look at the range
> requests done.
>

right, I did some quick experiments with the kakadu demo executables and
creating different codestreams as I no longer have the kakadu sdk. It was
some time ago now but I wrote the JPIPKAK driver.

I am currently evaluating this with Python and Numpy, but no commitment
there on whether this will be a full library, as you say J2K is full of
headaches.


>
>
> Another issue is that even with the best implementation, the CPU time
> needed to decode JPEG2000 is way higher than with JPEG.
>

Understood, I think this needs to be measured and is one of my goals. The
use case of progressive updates might be preferable for a user in an
interactive use case.



>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/cog/attachments/20180518/d4a8d578/attachment.html>