JPEG XL

25941 snake spline points, 28289 bytes

10293 snake spline points, 29764 bytes

Why does the file size increase?

Points are delta encoded

And then ANS encoded, all in the same ctx, iirc

hybriduint means small values can get good entropy coding, large values have bits signaled raw

that's fun

Are that splines in the qr code, <@288069412857315328> ?

yes

Challenge: do an artistic qr code in 128 bytes (likely without splines)

8x upsampling might give interesting results

i tried with a tree. it's always worse than cjxl on a png

with a lower limit ~ 400 bytes

here's "128 bytes" in 128 bytes `cjxl -m -g 0 -I 1 -e 9 -P 7 --override_bitdepth 10 --patches=0`

created from a 8x smaller png with `cjxl -q 100 --resampling 8 --already_downsampled --override_bitdepth 1 -s 9 -R 1 --patches 0 -I 1 -P 3`

These are *really* small files

how does this work?

By context meta prediction

Basically you specify bitdepth with a tool like the one you can build with libjxl or the site surmajxlart .web.technology

He's the dev of squoosh.app

If you have any question there is a guide in the same site you write Discord when you're posting the image and publish the jxl

And in Channel <#824000991891554375> will show a preview in jpg

And a link with the hash like

The meaning of compo for jon sneyers Is that

Competition

Wondering about the choice of splnes. While I think it's definitely not bad (definitely better than the standard but unintuitive beziers!), why not something that's even better: Ralph Leviens spline: https://spline.technology/ Demo: https://spline.technology/demo/ Blogpost: https://raphlinus.github.io/curves/2018/12/21/new-spline.html It's a combination of his earlier spiro curve implemented in inkscape among others, and κ-Curves used in Adobe Illustrator curvature tool

I think the best thing to have for splines in jpeg XXL is to have floating point control points

Is XXL the next-next codec? 😋

Heh no, no plans for that yet

I doubt there will be a jpeg XXL, I think/hoping if jxl can last long enough to be eventually replaced by neural codecs that directly stimulate your brain instead of bothering with pixels and displays

Would 1/8 pixel precision be enough? Because maybe we can still make that work, we still have to resolve something unclear in the spec regarding the interaction between upsampling and splines, and if we make it so that upsampling is done first and splines are interpreted in the upsampled coords, effectively you get up to 1/8 pixel precision

yeah 1/8 sounds good

although it sounds kind of superfluous since the same result can be gotten effectively by multiplying the coordinates by 8 beforehand

and in both solutions it would make the image 8x larger which is kinda much

Yes, I guess

In principle we could optimize the upsampling away if the image is to be rendered at a lower resolution, but I doubt that will happen in practice

However, as real-world experience shows, there are usually things that couldn't have been predicted at the design stage And understanding what can be improved, added or changed will only come after the format has been in practice for a long time, and most likely a new format every 10 years will be practically better than a format that was planned 30 years or more in advance Because requirements may change unpredictably, new research and more efficient algorithms may appear in the meantime, old patents may expire, etc It would be interesting to use some draft format in some limited application for some time, like 2-3 years and only then release all corrections and improvements that became clear after such practical use, although this is not always easy for many reasons However, there have been cases like this, even WebP was used for a while (e.g. in Opera for Turbo mode) and changed for the first couple of years, also the incoming HTTP/3, which is based on QUIC 2012, which has been improved and changed mostly only on Google services

**\_wb\_** _“Subsample This Chroma, Biatch!”_ 2021 image/jxl 33 bytes https://jxl-art.surma.technology/?zcode=C3IOUTDgcsosSUktKMlQsOAKLixNTa1K5QoCS3BlpikkK9gpGFtwKSgA2QFFqWWuRUVAEQOggIKCrkI4lAWUrIQLg7k14TVIAiC1fkg8oAI%2FFGmQguDUEiwiRqamXOgqYCwA

This one gives funky aliasing/downsampling artifacts when I zoom in and out on the image in the online editor

Looks very different at the pixel level than zoomed out

An idea to keep your JXL-art master pieces forever => record them as NFT and copy the base64 bytestream in the description. e.g. https://artion.io/explore/0x61af4d29f672e27a097291f72fc571304bc93521/212

September ends today! Time to submit your entries for <#882173948534603806> , <#882174149374672896> or <#882174448478863370> !

*didn't it already end*

https://tenor.com/view/shh-secret-chris-pratt-silence-dont-say-gif-17543341

Another hour and 20 minutes of September where I am.

*I was referring to the end of the submission period*

september busy times + no submissions :(

Anyway, if it's going to end at about the time it ended last month, I'll see about submitting something after work--just because Jon is persistent.

**Retr0id** _“lossless”_ 2021 image/jxl 86 bytes https://jxl-art.surma.technology/?zcode=rVI7FsIwDNtzCl%2BA95qf4y4MXIErUB7dGDLA7YG%2BNE0TUTrQTZLtWLVOY7wM93gjrdR4pScdyfWsiBLwRt5ggo%2BsFcSsFxR3XabynMBSkJmWVe3nO9B5iIRZXY%2BYnmOuimehl0r4Nh3PR9U1s%2B4DXuuGtJv2TjULa2Fk0BqPDVof%2Fm4QVZZVi1oloskDOA88TCLFBmReuN8VkPTrrbid1rfMg%2Fwaz%2BrXUByOGZcdTQpAAkBy2kW2j7WgFw%3D%3D

Last chance to vote for the September jxl art compo! <#882173948534603806> <#882174149374672896> <#882174448478863370>

Good luck, all.

Congrats <@288069412857315328> and <@193530557026533376> !

<:FeelsWeirdMan:666827205308842008>

What should we do for the October compo?

How to get more participation?

What categories should we have?

**\_wb\_** _“I have no idea what is going on here”_ 2021 image/jxl 26 bytes https://jxl-art.surma.technology/?zcode=C3IOUTDkcsosSUktKMlQsOAKLixNTa1K5eLKTFOoCa9RsANKKyjoKgSn5qQmlyjoQnjhqZnpGSWpKUBJAA%3D%3D

32-bytes is a nice category I think, it's limited in what you can do (no splines for example) but there do seem to be things there left to be explored

Not sure about 128 and 1024

Maybe better have 64 and 256?

Or just do 32 and 'no limit' (though of course smaller is always more impressive)

?

i think that's better at least

More participation? Maybe Discord is not the best place to host because it's not public. The JXL subreddit seems a simple alternative. Regardless, it will take time to build interest.

The discord is kind of public, the invite link is right on jpegxl.info and other public places

But yes, maybe not so easy to find

Yeah, anyone can join, but the content is not posted publicly.

So by default you have less eyeball potential.

On reddit it's not really possible to reply with images, right?

As for categories, I'm a fan of less restriction. IMO, that makes it easier to make more intentional art. The smallest stuff tends toward discovery more than intention.

Yes, less restriction allows more artistic expression

Oh, not directly, I guess (I'm not really a user myself). But you can link to Imgur or another image sharing site.

More restriction results another kind of creativity, indeed more about discovery and finding/engineering ways to shave off bytes. I think it's good to have both

Like the traditional 4kb intros, 64kb demos, and unrestricted demos.

To raise interest, I once suggested adding more impressive examples and a brief description of the features and how it is made, here: <https://www.pouet.net/topic.php?which=12091> and perhaps to some other demo-maker communities, then perhaps more interested people will join

In 64kb of jxl I suppose you could make a (visual only) demo

I think one tiny category and one unrestricted category makes sense for now.

Unrestricted also just means easier to get into.

Maybe bump up the tiny category to some other number of bytes?

64 bytes maybe

Or 42

I'd lean toward 64. Again, it's at least some room for design complexity.

But this can change between compos of course as the realm of possibility is explored.

I wonder when we're going to start to explore VarDCT jxlart 😅

all_default headers are vardct, so that's a small advantage there

linking to Surma's thing should work (duh)

Only hiccup is animation

Yes, but scrolling through an art thread and having to click on everything to see a preview is not so nice

Mm, valid.

Well, Discord is very convenient in that respect. Maybe accept submissions from both places.

Yes, maybe we need a version of <@228116142185512960> 's tool that just lets the browser decode the jxl (which only works if the flag is enabled, but it would make animation work without effort)

Or someone suggest another popular, free platform.

It's possible, like here <https://www.reddit.com/r/pics/>, and I think it's easier to put a picture and for example a link to jxl-art.surma.technology in the first comment

A post can have a picture, but a comment cannot

So you would need one post per entry, which is maybe a bit much

*maybe*

Then again, we can use https://www.reddit.com/r/jxlart/ for it

In order not to spam the main jxl reddit

Lol, there's actually already a sub. Yes, this would be ideal if you do the post=submission thing. Then need some flair or tag (or whatever the lingo is) for users to mark their post as an entry for that month's compo, so it's easy to find them all.

And this mitigates some bias in the reddit algorithm where a popular comment with a large comment thread can push less popular comments way down the page. Having seperate posts levels things a bit. (not that we'd likely run into that phenomenon any time soon)

**simnalamburt** _“Hi!”_ 2021 image/jxl 135 bytes https://jxl-art.surma.technology/?zcode=C89MKclQMDQwMODySM1MzyiBsIMLcjLzUgNLE%2FNKMqsSSzLz8xxTskqLS3JT80oUjGDyXApg1QYKFMFBZoqJAggYAiElphgBXQLEUJYFnGUKZpmgsIzgLJA617wUaOiOhjIhU8yALjExhbFGQ4%2F00DM2gLOMRkOPFFPMTWE51wLBArrO3ABZdjREiTcFHHoWMBZabtZVCE4tUTAz4QIA

Hi!

👋

cross posting to the sizecoding discord might gather some attention

(I am interested in participating in future competitions but am currently swamped with work)

**monad** _“I've never tried the publish thing before”_ 2021 image/jxl 572 bytes https://jxl-art.surma.technology/?zcode=lZnNahxHFEb38xT3BQbq%2FtTfJpBAICsTyGLWxlYiQRbGiJC8fdqxxjPSd7zIarqrThejo7s49Pz09Pzx4dPzo%2Fnp8vTx%2BNxrnn55ePrj8dlq1%2BnHPz89vj89%2FW4f7AeLk9lx%2Bevnh7%2BOuzzuzM7228OztdP1yr%2FA%2Fxzb7Sv893G5V79j67bR%2Fls%2Bbt69nP6a%2Brp1OX%2FZ9e%2Fsnt%2F9fOyerw%2B%2FnNVebu9POPu3xftH293q7Y94u%2FL6QH3yLfX6nNuXoHPO%2Fr8OkodeI%2FcH3GRdr44DLufL5e3%2Fp66P3Zb87tzr4tzCzSTOhRsLuDGUa8D1JVwP4ppwNYGrLlxu4HIqV8SFcDGAC%2FXs5MXVi5NnV8%2BtA9fyLbc2eFm7KxfEiee1wMta4mVN8LzmVA7mbw2ZvzWSOPGyOnhefSgH87dK5m9VJ049J3lO9RzkJdRLkOdQzw7zt1zmbzXy0tRLI89NPM8NXuZO5cDzXOJ5riBO5m9O8DKneJkDPM8xlYP5m13mb%2FYkTr0UeJ41lCMvqV6SPKd6Dpi%2FGTJ%2F08mLqxcnz66eG8zfbKUceB5bPI%2BdxInnscDLWKkceB5TPI8ZxMn8jQFexhAvo4Pn0ady5KXUSw3ixPNImL%2BRQznyEuolyHOoZ4f5G96VI8%2Bunht5buK5b%2FDSdykHnvsSz30lcTJ%2FfYKXPlM58NyHeO4jiBMvvYPn3sVzL5i%2FXlM58pLqJclzqueA%2BesxlCMvrl6cPLt6buSlqZdGnpt4rg3zV1vmrxZ4Ke3sos4u7eyizi7t7KLOLu3sos4u7eyizi7t7KLOLu3sos4u7exK8hLqhTq7tLOLOru0s4s6u7Szizq7tLOTOju1s5M6O7Wzkzo7tbNzgpecpRx4Tu3spM5O7eykzk7t7KTOTu3sLPJS6oU6O7Wzkzo7tbOTOju1s5M6O7Wzkzo7tbOTOju1s4M6O7SzY4GXWF25IE48B3V2aGcHdXZoZwd1dmhnB3V2aGcHdXZoZwd1dmhnB3V2aGcHdXZoZwd1dmhnB3V2aGcHdXZoZ%2FsGL76HckmceHbqbNfOdups18526mzXznbqbNfOdups18526mzXzvYiL6VeqLNdO9ups10726mzXTvbqbNdO9sbeWnqhTrbtbONOtu0s40627SzjTrbtLONOtu0s40627SzjTrbtLOPMAauqxfqbNPONups08426mzTzjbqbNPONups08426mzTzj5EA2e3%2BYN37Hc%2FAtxeS7%2B819afFa6f%2FwI%3D

<@!489921999120891904> RE: https://discord.com/channels/794206087879852103/794206087879852106/894999740075343873

``` B encoder 19601 pingo -s9 18730 cwebp -z 9 1609 cjxl -d 0 -e 9 -E 3 -I 1 -g 3 572 jxl_from_tree (handwritten MA tree) 215238 Chrome JPEG (lossy preview)```

I'd be curious to see the difference between the hand-written tree and the computed one...

awesome <:BlobYay:806132268186861619>, thank you 😊 !

The computed one does not use offsets, right? So all nodes are +0...

computed:

note that of course in non jxl_from_tree cases, residuals do not have to be all-zeroes

for that first row case, it would be nice if we could add syntax to jxl_from_tree to write a repeating sequence of residuals

so that you can basically have for the y==0 case something like `- Set Repeat { 1 0 1 1 0 1 0 1 1 0 1 1 0 1 0 1 1 0 }`

interesting...

The tree is allowed to reference residuals? Sounds funky. Syntax for that might be useful in some cases. In the case above, you'd need 610 pixels to tile the row--so it wouldn't really be less writing effort and I'd be surprised if it compressed better.

It will certainly compress better than making almost as many tree nodes as pixels

But in particular, residuals can use lz77 so in a case like this where they are repetitive, you would only encode 18 values and the rest of the row would be a lz77 at distance 18 of length 592

If you could just LZ77 the whole row, that should compress well. But I think I wasn't clear: the 18 pixel example you gave does not repeat across the row. The row is 987 pixels wide and you'd need to encode the first 610 values to naively match the rest of the row.

Ah, well you can just lz77 the whole row and then go back to the MA tree (you would just have - Set 0 for the first row, and encode residuals with lz77)

was curious and got this down to 176 bytes with cjxl 👍

<@!415302089523331092> Well, share the parameters! I had noticed adding `--override_bitdepth 1` to the command I posted helped a lot, but only down to about 1KB.

``-d 0 -g 3 -e 9 -P 8 --override_bitdepth=1 --patches=0``

P8, eh

I've had an idea since yesterday to make the jxl_from_tree version smaller, which I wanted to try today, but it wouldn't have been that small.

how did you get the tree for this?

Compile and run benchmark_xl with `kPrintTree = true` in `enc_encoding.cc`. Might also need `kWantDebug = true`, I just flipped both without investigating.

All I had to go on to find that was this comment: https://discord.com/channels/794206087879852103/803663417881395200/832486352075358251

neat,

adding some option to have nonzero residuals in jxl_from_tree could be interesting. E.g. if you can specify that the residuals are 0, 1, 0, 1, 0, 1 repeating

Then it would also be useful to expose the multiplier in tree nodes

Something like `- W 5` actually means "set pixel to W + 5 + 1 * residual"

Currently it just sets all residuals to zero, which compresses very well, but something like a short repeating sequence would also compress very well

And the multiplier can be any positive integer (it's how we do quantization in lossy modular)

**\_wb\_** _“Progress Pride Flag”_ 2021 image/jxl 131 bytes https://jxl-art.surma.technology/?zcode=hVFBCoMwELzvK%2FYDQrIm2lOhLYUeioe24FmqrUKhQnNof1%2BjSdRIMJddJrObyczlcEMO%2B0aVVatqjCFvyq5yRgJOVfOsFUpOsHu1dQHZW52LjwJoHnjHLRJGeK0Uphr4dcBG2o6nzLYkHRoLhwqSdg1D03CzL0pMw0ylIJX5I2GqvzQOMmNvQq4%2Bb5ki%2FCfyqARTgyLMjtib89XT9orpi7wrznJLoS4VowEmKczEWa4gwP44cUYCjrjmcUoXxg%2BECPNh3aDBi12Mprv8aSlnKmtmjXQ%2Bez9ZjzuBPw%3D%3D

**\_wb\_** _“Belgian flag”_ 2021 image/jxl 32 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOQKz0wB0uZmFlweqZnpGSUKpoZGXFyZaQrJCnZAaQUFXYXg1BIFAyALKFgBFDQyNQVywFyQGgMwBy5ramgIFUDWisyHySPzYCoB

**\_wb\_** _“French flag”_ 2021 image/jxl 33 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOQKz0wB0uZmFlweqZnpGSUKpoZGXFyZaQoVCnYKRqamXAoKUI6poSGQA%2BYmA7kGYI6Cgq5CcGoJGg%2BiEMGGakEXRmgGAA%3D%3D

**\_wb\_** _“Italian flag”_ 2021 image/jxl 35 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOIKz0wB0uZmFlweqZnpGSUKpoZGXFyZaQoVCnYKRqamXAoKUI6poSGQA%2BYmA7kGYI6Cgq5CcGoJGs%2BYC5UN1WLIha4Bq1lGaCYDAA%3D%3D

**\_wb\_** _“Swiss flag”_ 2021 image/jxl 55 bytes https://jxl-art.surma.technology/?zcode=fU4rEoAgFOycYi%2FgDG%2F8jMlgshs8gKDSDAS9vegIIoKJ%2FbFvW6WFXPUCYoMS5q05Z51U86IvyNSEEQ04AwzcDaTyJI5WNwUy9FLDMmNvLzsMuAh5EScWdeGJ7loof0tf8ZyqwLAfKKHz8OoWrYmXJEemZv4OTU%2BN1fnKg23DAQ%3D%3D

**mmmnad** _“_"This piece is thusly __christened___ I've never tried the `_“${title.value}”_` thing before 2: Episode II: **attack** of the welp, I tried <:PepeHands:808829977608323112> _ ... guess that's enough ||<:BanHammer:805396864639565834>:computer:|| for tonight <https://youtu.be/dQw4w9WgXcQ>"_”_ 2021 image/jxl 201 bytes https://jxl-art.surma.technology/?zcode=lZVNSwMxEIbv%2BRX5A4F8f1wEBcXTUvCQc7GrXahY6iL670232SabfXvw1MnMM0M672T2YRh3%2FXHcU0HisEu%2FwTvy3A%2Fv%2B5Hq4Mj94bjfkqfT9qPffH5RTpkiwxt9pXdUEkqTuTn13%2Bmk0olSRl%2F6kXIyW%2BIM%2F%2BZwMn%2BSGbypWF0CfHKnQ5erL6lLKLJzVNyIsu4xRdmcnGvxfKwrMHF11qm88pY%2F0XqWBdeZLbWsUy6B6jDxr0KrpCVSFyjNmq0sTlYyshgXMrBu6rXWoFhurdASulVYXOTqdpgWkJYB0tJiWkNaeEgLi2kOae4hzQ2mFaKDQ3AwkJWQ5Yj1GrEe6uJg6xzsnIOiWKiJVZAViDWwaQb2zEA5NFRDw55p2DMFtVBQCwlHWcJJlniQ8RzjMYZawBm24HULsE7zu2a3d4JYL%2BxcKE5XUis2FpITsFfXe%2FGSzeZt0n4ppkD5Qlzjs6uahOzywbaU57alnJEtZa1sKVNJlF3KlXc1h%2F4A

welp, I tried

😮 that is still pretty good

I wonder how long it would take to "brute force" a solution to these types of images

Too long, especially if you want something small. Clever search is best.

i'm so happy i got this ball rolling. thanks you guys! :) <@!263300458888691714> <@!415302089523331092>

and those flags are a good cool too. gives me a bit better an idea of of that code works <@!794205442175402004> :)

if you want more CAs of the sort. rule 105 is cool because it kinda brings out a "character" of it's starting sequence. thue-morse: https://opensofias.github.io/celluloid/#amount:1,page:105,neighbors:3,radix:2,seed:'tm10',zoom:1 dragon curve sequence (aka paperfolding sequence): https://opensofias.github.io/celluloid/#amount:1,page:105,neighbors:3,radix:2,seed:'dc10',zoom:1

i also made some illustrations about some of those bounded, highly regular but non-periodic sequences, maybe that helps with coding them: https://commons.wikimedia.org/wiki/User:Opensofias#sequences (dragon curve is still missing, i should do that some time)

That first one is cool 😮

'Fake sky with fake rainbow' 119 bytes

https://jxl-art.surma.technology/?zcode=7ZRPSwMxEMXv8ynmLpHJ7mYbL0KVak_1T4U9Lya2EZuWNhX10ztJ0y0IPdXDIpLL483LLPsjvMaZMEdJRQVj62bzsNMwXb05bx-2rQ_uqw1u6YfmdbsJC-sDUh4DokQ65fAG6sEGffKGiojJqSgvWNaFymZBBCNvMrBf5Cb_BLdSd9y0VplbNI9wo39uO271gdtg_96ieYzbedmD_5Z9IFcdyKnuxVU_ycHNul3Y--WGr4lC1XC3dtx9qQpxAI_XTyjhygVjV6lAwb3gM16yKXBqY0dmI4mPJAQ2KPYBJWWcfPJEpUxzO86p4ftscjZpsOz0CEWZMpzQRN03eGNqbWtQwTc

i will add that i found a small change makes it a bit smaller, and also seems to work better on these types of images generally ``-m -g 3 -e 9 -P 8 -I 1 --override_bitdepth=1 --patches=0 --palette=3`` (not sure if i should put this in encode params but oh well)

Would anyone participate in an October jxl art compo? Two categories? max 64 bytes, unrestricted?

Sure, man, I'll commit to making some more bad stuff and feign it has any relation to the ancient tradition of art.

64-byte <#824000991891554375> entries go here, before end of October

Unrestricted <#824000991891554375> entries go here

> of course a 1 MB jxl is not going to be impressive sounds like a challenge

I mean just drawing something in Gimp and saving it as jxl is not really impressive

**_wb_** _“The Sunset That Didn't Fit In 64 Bytes”_ 2021 image/jxl 66 bytes https://jxl-art.surma.technology/?zcode=zZE7C8IwGEX3%2FIpvl0DSh3YSqlQ71SdkLia2EZuWNhX115vGqh3cXCQQTj4ON%2BSGSa5zoMTxUCxklusno111lkps2lRpeU%2B1LFXIT22jC6E04KGDAKgTAPllmYyx93OE6%2FxDhEMIBORDPooU76tCizotxLpsrLuqpWnTlgsBYt9%2FYjvfA%2FXRTGouKisgeYQDTMHC1QIGBtTumHbTm5nSSUdsGfdGeMmSUcLAfXME2LXOK8NeKzhgf3jyzWMe

https://twitter.com/sizenewxyz/status/1449698338790645761?t=LDcEE_NHSz86oVvFrKev7g&s=19

Does anyone know who made that?

That's afaik the first jxlart that was sold?

oh, that's an NFT <:monkaMega:809252622900789269><:NotLikeThis:805132742819053610><:tfw:843857104439607327>

sadly there is no link to the codestream of the Jxl, so we don't know if some post-processing after jxl decoding is done or not, so we cannot authenfify real jxl :p

<@456226577798135808> I put your winning piece on the title slide for the jxl AhG report 🙂

I'm very proud !

Very nice.

yes but since the beginning, some NFT can give you some power in games, can interact which each others (NFT of a cryptokitty can do babies with another cryptokitty), can give you access to a concert (like a ticket), etc. 🙂

why do you need nfts do do those things

i think it would be really funny if zou ended up on a slide

because then the ownership of the NFT is secure by the blockchain (e.g. ethereum) and not by a central entity like a game company, a bank, etc. I know that for small applications like games and concert it is not really needed...

For what is needed, the world is based on the respect of the private proprierty, no one can private you off something you have buy without face legal consequence... at the same time without a similiar legal autority someone can say that your nft is not valid... nft not fix anything

I hand-decoded a jxl art file

``` RCT 15 if PrevAbsErr > 0 - AvgAll -4 if y > 0 if |W| > 0 - N 0 if N > 0 - Set 0 - Set 255 - Set 0 ```

this one

These are the compressed bytes: ``` ff 0a fa 1f 01 91 08 06 01 00 50 00 4b 38 41 e6 4d 75 fc 86 b5 93 2a 20 d0 01 de 1f 49 c2 01 5c ```

Here is an annotated hand decode

``` FF 11111111 | Signature 0A 00001010 | // Size header FA 0 not small 01 read height as u(13)+1 11111 1F 00011111 u(13) is 1023, so height is 1024 01 001 ratio is 1, so width = height // Image header 0 image header is not all_default 0 no extra fields 0 bitdepth: integer 00 8-bit samples 91 1 16-bit buffers are OK 00 no extra channels 0 not XYB 1 color encoding is all_default (sRGB) 00 no extensions 1 default transforms // Frame header 08 0 frame header is not all_default 00 frame is kRegularFrame 1 encoding is kModular 00 flags are default 0 not YCbCr 0 06 0 upsampling factor 1 11 group size shift 3, so groups are 1024x1024 00 one pass (not progressive) 0 not cropped 00 kReplace blend mode 01 1 is last frame 00 no name (name length zero) 0 restoration filter is not all_default 0 no Gabor-like transform 00 zero EPF iterations 0 00 0 no restoration filter extensions 00 no frame header extensions 00000 padding ```

``` // TOC 50 00 read first and only group size as u(10) 010100 00 0000 first group is 20 bytes long 0000 padding // LfGlobal 4b 1 default LF dequant 1 decode global MA tree 0 lz77 disabled 1 simple clustering 00 zero bits per entry (all contexts in single cluster) 1 use prefix code (log alpha size 15) // hybriduintconfig 0 38 000 split_exp is 0, msb is 0, lsb is 0 1 computing symbol count 0011 n is 3 41 001 symbol count is 1 + 8 + 1 = 10 00 no skipping // code length code lengths 010 E6 0 code 2={2,3}, eating 2 bits, value of clcl[1] is 3, space -= 4 (28) 11 code 12={2,0}, eating 2 bits, value of clcl[2] is 0 00 code 3={3,2}, eating 3 bits, value of clcl[3] is 2, space -= 8 (20) 111 code 14={2,3}, eating 2 bits, value of clcl[4] is 3, space -= 4 (16) 4D 01 code 7={4,1}, eating 4 bits, value of clcl[0] is 1, space -= 16 (0), done // code lengths 10011 code 19 = {3,1}, eating 3 bits, cl[0] = 1 0 75 01 code 10 = {1,0}, eating 1 bit, cl[1] = 0 1 code 21 = {2,3}, eating 2 bits, cl[2] = 3 10 code 21 = {2,3}, eating 2 bits, cl[3] = 3 11 code 29 = {2,3}, eating 2 bis, cl[4] = 3 0 FC 0 code 7 = {3,4}, eating 3 bits, cl[5] = 4 110 code 24 = {1,0}, eating 1 bit, cl[6] = 0 1 code 28 = {1,0}, eating 1 bit, cl[7] = 0 1 code 30 = {1,0}, eating 1 bit, cl[8] = 0 1 code 31 = {3,4}, eating 3 bits, cl[9] = 4 ```

``` // start of MA tree decoding 111 86 0 token is (prefix coded) 5, so property is 0b10000 + u(4) 0011 property is 19-1 = 18 = PrevAbsErr 0 token is 0, so splitval is 0, so first node is "if PrevAbsErr > 0" 0 token is 0, so property is 0-1 so leaf node 1 B5 01 token is 4, result is 0b1000 + u(3) 101 predictor is 13 (AvgAll) 101 token is 3, result is 0b100 + u(2) 93 11 uoffset is 7, signed offset is -4 0 mul_log is 0 0 multiplier is 1; leaf node is "AvgAll - 4" 001 token is 2, property is 0b10 + u(1) 1 property is 3-1 = 2 = y 2A 0 token is 0, so splitval is 0, so node is "if y > 0" 101 token is 3, so property is 0b100 + u(2) 10 property is 6-1 = 5 = |W| 0 splitval is 0, so node is "if |W| > 0" 0 property is 0-1 so leaf node 20 0 predictor 0 (Set) 0 offset 0 00 multiplier 1, so leaf node is "Set 0" 0 property is 0-1 so leaf node 001 token is 2 so predictor is 0b10 + u(1) D0 0 predictor is 2 (N) 000 offset 0, multiplier 1, so leaf node is "N 0" 101 token 3, so property is 0b100 + u(2) 1 01 1 property is 7-1 = 6 = N 0 splitval 0, so node is "if N > 0" 0 property is 0-1 so leaf node 0 predictor is 0 (Set) 000 offset 0, multiplier 1, so leaf node is "Set 0" 0 leaf node DE 0 predictor is 0 (Set) 1111 token is 9 so uoffset is 0b100000000 + u(8) 110 1F 11111 uoffset is 510, so offset is 255 00 multiplier 1, so leaf node is "Set 255" ```

``` // MA tree decoded, start of modular image decoding 0 lz77 disabled 49 1 simple clustering 00 zero bits per entry (all contexts in single cluster) 1 use prefix code (log alpha size 15) 0100 split_exp is 4 C2 010 msb_in_token is 2 00 lsb_in_token is 0 0 symbol count is 1 // Modular header 1 use global tree 1 default WP params 01 01 nb_transforms is 1 00 transform is RCT 00 begin_c is u(3) 00 5C 0 begin_c is 0 10 rct_type is 2 + u(4) 1011 rct_type is 13 (same as RCT 15 in jxl_from_tree) // Modular channel data: read 0 bits for every sample 0 padding ```

spent about 4 hours on that, haha

Pretty cool to what extent it is really a bitstream and not a bytestream. So many things are encoded with 0, 1 or 2 bits...

32 bytes are 256 bits, so I guess this could become a 16x16 matrix of bits. Will be challenging to turn it into a nice infographic...

So some lessons for jxl art: probably would be good to enable gaborish, so a default restoration filter is used, and I think that should reduce the frame header by 1 byte (since there are 5 padding bits already)

Choosing the 0.0.0 hybriduint config for the modular data would also save 4 bits (though it wouldn't save a byte here)

It's a pity that the TOC has u(10) as smallest option, I wish it was u(6) so jxl art with a payload up to 64 bytes would be one byte smaller, haha. But nothing to be done about that now...

It may be difficult to produce an info*graphic*, but how about something a bit more dynamic, such as a webpage where you can hover over the bits and it shows what they are parsed as? It wouldn't be as slideshow able, but should stil be a pretty good way of helping people understand the bitstream.

Could stick it on jxl.info

If I have time over the next few days I might have a go at doing that.

I actually want to see this for pretty much every format 😉

first attempt at turning the above into an infographic

🤏

I think this is the (or rather a) smallest possible jxl file

ah no

Tiny boi

Gotta save that 1 byte

``` 11111111 00001010 Signature: 0xFF0A 11111111 00000111 Dimensions are 512x256, default image header, default transforms, 5 padding bits 00001000 10000011 frame header: kRegularFrame, kModular, group size 1024x1024, last frame 00000100 no name, default restoration filters, no extensions, 2 padding bits 00001100 00000000 TOC: payload size is is 3 bytes, 4 padding bits 01001011 00100000 Use prefix coding, no lz77, alphabet size is 1 (all zeroes), global tree is "- Set 0" 00011000 Use global tree, default WP params, no modular transforms, 1 padding bit ```

OK now I'm pretty sure this is as small as it gets

how did you save that byte?

I forgot to set epf to 2

I see

what's with the size btw? 😛

epf 2 and gaborish on gives a minimal frame header

that's the largest small size 🙂

isn't 512x512 also a small size?

I assume that trying to make frame_header AllDefault() results in VarDCT losing more bytes than what you gain with the 3 less bytes of header

I haven't tried but I assume that, yes

no, the max small size is 256

for height

ahhh I see

but then you can make width = 2 * height with ratio

and I assume non-small sizes make you lose more than 5 bits

a non-small size is at least 6 bits more

U32(u(9), ...

instead of u(5)

right

so I think that's the largest smallest jxl you can make 🙂

now the next question: what's the smallest that is not a solid color?

or the smallest non-black one for that matter

by some miracle, all zeroes happens to decode to the tree `- Set 0`

if you want a different tree, then you need a non-all-zeroes but then you need to spend bytes on huffman coded huffman codes

makes sense

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902285255422124052/realsmallest.jxl

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902534603179442197/sunset65.jxl

it works!

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902536591405375568/small-nontrivial.jxl

how did you make it?

just a small nontrivial tree?

``` Width 512 Height 256 XYB - N 1 ```

but with a hacked jxl_from_tree that uses default XYB dequant

otherwise the XYB dequant factors (which are non-default in modular) take too much space

forgot to add the `EPF 2` and `Gaborish`

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902538031960035359/smaller-nontrivial.jxl

so that's 3 bytes more than the smallest jxl file, not too bad

still 1 byte less than what I _thought_ was the smallest possible jxl file until yesterday 🙂

found a better one

``` Width 512 Height 256 XYB EPF 2 Gaborish - W -1 ```

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902540022786441246/smallest-nontrivial.jxl

`W` is predictor number 1 and -1 is UnpackSigned(1), so this way it only uses symbols 0 and 1 for the MA tree

ah yeah that'd help

(`N` and `1` are both 2, so that leaves a gap of unused symbol 1)

so maybe a 16-byte jxl art competition could actually be somewhat interesting 🙂

I don't quite understand why it looks like this

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902549466119278662/antique_sierpinski.jxl

``` Width 256 Height 256 EPF 2 Gaborish Bitdepth 2 if y > 0 if |W| > 0 - N 0 if |N| > 0 - Set 0 - Set 1 - Set 0 ```

It works even on bluecord

oh, looks like jxl_from_tree is not initializing its cparams properly

that explains why it is doing an RCT without me asking for it

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902552907726069810/small-sierpinski.jxl

ah the embed bot has the upsample bug

<@!288069412857315328> what version of the decoder is it using? you might want to update it

how recent is the fix? app's on libjxl from 19 days ago

https://github.com/libjxl/libjxl/issues/459 ?

ah, maybe it isn't fixed yet 🙂

that is, the bug happens depending on what decode api you use (decode to float vs uint8 buffer)

is it that simple to fix in libjxl?

I don't know if it's a simple or hard fix, or if that's even the issue to begin with (the bug being on one of the special decode paths)

<@!179701849576833024> or <@!604964375924834314> probably know better how tricky this is

I thought we had that fixed...

It ought to be just a few variable name changes

pdf version of the manually decoded bitstream explainer

64 megapixels of JXL art in 16 bytes

preview is downscaled 50% because otherwise it's too big for discord

do zoom in on it

funky purple blobs on a yellow background

Rip when trying to decode in Chrome <:Cheems:884736660707901470>

data:image/jxl;base64,/wr6/xnIgwQYAEsIpRGcAA==

Chrome still has the upsampling bug I think

Yeah, seems like it <:Cheems:884736660707901470>

firefox also

embed fails?

Imagine a world where Discord would support jxl, avif and AV1 <:KekDog:884736660376535040>

I meant <@288069412857315328> 's <@&902534238069489715> bot

I know. Would just be nice if Discord would add all those things

~~probably because of file size limit~~ nvm

How can I make extremly tiny JXL art at a specific size

specific dimensions, I mean

<@!853026420792360980> If you're using jxl_from_tree, sounds like you want `Width` and `Height` https://jxl-art.surma.technology/wtf.html

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/903021129655013456/20bytes.jxl

i didnt do anything

If you mean hacking the bitstream, I guess read through the stuff Jon has posted recently. https://discord.com/channels/794206087879852103/794206170445119489/900463961772793856 https://discord.com/channels/794206087879852103/824000991891554375/901846908102930452 https://discord.com/channels/794206087879852103/824000991891554375/902576630692741130

works, but how do I make it redo something random

discord is electron, which is based on chromium

so as long as chromium gets it, it probably will eventually

except discord doesnt want to

like embedding .opus extension and av1 video

yea it's so dumb that discord will embed opus but only if named `.ogg`

Random?

**Anonymous** _“Unnamed piecelyndon kirk”_ 2021 image/jxl 32 bytes https://jxl-art.surma.technology/?zcode=y0xTSFawUzDgykxT8AMyTEGMcDBDV8GxLN0xJ0dBV8EQyAlX0FYwMjAAsvzgrODUEgUDAA%3D%3D

I thought there was a randon input

guess not

*every time you open the image, it's different*

Time to update slide 80? https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gde87dfbe27_0_43

Ah, yes maybe. A 1x1 image is a bit larger than a 8x8 image (need an extra byte for the SizeHeader)

Then it might be a good idea to add another column with the smallest possible file size for each format (not just for 1-pixel images)

Updated it a bit.

Does anyone have smallest possible sizes for avif, webp or heic?

Maybe this will be somewhat useful for AVIF https://chromium.googlesource.com/codecs/libwebp2/+/refs/heads/main/doc/container/

One reference: <https://github.com/mathiasbynens/small/commit/1cd7c58a1b3c357e73ff7be26accd362bc093354> <https://github.com/mathiasbynens/small/issues/115>

<https://github.com/mathiasbynens/small/blob/master/heif.heif>

I didn't know if that was heic.

Yes, this is HEIC (HEIF-HEVC)

Also <https://github.com/mathiasbynens/small/issues/114>

thanks, updated the slide

the 14 byte GIF is a bit dubious imo

it works in chrome

firefox:

so either all of these don't properly implement the GIF spec, or it's not actually a valid GIF

🤔 <https://stackoverflow.com/questions/2570633/smallest-filesize-for-transparent-single-pixel-image/15960901#15960901>

ok, I'm going to interpret "valid" as "follows the spec and has a somewhat predictable decoded image"

otherwise it's a matter of what kind of invalid files are supported by what and that is a different game

(I can make a decoder that renders any invalid file as a 1 pixel transparent image and then you could argue zero bytes are enough)

Yep, because PNGs can also be: <https://github.com/mathiasbynens/small/blob/master/png-truncated.png>

<@!794205442175402004> funnily enuf the stackoverflow article said that chrome was fixed to not allow the 14 byte gif to render anymore

37 bytes is apparently the minimum that's required to follow the gif standard properly

but 33 is what's required to display in all the current major browsers supposedly

That repo also contains https://github.com/mathiasbynens/small/blob/master/jxl.jxl which is 16 B and could be updated by the proud inventor of a smaller file, <@!794205442175402004> 🙂

Yep <https://github.com/mathiasbynens/small/pull/125>

could anyone represent my discord profile picture in jxl art?

monad made something similar even more complex

I don't know what I've made that's similar. Giving a sense of the image is straightforward enough with splines, but making something small would be a challenge with representing the distinct red areas.

Reminder: there's a <#899346138266746890> and an <#899346548796841994>

some of my entries are substantially smaller than the 64-byte limit

Submissions have to be made this weekend - don't be shy!

Looks like > 64byte oct compo and an #deleted-channel To me

yeah threads auto-archive, they're still there but you have to click on Threads

unarchived it

So, apparently djxl doesn't decode splines with 734149 coordinates.

It may depend on the image dimensions

ah

524288 coords at 1024x1024 seems kinda limited

seems number of coords is limited to half the pixels

*when decoding a 451kB image consumes all memory*

we needed to put in _some_ limit to avoid security issues

I guess else it could be used for denial of service.

Only one participant per category

That's not really a contest then, is it?

Shall we combine the October and November compos and just leave it open for another month?

Reality is, the audience here isn't interested enough. If you want to keep trying though, keeping it open for November is a fair idea.

I just haven't created anything I consider good enough

Same, I just try to support the initiative.

'good enough' is up to the audience to judge, not the artist, imo

Worst thing that can happen is you put something in a discord thread and it doesn't get any <:BlobYay:806132268186861619> emojis

Jon probably thinks an 8x8 white square is the most interesting JXL art. So, there's that.

And, hey, I have a new role. Unexpected, but I guess I'll take it ...

A 8x8 white square in 14 bytes would be interesting. In 20 bytes it's not interesting. I have a strange taste, I guess 😅

<:monkaMega:809252622900789269>

maybe extending one of the contests out to a longer time frame like 3 months would reduce this issue or maybe make it every two months or smth instead of monthly

i would but school happened

I just don't think the time frame is the limiting factor. It's a niche thing in a budding format. If 1% of people with exposure to JXL wanted to make art in this format, that would be very good. But even among the geeks in this server, we didn't see participation reach that proportion in the last two events. I think the event needs to reach a lot more people and a public venue is a good start.

Tried to reach some more people on twitter and reddit

I wonder which is better for cinematography. Jxl or avif? Mostly would consist those with just a small part moving I think. Or with multiple layers and a few semi transparent pixels in the foreground moving

If things can be done with cropped frames, jxl might be ok. If motion vectors are needed, avif will be better.

But the jxl encoder currently doesn't even try to be smart about animation

So it depends. Ok. Should also check if actual video is better than avif.

Avif is actual video

There is no difference between av1 in avif or in any other container

**\_wb\_** _“Structure out of the blue”_ 2021 image/jxl 34 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOEKcg5RMDTkcitKzE0NyC9W0DUyNVPQNTU04uLKTFMId%2FdQsFPQteBSUNBVcCxLD9f2C1cwhPH8tP1cFXQNuQA%3D

**\_wb\_** _“Steampunk Game Texture Collection”_ 2021 image/jxl 28 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOYKLixNTa1K5QotKE7MLchJVTDi4spMU0hWsFMw5FJQADLD3T2AHAMgR0FBV8GxLN1P288VLInM1wUJ6CoEp5YATQAA

Just to clarify: any jxl art I make can be considered open source with a permissive license: feel free to 'fork' any jxl art 'source code' and make a derived jxl-art from it (for the compo or just for fun). If you scroll up, you'll find lots of starting points in this channel...

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/902552907726069810/small-sierpinski.jxl

right... forgot about discord's caching

Bitdepth 8 RCT 0 if WGH > 1 - AvgAll 2 if Prev > 2 - AvgN+NE -2 if N > 2 - Set 0 - Set 255

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/913386735856132136/message.jxl

funky, I didn't know we had a `jxl_from_tree` bot

Oh, nice.

Is there somewhere I can read about how `Weighted` works? I'm trying to convert some jxl art into a standalone executable without any dependencies and am struggling to understand exactly what it does

It's complicated

It's a self-correcting predictor, in two ways: it has 4 subpredictors and it uses a weighted sum of those based on their recent performance (those with less error get a larger weight), and the error from previous predictions also feeds back into the subpredictors themselves

I think I understand generally how that is working now, but how do the 5 `PredictorMode`s come into play? This will all be in the spec when it's released in january, right?

You can also try to read the code :)

The 4 subpredictors have parameters, in the current jxlart tool (jxl_from_tree) you'll just get the default WP params

But you can adjust some constants in how the subpredictors are defined

At slow encode settings, a few different parameters are tried, I think that's the predictormodes you are talking about

But that's just an encoder implementation thing, in reality there are no modes, just about a dozen parameters that can be signaled

That's helpful, thanks 🙂 I will look more at the code

**nwoeanhinnogaehr** _“Staircased”_ 2021 image/jxl 63 bytes https://jxl-art.surma.technology/?zcode=nZBBC4JAEIXv8yveH1jY1VnxFFhEnTxU4Dl004VFIpZ%2Bf5jWmhlCtzcf8%2BbNzNr6ylx9A8VU2KoTMmLaG1s3vteHzQmRJLIXFFhBEjBIlcQpk8DR%2BBfOh46%2BEPn2XfcukRcj8mTlBwC6ec6UHqxnKVNgu9u5sqb1iP%2FMEPMhgpNRSnavM%2Bcg0h%2BHhQ41JWr5LSFU6aldL3n4ewVNDw%3D%3D

**Anonymous** _“Colorful checker board”_ 2021 image/jxl 28 bytes https://jxl-art.surma.technology/?zcode=80jNTM8oUTA1NOIKz0wpyQCzuDLTFPwU7BQsuBQUgMxkINMQyFRQ0FUIB6tPTVHQNYKKBKeWKBhwwVhGpqZcAA%3D%3D

**\_wb\_** _“Gooey chessboard”_ 2021 image/jxl 30 bytes https://jxl-art.surma.technology/?zcode=80jNTM8oUTA0suAKz0wpyQCzQguKE3MLclIVLLiCC0tTU6tSuZwyS1JSC4DyZlxcmWkK4Qp2CsYGXAoKugp%2BCromQAZQ0A8mCBIOVzCEs0y4AA%3D%3D

**\_wb\_** _“Plasma gun spritesheet”_ 2021 image/jxl 29 bytes https://jxl-art.surma.technology/?zcode=80jNTM8oUTAyNeMKz0wpyQCzQguKE3MLclIVLLiCC0tTU6tSuZwyS1JSC4DyJlxcmWkKyQp2QBaQEQ5iGHApKOgqBKeWKOhC2eEKhlwQEQMuAA%3D%3D

**\_wb\_** _“FFFFFFFFFFFFFFFFF...”_ 2021 image/jxl 27 bytes https://jxl-art.surma.technology/?zcode=80jNTM8oUTAyNeMKz0wpyQCzQguKE3MLclIVLLiCC0tTU6tSuZwyS1JSC0DyXFyZaQrJCnYKJiCGH5BhzKWgoKsQrqALYxhy6SoEp5YoGHABAA%3D%3D

**\_wb\_** _“RGBTQ+”_ 2021 image/jxl 30 bytes https://jxl-art.surma.technology/?zcode=80jNTM8oUTA0suAKz0wpyQCzQguKE3MLclIVLLi4nDJLUlILgBKmXFyZaQoBRalljknFrkVFCnZAaV2FcAVDkLgfkGtsyqWgABLRNYSywIanpgCVcAEA

**\_wb\_** _“Yet Another Sierpinski”_ 2021 image/jxl 45 bytes https://jxl-art.surma.technology/?zcode=ZU%2FLCsIwELzvV%2BxdArYY6UlQETyV4oOc1UYbqFDaIPr3TtJEW80hmccys9lqc6ssp3JOypS28ujYdKd7U2vOiFbGlrqBkdFufeCEyFz5wgsggKJo9WN57jZtC2lKgvfa4oWVQxDSScp36JJFMqJZjPLzzxCgkOxugSqnv8YDzIAqQGaBnh6Fyp44o99kyFIp6evE17cokbtQlPog0MBibipn9BP7WS52KJ5wEthg4X9zkIIPOAfYibW%2BWD%2BH8wY%3D

**\_wb\_** _“Minimalist XOR pattern”_ 2021 image/jxl 25 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTg4spMUwjX9QtXsFPQNeRSUABy%2FYB8GFdBQVchXAHGAioz4AIxglNzUpNLgOIA

**\_wb\_** _“Interesting Moiré (zoom in and out on me)”_ 2021 image/jxl 30 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsODi4gouLE1NrUrlykxTSFawUzAxALHCdf3CgRxdQy4FBSDXD8iHcRUUdBXCFWAsoDIDLhAjODUnNbkEKA5iligYAAA%3D

**\_wb\_** _“Psychedelic hippie clothes”_ 2021 image/jxl 32 bytes https://jxl-art.surma.technology/?zcode=NcqxCoNAEIThfp5iXuDAIyJWFrFJZaGRq0U3emDggmuTp3evsPv%2BYZ5RF0m68YExHdM37cIaIS42VSVeEtdNszD8TpG%2FoG%2Ff9ED8cGZDX2UF1wUL50FadtZ3ko6Bt%2BxWIGOQXWa1PVNZXA%3D%3D

**\_wb\_** _“Endoplasmic Reticulum”_ 2021 image/jxl 37 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTgCi0oTswtyElVMOEKz0wBipkaGnF5pGamZ5SAmUHOIQqGXFyZaQrJCnZAlgIQADmVQI4BmKOgoKvgp6BriMQBsYFqwuFqQBx3DxQt4WArUlMUdE3gYo5l6X7afq4KuqYQdUiqDA0MDLgA

**Anonymvs** _“Tit LE”_ 2021 image/jxl 37 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTgCi0oTswtyElVMOEKz0wBipkaGnF5pGamZ5SAmUHOIQqGXFyZaQrJCnZAloICkFkJZBoAmQoKugp%2BCrqGcCZUPhwuD%2BK4e8C5IFXhYMNTUxR0jeBijmXpftp%2Brgq65qZcaKqMTM24AA%3D%3D

**\_wb\_** _“Endoplasmic Reticulum 2”_ 2021 image/jxl 41 bytes https://jxl-art.surma.technology/?zcode=PY1NC8IwEETv%2BRVzl0ASFPUiVCn2FMQPctZmbQMVQhr6%2B91G7G3e22H2GLKnmHtoJVzwHDZKiYZC1%2BcSH3F8fuJAWIvr6Q6zFyK80eIALQCOl0RT9RrrlNgZxRKQuFHGVv3JQpYL1x23fnqGc7Pg3HPlL3lIvbhq6uzK1pA7vWwP1GZow%2Ftf

**\_wb\_** _“Untitled”_ 2021 image/jxl 35 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0qYGBlweqZnpGSVgZmhBcWJuQU6qgglXkHOIgiEXV2aaQriCnYKukakBl4ICiOfuAeQbgCSSwQxdhXCwAakpQFVANQoKyCKGUBHHsnQ%2Fbb9wiICuQnBqTmoyxE4A

https://jxl-art.surma.technology/?zcode=PcaxDkAwFAXQ_X7F_YEmFbpKmEwWEXPDo00qqajF1yuD6ZzWp0Viciwx-SVrtEYnfnPp6xhPu8cgrDAcl8gtaEJ0FvArZ9Y0IHOnXFXmk4o9VfG3wusgiRoP

'Acrylic paint splashed on glass'

**\_wb\_** _“Upsampling Boundary Cases”_ 2021 image/jxl 22 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMOQKz0wB0WZcHqmZ6RklIFZoQXFibkFOqoIFF1dmmkK4gp2CAZeuQnBqiYKuMYxlbMgFAA%3D%3D

This should be the right channel, how does the coefficients portion of spline exactly work?

**Mr.Korrupto** _“Early practice #1”_ 2021 image/jxl 32 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTgCi0oTswtyElVMOEKz0wBixmZcHmkZqZnlEDYwYWlqalVqVyOOQUZiVxBziEKhlxcmWkKyQp2CqZcCgq6CsGpJQoGQBZQMBwoaARkwoRh7HCwgakpCoZGFlwA

**Mr.Korrupto** _“Early practice #1.5”_ 2021 image/jxl 29 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDTgCi0oTswtyElVMOEKz0wBixmZcHmkZqZnlEDYQc4hCoZcXJlpCskKdgqmXAoKugrBqSUKBkAWUDAcKGgEZMKEYexwsBGpKQqGRhZcAA%3D%3D

just me figuring the system for now, made a challenge for myself to attempt atleast 1 original piece per day

The coeffs are 1D DCT32 coeffs for R,G,B (or X,Y,B) and sigma ("thickness" or "blur radius")

See also this

Oh so its just 32 numbers right one after another separated by spaces?

Yes, four times

alright, thanks!

**\_wb\_** _“A binary tree shaped like a Sierpinski triangle”_ 2022 image/jxl 45 bytes https://jxl-art.surma.technology/?zcode=C89MKclQMDI14%2FJIzUzPKFEwNLLgcsosSUktAIlzhRYUJ%2BYW5KQqmHA55hRkJHIFOYcoGHNxZaYpVCrYKRhwKSgAmX5QJoSj6%2BcK5yso6CoEp5Yg8fwUtJHUhuv6IalF6NY1hAqBtYTD9WCaiEsPFi2mENdWANUaGpnD3ADhWuBwLkwfQgYA

**\_wb\_** _“Cellular Disintegration”_ 2022 image/jxl 81 bytes https://jxl-art.surma.technology/?zcode=dZA7DsIwEER7n2IuYClxsBIaChASlQsSyReISdxRuIDbs47l%2BCPSzbxdrXbmat1s3m7FwJ63CR3TdiYnmn5gD2OX1QXN7AsfXNA1DCD9jXpzilwwAMdo3O78UPN8HhhXd2K83eGGF2IiZ4mKgiZ%2Bqrh%2FQGnw%2FoBTxH%2B4PBNY%2FkiZ6jBDvRaJkDJ25ZsT51SPb1W2KV59ojyQz6P6AQ%3D%3D

Added some arty-farty blob of text to this one: https://twitter.com/jonsneyers/status/1477236176142667776?t=-YNZtk0RouVu0vR981L4Cw&s=19

woah, this one is interesting! if I'm reading the code right, you're essentially having one main algo, and special cases for each group, right?

Yes, the "decay speed" of the right side of the sierpinski triangles differs per group

ah, nice there's also something else I'm curious about, what causes the distinct "sky blue" lines on the right side of each traingle?

The choice of RCT. Without the RCT, it would just be grayscale.

ah, alright, thanks!

https://jxl-art.surma.technology/?zcode=jZDLCsIwFET3-Yr5gQtJH-jKhVJwlYUPspY22oBCwSz0771JbZrixt3McCYZ7tb5zg6-x1ocdicoYVzHrlaF2Ft3632U5-F5eQx3y5RwV7TYMAmwfLOULAGCBqmvPFqPoq5Hpk0Mm1cygTNQSYcOjaX09GRjoLPqVJh9AAwtmTEl3XBKKovjXMPZT4jyz3az-GfaU0k5DzahWMp8s4lHtR2oylOsmPoA

'Alien Beehive'

not feeling the top part but bottom is so cool!

The top is just a way to get randomness to initialize the bottom with. It doesn't look as interesting without random initialization...

ah, huh I didn't know so top is a setup for the later instructions to be able to read out from?

Things are evaluated top to bottom, and the Weighted stuff behaves weirdly enough to be similar to a pseudorandom number generator

Could have a smaller top section though

Like this: https://jxl-art.surma.technology/?zcode=jZA_C8IwFMT3fIr7Ag-a2lAnB6Xg1ME_ZJY22oCFghn02_uSmpg6ud0dv0uOt7WuN5MbsBaH3QlSaNuzU7IUe2NvgwvyPD0u43Q3KIWwV3TYMAmwfLEsWAKEFiQ_8mgcSqVmpksMm2cyntOQSfsOzaX0tIoo-zZrRv7rPaBpycwptQ2nJLM4rNWg-jeD_LPcLL6Jc6oi26t9cVXkk3U4qelBVZ6iZuoN

huh, that's useful to know!

in theory with custom origins you could omit that top part, no?

Sure

https://jxl-art.surma.technology/?zcode=jZDNDoIwEITvfYp5gU1apMGTBw3GEzH-pGcCVZpIJMJB394FpBZP3mYm37STXbuutE1XYSkOmxOUMK5kp1UkdtZdq26Q20de2_29hQRpJc5Nm9fNzTIu3AUFVqwAli-WkiVAyEDqI4-2Q6T1yBSeYfP0pucMlNd9h8aSf1pPKPssaE781_eAoTkzppSlnJIK4mGtASW_GdSf5XT2zTQnlsFe0xcXMpxshgvbEhSHKRKm3g

Like that

Looks like the interaction of upsampling and crop doesn't quite work, probably a bug in jxl_from_tree but maybe worth checking out

https://jxl-art.surma.technology/?zcode=jZC_DoIwGMT3PsW9QJO2QnBy0GCciPFPOhOo0kQikQ769n4FqcXJ7e7yu_byra2rTecaLNlhc4Jk2tbkUqnYzthr4wa5fZSt2d97CHApFDt3fdl2NwPFmL2gwoqaAMkXSUES4CgI_sijcVBpOjJVYMg8g_Gchgzad_hYCk-nE0q-iJoT__Ue0HzOjCkvckq5jOJhrQbPfjPIP8v57JtpTiKivdoXFyKerIcTmxo8iVNkRL0B

😭

I think because this is not fixed (at least in this online/browser version) https://github.com/libjxl/libjxl/issues/459

<@228116142185512960> could the jxlart libjxl be bumped again? Oh and another thing that would be nice, is to have a button to get a base64 data url for the jxl...

<@!794205442175402004> I just tried building 0.6.1 and it seems that `libskcms.a` is not being built anymore and I can’t find it anywhere in my build folder. Did something change around skcms?

Yes, iirc we made it so you can plug in skcms or lcms

<@604964375924834314> do you know what is going on?

set(JPEGXL_BUNDLE_SKCMS true CACHE BOOL "When building with skcms, bundle it into libjxl.a.")

**\_wb\_** _“The y2k22 bug”_ 2022 image/jxl 34 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDbk4spMU6hQsFMw4FJQ0FUIVwADQwMwAAsFp5YoGBkaGhmDBbkA

**\_wb\_** _“Overflow Nightmares”_ 2022 image/jxl 24 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDbicsvJTyxxrShwyiwpVrDg4tJVCE%2FNTM8oSU1RMDQwsTA1N%2BMCAA%3D%3D

**\_wb\_** _“More Overflow Nightmares”_ 2022 image/jxl 24 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDbk4tJVCE%2FNTM8oSU1RMDQwsTA1N%2BMCAA%3D%3D

Note: none of the above jxl files are technically spec compliant bitstreams. Overflow is not supposed to happen when int32_t is used for the sample values (or int16_t if the modular_16bit header flag is set).

**\_wb\_** _“One million shades of gray”_ 2022 image/jxl 25 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDLg4spMU6hUsFMw4NJV8FMwNDAyATLCFQy5AA%3D%3D

**\_wb\_** _“Overflow Caterpillar”_ 2022 image/jxl 33 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDbkCnIOUTDk4spMUwh391CwUzDg0lUIT81MzyhJTVEwNAADZCEjiAgA

<@!794205442175402004> So what do I need to change? I’m guessing/hoping there’s a cmake flag that links one of those? https://github.com/surma/jxl-art/blob/main/jxl/Makefile#L46-L56

`-DJPEGXL_BUNDLE_SKCMS=YES` might do it

cheers

Bitdepth 1 RCT 1 if WGH > 0 - Weighted 10000000 - Weighted 400000

"overflow dither"

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/927201546670837810/message.jxl

<@!604964375924834314> Sadly, that didn’t do the trick :S

**\_wb\_** _“Overflow Noise”_ 2022 image/jxl 32 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDbk4uIKLixNTa1K5cpMU0hWsFMw59JVCE%2FNTM8oSU1RMDSAAaBocGqJggFQAwA%3D

**\_wb\_** _“Overflow AvgAll”_ 2022 image/jxl 24 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDbicsvJTyxxrShwyiwpVrDg4tJVcCxLd8zJUTA1AAMuAA%3D%3D

**\_wb\_** _“Brachiosaurus by a beginner linocut artist”_ 2022 image/jxl 28 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQsOAKz0wB0kamZlweqZnpGSVgZmhBcWJuQU6qggkXV2aaQriCHVDYlEtBQVchHKwqNUVBF6QQRcTQwJgLAA%3D%3D

<@!794205442175402004> is it possible to do multiple steps in a "then" stage of an if?

You can have nested ifs but in the end you always have to reach a single leaf node that is a predictor plus an offset

question, how do I use the embed bot? :)

right click the message and then hover over apps

embed is for jxl files

oooooh

Bitdepth 16 Upsample 4 Width 1024 Height 1024 RCT 1 if c > 2 - Set 0 - Weighted 128

https://embed.moe/https://cdn.discordapp.com/attachments/824000991891554375/927299439310282852/message.jxl

any idea how to get the "oil spill" effect to be bigger?

and just overall more uniform

for that you could either increase the bitdepth or decrease the "128"

lower weighted seems to do the job for making it bigger, but not more uniform

oh shit bitdepth was a very good call

**Mr.Korrupto** _“Early Practice #2”_ 2022 image/jxl 26 bytes https://jxl-art.surma.technology/?zcode=c8osSUktKMlQMDLhCi0oTswtyElVMOEKz0wBihkaAEU9UjPTM0og7CDnEAVDLq7MNIVkBTsFIy4FBV2F4NQSBQMwKxysMjVFwdDU0IgLAA%3D%3D

**\_wb\_** _“Misty Ruins”_ 2022 image/jxl 42 bytes https://jxl-art.surma.technology/?zcode=XY3BCsIwEETv%2BxVzl8AmGo9CFLGnIqLkrDS2gQihDf1%2B1ygIPb43szv7WLqQy4AtXQ5XaPKxEzKWqQmxHwosM93ydH%2FlFLAhik%2F4U4MdmACB8xhm95iO4yjOiAMU3Ny7lKC%2BLK1WQs1c8Vfwq9ZDafuXvi6Grr757MiRWjMtUmWWRtMb

oh this is sick af

**\_wb\_** _“This is fine.”_ 2022 image/jxl 64 bytes https://jxl-art.surma.technology/?zcode=fVDLCoNADLznK3IvC7td3d4Ktkg9ifTBntu6VcGCqAj9%2B2Z9ofZxy0wymUl2WR2bok5RwXF%2FRgE6iwlJKSEwWZLWqJSCS1Fdn0Vu0AHIHhhFpWlwixwQGZ5MjcKlkjp3YgWVLQgJsDVvoR30miRchT4ysaA08kHzIo0zSAjrQ9AbjZQ1926VX5Z2duz067w8RzEh7Q6a2%2FAJN0adk3aDbo82MQX%2F0xP2P%2FPmcJyEhTNTHD4HNTIJX5e7k%2BvnGbtX8w8D14UfMWd8J34D

https://c.tenor.com/-kZOB16tELEAAAAM/this-is-fine-fire.gif

**\_wb\_** _“Something rainbowish”_ 2022 image/jxl 64 bytes https://jxl-art.surma.technology/?zcode=ZZBdC4IwFIbv9yveexm4TaVugoqgK4M%2B2LXo0kGZ1Ij6902zNfVuz8vheXfOSptCNabCjOzXRzAidWFJhCHZKl1WBol9nppHdm0uChHZ3bWqTWb0rbbTRJ%2FxxgLcDgE9iA4cRj26IHYBQLF8lmmQbjDNpMvGU8MJq82tlv1KXxa8yhYZ9%2FUSVAxQuJ6DMqAsdgvkU9ff1Afc2%2BfrYyOm3KtrK3jsSWXrSAYf7E6vCvuV8a1kkILNyQc%3D

>black

**\_wb\_** _“Rainbow Cubicles”_ 2022 image/jxl 49 bytes https://jxl-art.surma.technology/?zcode=VY49C8IwEED3%2FIrbQyBpKzoJ6uIUwQ8yFxvbA61BD%2FHne21qSLf3wt3LbZEaH6gDo8VxdwYjHDajFpXYe2w7inwJ7%2FoR7p4nDi%2F0PdWEz55N4A2usGYCYPwyasYklY4KoMCBKjIpRaSTJ1CLcW6KzQr%2F%2FUmXKRgrZmbZB0PWaJ1adrgyu2bzaa20vFLmT05akCse%2BwE%3D