JXL_FROM_TREE(1)

🌸 JXL_FROM_TREE(1) 🌸

okay bestie, gather round, this is the User Commands manual page for jxl_from_tree, and it's genuinely such a niche little icon, iykyk 💅

---

✨ NAME ✨

jxl_from_tree — literally just jxl_from_tree, she said "my name is my name" and honestly? iconic 👑

---

🎀 SYNOPSIS 🎀

jxl_from_tree tree_in.txt out.jxl [tree_drawing]

that's it. three little args. slay.

---

🦋 DESCRIPTION 🦋

so like, jxl_from_tree started out as a debug/test tool 🛠️ — her whole origin story is producing handcrafted JPEG XL bitstreams directly, as opposed to the normal way where you feed pixels into the libjxl encoder and let it do its thing. different vibe entirely.

and these handcrafted bitstreams are tiny tiny tiny because all they consist of is a context model for the entropy coding — and that context model gets described by means of a MA tree (hence the name jxl_from_tree, the tree is the moment 🌳✨) — with the actual entropy-coded residuals simply being all zeroes, which compress to zero bits. zero. bits. the compression girlies are obsessed. 🫶

MA stands for "meta-adaptive" 🧚 and it's referring to the fact that we are not using a fixed context model (which is, like, the usual approach, no shade) 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 actually works well for the image it's encoding. and context modeling is itself "adaptive" in the sense that it adapts entropy coding to local context — so by letting the context model itself be changed too, we made something ✨ meta ✨. meta-adaptive. it's giving main character energy fr fr.

---

💖 EXAMPLES 💖

bestie watch this:

 % 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

gorgeous. flawless. now however 👀:

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

may produce either:

 77c4ccf6f23b320819610ebd5e1b2af0 splines.ppm

or

 9ca111503859edaa6c3b1cb92ff657b7 splines.ppm

two different hashes 😭 not a bug, it's just the lore, keep reading.

Splines are not currently used by the encoder at all — this is a test bitstream that was artificially produced, periodt. 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. and 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. so like. that's the whole thing. 💀

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. so breathe, bestie, it's fine, it's expected.

---

👑 AUTHOR 👑

This manual page was written by Mathieu Malaterre <malat@debian.org> for the Debian GNU/Linux system (but may be used by others). thank you for your service, we appreciate you 🫶🌸

---

aaaand that's the page!! this was jxl_from_tree version 0.11.2, August 2026, from the User Commands girlies 💖 bye bestie, go make some zero-bit residuals, you ate that ✨🎀🦋