JPEG XL

so one thing you could do is just ignore sections that are corrupt, and render something like a progressive preview from the ones that are not corrupt

as long as the DC is intact, that basically gives you a picture that is blurry where corruption happened and sharp in the rest of the image

That'd be cool

I don't know exactly how the predictor works, but I imagine you could do something for modular mode images where if you're missing data you just assume the predictor is right all the time? Probably wouldn't look good at all on large missing patches, but might work well if you're missing a byte or two?

you could also ignore the corruption completely and show whatever the corrupt section decoded to, which should lead to basically 256x256 regions where the top is OK and the bottom is complete garbage in the high frequencies but somewhat recognizable if you squint

You do wanna be a bit careful with the header though https://github.com/libjxl/libjxl/issues/3793

Reminds me of when you talked about error resilience in libjxl, skipping corrupted LF/HF groups and using the rest to get at least color or texture in that area

https://github.com/libjxl/libjxl/issues/3712

I used this briefly on a few JXL files a long time ago, can't remember the results though https://github.com/Akascape/Pure-Glitch

Thanks, and I see <@386612331288723469> found it too haha

Yep!

heya! been a while

Yup

I used my fork's gh-pages to share a piece before <@179701849576833024> If you want to try https://discord.com/channels/794206087879852103/824000991891554375/1216826286266253503

I really should add dynamic horizontal/vertical split layout based on screen aspect ratio :o

Great logo design from Jonny

it's very different, I am not sure I have the bandwidth to figure out if I should merge it or not xD

Well, if it wasn't different then there wouldn't be much point to it? It's an improvement :)

yeah you're probably right 😛 I'll try to find the time to review the changes - but to begin with, can you include ace etc as submodules instead?

I tried before, but I couldn't get the build system to find and include the necessary config files then. The color palette, keybinds and language syntax definitions then aren't included and the editor becomes ugly, useless and not really an improvement.

And having access to ejs is a massive improvement, but without syntax highlighting and a reasonable editor that feature won't really be used much except as a way to share code for generating jxl.

I'm sure there's a way to make that work... I have some memory of having succeeded at it for another project, but then again I was not using npm

And without the editor theme the whole color theme across the page isn't coherent and nice looking.

It's not just npm, it's the bundler used which is the tricky part

It renames and moves all the files.

did I already say I dislike most JS environments?

anyway I am not so sure I'd like to include a copy of ace in the jxl-art repo... when I have some time I'll try and see if I can make submodules work

I like JS when I can just click the file and have it open in my browser to test it locally. No build step or complications. Now for security reasons some bigger projects need a local server program running to connect to localhost, which is doable since there's no build or compile nonsense. But it is a step away from just being a trivial open file on any computer with no extra installs which I can send to anyone and have it work under any OS, no install, no tech knowledge etc.

The bundler makes changes extremely complicated, slow and inefficient. A trivial npm dependency include becomes an unsolvable nightmare like in this case. Any change takes several seconds to complete when it is just instant without the bundler. And a single bit changed means all bundled files are discarded, all files are parsed again and the entire project is duplicated. I just want to update a color code? 20 MB of just the code is pointlessly parsed and written to disk every time I Ctrl+S and then I have to wait for it all to complete to see the change.

Since I didn't complete my jxl art before I guess I'll share the WIP code now, as a demo of why I like having ejs right there on the jxl art page:

Line 346: `let flag = (x, y)=>(200 <= x && x < 300 || 200 <= y && y < 300 ? 15 : 36)` defines the shape and colors if you want a clue to what all that other code is for.

And look at the second code tab "jxl_1" to see the output jxl language

**\_wb\_** _“Directions”_ 2024 image/jxl 27 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=43LKLElJLSjJUDA04gotKE7MLchJVTDkcknNKUkMSMxJLSlJ5eLiykxT8AvX9VOwU9A14tJVcCxL99P2C1dAsF1BElwA)

**\_wb\_** _“Melting”_ 2024 image/jxl 27 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=43LKLElJLSjJUDA04nJJzSlJDEjMSS0pSeUKLShOzC3ISVUw5OLKTFMId%2FdQsFMw4NJVcCxL99P2C1cwgrNdFXSNuAA%3D)

**\_wb\_** _“Untitled curly stuff”_ 2024 image/jxl 36 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=HcexCoAgEADQ%2Fb7i9nDILJoaoqhJWsJZ8MoDC6n7f5K291biMwrqtgPHQeKvkSVQLulhoiR%2B84lECPb8%2BisnQgPAB7rKKutwQNVoULg8PjDdgqouszNqbeAD)

Does JXL Art support patches? To copy rectangles of the frame to create repeating patterns?

the `jxl_from_tree` tool doesn't support patches yet

Thanks, I was just looking for a simple example, don't really need it in jxl art

Has anyone tried to make spline based text font yet?

that'd be fun

I posted an idea for a DjVu to JXL converter for scanned documents, but vector based fonts would be cool too

I guess something like a cursive or elvish font?

One image format to rule them, and in the pixels bind them!

a patch frame with a spline-based font would be nice — adding that to jxl_from_tree can be done in principle, though perhaps at some point we should consider just creating a new jxl encoder from scratch that just does "vectory" stuff using splines, patches, and simple modular image data to do filled polygons, or something. Basically a drawing app with primitives that are based directly on the coding tools available in jxl.

Well just some crazy ideas 🙂

That is exactly something I want to create, a jxl-art focused encoder. I'm behind in school after being sick for two weeks though, so I don't know when I will possibly be able to justify the time expense 😅

From what I understand you can also do simple animations with transformations of previous frames, like maybe candlelight flickering

The most annoying part early on will probably be porting libjxl's entropy encoding code, since I think most things you might want to put in a jxl-art file are entropy coded?

yeah, you could have a background frame and put smaller animations on top of it

Can jxl also do things like drop shadows?

This could be cool for small animated logos, or something like my profile picture

Any kind of image can be encoded into a JXL file, but I don't think JXL has any method of generating drop shadows..

Maybe something like a snow animation over your profile pic... particle effects?

that's just patches

Patches everywhere!

Has anybody tried to make like procedurally generated textures? Something like paper texture?

I'm thinking something like this without the text: https://archive.org/details/aliceinwonderlan0000unse_f1r9/page/6/mode/2up

Basically something like the synthetic film grain for av1

Ahh, so you made the reddit post I replied to. Was just about to correct a few things in your comment

Yes, please feel free to correct me 🙂

**\_wb\_** _“something like this, Dejay?”_ 2024 image/jxl 44 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=88vPLE5VMNAzAWJjIDYyBRFAbKhgAIJcTpklKakFJRkKhkZcEZFOXFxcmWkKyQp2QCkow5BLVyE4tURB19TAAMoEsYDMcAUjAA%3D%3D)

Noice

Can I find any more documentation for example the noise parameters in the source code?

they are amplitudes (higher value is more noise) and go from dark to bright

stumbled upon this and am curious-not sure if this is the right channel. someone implemented rule 110 in JXL. that means JPEG XL is boundedly turing complete. does anyone know of existing work that has gone further? i'm really fascinated

in the future we'll be able to run linux in a jpeg

It's extremely limited, only within a max group size of 1024x1024 px.

Relevant discussion: https://discord.com/channels/794206087879852103/803645746661425173/1287083527464292503

It's hard limited by the jpeg xl format itself, so anything further is just a pipe dream

We definitely designed jxl to be NOT Turing complete. An image that can make a decoder go in an infinite loop is a security problem. Some formats do allow that, like PostScript and full SVG, and that basically implies you have to use a sandboxed, time/memory limited environment to render such formats...

i read about this. definitely good design decision. i just want to push it as far as it can possibly go bcs its fun

I guess the farthest you can go in terms of chain compute, is using a 4099-channel image with 1024x1024 groups, where each channel can in principle access all previous channels.

Maybe some basic operations between layers too? Like inputs and outputs based on pixel values. But this would need a complete understanding of the format to pull off

You can’t loop though

``` _____ _____ ____ ___ ___ ___ ___ \ | | __ \ / __/ / _/__ \_ \/ _/ | | /\_) | | ___// __)_( (__) ) _) (_ | |_/\ \____/ |_\ (_____/ \____/ (__/\__) |____/ ```

hm, that looked nicer in the monospace font I used for editing

Rip

Here's an idea: font atlas reference frame, then patches to do "ASCII art"

``` \ \/ / (_/ /\ \_) ```

yeah it would be nice if you could just pass some image to jxl_from_tree to be used as reference frame, and then have some syntax to define patches and to blit them — possibly with some syntactic sugar to do grids in a compact way where you assign characters to each patch and then use lines of ascii text to fill the grid

How about being able to provide some kind of "atlas map" file? So you could get convenient predefined patches to use and reuse in many jxl tree files without having to copy paste.

Are patch coordinates entropy coded?

These advanced features feel more like something that should be added in that jxl art program that everyone agrees should exist

Yea

That one is nice

``` _____ ______ `####= _####* )# *####_ #####`)# ###,*####=##### ### #### `#######* #### #### _#######_ ####, _____=####`_####^##### #####_____ ########* #####* #####_*######## ******` _##### *####= ``***** ***** `***** ####_ =###* ,_*###_ _####`_ ##_`####_####_## ###,`######* ### _###`_######= ###_ ########`#####*####`######## ######*_####` ####_`*##### #### *###= ```

``` _=## ##* ~+~ === ## ####[ `##_ ### ]#} *## *#### ## ## ####_ ## ##, ##/`##= ##### ]## ##* `##- )## _### `` ```

I recognize those

Has anyone tried to recreate this? I wonder how small it could get

The SVG is 4.1 kB, so quite a lot of room to work with. Getting something that looks pretty close and replacing the SVG on the website with the JXL would be such a power move <:KekDog:805390049033191445>

JXL is not a vector format though, so it wouldn't quite look as crisp...

That's true. This was more one of those "whether you could" ideas rather than a "whether you should" idea

If you didn't want curves then it would be much simpler https://discord.com/channels/794206087879852103/824000991891554375/1216826286266253503

How crisp can you get curves? With boosing line color to something like RGB(1000,1000,1000) they get thicker but very crisp. So for white or black or primary colors this should work

the problem is that since jxl is a raster format, eventually it will become pixelated

You'll usually get browser upscaling or downscaling if you replace an SVG by a rasterized version of it.

**Anonymous** _“Unnamed piece”_ 2024 image/jxl 77 bytes https://jxl-art.surma.technology/?zcode=bVLBTsMwDL3nK57EcYqUtM3ogSGxgbZTDwyp57FmXbSqQiUg%2BHuctOnSlZv98pznZ7s0lT1DiiRjO23qs%2B3jtbGV%2FqCXnL1u3rBkzJzwi0dIJRhAyZESFwIcxRAR%2FEOwEn3qgXK7c9AAOPbTd10sihILJGIGv1CUROXuv%2Bz%2Bhle6ci6v6KhzhSZKUv2DOyn%2FEKyly%2BDiGH01pDIWm7rsP91rC57NsVzMK%2BWERV6gZnWJuBlDLOhmTvNTE4AjVcFBSQVchQLS8MvVFYEsVkmpY9186rDU1Wrcat8EcIfnQ3dB3WndRjQZ0WTueevOi3QzbhJxM6ISd9%2F4a3tvvjSsaa2%2FMGczFyLs5GEcAse2O1RGt5Zsq7hDOsg%2F

**juliobbv** _“freshly baked tray of neoncookieli”_ 2024 image/jxl 45 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=C0pNNjI0MFAICOQKLixNTa1K5eLKTFNIVrBTMOBSUIAyDYFMMKcSKg4Cugp%2BCrpGCF5waomCiYGlKUxtBYracAVDVKW6QLVmXBBjDLkA)

argh why is it so bright

it's missing `Bitdepth 12` I think

I think it's because it's a PQ HDR image

and still it has peak intensity of 10000 nits, so...

these neon cookies are powerful 😛

squeeze does some weird things

**\_wb\_** _“More neon cookies”_ 2024 image/jxl 32 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=C0pNNjI0MFAICOQKLixNTa1K5QpyDlGw4NJVCE4tUQBKcQEA)

**CrushedAsian255** _“neon fractal”_ 2024 image/jxl 36 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=C0pNNjI0MFAICOQKLixNTa1K5QpyDlEw4spMU%2FBTsFMAynHpKgSnliiAaD8FbZAAAA%3D%3D)

**\_wb\_** _“Sierpinski's shadow”_ 2024 image/jxl 35 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=C0pNNjI0MFAICOQKLixNTa1K5QpyDlGw5HLKLElJLSjJUDDm4spMUwhXsFMw4NJVCE4tUdA1AjLCFQy5AA%3D%3D)

Please show me what that looks like

And define "crisp curves"

Something like this <https://jxl-art.surma.technology/?zcode=zZAxCsMwFEP3fwpdICB_27ieQ6FzXMgFbGJDCRl8f1qc3CBLpeVND6G15V7hjcqrtK32gcv8BkUkHZ-2F8EvhiRu9Q81iklvSyK8O0eZB6yPJ8cAtQOtIcI1OxBW_WCnhCPluefrZpmQSge_>, to have curves with sharp and not blurry edges

I was wondering which image formats/codecs allow to have something like what jxl_from_tree create ?

JPEG XL

Maybe FLIF (which is part of what jpeg xl was based on)

oh, I thought it was a more common use case aka only predictor tree without correction

Not sure how common predictor trees are in any formats other than JXL and some general data compressors

Most formats just use either block based transforms or static predictors

All I can think of is lossless WebP’s predictor image but that’s kinda granular and not the same thing really

It’s a sub image that defines the predictors used

Not really a prediction “tree” it’s more of a prediction “grid”

I’m thinking something similar to JXL modular could be made with audio A mix of LPC and ADPCM maybe

<@532010383041363969> could this work?

Or am I reinventing Opus

Can you use jxl art to generate speech or thought bubbles for comic / manga? Like a blurry blob generated with a wavelet and then use a filter to only use one outer band of the blob where the falloff of the color is inside a narrow band?

Again, just asking out of curiosity

That might be better done with splines

Hmm. I was thinking of creating a filled polygon to cover over the background painting, but I guess it can be solved by just encoding the background to fit. And also probably not smart to create "overdraw" by painting over using some sort of fill.

Here's a blogpost from 2017 which does something kind of similar to jxl art but in FLIF: https://cloudinary.com/blog/compressing_cellular_automata

Can this sort of thing be translated into jxl?

Yes

Lossless FLIF transcoding <:Hypers:808826266060193874>

JXL already does a lot of what FLIF does (and more!). For example the Rule 22 image in the article is 3.4 KB for the PNG, 83 bytes for FLIF, and I got 82 bytes for Jpeg XL.

Just by running `cjxl -d 0` on it?

well, it was e11

e7 was 188 bytes

🤨

Ah wait, that was the example of the poor JPEG result xD

I was about to say 😂

I'm still waiting for ||a rule 34 image|| [⠀](https://cdn.discordapp.com/emojis/1059276598660059136.webp?size=48&quality=lossless&name=av1_trollhq)

Wasn't there some formula some mathematical pervert came up in antiquity already?

Behold... rule 34

**CrushedAsian255** _“Rule 34”_ 2024 image/jxl 27 bytes https://jxl-art.surma.technology/?zcode=C89MKclQMDI14%2FJIzUzPKAEznTJLUlILgOKGXFyZaQqVCnYKBlwKCroKfq5gBlCsAihmaGQB5CBxLcFckMLg1BKgZmSeAReyDAA%3D

Google "Rule 34" to find out more

Cellular automaton porn?

I feel like that would be finding the most complex structure from the least amount of bytes

So JXL art

kinky

Splines would obviously be cheating

Actually it would be more efficient to just use the predictors. This: https://discord.com/channels/794206087879852103/824000991891554375/1302506243692433408 was done only using the lossless part of jxl.

You say that as if there's any VarDCT based art :P

think that would be way harder

you could probably intergrate VarDCT patches into jxl art though

VarDCT art could be fun. You could make singleton histograms for some coefficients that give them a nonzero value, and use regular jxl art for the modular parts like the LF and the block selection.

With my blue noise addiction lately I started wondering if an approximation is possible in an MA tree, since e11 only manages 1 KB less than raw image data

Noise is inherently almost uncompressible

How does VarDCT use its distributions ?

If you could perfectly detect, classify, separate and remove and then generate noise, it would be perfectly compressible in lossy.

**\_wb\_** _“Pixelation, Interpolation”_ 2024 image/jxl 33 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=43LKLElJLSjJULDgCi4sTU2tSuVyK0rMTQ3IL1bQNTU0AhNcXJlpCskKdgqGBnCWJZeuQnBqiYIBkA4HqgJThgYA)

where's this from?

a jxl overview paper I'm working on — btw I'll want you to be a co-author 🙂

Can I buy it when it comes out?

interesting illustrations, they're very informative

what's the difference between the West and WestWest predictors?

the resulting images look the same to me

WestWest uses the pixel 2 to the left

oh, I can see the difference when I zoom in

Zoom in, there’s a slight zig zag

yeah

Maybe the images should be slightly lower resolution, to see the difference between West and WestWest easier

maybe a zoomed-in view of WestWest of the zigzag region, and place it where the blank space is down below would help

that should do it too

if the last column before the predictor area is different from the second-to-last, it would be way more noticeable, fwiw 😄

It will be freely available

**\_wb\_** _“Improved predictor demo image”_ 2024 image/jxl 60 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=fY89a8MwEIZ3%2FYp3DoRIBoeQoUO7ZPKQBjQL61If2JKRr6T995HifC3JontA791z98niaZQOG2XZ51rVa7Uj%2FunkgvuvA9ZK8RH%2F%2BECtC%2F3NtFpgTOS5lZggEZ6GGCZJTmiLxUotYS20Krkj9z0cpCNwYGHXw2iNFE8TXPBoY%2F87hAknzhtMcSCMToRSKHOysc1Gkwc2%2Bb2uYuZdClb6gjajzqFvknut6rq02bnvlrBYmkdCq2dF%2BbsdaR73Xh3NC8cs0W8kZw%3D%3D)

**\_wb\_** _“Further improved predictor demo image”_ 2024 image/jxl 85 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=fZC9bsMgFEZ3nuKbI0XBVhxVHTo0SycPSSVmZJP6SjZY%2BFahb1%2Bw45LFXbgHuD8H3olbM3KHF6GojbE8SfFh6KvjGS%2FnT5yEoBt%2B8IZjlSgsdNhh9Kalhp0HO7RmcHZir9m8YncQeygFKVLejfoeGtwZkCUm3aOQEt7dJ2jbonH992An3CkaTG4wGDWz8Tb1iRObOLGIDeu4PlSKSq5YyoxlxuMTzmV1RBm7XA3%2FxbKqkui8rzFXqM20Wi3z1wyFfZEzpHhWTXfrZz1cQ3YN2TVk15BdtyXWE7XYbj1q0ZX%2F6P4C)

Now the difference between WW and W is much clearer. Above one is WW

This is W:

Oh this is awesome thanks. So if you'd want something like South you'd need to rotate copy the frame?

I suppose that's a way to do it

Yes works way better

What if you encoded using Weighted on the complete image, and then zeroed the residuals in the result? Assuming that's not what you already did

I just used jxl art to produce these, like this: https://jxl-art.lucaversari.it/?zcode=fZAxb8MgEIV3fsWbI0XBVhxVHTo0SycPSSVmZEiNZIOFrwr99wUclyzuwj3g3bsP3g0pPVGPFyaMirU-cfahzVdPWV7OnzgxZm74wRuOTVJhUYcdJq-V6ch5kIPSo7MzeUn6FbsD20PkHK3AWXLfzDBAgnoNYw0ZOaDiHN7dZ0ir0Lnhe7Qz7iZyzG7UmCSR9jalxbldnFvF2DauD6Cq4auseZF1kccnmdvaKHlMuWr6q3XTJNy8b5E7xKatFcv81SGwr4qDs2fUdLd-2YM1FNZQWENhDYV1G2I9EQvt1qMWXP4P7i8

yeah, this is way better now

Ah yeah, I was just thinking that since weighted uses the prediction error, only using JXL art might not be representative of what it actually does on a real image

cjxl could take advantage of zero residuals in `-d 0 --keep_invisible=0`

True, but it's a bit hard to illustrate that anyway with a large rectangle of zero residuals, since when doing real lossless, you would correct it constantly

Right

And isn't that what it does already?

Not really

It in fact just zeroes out invisible pixels so the color becomes black.

Ahh right

**\_wb\_** _“The Organ”_ 2024 image/jxl 24 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=Hca9CoMwFAbQ%2FT7FN1uCuaFaunQQajexhZJ2TPXaBBSDyfvTn%2BHAaUIeJWYP1lQWdJPBsNbor1SUdHGvdQvJ07lvYejxbH5aN%2BR1S9jrY42KDUxV0z0mt8RZwERhgt11qrM4QROg8K3i%2F6yEt88ygs3hAw%3D%3D)

question: afaik gaussian kernels have to be odd-sized, so when downscaling from e.g. 3,000px -> 1,000px vs 2,000px -> 1,000px, do you use a 3x3 gaussian blur for both but just with different sigmas?

Depends on the speed tradeoffs needed but I would probably use a 5x5 or even 7x7 kernel most of the time if it's just for downscaling a single still image. 3x3 is a bit small even for a small sigma like 0.25

Nice, this one kind of reminds me of those electron microscope pictures of CPU dies

These too, actually

**\_wb\_** _“Merry jXl-mas!”_ 2024 image/jxl 276 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=3VXLitVAEN3XV9QPzFCP7q7qjQtBcKXgIK6Hua0TGO9cnbjx6z25yfUB7iIMSAh16pnuPqfJy2k%2BjNN8z0nvxp2pCL39Oo3jfDtPj0dWevM4PQ2Wa8dr27vgsmFloQ%2FTARO0m9DrMX26n1klhd6fnm4%2Fnx4GptDN6WE6DtLryrLn%2BQcTys5%2B4ytsve7bRens1shM2Qts76xeyYuwi5N3ge9UarDXQk07WzRYY%2FNG1Qtbwjc%2F5wPrsRoUAuvwG2zplOf6JW%2F4nlMk5lelzIb6Qhmos6BeMK8odazDHPne2LVSb1hnSQKf%2FVyo0hORQqqJkcVIEUbqHOlcOoC0XIEvY7CNV8fDJoBfStjNwvP2L3dgpwaqcaaSZnCWSgbOVGwJOEA1cjfuKtQiuUaCXVhtYLFxTbBXHH796TeopdiqgqoBlVQO5CvYD2mYJ4grhSt3M4paGMxT1s4BlSys56KCs%2B8gUoM7ZKmqawVsohU60FY4PVayE5JRrQtAl4muNZ6YD9UB1LXGoLO0voDAQFskUjiw6b9IxJ75ou%2Fv930CabitVjYQXX47pP%2FkiJJt%2FxF1uQCTP3X05dsY3wdNH%2FmOX7BdQNIV34yZr2wDVi8puQDdUrLZuIDlF0k%2FAA%3D%3D)

<@245794734788837387>

**Claude with help from ebfeebfe** _“Spectrum Falls”_ 2025 image/jxl 36 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=VY0xC8IwFIT3%2FIrbJZDWBjs5iKBTEBwyB%2Fq0gSJS3lChP97XxKrZ7t7d%2B%2B5M8d4zbFUrHzvukzpE7ugpplVHGjhcwkDMpFS8YcIeRgEiXyIrsxhAw0O3q74So7Y219xSs2t0GkMX6cHQ9r9tEvxHFOMLvMOmKfApSbPb%2FDx77fwsT80HMBXDeeUL2xmVb9J4Aw%3D%3D)

is AvgAll the one I added with strange weights or is there still one more?

Yes that's yours

I never analyzed it like this -- I just tried out things which worked best for delta palette prediction from butteraugli/human viewing/size perspective

and only for compressing photographs with the delta palette, with dithering

dithering makes averaging slightly more attractive than 2nd order prediction

I suspect AvgAll works well not just for delta palette but also for a non-palette near-lossless technique where you use quantized prediction residuals like what <@826537092669767691> did for PNG at some point using the avg(W,N) predictor.

Was Delta palette specifically <@532010383041363969> ‘s invention?

It was an experiment in lossless webp already but was too late to make it into the spec iirc

the idea is not *too* hard to come up with, I believe I ended up adding something similar to the original DC compression setup in PIK before we replaced it all with Modular

So just making sure I’m fully understanding, delta palette is a palette of residuals from the global predictor, correct?

yep

**CrushedAsian255** _“something”_ 2025 image/jxl 28 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=80jNTM8oUTA1NOIKz0wpyQCznDJLUlILgBxLLgWFzDSFcAU7BUMjEEdXIRysITVFQdcIzA9OzUlNLlEwtjAAAA%3D%3D)

**\_wb\_** _“Blue curtains”_ 2025 image/jxl 28 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=80jNTM8oUTA0MDLhCs9MKcmAMIOcQxQMjbmcMktSUguAgpZcXJlpCuHafrp%2B4Qp2CgZcCgq6Co5l6X7afq4KusYwLlCBgrGxMRcA)

I was referred back here by <@226977230121598977> for this: Any insight how to best recreate this image?

I referred you not here

You may want to look back at this https://discord.com/channels/794206087879852103/824000991891554375/1284112799999721564

It's possible to arrange the colors, but far more work

Hmm. The order isn't necessarily so important, but having all 2²⁴ Truecolors is, & the square dimensions _would_ be nice. How simplest to do that?

Scrolling up a bit from the last link, there's a tree here https://discord.com/channels/794206087879852103/824000991891554375/1284098812121710644

**\_wb\_** _“Interference”_ 2025 image/jxl 56 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=jZCxDgIhEET7%2FYrpDcmCF7Wy0NhSnCZ8AGK8zoJC%2F%2F5AuAP17mI381hmJ9seL1BMh85f3cPfIZlaZ5VkBlF3wwt7MAFB2iBlkICAhkgycJ1HBmtEJPl9gEKfqrEUcnb%2Bi%2BjKz%2F3SCyll%2FVROVekdZLBabDT787d4JFueOJTBeKdnwOtdU6pGsGk%2B9tk%2FjhRJ6ZP8WDBbRT0%3D)

Where did the bot get that from?

click source tree, on that site you can click publish to post it here

No, I mean: Is the the author the <@794205442175402004> here? Amazing!

This channel contains the entire history of jxl art 🙂

A while ago I found an animated 'sunset' JXL art using multiply blend frames. Do we have any other examples of animated art?

There's an animation here: https://jpegxl.info/old/art/

I posted a few, but mostly spline stuff

We should have a yearly jxl art contest in this server

There used to be, but we should continue it

Strange... I was messing with the RGB art from a few months ago, but local jxl_from_tree outputs a black file around 70 bytes bigger than on https://jxl-art.lucaversari.it/

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1346280489404858388/Website.jxl?ex=67c79ce9&is=67c64b69&hm=3964f6a0e036e77e56de19f60158f4f2016fd2ccd29ebdd4247570da63490acf&

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1346280522577481799/Local.jxl?ex=67c79cf1&is=67c64b71&hm=47567488e332aa7a9e6e5987c21fdc529f204c6d8d95fc9b194ae5641b1b27ae&

Sounds like something broke then...

uh, sounds familiar

I once got similar blackout with jxl_from_tree, but can't find which one

must be related to the chunked encode

there: https://github.com/libjxl/libjxl/pull/4141

While you're at it, this was never merged too https://github.com/libjxl/libjxl/pull/3824

<@179701849576833024> when you have a moment, I don't suppose you could approve the above PRs?

Though I forgot the modular flag needs a rebase....

Once they are fixed, I can check them 🙂 but pls tag me on them

you are the reviewer for that last one

I’ve just merged

I mean resolved the merge conflict (merged main into that branch)

not merged that branch into main

uuups

Thanks guys, now we can make the smallest jxl officially haha

**\_wb\_** _“A new phone wallpaper”_ 2025 image/jxl 52 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=hVC7DsIwDNz9FfcDlpI%2BkFgYQAimDjyUuaKBRiooggzw9ySkFFpU4cV31p198maxg6C5cZW2rsaUlKl8zyaC1tqcagcpkoz29laebaMhicwRD8y8C%2FCwaGEkigNn%2BRrEERfLThKKsdWux1fXsjL64pD%2BsTX64D7Le1bOBxnEz66esVBIRiKNOIap2zgyj3%2B4e70U3ScCTcVbz1D4xhxvByjpCQ%3D%3D)

**\_wb\_** _“MicroRough Surface”_ 2025 image/jxl 63 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=jVHBCsIwDL33K3IfhXao9SSoiLcenJCzbFULQ0SK6N%2Bb2rWjusFuLy95L%2BHlsD1CqdjGusbc3RWkYMyeoYYVSAZA8EVQEATggMBlB3Xsv1OfCiw010jMUgTOj1bGkS4RNKaTJhLIPde59zTXu2w0GK6fF13QGvXD7x%2Bnxpqbm%2BpTmdbUNF2O%2BqiBI8Wgd7byGxD%2BGyPCYpraZzZyrpzFtP1rslw9MRe9zn9MZlU6KbQ%2B)

you guys heard of any jxl art with this kinda pattern?

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

also these which I downloaded a few years ago

https://discord.com/channels/794206087879852103/824000991891554375/844164924527476757 24 bytes

Found this one too, but Upsampling seems to be broken on the site https://jxl-art.lucaversari.it/?zcode=TY4xC8IwFIT39ytuL4FqW9FFUAedIlglczDPJlBrrM_FX28iIm733QfHrYM4juJR0WFzREkmuESLWUk7Dp0XNHVJp_iw19gz5rQfAw9iJdwGTKi9P5lfTKs-eksULjhjiYaAFE2hlTaJq8SAgoaqP_Fffqvst6N1eR3TX2VQZK_QsqR3bw

something changed at some point in time with how the website generates/interprets stuff, I remember I encountered this when me and <@207980494892040194> where trying to get a older art piece to render the same to edit it and we had to use a archive.org wayback machine version of the site to get the old output

I know RCT had it's values changed

Very mathematical looking...

**\_wb\_** _“Untitled”_ 2025 image/jxl 37 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=HcixCoMwFAXQ%2FX7F3UsGUxJ0ESwdOokgkjnoUwMpBHz0%2BxvcDgevpJsUPdniLVnjFLOoCkLaalrn8JF0nFrpsZQrfksWWgBpZ3iMZgzs6Z8gDYffUSvQNLa7Y5Ysq9LjDw%3D%3D)

**\_wb\_** _“Something something neon HDR”_ 2025 image/jxl 62 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QpKTTYyNDBQ8PBx5wotKE7MLchJVTDi4spMU6hUsFMwMjKCMU1NTbl0FRzL0v20%2FcIVdA3hHFcFEBsixsUFAA%3D%3D)

**\_wb\_** _“Relatively interesting for 21 bytes”_ 2025 image/jxl 21 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5XJPTMovyizO4HINcFMw4uLSVXAsSw%2FX9gtX0DXmAgA%3D)

**\_wb\_** _“Nuggets of default delta palette in HDR”_ 2025 image/jxl 39 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QpKTTYyNDBQCAjk4spMU%2FBTsFPQNTQ159JVcC9KTMlMzSsB8oG88NTM9IyS1BQFMwMuAA%3D%3D)

No other format can encode a migraine aura so efficiently.

that's the JPEG XL promise

**Anonymous** _“grid”_ 2025 image/jxl 39 bytes https://jxl-art.surma.technology/?zcode=dcxBCsJADIXh%2FZziv0AgHaF15UL3I2hh1qWOOCBVJPfHTEV37l5evgRgX%2B1SnnZjG3zi%2BKplscnqY2FYm9NhpA%2BhXpnZ0XnnMbeougIhZ6QthHMxurj5av3oJCn9PbiX2Rw25ibq748GIWXiGw%3D%3D

there seems to be a slight issue with this tree: ``` Bitdepth 8 RCT 0 Width 32 Height 32 if c > 1 - Set 0 if c > 0 if x > 0 - Set 0 - Set 255 - Set 0 ```

I'm only setting the first row, but the color also ends up in the second and third rows

is there a way to avoid the color bleeding?

how did you take the screenshot? the file itself doesn't have any color bleeding, that's just an artifact probably from upscaling

this is what i see when i zoom in on https://jxl-art.lucaversari.it (by just using the mouse wheel on the preview)

I think it might be a bug with mac's preview, since the PNG download looks fine when zoomed in

thanks

oh that's interesting, wonder why that happens 🤔

**Hammad** _“Dream”_ 2025 image/jxl 28 bytes https://jxl-art.surma.technology/?zcode=ZY89C8IwFEX3%2FIq7dAqBJP2ggwhVukZQIbPQ2GapIkHsvzepaQ10fHkn5953sK4zTzegJqeXNaO7OfsYIcj5eEVFiL1jwh6CcwIwNO9eUdWCymTUYMKPHv14NJ%2FRsNXG9oMzHaiILwosX8gMJccOsow779LB5dW%2F1AzFDPC%2FW67ui3EQcpPEkl465JL4s0gOaGm7gGphptUey1UhO9%2BeIpMCNf8C

it feels like it can be done in smaller fiel than 28B as e.g. this is 28B https://discord.com/channels/794206087879852103/824000991891554375/1332994576260141098

I'm curious what suggests it isn't minimal ```RCT 6 if y > 100 - AvgN+NE +2 - AvgN+NW -1```

NW -1 works to reduce complexity, but not bitstream size

**gpt o3 + ebfe** _“ouch”_ 2025 image/jxl 121 bytes https://jxl-art.surma.technology/?zcode=vZC9DsIwDIR3P4V3VMm22kAXBiYmFoY%2BAC00G0MGeHuc%2FiUB8SNR6HSnq85frrK1axGRSXLYNvbUusFsrKubs4YrALBHPOAaGQBVXlUSoJc7lVJ409kqsogZ7huHveu1FMWrX%2B9iM6SZugzz5ApH2ULBQonvDHUjOgX00vyBXT5ml%2BgGEwVM3zdz91TOpfQjXPyl5dtBvp2D84TZ0LP3pMxCXTRyPi4yR%2F80Cf%2BiXr8b

I know nothing from jxl_from_tree, I just thought that I saw much more complex patterns with 28B, so I thought it could be smaller

emergent complexity ;P

Very complex yes https://discord.com/channels/794206087879852103/824000991891554375/1302506243692433408

oh well in my previous message I linked to this 28B image: https://cdn.discordapp.com/attachments/824000991891554375/1332994576553873439/art.png

I was joking lol

This one is relatively interesting for 21 bytes https://discord.com/channels/794206087879852103/824000991891554375/1358526333931622613

I see what you did there <:PepeGlasses:878298516965982308>

https://discord.com/channels/794206087879852103/824000991891554375/1039273310392950806 Not only did I find out that RCT values shifted, but the website makes this art larger?

It went from 34 bytes to 52 bytes...

Changing `upsample 2` to 1 brings it down to 33 bytes, so what changed since then where upsampling takes up so much space?

Upsampling is completely broken for me

Or... Apparently only for certain images? Weird

Something broke internally to jxl_from_tree with resampling. Using cjxl it's a fixed 3 byte cost with no memory increase jxl_from_tree is going from 33 to 52 and 82 bytes with memory usage hitting 100 MB, 400 MB and 1.4 GB for Upsampling 1, 2 and 4

It's likely that it broke around the same time RCT values changed, was it 0.10?

Wait a second maybe this fixed it? https://github.com/libjxl/libjxl/pull/3824

It's a shame the website is still using 0.11

YCoCg got changed from 1 to 6, but AFAIK the rest were the same

I'm using that build, it's where I got my numbers from

Welp time to go into another rabbit hole

No, values > 1 in the old numbering need a -2 correction too

Ah, thanks

This is probably a side effect of chunked encoding, it may be introducing more groups in the frame due to higher image dimensions that shouldn't be there because the actual frame dimensions are still smaller.

Probably, I know this didn't fix it since that's the version of jxl_from_tree I'm using https://github.com/libjxl/libjxl/pull/4141

**\_wb\_** _“The rocket”_ 2025 image/jxl 28 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMOVySc0pSQxIzEktKUnlcg1wUzDick9Myi%2FKLM7g4spMUwjX9tP1C1ewU9A15dJVALJ0DYG0e1FiSmZqXomCGRcA)

**\_wb\_** _“Fire”_ 2025 image/jxl 25 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnlcg1wUzDick9Myi%2FKLM7g4spMUwjX9tP1C1ewU9A1NubSVQAydQ2BtGNZOlAmXMGECwA%3D)

The rocket must've been a Boeing

**\_wb\_** _“Unexpected marble and gold”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5eLKTFMI1%2FbT9QtXsFMw4NJVCE4tUdA1NgayHMvSHXNyFIy4AA%3D%3D)

**Jonnyawsom3** _“Corruption of order”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=C89MKclQMDU04vJIzUzPKFEwMjXjcknNKUkMSMxJLSlJ5XINcFMw4nJPTMovyizO4OLKTFMI1w0P1%2FUL1%2FYLD1ewU9A14dJV8AtX0DUE0uFgU1JTFEwA)

I was messing with the rocket and ended up with that

**\_wb\_** _“Spilling and smearing”_ 2025 image/jxl 31 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5eLKTFMI1%2FbT9QtXsFPQNeTSVQhOLVHQtbQES7h7AEUNgIKOZel%2B2kA1xnC2q4KuERcA)

**\_wb\_** _“Brushed plastic”_ 2025 image/jxl 36 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnl4uLKTFMI1%2FbT9QtXsFMw4NJVcC9KTMlMzStR0DU2MECR1TWECrh7QNU6lqX7aQPldI3hHFcFY2RDDLkA)

**\_wb\_** _“The Epic Siege of the Nether Castle”_ 2025 image/jxl 47 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOQKcg5RMDLnCkpNNjI0MODiykxTSFawUzAEMSqADAMuXYVwBV1DIOUHEQ3X9tP1CwdKGRsbg0SBsiAWsoyuoSFEqbsHSB1QlWNZup82SKkRnOOqYAJkuxclpmSm5pUoGHEBAA%3D%3D)

**CrushedAsian255** _“melting crystal”_ 2025 image/jxl 31 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnl4uLKTFMI1%2FbT9QtXsFPQtTDg0lVwLEv30wbydQ2BHPeixJTM1LwSBSMDAA%3D%3D)

i don't have the source tree for this; I made it by editing random bytes in the JXL file

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1364415898030575718/art-1.jxl?ex=680996d3&is=68084553&hm=7387c32a89a3dffec8dd79cf121370ef5ef5c7637ea6795f54f55eb8535901de&

I've been trying to experiment with something similar, but using fuzzers like AFL++ Here is one image that was found by applying successive randomish mutations to an existing image: I only ran the fuzzer for like 15 min but I want to do a longer run at some point for a few hours It reminds me of soapbubbles

Someone should try to make a tree_from_jxl

I might give it a go sometime

**\_wb\_** _“HDR test image”_ 2025 image/jxl 113 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=ZZK9TsQwEIT7PMXWB8ntrv8bCkRBCVzBA0Dg0sBJZwl4exwnu5HibuR86xnv5H7K7%2BMln4Gwe3ruHsfp85zBEXfd9AG%2FcAc4i78iDGLXwyuQfGEUFa0oIj0kyypD1CHWUw56lWGvMgaR1inrWFmXzCbV2Hu1CFaBuLnFlEr805ghBQ9wPIC3AeFrytdbuHFwzd%2BXKxyOIBRipQybKJRVaoUimwqRZ73K7KFgF79ILAzvGe%2FTjFh0gtCGlBe81SYWFreEqyp7mKcZzTp9eniBn%2FOUx82hbLAmRVqZnvYhyr5nxOEgL%2B6boKWeauUGSdo3Dy5tVisevDDN5kr5tYNBIveuQbjGMQMFYfyeKX9WtRqcWoWGsfUeHEISJjYM4cIYZVJTtl0QUqQM7Zito38%3D)

every band above is twice as bright as the previous one (before tone mapping, that is); the red line indicates where SDR ends.

wow, discord preview is world away from the true image, it s not even close

yeah discord tonemaps

unfortunately chromium on android seems to have some issues with hdr images, i noticed that with the test pattern i made too

my discord preview doesnt even have perfectly increasing white going to the right

the gradient has an insane amount of banding

like what-

and the entire page flickers a lot when not in desktop mode, for some reason

On my Nothing phone it looks like that banding mess (and only SDR), on my Motorola Edge 40 it looks fine (and HDR). Both have HDR-capable displays in principle, but I think the Nothing phone is somehow only using it in 8-bit SDR mode while the Motorola does use it in HDR mode.

My phone is an ancient Huawei, which also has a HDR capable display, but it uses a custom API so only YouTube and the internal video player can show HDR content

interesting, it's broken on my xiaomi (poco f7 pro) and also a friend's oneplus (13r) (both are very recent and support SDR dimming, so they do display it in HDR)

ah nothing phone, yeah they have a really poor reputation in android rom circles for bugs lol

what android is it? stock a10 or below?

On that Nothing phone, in youtube and the native photo gallery app, I can view things in HDR, but not in Chrome, it looks like. That's a pity. I hope they'll fix that in some update.

EMUI 12, Android 10

rip, one major update away from proper HDR

well, a11 isn't great, hdr on android doesn't actually become good until A13

HDR on samsung phones is a mess also

is it? I never had an issue on mine, even on s9+ samsung had a fairly sophisitcated HDR pipeline despite being A10

HDR on Samsung works fine with video, but becomes a mess with images, especially in browsers. Even chrome doesn't work properly oftentimes. Samsung Internet (lol) works better sometimes, but not always. Additionally I have not managed to get wide gamut to display properly in chrome. Heck, even the samsung gallery does not properly display wide gamut on my S23U

At least it works on an S24, but I don't think that the S23 is so old that this should not work?

interesting

**\_wb\_** _“DeltaPalette + Squeeze = ?”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnlCi4sTU2tSuXiykxTSFawUzDk0lUITi1RMADSfuEKusZcXFwA)

I was surprised to see such shapes emerge

Delta pallete is hardly explored, and was actually broken for images above 2040 w/h until I fixed it in my fork last night. Throw in Squeeze and you can 'see' the raw MA tree in fully encoded files using progressive loading, since residuals are stored without predictors for delta. This is the first pass of a Factorio screenshot

It's interesting how you can already see the square menu shapes being made by the tree (Or whatever's causing it)

**\_wb\_** _“DeltaPalette + Squeeze = ??”_ 2025 image/jxl 27 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QouLE1NrUrl4spMU0hWsFMw5NJVCE4tUTAB0n7hCrrGXFxcAA%3D%3D)

**\_wb\_** _“DeltaPalette + Squeeze = ???”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QouLE1NrUrl4spMU0hWsFMw5tJVCE4tUTAB0n7hCrrGXFxcAA%3D%3D)

Things are getting interesting

**\_wb\_** _“Set 0”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QouLE1NrUrl4spMU0hWsFMw5NJVCE4tUTAA0n7hCuZcXFwA)

**\_wb\_** _“Set 1”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QouLE1NrUrl4spMU0hWsFMw5NJVCE4tAdN%2B4QrmXFxcAA%3D%3D)

**\_wb\_** _“Set 2”_ 2025 image/jxl 27 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QouLE1NrUrl4spMU0hWsFMw5NJVCE4tUTAC0n7hCuZcXFwA)

**\_wb\_** _“Set 4”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QouLE1NrUrl4spMU0hWsFMw5NJVCE4tUTAB0n7hCuZcXFwA)

**\_wb\_** _“Set 6”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJ5QouLE1NrUrl4spMU0hWsFMw5NJVCE4tUTAD0n7hCuZcXFwA)

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

wtf gais

Does delta palette or squeeze run first on decode?

it's configurable

theoretically even squeeze-palette-squeeze is possible, but maybe jxl_from_tree doesn't support it

What would that do?

Squeeze the delta palette parameters of the already existing squeeze?

Lots of possible things are not available from jxl_from_tree. We would need to come up with some syntax to pass arbitrary modular transform chains...

maybe something like ``` Transforms - Squeeze - DeltaPalette - Squeeze ```

do they take any parameters?

Yes, currently jxl_from_tree just does default squeeze and deltapalette with zero colors and some default predictor, there are lots of other options that can be signaled but it will require some annoying/boring code plumbing to expose all that.

What about Transforms { Squeeze { Parameter 1 Parameter 2 } DeltaPalette { Parameter 1 Parameter 2 } }

Like I think maybe we should have 2 blocks, the header block and the tree block

**\_wb\_** _“Messy mosaic”_ 2025 image/jxl 25 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnlCi4sTU2tSuXi4spMU0hWsFMw5dJVCE4tUTAA0uEKJkAJLgA%3D)

**\_wb\_** _“How to tame this thing?”_ 2025 image/jxl 27 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcg1wUzDick9Myi%2FKLM7gcknNKUkMSMxJLSlJ5QouLE1NrUrl4uLKTFNIVrBTMOXSVQhOLVHQNYULGUKFQHS4gq4xFxcA)

**Tirr** _“Noisy palette”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnlCi4sTU2tSuXiykxTSFawUzDk0lXwUzAHkuEKplxcXAA%3D)

**Tirr** _“Noisy pattern”_ 2025 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnlCi4sTU2tSuXiykxTSFawUzDk0lXwC4dRuoZcXFwA)

Would be curious to see how random that is

```bash r2@4f34c12546c7:/app$ rahash2 -a entropy random2.bin # same size file from /dev/urandom random2.bin: 0x00000000-0x000fffff entropy: 7.99983608 r2@4f34c12546c7:/app$ rahash2 -a entropy random.png random.png: 0x00000000-0x0020c263 entropy: 7.99787395 ``` This might not actually be the best way to calculate that, and would be better to see if there are some parts of the file that are lower entropy

binwalk has high entropy across the board for the .png file

this second image is a tiny bit more lumpy, hard to see unless you zoom in

Nice, so... We have *essentially* pure RGB noise in 26 bytes?

Probably XYB noise but anyway

Ya, I would say this output is what I would expect from a pRNG. There are some fairly small pRNG algorithms, such as LCG, which usually is a register which gets shifted/added by some constant and then a modulus is taken. I'm not entirely clear on what the squeeze / delta palette combination is doing here but I can imagine it may be a similar effect

**CrushedAsian255** _“A thing”_ 2025 image/jxl 37 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnlCi4sTU2tSuXi4spMU0hWsFMw5FJQgDKNgEw4xxjMgXMtoFywQAVInwFcRFchOLUEUwDG11UIB9uCLA4S0wXq0FXwcwXp5AIA)

**CrushedAsian255** _“Another thing”_ 2025 image/jxl 30 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=PcmxDkAwFAXQ%2FX3F%2FYEOFcJkEINRYugsXNqkA8mz%2BHpF2E5ymqAzN%2FWoZNgP8qS0jDr2Y6QqxYU5ZWEz6RhWrw8lLHCoYSpB4pRYCgwGKkx2y8HY%2F4rv8resXA%3D%3D)

<@224363555074342912>

The bot seems to have failed to publish this. Animated Delta Squeeze JXL Art

https://embed.moe/auto.gif?q=https%3A%2F%2Fcdn.discordapp.com%2Fattachments%2F824000991891554375%2F1365947610267127821%2FTV_Static.jxl%3Fex%3D680f2958%26is%3D680dd7d8%26hm%3Dfa232b6204174864f80a433c38cf6b950da59748ec13a34fb34ab59668d1a1de%26

<https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOBySc0pSQxIzEktKUnlCi4sTU2tSuUKz0wBShoaGJlweaRmpmeUQNiOeZm5iSWZ-XlcLqVFYAZQ3IDLL7_EJ7G4hCszTSFZwU7BkEtXwU_BHEiGK5hycTnR3i4LOtplCbbLhC52GRrSxjJUS4wglgAA>

125 byte JXL vs 6 MB GIF <:FeelsAmazingMan:808826295768449054>

10.2 MB Lossless WebP, so 99.99884% smaller as JXL art

this just demonstrates the png compression at work. running rahash2 against the raw pixel data yields 5.77188076

the entropy is likely not that high since most of the pixels will be some default palette color, of which there are only a small amount

(and then I suppose there will also be pixels that are deltas but again the distribution will not be very uniform)

but visually it looks pretty much like random noise, and probably the most significant bits of the pixel values are pretty much random, just the least significant bits aren't (but those don't matter perceptually in an image that basically has maximum contrast masking)

not actually jxl art, but resembles a previous jxl art image https://static.bhphotovideo.com/explora/sites/default/files/03-trvphoto-377-0039.png

transcoded to jxl; now it's relevant

oh, right, why is that lossless on their website

Hmm, wonder how many bytes adding a moon to the previous art would be

Can JXL art draw circles?

If so you could easily just add a layer with a blend mode

Could use splines, but they aren't filled so it'd need either a spiral or the inner color to be set seperately

A fat spline can look like an ellipse

Can a spline be a single point?

If so then it can be circle

It's been done before https://discord.com/channels/794206087879852103/824000991891554375/882262818727034942 https://discord.com/channels/794206087879852103/824000991891554375/899379720611840050

that is awesome!

Been done before but I fixed the aspect ratio and where the lines meet the corner :) tis my first major jxl art! 154 bytes [source here](https://jxl-art.surma.technology/?zcode=hZY9b9swEIZ3_4rr0sFQEdKKIidAOhRo0Sko0CGzatM2EUUUKMYf-fW9oyiKpOQE8CCKx-PLh_eefLOEP1rtteg6fJBbAb_qag9HDsubxW8h9wcDd4wtnuXWHIAzfPwhzVa0OFovFnIHZ_gOtwWDmyW8VrKBHa1vK20oA2DABQNyZgP-KWPUKxyqemdnh-min27fdFsL4LzMAH88L_ooCttgGKPnYcDtAL7BX2EoNByWi2CKl3MpaNtb1g99SquxfhPAUAAqWBWDAp8OX0XjspymQJyioRx8tc4gX6c58nU0xKhAryXRKNBiC4RTaZevara9uIGcpxAstAGyg6o-VZcO3oVWNoVRLagdtPaK7RV5skSCswjMKgFjU19EXavThEdezvMJlypdNXuRLuW3bHZpuJIoDMscvHCwInSuCG385iCOWjVIThpZ1fJd2OMTlgxa2bxkluPpII2ISjBnvN_vKHQnfB5ajKcW2hbtl5iaK9udPA-laxTsFXRGV9LASaJJOtnscaKWjT-_07sqZiC7PJTyccYIk_KfGCC2QGICGj79vG4CkpUPsiJdtq56VXPemKiauCX1i69ar9MLC57HeiQRnajFxgyF2BlqMpeEal7wa6Fnr9ennYkVWB6XsFSfnmGOiAt_pDNmZIMM338KhKWA8oSHJxZsPJo0kOs8lVAYi4tfiz1HtdQnnglOOMQg5tztSKCrYxJTFBMWk4Yw123H7Z1sduWK6Pxl8VE30OrUZFjT1eYFvoI4y86gTV133Kha6S6-SkrJC5Yeydlfd8Y2KvS9bC0I2_fxF2KI-1fSw2IwveNI3bSg7BwdAPe5x6IryIs83Mil5RO16c5Fmb65LwPX9Qyt5R8GlA-9rmxkODbWoKmOpVXEd5azOcOPt007Rnni7oj7-DoryXaMfdYZ_bfMV1lZfPrZqe0fH9v0qA3fEWLr8nWqiydfw_jTjquivyn87j8)

WOW

awesome

Huh, I wonder if you could turn the bottom of this into the flag

<:logo:829708783336816671>

what I like about this one is that the JXL encoder is actually able to somewhat reproduce this when encoding the raw pixel data

`art.jxl 154 B` `djxl art.jxl dec.png` -> `dec.png 7.4 kB` `cjxl dec.png new.jxl -d 0 -e 11 -g 3` -> `new.jxl 291 B`

dang, 291 bytes is pretty good! I wonder what the prediction tree looks like 🤔

I have a version of the encoder patched by Jon that's able to export the tree, but it only works on grayscale images (because every channel has its own MA tree, and the code is only made to output one)

It outputs all MA trees, but only 1 channel's PPMs

oh ok

the lower efforts do pretty well too

Huh, interesting. I can only get down to 510 bytes

Ahh, 0.10 is 291 bytes, 0.11 is 511

I did specify group size 3 for all effort levels

Effort 11 ignores all other parameters

And I did `-g 3 -E 3 -I 100 -P 15 -e 10`

got it down to 285 :3

`-I 91`

Main thing is only Gradient and Weighted predictors are used until e10, so adding `-P 15` brings pretty much all effort levels together

it would be fun if we could set a seed for the random generator that decides which pixels are used to learn the tree from. that way you can do `-I 90` and try 100 different variations of it, and go with the best one

you could probably train a neural network to give you the best subset set of pixels to for learning the MA tree on any given image. ...though how well that works would depend on how sensitive the tree learning algorithm is to tiny changes

the fact that a subset of the pixels can give a better result than all of the pixels, implies that there's some tuning that can be done. ideally no subset gives a better result than the whole, unless this is one of those undecidable problems

I recall Monad discovered `-I 100` isn't actually 100%. You need 1000% to use all pixels https://discord.com/channels/794206087879852103/804324493420920833/1288947695066546176 https://discord.com/channels/794206087879852103/822105409312653333/1346201024221806602

I wonder how costly it would be to *actually* make `-I` map to the percentage

huh

does it like, do one iteration, trying to capture everything in the tree as well as it can. and then do a second pass for the pixels that have the highest residuals, as a final attempt to still properly capture those, or something?

I don't really understand

Gonna move to https://discord.com/channels/794206087879852103/804324493420920833/1370401843678675058

**\_wb\_** _“Wonky frame corners ”_ 2025 image/jxl 29 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJVeDi4spMUwjX9QtXsFMw4FJQ0FUITs1JTS5R0DUC8oByfkBJqBxIFqgQLANiQ5lcAA%3D%3D)

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

**\_wb\_** _“Étude nº19”_ 2025 image/jxl 30 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJVeDiykxTCNf1C1ewUzDgUlDQVQhOzUlNLlHQNbQEcoGSfkBZqCRI2rEs3U%2Fbz1XBCMEP1wZq1zUECnABAA%3D%3D)

**\_wb\_** _“Étude nº20”_ 2025 image/jxl 30 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJVeDiykxTCNf1C1ewUzDgUlDQVQhOzUlNLlHQNQJxgZJ%2BQFmoJEjasSzdT9vPVcEIwQ%2FXBmrXNQQKcAEA)

**\_wb\_** _“Étude nº22”_ 2025 image/jxl 30 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTgcknNKUkMSMxJLSlJVeDiykxTCNf1C1ewUzDgUlDQVQhOzUlNLlHQNTICcoGSfkBZqCRI2rEs3U%2Fbz1XBCMEP1wZq1zUECnABAA%3D%3D)

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

Delta Palette my beloved

**\_wb\_** _“Default delta metallic”_ 2025 image/jxl 30 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=HcgxCoAwDAXQPaf4uxRsoXVzEEGn4pa50KgBEZHcH4vb401qVR474Xua5bKylUvMhIi1to4%2B0Cp6nIYQE5Hu4C67zBjhhp4Ah%2BUtVeU2OJ%2F%2BYIYfmugD)

Yes.

Is that jxl art or <#805007255061790730> ?

It looks like a dct coefficient ordering mistake

(transposing them or something)

oops, yes, sorry

jxl-rs glitch art

transposes, how do they work?!

Mistaking columns for rows.

sometimes they do sort-of get baked into standards!

https://www.rachelplusplus.me.uk/blog/2025/03/lets-build-an-avif-encoder-part-2/

is this a frame from big buck bunny or is my mind playing tricks on my

somehow this image activated my big buck bunny sleeper agent even though I don't consciously remember much of what that video looks like... weird

Has anyone made a colorwheel in JXL art yet? I know we have the RGB cube, though that's not sorted so it's hard to see all the colors

it is big buck bunny!

I knew it

those pastel colors and trees are unmistakeable 🐰

**\_wb\_** _“Co and Cg colors”_ 2025 image/jxl 35 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOQKcg5RMOPiykxTSFawUzDgUlCAMg2BTDCnEioOAroKfgq6hnBOcGqJgqmhEUxlBYrKcAVUhboQlRCOkakpFwA%3D)

Something like this?

Close. I was hoping for an RGB one, to visualise the effects of RCTs. I could even make it animated then

`cat tc.jxl.part <(echo -n 'JXL IS TURING COMPLETE') > k1_turingc.jxl` `cat tc.jxl.part <(echo -n ' FLRKQLL:RIF.DWKIZ!MRE') > k1_turingc_dec.jxl` I had a bit of fun and madea partial jxl file you can use to en/decode 22-character messages 😄 (not quite jxl art, but close enough...)

**\_wb\_** _“RGB colors”_ 2025 image/jxl 63 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKcg5RMODiykxTqFCwUzAyNeVSUIByTA0NgRwFBV0Fx7L0cG2%2FcAUYP1xB1xCirhKozgAsCuVATEASMLYwhgrAhcyMLeFCcEFzM3MkQbBwMtxwBNBV8MMqZohNsyGRmnUNuQjoxbQC1SwsrkW3DMUiDPVYbMVmAEIeIYtmlq5CcGoJGg8UKwA%3D)

Huh, how does that work? It looks like you're just attaching the text to the end of the file and the MA tree is creating the letters?

could be messing with the ANS or something

and/or with patches

it's a combination of MA and patches

But, it's just raw text being added to the end, right? I'm amazed that's a valid file yet alone that it produces text as the output

it probably is just treating each byte as some kind of 8 bit index

to patches that just so happen to line up with ASCII

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1379064375155097620/test.jxl?ex=683ee148&is=683d8fc8&hm=da975065cf515f9bf17065894339218ae44c0290b79bb3a408d4bd001e071961&

would it be possible to write a version that skips the en/de coding part and outputs the text directly?

Sure, although a bit boring 😛

it would still be really cool

is it currently just an invertible S-box or something?

just a xor with a fixed sequence of bytes

ah ok

Hi everyone, I am new here, I wanted to let you know what I'm building. Since scripting those JPEG XL meta-adaptive trees is tricky, I'm building an AI system to do it for me. It's a two-agent setup: one agent writes scripts based on a set of learned rules, and a second "critic" agent tests them. The critic is pretty smart; it checks for errors, decodes the image, and even throws out boring results like all-black images or pure noise using entropy checks. The cool part is the reinforcement learning loop. The creator agent learns from the critic's feedback, so it's getting progressively better at writing scripts that produce valid and interesting art. My plan is to use this system to generate a whole collection for inscription. It's still a work in progress, but it's getting to a pretty cool stage. The intention is to have a collection of good jxl-arts. IMPORTANT: I am not using any of the scripts and / or images from this channel to train my system. I would like to know what you think about it and, in case I decide to release the collection as Ordinals (Bitcoin NFT), who should I give credit to in the description, Luca Versari, Surma, ...?

There's always been an idea to use a small neural network to create the MA trees for lossless compression, as any bad results would just mean worse density, not corrupted images. Using one to create JXL art, hasn't been explored though. You'd have equal luck just running a fuzzer and checking completely random images for entropy too, probably saving a lot of compute time too.

Maybe you are right, but anyway for sake of precision I would like to explain better, I am not using neural network or LLM, I am using an agent system, one agent produce scripts based on rules extrapolated from docs, the other test the jxl give feedback, the system improves both for the mechanism of reinforcement learning and because I don't explore the parameters space at random but using a genetic algorithm. Moreover there is an external loop of human based reinforcement learning. So in some way guided by my aesthetic taste.

I guess it is fair to say I am more responsible for jxl art than most other people if you need to pick a person, but the whole jxl team also has some merits 😛

Yes I know, you wrote jxl_from_tree 🙏 Do you see a reason for which what I would like to do could be non ethical? In case I could change something. And, could you send me a list of names to put in the credits, if i will do that.

(on my end I reacted just because for me, NFTs are diabolical, but I am just a single human in the unverse with opinions, don't feel too discouraged by people like me not liking these things)

It's OK, I like to hear all the opinions, thanks.

Yeah, considering JPEG XL is touted as a free and open format, selling off jxl art that people usually spend days or weeks crafting by hand feels a little off...

Sorry, I don't understand, if I will sell it I will sell my jxl art, produced by my system for which I worked lots of days and it will need several other days, why should be different?

I don't see any real issue; though there might be cases where it's not exactly clear if a jxl art meets the threshold for being copyrightable — I think some trees are just too short, e.g. you also cannot copyright a book that consists of just two or three words.

Thanks for clarification, but I don't think that for inscribe jxl-art as ordinals they should be copyrightable, I can also release my produced jxl.art as CC0

And put the script in metadata so anyone can see and use and remix in an open source spirit

Luca Versari and myself (Jon Sneyers) are probably the 'most responsible' for the concept of jxl-art. Also Surma's creation of a web interface did help to popularize it. And of course everyone who contributed to jxl or made jxl-art over the years — you can scroll back all the way to the top of this channel and see most of the history of jxl-art 🙂 https://discord.com/channels/794206087879852103/824000991891554375/824001294116454420

A simple version of your idea of your two-agent setup is something I played with a little bit at some point: https://discord.com/channels/794206087879852103/824000991891554375/824283392786563082

That is, I just made some trees with parameters, decoded the jxl files to pngs, and sorted them on file size to find the "interesting" ones (generally low filesizes are boring, though too high filesize might be boring too since 'too noisy')

Yes, mine started in similar way using size as measure of complexity, now I'm using entropy and other features extracted from image to better classify. At some point I could also use a small multimodal model to obtain a description.

https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsODiykxTCChKLVOwUzDg0lVwL0pMyUzNK1HQNQTJhGv76fqFg-WQeUampkC1fq4KusYgTeGpmekZJakpCoYQUSOgsVwA