JPEG XL

**\_wb\_** _“A selection of Occam's razors”_ 2025 image/jxl 31 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKcg5RMDTm4uLKTFMI1%2FbT9QtXsFMw4FJQQOYbmZoCRRQUdBX8XBV0Lc2hnODUnNTkEgVDLhDHsSwdqD5cwZwLAA%3D%3D)

Nice title

**\_wb\_** _“Alien Muscle Tissue Sample”_ 2025 image/jxl 37 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKcg5RMDLn4spMUwgoSi1TsFMwNDHgUlDQVXAsSw%2FX9gtX0DUEcoHSQI4ukGunAJJGFTEyNQWLQbU55uQAdQFNhYkFp%2BakJpcAbYMrAZtsaMkFAA%3D%3D)

**\_wb\_** _“Entropie Émergente (Étude nº 241)”_ 2025 image/jxl 28 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5eLKTFMI1%2FbT9QtXsFMw4NJV8HNV0DUyMQSyHMvSgTIKhlwKCgpcAA%3D%3D)

**dogelition** _“ITU-R BT.2111-3 (2K, 10 bit, full range PQ)”_ 2025 image/jxl 234 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=rVaxctswDN3xFfwB3wEgaIlLhgy9TLm0HTL3EiXxkGsu8ZD8fW2XlCUBsGRfNvGBJAi8B0D3m8ftS6DcCtx0m%2BeXbSDOAj%2Fe%2F7x2d38%2FwmotYcUkcL3ZPnZv%2B70Iv7oHJsRw9xNg8xSew1VgghDqN%2B%2B%2Bj6t4WB3Wn7u1xKYAPdQw9lAPtjgEj3A7hg%2BGh51hCvcGUoYQVuF3tw2pZdfGqM8VS15%2F2wuYk2uLMTkvSJJggX%2FXe41eHEuUFswTaZiv%2F9jRadmTZcw3SZzyzRw13xGjxXdqGh3W3rCWxsr3QU9kZbUaW8uow9E28XlEJ5OUYX77ZfTF5MpDRVje32SY8er4rNSyjbfjgijeMsEJX6anElmDYHmPoD3n2mq%2B9r1BBr1mD%2BSotIejS%2B5HDyicoTpEo2ZQVYxiCTaiI1gh9ASbKJ4QrBKRXW%2Bm%2FpCjK9rMnrZashtAQxbTaxLNDDG4URSBYB7m%2BUv1gB6UidPbgApZCWfNEU26%2BBxHFhGzTfxkkt2hgHBOD3I9XT57zny2c%2Biy5rX4%2BuGBSZWrGi8cDmU9rvCxb2Pu1NFCDLNDpf6PqFIxnuELf9L5lC7rz0gCM1mLx7EK1qg4s96m1aZqrVYO5kU5c8TiZWxWxXievhfIbOE0RFhwswKPCvgH)

they updated the standard to change the position of the gradient, and the colors are quantized differently

+ i found an optimization to save 1 byte

don't know if it was an android or chrome update, but this is actually fixed now on my device (poco f7 pro)

**\_wb\_** _“Stairs mutating”_ 2025 image/jxl 29 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKcg5RMDTm4spMUwjX9tP1C1ewUzAyNeVSUNBVCFfQNTK1BDMdy9KB0uEKhlwA)

**\_wb\_** _“Entropie Émergente (Étude nº -225)”_ 2025 image/jxl 31 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnl4spMUwjXDQ%2FX9QvX9gsPV7BTMOBSUAAJavsBxaB8BQVdheDUnNTkEgVdIyNTqIh7UWJKZmpeCVgJEteQCwA%3D)

**eis** _“broken prism”_ 2025 image/jxl 33 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c0nNKUkMSMxJLSlJ5eLKTFPwC9f1U7BT0DXkUlAAcsPdPYA8AyBHQUFXIVzB0MgCyvZT0DUyNeUCMR3L0sO1%2FUByAA%3D%3D)

**eis** _“broken prism”_ 2025 image/jxl 33 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c0nNKUkMSMxJLSlJ5eLKTFPwC9f1U7BT0DXkUlAAcsPdPYA8AyBHQUFXIVzB0MgCyvZT0DUyNeUCMR3L0sO1%2FUByAA%3D%3D)

**eis** _“the smiling face”_ 2025 image/jxl 116 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=zZFNC8IwDIbv%2BRW5yyDp%2BrWLICp4ElFhZ8G6DcbwUPz9dvELL166gy0lKWlfkuddhT6edqc%2BxBhgvzyihbo7xxaZlIZN6Jo2PnI4XPtuCIBpKSLM2qLiJlEpJ1HhPBEmKL3G1zGsANbD%2BYlsenTlHxmQj85qEmxj%2FIHuMzRTTsNjlmXDW4Xzm8mnx5aEnFKJoEvRe7SVwdIodIpQs0WX6toTOiOEUzRgtJa7JS916x7vnbLy31Uket6IM1%2BudBesZ9tiW%2BNc5ijwEOIzW9yaVMOC7w%3D%3D)

that'll teach me not to check this channel before sleep

ok then

**\_wb\_** _“The Snake”_ 2025 image/jxl 110 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=rZJNC8IwDIbv%2BRW5j0r3Ud3Jgyh6GsIOPQ8bXaGUIfn%2FmM4N6nm2hCd5C2%2FTjzMFHu5DIGYC6x2PWGqt4Ub%2BNfI3P3l2NM0rANBPwUcClKE3TSV2yaX6i8u2XhaTdlMzqtwZqLS4GQ2tUPKZErO%2BshYeMkpAnbER7jNKQJPRCE1O2a8xGev0UJfolrcC%2F0SrrFWdLTpr8YjpuEksOtGWGlFhT4EenC51Va7vwXmK8hXgpzQf)

**\_wb\_** _“More Delta Palette Abstract Stuff”_ 2025 image/jxl 32 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c0nNKUkMSMxJLSlJ5XLKLElJLSjJULDg4spMUwjXDQ%2FX9QvX9gsPV7BTMOBSUAAJavsBxaB8BQVdBfeixJTM1LwSBV1DIEAXBAkgcY0A)

Delta palette my beloved

what the heck

The page is erroring out on Firefox *and* Chromium Android

Which one?

https://jxl-art.lucaversari.it

**Haley Halcyon** _“Baby’s First Sierpiński Triangle”_ 2025 image/jxl 28 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=C89MKclQMDQwMuHySM1MzyiBsJ0yS1JSC0AyXFyZaQoVCnYKBlwKCkBmJZQJ5viF6%2FrB%2BQoKugrBqUADoDyEvC5MCKbEAI0PtIWLC1UaKgEA)

**Haley Halcyon** _“Randomized: Laser Slopes”_ 2025 image/jxl 136 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=bVOxasMwEN31FdqNwDpJjrQUDA3NZAIdNKeJmgQ8pSa0kI%2Fv6ezYkuLNvJPv3bv37j30w2F%2F6MMwBOavp%2BHCwTRsF67ny0Cf7PrN97dwb79%2Btrcbf%2BOy0YzziEZ4wmCDGKFeeI%2BIkM4SNIJVJ7oRbtQEj4WPHaHWzCjngn8GJM%2BQ9n7uKmxRSbVhC0yIMwvTwz%2BwISiTsiD5Nk5ZQ8HSh%2BPABTQlVdv3OJSs0yZHGlTq5O3CB2nnqQmKjspkVqEN0SqkyQqkBsW8wOP8XWSpm6IWf%2FLkVTjxClaqs8ba5YMn7gHY1elxt6DK6fdTGKIC%2BaLAR4c3K8JwEXaOCHE%2BdY5uC%2BtYsbtKajUmrcOV4T8Onh1oG3o1YKB06lqSUW1WEyWkgXw1v%2Fi6sG0aUkpXwNTAGZatYI7okgOYfE1nhToJbkdnJFnOKE2WwT98pBQrMuNKa7NzVe4lgHR02q6551bM26IVpgw4nSLLYxHp0ut8XhJoKD2J8m0hRDS5Qz7uFnP7Dw%3D%3D)

**Haley Halcyon** _“Waterfall Brushes”_ 2025 image/jxl 38 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c0nNKUkMSMxJLSlJ5QrPTCnJUDA0MDLh8kjNTM8ogbCdMktSUguAMhZcXJlpChUKdgoGXAoKQGYllAnm%2BAE5piZgnoKCrkJwaglUDiIbrgtSAJMHqXAvSkzJTM0rUdA2hosiVOoilIIUh4MdlJqioGuMXRxqCMJiCMvI1JQLAA%3D%3D)

Is there a reference somewhere on how Squeeze makes extra channels (and groups? idk how else to explain what I'm seeing)? Just guessing doesn't seem to work for me

Well there is the official specification but it’s a bit hard to read if you’re not already familiar with image compression systems

Free versions of it are floating around this Discord

If you want a technical breakdown, there's a paper explaining all the features of JXL https://arxiv.org/abs/2506.05987v2 Specifically for JXL art, I'm not entirely sure how it works...

yeah, I was asking more on how it works for jxl art, seems like there's little control for squeeze in the current tool even if the standard allows for more flexibility (e.g. squeeze levels always go down to 8x8, even if I don't need/want them to do that)

I guess time to read the specs and see how hard it is to make a tool myself to construct the MA trees and header

i am dumb i can grasp the logic behind the logic tree but i still need a video tutorial

is there a video tutorial

**PetrKDN** _“View from Space”_ 2025 image/jxl 35 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnl4spMUwjX9tP1C1ewUzDg0lXwc1XQtYQAIM%2BxLB0oqwDmKSgocAEA)

Where is this bot getting its art from

Can anyone showcase their art here too

?

When people submit their art on the website, the bot posts it here

If it's regular art instead of made with MA trees, probably fine to post in <#803950138795622455> or <#806898911091753051>

click the "source tree" link

Ah alr thx for the info

i learned that if you press publish on the art site a bot publishes it here

whats the easiest way to make seemingly random noise image?

wait what

every time i press run without changing anything it changes the image

im stupid

what am i doing wrong

https://discord.com/channels/794206087879852103/824000991891554375/1365778611570741372

Can you press the share button and paste the link here?

https://jxl-art.lucaversari.it/?zcode=dVDLCsIwELznK_ZeAkmfngQV0VMEFXKWGttcqkgQ_Xt32_QRqrfZYWdmZ9fWXc3D1bBgh6c1jbs4e2-gYMfNGXLG7A0-sAQZMwDEJWKBEICD8gjpN9KZ6MaW0Ls9UZ6g7dWrUpHSEEE8Y7eI4lFMbmkhwjVNYj5qh5BxL4iRP2jKkV2RtlSS9wXKiZEf5TQqLNh5nozDg-ZcKubK8Brt7wh1MhPsbyC9Owoeqsgk6wto3OeDAUYYW9XOXIFLNg1J2oO_

im still learning tho

so i could totally be missing something

It fails to decode for me ```JPEG XL decoder v0.12.0 6efa0f5a [_AVX2_] {Clang 20.1.8} Failed to decode image DecompressJxlToPackedPixelFile failed```

huh

Oh, it's a noise texture? It's just black for me with a few random pixels every time I press run

hm thats odd

shouldnt... the.. thing work the same on every device..?

I have the same as jonnyasom2

maybe try to delete cache?

**Jonnyawsom3** _“All RCTs (No-Channel-Permutation)”_ 2025 image/jxl 894 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=7ZS%2FTsMwEMb3ewq%2FAJLtuE66ILUwMKCoAqTMFQ2tB1pUDIK3xwmBxME34fGbcved7%2FO%2F%2BLc6uuetd6cjXb%2Bd%2B0AoKSWtnd%2B1L%2F4gKmrcLny1NBXdtG5%2F8N%2Fx3dWDkFSf%2FO321RO5J%2FEoLoMixBCqEPbJx6AP6WZzbt8nkhAXopllahz%2BGQ3t%2BuftXUv9J1d22rQPHbqaDBm0Qk%2B0UTWROuqLmd5Ndd%2F2J8JWJONVMB1qadlKerXcDIrzMZKrFDbtpZdsh%2BYqqfPWJrUDzc1aMt4ld0SlZpy4m7MVV0ivlPNnb5M7noox4i6N%2B8EkJR5KSOt%2B14ZSo3%2FfCM1r0XMNSRO5xB7jQ%2F3RafUvnCjgBDgBToCTPDjRwAlwApwAJ3lwUgAnwAlwApzkwYkBToAT4AQ4yYOTBXACnAAnwEkenFjgBDgBToCTPDgpgRFgBBgBRr4A)

https://embed.moe/auto.gif?q=https%3A%2F%2Fcdn.discordapp.com%2Fattachments%2F824000991891554375%2F1430012686086967346%2FRCTs.jxl%3Fex%3D68f83a98%26is%3D68f6e918%26hm%3D7d64339e7b96916e02936b946e6be5e2ee9b9571d57d2fc7fd2dae1f7d3297b5%26

The JXL plays at 1 fps, so sorry about the epilepsy from the bot

https://embed.moe/auto.gif?q=https%3A%2F%2Fcdn.discordapp.com%2Fattachments%2F824000991891554375%2F1430014080449511495%2FPhoton_Noise_Frame_Seed_Demo.jxl%3Fex%3D68f83be5%26is%3D68f6ea65%26hm%3Db1d691ca47dc463287c1e49f4f8f133a15edd3fa64bec48568652749073a5e2a%26

Discord previews strike again

it's a malformed tree, it misbehaves when you do that. you have ``` if y > 12 [then something] [else] if y > 136 ```

the `y > 136` is not an allowed test in the branch that has y <= 12, since it will always be false. Only tests are allowed that can still split the remaining range.

I'm not sure what exactly happens in this case but I think it just writes a bad jxl that the decoder will refuse to decode

I'm not entirely sure which channel this would fit in, but I think the best fit here: is there a tool to extract the MA tree from a Modular JXL? Or just setting all the residuals to 0? Essentially converting an arbitrary JXL into its underlying JXL art I know that the prediction models that the MA trees describe are autoregressive, so the resulting images probably wouldn't be all that interesting-looking without the residuals to guide the prediction process in the right direction I tried looking at the various crates, but I didn't spot a way to manipulate the bitstream in this way

I don't know if we have a tool for that, but we do have the code for generating these: [The JPEG XL Image Coding System](https://arxiv.org/pdf/2506.05987#subsubsection.5.2.3)

so this does give you the MA tree as well

Ah that's cool 😄 figure 26 is (cooler than) the sort of thing I had mind, but for arbitrary trees

that's in the encoder IIRC though

(not that it'd be too hard to do that in the decoder too, with some code change)

you could potentially try altering the code to replace all would be residuals with 0 at encode time, though prediction error is a property which itself can be used as a decision node in MA trees, so there might be side effects that mess everything up depending on how you do this

iirc the images in figure 26 are entirely created using the jxl art tool

I was messing around with the code used for generating Figure 27 some more here https://discord.com/channels/794206087879852103/1346574799396147220

I thought there were more examples there, I think I posted a handful in some channel instead

Oh yeah, that's a second level of autoregression kinda

Kinda. It gives you the tree in a formatted graph file, so you can't edit it or use it for another en/decode

yeah that's what I meant ^^

MA tree saving/loading has been brought up a few times as something for the API. It'd be nice if it was formatted to match jxl_from_tree, then we could do such editing with existing tools

my algorithm for creating this sucks but it's supposed to resemble the mona lisa 🤷‍♂️ https://jxl-art.surma.technology/?zcode=lVixkt02DOzfV7zekxkCBEmwcRE3rp3M5APii32diyt8f5_TkwVQwg7N6ziSKIDAYrHgP89fX77fqfHt89Pzt-8vdy719ufzy9enH2_P9fbl09_3dLs9_3d_vX-8U27b8ufbUtUelnwsOZEtmbflv9sHtz_ufz293D9wOR6l41HOtrJfk3_nW2vcWo6VuFWSuLWHrVKPVc3h-xxNVXvZybws1SKg6Z1nrdFqC9-X0X74v8T_X46wexnTIDmaaseqFdua35lBiV7maErUTsUOFjGrnksQJY5RevMyIEj4WBWQ3xR9sn-UuhKuamfWNR_FfgaQEv1hOQd8B1m34-Vj1Zq97upV2OIhIlxaP1ZEMUo1noLYwkQ11hnFOmODFQ_eiac9WZ56zBPPKkLD9yVik5IlirJa-KItLzDfS5aEX0W0ew82J2DYUE6SV44mFqoqnlPDsVhFN1nzvrr30YEOXC7FMwmqQMMO9TOSYRMAg2MB5Tac-zhiRC2lCNsNelY5kXEksncfEGzstkNvT6mhMAMU9kk3UF7i5TypftRtPMJ5JZisZ1w9oFOtUZW2ROM8a05TGvfwWUxJZIl385l3HwCKzb-kGfYY1Fc8X6EzdTw0TLQUC7N5ISFepQlJFavkavVByRVE9kpn_wDUAQC1V4GWpRbUzj_brDaHS_JGwtnFQ1npC11H1lmJkPk-xAUQh0Rb1ZpWi2lviIidTKitMGczGgSqritgWudNclG8M-IumtM7NYjMlDCqxTaRs6h45JKw3ZZXL-DVrBOzCCeRN5UGB8zUoPxoSbuPJb2i1ax-u6w04mxolnLmpKFQtoegSbZYp-RjCml2eBBodgBcagzJbLzVaAmYtXijjI2tRF-1XhTh5qq2s_LYnvV-yd_pzwqEWHaxqemsXn8Hmy1WplFAKclMJhq_gFYqQGDm887HYdOKmp7ycetTMQ3ELwD-AEzHIC2dSs4M-eD-NfocRXDMdAfCs_BFRj4ybSLPGZIvCmXnSkBgMus4uax5Vb0W8gq5uRr2iRjM0mBsl34ecH83KzQ-w2QvK51oUikTd2tbKfVm3N2XilDNSV2SJx7v4i2ehhuTY-XCb5jQqKBZABSRS2sC2pqAuKbanIlohbt6H8XEMTQYZEvyA_jdSYnactAf7o34azT_gExTc_B3BmFCw6CfmSuwkmZT1mYwbAFjzuksXuYgLQRcZO893JfaW_JDJQORGsSy5aVfJcb2WsoSjPt5Kr_AC2SneHaaGfP7OFBt4C9SJhqn0IRCuov3BDINpkcSnt0UyOwWphhh-RVsXSoqkkEWORmUlRmg5QgLb2II_jwrMjDhDzKgXQa3vXWByDJgJ53Z7XWOaWMYMASgrLRB8doYDvgBmOXhmgykT9c4kS55fChnGzHBaNIBo9fhXhTcdMk0ZsO9rywNouU8Tf40wno138_oAtOvAzn5dR1qRjQ7LYF7vY7uYGnGk6DTe79zSeuNyhdg2Mm61oWdfhjcJCuoDO6Xm-TX07U2iLyCzPvFF9W6pHr6ufgetmKqKrhDzKMkjrlF49cQIGcR0OQzKgMFUyOYfjqgVtJptwejBTnhoXsYjcjtFaC-OmXJZMabXwSWlQGg-bTV1yQQD0t3E4WH5i0SSS6ejnduD4ghNKwMjAZ2aAxfHy72_wc if you run it through libjxl w/effort 9 it does better 🫢 (edit: as in, libjxl does better. again, the algorithm kind of sucks 😔 )

we should add a way to jxl-art to specify the residuals per node (say, as a list of numbers followed by another list of numbers that gets repeated as long as needed), instead of only allowing infinitely repeating zeroes in all nodes (which would be `[], [0]`). That would make it a lot more expressive, since you'd no longer have to rely purely on the predictor offset like it is now.

that would be wonderful!

My current project is semi related to this (setting residuals)... more to come... 🤔

My script finally finished.... May I present the first ever JXL hashquine! This JXL image displays its own MD5 hash! ```bash $ md5sum jxl-hashquine.jxl c0dec000ec179f9af04ef4d7ee0c6c59 jxl-hashquine.jxl ```

I'll do a technical writeup of this at some point but whew it involved so many hacks to get working

woah!

impressive

I imagine having the md5 start with 'c0dec000' was for extra flexing

To be honest that was the easiest part. You can brute force 32bit prefixes of md5s in about 5 min on a laptop

yep, that makes sense

did you do patch copying + arbitrary bytes in the red part for changing md5?

Yes I modified jxl_from_tree to allow arbitrary error bytes to be supplied, but I also had to do a bunch of messing with the encoder and compression settings, such as crafting a specific Huffman tree that allowed me to replace arbitrary bytes in the file after encoding

ahhh nice trick

I am guessing you could have gotten the same result possibly more easily by adding a 8-bit huffman code for a patch frame that never actually got used

now to nerdsnipe someone into improving jxl_from_tree by a lot by announcing a "smallest jxl hashquine challenge"

You can certainly make it a lot smaller, most of the size comes from the lack of compression. I think if you change up the Huffman tree you probably can trivially reduce the size by at least a factor of 8. Could also do it in fewer frames, but the prediction tree complexity was growing so I decided to split it into 32 frames

is it just me or does the publish button not work?

**Lonnie** "*Flag of Cornwall* 2025 image/jxl 42 bytes [source tree](<https://jxl-art.lucaversari.it/?zcode=C89MKclQMDQwMODySM1MzyhRMAMynTJLUlILQBJcXJlpChUKdgqmJpZcCgpATiWQYwzmKCjoKgSnligYgNlQKSOoFEzSEIVnADEDZKAJihmGyGYYo5lhAOVhWIFuCVwDAA>)

**\_wb\_** _“Cornwall flag”_ 2025 image/jxl 42 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMOQKz0wB0QYGBlweqZnpGSUKZkAmV2aaQoWCnYKJiQGXggKUY2oG4oC5lUCukQmECxcwNoMJKCjoKgSnliig8w25MGURMmjmYpiKaiayiTAZLgA%3D)

oh lol I didn't see this was already done

For reference the SVG file size on Wikimedia Commons is 359 bytes https://commons.wikimedia.org/wiki/File:Saint_Piran%27s_Flag.svg

or 277B once optimized <:KekDog:805390049033191445>

compressed to 184 bytes with `brotli --best`

zstd compresses it down to 200 with the best compression. I assume brotli's advantage here is that it has a spec-defined dictionary trained on SVGs among other things

199B with gzip

since zstd supports signaling custom dictionaries, I wonder if at some point the web standard will define zstd dictionaries per IANA media types. so one for `image/jxl` trained on a large corpus to compress a lof of the header away, certain ICC profiles which are duplicated a lot etc.

same philosophy of brotli, except brotli to my knowledge has a single dictionary trained on a bunch of data

hmm I wonder if I can download that training data and derive a zstd dictionary from it, and see how it compares

but the post here https://discord.com/channels/794206087879852103/794206087879852106/1444335869778464958 claims the SVG is 186B, trying to find it online but can't

Here is my final larger cleaned up version. I ended up reducing all the logic down to one frame with one massive prediction tree. I think I can reduce the file size further (maybe cut it in half) if I write some more optimizations on my naive tree algorithm (most of the tree size come from rendering the digits). Also unfortunately I did not manage to get the 8x size reduction from better huffman codes because the bit flips were causing mis-alignments... The final cover image was directly injected into the residual bitstream in jxl_from_tree. ``` $ md5sum shark_hashquine.jxl c0dec0007b5246f7428936d9bed2f446 shark_hashquine.jxl ```

Here is what the tree logic "circuit" traces look like

that's one of the coolest hashquines I've seen, very nice

fwiw, you can render digits using patches and that might be easier 😄

I have not tried to do anything with patches yet. Is there a way to conditionally select a patch based on existing pixels in the image? Each 15x15 region here can render any of the 15 digits based on the pixel value on the "wire" plugged into it

I did that by having 16 extra alpha channels that are either 0 or 1 and using them for blending

so you always have 16 patches (one per digit), but you can use channels as a bitmask to choose which character you actually use

Gotcha, I considered a similar thing, but with the current compression setup I have, each additional channel adds considerable size to the final image file

ah, you can get all that data from the color channels using prev-channel properties for the extra channels

you just need 3 nodes per extra channel, I believe

I think I need to see if its possible to mark a channel as not having any residual data associated with it? Right now each channel has WxH tokens of residual data (mostly all zeros) and with bad compression it gets large

basically `if {PPrev-N} > N { if {PPrev-N} > N+1 { 0 } else { 1 } } else { 0 }`

all 0 residuals are basically free

and you can use a histogram that says "residuals are 0" for those channels and you use ~0 bytes

histogram with 0 symbols = all 0 values from the entropy coding

Is it possible to have a histogram that only applies to a single channel and a different one for the other channels in a single frame? Right now I can't have an unbalanced histogram due to how the bitflips work. I did try having something like that where zero tokens were 1 bit each but ya it failed to work with my bit flip setup

yup, every leaf can have a different histogram

Ok I'll have to look into that, I think that would save a lot of space, by only having this bad histogram on the one channel where it is needed

**\_wb\_** _“Heat”_ 2025 image/jxl 53 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=TYuxCgIxEET7%2FYrpQ2Q3sRZU5Cxki0NILXdR03iiQfDvTfCIFjM83u5sUh7jPV8hTP32CPHUx8EJM%2FaHjnRKzwhesCslFVrV%2BJJlZSJKZwxYgQko%2BJ4RsFBYmTFAvvdg1GpoT9XYEIoyGn66TrrHaUzxlv%2FU%2BnVRoztYR03UIcR5%2BgA%3D)

How does specifying noise in jxl_from_tree work? A graphic designer made a really nice looking gradient background with noise for a nonprofit I'm a member of, but we had to change it to a pure gradient because the noise bloated the filesize way too much. With both Chrome and Firefox getting JXL support in the near future, it might be worth trying to make a small JXL art version of the original image.

Noise is entered as the 8 LUT values from dark to light Here's some numbers I grabbed from libjxl as an example `Noise 0.166 0.169 0.053 0.04 0.034 0.03 0.028 0.026` <https://jxl-art.lucaversari.it/?zcode=88vPLE5VMNAzNDMDk5ZA0sDUGESagAhjCAkijCzApBmXU2ZJSmpBSYaCBVdEpBMXV2aaQrKCnYIBl4IClGkIZCoo6CoEp5Yo6JoaGCBxITxdhXAFIy4uAA>

hmm

also huh how does XYB work in jxl_from_tree? -500 and +500 being valid don't make a lot of sense for 8 bits.

Oh right, I just did -500 and +500 to get a gradient down the middle, I didn't think about it much

I guess the bit depth only matters after conversion from XYB to RGB

Bit depth was also a random number, probably don't need it

XYB in jxl_from_tree uses some default quantization, you can actually adjust those too. The default quantization for xyb in modular mode is just something I considered fine-grained enough to get sufficiently high quality lossy modular. It's something like 11 bit or so

Modular mode has no problem representing negative numbers, in XYB it makes sense to do that (so grayscale has X=B=0). It is the same when you do the YCoCg RCT when using RGB.

right

adjusting the XYB quantization, is that XYBFactors ?

I forgot the syntax but that could be it, yes.

did the syntax of JXL Art change?

There have been additions and YCoCg changed to RCT 6, but nothing breaking AFAIK

I remember I had to use an older version of the site to view some really old JXL art from a few years back because it looks different now

soo uh I think something changed at some point but I have no clue what and when

the RCT numbering changed

btw, how does the jxl art encoder entropy-encode? borrowing the code from libjxl, or something custom?

I think it's ANS.

as for looking different, that can happen with decoder changes too. spline rendering and limits changed over time, some trees no longer decode, and it's always possible that arts producing out-of-spec files will render differently.

borrowing from libjxl, the website is essentially jxl_from_tree from libjxl just on a website

The latter part I had guessed, I just somehow didn't realize jxl_from_tree was from libjxl. Thanks!

how so?

the way jxl_from_tree interpreted the RCT command changed, so older files will have different colors if run through a newer version of jxl_from_tree

is there some kinda mapping?

i.e. what used to be RCT 1, what is it now?

YCoCg used to be RCT 1, now it's 6. Not sure what the mapping actually is.

that's what I actually cared about 😅

`sunset.jxl` https://jxl-art.lucaversari.it/?zcode=jVPBTsMwDL3nK3zeFM3J2gEXJJiAHVBBG1LOFQ1thNqiLUPb3-O0KU27CnGLn_Psl2fn3thMf9kCBDJlMjpIjK7ZRpu8sATKiG3Xb7BiL3ujK5taU1dwxR73aalf6wPwJSJwiciY-YB3uAVkAIsZrIt9XaYwW1DoM4KOTZBTINsIgMNOW-Ax-pjyJ8pHXdwgiitFIBe_oCOqS6BntXVJ3mRX3yW8TtVAjugCcaRrFQ85c1iOOPwGvQfPx8CBs2vfcim1-zxDWmVQ1kdy1VSH9t4_hDo3njYELQdPv_vOk3ni9MQBTpcTxRNnXYwYJHrKA53iUaap01tLevXJ6kBup9ZnTWXs5VM6Aa77CgftqYVzewg15gWOO5t02lfzVggU8XBsAifsEdP2SDZpgewGs6Wp1GWlD39NxO3icA-a_6Izp2W8QjJcIdWOYpIajZhuYj8

recent jxl_from_tree just uses the mapping from the spec the older one used the mapping that was used a long time ago, where 0=RGB (noop), 1=YCoCg, and 2+X gets mapped to RCT X in the numbering from the spec

A while back I made a demo of all the RCTs (without channel permutations) https://jxl-art.lucaversari.it/?zcode=7ZS%2FTsMwEMb3ewq%2FAJLtuE66ILUwMKCoAqTMFQ2tB1pUDIK3xwmBxME34fGbcved7%2FO%2F%2BLc6uuetd6cjXb%2Bd%2B0AoKSWtnd%2B1L%2F4gKmrcLny1NBXdtG5%2F8N%2Fx3dWDkFSf%2FO321RO5J%2FEoLoMixBCqEPbJx6AP6WZzbt8nkhAXopllahz%2BGQ3t%2BuftXUv9J1d22rQPHbqaDBm0Qk%2B0UTWROuqLmd5Ndd%2F2J8JWJONVMB1qadlKerXcDIrzMZKrFDbtpZdsh%2BYqqfPWJrUDzc1aMt4ld0SlZpy4m7MVV0ivlPNnb5M7noox4i6N%2B8EkJR5KSOt%2B14ZSo3%2FfCM1r0XMNSRO5xB7jQ%2F3RafUvnCjgBDgBToCTPDjRwAlwApwAJ3lwUgAnwAlwApzkwYkBToAT4AQ4yYOTBXACnAAnwEkenFjgBDgBToCTPDgpgRFgBBgBRr4A

Oh cool I didn't know animations actually get rendered as animations in the online tool

Unfortunately the Discord embed bot doesn't maintain the timings, so it was quite the epilepsy risk last time I tried https://discord.com/channels/794206087879852103/824000991891554375/1430012701668675686

It'd be nice if I could animate a real image with different RCTs to show the effects more clearly, but I'd probably have to do some trickery with partial loading to avoid the decoder running the reverse transform

Thinking about it, that would be yet another use case of expanding djxl options. Disabling features like RCT, Patches, Noise, ect to reveal the image as it's stored

**Anonymous** _“lol ”_ 2026 image/jxl 73 bytes https://jxl-art.surma.technology/?zcode=C89MKclQMDQwMuHySM1MzyiBsLmCC3Iy81K5DBUMKIEDrt%2BUQv3GBgYKxqZADKTNTA24XPNSoCEzGkJQ%2FYZGCibA0DG1AGIQDeSbAWkTExM4Hyg%2FGnIY%2Bs2NTMBpC0SjpS1dheDUEgVtAwA%3D

**\_wb\_** _“Flares”_ 2026 image/jxl 52 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=ZYvLCsIwFET39ytmXwJ5QLITqkhdRVuErKWNbaBUkSD4915LKQV3Z87M7FPu4jMPUJKa2GolJS41NYcrLJ1fKU75ltNjgiFKd7TYQRHA%2BGGUjICAh1ALhm2vtZ41x1CdWJg5%2Fnblu%2FeFDyj%2B3JHJrDc%2BWWu3k3IcIZxzqwsx9UOOHb%2B%2B)

missing the "alien" branding

https://www.januschka.com/jxl-art/

why are the + and - wiggly red underlined like a complaining spellchecker?

fix is underway, "16" in front killed my keyword marker 😄

⁨``` Bitdepth 8 Width 256 Height 256 Gaborish 16BitBuffers XYB XYBFactors 4096 512 256 EPF 2 if c > 1 - Set 128 if c > 0 if x > 128 - Gradient +2 - N -1 - Set 200 if y > 128 - W +1 - Set 100 ```⁩

just need to figure out why chrome-native jxl fails to handle the 16bitbuffers

(art thing, now uses png output in this case, eventhough it says "JXL Native" in the top area)

(if it's not clear: this is currently https://github.com/veluca93/jxl-art/pull/3, I will merge and upload to jxl-art.lucaversari.it once y'all tell me you like it :D)

crabbified JXL art :3c ```rust fn main() { let art = jxl_art::Art::new() .bit_depth(8) .width(256) .height(256) .gaborish() .sixteen_bit_buffers() .xyb() .xyb_factors(4096, 512, 256) .epf(2) .tree( ma_tree!( if c > 1 - Set 128 if c > 0 if x > 128 - Gradient +2 - N -1 - Set 200 if y > 128 - W +1 - Set 100 ) ) .build(); } ```

what's that 👀

⁨`ma_tree!`⁩ is clearly a proc macro

people were talking about the jxl art syntax so I was playing around with what it could look like when exposed as a Rust library

not a real library, sorry to disappoint 😅

ah that makes a bit more sense 😄

tbh the syntax was chosen because it was easy to parse in C++, not because I thought it was the best syntax ever

if you want type checking without the complicated proc macro, you could directly build an AST by using nested enums/structs for nodes

though that probably won't ever be as ergonomic to write JXL art with, but a lot more ergonomic to implement

the tree syntax is reasonably human-readable when indented properly and it's pretty minimalistic (not much overhead) the keyword syntax in jxl_from_tree is not very nice, in particular for things like splines or noise it's not exactly nice and it's annoying that you cannot parse it without knowing how many arguments each keyword has

Pretty sure you can make something like `split(N < 10, split(W < 5, Gradient + 3, Zero + 2), Weighted - 1)` work

It's almost the same as the tree syntax too

in Prolog that's how you'd do it since you can just use the built-in term parsing then

**xman** _“Pixels Singularity”_ 2026 image/jxl 74 bytes https://jxl-art.surma.technology/?zcode=hZHLDoIwEEX3%2FYrZE5IOUHVlosboChMx6dpg1W7wkWrUr3daH7SAkRVzpnPvnXaszUYdzR6Qs8VZq8qsjT5U0GfLyQqwx4rTRamHYgzo01u4wxBQcFc6UBL4lAAx5F5F7Ru1Ba%2BRg3I2t9iDdnJ03eVRLiGCpLMzpb8kFLLq2YC3j0srFIc6X%2BPwfGiNP3rWHOut3TWkwt%2B0bCi%2FETYztG%2Fk5VMoQ4m7eca7VdpppZcz1MBEsL9B7PtF9PpNRqLoLytpNhb%2BLFkrvdsbtYEYWdM8dYs9AQ%3D%3D

The most recent jxl art on https://jpegxl.info/art/ is from 2022, from the Inercia demoparty (see https://discord.com/channels/794206087879852103/824000991891554375/1037784316337463357) . We could add some more recent stuff. Feel free to nominate jxl art created since then, or to make new jxl art right now, to add to the gallery!

this reminds me that I still need to look at https://github.com/veluca93/jxl-art/pull/3 -- did anybody check if https://www.januschka.com/jxl-art/ is OK?

https://www.januschka.com/jxl-art/?zcode=eJxtVE1zmzAQvfMr9pyUiSQMtnvoTJJJm0OGdpLOcFZsBTQBRECO439frT5AcXNCaJ_evn270o3UezHoBihJfo9S9JprqXpYJ5Xcm21GVpvkXsi60QbCVsnj7V8okut2aHjyc-Sd-KMmSIuCQUoJSa4uYDeqYQLdCJC91DCq4wT8yE_fgPd7GPioQb3Y-CQ4aAW10MCBfc-AT4PYmSOoAS6ukqRU-oFPGgztUcBRti2odzG2_AST6oRuZF-DkavV4EjlZM_JF9jBD2BJCk_CKs-QQw387SDguQbDIEYLNdu3zag6jn_-HAkLiosamainSnMb_DB7K7uq0qoyPykCqvAhHp0REjH4c8QhI3UGFYJF7sKXkIWMWwwbmQ-HWeQJCa3bT68n62unDqZ3sp884jwlKv11b5ZIe_1el5clJskxUFZpiSXkhMzBOyMwN38WRQHdEx9aRJmCe7bL5-ktX0EsYYm1BkdSVy0qF6EaVEgJzb2DJFJLY7UsVscSy_JoilddL6b_C8e2ODft_Io9cgfPmc_i6v4EWnkM2uGStKpWfmSWYTNVm4x4H1z3XGI7Zn17MrbYGUewnflluph1E4OW14ysx3K8VVGH82JuYEGpa0Y0KWQbgEW2CcsNDZO6IqFY24S75ROw5NN4uC4wNocZW88EfmtNviA_0-gTVVGiiGg5Ho5tGYvT4FY2s-dk0fY1C744qlVjeFSsp_FVXi6Ztf0wvh2UnARi5gpMoFfuNfG9eFZaq25uXUD-A02MUDI this one seems to have an issue

while https://jxl-art.lucaversari.it/?zcode=bVRNc5swEL3zK_aclIkkDLZ76EySSZtDhnaSznBWbAU0AURAjuN_X60-QHFzQmif3r59u9KN1Hsx6AYoSX6PUvSaa6l6WCeV3JttRlab5F7IutEGwlbJ4-1fKJLrdmh48nPknfijJkiLgkFKCUmuLmA3qmEC3QiQvdQwquME_MhP34D3exj4qEG92PgkOGgFtdDAgX3PgE-D2JkjqAEurpKkVPqBTxoM7VHAUbYtqHcxtvwEk-qEbmRfg5Gr1eBI5WTPyRfYwQ9gSQpPwirPkEMN_O0g4LkGwyBGCzXbt82oOo5__hwJC4qLGpmop0pzG_wweyu7qtKqMj8pAqrwIR6dERIx-HPEISN1BhWCRe7Cl5CFjFsMG5kPh1nkCQmt20-vJ-trpw6md7KfPOI8JSr9dW-WSHv9XpeXJSbJMVBWaYkl5ITMwTsjMDd_FkUB3RMfWkSZgnu2y-fpLV9BLGGJtQZHUlctKhehGlRICc29gyRSS2O1LFbHEsvyaIpXXS-m_wvHtjg37fyKPXIHz5nP4ur-BFp5DNrhkrSqVn5klmEzVZuMeB9c91xiO2Z9ezK22BlHsJ35ZbqYdRODlteMrMdyvFVRh_NibmBBqWtGNClkG4BFtgnLDQ2TuiKhWNuEu-UTsOTTeLguMDaHGVvPBH5rTb4gP9PoE1VRoohoOR6ObRmL0-BWNrPnZNH2NQu-OKpVY3hUrKfxVV4umbX9ML4dlJwEYuYKTKBX7jXxvXhWWqtubl1A_gM does work

interesting, it works on initial load but not on "Run |>" for me

<@623776984987729940> 😄

i ll look

something stopped working with jxl_from_tree, also I noticed that Upsampling now comes at a substantial cost in filesize while in the past it was free. Maybe streaming encoding?

We spent a few hours this morning trying to understand some weird behaviour. Eventually we traced it back to a fix we did for... Something... But we can't remember what was broken or how the fix worked. Sapien made a PR to remove the old code https://github.com/libjxl/libjxl/pull/4637, but personally I still don't think it's quite right, it seems to work though so eh. Might need help double checking the pipeline in <#804324493420920833>

what I'm concerned about is that `Upsample` doesn't work with jxl_from_tree as it did a few years ago — this is already an issue in jxl-art.surma so it's not a recent problem

this one for example is now 34 bytes if you make it Upsample 1, but as it is there, it is 87 bytes

Oh right, yeah I've noticed that pretty often, it would randomly break between files and I never knew why. I just assumed Surma was missing bugfixes from main

I think in the past we would produce a single-group image, but now this is getting encoded as a 16-group image

same problem on Luca's version: https://jxl-art.lucaversari.it/?zcode=Tcy9CsJAEATgfp9iejnwNhymEtTCVCn84ergrcmCyqGLz-8qFumGb4bZqhWpNqGlc30N93oTj4fdCZEoa_EmRaZOdJzsF0mvuGDtfcBRDMsv5EUf-uwaIrcEzIlTcgECNu_RFYGZ_7J_DkXlYf42G3Czog8

it also takes very long to produce the jxl file when doing Upsample 8

IIRC it's reproducable with the CLI too, so testing is a bit faster

it's somehow not correctly computing the number of groups; in this case the frame is 512x512 which fits into a single group at our group_dim_shift. But it's treating it as a 4096x4096 frame, which is the upsampled dimension

I'm surprised it still decodes fine if its putting so much extra in

It should affect normal images with`--already_downsampled --resampling 8` too

Well it's definitely doing something bad, my phone just crashed trying to encode it on the page 😅

so how hard would it be to make a jxl-art-only encoder? (in Rust maybe :P)

intuitively it shouldn't need *too* much code...

xsize and ysize get divided by the resampling <https://github.com/libjxl/libjxl/blob/b3510d19c616db3de03e8e15af92f16a1f0655c4/lib/jxl/encode.cc#L2097> But frame size is multiplied by resampling <https://github.com/libjxl/libjxl/blob/b3510d19c616db3de03e8e15af92f16a1f0655c4/lib/jxl/enc_frame.cc#L439> Maybe they're running in the wrong order or something? There isn't much to the already_downsampled code

Basically only need a header writer and an MA tree encoder, though that does require implementing most of the entropy encode I guess

Not *really*, right? Most of the optimizations we don't actually need (it's always 5 contexts and relatively small amounts of data, always ans, no lz needed, ...)

Right. Not sure if it's always ans, iirc for small jxl art, prefix is more compact

Ah I think I see what's going on. We end up encoding a frame that is 8x too large in both dimensions, and cropping it to its top left corner so it still looks the same as before... But it's actually a huge frame

That 512x512 image with upscale 8 becomes a 4096x4096 image, but we then encode a 32768x32768 frame (of which we only see a small corner)

<:monkaMega:809252622900789269>

No wonder my phone was 'unhappy'

Will make a fix, but first have to put kids to bed

I added this: https://jpegxl.info/art/big_gallery.html

it loads smoothly on my chrome, except for "Lovebirds" which has huge splines, maybe a good test image to try to speed up spline rendering?

crazy how flags are heavier than other beautiful arts, like Rift which is only 36B

I wonder if there's anything we can apply or learn from the years of optimizations browsers have done to speed up SVG rendering

I don't think that's even simdfied at the moment

definitely there's plenty of work still tbd for those 😄

> Color Leakage in the Synthetic Beehive that one doesn't load for me (and also the source seems broken)

fixed it, there was a copy/paste error

also if there are nice images in the history of this channel that I missed, just point to them and I'll add them

easy speedup

10x <:Stonks:806137886726553651>

kinda easy when you go from scalar to avx512

Okay, it is funny and ironic that [this](https://discord.com/channels/794206087879852103/824000991891554375/967519325818880001) was curated. It was actually produced the day of the jxl_from_tree release and the creation of this channel in the process of learning the tool.

The more artsy-looking result was [this](https://jxl-art.lucaversari.it/?zcode=y0xTqFCwUzA0MOBSAILMNIVKJC5UKBkohBCACoK0GZkZoQgjGYFNCsk4Q6ySSEabGJngVIJkDSFlSCZaEqEUBHQVHMvSHXNyFLTRPE3AKcSaT5YdEE3BqSUKRqamXMSpxG8yITXQUDPHEY8k-wQaSoTMIzl08IcKLl9iE4f62MwAm3I8LoL6DJs-onyD6QNk10HZAA). This particular tree was also more technically interesting for me because the rearrangement to reduce AvgAll nodes yielded a smaller JXL than the straightforward modification by several bytes. Still less than art, but at least more beautiful.

**SB112** _“Small and not accurate colors russia”_ 2026 image/jxl 27 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOQKz0wB0pZcHqmZ6RklCmZcXJlpCpUKdkApBQUo0xjIBHOSgRwDMEdBQVchOLUEjWeIrNAQixSyNoQ4FwA%3D

well thats not how it looks in the website

image attachment fail thats not how the image looks

Interesting how the preview fails, maybe because it is so small?

**\_wb\_** _“is this better?”_ 2026 image/jxl 31 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOQKz0wB0pYGBlweqZnpGSUKZkAmV2aaQqWCnYKhpSWXggKUYwzmgLnJQK4BmKOgoKsQnFqCxjNEVmiIRQpZG0KcCwA%3D

**dogelition** _“test”_ 2026 image/jxl 27 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMOQKz0wB0pZcHqmZ6RklCmZcXJlpCpUKdkApBQUo0xjIBHOSgRwDMEdBQVchOLUEjWeIrNAQixSyNoQ4FwA%3D)

somehow that's the result of the browser encoding the canvas pixels as jpeg

that sounds very cursed

ah, that seems like the antifingerprinting thing firefox sometimes does

Is there any other tool to make jxl art except for the web app?

alternative site: https://www.januschka.com/jxl-art/ or just the `jxl_from_tree` binary from libjxl

https://qon.github.io/jxl-art/ is still the most featureful editor

It would be so nice to have such encoding possibilities in a vector graphics program as an export option.

What specifically?

The whole mathematical equasion thingy that this encoder is known from here. Most if not all of the art presented here is not really raster in it's nature, and being able to extract vector graphics into a more supported typical output for convinience sake would yield much more savings than having to manually re–encode from a \*.png extract.

I don't understand how jxl tools would preserve vector representations, or make translation more convenient with some tight coupling, except in the seemingly narrow case where splines could preserve some accuracy. SVG is way more general with real vector support for delivery.

I do still think an editor with WYSIWYG JXL spline painting would be cool.

Semantics for writing MA trees to preserve some information seems impractical in general, but technically plausible in specific situations.