JPEG XL

I’d gzip the code first, but `CompressionStream` isn’t supported everywhere

but maybe I can find a polyfill 🤔

<@!424295816929345538> Almost Piet-like!

Rule 110

ooh nice

I've implemented https://en.wikipedia.org/wiki/Rule_110. This proves that JXL would be Turing-complete without the 1024x1024 limit.

Source code: https://www.pouet.net/topic.php?post=568703. You can modify it to implement any elementary cellular automation.

<@!228116142185512960> Thanks for making the playground!

Awesome! I was about to do that actually. Good that i waited 😄

<@722852650655154287> nice!! I wanted to look into cellular automata but you were faster :D

Hehe

Thanks!

<@179701849576833024> <@794205442175402004> in an image with multiple regions, can the predictor cross group boundaries? Like can `N` get the value of a pixel in the group above?

It would be really nice if the playground understood comments

Here is the source code to my Rule 110. ``` > cat rule-110.txt if y > 0 if N > 0 if NW-N > -1 ; N = 1 if N-NE > 0 ; NW = 1 - Set 1 ; NE = 0 - Set 0 ; NE = 1 - Set 1 ; NW = 1, NE = 0/1 if NW-N > 0 ; N = 0 if N-NE > -1 ; NW = 1 - Set 0 ; NE = 0 - Set 1 ; NE = 1 if N-NE > -1 ; NW = 0 - Set 0 ; NE = 0 - Set 1 ; NE = 1 if x > 1022 - Set 255 - Set 0 > cat Makefile rule-110: rule-110.txt sed 's|\s*;.*$$||;s|t 1|t 255|;s|-1|-255|' $< > $@ ```

Because it was too difficult to keep track of cell states in my head, I wrote them down as comments and put a sed command in a Makefile to remove the comments

Would there be a systematic way to "cleanly" plot the sierpinski aka rule30? It's not that clear for me 😛 Edit: Rule90 rather!

You can take the cell configurations from https://mathworld.wolfram.com/Rule90.html and change Set 0/1 in the source code to match them

You'd need to shift the starting pixel to the center, too

nope, you can't do parallel or cropped decoding otherwise

I didn't bother with comments in the C++ parser, too complicated 😛 it might be done in JS though...

Rule 90

https://jxl-art.surma.technology/?code=aWYgeSA%2BIDAKICBpZiBOID4gMAogICAgaWYgTlctTiA%2BIC0yNTUKICAgICAgaWYgTi1ORSA%2BIDAKICAgICAgICAtIFNldCAyNTUKICAgICAgICAtIFNldCAwCiAgICAgIGlmIE4tTkUgPiAwCiAgICAgICAgLSBTZXQgMAogICAgICAgIC0gU2V0IDI1NQogICAgaWYgTlctTiA%2BIDAKICAgICAgaWYgTi1ORSA%2BIC0yNTUKICAgICAgICAtIFNldCAyNTUKICAgICAgICAtIFNldCAwCiAgICAgIGlmIE4tTkUgPiAtMjU1CiAgICAgICAgLSBTZXQgMAogICAgICAgIC0gU2V0IDI1NQogIGlmIHggPiA1MTEKICAgIC0gU2V0IDI1NQogICAgLSBTZXQgMAo%3D

you're too fast, and i have to do some RL work at the same time 😛 good to have you! 🙂

Would be the smallest *clean* sierpinski? i guess not, since this is general purpose, right?

Oh of course. Duh

We should totally add comments

<@179701849576833024> i was actually thinking about adding a special first line like `#tile 8` which would divide the 1024x1024 into 64 squares

Heh. Okay, I see what you mean by "clean". I don't know, but I am pretty sure you can do better than this generic approach.

If you get really serious about it, you can implement on optimizing compiler

(we can only divide in squares of down to 128x128)

Parsing C++ must not be too fun

(ignore that, I can't divide)

Oh TIL. Well it would be interesting to come up with a notation for an arbitrary dissection of a given image size.

*in C++

<@!722852650655154287> well, my supertiny 10 byte thingie isn't clean either, but the variation above is clean enough 🙂 ( https://codegolf.stackexchange.com/questions/6281/draw-a-sierpinski-triangle/95479#95479 )

Parsing C++ itself is **hell**

there are parser generators, but this was a half-day hack so I didn't bother 😛

The parser is actually really simple. The tokenizer is just `file_contents >> next_token` 😅

yeah, that makes some thing like "comment until newline" a bit complex though 😛

Neat. Maybe you can use the connection between Sierpinski and binary addition in JXL, too.

So far, i couldn't wrap my head around it. My first thought was implementing as "Rule xyz" and then look further. It's not the easiest language to directly express calculations 😄

Well you got NE, N, and NW

and the rest is... `if` statements 😄

And +-offset

I just deployed a new version real quick that runs deflate on the code before generating the share URL

So this: https://jxl-art.surma.technology/?code=aWYgYyA%2BIDEKICBpZiBOID4gMTAKICAgIGlmIFcgPiAxMAogICAgICAtIEF2Z04rTlcgLSAxCiAgICAgIC0gVyArIDEwMAogICAgLSBOICsgMTAwCiAgaWYgYyA%2BIDAKICAgIGlmIE4gPiAxMAogICAgICBpZiBXID4gMTAKICAgICAgICAtIEF2Z1crTlcgLSAxCiAgICAgICAgLSBXICsgMTAwCiAgICAgIC0gTiArIDEwMAogICAgaWYgTiA%2BIDEwCiAgICAgIGlmIFcgPiAxMAogICAgICAgIC0gQXZnTitOVyAtIDEKICAgICAgICAtIFcgKyA5OQogICAgICAtIE4gKyAxMDA%3D Becomes this, which is a lot better 😄 https://jxl-art.surma.technology/?zcode=y0xTSFawUzDk4spMU%2FADsQxArHAIS1fBsSzdT9svXEEXqEQXKKwNFAaJ%2B0FZIMUgAwzwGBBOyACi7LW0ROgCAA%3D%3D

Nice!

Could also use jxl itself as a compression method, I guess :)

You'd lose the whitespace and comments though

At least Brotli, which is also supported in browsers

Or add a bit of serverside and store stuff so you only need an id. But this is good enough already, I'd say

The rule 90 above is easy to change into rule 30 (mirrored) https://jxl-art.surma.technology/?code=aWYgeSA%2BIDAKICBpZiBOID4gMAogICAgaWYgTlctTiA%2BIC0yNTUKICAgICAgaWYgTi1ORSA%2BIDAKICAgICAgICAtIFNldCAyNTUKICAgICAgICAtIFNldCAwCiAgICAgIGlmIE4tTkUgPiAwCiAgICAgICAgLSBTZXQgMAogICAgICAgIC0gU2V0IDI1NQogICAgaWYgTlctTiA%2BIDAKICAgICAgaWYgTi1ORSA%2BIC0yNTUKICAgICAgICAtIFNldCAyNTUKICAgICAgICAtIFNldCAwCiAgICAgIGlmIE4tTkUgPiAtMjU1CiAgICAgICAgLSBTZXQgMAogICAgICAgIC0gU2V0IDI1NQogIGlmIHggPiA1MTEKICAgIC0gU2V0IDI1NQogICAgLSBTZXQgMAo%3D&zcode=y0xTqFSwUzDgUlDITFPwgzIhnHBdEF%2FXyNQULAQR1PVzhSsCAV2F4NQSBYQamIgB2XoQVmOaoYupiRirdXErQjUGqKUCqN7U0JAL0waYRgA%3D

The thing is, none of these compressors are exposed to JS. Just recently they started to expose gzip via CompressionStream, but that's in Chrome only.

<:SadOrange:806131742636507177>

<@!228116142185512960> Is it possible, that the "zcode" generation only works, if the current URL does not already contain "code"?

Hm

Maybe

Not at laptop right now

I should remove`code` when adding zcode tbh

It's fine for now, removing the appendix and clicking the button again is not too much of a workaround 🙂

I've rewritten your script to apply run-length encoding to horizontal lines of pixels. ``` #! /usr/bin/env python3 import sys from PIL import Image def main(path): im = Image.open(path) width, height = im.size if width != height: raise "Image must be square" size = width if not is_pow2(size) or size > 1024: raise f"Image size {size} is not a power of two <= 1024" zoom = 1024 // size pixels = im.load() for y in range(0, size - 1): print(f"if y > {y * zoom}") for y in range(size - 1, -1, -1): changes = [] color = pixels[0, y] prev = color for x in range(0, size): if pixels[x, y] != prev: changes.append(x) prev = pixels[x, y] for x in changes: print(f"if x > {x * zoom}") for x in changes: print(f"- Set {color}") color = 255 - color print(f"- Set {color}") def is_pow2(n): return (n & (n-1) == 0) and n != 0 if __name__ == '__main__': main(sys.argv[1]) ```

This reduces the black & white Einstein picture to 13K

Impressive. I had some kind of quadtree (or just quads in general) in mind, but again, the time 😦

I am too lazy to implement that 🙂

https://jxl-art.surma.technology/?zcode=y0xTqFSwUzDgUlDITFPwgzIhnHBdEF%2FXECwAEdL1c4UrAQFdoBZtFH5wagmcT6oOhKWYJsCdgW4J2MhwJDOJ1APiG5maQjxeAVRtaGBkxIUuh9AJAA%3D%3D

Avoids big constants, makes the jxl smaller

Neat

And you don't need to process `Set 1` into `Set 255`

I still wonder how we could get to the *direct* formula. Or if this thought is actually hindering progress for the CA approach.

https://jxl-art.surma.technology/?code=aWYgeSA%2BIDAKICBpZiBOID4gMAogICAgaWYgTlctTiA%2BIC0yNTUKICAgICAgaWYgTi1ORSA%2BIDAKICAgICAgICAtIFNldCAyNTUKICAgICAgICAtIFNldCAwCiAgICAgIGlmIE4tTkUgPiAwCiAgICAgICAgLSBTZXQgMAogICAgICAgIC0gU2V0IDI1NQogICAgaWYgTlctTiA%2BIDAKICAgICAgaWYgTi1ORSA%2BIC0yNTUKICAgICAgICAtIFNldCAyNTUKICAgICAgICAtIFNldCAwCiAgICAgIGlmIE4tTkUgPiAtMjU1CiAgICAgICAgLSBTZXQgMAogICAgICAgIC0gU2V0IDI1NQogIGlmIHggPiA1MTEKICAgIC0gU2V0IDI1NQogICAgLSBTZXQgMAo%3D&zcode=y0xTqFSwUzDgUlDITFPwgzIhnHBdEF%2FXECwAEdL1cwUKGRlAhRQUdIF6dFEFglNLFAww9KBq0VbArgNhLaYJcIegWwI2MhzJTDx6jExNsZgC1FABVG1qCFGOqhSqDAA%3D

Can then start using other values besides 0 and 255

And explore other automata than just the elementary ones

From 47 to 41 bytes 🙂 https://jxl-art.surma.technology/?zcode=y0xTqFSwUzDgUlDITFPwgzIhHF0%2FVzhfQUEXKKuNxAtOLcFQq2uIRRqiIFzXD8kwsHHhSObBtBiZmkKcUgFUbWhgZMSFLgc3HAA%3D

And down to 40 🙂 https://jxl-art.surma.technology/?zcode=U1DITFOoULBTMDQwMuJSAAJdheDUEgUjU1MgDyjnB5QzAEuAOLp%2BrnA%2BSKmfgjYSD6QRXa2uIRZpiIJwXT8kw8DGhSOZh%2BwUAA%3D%3D

``` if x > 1022 - Set 255 if N > 0 if N-NE > 0 - N + 0 - Set 0 if N-NE > -1 - Set 0 if NW-N > 0 - NW + 0 - Set 255```

The script now supports color. Since it is getting longer, I'm posting a Pastebin link. https://pastebin.com/Jk8gBSSn

An example

This is probably the silliest way to 'compress' images, lol

Now it's just a matter of implementing a JPEG decoder in Rule 110

Surprisingly the size with this method is not that big (but perhaps the decoding speed will be very slow), normal encoding for comparison

I suspect, for this pixelartsy stuff with very low colorcount and large areas, a simple subdivision scheme like mentioned above, will also have okayish results 🙂

This is my guess, too

But rn i'm brainstorming about a shorter sierpinski 🧠

39 bytes with a horizontal flip. https://jxl-art.surma.technology/?zcode=y0xTqFCwUzDkUlDITFPwAzINgEwIJ1wXxNc1BAsoKOgqBKeWQKVBPD8FbQzFMFmQiK6fK7J2mAFGpqZIIn7hcFNQbYArBgA%3D

38 with a color inversion https://jxl-art.surma.technology/?zcode=y0xTqFCwUzDkUlDITFPwAzINgEwIJ1wXxNc1BAsoKOgqBKeWKBiZmkL5ICW6fq5wLRA1fuEK2igCIE3oZhrAjfRDUo1sAVQfAA%3D%3D

I wanted to reach 32 first before posting but you're pretty fast. So here is 33 🙂 https://jxl-art.surma.technology/?zcode=y0xTqFCwUzDkUlDITFPwC9f1A%2FJ0QVxkAQMwX0FBVyE4tQSNZ2RqyoUqB2UBAA%3D%3D

Wow

Okay, here we go ... 32! 🥳 https://jxl-art.surma.technology/?zcode=y0xTqFCwUzDkUlDITFPwC9f1A%2FJ0QVxkAQMwX0FBVyE4tQSNZ2bMhSoFZQEA

"Dimming the lights" like that might be a bit of a cheat If you replace `Set 63` with `Set 10`, you get 31 byte, and the triangle is still sort of visible.

It's worth trying to achieve 32 bytes with only black & white

Yeah, i'm still pondering. 32 is the *smallest* category on "pouet.net" so that is definitely a milestone, but i'm not entirely happy

It's 30 bytes with `Set 1`, but I can't see that even if I tilt my display 😛

Okay, but *NOW* 32 bytes and pure black white 🙂 https://jxl-art.surma.technology/?zcode=y0xTqFCwUzDgUlDITFPwC9f1A%2FJ0DYFcZAEDMF9BQVchOLUEjWdkasqFKgdlAQA%3D

Congrats! 🎉

So it's worth remembering that comparing a value to zero is smaller than comparing it to one

You should post this Sierpinski in the pouet.net thread to give it some permanence

It may be global value compression, many zeros there

Note that when we sync the dev repo with the public one, and surma updates his thing, everything will likely be 4 bytes smaller

I'm thinking about doing a wild release 🙂 it's a fine wild production in the 32b category. and also, in a few month, it is very possibly just watchable in chrome (at least)

Oh, that's a good idea

We can avoid starting an ANS stream, which costs 4 bytes of initialization, since for singleton histograms, the prefix coding and ANS do the same thing: zero bits per symbol

How do you get pouet.net to add a new platform? They did it for PHP and mIRC scripts!

If you're lucky, the table of contents also becomes shorter by enough bits to save a byte, since it is padded to a byte

well *that* is another issue, and a hard one. Getting TIC-80 accepted was tough. And JXL is "just" an image format, so ... i wouldn't bet on it to become a category.

Maybe if someone holds a JPEG XL compo it will seem more legit?

I'm not happy to be the one that casts the doubts, but amongst the sceners, i consider myself to be the open minded one when i comes to new platforms. And still i fear the admins will have none of that.

The TIC-80 is a full fledged retro computer (but virtual) and still it was quite a fight to get it accepted.

I see. Oh well, it's still fun, and there are catch-all categories.

<@!436097739391107072> By the way, I loved your _Rise of Ramses_ and _Platforms_ for DOS. They inspired me to look into the demoscene again.

As an example, this one got the meteoriks award for "outstanding technical achievement" (it beat my nominated productions fair and square), still, it has no category attached, it is "wild" https://www.pouet.net/prod.php?which=83691

Oh thank you 🙂

... so, even the mighty MatLab is *not* a demoscene platform.

That is not just a novelty but a good intro in its own right. Impressive.

I wonder how far I could get with https://en.wikipedia.org/wiki/Maple_(software) 🤔

Yeah, it felt unfair to be pitted against that mindlowing production for the award. My nominee was some perspective scroller with sound, how was i supposed to beat *that* 😄

Clearly, you should be using MATLAB, too 😉

To stay on topic, flipping ( at x=y) the 32b thingie is also an option, but nothing groundbreaking ... i want to make that "extra" pixel go away, but so far, no idea : https://jxl-art.surma.technology/?zcode=y0xTqFSwUzDgUlDITFMI1%2FULB%2FJ0DYFcZAEDMF9BQVchOLUEjWdkasqFKgdlAQA%3D

I'll see if I can do it tomorrow. G'night!

Good night 🌛

Release : https://www.pouet.net/prod.php?which=88495

https://jxl-art.surma.technology/?zcode=y0xTCFewUzDkUlDQVXAsSw%2FX9gsHskD8zDSFZKCUAZAJkgxOLVEwMjVF4RkAAA%3D%3D

My 32 byte entry for today

Also, there is a discussion going on in demoscene discord about what category JXL can be in and that it is not executable, although I would also like to see a category with a competition of image formats (assuming they're common and supported on some platform)

For an instant, I skipped an else keyword in Python.

Much more beautiful than the pure sierpinski 🙂 I also thought that my 36b thingie would have been prettier, but it's too big 😄

Anyway, i just caught up on the demoscene discord discussion. Wow. I think i can be glad that the prod hasn't been nuked from pouet as of now 🤪 The fact that there is minishadertoylike tool to create these online in something that is definitely a programming language (on the surface) helped a lot i think 🙂

But i guess it's best to not flood pouet now with new JXL entries. That might madden the pouet gods 🧙 🧙‍♂️ 🧙‍♀️

I haven't practiced as much as y'all yet, but i do like the colors :D

https://jxl-art.surma.technology/?zcode=y0xT8FOwUzDmUlDQVXAsS%2FfT9nMFsoyA%2FMw0hWSglAGQCecYgjkgtcGpJQpGpqZofIhiKM%2FEFAA%3D

What 'compo categories' would make sense for jxl art?

Limiting by file size is an obvious and traditional criterion.

Using powers of two as boundaries is common.

32 bytes are enough for some things (especially when the 4 byte saving lands)

That's entirely up to the competition (party) organizer. I've seen first hand now that my point of view (wild, procedural graphics) isn't widely shared (it's not globally rejected either). In the next edition of "Lovebyte", where we had a 256 pixel competition, i can totally see a JXL-Art compo. As for the upcoming "Revision", maybe Gargaj is right and they would downright reject it, but they also accept simple *videos* so maybe they would accept a real outstanding killer 256 bytes JXL art, containing stuff that's really impressive.

The current tool does 1024x1024 single frame images, but things could be applied to much larger images and to animations

that one is 2048x2048, in groups of 256x256, not in RGB but in XYB, where Y is just a constant in every group, and X and B make a simple gradient

I didn't hand-write the tree here though, this is just what it learned, so probably it could be more compact

in general, doing things in XYB instead of RGB will probably make nicer effects, because you can make smoother gradients that way that evolve in perceptually nicer ways

I like the direction this is going. It's really beautiful already.

I'd love to augment the syntax to include larger images with smaller groups and other color spaces

currently jxl_from_tree is just a quick hack that produces an image using a tree, then calls the regular encoder with a hook to override tree learning and use a fixed tree instead. To get more expressive, it would be better to skip the image generation, and add a hook to the regular encoder to override looking at the image and just pretend all symbols are zeroes (or even more interestingly, they could be whatever else that lz77 can compress down to nearly nothing, e.g. some short repeating sequence)

then we can more easily do transforms and different color spaces etc

we do have some more urgent things to do though, like preparing for the next JPEG meeting and getting jxl support in chrome 🙂

most of these are still to be done, ugh

You got this. Hate to say it, but don't let art distract you too much 😉

Interestingly, on my dev version, it does make a difference

that's the original jpinski

that's the one with W-NW

😮 Okay, so i guess we have a new record then 😄

so you are saving something with the W-NW, probably because y and W-NW have a lower index in the tree encoding than x and NW-N

Just by looking at these i have a feeling that *much* smaller and "better" images are possible when coding against the internal API, with all that knowledge

probably

the current tool is something like commodore basic

you could do a lot more with direct machine code

<@794205442175402004> what document are those screenshots from. Is it public?

That's from the spec, and no it's not public

Will it ever be ?

well, we'll certainly try...

maybe we need some super bad hacker leak those spec files? or some file system permission accident(chmod 777)?

i'm going to try to get it discussed at the next jpeg meeting

meanwhile

this gives me a weird 3D effect

I see the red sierpinski floating in front of my screen

anyone else seeing that?

this was made by allowing prev-channel properties in the tree

``` if c > 0 if Prev > 50 - Set 0 if N > 254 - Set 255 - N + 1 if y > 0 if W-NW > -1 if W-NW > 0 - Set 255 - Set 0 - Set 255 - Set 255 ```

i'll make a MR so others can try this too

being able to access previous channels probably adds quite a bit of expressivity

``` if c > 0 if c > 1 if PPrevErr > 1 - Set 255 - Set 0 if Prev > 80 if Prev > 85 - Set 50 - Set 255 - Set 0 if N > 3 - AvgN+NW - 1 - Set 255 ```

Every degree of freedom is welcome 🙂 And no, i don't see the 3D effect above as strong as you 😉

I don't get it on the discord preview, but I do get it when I open it fullscreen

it works for me on both my laptop and my phone, but I do need to set brightness high enough to see it

maybe it's like those magic eye things, I never see those, but here I do see a pretty strong 3D illusion

I also see 3D, and yes, Discord preview doesn't work (so open it in a browser, you can also click to make file pixel and screen pixel match 1:1 for *really* pronounced effect)

Yep, I too tend to see that effect with red+blue. I saw it in Jon's are better, but not as pronounced as with this pattern.

Hire someone to write a specification purely by describing the reference implementation, and then calll it ajixel ('alleged jxl') (like RC4/ARCFOUR).

IIRC ISO has no copyright whatsoever on JPEG XL itself, just on the specification text, so you wouldn't need to do that

What would "copyright on JPEG XL" mean apart from copyright on the specification text?

Ah, I see what you're saying. Sure, there is no such thing as a copyright on the ideas behind a specification, so anyone writing a document describing it without copying the actual text (and presumably without calling it JPEG/ISO/...) wouldn't be a copyright infringement, even if they did so by starting from the actual spec.

(IANAL)

Oh god just knowing that someone has to care about details like this is giving me anxiety lol

I'm not sure where the boundary is, best to ask people who have more experience with it. But I do feel like taking the "meat" of the spec, stripping the ISO boilerplate, change the layout a bit, and upload it somewhere. Resisting the urge for now because I don't want to endanger the process 🙂

https://jxl-art.surma.technology/?zcode=y0xTqFSwUzDgUlDITFPwgzIhnHBdEF%2FXECwAEdL1c4UrAQFdheDUEhS%2Bn4I2nI9dB7IKVBMQlmKaAHcG2IhwnGbg1oNFi5GpKcTjFUDVpoYQ5chScLMB

I like how that one looks

``` if c > 0 if c > 1 if PPrev > 0 - Set 1 if N > 0 if N > 1 - N - 4 - Set 240 - Set 0 if PrevAbsErr > 0 - Set 150 if W > 0 - W - 1 - Set 0 if y > 0 if N > 0 if NW-N > -1 if N-NE > 0 - Set 0 - N + 0 if N-NE > 0 - N + 0 - Set 0 if NW-N > 0 if N-NE > -1 - NW + 0 - Set 0 if N-NE > -1 - N + 0 - Set 255 if x > 511 - Set 255 - Set 0 ```

adding some shadows

I definitely disagree with "anything under 64b is a waste"

Well that's his opinion. Or not, and he was just grumpy 😄 Either way, I love what we do, and that's what matters 🙂

or how about this 3D-ish sierpinski

``` if c > 0 if PrevAbsErr > 0 - Set 255 if N > 0 - N - 3 - Set 0 if y > 0 if W-NW > -1 if W-NW > 0 - Set 0 - Set 1 - Set 0 - Set 0 ```

quite minimalistic

34 bytes

sierpinski is drawn in the R channel using values 0 and 1, so not visible

but then G looks for pixels in R that are different from what median(N+W-NW,N,W) would predict, and makes those bright

fading down vertically

and then B does the same thing, but its previous channel is G so it gets an additional lighting up when the G gradient ends

Will the final version of both the JXL reference codec and libjxl contain build material for Windows (x86/x64/ARM64)?

it already does, no?

Oh wait... I may have seen VS-related files in some folders

How about modifications to its CMake system?

Very nice, any chance doing that in 32?

IIRC it works on windows, at least on mingw

and I think somebody managed to get it to compile in Visual Studio but don't quote me on that

Ok

How about on gcc or clang via cygwin?

should work in theory, if it doesn't please file bugs 🙂

Oh wait, JXL's repo recommends clang

No idea. Probably the tree encoding itself is not quite optimal yet, especially for such tiny trees.

I don't know if we can do much better there tbh 😛

On Visual Studio you can compile with clang. At least on VS 16 2019

What hybriduint config is used there? Could changing it make it cheaper to use largish constants like 255 repeatedly?

ah, it might be that we don't actually try all the options

that would be an easy improvement (but wouldn't help that specific image)

Or maybe we are spending bits on histograms for a tiny tree and a uniform histogram would be cheaper in total?

Is an ANS stream started for the tree?

https://jxl-art.surma.technology/?zcode=y0xT8NP181OwUzDmUlDQVXAsSw%2FX9gMyDIDczDSFcKgMipwRVCA4tUTByNQUAA%3D%3D

Change that first 3 to a 5 and you get

https://jxl-art.surma.technology/?zcode=y0xT8NP181OwUzDlUlDQVXAsSw%2FX9gMyDIDczDSFcKCMMZAJ5iQDOYZgDlSpY04OkGEEFYKqMIByUYwzRBWEaIQI6ioEp5YoGJmaAgA%3D

``` if c > 0 if Prev > 127 - Set 0 if N > 250 - AvgN+NW - 40 - AvgN+NW + 2 if y > 0 if W-NW > -1 if W-NW > 0 - Set 255 - Set 0 - Set 255 - Set 255 ```

```if c > 0 if PrevAbsErr > 3 - Set 255 if W > 20 - AvgW+N - 10 - Set 0 if N-NN > -1 if W > 238 - Set 238 if W > 2 if W-WW > -1 - AvgN+NE + 1 - W - 3 - Set 3 if N > 6 - AvgN+NW - 1 - Set 0 ```

"Electric Blues and Reds"

**Daft Punk intensifies**

```if c > 0 if PrevAbsErr > 3 - Set 0 if W > 240 - Set 100 - AvgW+N + 6 if N-NN > 3 - AvgW+N - 0 if W > 3 - AvgW+N - 2 - Set 255 ```

"The Essence of Pasta"

```if c > 0 if PrevAbsErr > 1 - Set 0 if W > 230 - Set 100 - AvgW+N + 10 if N-NN > 5 - AvgW+N - 0 if W > 3 - AvgW+N - 2 - Set 255 ```

good very good

"Synthwave meets acoustic"

``` if N > 3 if PrevAbsErr > 190 - N + 0 - AvgN+NW - 2 - Set 255 ```

"The Discovery of Color"

now things are getting funky

bypassing modular channel encoding completely and just letting it emit zero tokens after encoding the tree works

which simplifies jxl_from_tree and will make it easier to do more stuff

such as making jxl art in XYB instead of RGB

``` if c > 0 if c > 1 if x > 0 - W + 2 - Set -1000 if y > 0 - N + 2 - Set -1000 if g > 21 if g > 22 if g > 23 - Set 1500 - Set 900 - Set 500 - Set 100 ```

<@794205442175402004> What is the Prev* you started using?

Prev is the pixel value in the previous channel

of the pixel you're predicting

for R it is just always 0

for G it is R

for B it is G

in the RGB case

PPrev is the previous previous channel, so for B that would be R and for the others it is zero

PrevErr is the difference between clamped-gradient predictor and actual value in the previous channel

Those XYB greens are so surprisingly... satisfying. Especially in the darkest places.

"Transgender Sierpinski"

or let's just call it 'Sierpinska' ?

That one is _nice_

squeeze is weird

`- Set 128`

after doing squeeze

results in

What does Squeeze do?

Recursively downscales the image

Turning one channel into two channels of half the size at every step

The first new channel is a downscale (the 'squeezed' channel), the second are residuals minus a tendency

It's a nice fractal chessboard you get when just setting everything to a nonzero value

the single-group version of this is only 21 bytes

Looks the same, due to the fractal nature of this 🙂

I think some of this would also be good to add to this thread <https://www.pouet.net/topic.php?which=12091> to maintain interest

I wonder what other formats can do in sizes smaller than 256 bytes (even excluding the container size)

Besides flif, I doubt there are other codecs that can do this kind of stuff

But I would be happy to be proven wrong

21 bytes for a mebipixel, that is 0.000160217285 bpp

6241 pixels per bit

Almost a compression ratio of 150,000 to 1

Next up: train a neural network to predict pixels, and then define a codec that encodes every pixel as differences with that prediction.

0 byte files probably turn into cat pictures

😂

Forced progressive, no sequential to make predictions better (even for an AI it's probably easier to predict high frequencies from lower ones than to predict lower half from upper half of the image). Predictor would be something like HiFiC, but with multiple quality refinement passes for increasing resolutions.

Makes sense.

There were some plans to predict higher frequencies from lower ones in JPEG XL, but that was abandoned. I'm rethinking this idea... is there a way to encode low bitrate JPEG XL with HiFiC-encoded residuals (in an optional channel, in JPEG XL metadata or, if that's impossible, in a container)? That'd be fun.

I've just tried downloading HiFiC models. storage.googleapis.com/tensorflow_compression/metagraphs/hific-[lo/mi/hi].metagraph

693 MB for each model <:ReeCat:806087208678588437> Imagine embedding that monstrosity in encoder and decoder

```if c > 2 if c > 26 if c > 28 - Set 10 if y > 0 if W-NW > -1 if W-NW > 0 - Set 100 - Set 0 - Set 100 - Set 100 - Set 0 - W + 16 ```

in RGB, with Squeeze

"Subpixels"

default delta palette

```if y > 700 - Set -1 if x > 100 - NW + 1 if W > 31 - Set 0 - W + 1 ```

no idea how to tame that beast, but it certainly gives new expressivity for jxl art

Doing things in YCoCg is also interesting. It's cheaper than XYB because XYB requires to signal scaling multipliers while YCoCg is just an RCT

```if c > 1 - Set -50 if N > 0 if WGH > 0 - AvgN+NW + 1 - AvgN+NE - 1 - N + 50 ```

"The entrance to the rainbow cave"

"Lost in the rainbow cave"

"The center of the rainbow cave"

The weighted predictor error (WGH) has a lot of potential for interesting effects

```if c > 1 - Set -50 if N > 0 if WGH > 0 - AvgN+NE + 1 - AvgN+NE - 1 - N + 3 ```

like this smoke/cloud effect

but these are done to improve modular and to test modular and demonstrate its potential?

I can imagine an AI codec just sampling some of that and blitting it with Patches on a sky

these are done strictly for fun

or for art

but what you learned on it to improve jxl 0.3.8?

many things?

this i was thinking

it is an illustration of the power of the context modeling in modular mode

for now it is just that, a demo

doing images like the ones above in less than 100 bytes is just very cool

maybe at some point it will lead to encoder improvements, e.g. I could imagine using some of these very tiny images and using them as a coding tool in combination with Patches, but that will be very nontrivial

for now it is just an exploration, a demo, and art

``` if c > 1 - Set -50 if N > -255 if WGH > 0 - NW + 1 - NW - 1 - N + 5 ```

"Shredded flame"

OK, adding a bunch of extra things to the jxl_from_tree toy, <@!179701849576833024> please take a look at my merge request 🙂

``` /* Modular options */ RCT 4 /* Reversible Color Transform number 4 */ Width 800 Height 1000 GroupShift 3 /* Group size: 128 << 3 */ /* Other possible flags: XYB, Squeeze */ /* MA tree */ if c > 0 if PrevAbsErr > 3 - Set 255 if W > 20 - AvgW+N - 10 - Set 0 if N-NN > -1 if W > 238 - Set 238 if W > 2 if W-WW > -1 - AvgN+NE + 1 - W - 3 - Set 3 if N > 6 - AvgN+NW - 1 - Set 0 ```

that will be a valid input when my MR lands

I did that already 😛

producing this

er, looking at your MR, I mean

you are quick 🙂

did you get other nice results with squeeze? 😄

not really, haven't tried much yet though

but it's certainly very tricky to do anything other than the fractal chessboards 🙂

I sent a release email for that image, Fabian

it requires manual checking by wiki commons people it seems

I changed the image on the italian wiki page to just use the same image as on the english one

that also solves it

yes, <@!416586441058025472> please discuss this on <#794206170445119489>

```RCT 1 Width 2048 Height 1024 if c > 0 if Prev > 75 if Prev > 85 if g > 21 - Set -100 /* Second group */ - Set 50 /* First group */ - Set 255 - Set 0 if N > 0 - AvgN+NW - 1 - Set 255 ```

just having easy RCT makes it possible to do interesting colors much easier

also not having to worry about negative or >255 values is nice, just let decoder clamping do its thing

the group numbering is a bit tricky

I have no idea why the groups have number 21 and 22 here

I guess there are 32 AC groups here

ah no

it's because there are 17 quantization tables, potentially

and then 3 dcgroup thingies

and globalmodular

so that makes the streamid 0 for the global modular (which would be empty here), 1+k for the k-th modular LF group (those are also empty here), and 21+n for the n-th global HF group

or rather 18+3*nb_LFgroups+n

for images larger than 2048x2048

<@228116142185512960> new things are coming, it would be great if you could put it in the online tool too... 🤞

i was wondering - things like `Set -100` aren't currently legal in the online tool, right?

what do you use to quickly experiment with different predictors?

<@!794205442175402004> Let me know when it’s in the public repo 🙂

<@!119417751176609792> afaiu (cc <@!179701849576833024>), `Set -100` is perfectly valid syntactically, but since the current tool only works in RGB, it doesn’t make sense. Once we have way to select different color spaces, that would also be valid semantically.

aha

In 8-bit YCoCg, the range for Co and Cg is -255 to 255

But also: in the new code, out of bounds values are allowed (the decoder will clamp them at the end anyway)

_nice_

And that can be useful: you can e.g. use 'blacker than black' or 'whiter than white' to let gradient loops behave differently in useful ways

Or use it to make pixel values that have unusually large impact on e.g. an Avg predictor

What exactly is `RCT 1` vs `RCT 4`? A predefined set of reversible color transforms?

RCT 0 is just RGB, 1 is YCoCg

The rest.. uh

If you subtract 2 and divide by 7, that number determines what permutation of RGB to do

Then the remainder determines what to do after permutation, but I would need to look it up (on my phone atm)

nothing stopping you from (at least in theory) combining RCTs with XYB and YCbCr, btw... I have *no idea* if it makes any sense whatsoever, but you can 😄

that's correct 🙂

We could make a list, I suppose. It's things like R-G, G, B-G, or R, G-(R+B)/2,B-R

Ah YCbCr, forgot about that, haven't exposed that option yet

Combining RCTs with XYB/YCbCr could be nice for weird effects

``` RCT 3 Width 1024 Height 512 if WGH > 0 - NW + 3 - NW - 3 ```

25-byte cloud

```RCT 1 Width 1024 Height 1024 if c > 1 if N > -255 if N > 50 - N - 1 if N-NN > 0 - N + 1 - N - 1 - N + 1 if y > 0 if x > 0 if WGH > 0 - AvgN+NW + 3 - AvgN+NW - 3 if N > 0 - N - 1 - Set 300 if W > -10 - W - 2 - Set 300 ```

change the +-3 to +-1 and you get

And now JXL art actually went *nuts*... What will we have further down the road? Damn.

``` RCT 0 Width 1024 Height 1024 GroupShift 1 if y > 127 if x > 127 - Set 0 - Set 255 if x > 127 - Set 255 - Set 0 ```

``` RCT 1 Width 1024 Height 1024 if y > 0 if y > 666 if WGH > 0 - NE + 1 - NE - 1 if WGH > 0 - AvgN+NW + 1 - AvgN+NW - 1 if c > 1 - Set 0 if W > -200 - W - 2 - Set 300 ```

these are getting more interesting

that one is my new wallpaper

alas, until gnome supports jxl wallpapers i do need to store it as a 1.95MB PNG

<@!179701849576833024> is there an easy way to see distributions?

https://twitter.com/jonsneyers/status/1378971035438055425

trying to figure out how to do the xor pattern

This is a great idea.

the encoder doesn't learn offsets, so the debug trees have zeroes there and the offset will be in the distribution

what does "see distributions" mean exactly?

if it's a singleton, what's the value

ah - not that I can think of

it might be easier to put the if in the leaf stage of the tree learning...

``` RCT 1 if W-NW > -1 if NW-N > -1 if N > 254 if c > 1 - Set -127 - Set 0 if W > 0 - W + 1 if c > 0 - W + 3 - W + 1 - NW + 0 - Select + 1 ```

"Colorful XOR"

I have jxl wallpaper in gnome

The pixbuf plugin work

ooh

``` RCT 1 if c > 0 if Prev > 50 if Prev > 200 if Prev > 350 if Prev > 400 - Set 0 - Set -400 - Set 0 - Set 255 - Set 100 if W-NW > -1 if NW-N > -1 if N > 510 - Set 0 - W + 1 - NW + 0 - Select + 1 ```

``` RCT 3 if W-NW > -1 if NW-N > -1 if N > 511 - Set -255 - W + 1 - NW + 0 - Select + 1 ```

"The Queen's Exclusive Fractal"

add Squeeze to that, and you get

"Linnen Collection"

``` RCT 15 Height 1020 Width 1020 if c > 0 if c > 1 if y > 0 if N-NN > -1 - N - 1 - N + 0 - Set 255 if x > 0 if W-WW > -1 - W - 1 - W + 0 - Set 255 if W-NW > -1 if NW-N > -1 if N > 253 - Set 1 - W + 1 - NW + 0 - Select + 1 ```

"Minor Misalignment"

I love these

We don't have xor in MA trees so I thought we couldn't do the xor pattern

But then I gave a xor pattern to cjxl and with -s 9 -I 1 it did find a tree

Turns out you don't need xor to implement the xor pattern :)

finally found the "clean" xor pattern: https://jxl-art.surma.technology/?zcode=y0xTCNf1C1ewU9A15FLITFPwA3KhPDAXyDYyNQFyFHQVglNLFAxATJBMJVAGwgFJhStoKxhCeUDJCpySSKboAi0DygDZIMGc1OQSsDoA

Perfecting my chessboards

``` RCT 15 Height 2048 Width 2048 if c > 0 if g > 22 if y > 0 if N-NN > 0 - N + 0 - N + 1 - Set -255 if y > 0 if N-NN > -1 - N - 1 - N + 0 - Set 255 if W-NW > -1 if NW-N > -1 if N > 255 - Set -255 - W + 1 - NW + 0 - Select + 1 ```

'The Queen's Ice and Fire'

trippy

it's 2048x2048 so four groups, because I wanted it to be a full chessboard in a nice resolution

the black squares are mostly Y < 0, so impossible colors

they usually clamp to black, but if the chroma is strong enough and the black not deep enough, there is some color still

it's all impossible colors in the black squares, that you wouldn't get from doing YCoCg on a normal RGB image. Good test image to verify clamping behavior of decoders 🙂

Oh Nice!

I didn’t think that was possible with the current iteration of the playground

I guess “Select” plays a big role here?

Maybe we can find a better description than “predictor from lossless WebP” 😅

it's either N or W, depending on which is closer to N+W-NW (N if it's a tie)

Something similar to PNG's Paeth, I guess?

Yes, but slightly simpler and better for compression

does the board somehow look slanted to anyone else?

I’m almost sure that it’s not and that it’s just an optical illusion

but I find it hard to shake off

Yes, I see it too, and I think it's an illusion.

Yep, just an illusion (and it's possible to "correct" the slant by changing the angle of view)

``` RCT 21 Height 1024 Width 1024 if y > 350 if WGH > 0 - AvgN+NE + 1 - AvgN+NE - 1 if W-NW > -1 if NW-N > -1 if N > 254 if c > 0 - Set -255 - Set 0 - W + 1 - NW + 0 - Select + 1 ```

"Evaporating Queen's Fractal"

I should probably orient this one upside down

*Mr. Jon, I don't feel so good...*

It's better oriented differently

https://tenor.com/view/thanos-infinity-gauntlet-snap-finger-snap-gif-12502580

https://tenor.com/view/i-dont-feel-so-good-mr-stark-avengers-infinity-war-tony-stark-spiderman-gif-15541848

how did you flip it? exif?

Thanks!

TIL PNG also has a couple predictors. Interesting!