jxl_from_tree - jxl_from_tree

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

jxl_from_tree 0.11.1                               March 2025                                   JXL_FROM_TREE(1)

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

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

       jxl_from_tree - jxl_from_tree

jxl_from_treetree_in.txtout.jxl [tree_drawing]