NAME¶

jxl_from_tree - jxl_from_tree

SYNOPSIS¶

jxl_from_tree tree_in.txt out.jxl [tree_drawing]

DESCRIPTION¶

jxl_from_tree originated as a debug/test tool to produce handcrafted JPEG XL bitstreams directly (as opposed to using the libjxl encoder in the usual way by giving it pixels as input). These handcrafted bitstreams are very small since they consist of just a context model for the entropy coding (this context model is described by means of a MA tree, hence the name jxl_from_tree), with the actual entropy-coded residuals simply being all zeroes, which compress to zero bits.

MA stands for "meta-adaptive" and it refers to the fact that we are not using a fixed context model (which is the usual approach) but a context model that can adapt to the image contents itself. The context model itself is signaled in the bitstream, allowing an encoder to use a context model that works well for the image it is encoding. Context modeling itself is "adaptive" in the sense that it adapts entropy coding to local context; by allowing the context model itself to be changed too, we made something "meta".

EXAMPLES¶

% jxl_from_tree /usr/share/libjxl-testdata/jxl/splines.tree splines.jxl
% jxlinfo splines.jxl
JPEG XL image, 320x320, (possibly) lossless, 8-bit RGB
Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative
% md5sum splines.jxl
222fcf2d528904bc796a7c3a3c64cd76 splines.jxl

However:

% djxl splines.jxl splines.ppm
% md5sum splines.ppm

may produce either:

77c4ccf6f23b320819610ebd5e1b2af0 splines.ppm

or

9ca111503859edaa6c3b1cb92ff657b7 splines.ppm

Splines are not currently used by the encoder at all, this is a test bitstream that was artificially produced. Splines are additional image features that are represented internally in a vector form (control points for catmull-rom splines) and painted by the decoder on top of (added numerically) the underlying pixels. The jxlinfo tool only inspects the image header and sees that the pixels were encoded in RGB (not XYB), so it offers the suggestion that the image is possibly lossless, but this is in any case just a possibility (there is no way for it to know the history and workflow that was used to produce the image). In this case the pixels themselves are encoded losslessly using Modular, but they are just all black. The rest is painted with splines.

Spline rendering is defined mathematically in the spec and with infinite precision it is precisely defined; however practical implementations do things with limited precision and there can be tiny differences caused by rounding errors (which can be platform dependent and compiler dependent). The same is true for other coding tools like the DCT. For that reason we have conformance tolerances.

AUTHOR¶

This manual page was written by Mathieu Malaterre <malat@debian.org> for the Debian GNU/Linux system (but may be used by others).