The JPEG XL image format has demo potential
category: general [glöplog]
The format includes powerful image "predictors" that can conjure images out of nothing. According to Wikipedia:
One of the JPEG XL's developers is playing with predictors and posting the results on Twitter. In JPEG XL the following image is 59 bytes.
The lighthouse on Mt. Sierpinski
Ever Given, 85 bytes.
Quote:
Prediction is run using a pixel-by-pixel decorrelator without side information, including a parametrized self-correcting weighted ensemble of predictors. Context modeling includes specialized static models and powerful meta-adaptive models that take local error into account, with a signalled tree structure and predictor selection per context. Entropy coding is LZ77-enabled and can use both Asymmetric Numeral Systems and Huffman coding (for low complexity encoders or for reducing overhead of short streams).
One of the JPEG XL's developers is playing with predictors and posting the results on Twitter. In JPEG XL the following image is 59 bytes.
The lighthouse on Mt. Sierpinski
Ever Given, 85 bytes.
Where do I see the original compact images? The jpgs appears to have been converted to a more optimal bigger jpg file.
s/One of the JPEG XL's developers/One of JPEG XL's developers/
There are a few hex dumps in the original Twitter thread. I see that the JPEG XL Discord has the binary file and/or the source code for many of these images in #jxl-art. The source code is a bunch of conditionals containing either nested conditionals or statements that modify a predictor. It is executed for every pixel.
There are a few hex dumps in the original Twitter thread. I see that the JPEG XL Discord has the binary file and/or the source code for many of these images in #jxl-art. The source code is a bunch of conditionals containing either nested conditionals or statements that modify a predictor. It is executed for every pixel.
Thanks for the interesting information. I have a question: How big is the decoder?
On x86_64 Linux the full libjxl_dec.so.0.3.7 built with the default configuration + -Os and stripped is a whopping 1.6 MiB. You can probably reduce it if you disable various features, but I haven't done it. The predictor code on its own without the includes is around 650 lines of C++.
But I think the format is more interesting as a potential platform. You could have a 256-byte or even smaller JPEG XL procedural graphics compo.
But I think the format is more interesting as a potential platform. You could have a 256-byte or even smaller JPEG XL procedural graphics compo.
(Sorry, the topic should have been "The JPEG XL image format has procedural graphics potential" to make that clear.)
In no time, some JPEG XL devs have made a little online playground to test tiny tree structures. You can edit, share links, and download JXL and PNG files.
A 36 byte thingie i made
A 36 byte thingie i made
Quote:
In no time, some JPEG XL devs have made a little online playground to test tiny tree structures. You can edit, share links, and download JXL and PNG files.
A 36 byte thingie i made
Incredibly cool stuff!
now this is some cool stuff!
HellMood, nice graphic, and thanks for the playground link.
I've implemented Rule 110 in the playground. Which means that JPEG XL predictors are Turning-complete (or would be on an infinite image). You can modify the source code to implement any elementary cellular automaton.
Here it is, 50 bytes.
The source code with comments and a makefile to remove the comments:
I've implemented Rule 110 in the playground. Which means that JPEG XL predictors are Turning-complete (or would be on an infinite image). You can modify the source code to implement any elementary cellular automaton.
Here it is, 50 bytes.
The source code with comments and a makefile to remove the comments:
Code:
> 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|' $< > $@
Thanks to rgba and _wb_ the famous sierpinski is now down to 32 bytes =)
see here
You will be likely able to watch this 32 byte file normally in
your browser in a few weeks =)
see here
You will be likely able to watch this 32 byte file normally in
your browser in a few weeks =)
Wouldn't it be smarter to replace JPEG XL with a simple Turing-complete language?
I don't have any CS degree but isn't the main purpose of JPEG XL to encode images? You usually don't encode images in programming languages. Any Turing completeness in there is just a bonus.
El Topo, spot on. The purpose of JPEG XL is : general purpose image compression. Turing completeness is a bonus. Meanwhile, the artist section amongst the developers ( ; ) ) explore more nodes and features of the format, which i will think will slowly also be available in the online tool to play with :)
for example :
(chross channel access to hide meta information in one color channel )
Join the discord to find out more : https://discord.gg/XVHWYSBDfZ
for example :
(chross channel access to hide meta information in one color channel )
Join the discord to find out more : https://discord.gg/XVHWYSBDfZ
We are having a compo for this at Inércia this year!
Here is a short video interview explaining the whole thing: link
Looking forward to seeing more people demonstrate what art can be done with JPEG XL predictors.
Here is a short video interview explaining the whole thing: link
Looking forward to seeing more people demonstrate what art can be done with JPEG XL predictors.
