JPEG XL

I can't get idea of this channel checks. For me it would be logical just to check y and set color

the prediction tree runs separately for each channel

so unless you want to perform the exact same action on each channel, the tree must branch on the channel number

You could just set the color directly if the image used a palette, but that hasn't been implemented for jxl_from_tree yet

Could you please explain what if c > 0 if c > 1 does? Documentation says "c: the channel number, where 0=R, 1=G, 2=B, 3=A (if Alpha was enabled in the header)". So for me it reads as 'if channel > red if channel > green set pixel color to' and it is quite confusing

```c if (c > 0) { if (c > 1) { return 1; // c == 2 } else { return 2; // c == 1 } } else { return 3; // c == 0 }```

Remember, each pixel is made of 3/4 channels or sub pixels

The tree is ran for each channel, not each pixel

``` if c > 0 x y ``` means that if the channel is green, blue, or alpha, do x, otherwise (if it's red) do y. so ``` if c > 0 if c > 1 // channel is bigger than 1, i.e. it's 2 // channel is isn't bigger than 1, but it is bigger than 0, so it's 1 // channel isn't bigger than 0, so it's 0 ```

Finally got it, I was confused by if (else) syntax. Thank you!

glad to be of help

Colors are bit different, here are correct. But anyway, thank you all!

yeah, it’s maybe not the clearest syntax

let me change the colous

I wonder if just having `<` to be able to flip the branches wouldn’t help already

also what's the aspect ratio?

as in a part of JXL or just `jxl_from_tree`

jxl_from_tree, as syntaxic sugar

could help, wouldn't be too hard to add i wouldn't think

I guess we would just have to be careful about the potential off-by-one when flipping

i < k is the negation of i >= k, which for integers is i > k - 1

so we would need to remember that -1

maybe also add `>=` and `<=` while we're at it

here you go ``` Width 900 Height 600 if y > 299 if c > 0 if c > 1 - Set 0 - Set 215 - Set 255 if c > 0 if c > 1 - Set 184 - Set 87 - Set 0 ```

speaking of off-by-ones, I think my Swiss flag has them

this is with those pantone colours

although i think colour spaces are doing something funky

it’s probably just the screenshot that’s “wrong” (in the display colorspace but tagged as sRGB)

probably

If you are talking about my screenshot - yes, monitor is +/- AdobeRGB, and screenshots looks incorrect

I think at least “>=“ should be added just for convenience

As off by ones are really annoying

My original render had an off by one I think

I'd prefer 'else' if only one change is possible 🙂

3:2

Suggestion for all in this channel, let's post sources of your images, if there are no secrets 🙂 It would help newbies a lot

the overwhelming majority of these do have sources, usually via a link to the online tool

The links the bots post go to the source

The JXL-art zcode link

Oh, then I shoud be more attentive 🤦‍♂️

consider just typing your else, or some other note in a C-style comment block `/* ... */`

How does delta palette work?

this is buggy though, doesn't always work

positive numbers use a regular palette (there is a default one) and negative numbers use deltas that apply to a prediction. So if some delta entry has the value (0,1,-1), then the currect pixel will be whatever the predictor predicted in the red channel, whatever it predicted plus 1 in the green channel, and whatever it predicted minus 1 in the blue channel.

hmm, maybe comments are more reliable in the EJS interface then. personally I made my own preprocessor before they were built into jxl_from_tree

also avoids that annoying tab behavior

not sure what that means, don't negative numbers always subtract?

if you're using a palette, numbers tell you which palette entry to use

0 and positive numbers use the regular palette, negative numbers use the delta palette

is the delta palette a second palette

oh, so the normal palette is palletising the pixels, where the delta pallete is palletising the residuals?

yeah

that makes sense

but now are there 4 channels?

there's just one palette channel and just one image channel

image channel?

as in, the channel that holds the image data. it's just one channel when you're using a palette

the delta palette is storing deltas to a prediction, how is that prediction stored?

like PNG indexed colour?

yes

the prediction isn't stored. it's predicted :p

so are there 4 trees?

no

don't you need R,G,B trees then the delta palette index tree?

there's 1 palette channel, where you probably aren't using trees at all

and there's 1 image channel, which just has a single number for each pixel that tells you which palette entry to use

you can use a tree on the second channel

for delta are there 2 palettes? the positive (normal pixel data) palette and the negative (delta entry) palette?

wouldn't there be 3 palette channels, one for R,G,B?

the palette channel is 3 tall, and as wide as the number of palette entries. the first row is R, the second row is G, and the third row is B

otherwise wouldn't the palette be greyscale?

oh that makes sense

delta palette and regular palette are stored in the same channel

so they're the same palette being read differently?

part of the palette is delta entries, and another part is regular entries

there's some math to map negative numbers to the delta entries and positive numbers to the regular entries

> whatever the predictor predicted in the red channe what prediction to the red channel though?

you said there are 2 channels

you still output 3 color channel though

oh, so it's like a running total?

like if the previous pixel is (30,20,10) and the delta says (1,2,3) then output (31, 22, 13)?

depends on the predictor

what predictor?

the image channel is storing palette indexes isn't it?

instead of "previous pixel" it would be "predicted pixel", i think?

when you're using delta palette, there's a fixed predictor that runs on every pixel whose palette index is negative

yes. and the predictor will use some combination of information from previous pixels.

in jxl_from_tree you can currently only use the default palette, which has zero defined colors, so positive indices are predefined colors and negative indices are predefined delta palette entries

so a delta pixel is ``` output = FixedPredictor() + delta_palette[palette_index] ``` ?

in the jxl bitstream, you can have a non-default palette, and then the first N entries are interpreted as delta palette entries, and the next ones are interpreted as regular palette colors. The number N is signaled as part of the Palette transform info.

(also the type of predictor to use for the delta entries, the number of channels to apply Palette to, etc)

that makes sense

the jxl Palette transform is as generic and flexible as we could think of, even with an empty palette you can do lots of things 🙂

**Dominikhlbg** _“German flag”_ 2024 image/jxl 36 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0pZmBlweqZnpGSVgJldmmkKlgp2CmYkBl4ICkJMM5ICYIADlGkK5Cgq6CsGpJXBpGN%2FI0JQLhW9qCjPW2Ih8Yw0wDIWKAwA%3D

<@736640522042605604> You can actually optimise it a little bit

``` Bitdepth 8 Width 960 Height 960 if y > 320 if c > 0 if y > 640 if c > 1 - Set 0 - Set 215 - Set 0 - Set 255 - Set 0 ```

im guessing mine can also be optimised further

someone should try to make a svg to jxl art converter

https://github.com/wwww-wwww/spline

Would be nice to add support for some solid shapes to that too, in addition to lines. Rectangles are easy to do as a MA tree. Shapes with diagonal lines at 45 degrees are also relatively easy.

**spider-mario** _“Swiss Flag (pantone 485C, delta palette)”_ 2024 image/jxl 65 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0pZmBlweqZnpGSVgpktqTkliQGJOaklJqkJmGlelgh2XobkljGkOZOpyBaeWKJgbcXFlpikABRVMzSy5FIAqFCrgHAUFXQWoKhAHKmdsAZGDyRpaWKDwwaqhhsLUQrUCLcZUiiRvCJfHNBy7Y2AOxWUiwrF4TYQzAA%3D%3D

oops, the “Prettify” button doesn’t seem to interact well with DeltaPalette

here it is with correct formatting https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0pZmBlweqZnpGSVgpktqTkliQGJOaklJKhdXZppCpYKdgqG5JZeCApRjDuYoKOgqBKeWKJgbgTlQOVMziBxYoAJFAE0DkhpjC4QamCpDCwsMMbhOqGXI-qBGwdyGw0K4OkMUddgtxe1gZE_hswXVY0TYAmcCAA

are you just using DeltaPalette for palette instead of specifically delta?

yes

I’m using the implicit default palette

the red is quite approximate though

is there a way to define custom palette using `jxl_from_tree`?

it’s supposed to be (218, 41, 28), but it seems to be (191, 63, 0) instead

I got the palette indices by rebuilding with this: ```patch diff --git a/lib/jxl/modular/transform/enc_palette.cc b/lib/jxl/modular/transform/enc_palette.cc index 3392b4f8b..212777c8b 100644 --- a/lib/jxl/modular/transform/enc_palette.cc +++ b/lib/jxl/modular/transform/enc_palette.cc @@ -96,6 +96,17 @@ static int QuantizeColorToImplicitPaletteIndex( } } +static bool printed = [] { + int red = QuantizeColorToImplicitPaletteIndex( + {218, 41, 28}, /*palette_size=*/0, /*bit_depth=*/8, + /*high_quality=*/true); + int white = QuantizeColorToImplicitPaletteIndex( + {255, 255, 255}, /*palette_size=*/0, /*bit_depth=*/8, + /*high_quality=*/true); + fprintf(stderr, "red = %d, white = %d\n", red, white); + return true; +}(); + } // namespace palette_internal int RoundInt(int value, int div) { // symmetric rounding around 0 ```

then, running pretty much any binary (which also happens while building) will print ``` red = 72, white = 188 ```

I did something similar here: https://discord.com/channels/794206087879852103/824000991891554375/1281672949044215850 To find the color, I remembered it was a 4x4x4=64 color cube followed by a 5x5x5=125 color cube, so white is at the end of that and I manually looked for a good red in the second cube. I was actually on the fence about going with 67 or 72 🙂

Even much smaller than the .svg on Wikimedia Commons

to be fair, the use of the implicit default palette means that the red is somewhat off

this one has a legal colour

(the same as on wikipedia, incidentally)

They probably took the colour from the Wikipedia SVG code

i made it smaller by using `HiddenChannel` as a mask https://jxl-art.surma.technology/?zcode=jY-xDsIgEIZ3nuJewARqaWFx0MXRxMHZyCkkpjENMfr2Qgu0JaFx4r7jv_-_2xur8GU1CHIxyr2yoeSI5qHtWBqlsDvoa9fhExgh5g432AElAK489fh2VPHaMcAGzmgd8YGClA2QsAqY1CJr1HEg_DMxZn29Vyujtcc2YNTSKcp_80Ymb9f6ZK18aibbirksP6w0HmKXw8FxWrUUnaQsk5biV_Zfnrmalp_6X1qsfw

Basically using a hidden channel to store a 1 bit image?

ooh, very neat

You could probably store arbitrary bit planar images like that

yes, i use `255` on the hidden channel where the flag should be white, and on the other channels i check if the previous channel value is `255`, and if it is, set the current channel to 255, otherwise to the red of the flag

As long as you can reference back far enough with Prev

also, curious if anyone can manage to get my austria flag below 41 bytes... i tried a bunch of tricks like this one but couldn't do it

Which one?

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

feels like there should be some trick there to get it smaller, but idk

I used 4 hidden channels to have 4 masks to make the flag of Seychelles https://jxl-art.lucaversari.it/?zcode=lZA9C8IwGIRn%2ByveXQr5bl0c7OKkokLnYqMNSJQSRP%2B9adqEgNri9twldwfvvjgCStaqrqUumkpreQWWrJSp5d00kCfbVkltKqNu2j6UqrbuQtiIVJfGALOYqDOcYGl7BsAeiAcaPjEP3Fm7Vj6oj3SCxYLHQjiRwkEawFQMlPMBqAfCPfE8bJC4aWqwTwsPBGe%2FNzChYQTHVVOLfRyFQhLWPkf6G7%2FcjQFS2MAcMKedsP7T%2BbMUSvvUhWZ%2FpzhGoylEvqUyMbrVlY6H3g%3D%3D

it's definitely a powerful technique

I saved 1 byte https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0qbmZlweqZnpGSUKxhYmXFyZaQrJCnYKBlwKCkBmQFFqGZBnZADiKyjoKgSnligYmZqCeVClhmAOTNLEDIVraAYxqBKk0Mgcpg_EhRkDNxZqCbo1CFkA I lowered the image resolution to take advantage of the div8 resolution mode

**\_wb\_** _“Flag of Austria, using YCoCg”_ 2024 image/jxl 37 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKcg5RMOMKz0wB8iwNDLg8UjPTM0oUzIBMrsw0hWQFOwUDLgUFKNMQyFRQ0FUITi1R0DU0MkDiGlpA1VWC1FlagqWgXGMoF6bWzACFa2KAbBBQEgA%3D

I haven't tried to get the colors exact, but it should be possible. Basically I set the whole image to the right chroma value for the red, and then it's only the luma channel that needs to be adjusted. Using a "brighter than white" value for chroma makes the resulting color clamp to white so the chroma values don't matter (this trick only works for white and black)

Forgot RCTs existed lol

interesting approach, i just tried a similar "brighter than white" trick using the `N` predictor to add and subtract from the channels, and it *almost* works, but the stripes end up off by 1 pixel

https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0pYGBlweqZnpGSUKZkAmV2aaQqWCnYKhpSWXggKUYwzmKCjoKvgpGIBZUAkjqAREStfI1AyJC-EBVSYDVcK1gTiGcFXBqSUKJmYoXEMzLgTHCOgkAA

that off-by-1 should be fixable by picking different constants, but that might make it exceed 40 bytes

nice, your approach indeed worked to get it down to 37 bytes with the correct colors https://jxl-art.surma.technology/?zcode=VYqxDkAwGAb3_ym-F2jyNyhdDCxmJB5AS7sZunh7RSW63eWu88HYIzg0NPYzFC3eRNPMNFi_uwAVkfyGFS2YgIQyIiAw2QAhuf6prMr3O-9P6yclLZJ-r8q1ZKYsXg

**\_wb\_** _“Shaving off one more byte by reducing resolution ”_ 2024 image/jxl 36 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKcg5RMOMKz0wB8ozNDLg8UjPTM0oUjEwMuLgy0xSSFewUDLgUFKBMQyBTQUFXITi1REHX0MAciWtoagJRVwlUZ24JloHyDE0hXJhSM1SusaUlF4okAA%3D%3D

Still possible for the most complicated flags?

I want to see the flag of the Portugal now ! 😄

Should try and do as many flags as we can, then compare the sizes to their SVG/emoji equivalents on the new website ;P

looking forward to your result

I wonder what MA tree will be learned if you use the flag of the United States

The idea of encoding with cjxl, then viewing the tree and streamlining it is an interesting idea

Might actually be slower than running e11 though ;P

can't do that straightforwardly with libjxl producing non-zero residuals

Yeah

I think the tree for the xor pattern was found via throwing an image at cjxl

The stars might have to be done with patches

For max efficiency, probably

How do you draw a star using JXL art?

<@265247121261854722> figured out a method earlier this year: https://discord.com/channels/794206087879852103/824000991891554375/1208537351278694461

**dogelition** _“Identity 3D LUT”_ 2024 image/jxl 43 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOMKz0wB0qaGRlweqZnpGSVgJldmmkKygp2CAZeCApRpCGSCORVQcSg3IKAotQxJSEFBVyEcjWeIUF6JohSkH107SIsfBt8CycDg1BKoPJqBQK4fkGtmhFUxzCiYaxByKL4CcsKRDUE1AuEdmDgA

**\_wb\_** _“Funky iPhone 16 wallpaper”_ 2024 image/jxl 31 bytes https://jxl-art.lucaversari.it/?zcode=43LKLElJLSjJUDA04grPTAEyTMyNuDxSM9MzShQMDYxMuFxSc0oSAxJzUktKUrm4MtMUwrX9dP3CFewUdE0suHQVHMvSgSIKuoZAdjhYX2qKgrERAA%3D%3D

Melted cloth

I like how you can keep a similar structure but completely change the colors by changing the number in the if condition

**\_wb\_** _“YCoCg visualization”_ 2024 image/jxl 55 bytes https://jxl-art.lucaversari.it/?zcode=Zc0xDoAwCAXQnVNwgSaFSNPJQXcHNfEAWqObQwe9vWhKYuLEC%2FChb0cM0Ox5SUfeMALsK85YI726VP5Bp3AsAZzSkZYhZWSRjyzqX50WnRQsVVksRyakb8N%2BCZFlH5bbbGEK%2Fj8mjkWhAoAb

**\_wb\_** _“XYB visualization”_ 2024 image/jxl 63 bytes https://jxl-art.lucaversari.it/?zcode=i4h04uLKTFNIVrBTMASzKoEsAxDDD8jQNTU04NIFMnWNgFRwaomCqaEhEgum1QDMqoBpDQcyIDpBCnUhesIVjJAFYHaB2FC9CLMNzQxgug2NDAwwFVjA5U2ALC4uAA%3D%3D

**\_wb\_** _“YCbCr visualization”_ 2024 image/jxl 56 bytes https://jxl-art.lucaversari.it/?zcode=c06KdC7icsosSUktKMlQsOTiykxTSFawUzAEsyqBLAMQww%2FI0DUyNePSBTJ1DYFUcGqJgpGpKRILptWAC67X1NAQxKyAMqFqDQygLFMDTFldU5isLkghF0wFWGk4kGFkagJXAHZQuIIhsgAA

those are nice

very colourful

You can see how those "same-luma" planes are only roughly the same actual luminosity in YCoCg and YCbCr, while XYB has slices that actually do look like they're constant luminosity.

(even though the Y of XYB is only based on L+M, not S cones)

is it just because S cones are quite weak?

For jxl, XYB is designed the way it is because the frequency sensitivity for S cones is lower than for L and M cones. While S cones do contribute to overall luminosity (but with a small weight, see e.g. the weights for blue in the various yuv matrices), this is only really true for large areas of color (say, color patches with a diameter of several degrees of visual angle). At higher frequencies (pixel-sized colors), it's basically only L and M cones that do the work.

for what it’s worth, here are their unnormalised sensitivities

<@179701849576833024> do you think you could update the website to allow this? https://github.com/libjxl/libjxl/pull/3728

Or is that a bump to 0.11 when it comes out soon™

ping me again when 0.11 is out 😄

Will do

Does anyone feel like implementing this test pattern as a jxl art? https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2111-2-202012-I!!PDF-E.pdf (the one for PQ full range, for example — we don't have narrow range in jxl, at least not in the enum colorspaces)

sounds right up my alley... i guess it would have to be done at half the size of the 2K version? (actually that doesn't quite work, d/2 wouldn't be an integer then...)

half the size (maybe with `Upsample 2`) is easiest but you could also make an image that is actually 2K, it's just a bit annoying that 1920x1080 requires four groups so you'll need some `if g > 21` stuff

oh, didn't know groups were a thing

i'll give it a shot later

I should write a tool that spits out trees for patterns made entirely out of rectangles

huh, right now I wish (delta)palette and hiddenchannel worked at the same time, would make this much easier

**dogelition** _“ITU-R BT.2111-2, PQ full range in 2K”_ 2024 image/jxl 301 bytes https://jxl-art.surma.technology/?zcode=rVcxdtswDN1xCl4g74EgIZJLhk6ZsnTIARo38dbBQ3P7WrYkSyRAimo2C5AIEPj4%2BH47v18%2BjU2E8HI6f3xejMWI8ON8eT%2F9GT0IcP5tPsyzIQvGzL%2Fp%2Bvvx5G5Pt%2Be%2F12cXZsNiGnhYTIsxuLVxMUe7Nd8cv64OzMyLwxYOY57Mz9PFcCTVR1h%2BN3nS92VAxKrPOa9kwN7Djvhq9Pn22vnOBxC%2F4PVZd9sj6PROyvodUt5uy6lsN7kktZutK291c0QnlfsOJ6ngczokORd34iS6y%2BvJfgTd53UcoIY1hPbrx9rvmHcDY8o%2FRGhEVWLOtSPZHrcDNUVLFiqxxEjTzQJCK%2FocOc1U9TUCh9IDu6Mh2A14R1NEAbxrTlN5rcJtVX6rMkyDZVpcV%2Be7Gud9T1Yy%2F9U5UOfBRk7VjHROrPGixo3aqEokMjU%2Bf%2FFNxDatCrKArzzMepQASV5hU%2BdVQHqfdDYdmKGfLO9ei%2BTUcibSeCvaKBY6WIlFBuvLqbcE6i0m8sFy8LO5H20pb9qrKS1P3qFEGV0NkrrQVBfVCmPP6OjLTY10XBR1pq18dGwr7j5%2B%2FUG2PorlIayOUhwp8kgVSBWJVBVJDZnUFEo7pFJbLNXlUlUwtcFIuLO5xyHqmKFnh0gC6rBuT6QKt0EWbsn%2Bl3DLBZWWyVZUbWCOoO%2B2bXMEuM9o9hGaKJ4jspenJXKALkDnO0MoLyZNY6P8R4qQQeSY3X%2BviiqVW0raUfmGKvbTsm54d6nLih6fK%2BxbCp1j3XlSdSbkicjOLowPwPwD

verification of correctness is left as an exercise for the reader

not sure if there's a better way to handle the bottom row of pixels that fall into the last 2 groups, i just copypasted the tree from the previous tiles

any reason not to tag it as PQ?

not supported on the site yet, i think? https://discord.com/channels/794206087879852103/824000991891554375/1282936525138558988

ah, true

did it locally, here's the file tagged as bt.2100 pq

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1283494386898047017/art.jxl?ex=66e332cc&is=66e1e14c&hm=49bb22fc39b27fe6c5084af48e32840539cd005d2b548d3c91909569de6a8085&

are those weird colors at bottom left and right from tonemapping? it looks correct with proper HDR support (tested with jxl-oxide-wasm on chrome)

you mean in the preview here? that's just (wrongly) tagged as sRGB

though discord does support hdr png files, so one sec

currently thinking that this should be doable by using alpha compositing, putting the bottom bars on the first layer and then making the second layer's last 2 groups fully transparent + making the bottom pixels of the first 2 groups transparent? not sure if that works

here's the tree without the copypasting for the bottom part, if anyone has a better idea <https://jxl-art.surma.technology/?zcode=tVUxdsMgDN05BRfIewKBgaVDp05dOuQATZp46-ChvX0d2xAHJGLy0s3WBySk__n7_jCcpQoaxNuxP50HqcCDeO2Hw_H7goAQ_Zc8yReplZAyfuvxW8qd_DgOEqbvEfkdkU6H6TcFnIqBFPJwDU3BnzGIDlfBFO5sdxNOgMMcSJBXJTSBnyMIBJRARYLxotbrKq6B3r-g4X-q0tpWcURTqcoaIxpqqlYUu1TLh8YJdqfNz10TLFsbsORQvnCfFbo0bNWQRL7yMGWAIqQ2SBMSDUtIYwLdy5nhttbNgBVUgUa2nUGXY5oRrzzZaJcJZ452aj3QpSylBXuLeYmBUviZ7i-xkA_tXZaRnUGgnoymAVFTqPB5Q4ehRTrclkom9rRnl81sYvKz2RuPX2_I7KMwD8I6ohEQZqJsIKmBgaaGVchp13qsaVdxD_dUmuae7mVBsIFZcE__dUatVFh7qnkyatg43McpiuS7x3vIch_nn0BRGzSH-I7kqAlK3MnK5Fxu60BsqSRWQdAcBO9tt8Mh6B7ZbLy4y-KY0RpaLd460UTo3DOI9kJgBoLgBM1QK8g3RvCUvZVU0aXSpSiPyh2q8KdkN3Zzq8uOPq4raDOFRlk3nlTVBK2I7OwieCXMHw>

None of the tools I have maps correctly the colors [⠀](https://cdn.discordapp.com/emojis/654081052108652544.webp?size=48&quality=lossless&name=av1_Hmmm) browser, FFmpeg, decoded PNG using djxl, ...

even eye of gnome does not show the same art.png you sent <:KekDog:805390049033191445>

hm, i just djxl to make the png to clarify: i ran djxl on the 311 bytes art.jxl file, which is actually tagged as bt.2100 pq

I don't have an HDR device to test anymore since my s9 dedded itself

**dogelition** _“ITU-R BT.2111-2 (2K, 10 bit, full range PQ)”_ 2024 image/jxl 232 bytes https://jxl-art.surma.technology/?zcode=rVY9b9wwDN35K%2FQHDqBIypKWDh2KTEGBDpmD5JrcUDRobkj%2Bfe7D0tkWebYP3ez3LD2JfCT9sHvevzqfCeFuu3t53TtPWeDHv8c%2F259%2F3x26DXmB77v98%2Fbt%2BCUC7H67F%2FfNkQfnyjMdni9vfHo7vX8c3jkWoEJd6CpUwchDsMLJj%2BET8XQgcAJXwjeEcxv3a7t3IZHJEbbreib%2FvxMQBZNjFuMEQQQW6Jvq5fbW%2FiwR1BVhuNcZu4j23%2BRJvmOeptuH3KabOGvpDp7bW52IxFq4z3bSAl6OQxpZ6RyySrfX03kEmxPbB2h5DWH%2B89vSzyEsNkZ%2F%2FphgRtXQLLEjHU%2FjgurVsocrWqpSf7OIMKdelHNpVZ%2FH3iID7x6BzE2vwtEmD66tCBrUbe15reG9oGZ4EsPwLJ1leJFsG74LAdb7%2Bcx6JDY9m8myVvJJTXT0WqI7L21iPIF5i94fOGosx3Qx8jjOZ1AmovcOG2QjjG2OOK5KkZaH2RFwNcbmSEFY04FMpdsn18pjG4tua12Ltx8umNR4U%2BF1XA0n2rC%2Bx9rK2CqTSRLMzqSiFkS3UgoRVo2oad0oDRWzNQpQn%2FeEAdQoL%2F4LaKKkVKpap9MqbWq0llxYHOw2prfbH9cVhr7IlF%2B509Wpq%2F9BTPZuwItlvgA%3D

figured out how to optimize it: using `FramePos`, shift everything up so that the bars on the bottom start where the first row of groups ends

so then i don't have to duplicate anything

*maybe* the entire thing can be optimized a bit more by also shifting it to the left, since there is a tiny bit of duplication on the horizontal borders too

i think the only viable option there would be to split it in the middle of the green bar

did that, now it's down to 225 bytes [here](https://jxl-art.surma.technology/?zcode=rVY9bxsxDN35K_QHDJAU5ZOWDh2CTkGBDpmDxE08FA1SD8m_r-2e7kMk72yj2-lR0hPJR_Ie9s-H10AlC3zb7V9eD4G4CNy9P_7aff_9J2y2EjZMAl_3h-fd22kvAux_hpfwJTBBCPWbj9_jKp5X5_XHcS2x64EB6hgHaAAzTsERznP4bHg6Glp4MJAyhLAJP3aHkDK7NkZ9rreU7X97AXNybTGK84IkAhfwu-zVe-_-KB2YJ9L0rn_YSNrvKU2-SWKbb-ao8x0xWvlOXafdOhm26pGjnsiKajVmy6jd0Tbx84ieVhDWt9-WvpjSxYnt399lWGF1OGtq2cbzvCB6tkKwwGUy9Z51CGvslbnUVvN56g0y0d4JKFFpD2eXPAStaJrQVw3PmkFVMYol2IiOYIXQE2yiuCBYKguiHOvNshJydEVb2NNWpmxmuiMr01sSnRlicL3oBYJlGudP1QMGUBrS-4AK2Ug0hgg1XXwtR1YiVpv4YpDdoYBwTQ9ymW6fPVc-2zl0W_O6-PrpgabKVY3XP4QkYFf4nNuYO3W0EMPqUKlsqlR6g19dU-E3nQ_twcuYwAzWxeNYOWtUnFlvbbWpWquVM3NqOWY6NLerGK_Tt33Ipb_ypsXxaf8KNHcrcJTMXw)

properly tagged jxl

This is because my monitor is not hdr, or it is intended?

it's intended, this is how the full range pattern is specified

on the limited range pattern, the very first step is blacker-than-black and the last step is whiter-than-white (i.e. outside of the nominal range)

Thanks

are they meant to look different even on hdr display?

for blacker-than-black: no, unless you lift the black level of the display for whiter-than-white: i *think* not, but i know that they are supposed to be distinguishable in SDR, at least in areas like broadcast monitoring

they look identical both in HDR and SDR for me

i meant not on this image, but whiter-than-white in SDR in general

or do you mean in editing software there is meant to be indications?

if you have an sdr tv/monitor set up in limited range, then values above 235 (the upper limit in 8 bit limited range) should still be distinguishable (i.e. instead of clipping, actually go brighter than the 100% white level)

but there's not really a point in that for consumer use, i think? just production

i think mac display is probably full range though

even in SDR

these whiter-than-white values can't even be obtained normally with limited range output, as e.g. your graphics card would map full range 255 to limited range 235

to actually send those to a display, you have to do weird things like setting the gpu output to full range but then telling the tv/monitor to interpret the signal as limited range

very niche stuff, again not really something you'd ever want to do as a normal consumer

in the pc world pretty much everything is full range

oh, since limited goes up to 235, is the "white than white" mean signalling 255 to the limited range system?

and jxl doesn't even support tagging an image as limited range

because limited range should DIE

iirc 255 is reserved, but everything between 235 and 255 (exclusive) should count

isn't 255 just full white?

why is it reserved?

reserved in limited range signaling, not full range

iirc this is in the hdmi specification? one sec

oh

so 0 is also reserved

don't think anything special would happen if you actually send that to a display? idk though

given limited range only allows 220 instead of 256 colours, is it technically 7.78 bit colour?

pretty much, you're wasting a fractional bit by limiting the nominal range

and we still do this?

yes

what good reason other than i guess backwards-compatibility?

https://tenor.com/view/i-guess-memes-meme-gif-17950413

afaik there is no other reason

why couldn't we dump limited range when moving to HDR? it would have been the perfect time!

to come back to that test pattern: i could make my jxl art use the values specified for limited range, and then you'd see a difference between the 2 white boxes on a normal setup

but to actually "use" the pattern properly, you'd have to output it from your gpu as full range and then tell the display to interpret it as limited range

which should bring it back to those 2 boxes not being distinguishable

is the point for them to not be distinguishable?

im guessing the very left box is 0 and the box next to it is 16?

i think hdr tone mapping should always map a 10k nits signal to the peak of the display, so i don't see what a display could possibly do with a signal above 10k nits (which the last box would be), other than clip it to the same value

blow up the monitor?

for the 10 bit limited range pq pattern

for completeness: these ranges (for the applicable bit depths) are also defined in bt.709, bt.2020 and bt.2100

this simple `jxl_from_tree` input: ``` Width 3840 Height 2160 Bitdepth 8 - Set 255 ``` compiles to use self-correcting predictor instead of Zero for some reason, and shows completely black image. tested on git head. ``` 2024-09-12T08:24:40.769955Z TRACE decode channels{stream_index=22}: jxl_modular::image: Single MA tree node cluster=0 predictor=SelfCorrecting ```

That's weird

where do you get those TRACE logs from?

`jxl-oxide -vv`

oh its jxl-oxide not libjxl

i guess that make sense

To me it mostly feels like a hack to get away with doing things in gamma-compressed 10/12-bit int that should actually be done in linear float

that's what i was thinking as well

yeah, I’m not sure I’d go as far as “making sense”

it's not the most crazy part about colour management adn digital signals

Like the sRGB linear segment to me mostly feels like a hack to make sRGB -> linear 16-bit -> sRGB a lossless operation. Without the linear segment you wouldn't be able to do that, and presumably this was important in early color management systems.

I would assume so, iirc the official reason was quoted to be "to optimize encoding implementations"

daniele sira... something quotes the specific reason here. sadly without accsess to the actual srgb spec, i dunno, I do know that the multiple specs that are out there, are contradictory and unreliable https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/4024

Both the "limited range" hack and the "transfer function with a linear segment" hack have become pretty much obsolete then, at least for still images, now basically everything (in authoring workflows) is doing things in float anyway...

can it store floats?

found the post, 66, also coincidentally, a reply by an aces developer talks about this, specificly the reply to the post in question, apparently it's not so simple > Actually, we do. A lot. Display swapchains are quantized to 8 bits in 95% of the cases. You can request a 10:10:10:2 or a 16:16:16:16 swapchain but the OS is free to return a 8:8:8:8 display surface and pretend.

I don't know how this would ever fly, but apparently it happens ~~must have not used rust~~

I can't say I have ever seen this be an issue, perhaps this is just a really specific issue that only has an effect in a specific use, but affects it hard

Isn't self correcting the default since it's usually the best? Could be that jxl_from_tree simply doesn't override it

sure, but the `jxl_from_tree` has `- Set 255`

yeah that does look like a weird bug

I don't think I can get this image to render in any way that is close to the intent on my computer. I end up with this, with a harsh discontinuity between the very light red and the very intense red.

on my ipad it looks like this but brighter

In Thorium on my macbook it looks as intended. Most other things I tried do weird tone mapping on it.

what about in mpv?

looks nice

on SDR screen (idk if that changes anything)

misinterpreting it in SDR sRGB looks dull but OK-ish, like the above discord preview. interpreting it correctly in HDR causes weirdness because it uses parts of the Rec2100 PQ space that are way out of gamut and out of luminosity range for any current display, so tone mapping has to be done, and presumably many things are doing that in poor ways

i ran into the same bug now ``` Bitdepth 8 Width 2049 Height 2048 - Set 255 ``` this somehow produces a 303 byte file that's only black, increasing the height by 1 makes it go up to 363 bytes (?? except the size actually changes every time i regenerate the jxl) if they're both ≤ 2048, everything works fine

Could be something to do with the group boundaries?

Please open a GitHub issue for this, I bet something got messed up when we switched to streaming encoding.

it doesn't seem to be directly tied to the *number* of groups at least, as changing `GroupShift` doesn't change the resolutions it happens at

Is there a fuzzer for jxl_from_tree?

The fact that is acting differently each time you run it makes me think it’s reading bad memory

As there shouldn’t be any non deterministic aspects

No, it doesn't get tested, isn't considered part of libjxl itself...

here's a screenshot of how it looks on my SDR screen

done

anyone know why [this tree](https://jxl-art.surma.technology/?zcode=lZTBDoIwDIbve4q-gAmDgXjx4MkTIfHAA8jE3YwhRt_eQYfdxmB4Yv3_rw0rpSfVt_LR36FkjWr1M01Eyc5Sdfcez0zd4ApHSBiAOXJ9HIO30U1Y10_5siSAHTRexAviPw47FPDzh5xqFhfCTup0RsotZNJSSyM1c1TShaeTk88c8oqAR-4-6JJfLvhEHBaJH5MlKwxRfJUiLo1wRGZRklixgSU630QPw3CRPfA_8W3vYuAtlzRovHMGjH0Kg61_V4TW5gOJ5RlDf2lG0Q3PN3qhtqMz7zDqfjNRdftmLs98JWGBraHDavxFBQvR08KYqpHnLC8dNE4Vt8a4tpitfwE) doesn't compile on the site, but does compile locally? seems to be related to the depth of the big `if` cascade, as removing a few of those makes it work on the site

(it's supposed to be compiled with width and height of 4096, which is why i need that many)

[changed it](https://jxl-art.surma.technology/?zcode=dZMxDsIwDEV3n8IXQErSUMrCwMRUVWLoAWhosyEUIbg9aUmVpORP9X-2f5xGPls3mIebuKHeDv6rhG7oYuw4uV9M9s43PrEg5hBKHy7iHXiQXfc0rwQx77jfKFnH-k9WOxts--ee9k_XOm0afYdqkpLAKpWwSHVGI99v-HzU1TiWMIGcKtQAE-VJBfCXyAYmgJM6ggbEC39Z6dLsqgYnHoAz4sgHPQri5SkVcEcPhTjygQ8CuKDCZnjZLlfWVKpel2L1jLlsQb3oM5fcY1lNSvkX) to a balanced tree and that compiles on the site, while the file size remains the same

it was indeed the fault of streaming encoding, disabling it in a local build made it work

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1284108786705109034/art.jxl?ex=66e56f00&is=66e41d80&hm=6a0023568616680ee4cb474a3b100845670c180ce047b54a358fc442f0d6a453&

contains every 8 bit rgb color exactly once

is this for that AllRGB thing?

more or less, at least inspired by it

idk if i'll post it there

try to see if you can make a more complicated pattern other than the RGB squares, while still using one of each colour

im guessing it would probably be way harder

especially without the ability to use residuals

I wondered if someone would do that, next up 16 bit ;P

sounds hard, yes

just having to deal with 16 groups at all is enough of a pain

yeah

jxl art is way easier when staying within 1024x1024

alternative "smoother" version that looks nicer but is bigger

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/1284111927865249905/out3.jxl?ex=66e571ed&is=66e4206d&hm=0f417a88ba2b7ea1c46d9a54bbfc17364cb9c0d208b996cc083a01e6e931dfe4&

is that sorting by luminance instead of binary counting?

the difference is how the blue values are arranged (which is the only thing that changes across the groups of 256x256 pixels)

this image has them incrementing in line-scan order

which, in theory, is nicer, but requires me to explicitly code higher starting values for the later groups

whereas in the smaller version, i increment the blue value by 16 between adjacent 256x256 groups, which lets me set the starting values per 1024x1024 group to 0, 1, 2, 3, ..., 15 – those are more efficient to encode

Perhaps using an RCT could help to make other patterns that are a bit different...

friendly ping 😉

you didn't forget 😄

Indeed you didn't

lol

please also disable streaming encoding, see <https://github.com/libjxl/libjxl/issues/3818>

Trust me to be the one person who didn't ping him after it released xD

can you share the tree for this one?

https://jxl-art.surma.technology/?zcode=dVPLDsIgELzzFfsDJkCR4sWDJ09NEw_9AIstN2Mao38vrUQeMqfuzO7MwtI9uWW092UmwwY3-q_kyrCzddO8fGPmbnSlI3FGFELhww28Ah9g3z_sM6GIdjQUSMTyd1a66kv5Kun-sNCpaPIKaZKSwDUy4SKrMjby-4JfW13sNgOY4cCrAQpx0DBTPy3qIJCP4ijT6LqXPECFRJnavKWq3UCiri3wbtGIWgmc0MtpgxL1kyJ_-JpoPAYYoUdDPxhnlUXxsNturVit-rcjrMxl6-rBkLnkHnFRA_8B

(with wrong dimensions so it at least compiles on the site)

ty

with RCTs that are a multiple of 7, you can permute the R,G,B, so that makes some easy (but somewhat boring) variants. Perhaps there are other RCTs that could also be used but it will be trickier to still have each rgb888 color exactly once

uuuuuuhhh I just noticed https://github.com/veluca93/jxl-art/pull/1

I assume it was from <@265247121261854722>

`Cannot read properties of undefined (reading 'byteLength')`

uhm

available here https://qon.github.io/jxl-art/

on my laptop I like @Qon's interface, on my phone I prefer the old one because I use my phone in portrait mode 🙂

**dogelition** _“Test”_ 2024 image/jxl 111 bytes https://jxl-art.lucaversari.it/?zcode=dVPLDsIgELzzFfsDJkCR4sWDJ09NEw%2F9AIstN2Mao38vrUQeMqfuzO7MwtI9uWW092UmwwY3%2Bq%2FkyrCzddO8fGPmbnSlI3FGFELhww28Ah9g3z%2FsM6GIdjQUSMTyd1a66kv5Kun%2BsNCpaPIKaZKSwDUy4SKrMjby%2B4JfW13sNgOY4cCrAQpx0DBTPy3qIJCP4ijT6LqXPECFRJnavKWq3UCiri3wbtGIWgmc0MtpgxL1kyJ%2F%2BJpoPAYYoUdDPxhnlUXxsNturVit%2BrcjrMxl6%2BrBkLnkHnFRA%2F8B

ok, it seems at least to be working

so, updated to v0.11 🙂

**dogelition, tagged by Tirr** _“ITU-R BT.2111-2 (2K, 10 bit, full range PQ, properly tagged)”_ 2024 image/jxl 235 bytes https://jxl-art.lucaversari.it/?zcode=rVY9c9swDN3xK%2FgHfAeAoCUuHTrkMvXSdMjcS9TEQy69xkPz72s7oj4IQLJ93aT3RD6CeAD0sHvavwTKrcBtt3t%2B2QfiLHDz5%2Bdrd%2Ff2HjZbCRsmgfvukQkx3H2Hr7v9U%2Ff7uAwBdr%2FCc%2FgSmCCE8syH5%2FEtnt5O738P7xKbHhighnGABrDFKTjC7Rw%2BEY8HooYHghQRwib86PYhtexyjHpdz%2BTtfzsBc3K5GMU5QRKBM%2FRd9RK9t3%2BUBswVabrXJzaK9t%2FkKt8ksc43c9T5jhitfKem0WEdia065Ognsm61kK1F6nA0J34e0fMKwvrn16UvpnR2YvvzNy2sqDqaJbVs4%2B28IHq1TLCgZSr1kTUIa%2BpFOZdW83HsDTLx3hHIUXkPZ5s8BO1omsgXD8%2BaQXEximXYiI5hhdAzbKK4YFjKC6Yc681iCTm6ps3seaul1sx0Q1amtyQ6M8TgRtEbBPP0nj9UDxhAqUS%2FBVTIRqIxRKjq4ms5shKx2sQXL9kdCgiX9CBX6frZc%2BGxnUXXNa%2Bzt58uqKpc1Xj5Q0gCdoXPtY25U0YLMawOlaKmSqUn%2FOqaGr%2FqfGgPXsYE5mWdPY5VsEbFmfVWV5uqtVI5s6CW70xfzfUuxsv8bS9y5S%2FcaXF82r8C1d4KHC3zDw%3D%3D

**dogelition** _“Every 8 bit color”_ 2024 image/jxl 135 bytes https://jxl-art.lucaversari.it/?zcode=dZNBDsIgEEX3nGIuYAIUsd24cOWqaeKiB7DYsjOGmHp7aaUBKn%2FV%2BW9mPkPJXKwbzNNNVLPeDv6reKPZ1dhxcr%2BY2Qfd6UycEYVQ%2BHAVc%2BBBdt3LvBNEdKB%2Bp4SO9Z%2BsdjHY9y897Z%2FWKm0afYesk5LAKpmwSFVGIz%2Fu%2BHLUzTgSMIGcKtQAE%2BVJOfAXyAYmgJNsQAPihb8sVWl2qcGJJ%2BCMOPJBj4J4eUoJ3NFDIY584IMAzllhM7xs1ysrVqrelmLzjLlsQb3oM5fcY11NlvIv

nice, can do large images properly now

<@179701849576833024> suggestion: in the embed, use a markdown link (with some fixed short text) to link to the website, to prevent long links from taking up so much space

I don't think the bot has been changed much since the Discord first started, so the markdown probably wasn't even an option back then haha

would also be nice to have proper high bit depth/hdr embeds, though that's not entirely trivial

probably easiest to just use the png encoding code from libjxl for that?

**\_wb\_** _“Every 8 bit color, in a different order”_ 2024 image/jxl 137 bytes https://jxl-art.lucaversari.it/?zcode=dZNBDsIgEEX3nGIuYAIUsd240I2rplGTHsBi250xxOjtpZUGqPxV57%2BZ%2BQwlcxhtZx52oJK1Y%2Be%2BileanczYD%2FYXn49XkoKx8U432hNnRD4ULpzF23Mvm%2BZpXhEi2lC7UkKH%2Bk9SOxms%2B6ee%2Bk9rFTf1rkOWUYlnhYxYoCqhgW9XfDrqYiwJmEBOBWqAifykHPgLZAMTwElWoAHxzF%2BWKje71ODEHXBGHPmgR0E8P6UE7uihEEc%2B8EEA5yyzGU7W85UVy1UvS7F4hlyyoE60iUvqMa8mi%2FkX

I'm wondering if there's something like the XOR pattern (https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTg4uLKTFMI1_ULV7BT0DXkUlAAcv2AfBhXQUFXIVwBxgIqM-ACMYJTc1KTS4DiAA) that could be used to make more interesting-looking all-rgb images

I feel like getting it to be all-rgb would be really hard

**Lonnie** "*Not all-rgb, but looks neat I guess*" 2024 image/jxl 39 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMDTg4uLKTFNIVrBTMAQxwnX9woFsXUMuBQUg1w_Ih3EVFHQVwhVgLKAyAy4QIzg1JzW5BCgOM8eAPHPcixJTMlPzSoBcCg3QNeICAA

The xor pattern itself doesn't have the right histogram to be useful, but maybe there are other such patterns that would work

I'm not touching the embedding code xD

I wonder if there's a way to slice up YCoCg to make an interesting looking all-rgb image.

**\_wb\_** _“Chroma and luma (Rec2100 PQ)”_ 2024 image/jxl 55 bytes https://jxl-art.lucaversari.it/?zcode=i4h04gpKTTYyNDBQCAjk4spMU0hWsFMw4FJQgDINgUwwpxIqDgK6Cn4KuiZwTnBqiYKRgYk5TGkFitJwBVSVukClFhALwnX9woFqdeGW%2BAFFEAIQ3aYIS8OhxoIMyklNLgHKAQA%3D

**Anonymous** _“just a test”_ 2024 image/jxl 73 bytes https://jxl-art.surma.technology/?zcode=dZDBDoIwEETvfMXcDUkrFDyZqDF6wkRNejZQoRc0pjH6924bAi3grft2OzO7ALDVplJP02AVUYXTS6vW3Ix%2BtEgcOe%2BuyCL31Hd8sQYXzJUOlATSrgRiFGB9Re0PtQUbkIPycLTYg%2Fbn5l0Xi0JigeVsZ0%2BvPBSy6mnOpuPSCsWhTm8czgfW%2FE%2FLevNhaXeFJPMXLUfCHeLjCDZyIqYRLspQ4HmesjkVwaZppZcz1OCCRTMS49sVdH4xYSQq%2FGUl%2FY0DQbJWum6MqhDzaGyepPZWPw%3D%3D

**dogelition** _“link test”_ 2024 image/jxl 17 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKz0wB0oZGFlweqZnpGSVgJpeugp%2BCIRcA

chrome didn't take my js override for some reason...

**\_wb\_** _“we need a way to set modular_16_bit_buffer_sufficient=true so this can be 12 bytes”_ 2024 image/jxl 13 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKz0wB0kamZlweqZnpGSUKhkYWXO6JSflFmcUZXBGRTiDslphckl9UrGBiYGmmYGpoBFbvGuCmYMTFpasQnFqiYMAFAA%3D%3D

<@794205442175402004> send a PR 😛

Resolutionarily small

https://github.com/libjxl/libjxl/pull/3824

Where’s the bot code hosted?

<https://github.com/veluca93/jxl-art> everything just runs in the browser, the embed is sent to a discord web hook url

i couldn't get it to build/run locally though due to some weird nodejs related errors, both on windows and wsl2

It probably trying to red the whom

Secrets

seems to be caused by the default stack size being too low, setting `-s TOTAL_STACK=1MB` when linking fixes it

<@179701849576833024>

uh, doesn't even seem that long... can you send a PR? 🙂

i also wanted to try working on getting libjxl to output an icc-tagged png instead of just pixels, but i couldn't figure out how to enable/link libpng and still have a working build

yeah good luck with that xD

the problem is not the length, but the depth

yes, I meant deep xD

the parsing function must be pretty heavy to blow the stack after such a small depth

actually, after checking again, it does work on <https://jxl-art.lucaversari.it> but not on <https://jxl-art.surma.technology>, so that's interesting...

i guess something changed on the bump to v0.11? but on my local build from git head it doesn't work without the increased stack size either

and now my build is back to not working at all for no apparent reason

😭

after looking into it a bit more, emscripten reduced the default stack size from 5 MB to 64 KB in 3.1.27, which is a later version than the one used in the repo. not entirely sure why the other site is affected by it then, but it does explain why i had to change it on my local build (since i'm using the latest version)

i guess the difference could still just be something that changed in v0.11

**\_wb\_** _“Minimalism”_ 2024 image/jxl 22 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMORyT0zKL8oszuByDXBTMOLiykxTCNf20%2FULV7BTMOBSUNBVADJ1DcEs96LElMzUvBIFIwA%3D

**\_wb\_** _“Bruges Lace”_ 2024 image/jxl 24 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMORyT0zKL8oszuByDXBTMOLiykxTCNf20%2FULV7ADchUUdBWATF1DMMu9KDElMzWvRMEIAA%3D%3D

**\_wb\_** _“Checkerboard pattern”_ 2024 image/jxl 20 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQMOTiCs9MATGMLLg8UjPTM0rATK7MNIWa8BoFOwUDLgUFXYXg1BIoKxyoBwA%3D

**\_wb\_** _“I wonder what is the most interesting thing you can do in 20 bytes or less”_ 2024 image/jxl 20 bytes https://jxl-art.lucaversari.it/?zcode=c8osSUktKMlQsOAKz0wB0kamZlweqZnpGSUKhkYWXO6JSflFmcUZXBGRTiDslphckl9UrGBiYGmmYGpoBFbvGuCmYMTFlZmmEO7uoWCnYMClqxAOFAGRuoZcAA%3D%3D

finally got png encoding in wasm working, now i just (?) need to change the ui code to display the png instead of a canvas, and in theory hdr images should then work properly

can confirm that it works, still need to change some things though so that everything works as it should

<@179701849576833024> i opened a pr

i tested it using a bot on my own server, so hopefully everything works as it should

have you also made the zcode into a markdown link or are you keeping it like it is now?

did that too

nice

wouldn't ``` Gaborish XYB XYBFactors 4096 512 256 EPF 2 ``` add more data? or does it allow it to use some default encoding?

Those are defaults for the restoration filter and xyb quant factor fields

For the signaling that is. In modular mode the defaults of libjxl are different.

trying it now 😄

**someone** _“more tests”_ 2024 image/jxl 405 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=7ZdLS8QwEIDv%2BRW5L4G8Jo%2BLIF48ieDB8%2BJWdmEpi4jovzebNm1TTNmYrRRsT%2FP8ppNhWnJ7PO236P6w21X13X5b19URa4QOr%2FgF32CLsHuc8vhWfTDqLBR1uo1VE6s6VlWsQqzKViX4qXrHHKCXmU2GeVcjM8Mvhaey4rDG1cpS%2FbKRwlqT8GTWKMy7Wpna6wxoyX3lNFJaaxqeyhqF0f4wtZhln9ZxzT%2Bugvksua2sPspKTbMTSXGU9zSiUH%2Fxp1o3a92s%2F7xZ11uldVQzj6pkNkvtKauJkkKT5EROHCT6I6ThemX89aoxWh2semCVEKxqYBXBCOF%2B9tXVesAb1yqXzXt8tvaz59l5pBUDDlFAuelKyDwaGdOYBEZVoIlsmjRDHOeGW%2FdRaHH8JxyZwDEe4ZhQQvU4lofbdPKZpYS20KFoLmr0ZtIC87CLhxgfFOGCagDzDQ%3D%3D)

seems to work just fine 😄 thanks!

**dogelition** _“HDR embed test”_ 2024 image/jxl 235 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=rVY9c9swDN3xK%2FgHfAeAoCUuHTrkMvXSdMjcS9TEQy69xkPz72s7oj4IQLJ93aT3RD6CeAD0sHvavwTKrcBtt3t%2B2QfiLHDz5%2Bdrd%2Ff2HjZbCRsmgfvukQkx3H2Hr7v9U%2Ff7uAwBdr%2FCc%2FgSmCCE8syH5%2FEtnt5O738P7xKbHhighnGABrDFKTjC7Rw%2BEY8HooYHghQRwib86PYhtexyjHpdz%2BTtfzsBc3K5GMU5QRKBM%2FRd9RK9t3%2BUBswVabrXJzaK9t%2FkKt8ksc43c9T5jhitfKem0WEdia065Ognsm61kK1F6nA0J34e0fMKwvrn16UvpnR2YvvzNy2sqDqaJbVs4%2B28IHq1TLCgZSr1kTUIa%2BpFOZdW83HsDTLx3hHIUXkPZ5s8BO1omsgXD8%2BaQXEximXYiI5hhdAzbKK4YFjKC6Yc681iCTm6ps3seaul1sx0Q1amtyQ6M8TgRtEbBPP0nj9UDxhAqUS%2FBVTIRqIxRKjq4ms5shKx2sQXL9kdCgiX9CBX6frZc%2BGxnUXXNa%2Bzt58uqKpc1Xj5Q0gCdoXPtY25U0YLMawOlaKmSqUn%2FOqaGr%2FqfGgPXsYE5mWdPY5VsEbFmfVWV5uqtVI5s6CW70xfzfUuxsv8bS9y5S%2FcaXF82r8C1d4KHC3zDw%3D%3D)

nice

works fine on macOS

iOS get WCG but no HDR

don't think if it ever did

does it work when you tap on the image to expand it?

that's what I did, it gets WCG, but not HDR

oh

interesting

seems to be the same on my android phone actually

or wait

it's using the embedded icc profile to tonemap it when it's expanded, i think

if i donwload the image than it shows HDR in the photos app

at least the bars along the top look the same as when i open them in firefox on my pc (looking very white)

what bars?

it's all bars

the ones in the top row, which are the most bright

oh those

this is what it looks like in firefox, for context (tonemapped to narrow gamut SDR by the 3d lut embedded in the icc profile)

works great on chrome with my phone (which has actual HDR support)

nice

white 58% bar looks the same to SDR white

that's what i get on iPhone before clicking on it

is the bottom white rectangle 58%

yep

the huge grey bars are 40%, everything else (with some obvious exceptions) is either 58% or 100%

also, my favorite part of the tree is how the 58% bars are generated from the 100% ones right above by just subtracting from every channel ``` if y > 303 if y > 304 - N 0 - N -430 [...] ```

is it 10bit or 12bit?

10

at 2K resolution in 12 bit, the gradient ends up being 2 steps per pixel since there's not that much space

which kinda defeats the purpose of the higher bit depth

**Access** _“Dutch flag (ish, the colors are probaly off)”_ 2024 image/jxl 37 bytes https://jxl-art.surma.technology/?zcode=80jNTM8oUbC0tOQKz0wpyVAwNDAy4XLKLElJLQDyLLi4MtMUkhXsFHQNuRQUgOxKINvY2BjIgXPNzMzAXLAASK0hlKugoKsQnFoCNNMATQTGh%2FCMTE25kLSjSmJTCpMBAA%3D%3D

that's me!

**\_wb\_** _“somewhat more correct Dutch flag”_ 2024 image/jxl 33 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=80jNTM8oUTAzM%2BMKz0wpyVCwtLTkcsosSUktAHIsuFxSc0oSAxJzUktKUrm4MtMUKhXsFIyMDLkUFKAcExNjIEdBQVchOLVEwdgIiWNoYYEsxQUA)

how

xD

Palette

Default palette colors was a nice touch, gives you `4*4*4+5*5*5` colors to use even when the palette is the empty set

👀 nice

Why 444+555 specifically?

**\_wb\_** _“Delta palette fun”_ 2024 image/jxl 37 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=TcmxCoMwEAbg%2FZ7if4EMiUdIlg5F0FHo4BzIWQ%2BkiNxg374ROjh%2BfKPoezXEGGnWaityzvRUq7I3JOplszKVTcyESBeceICZyWE4SlX5GJy%2F4tsiBE%2FAH8xdA%2BDwEkMXbvAp3Yt%2B)

4\*4\*4+5\*5\*5

I think discord formatting broke their message

Layout was messed up with the multiplication signs

Lol I love it

the delta-palette-prism

**CrushedAsian255** _“Error: Calibrate printer before continuing”_ 2024 image/jxl 42 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=TcmxCoQwEIThfp9iXiBg4hKSxkIsrjqEK6wF9y6BFBZbeG9%2Fi5xgNfPxP6R%2BiiLGSEvdtCDnTGPVTXZDokmarvPaRFWI6hsHBjDzdVPXkcNzgfO251j5WgnBE%2FAHc28AHF6i6MMNPqV7oh8%3D)

It's first a cube of 4x4x4 colors that sits inside the RGB cube, followed by a cube of 5x5x5 colors. Those are default palette colors that come after the custom palette colors.

so a total of 189

Negative indices correspond to default delta entries, where -1 means "use the prediction as is" and more negative means "take the prediction and change some or all of the RGB values a bit"

**CrushedAsian255** _“Default palette”_ 2024 image/jxl 23 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=80jNTM8oUTC0sOQKz0wpyVAwMjDgcsosSUktAHIsuFxSc0oSAxJzUktKUrky0xQqFewUDLh0FfwUtA2BVHBqiYIBAA%3D%3D)

Probably we should add some way to change the predictor used for Delta palette (currently it uses the default which is AvgAll iirc)

iirc, the "prediction" you're talking about is a fixed predictor in the header?

Yeah it is signaled as part of the modular transform info for the Palette transform

**CrushedAsian255** _“Shattered palette”_ 2024 image/jxl 31 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=80jNTM8oUTC0sOQKz0wpyVAwMjDgcsosSUktAHIsuFxSc0oSAxJzUktKUrky0xQqFOwUDIFKdBXcixJTMlPzShR0DQ1AMpVAGZC4n4K2IZAKTi1RMAAA)

this delta palette is too much fun

**CrushedAsian255** _“something”_ 2024 image/jxl 42 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=80jNTM8oUTA1NOIKz0wpyQCznDJLUlILgBwLLpfUnJLEgMSc1JKSVK7MNIUKBTsFI1MDELMSytRVcC9KTMlMzStR0DVB4RnC1SE0GIA0OJalO%2BbkKGgbAdl%2BCtqGINlwuGxwaokCirHahgA%3D)

the 5x5x5 cube is slightly bigger in RGB, the 4x4x4 cube fits perfectly inside it in the 'holes' of the grid

in my experiments the last predictor is the best for delta palette -- I added it only to get the max performance out of the delta palette

0, 0.33, 0.66, 1 -0.16, 0.16, 0.5, 0.83, 1.16 ?

with two cubes interleaved the expected distance to a palette color is smaller than with a single cube, i.e., color precision is slightly higher

I anticipate interesting stuff to emerge when delta palette is combined with LZ77ish and context trees

it should be possible to create context tree sprites

first cube is 1/8, 3/8, 5/8, 7/8; second cube is 0, 1/4, 2/4, 3/4, 1, if I'm not mistaken

yes

makes me wonder if there is a "geological" name for such interleaved cube crystal structures

"Body-centered cubic" perhaps

yeah

i think

it's like an interstitial alloy

but for colours

it is a crystallized thought about color, literally

I designed it 😄

initially I had 6x6x6 cube, interleaved with 5x5x5 -- but 5x5x5 with 4x4x4 was better after all from my opinion

from performance? or just was nicer?

You added AvgAll just for delta palette? I'm surprised, but shouldn't be, given what it will be capable of with time. Shame the command is still broken in cjxl

average4 -- https://github.com/libjxl/libjxl/blob/main/lib/jxl/modular/options.h#L35

return (6 * top - 2 * toptop + 7 * left + 1 * leftleft + 1 * toprightright + 3 * topright + 8) / 16;

I derived the numbers experimentally, with some inspiration from extrapolative interpolation

this worked the best for pnorm * bpp metric (butteraugli/density)

Ahh, so that's why it's called `toptop predictive average` in the cjxl help

it's the only predictor that goes as far as toptop and toprightright (besides the self-correcting one which indirectly uses that information too)

ah experiments, that's why the weights look so arbitrary

predicting from past samples is quite asymmetric possibly because in x-direction we have samples from both directions, but in y-direction only one direction

This all goes way over my head but it sounds super interesting nonetheless

**Access** _“Stripes of Order in a Sea of Chaotic Clown Vomit”_ 2024 image/jxl 26 bytes [source tree](https://jxl-art.lucaversari.it/?zcode=80jNTM8oUTAzM%2BMKz0wpyVCwtLTkcsosSUktAHIsuFxSc0oSAxJzUktKUrm4dBXcixJTMlPzShR0DY1NzcwsjC25AA%3D%3D)

I remember seeing a Mastodon bot that generated random computational art like this, I don't think it was JPEG XL but you could probably create a bot that creates random valid JXL files

~~aka fuzzer inputs~~

FLIF was designed without any error detection mechanism since my philosophy back then was that no bit should be wasted, so every bitstream that doesn't decode is a bug in the design since it means _something_ is redundant

so you can in principle just create random FLIF files and see what they decode to

in JXL there's a little error detection so not everything will be a valid bitstream

but still, you should be able to take some small jxlart file and randomly flip bits, not everything will decode but some of it will

That's interesting. I like the approach of WebAssembly, which is not to encode error correction into the file itself but the file must follow a relatively easy to verify structure, and runtimes will always verify a Wasm module before it is run. This allows you to move validation out of the hot code and you only need to care about the happy path, such that invalid Wasm could trigger undefined behavior in your runtime, but since it's validated for correctness prior, that still can't happen

then you can decode to png and sort by filesize. The very small PNG files will be boring (just solid colors or repetitive patterns), but the larger ones could be interesting 🙂

I've seen many of your generation loss videos, It'd be cool to see a similar thing where more and more bits are randomly flipped in images in different formats to see what they turn into or what happens over time (maybe ignoring necessary headers because that would probably immediately prevent them from being decoded)

I might see if I can do something like that at least for JXL, I bet there's already software designed to simulate bit rot on files

we don't yet have a mode in libjxl to ignore corruption and decode anyway

in most other codecs you'll have the same problem, they'll refuse to decode when they detect corruption

but default vardct jxl should behave quite nicely in this way, if you have a decoder that ignores corrupt sections

Ah so the error correction in JXL extends to the FLIF (FUIF?) part as well?

Part of me knows it would be a lot cooler if in stead of "this image was missing or corrupted" we got some cool ass corruptions everywhere, modern errors are so boring... but it's probably for the best

there is no error correction, there is little amount of error detection: at the end of an ANS stream (and there is typically one such stream per section of the bitstream) the final ANS state acts like a CRC

Gotcha