[gdal-dev] Default progression order in JP2OpenJPEG driver

Shot2 shoshot at ya.ru
Fri Mar 6 02:28:15 PST 2015


Jukka Rahkonen <jukka.rahkonen <at> maanmittauslaitos.fi> writes:

> 
> 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 consider
> as standard geospatial image, let's say 15000 by 15000 pixels, RGB.
> 
> -Jukka-
> 

Hi,
and thank you all for your dedication to bringing the GDAL-OpenJPEG codec up
to par! One small step for jpeg2000 :)

The books by Taubman & Marcellin "Jpeg2000 Image Compression Fundamentals"
(2002, Springer publ.) and "The JPEG 2000 Suite" by Schelkens et al. (2009,
Wiley publ.) are definitely worth reading, if time allows...

As noted by N. Barker, it all boils down to the intended or expected use of
said imagery. Imho it is up to the end user to decide - the best they can -
on sensible dimensions, local vs. remote browsing, usability requirements
(fast zooming, fast panning, etc.), decoder-friendly features, compliance
with standards or spec profiles, etc. One size can't fit all.

Still... in my experience the most unkindest impact usually depends on the
decoder involved and the specific codestream they expect to be fed: some
prove smart at leveraging the full power of the Jpeg2000 format, whereas
others are picky, crash-prone, or take a sluggish approach.

As a rule of thumb, from my various experiments with the format:
- quality-progressive orders (e.g. LRCP) are or limited interest, except for
specific cases involving interactive retrieval of remote datasets over slow
links, or for a quick "bitrate peeling" during transcoding. Still, in its
current state the Jp2OpenJpeg codec always creates a single quality layer,
thus making the default progression order rather harmless;
- quality-last, resolution- (RPCL) or region-progressive (PCRL) orders make
more sense for efficient zooming/panning respectively, e.g. for local random
access in huge geospatial imagery;
- precincts may greatly help with making zooming/panning/extraction
comfortable *if* decoders know how to use them;
- (indexed) tiles may prove either beneficial (w.r.t. memory requirements,
area extraction...) or detrimental (whenever a tilepart-blind decoder is fed
thousands of them).

tl;dr:
Considering plausible use cases, the new defaults for the Jp2OpenJpeg codec
look like a decent tradeoff:
- (L)RCP progression, maybe not the best but still a zoom-friendly
resolution-progressive order in the absence of multiple quality Layers
(otherwise RPCL could be a sensible alternative for gis datasets);
- ability to specify precincts (... which is now the default);
- use of moderate (1024²), memory-friendly, profile1-compliant or
configurable tiling;
- no more restrictions on the number of resolution levels.

Besides multiple quality layers, I'm wondering about additional benefits
from configurable Tile Parts indexes (-TP param, helps with browsing and ROI
retrieval when R- or P-indexed), as well as optional small code blocks (-b
param, e.g. 32² instead of the default 64², allowing for fine-grained ROI
retrieval).

Cheers


More information about the gdal-dev mailing list