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