[NAME]
jxl_from_tree - jxl_from_tree

[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).
