JPEG XL

MA tree learning might be worse than linear in the number of pixels, or is it linear, <@179701849576833024> ?

Hard to say

An upper bound is tree height * num pixels

Which is likely n log n

The constant factor is not tiny though 😉

oof

The thing is: an encoder could basically spend as much effort as it wants on making a good tree

Genetic algorithms anybody? :p

The search space is huge

But even with fixed trees (like what -e 3 and lower do) results are not too bad

Very likely better trade-offs between encode time and compression density are possible

And also likely better things than -e 9 can be done — the gap between -e 9 and exhaustive compression optimization is still pretty big

Also, for -e 3 it would be nice to have some quick switching method for non-photographic images to something similar to -e 2

Because -e 3 is good for photos, but can be very inefficient for artificial images

https://news.ycombinator.com/item?id=28500014

https://twitter.com/HenriHelvetica/status/1437875246732881934?s=19

do we know it on 15th september

> This free event

Signed up!

Perhaps it is worth updating the presentation with examples of using salience in progressive decoding, experiments with separate encoding and update the lossless comparisons

Also I joined having win 7 and not want to download Zoom.exe probably i will Watch on phone and making some screenshots

Are you presenting, and will it be the same presentation as last time?

Henri wants the event a bit shorter I think

So no, it will not be the same presentation, you can just watch the recording for that :)

It's supposed to be more of an update on jxl

Not sure what I should say / put the emphasis on

What should be mentioned in a 15 minute update regarding jxl? Say assuming you already know what I said at last year's event

Progress in getting it supported in various popular apps like chrome/firefox

Features that have been implemented since the last one

Elevator speech on what JPEG-XL is for any new people

Makes sense

https://youtu.be/cGyLHxn16pE

Haven't watched yet

<@228116142185512960> not all devices can display all sRGB colors, in fact most cannot really (but they do cover some percentage of the sRGB gamut)

Nice intro on colorspaces

Oh really? I read that it was called the "safe color space" because of that

Guess I'll have to read some more :D

yeah, coverage of gamuts is pretty bad

it *is* true that most displays assume the input is in sRGB though

but what they'll actually show is anybody's bet

I have a fancy monitor that can show 100% of sRGB (and a good chunk of Adobe RGB 1998 and P3), but a typical display is not that accurate

my new monitor supposedly can too, but i had to specifically look for that

they're getting pretty wide now though, and imo it's also becoming a problem that they're not calibrated and srgb & rec709 content becomes super oversaturated

my cheapo viewsonic is 150% srgb volume

my older secondary monitors which are also super cheap happened to be just close to 100% srgb volume, so they weren't noticeably oversaturated

of course not accurate out of the box, but i find it less offensive than being over saturated

Is Surma a first or last name?

my viewsonic vx2768 (1440p 144hz ips) was 360 cad

there are even cheaper ones now

cheap 100% P3 monitors might interpret sRGB colors as P3 and oversaturate everything

yeah they never come with a profile

actually that makes no sense

all monitors do that

they dont interpret anything

nobody even ever switches on the srgb mode on their monitor because it's too dark for most people

mine is only 99% sRGB, but probably because it's 35"

anything above 98% coverage is pretty much as good as it gets

i use pre-calibrated sRGB mode and its fine

🤔 <@!228116142185512960> are u using a joycon to advance slides or smth <:kekw:808717074305122316>

but yeah only recently are we getting laptops that advertise 100% of srgb colour space on the screens unless u pay obscene prices <:kekw:808717074305122316>

yeah laptop displays suck

yeah same

it's a problem for those who don't have a colorimeter

but at the same time those who don't also wouldn't know

I created an animated JXL test file to optimize my qt-jpegxl-image-plugin better in the future. Now it consumes lot of memory when playing this file: http://188.121.162.14/jxl/animation.jxl Google Chrome on my machine have some troubles to play it fluently. Any similarity in the animation to actual persons, living or dead, or actual events, is purely "coincidental". 🙂 As a comparison, here is AVIF variant of the animation: http://188.121.162.14/jxl/animation.avif

Does this AVIF use AV1?

yes, AVIF use AV1

I think Chrome has a limit on how many pixels it keeps in memory when playing animation, so probably for this one it cannot buffer all frames and has to re-decode a lot

❌ **You are not able to use moderation commands. You require the `manageMessages` permission.**

(probably the same is true for avif, but there re-decode is likely a lot lighter because it uses inter-frame while jxl has intra only)

If you let it loop few times it gets to perform better.

Hm, maybe it just cannot decode fast enough then

Intra only is kind of heavy compared to having 99% inter frames

This is why for stuff like this, actual video codecs like av1 are better than still image codecs like jxl

The animation has 11seconds but it takes approximately 20seconds to decode all frames on my computer.

Interesting, I cannot decode it as AV1 video via Firefox. <:Thonk:805904896879493180>

it doesnt use the same video decoder in chrome

it uses libavif

firefox uses dav1d directly

It is because container has slightly different structure.

How did you create the AVIF?

https://github.com/AOMediaCodec/libavif

Decoded video using ffmpeg and pipe into avifenc: ffmpeg -i dog.mp4 -f yuv4mpegpipe -pix_fmt yuv444p - | avifenc --stdin dog.avif --cicp 1/13/6 --speed 10 --fps 30

what about this

https://twitter.com/HenriHelvetica/status/1437875246732881934

i have not received any notification on Friday

and i'm suscribed to the email

<@!532010383041363969> sorry for ping, On 20210909 I get some vardct file size issue for specific manga case (already denoise grayscale png, avif can correct compress this case). > https://discord.com/channels/794206087879852103/794206087879852106/885516651657822219 In my test, disable gaborish can this fix file size issue, I think gaborish probably have some little issue? > https://discord.com/channels/794206087879852103/794206087879852106/885915822718091304

Oh, is it too late for more spline improvements now?

jpeg xl is frozen so yeah

I thought only part of it was frozen: future decoders will support all legacy encoders from now, so decoders could change? But maybe there's some wiggle room for a few additional features,

the entire bitstream format is frozen afaik

and that includes its defined splines

which happen to be catmull-rom splines with delta encoded control points stored as integers

i think it's the other way around. all future encoders have to produce files that'll work on the decoders we have now. that way a viewer can support jpeg xl without having to continuously upgrade to the latest decoder.

No optional extensions that can be ignored by decoders? So a future decoder can show those "extra" features? Sorry, I might've mixed up forwards vs backwards compatibility. This part is from memory: there was a slide about the standards process with ~4 stages listed. And something about a "missing release" specifically that would freeze decoders(?) too.

technically what's frozen is the bitstream, which means any future encoder must produce files compliant with the bitstream that is defined right now. i'm not sure if the bitstream allows for extensions.

Future decoders will be able to decode what current encoders produce (that was the aim for v0.2)

Future encoders will produce things that current decoders can decode (that was the aim for v0.4)

There are still a few open questions where the spec is not fully clear atm, like the interaction between upsampling and spline rendering

So those still need to be clarified (we will resolve them in the 2nd edition of the spec). In practice it will not cause any issues except maybe with some jxlart or other artificial bitstreams

(anything cjxl produced should remain decodable, etc)

There is room for extensions in the bitstream, but none have been planned so far.

if there is a bug it needs to be fixed

what constitutes a bug in the code or a bug in the spec is consideration by the respective decisionmakers (code is compared against spec, for spec the committee with the help of committee leads will decide)

adding more expressivity is likely not a bug but could be in rare cases

DAMN IT <@!792428046497611796> YOU \*\*\*\*\*\* IT'S STILL COMPRESSING 🤣

...I give up.

PLEASE HELP ME This thing is just 93 KiB big as a PNG and 506 KiB as a JXL...

(Squeeze helps a lot, I've just checked and disabling Squeeze increases file size to 1005 KiB.)

What did you try so far?

I would expect max group size to help

`~/libjxl/build/tools/cjxl who-said-interlacing-reduces-compressibility.png who-said-interlacing-reduces-compressibility.jxl -m -s 8 -g 3 -E 3 -I 1 --patches=0 -R 1`

Those settings produced the 506 KiB version.

I've tried `-s 9`, but it was **ridiculously** slow (I aborted it without getting result).

is this somehow abusing the interlace pattern to compress, like the compressibility of the top and bottom field separately outweighs the total compressibility?

like using adam7 or something https://en.wikipedia.org/wiki/File:Adam7_passes.gif

Exactly, it's from allrgb.com and it's designed for PNG. https://allrgb.com/who-said-interlacing-reduces-compressibility

Ah

howd you even manage to get it to 500kb

default settings d 0 is 19mb

Might be impossible to beat png in such a pathological case

Yeah, `-s 7` with my settings balloons the file size to ~20 MiB.

oh didnt see your settings

Perhaps doing the last adam7 pass as a separate frame could help here

Duplicating the odd lines to the even lines and using alternating lines of alpha=0, alpha=255, or something

I mean, this is a bit like expecting another codec to compress JXL art well 😛 ain't gonna happen...

Yes, that's exactly what it is - exploiting a very specific codec feature of png that magically makes it compress much better than normal

Try a non adam7 interlaced version of the png

most of those (non interlaced) on that website dont compress better as jxl

Is there any software that'd allow me to see intermediate Adam7 passes of a PNG?

I think usually for the non-interlaced ones, jxl should be able to match png, but it might require weird options or things the encoder isn't currently trying

Truncating the file and opening it in a viewer that does not just refuse to show partial files should work

But I don't know how to truncate *exactly* on particular passes...

Ah, not sure if adam7 puts each pass in a separate chunk or not, if not then it is indeed tricky to find the truncation points. It might be easier to hack a png decoder then to stop after pass N.

adam 7 in jxl

The thing with Adam7 is that each pass is encoded as a separate image, where pass N is not used at all to help predict pass N+1

Which is usually bad for compression since you never predict from spatially nearby pixels

Except of course in this particular example where it is good for compression because the image is constructed that way

If Adam7 is so good, why isn't there an Adam8?

Flif does Adam-infinity

But it does predict from previous passes too

So it likely still doesn't beat png on that pathological example 😅

Squeeze is also a kind of Adam-infinity, except it's not doing interlacing like png/flif (i.e. nearest neighbor subsampling, with all the aliasing artifacts that creates for the progressive previews) , but it's doing actual downscaling

smh bitorrent

Yes, I'm on two private trackers, do you have any problem? 🏴‍☠️

🏴‍☠️

plox donate freeleech content to this poor boi <:FeelsSadMan:808221433243107338>

Yup, that's my child. 😜 I remember how I designed and coded the tool for making it. I used sw for mass personalised communication. Good old days…

Did you really say "pathological"? And did you say it twice? It's a png-compression-art and not pathology… 😜

Anyway, I'm glad that my image provoked such a fruitful debate. 😆

And it also includes 389 B of metadata so the challenge is even harder… 😉

It's all in a single IDAT.

BTW, as soon as jxl becomes supported in major browsers by default, it would be cool to contribute to allrgb.com with it. Any applicants…? 🙂

"pathological" is just a word to indicate an artificially constructed and/or very atypical edge case.

E.g. all jxl art are pathological cases

https://jxl-art.surma.technology/?zcode=hZG9DsIwDIT3PIV3VCk_Jm0WZqYKiSEPAKXtiioEb0-SxkeFkFja7xzfOXJUnK_LRKyDV8dhHqdlZTXf6EIHMoqIEp_uwyNJTQ316Zsrm1IkXfueqJgsX_BwThyTtOWgkAU5EIP2IA9qQR0oCDkNwgyHGQ4zHGa4vWroPCzljvlvfIXkW4G7Cp4rdNIcpNkY6TZW2g0zMpHewhHEYbU4rBWHZU2qrDM_QVktlllEkX1ZEtcCVa_e6J526wN-nco7fbLi36z4I-sN

that's a rather boring one

but 142 bytes is not bad

jxl 3dlut

here is a slightly more interesting one:

That's basically this: https://allrgb.com/thingy – but 395× smaller. 🙂

just relied on tree learning to figure it out here, can probably reduce that size with a hand written tree

``` include <stdio.h> #include <stdlib.h> #define W 4096 #define H 4096 int main(int argc, char *argv[]) { FILE *fp = fopen("xor.ppm","wb"); fprintf(fp,"P6\n%i %i\n255\n",W,H); for (int y = 0; y < H; y++) { for (int x = 0; x < W; x++) { int a = (x ^ y) % 256; fputc(a,fp); fputc((x / 256) + 16*(y/256),fp); fputc(((x % 256)-a) % 256,fp); } } } ```

this is how I produce such images

A little curious, if I compare different lossy encoder, decompress compressed image to png(pixel), (change color space XYB to RGB or ycbcr to RGB, and make sure png on same bit depth), this image quality compare should be a fair compare? And color space transform to RGB(XYB to RGB or ycbcr to RGB) should not affect quality?

Best to use 16-bit png for now, 8-bit introduces some banding since it's quantized without dithering

If original png is 8-bit depth, still necessary use 16-bit depth for jxl decompress? (original png 8-bit => jxl vardct => png)

always

less rounding errors for any intermediate calculation

I understand, thank you very much 🙂 (original png 8-bit depth => jxl vardct => decompress png 16-bit depth => png lossless pingo 8-bit) Can I use png lossless compress(pingo) transform decompress png 16-bit depth to 8-bit depth?

pingo will just drop the 8 lsb iirc

I don't know what the easiest way is to convert 16-bit to 8-bit properly (with dithering), <@456226577798135808> do you know?

The easiest way is to push <@!179701849576833024>'s "random CL" into main. ;P Otherwise you have to use Image Magick or GIMP.

Does JPEG XL do (chroma?) subsampling with its XYB colourspace?

Also what do each of the channels represent?

1. afaik no, only ycbcr subsampling in jpeg mode

What does the XYB colourspace do then? The reason to use YCbCr in JPEG is to be able to subsample right?

the only snippet on wikipedia is still <https://en.wikipedia.org/wiki/LMS_color_space#Image_processing>

the reason to use ycbcr is because compatibility

Fair. I assume a lot of software and hardware like TVs doesn't like RGB. No compression advantage without the subsampling though.

other things could subsample too but subsampling is ehhhh so its intentionally not implemented elsewhere

subsampling is v poor way to compress stuff tbh

it kinda makes sense in video hw but jxl is mostly optimized for software because that makes the most sense for img codec

Fair. I've been writing a talk on JPEG (1992) and find it pretty incredible how you can discard 50% of the raw pixels and the image looks basically the same (at least in photographic content)

depending on resolution you could discard 75% :^) but yes for pretty primitive technique its pretty good for some use cases, but jxl have better tools than that

it makes sense that chroma subsampling doesnt work well anymore since ideally the same image at 2x the size should compress the same

so why should an image 2x smaller compress smaller

because at this point we're not talking about pixels and image data but an actual image that humans look at

Unless there is a huge amount of pixel by pixel detail in the colour, yeah I imaging that should be the case.

i never use jxl for lossy but i gather it knows what to do in those high-frequency conditions like noise and does them well

No, only more quantization -- especially for B in high frequencies

YCbCr is not just for subsampling - it's also for decorrelation and to basically remove the lsb of red and blue

subsampling is an effective but very crude compression tool

So they are more aggressively compressed, just not though subsampling for the reasons discussed above.

Thank you very much.

also don’t forget that it’s quantized in DCT space

4:2:0 chroma subsampling is exactly the same thing as zeroing 75% of the high-frequency DCT coefficients

In jpeg it has the advantage of effectively using 16x16 blocks for chroma, also causing cheaper signaling for chroma DC (important because jpeg DC compression is weak)

exactly is a strong word there

I'd use the description 'is related' for that

after all things like the dct are mathematical objects and the word exact has a more exact meaning in mathematics

What is sigma prediction? 🤔 https://github.com/mkondratek/jpeg-xl-sigma-prediction/pull/1

There are multiple ways to do subsampling/upsampling; doing DCT and keeping only the 1/4 low frequency coeffs is one of them.

No idea.

only allows sigma males in

Agreed! The results will be however different from spatial subsampling (and visually greatly inferior to spatial subsampling).

however, having the possibility of not to quantize everything, i.e., just higher quantization multipliers for the remaining coefficients can lead to more flexibility in visual compromises than subsampling

Purely guessing here. If I was asked to make 'sigma prediction', I'd consider it as a possible tool for context modeling -- to use different contexts for predicted variability in the signal. The context trees in JPEG XL should be powerful enough to do many such things.

Perhaps this is some work from Jarek Duda's students (Jagiellonian University) 🤔

How to use magick and cjxl in windows cli pipe? > magick convert test.webp png:- | cjxl - test.jxl

I think cjxl stdio pipe probably have some issue.🤔 > https://github.com/libjxl/libjxl/issues/542

look like stdin issue still happen on JPEG XL encoder v0.7.0 233db00 > magick convert test.webp png:- | cjxl - test.jxl > Failed to read image -.

found this looking for corrupt images <https://miroware.io/corrupt/>

Hey guys, I was hoping to use jxl for a "Computer Art" class project, can you guys let me know if my idea makes any sense? Because of the fact JPEG XL images can look super cool in only a couple of bytes, would it be possible to essentially just "generate X random bytes" and create a decent looking image once every Y tries?

probably would need to have a couple bytes set so that the image "compiles" right?

maybe instead of doing random bytes, using smth like https://jxl-art.surma.technology/ and changing just the numbers would make more sense?

Random bitstreams are very likely not to decode, since the ANS "checksum" will not be correct

Some genetic algorithm on MA trees could be a nice generator though

you could generate a random MA tree and it would decode

(or random input to jxl-art in the correct format)

Strictly random MA trees would not likely decode, but if you define rules to only generate valid trees with random parameters, that might be practical.

right, but that's probably not hard

Random trees likely produce not so interesting output though. I think it's better to start from some interesting tree, and then propose some potential mutations (changing a number, adding or removing a branch), and make something interactive/visual where you can grow a population of interesting trees

Or can do it non-interactively by using some heuristic for the tree fitness — compressed size as a png is a possibly good indicator (too small: probably boring / too large: probably too noise-like)

I still can't success use stdin pipe on cjxl,😢 but other cli tools can success use stdio pipe(magick, jpegtran, oxipng), maybe my pipe command is wrong? > windows 10 cmd.exe > magick convert test.webp png:- | cjxl - test.jxl > > Failed to read image -.

I think this issue happen in cjxl.cc. > https://github.com/libjxl/libjxl/blob/08dcb04eb2bed2a9f6875859b4bb9a4080a2d7ec/tools/cjxl.cc#L751 > fprintf(stderr, "Failed to read image %s.\n", args.params.file_in);

Maybe the stdin code doesn't work on windows, it's not convenient for me to debug that since I have no windows environment

starting from an existing image is something I considered and I guess would more likely yield pretty results

I dunno what kind of project you want to do, you can also just manually create some jxl art 😀

I want it to be more of a generator with some user input (the initial image input and maybe picking the next "path" to take).

Something like this as a starting point: https://jxl-art.surma.technology/?zcode=C3IOUTDgcsosSUktKMlQMOYKLixNTa1K5eLiykxTSFawUzDkUlAAMmvCa4AccyAHzA0HcgzAHAUFXQW_cAVdUzgvXMEUWRmyTGpmekZJaoqCriGmmAUXiBucWgI0GAA

Change a number by +1 or -1 and you get something else

Can also add some more branches if you want more degrees of freedom

Or change the tree structure itself, but that's a bit trickier than just changing numbers

Can you recommend me any good reads about the MA trees? I admit I don't really know much about any of this <a:peepoSadLove:574680544265109504>

So I maybe get an idea on how useful it'd be to just use the "code" approach that the jxl-art app provides

The help screen in the jxl-art app is currently the best documentation we have 😅

I guess just changing numbers in the "code" and maybe adding more ifs will be enough of a challenge then <:VUTrtzW:498624900957732866>

Thanks a lot btw <:peepolove:827833315666558996>

I understand, thank you 🙂 Hope we can get stdin on windows in near future.

That was quite an interesting ImageReady 1.2 !

Who here was participating in it?

https://tenor.com/view/tumbleweed-crickets-chirping-silence-anyone-there-hello-there-gif-18512183

I hope the recordings will be published (and preferably not for several months like last time), watching live is not always convenient

me

They will be published, and I assume faster than last time

~~Totally didn't forget about it or anything 👀~~

~~Will just blame too much trappist beer~~

Trappist beer is always a valid excuse

Lol, true

Especially Rochefort

And beer from Achelse Kluis, which is my favorite

Not too strong, not too light and just a perfect taste

Went to Belgium 2 weeks ago and that was the first time I drank trappist beer... and still the best I ever drank :p

Rochefort second though

Belgian trappist, best trappist :p

~~Oof, I become kinda spammy after too many... special beers~~

Chimay Bleu and Westvleteren 12 are my favorites in autumn/winter

Rochefort 10 too

In summer, Orval and Westmalle Trippel are nice

(and this is on-topic, just not quite on the expected topic)

Rochefort 10 is <:PepeOK:805388754545934396>

My favorite and same for one of my best friends

Regret not buying it

It's 3 bucks per bottle here sadly

And lol, true. Trappist is probably the most random on topic topic yet :p

And tf. Campo Viejo Rioja Garnacha was on sale and it's the weirdest wine I've had yet. It has 3 completely different taste stages

I didn't know you were a wine enjoyer 😳

I like it sometimes

Used to like it more, but then I drank a little too much one day and now alcoholic drinks are kinda gross to me <:Cheems:890866831047417898>

https://www.phoronix.com/scan.php?page=article&item=windows11-wsl2-good&num=3 jxl 0.5 running under wsl actually performed better than bare metal with a jpg input

huh

On 27/09/2021 10:32, Ziemowit Zabawa wrote: > Hello. > I found your email by your GitHub account associated with your AUR username. I kindly ask you to update FLIF repositories since there were some quite important updates recently, including those related to FLIF being superseded by JPEG XL. While we're at it, why not join our Discord server? It's our main place for JXL-related discussions (libjxl core devs are there!) and I couldn't find you there. > > Regards, > Ziemowit Hello Ziemowit, Thank you for reaching me. The stable AUR flif package is up-to-date with upstream flif (at version 0.3, the latest released). So, there is no update to be made. And the AUR flif-git package does not need regular updates, since it updates the version automatically when running makepkg. Thank you for inviting me for the Discord server. -- Best regards, Daniel Bermond

<@!794205442175402004> maybe make the "final" FLIF v0.4 tag on GitHub?

note that the “standard” procedure to request an update of an AUR package is to click “Flag package out-of-date”

so once 0.4 is tagged, we can go to https://aur.archlinux.org/pkgbase/flif/flag/ to notify the maintainer

Nice to know, thanks!

By the way there are 2 warnings that I don't know exactly how to fix since I don't know original PR author's intentions: ``` image/image-pam.cpp: In function ‘bool image_load_pam_fp(FILE*, Image&)’: image/image-pam.cpp:90:27: warning: comparison of integer expressions of different signedness: ‘ColorVal’ {aka ‘int’} and ‘unsigned int’ [-Wsign-compare] 90 | if (pixel > maxval) | ~~~~~~^~~~~~~~ image/image-pam.cpp:106:27: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare] 106 | if (pixel > maxval) | ~~~~~~^~~~~~~~```

`pixel` is `ColorVal`, which is either `int32_t` if HDR is enabled during build or `int16_t` if it's not. `maxval` is an `unsigned int`.

Can make maxval int32_t, since pam/ppm have at most 65535 as maxval

And how the hell is `pixel` calculated? What data type is needed to store that **safely**? `ColorVal pixel = (msb << 8) + lsb;` Remember that `ColorVal` can be both `int32_t` or `int16_t` depending on the circumstances, and weird bit-shifts combined with changing variable sizes don't make the issue easier...

Flif code likely stil has lots of not very safe/portable code in it.

Hello, I plan use jxl on some legacy platform, so I need decompress compressed jxl to png format, but I notice djxl embed png chunks cHRM, gAMA, sRGB on decompress png file, imagemagick also have similar behavior(embed gAMA). I research this behavior and find this artile, look like gamma 2.2 will let image colors slightly different. > https://stackoverflow.com/questions/43784957/why-do-the-color-profile-spaces-of-my-png-images-change-when-processed-with-perl I don't really understand why libjxl and imagemagick have this behavior, could somebody can teach me about this?

the sRGB transfer curve is not a pure gamma curve: it's linear in the very darks and then switches to a gamma function

I understand if png iCCP chunk is exist, decode will use icc profile first, If original png don't have iCCP, new image embed chunks gAMA, sRGB, those chucks will give me colors different result on my legacy platform(like that artile)?

if the original PNG doesn't have any color info, cjxl will assume it is sRGB and encode it like that

which is the correct thing to do

sadly a lot of viewers will do something else in this case: they will just send the pixels to the screen and conveniently assume that "no color info" means "it happens to be the same colorspace as the screen"

since a lot of screens are not sRGB anymore nowadays but e.g. Display P3, those viewers do something incorrect

If gAMA, sRGB exist in same png file, it's mean gamma 2.2 + srgb colorspace, For general LCD display I will get some color different(compare no color info original png)?

Sorry, I didn't make it clear, I mean for no color info png, general decoder will Implied assume this png is gamma 2.2 + srgb colorspace(gAMA, sRGB), so if new png explicit define gamma 2.2 + srgb colorspace(gAMA, sRGB), general decoder still give me the same result(no color different)?

I think sRGB is supposed to overrule gAMA

If decode only use sRGB chunk, why djxl and imagemagick embed chunk gAMA(gamma 2.2)?

that's a recommended practice to get graceful fallback in viewers that don't understand the sRGB chunk

back in 1996, when PNG was standardized, things like ICC profiles barely existed

oh, I got it, so priority order should like this iCCP > sRGB > gAMA + cHRM, I have another question, If on general LCD display, same png image, define sRGB or define gAMA + cHRM(gamma 2.2) both define should display same result(no color different)? That article happen image colors slightly different case, only happen on no color management viewer, if use libpng decode should not happen this situation?

I got it, look like png sRGB ≒ gAMA + cHRM(gamma 2.2), <@!794205442175402004> Thank you very much for your teach, look like I don't need worry png gAMA. 🙂 > Unlike most other RGB color spaces, the sRGB gamma cannot be expressed as a single numerical value. The overall gamma is approximately 2.2 > https://en.wikipedia.org/wiki/SRGB

🤔 https://twitter.com/kornelski/status/1444686850401112074

re: gAMA and sRGB, imagemagick has an unfortunate bug in that it seems to write the gAMA chunk of 0.45455 that PNG recommends for compatibility, but _not_ the actual sRGB chunk

so software that interprets PNGs as it should ends up displaying the image differently than if it had been tagged as sRGB

this recent PR: https://github.com/libjxl/libjxl/pull/270 made it so that the PNG written back by `djxl` would have the same tags as the original instead of an ICC profile corresponding to our interpretation of them

so that other software would display the original and decoded files identically, whether correctly or not

(instead of “the decoded file correctly because of our ICC profile, but the original incorrectly, and therefore the two differently”)

> 2. The maintainer adds some form of notice (e.g. https://wiki.archlinux.org/title/PKGBUILD#install to display a message post-install and/or you can also add a comment under the AUR package page) so that users will know that it is recommended to move from FLIF to JXL I've already added similar notice that gets printed at all verbosity levels every time `flif` command-line tool is used. Compile FLIF from git sources and you'll quickly know what I'm talking about. https://github.com/FLIF-hub/FLIF/pull/563

I plan use this method process imagemagick gAMA chunk bug, Could you check my method? I worry I made a some mistake. 1. identify input original image file(png,webp), 2. If ICC profile exist or gamma not equal 2.2, don't add srgb.icc. (don't override original image color management) > magick convert test.webp test.png 3. else situation add srgb.icc to output png. (no color info, no ICC profile, gamma equal 2.2) > magick convert test.webp -profile sRGB.icc test.png

is the goal to mark untagged or insufficiently tagged images as sRGB?

if so, in step 2, it would be safer to also check the cHRM tag

I don't want imagemagick add gAMA(2.2) on output png, If I add srgb.icc, imagemagick will stop add gAMA on output png.

I want avoid this displaying issue, so I imitate djxl behavior(for no color info png, djxl add sRGB and gAMA).

I reading png spec but I still have some question. > https://www.w3.org/TR/2003/REC-PNG-20031110/ This part say choose a default gamma(2.2) for no color info png. > When the incoming image has unknown gamma (gAMA, sRGB, and iCCP all absent), > choose a likely default gamma value, > > but allow the user to select a new one if the result proves too dark or too light. > The default gamma may depend on other knowledge about the image, > for example whether it came from the Internet or from the local system. but this part say strongly encouraged to write the sRGB chunk without performing additional gamma handling. > PNG encoders capable of full colour management [ICC] will perform more sophisticated calculations than those described > here and may choose to use the iCCP chunk. > If it is known that the image samples conform to the sRGB specification [IEC 61966-2-1], > encoders are strongly encouraged to write the sRGB chunk without performing additional gamma handling. > In both cases it is recommended that an appropriate gAMA chunk be generated for use by PNG decoders that > do not recognize the iCCP chunk or sRGB chunk. For process imagemagick gAMA chunk issue case, on no color info png(decompress pixel from jpg,webp,png,bmp) I should choose imagemagick default gAMA(2.2) chunk or write new sRGB chunk and overrule gAMA(2.2) for imagemagick output png ?

when there's no color info, the only reasonable thing to do is to assume it is sRGB

I understand, thank you 🙂

definitely doable but also probably too blatant

It's tricky to do that in a portable way, not all Windows terminals support ansi colors and figuring out if it does is not trivial

in C/C++ maybe yeah im too used to golang where lib for that is just 1 import away

There's no supported version of Windows where it doesn't work, but that doesn't mean there aren't users running unsupported versions who won't complain about it 😉

winxp for lyf

https://www.mozilla.org/en-US/firefox/93.0/releasenotes/

wow, i just found a picture that compresses _much_ better with optipng (-o9) than cjxl (-q 100)

it's a picture of a cellar automaton (sorry for the eyestrain)

i was just a bit suprised and i thought maybe it points to something worth investigating

JXL (and virtually every other modern lossless image format I've tested) is relatively bad at compressing *ordinary* data 🙂

it is technically possible to make them also workable for non-pictorial data, but they didn't

Maybe `--patches=0` will help

I've personally tested this because a possibility to use it in place of PNG bootstrap (a code golfing technique where grayscale PNG hosts the actual code)

and any single format was unable to beat PNG

mhhh, tree learning ought to be able to do quite well with cellular automata

it might be that the group size limitation is the problem here

possible, for the general data I found `-g 3` is better

Try -g 3 -e 9 -I 1 on that image

what is -g?

🤔

yeah, i got similar results (all are -e 9)

Can also try -I 0 -g 3 -P 0 -e 9

(no MA tree, try with pure lz77)

Ah and --patches 0

I guess doing an identical jxlart would be easier than trying out hundreds of parameters. ;)

That's the best I could do. 😄 ``` cjxl -m -e 9 -P 2 -I 0 -E 3 -g 3 --patches=0 553_o.png 553.jxl JPEG XL encoder v0.7.0 8917d6a [SSE4] Compressed to 76984 bytes (0.028 bpp). ```

thanks for the suggestions and thanks for trying them :)

here is how i made the CA, btw: https://opensofias.github.io/celluloid/#seed:'tm12',amount:1,page:553,neighbors:4,radix:2

Couldn't resist: ``` cwebp -mt -m 6 -lossless -o 553.webp 553_o.png Output: 16610 bytes (0.01 bpp) ```

good news everyone, the favourite CA-thing i found compresses wayy better 😎

😎

https://opensofias.github.io/celluloid/#seed:'rb18',amount:1,page:105,neighbors:3,radix:2,zoom:1

bigger version for better appreciation and less eye strain: https://opensofias.github.io/celluloid/#seed:'rb16',amount:1,page:105,neighbors:3,radix:2,zoom:2

well, it's smaller but zoomed in…

being zoomed in also makes it compress worse

zoom:2 is the default, so that even-numbered neighborhoods are centered, it's also used in the 553_o.png, becuae it's neighborhood is 4

anyway, i hope this is somewhat interesting 😅

Is there a formula to easily convert cellular automata's transition rules and initial configuration to Surma's web tool?

If the MA tree can represent every 1D CA (only limited by JXLs image dimensions and bit depth), then this should be possible, right?

There are various ways to define CAs

Simple elementary ones can be expressed by using trees with the properties `N`, `N-NW` and `N-NE`

So you mean a generic translation aproach wouldn't reach quite the elementary/easily compressable level?

There are only 256 elementary CAs, one for each mapping of NW, N, NE to the current pixel (there are 2^3 possibilities for those pixels, assuming 1-bit, so 2^(2^3) different mappings)

Each of them can be expressed as a simple binary tree with at most 8 leaf nodes

https://jxl-art.surma.technology/?zcode=jZJPC8IwDMXv_RQ5C9Vk6MWDB0XwpKCC5-I6DcxNZoZ_Pr3d6tTJxjy275e8vDZTltCe5Qik1rMtoFplbBMxwmni7nYcFhoGQ7WwfDgKjChQiiO4w8TRAIMe7G0c57HJwOSSnoy4ytBGnHDRZAy9gcNcxfJVUdb0qe8FL-10oWoqL0qAPoBH9HL-bvBm8MMAaNhY-SWonXA6_uGCTS5UJ6iNKKJiQ9SvGQgbZ9A1C8KuIQg7ov5jg9j1oogtWZ0WcXYRyNIrlJ9vYn74RapW4OYMR4TVW_hjNUDd7DvhS3kC

So this means CA with a radius of 1?

oh, I was trying that myself but not quite working

I guess the main reason is the predictor does *not* wrap around?

It does not, no. There are edge conditions at the edges

I mean, I thought `NW-N > 0` can be used even when `N` is 1

Uh, everything is conceptually in infinite precision integers

(in practice it is signed int32_t)

yeah, probably ~24 bits would be sufficient? (realized that AvgAll requires 4 additional bits of precision)

I think we can safely handle 24-bit uint input and have enough spare room for some transforms and stuff

oh wait, I realized Weighted can overflow...

Predictor arithmetic we do in int64_t

int32_t is for the buffers themselves

So the extra bits needed for Weighted and AvgAll etc are no problem

I guess so. While NWW and NEE cannot be accessed directly, you can look at NN-N and W and WW, which probably extends the CA possibilities quite a bit

in my CA-examples, the first rows are also procedurally generates sequences, namely the rabbit sequence (seed starts with "rb", basically the same as the fibonacci word) or the thue-morse sequence (seed starts with "tm"), i dunno if jxl's predictor can generate them too.

I guess you can technically use an optional extra channel to "store" the intermediate result

Also you could use a redundant palette where the same colors appear with different indices, and that could be used to add some state to things to transfer e.g. the value of NWW by putting it in the hidden state of W

Prev etc. would then be usable

Ah yes, that's another way to transfer state

i should try that jxl-art thingie at some point. it looks very neat. i'm just a bit afraid that it may be very easy to crash my browser with it 😅.

not that this would be a huge loss or anything, but big enough for me to be an excuse for lazyness :P

I think surma's website uses a wasm implementation so it does not crash your browser 🙂

i didn't know wasm was less likely to crash the browser, but thanks! :)

> There are only 256 elementary CAs What about making a contest in <#824000991891554375> to recreate every possible CA as `jxl_from_tree`? The top row should be initialized with simple data that gives the most "interesting" results, whatever that means (so we can see the CA rule in action and not a blank screen).

Snyder already posted the template for such trees

But I want them *all*, collected in one place for future reference

little pet-peeve: the "elementary" CAs aren't really elementary for anything, they are just "fairly simple CAs". and there are more simpler CAs that have interesting behaviour. namely these: https://opensofias.github.io/celluloid/#amount:16,seed:'ts6',page:0,neighbors:2,radix:2

basically just the 16 boolean binary operations

especially rule 6 and rule 9 have some _nice_ behaviour 😏 https://opensofias.github.io/celluloid/#amount:16,seed:'tm7',page:0,neighbors:2,radix:2 https://opensofias.github.io/celluloid/#amount:16,seed:'rb11',page:0,neighbors:2,radix:2 (pretty sure they are xor and it's inverse, equality)

but i do agree that would be neat to have

It is just the web version of the jxl_from_tree cli tool, fwiw...

ah, thanks!

are there plans to address the problem that lossy encoding may make files bigger? i suspect that's the case for basically all "graphical" content. perhaps there could be a "try lossless" flag, that automatically detects when the given quality setting would be bigger than lossless and chooses the smaller option. and since gif is compressed lossless by default, indexed png should probably be treated the same. a low bit/pixel png also seems like a good indicator for using lossless.

does lossless even use DCT at all?

i hope i don't come over as arrogant. i'm pretty sure you already considered this and chances are you have better ideas than me how to best address this.

<https://github.com/libjxl/libjxl/pull/466>

ah, thanks :)

nope. Making DCT reversible would make it ineffective (you'd need to bump up the bit depth quite a lot for that)

ah, that's what i thought.

i also thought about upscaling images based on DCT data, rather than pixels. with jxl's variable blocks that should not be that hard to implement, right? i'm curious that would look like 👀.

I had some thoughts at some point in my life about doing DCT in a finite field, but I have no idea how well that would work 😄

we actually kinda do that already

the "LF"/"DC" (8x8 downsample) is effectively upscaled in DCT space to pixels if HF/AC is 0

but traditional pixel-space upsampling tends to work better visually, which is why we just have a 5x5 upsampler for progressive previews

i still haven't figured out what AC/DC means in regard to jxl. and why 5x5? i though both block sizes and interlacing are based on powers of two? sorry, i can't make much sense of that. are there examples that i can look at or create somehow?

ah, by 5x5 upsampler I just mean that it is a 5x5 kernel for a 8x8 upsampler

as for AC and DC... AC is everything not in the top-left N/8 x M/8 block of a NxM DCT, DC is everything in that block

kernel like in convolutions?

yep

ah

one way you can think of upsampling is as $many convolutions

like a 2x2 bilinear/lanczos/... upsampling is AFAIU 4 convolutions, one for each of the 4 output pixels

DC is the top-left block and AC is everything else 🤨?

i think i understand the convolution part.

and what does NxM DCT mean if not the size of the block? but it sounds like it's the inverse somehow?

errr

sorry

so in a 8x8 block, DC is the 1x1 top-left corner and AC is the rest

in a say 16x16 block, "DC" is the 2x2 top-left corner and AC is the rest

(we don't actually represent that 2x2 top-left corner as-is, but that's another story...)

ah, i think i get it...

in the spec, we call it LF (low freq) and HF (high freq)

because DC / AC is a bit confusing/incorrect if the blocks are not 8x8

a DCT32x32 block has 16 "DC" coeffs in jxl (so calling them LF makes more sense)

while if DCT4x8 is used, two 4x8 blocks actually share a "DC" coefficient

Maybe I'll fiddle a bit with `lodepng_util.cpp` to check for `PLTE` chunks and if they are present, encode losslessly?

By the way <@!768090355546587137> what about updating lodepng in libjxl to the latest version?

Here are all commits between lodepng bundled with libjxl and the current lodepng master: https://github.com/lvandeve/lodepng/compare/48e5364ef48ec2408f44c727657ac1b6703185f8...8c6a9e30576f07bf470ad6f09458a2dcd7a6a84a

All pipelines passed for my commit 🙂 Is there anything against updating lodepng in libjxl? https://github.com/ziemek99/libjxl/actions/runs/1312552522

Lode would know best

Usually everything Lode does is just better in all ways 🙂

Hello I have some png question, could somebody can teach me about this? 1. decompress jxl to pixel, I need decompress to 16 bit depth png and do ordered-dither 4x4 convert to 16 bit depth png. I notice imagemagick have different dither method(4x4, 8x8), what's best dither method for this case? *Edit: remove silly part.😢 2. png have iCCP or sRGB, define to correct color profile(iCCP,sRGB), no color info png, define to sRGB, If png only have gAMA, I understand if gAMA not equal 2.2, I need keep original gamma, But if png gAMA equal 2.2, can I override sRGB to this png?, what's best practice for this case?

gAMA equal to 0.45455 (1 / 2.2) is not strictly equivalent to sRGB, it’s just the best approximation possible with a gamma function

if there is a gAMA chunk but no sRGB/iCCP then adding sRGB will slightly change the appearance

also, are you sure you need to bother with dither for 16-bit output?

just send a PR 😉

oh, sorry, I forgot write convert to 8 bit depth...

Is it OK that Part 2 has "image coding system" (lowercase letters) in its title but other parts have "Image Coding System"?

https://www.iso.org/standard/80617.html

oh,I got it, I just need pass 16-bit depth png to cjxl, and not necessary dither denoise png... I so silly...😢

I change my first question, I notice imagemagick have different dither method(4x4, 8x8), what's best dither method for decompress DCT pixel? use 8x8 will get better result?

imo, for dithering 16-bit to 8-bit, you don't really need very fancy dithering, since it's just about reducing the banding caused by 8-bit not being enough

(I mean for the usual cases of sRGB or maybe Display P3 colorspaces; of course for very wide gamut colorspaces like ProPhoto or for HDR, it's a different story but there I would just avoid quantizing to 8-bit)

it's not that you're actually going to notice the dithering pattern, like what happens if you reduce colors to a 256-color palette

2x2 dithering effectively makes slow gradients have ~9-bit precision instead of 8 because you can make an intermediate shade between K and K+1 that consists of a checkerboard pattern that alternates between K and K+1

Thank you for your reply 🙂 So ordered-dither 4x4 probably enough for png 16bit to 8bit?

yep

https://mobile.twitter.com/jonsneyers/status/1446194479904481285 I agree, I don't recommend to promote JXL by saying negative things about AVIF.

*meanwhile* <https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg>

That conclusion I wrote there is still OK, imo

> The newest generation of image codecs—in particular AVIF and JPEG XL—are a major improvement of the old JPEG and PNG codecs. To be sure, JPEG 2000 and WebP also compress more effectively and offer more features, yet the overall gain is not significant and consistent enough to warrant fast and widespread adoption. AVIF and JPEG XL will do much better—at least that’s what I hope. > Will there be a single winner as the dominant codec in the decades ahead? If so, will it be AVIF, JPEG XL, or the upcoming WebP2? Or WebP, now that it has universal browser support? Will there be multiple winners instead, with, for example, AVIF as the preferred codec for high-appeal, low-bandwidth encoding and JPEG XL for high-fidelity encoding? Will the new codecs lose the battle, and will the old JPEG once again survive the dethroning attempt? It’s too early to answer those questions. > For now, a good strategy might be to implement several different approaches for image encoding, not only to leverage their unique strengths but also to lessen the probability of any of the approaches becoming an attack target for patent trolls. Disk space is of no concern here because, relative to the enormous storage savings they deliver, image codecs occupy only minimal space. > Furthermore, given the many factors in play, not all of them technical in nature, success of codec adoption is difficult to predict. Let’s just hope that the new codecs will win the battle, which is mostly one that’s against inertia and the “ease” of the status quo. Ultimately, unless JPEG remains a dominant force, regardless of which new codec will prevail, we’ll reap the benefits of stronger compression, higher image fidelity, and color accuracy, which translate to more captivating, faster-loading images. And that would be a win for everybody!

The way I personally see it going is for AVIF as the "low to medium quality web image", due to the more appealing look of heavy compression (as well as the compression overhead not being so much with smaller images), with JXL being the choice for high quality images, and non-web image workflows.

So basically AVIF replacing webp, and JXL replacing PNG and q 90+ JPEG on the web.

But only time will tell.

Encoder improvements will influence where the cutoff point is where jxl becomes better than avif

Atm I think that point is around q50, but future avif improvement might shift it higher

(and future jxl improvements might shift it lower)

For other uses too, but for web delivery specifically, some other features may influence which one to choose in certain contexts: I may decide to spare some extra size for hero images if nice progressive display will mean users will see something more than a black hole much earlier…

In my opinion JXL is generally better suited for medium to high quality web use than any other modern format, AVIF can be better on low quality and the same or better on medium (on synthetic images) But, JXL is less complex and with identically optimized encoders will be much faster while retaining full format features (AVIF will need to disable some tools to achieve faster speeds) Lossy JXL is basically always progressive, with minimal progressivity it may decode in blocks in different order and show at least MQIP, with full progressivity it may show almost full image already at ~60% or use one image for different resolutions Also there is no such limitation on resolutions (as I have shown before images with 20-40k resolution on one side are not so rare) AVIF is very effective in animation, and low quality (for example for previews), also for medium quality, but the problem is to encode images fast, especially user generated content or when the result is needed faster, AVIF encoders do not use maximum compression and they need compromise which also reduces quality (like if one format encodes faster than another with the same or little difference in quality, why should I choose the slower one?) And also over time global internet speed is constantly increasing and I prefer the way to increase image quality than to over-compress them (yes, heavy lossy compression will always be needed, but still, the percentage of images of at least medium quality is much higher even now, not to mention the future)

Also JXL lossless and lossless Jpeg recompression So these formats have their non crossing better sides which can be used and some crossing things like medium quality, but in general JXL is more future-proof, AVIF will most likely be replaced with something newer when AV2, AVx and so on are released

I want jxl based video codec / h264 with jxl I-frame 😆

motionjxl

.mjxl

i wanted to say that

<@!132637059327328256> Thank you a lot for your image corpus.

It's really appreciated.

I hope they are good for whatever purposes you may have from random photos

jxl in fax (<https://datatracker.ietf.org/doc/html/rfc3949>) when

TIFF-FXL

yes, and I don't know

yes, and yes, but no idea how much (could be quite small impact)

Maybe make FLIF v0.4 final release despite those problems? FLIF is deprecated anyway...

yes, I guess

you know that a tool lacks documentation when, even having written the tool yourself, you don’t remember for sure how to use it

not sure

Does anyone know if Sharp (https://sharp.pixelplumbing.com/) will get JXL support in the near future?

Probably, since it uses libvips

This workflow needs re-running: https://github.com/libjxl/libjxl/actions/runs/1317915784

One of the checks failed (due to a weird reason) at checking out the source. The exact same workflow passed when I fetched commits to my fork.

<@!416586441058025472> Let's continue the discussion here https://discord.com/channels/794206087879852103/803574970180829194/897550316302663720 Fabian, if MJXL was a thing, it'd be an all-intra video standard, not normal video coding...

i did not talked about photo that have many nits

i don't think photon camera github has this purpose

anyway the denoising is also good

https://netflixtechblog.medium.com/cambi-a-banding-artifact-detector-96777ae12fe2

Another workflow failed at checking out the source and needs re-running... https://github.com/libjxl/libjxl/actions/runs/1342538811

Thanks again! 😃 By the way: why was there less commits this week?

I imagine that commit rate doesn't directly correlate to work being done. Especially if you go for commits on main, as a major PR may just end up as one commit there.

I've been editing the 2nd edition of the spec, so not much coding

JPEG week next week so have to get stuff ready for that

Ah, I've been suspecting something bigger behind the scenes going on...

I wanted to add PNG PLTE detection to `cjxl` and skeleton code works flawlessly, but I'm not smart enough to tap into LodePNG to extract that info...

More code reading, I guess...?

The worst thing is that I can rely only on my mind for interpreting the code, any IDE (e.g. VS Code) will be too RAM-intensive for my laptop (which is pathological), so I'm stuck with GitHub's file browser, `nano` in WSL for editing and GitHub CI for getting builds.