[gdal-dev] Default progression order in JP2OpenJPEG driver

[Even Rouault]

Le jeudi 05 mars 2015 21:54:57, Jukka Rahkonen a écrit :
> Norman Barker <norman <at> cloudant.com> writes:
> > Even, Jukka,
> > 
> > the NPJE end EPJE specifications are both good for understanding
> 
> progression order in JP2. It all depends on what you are trying to do, so a
> default is just that, something that can be changed.
> 
> > A JP2 file with PLT markers (packet markers) in my experience removes
> > most
> 
> of the overhead of accessing packets as the header decoding doesn't have to
> be performed.
> 
> 
> I fear that only few people understand really JP2 and I do not count me in.
> It is our responsibility to try to offer reasonable defaults for we

I bet very few people can understand the whole complexity of the standard (and 
I do not count me either!). There are so many parameters that you can tune...

> consider as standard geospatial image, let's say 15000 by 15000 pixels, RGB

I've done a few tests encoding a RGB BMNG tile (21600x21600) with the 
JP2OpenJPEG driver with different block size (1024, 4096, 16384), with 
precincts, and with the PCRL, LRCP and RPCL progression orders. Using a 16384 
large tile requires a huge amount of RAM with openjpeg (at least 16384*16384*3 
= 800 MB, but perhaps twice or third times that when counting temporary 
buffers)

When reading with an efficient JPEG2000 decoder, for the same block size, I 
can't see any really noticeable difference between the 3 profiles, either when 
reading a single pixel, random regions at full resolution, or a downsampled 
region. I presume the difference between the organizations would appear in 
network streaming contexts rather than with an efficient storage and reader.

Note that the L factor doesn't count much as the driver only outputs one layer 
(that is something potentially tunable by the openjpeg lib, but not exposed by 
the driver)

Other findings are :
- The larger the block size is, the more efficient downsampled reads are 
(because that tends to reduce the number of requests that span over several 
tiles).
- The smaller the block size, the more efficient non-scaled reads are (with the 
size of regions of the order of the block size or less).

Those findings do not apply when using openjpeg as a reader because, as far as 
I tested, it doesn't seem to use precincts or other optimizations for intra-
tile reading at full resolution, so 1024x1024 tiles is a reasonable setting 
for it. Larger tiles will require a lot of memory for decoding too and will be 
slow. The main drawback is that getting the overviews will be slower than if a 
single tile would have been used.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com