JPEG XL

`JPEG` 79.53930745 2.5103836060 3-norm: 1.302746 `-d 1` 83.28755927 1.7946568727 3-norm: 0.618410 `-d 0.1` 92.68645483 0.2948192954 3-norm: 0.077324 `jpegli` 84.81737455 1.4984853268 3-norm: 0.691113

can you send over the original image

I think it's not taking into account that dark areas have extremely limited value ranges, so it just sees "Oh, it's only off by 7, that's not noticeable". It might even be related to the desaturation issue

libjxl is very much supposed to take that into account

one of the main selling points that has been advertized about libjxl is that it does that

what you're observing is probably a bug

The issue exists all the way back in v0.6, so if it's a bug, it's a very longstanding one

IMO, d0.1 looks way better than JPEG. indistinguishable at reasonable viewing distance while the jpeg has noticeable distortion in flicker test. the comparison only gets worse zooming in.

d0.1 was 6.3 MB, the JPEG was 2.8 MB

sure, and it looks way better, checks out

Looks worse than the JPEG to me, still smoothened and quantized slightly

Flicker at 1:1 between original and JPEG I can't see any difference, JPEG and d0.1 I can see it brightens and smooths slightly

`--intensity_target 20000 -d 2.8` seems to compensate, giving a smaller file without crushing the blacks

Obviously, not ideal...

Okay, taking a look at the full image, on my SDR laptop I had to turn up my brightness all the way to even see the blurring, and the smudging is honestly not *that* bad.

Same with my HDR phone, I had to turn my brightness up to see it, it's not super glaring imo. Also you could just target HDR displays like so `--intensity_target 2000 -d 1.4`

At 100% zoom? It was obivous to me and I only have SDR

Is you monitor well-calibrated? Well acutally I don't even know if my own monitor is well-calibrated...

Yes I compared at 100% zoom

Let me try another monitor

wait a minute

I think color profile shenanigans are happening

Yup I was right, instead having a proper sRGB color profile, it had a gamma chunk of 2.2 🤢. All color-managed software I have displayed the image too dark, meaning I can't actually see the compression in the blacks since the image as a whole was darker.

just use good software [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

and by that I mean mac, only mac

Tell artists that

I swear, why are drawing programs using PNG gamma chunks (which often have the wrong values) compared to a proper sRGB profile/P3 profile?

Okay I had to strip all the color metadata and append a sRGB profile

NOW I can see the blacks being compressed

If I used software with no color management it would have avoided this issue lol <:kekw:808717074305122316> "gamma chunk? what gamma chunk?" - qimgv & windows photo viewer

~~The file I was actually testing with was a `-o 1 -f 9` Oxipng pass, to get rid of the redundant Alpha, I guess maybe that made it sRGB too~~ Nope

Or Irfanview probably either read it properly or ignored it and did sRGB since it's ancient

Every time I run into color management issues, it's due to PNG's gamma chunk. (Looking at you FFMPEG <:PepeGlasses:878298516965982308>) The values are always improperly set and the image always looks too dark or too bright.

the weird thing about having a gamma 2.2 chunk is that it should be correct in the vast majority of cases. only in the case of an inverse oetf display should it display incorrectly, which is really just the status quo

It should be the same, but it's not. ~~It looks terrible in color managed software, a simple sRGB color profile does not have these issues. Libjxl is doing something wrong here.~~

Also, this has a domino effect with JXL, it takes in the incorrect color data and does crappy compression

Yep. Original, Gamma, sRGB

Infranview ignores the gamma chunk and just assumes sRGB ~~(as it should)~~

BUT, libjxl doesn't ignore it and assumes the image is actually darker it should be

But as Quack said, shouldn't Gamma 2.2 be essentially the same as sRGB?

~~I think it might be an error on libjxl's part~~

looking at jxlinfo reveals something

``` jxlinfo PNG-gamma.jxl JPEG XL image, 2654x3753, (possibly) lossless, 8-bit RGB+Alpha Color space: RGB, D65, sRGB primaries, gamma(0.454550) transfer function, rendering intent: Relative jxlinfo PNG-nogamma.jxl JPEG XL image, 2654x3753, (possibly) lossless, 8-bit RGB Color space: RGB, D65, sRGB primaries, sRGB transfer function, rendering intent: Relative ```

when decoding without specifing color profile, they should decode to the same [Hmm](https://cdn.discordapp.com/emojis/1113499891314991275.webp?size=48&name=Hmm)

might it be whatever software is being used that libjxl is interfacing with?

The original PNG has a gamma chunk of 2.2, and then I tested the same PNG with color metadata stripped out. Compressed with cjxl 0.11

Simplest answer would be checking for a gamma of 0.45455 and using the sRGB enum, since it's already detecting everything else

how about just [ignoring it](https://cdn.discordapp.com/emojis/862625638238257183.webp?size=48&name=av1_chad)

I mean for lossy, it should be, that's what I meant

Colorspaces are already simplified

man i wish stuff just handled color properly

IIRC <@604964375924834314> is the main colorspace man, maybe they have some input about the gamma weirdness

FFMPEG has similar issues with gamma as well, PNG screencaps from videos looked too bright, nuking color data made it look correct again.

IIRC the issue is that PNG with gamma2.2 is not the same as PNG with sRGB tf, but lots of viewers display them in the same way. Libjxl does the right thing but it will cause visible difference to the original if you are looking at it in a viewer that does the wrong thing. This mostly affects the darks.

hmm, are both paint.net and GIMP doing gamma incorrectly then? They both render JXLs with `gamma(0.454550) transfer function` too dark

afaik PNG's srgb tf is ambiguous and pretty much means "whatever you think sRGB is" or in 90% of cases, a noop. in color managed setups, whether or not sRGB is treated by doing a pure 2.2 or an inverse oetf is up to the application (and really should be able to be override on a per image case)

a pure 2.2 tag is explicit and should "always be handled correctly"

The first thing the artist themselves said was "Why is it so dark", so either libjxl is doing something wrong or all the art programs aren't displaying the canvas correctly. Might be another case of 'de-facto standard' rather than actual standard...

what are program ? I know lots don't display properly without a shit ton of fighting

also "why is it so dark " is something many graphics designers have heard when shipping images to customers xD

thanks srgb

In this case, sRGB is what they wanted

sRGB will never be consistent

https://www.escapemotions.com/products/rebelle/about

never used it nor know anyone who does so can't comment t.t

The `sRGB` chunk means specifically the sRGB primaries and the sRGB tf and there is no nothing ambiguous. But of course in practice there are many applications that don't properly do color management. In particular many applications will just ignore any tags except explicit ICC profiles.

It's a problem ~~with lossy JXL specifically,~~ it decodes too dark compared to the original PNG

I was going to say earlier but wasn't sure if it was Irfanview bugging out. Lossy JXL is dark and has the severe compression, lossless is the same brightness as the original PNG/sRGB

yeah it's strange, the extra dark image ~~only~~ appears when it's encoded as a lossy jxl, then decoded by any software. Same with jpegli

I think it's because the XYB interally means it gets converted to the requested output format, so libjxl is doing the gamma to sRGB conversion, but lossless relies on the viewer to handle gamma again

I see why your artist friend says, "It's too dark". The image is brighter and the darks are more visible in *Rebelle 7*, but in Google Chrome and in JPEG XL they appear darker.

It doesn't carry over

<@568056047701590026> maybe you can file a bug report for Rebelle, if we explain what the problem is. Basically the PNG it makes is a lot darker than your canvas, but only in certain software

does PNG specify whether or not the sRGB function should use the inverse oetf or the pure 2.2? iirc ICC defines it with inverse oetf

Rebelle 7 is outputting an image that looks different natively in software compared to basically every color-managed viewer I've tested. So I think Rebelle 7's fault for setting inaccurate sRGB values, ~~mainly because the program itself is not even color-managed, it doesn't respond to any color profiles or anything.~~ The base edition isn't color managed, you need to pay extra for proper colors. <:PepeSad:815718285877444619>

it doesn't seem to specify but the sRGB w3 spec hints towards 2.2

oops meant my reply to be in regards to PNG spec

I think Rebelle 7 is setting the wrong transfer curve. It think the program itself displays the workspace using the sRGB transfer curve, but then sets gamma 2.2 for PNG export, which leads to a minor discrepancy between what the artist sees on the canvas and the saved image. It's the opposite of "what you see is what you get" which is really bad for artists.

God my head hurts

ita more likely that it is displaying "as is" then tagging 2.2 which is the reccomended default for png

it does have color management options https://escapemotions.com/products/rebelle/manual/starting-painting/color-management

> If you do not want to use the color management and assign a profile to your Rebelle artwork, select "Don't color manage". This option uses your monitor profile as the working space. It removes any embedded profiles when opening images, and does not tag when saving.

this seems likely

Pro edition for functional image export 💀

wait its a different edition? RIP

hmmmm

ill check again cus they updated

**Source:** https://www.dpreview.com/sample-galleries/4314410403/fujifilm-gfx-100-ii-pre-production-sample-gallery/1213608457 `11,648 × 8,736 (102 MP) | Real Life Camera Photography` **Encoders:** ``` cwebp 1.4.0 cjxl v0.12.0 e3961729 avifenc 1.1.1 (svt-psy 68a84a2) cjpegli (Google - git upstream, 2025-04-17) ``` **Parameters:** ``` cjxl --allow_expert_options --codestream_level "10" -e "11" --container="0" -x strip="exif" -x strip="xmp" -x strip="jumbf" -x strip="iptc" -x strip="jhgm" --noise="0" --keep_invisible="0" --photon_noise_iso="0" --gaborish="1" --dots="1" --compress_boxes="1" --brotli_effort="11" --progressive_dc="0" --epf="0" --resampling="1" --ec_resampling="1" --upsampling_mode="-1" cwebp -preset "photo" -hint "photo" -m "6" -segments "4" -pass "10" -noalpha -sharp_yuv oavif -s "0" # tune=4, psy-rd=0, qpscs=0, -g 2x2 cjpegli -p "2" --chroma_subsampling="420" ```

is this meant to test encoder quality at max effort settings and such for encoders? If so I would recommend adding `-af` to cwebp, also it might make sense as well to add `-metadata icc` to retain possibly present color profiles in source images as without it they will look wrong. also why do you have epf turned off for cjxl? and also is there a reason you aren't doing XYB with jpegli?

Thanks, I will definitely retest again in the future. Yes, this test disregards speed. For reference, on my machine (9950x), and with this image, `cjpegli` is simply instant, webp is the slowest. `avif` is considerably faster than `cjxl` because I can use `--lp=5` with around 50G ram usage. Yes, I forgot adding `-af` for `webp`, you are right. I ould also add `-metadata icc`. I disabled `EPF` for `cjxl` because I did internal bd-rate curve test with it beforehand. It probably looks psychovisually better but it decreased bd-rate efficiency.

I am not convinced e11 cjxl produces better results than e7 for lossy

but would it produce worse?

It could

It's less tested and may well overfit for butteraugli instead of producing good visual quality

As a metric, I can recommend CVVDP, by the way

yeah, who uses e 11?

my older test

It was kind of consistent

All metrics except butteraugli-max are pessimistic about jxl compared to the results we get in subjective studies, interestingly. They are optimistic about avif. With that I mean that the metrics assign too high scores to avif images and too low scores to jxl images, compared to the ground truth of actual human observers.

That was also my observation. I am actually extremely surprised with the results.

The breaking point should have been around 70~ ssimu2

maybe even less

This is plotting the average metric score (averaged over 5 images) at a given visual quality in JND for various codecs, for various metrics.

JPEG AI manages to fool all the metrics basically, probably since it was mostly trained using metrics, so all metrics are very optimistic about it as a result

But you can also see that metrics tend to be pessimistic about jxl.

For HDR images, the amount of codec bias in metrics is even more pronounced, to the point that doing a codec comparison based on metrics will lead to pretty incorrect conclusions.

Thanks for this recommendation and also the PDFs are really interesting

Still in 2025, there is still no way to batch test image/video quality

Do you think it's borderline useless? (metric testing)

It's useful because it's so much faster and cheaper than subjective testing

Probably it is also still useful to tweak encoders, as long as you are careful not to blindly trust metrics

But things like Bjøntegard BD rates have to be taken with a very big grain of salt, since a metric can easily say something is 20% better while it has a 40% bias the other way so in reality it is 20% worse.

At the current JPEG meeting we will be issuing a call for proposals for AIC-4, which is objective metrics. Besides just the usual correlations, we will also look at codec bias. I hope this activity will lead to better metrics with less codec bias.

I guess this is the key.

Oh obviously. Especially for this test, since there are many more data points closer to the low BPP side, the "summarized" results are extremely biased

and all of the percentage difference comes from the relative bd-rate curve. It would change if quality range is changed or if you remove an encoder from the list (or add another one)

e11 lossy is internally remapped to e10. I encountered it with my resampling PR, so I had to move the slower downsampling to e10 instead

true

encoding a 102MP image 100 times, with actual E11 would be hell 😁

I almost disabled the remapping, but I think it would just do e11 on the 1:8 modular DC image

Many of the parameters you specified are set automatically, some even being harmful to density or non-functional. `--codestream_level` is set automatically, and forcing it to 10 could cause it to waste a few bytes. `--container 0` does nothing since it uses a bare codestream if no metadata is present. `-x strip=all` works the same as specifying them separately. Instead of `-x strip="jumbf"` you should use `----allow_jpeg_reconstruction 0`, if you don't want reconstruction. `--noise` is non-functional, so disabled by default `--keep_invisible` only applies to Alpha, which JPEG doesn't have, also only for Lossless with it being 0 for lossy `--photon_noise_iso` is disabled by default `--gaborish` adjusts based on quality, with it being bad at low quality/lossless `--dots` is non-functional like `--noise`, only increasing memory usage and encode time `--compress_boxes` is enabled by default `--epf` adjusts based on image/quality, so forcing it off introduces blocking Resampling only triggers at distance 20 (soon distance 10), so that's redundant too `--upsampling_mode` only applies when Resampling is active And finally, if think you're doing Lossless JPEG Transcoding. Not lossy encoding like the other formats. You need to add `-j 0` or `----lossless_jpeg 0`

I have --lossless_jpeg 0

I tested these settings prior-hand

As you said, most of these are already, the defaults

some of these don't affect the scores negatively or positively

and some of them increase the scores (EPF=0)

it can psychovisually be better

I disabled it similar to disabling psy-rd with svt

I rechecked again: ``` --container="0" \ --lossless_jpeg="0" \ --allow_jpeg_reconstruction="0" ```

Ah, good. It might be interesting for you to try v0.8 of cjxl too, as it has some... *Different* characteristics

Hmm, would it be meaningful to add it to a comparison like this? If it's too close to 0.12; then it would be noise though

If it behaves better against metrics, I can use that but it would be less meaningful though

or not?

```cjxl Test.png 12.jxl JPEG XL encoder v0.12.0 [_AVX2_,SSE4,SSE2] Encoding [VarDCT, d1.000, effort: 7] Compressed to 374.5 kB (1.445 bpp). 1920 x 1080, 2.696 MP/s [2.70, 2.70], , 1 reps, 16 threads. cjxl8 Test.png 8.jxl JPEG XL encoder v0.8.2 954b460 [AVX2,SSE4,SSSE3,Unknown] Read 1920x1080 image, 2865313 bytes, 131.8 MP/s Encoding [VarDCT, d1.000, effort: 7], Compressed to 307180 bytes (1.185 bpp). 1920 x 1080, 2.27 MP/s [2.27, 2.27], 1 reps, 16 threads. ssimulacra2 Test.png 12.jxl 85.82864552 ssimulacra2 Test.png 8.jxl 84.73574296``` Depends on the image, but it can be quite a lot better. There's more in https://discord.com/channels/794206087879852103/1278292301038227489

What's the reason though? Why did it deviate?

This PR changed how libjxl measures quality while making decisions. It helped for a few difficult images, but harmed most others instead https://github.com/libjxl/libjxl/pull/2836

Thanks. I decided to test 0.8 and 0.12 on the particular image I am testing, and then use the best performing one.

Oh, and if you do use `--xyb` on cjpegli, also use `--chroma_subampling 444` due to hard quality limits for 4:2:0

I tested with xyb now, and it is really better

though I tested 444 before and it was way worse (on metrics)

maybe it would behave better with xyb

I cite this almost weekly, but it could be useful to decide cutoffs for subsampling https://giannirosato.com/blog/post/jpegli-xyb/

I got this without -xyb

Is that averaged across the full quality range?

`-af` improved the scores. `-pre 3` improved it further. `-preset & -hint` already improve them. `-metadata icc or all` doesn't change scores. Exact same. Maybe the ref image doesn't have icc? Here see the output: ``` cwebp -preset "photo" -hint "photo" -m "6" -pass "10" -q "80" reference.jpg -o "test.webp" -af -pre 3 -progress -metadata all -v Time to read input: 0.322s Saving file 'test.webp' Time to encode picture: 76.614s File: reference.jpg Dimension: 11648 x 8736 Output: 3461904 bytes Y-U-V-All-PSNR 44.02 49.13 49.63 45.19 dB (0.27 bpp) block count: intra4: 129748 (32.64%) intra16: 267740 (67.36%) skipped: 71651 (18.03%) bytes used: header: 924 (0.0%) mode-partition: 446433 (12.9%) Residuals bytes |segment 1|segment 2|segment 3|segment 4| total macroblocks: | 1%| 3%| 15%| 81%| 397488 quantizer: | 32 | 32 | 24 | 18 | filter level: | 30 | 36 | 14 | 14 | Metadata: * EXIF data: 65460 bytes * XMP data: 12255 bytes ```

as far as I remember, it must be the full range. I'll retest with --xyb and send the scores

That might cause an issue then. Since 444 is wasteful for the extremely low quality range, but 420 can't reach high quality at all. So it will always look bad unless adjusted for the quality setting

something to note about `--xyb` is it uses a special chroma subsampling amount/mode if you don't define `--chroma_subsampling` at all

Okay so I can also test non-specified vs --chroma_subsampling Thanks for the tip

oh also with cwebp if you are curious what the different hints/presets set/change internally here is it all: https://github.com/webmproject/libwebp/blob/874069042ead095f8a8d6bdd35b9b145ce80af43/src/enc/config_enc.c#L60

above the line I linked to are the defaults if no hint/preset is defined

You are right

Before 60 SSIMU2, and before 2.5 Butter-3norm; it splits

I should really try and make a PR so that it changes based on quality

It seems (the split) extremely sharp and deterministic. I don't think this would change drastically among different images

Do you have the quality/distance value where 444 overtook 420? Metrics don't cleanly map to input targets and it'd save me running my own tests

Let me check

For butter 3-norm the splitting point where 444 better is: ``` cjpegli "${ref}" "${output}" -q "84" -p "2" --xyb --chroma_subsampling=420 cjpegli "${ref}" "${output}" -q "21" -p "2" --xyb --chroma_subsampling=444 ```

Both encodes have a similar size but 444 is smaller and has better score: ``` 420: BPP=2385518 SCORE=2.622476 444: BPP=2372800 SCORE=2.556109 ```

let me check for ssimu2

It's 26 (or 25) to 87 for ssimu2

Hmm, that makes it a bit more complicated... I didn't consider how far 420 stretches out into the high quality range before 444 takes over. Maybe I'll take a more conservative approach of switching at `-q 30`, so there's bpp overshoot from 444 but not lack of quality from 420. XYB needs 444 to be compatible with JXL Transcoding too, so we want most files to use it

If you ask me making 444 the default makes more sense here

I was considering disabling 420 for XYB entirely, but it does make quite a difference

looking at the results, 420 is terrible and less intuitive

a user might select a score as high as 87 and get an actual output of 30

Should I test not specifying it? username above said that it also had another mode

Oh the reason why 420 scores so poorly is because of a bug https://github.com/libjxl/libjxl/issues/3605

You should not specify it

Because if you do, it triggers different behavior for some reason

This is only for XYB by the way

I'm looking at the code now and... I have no idea what it's doing

It says it's subsampling Blue, but B is the only *non-*subsampled channel...

For benchmarking purposes, I was thinking on doing a 2 pass approach (encode low bitrates with 420, and rest of it with 444)

Because of the JXL transcoding and weird behaviour, I might just set XYB to be 444 by default. It can always be overridden with the flag. If you have the same crossover for YCbCr 420 and 444 I can still add that at least

*"something to note about --xyb is it uses a special chroma subsampling amount/mode if you don't define --chroma_subsampling at all"*

so is it a bug or a feature? lol

I would consider that a bug honestly. Imagine getting crappy results by using a common feature

Or just poor documentation I suppose

This is interesting

Specifying is still better up until some point (around -q 20 to 26)

Not a usable quality tbh

It's because of using XYB instead of YBX

It's subsampling luma

yeah, thats the bug I was talking about

doesn't `--xyb` internally use RGB JPEGs..?

Yes, but it still subsamples the RGB channels

oh yeah wait I forgot about the whole XYB color transform part of `--xyb` whoops. I've been awake for quite a while..

Made some changes, will test them soon™

In [my fork](<https://github.com/jonnyawsom3/jpegli>) I've set XYB to 444 unless overridden with the flag. Maybe <@604964375924834314> (sorry for another ping) could help me change it from XYB to YBX, then the normal subsampling flags would work correctly and unmanaged viewers wouldn't be bright pink and green (But still tinted)

Oh, also <@1028567873007927297> IIRC you wanted the APP14 marker for XYB, so I enabled that in the fork too

it would be nice to still have a way to enable/set the blue channel subsampling because afaik there is no option for it otherwise. I mean if what you are proposing with YBX comes true then it probably won't be relevant anymore but unless/until that happens I don't think the option for blue channel subsampling should be removed entirely.

I was going to duplicate all the subsampling options for XYB, but it felt very messy for what shouldn't be an issue in the first place

Merge request 😲

Alternatively, the YBX data could be stored in a traditional old YCbCr JPEG. The JPEG decoder will convert it to incorrect RGB values and then a color profile can be attached that converts the incorrect RGB data to the correct RGB values.

The incorrect and correct data can look pretty similar unless you swap the color channels :)

If you want it to be more obvious that it's being viewed incorrectly then swap the channels, otherwise put X where Cr is and B where Cb is

If you multiply the transform matrices of the reverse-YBX transform with the forward-YCrCb transform, you will get the matrix that will reverse the incorrect reverse-YCrCb and apply the correct reverse-YBX transform

I know it hurts to think about

You can even have an option, to swap channels to make it easier to tell if the colors are wrong.

And no need for an app14 tag anymore

Why not do it that way?

No need to worry about chroma subsampling compatibility problems either

If you saw the horrors of the codebase, you wouldn't be asking so much

Is there any reason whatsoever to do it the current way instead?

Oh I saw it lol. 😂

At least let us figure out what YBX looks like, since it's not a perfect match anyway and I don't have the knowledge to do it

C++ template hell

I don't think that's how that works (with my understanding at least). imagine the random assortment of numbers below is a palette of colors or something: ``` 2 6 1 x 8 5 x 0 ``` now imagine that the numbers with "x" don't exist anymore after a lossy color transform and are simply changed into nearby existing numbers. alright well now how do you reverse that? the answer is you don't because the data simply doesn't exist anymore and there is no way to tell if a number is what it was before or shifted over because of it not existing during the transform.

Even the current implementation tints my images pink in Irfanview, enough that I noticed immediately with color management enabled but not working perfectly

afaik XYB JPEG is done with RGB instead of YCbCr to avoid a double lossy color transform

Yeah I heard that the JPEG color transform itself is lossy but it can also be done at whatever precision you want I think? And it's better quality than webp's transform

The worst thing that will happen is banding

Maybe theoretically using an app14 RGB JPEG that disables the color transform entirely could give you less banding and better color

By avoiding the rounding errors in the color transform of the decoder by disabling the transform completely with the app14 marker

RGB works fine, XYB causes CDNs to incorrectly subsample Luma when using JPEG or WebP, so YXB should be used ideally.

I can't recall the conditions required for jpegli's high bitdepth, but it may need RGB to avoid the transform but still use the 12 bit DCTs(?)

There would only be 1 color transform. The one in the decoder. The encoder would store XYB data in the channels meant for YCbCr and use a color profile to correct the difference between a reverse-YCbCr and a reverse-YBX

I guess that is 2...

1 by the jpeg decoder and 1 by the color management engine

So yeah you're right... RGB JPEG is better for that reason...

Assuming low-precision, 8-bit JPEG decoding

If it's using RGB/XYB then it should never use chroma subsampling.

Just my hot take

Even if you ask for it, it should refuse. It's a bad idea. Compatibility mess. Not just for cjxl, but also some decoders might assume chroma subsampling = YCbCr

I remember Jon saying something along the lines of > Chroma Subsampling is a sledgehammer when you should be using a scalpel

decode speed improvement with chroma subsampling is nice

sure, and so is the speed improvement with downsampling the entire image 🙂

chroma subsampling is perceptually almost free on most content

sure — except when it isn't

Downscaling in linear light for the subsampled chroma planes gets you half-way there at least. But almost nothing does that...

So then I humbly suggest that XYB JPEG should never be chroma subsampled since RGB JPEG is traditionally never doing that and it even totally precludes lossless JPEG transcode...

Even when explicitly requesting both at once it should refuse...

not important to consider for JPEG imo. plus, you really do lose fidelity near the high end, this is testable

no, gamma45 and sRGB are not the same, notably in the smaller end of the curve

Oxipng actually strips the gamma with `-s`, which is only meant to strip chunks that don't impact rendering

umbrielpng strips `gAMA` and `cHRM` but only if `sRGB`, `cICP`, or `iCCP` are present

if none of those three are present, it leaves the fallback ones intact

you want to strip all non-color metadata, my tool umbrielpng does that well

it leaves critical chunks, color data chunks (except as mentioned above), animation chunks like fcTL and fdAT, and tRNS, and hIST if it's necessary

and strips all the others

sBIT is stripped if it's maximal

it doesn't decompress IDAT so there's no re-zlibbing

you may need to use another tool for that

https://github.com/Traneptora/umbrielpng/blob/main/umbrielpng.c

Oxipng my beloved

umbrielpng is not a PNG optimizer, it's a PNG viewer that has the ability to strip unnecessary chunks

is there a specific message in spec that specifies the behavior sRGB? as far as I can tell it's left ambiguous

a citation of IEC 61966-2-1

ah I see, indeed then

~~god I hate color~~

the spec also cites H.273 though, which is actually free

for cICP it cites H.273, which can be found: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.273-202407-I!!PDF-E&type=items

H.273 cites this formula

for Lc normalized between 0 and 1

I will never not hate that `IEC 61966-2-1 sRGB` and `reference sRGB` are not the same thing

in either case, gamma45 is H.273 TRC 4

and sRGB is H.273 TRC 13

they do have different formulas

the problem is a lot of software treats them as the same

because a lot of old PNGs would write gamma45 fallback chunks without sRGB chunks when they really wanted sRGB

so as a result, a lot of software started interpreting gamma45 as though it were sRGB, assuming that's what the authoring software intended

Like we encountered the other day

imagemagick does this too

libjxl just treats the files as correct

it doesn't make any attempt to assume what the encoder probably meant, and instead just reads what the file says

which IMO nowadays is correct behavior

to be fair, a lot of authors probably have no clue wtf they meant [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

I ran into this issue with the conformance sample lz77_flower

it's tagged gamma45

with uses_original_profile = true

so libjxl decodes it to a gamma45 PNG

jxlatte (at least at the time) would not write PNGs that are not sRGB or PQ, so it will transform it into sRGB before writing the PNG out

I need an AI that will tell me if an image should be decoded with gamma2.2 or inverse oetf lmao

Making such assumptions is a kind of paternalistic behavior in software that I think should be avoided. It is better to be literal and assume that everything is what it says it is, rather than trying to correct common mistakes automatically, which only introduces ambiguity and inconsistency.

If you have a PNG file with only a gamma chunk, and you are expecting it to be interpreted as sRGB, then you should fix the PNG file by stripping the gamma chunk, not by making viewers ignore it.

Speaking of weird gamma, I have some PNGs with an iccp that is being read by libjxl and converted to an enum space

it's got EBU primaries and gamma 0.53 I think

does that ring a bell?

does this space have a name?

something like 1/1.9 gamma

Maybe this one? http://www.eci.org/doku.php?id=en:colourstandards:workingcolorspaces

I have seen that one used in the wild by one of our customers, I don't remember which one but I think they were from Germany

``` Custom primaries: red(x=0.630003,y=0.339989), green(x=0.295044,y=0.604926), blue(x=0.154992,y=0.076980)gamma(0.555315) ```

these are the exact values

idk if this is the same one

> Copyright 2007 Apple Inc., all rights reserved.

this is the cptr tag

this is what we get from ffmpeg

``` [libjxl @ 0x63f632f13600] Unsupported gamma transfer: 0.555315 [libjxl @ 0x63f632f13600] Falling back on iec61966-2-1/sRGB transfer Input #0, jpegxl_pipe, from 'test.jxl': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpegxl (libjxl), rgb24(pc, gbr/ebu3213/iec61966-2-1), 600x450, 25 fps, 25 tbr, 25 tbn ```

```images Mpx (mean) colors/px (mean) | share | share colors (mean) tag 489 100.00% 0.41 100.00% 44049 0.11 all 32 6.54% 0.25 3.95% 15063 0.06 albedo 27 5.52% 0.79 10.58% 67442 0.07 algorithmic 31 6.34% 0.70 10.71% 85620 0.11 digital_painting 56 11.45% 0.21 5.90% 27049 0.13 logo 49 10.02% 0.44 10.60% 53513 0.15 lossy 34 6.95% 0.30 4.99% 49998 0.20 normal 68 13.91% 0.50 16.97% 74106 0.16 photo 71 14.52% 0.19 6.58% 475 0.00 pixel_art 68 13.91% 0.30 9.98% 33012 0.13 texture 28 5.73% 0.57 7.82% 32444 0.05 ui 37 7.57% 0.67 12.19% 86602 0.13 watermark 118 24.13% 0.44 25.91% 58164 0.17 content_other unique mins Mpx/s real (mean) B bpp (mean) mins | Mpx/s CPU (mean) best of 84881853 3.2853109 100.00% ···· 0.00209219644 0.0055602251 all 84891279 3.2858903 97.34% 97.34% 0.0088010715 0.0087908659 paq8px_208fix1_12 100551374 3.9033083 1.84% 1.84% 0.00344114548 0.020874815 cjxl_0.11.0_d0e11 107694944 4.1801616 ····· ···· 0.1798265 0.1943867 cjxl_0.11.0_d0e10 115760718 4.4603495 0.82% 0.82% 0.2861193 0.495180 cwebp_1.3.2_z9mt``` paq8px compressing PAM, others converting from stripped PNG

```images Mpx (mean) colors/px (mean) | share | share colors (mean) tag 19 100.00% 0.93 100.00% 95825 0.10 algorithmic 19 100.00% 0.93 100.00% 95825 0.10 jxl_art bpp (mean) unique mins Mpx/s real (mean) B | mins | Mpx/s CPU (mean) best of 2599676 1.103348 100.00% ···· 0.0019206458 0.005364068 all 2602292 1.104399 68.42% 68.42% 0.009261715 0.009258667 paq8px_208fix1_12 3495219 1.528870 31.58% 31.58% 0.0038084687 0.02133666 cjxl_0.11.0_d0e11 4283113 1.866336 ····· ···· 0.149306 0.168312 cjxl_0.11.0_d0e10 6155918 2.646459 ····· ···· 0.56353 0.99170 cwebp_1.3.2_z9mt```

**Base command:** ``` cjpegli -p "2" --xyb ``` - **Source:** `134.5 MP (13385x10264)` - **Filesize:** `101 MB` - **Camera:** `Phase One IQ4` - **Link to source:** https://flic.kr/p/2kXUoje

<@238552565619359744> 444 and not specified are close to each other but still, there is a difference

It's interesting how early the scores flatlined.

This test took some time...

Hmm, I have *yet another* datapoint you could add for the high quality range, disabling adaptive quantization https://discord.com/channels/794206087879852103/1301682361502531594

Probably only run that with 444 to save time

Interesting. Some options are not documented?

`--xyb` is one of them.

First, I thought Google's implementation doesn't have that but it does.

<@238552565619359744>

both 444 xyb

Just like `cjxl`, `cjpegli` also has `-h -v -v`

Interesting, I guess the AQ issue is only for YCbCr

"Tonight, on *'Graphs that need a logarithmic X axis...'*"

I (think I) just added that now, but now I'm thinking... Why does it only subsample blue? Not X along with B?

It's messy, but <@207980494892040194> can help us test and tweak it later <https://github.com/jonnyawsom3/jpegli/tree/jpegliSubsampling>

copy paste error?

Fixed

Tried it a bit ago, it was between 0.03 and 0.05 bpp smaller, so not really worth it for sacrificing the 20% transcoding

That was 444, 440, 422 and 420

Might be better if X was subsampled too, but it doesn't seem worth it at all

<@179701849576833024> didn't you have a threadripper or an EPYC server that you used to test chunked encoding?

I do have a threadripper yes

We got chunked working for progressive lossless, but me and <@207980494892040194> only have 8 core CPUs, so we can't see how far it scales. Don't suppose you'd like to help us make the most lobsided bar chart ever? xD

Could actually test our faster decoding tweaks too, since it seems hardware dependant

Actually I only have 6-core CPUs

And mine is an 8 year old 8 core

So good to know our changes work in less than ideal conditions, especially since most of it is about threading

I just realised I'm a fool. XYB is stored in RGB JPEG, so there *is* no YCbCr to take advantage of. This is the best it can look while being stored as RGB

Chroma subsampling should be possible for XYB...

I always thought it would make more sense as YXB as why is your luma channel not the first one?

It usually is the first one in most of the signalling.

I think it was called XYB just to sound more like XYZ

Ah so it’s just naming conventions?

well it is a bit messy, in jxl sometimes the component order is XYB and sometimes it is YXB

Probably should have just been defined as YXB

XYZ is another colorspace. Very old iirc, from analog times, but still used as an intermediary reference colorspace for a lot of conversion.

is it at least good?

it's the reference pretty much

Well, good for what 😅 It is actually used for some lossy encoding, in Digital Cinema for example, so I'm quite certain it isolates luminance (to Y, I strongly assume) like all the other colorspaces that are used to perform lossy encoding in.

XYZ typically (but not always) refers to CIE XYZ, which is the typical human visible range of color

Yeah, it supposedly defines all visible colors...

why wouldn't everything use it then?

because it's inefficient

also, XYZ is best reffered to as a color model, as its not the same thing as a colorspace

color space is a bit overloaded here.

1. Probably not very perceptually uniform, so encoding it is is not as efficient as it can be. 2. The simple YCbCr colorspaces are the only ones widely supported, really. One reason for that is because the math to and from RGB is so simple.

The only reason JXL can actually always use XYB is because it's used internally, part of the spec and the decoder.

there are a myriad of other reasons like it simply being expensive to compute

sure

that's a reason why YCbCr still rules, as I mentioned...

indeed. in the end, it's a good color model/space to be aware of, but it's not exactly the most useful out of scientific uses or using as an inbetween

xyY is a bit more useful since it splits chromaticity from luminance but other then that, also not super useful

doesn't XYZ do that?

or do you mean it does it more perfectly

no, XYZ is additive, chromaticity is based on luminance, one sec there is a good PDF describing this

https://graphics.stanford.edu/courses/cs148-10-summer/docs/2010--kerr--cie_xyz.pdf

not quite, it's basically a linear combination of the LMS sensitivity curves of the human eye. but not all XYZ/LMS triples correspond to real colors, since the curves overlap (so e.g. you can't activate only the Y/M sensor with real light)

you get the chromaticity diagram of all colors humans can see by iterating over all wavelengths, seeing what XYZ values those result in, converting that to xy (chromaticity only) and then drawing that as a 2d shape

why would it not be a color space?

What happens if you try converting the impossible colours into other colourspace and display them

if you convert them to color space with real primaries you get negative values

e.g. same thing as converting bt.2020 colors to bt.709, mathematically it works out fine but for colors that don't exist in bt.709 you end up with negative values

oh so that is why I notice negative values coming to my vapoursynth filter sometimes

I once found a -0.8 and of course my inverse transfer function wasnt built to support that so it created issues ahah

yep, you do run into issues when you use a transfer function, but as long as you stay within linear xyz/rgb values everything is fine

I am impressed by the fact that CPUs are so slow to process images typically, doing RGB to XYB seem so fast to me

How SIMDable is it

or the fact that SSIMU2 is only 6 gaussian blurs and yet it manages to be only 20 fps

as I said, colorspace here is an overloaded word, as a colorspace more commonly refers to the "gamut, transfer, whitepoint" which doesn't *really* apply to XYZ.

well it's pixel by pixel

so it is basically << 1ms on my gpu

need to check again my traces but probably around 330 microseconds

while it is a color space by one definiton, it isnt by another

indeed, and this is part of why xyY exists, but that's not super duper relevant to the point at hand, the major point is "it's made to encompass the typical human visible spectrum"

Indeed, without optimization, cpu processing sucks. gpus are just really fast if loops [av1_dogelol](https://cdn.discordapp.com/emojis/867794291652558888.webp?size=48&name=av1_dogelol)

idk, i think the only reason you could say it doesn't apply is because "white" doesn't make sense there, but alternatively and equivalently you can define a color space as primaries (in XYZ) + a transfer function

and it doesn't differ from other linear color spaces in that sense, other than the fact that it just "happens" to have (1,0,0), (0,1,0), (0,0,1) as the primaries

it would be very cool to have CPUs and GPUs working closer together and not have this insane communication problem between them this is sort of what AVX tries to achieve but it is not great at it and greatly affected by low memory bandwidth

yeah, you can use XYZ to make a colorspace in that definition, but in isolation it wouldn't. in general I just hate overloaded terms

apu says hellp

AMD actually had an SDK for this at one point but it is long gone afaik

yep, APUs seem cool

in big server compute chips, we are starting to see CPU X GPU merges in great way

like gracehopper chips

way more powerful than APUs

I mean, riscv with RVV is practically that

I do know people are actually working on fully fledged vulkan capable gpus using riscv

Apple silicon?

not fast enough

Or more like PS2 EE and PS3 CELL?

in the end, shared memory can only go so far, you need the actual programming APIs to properly share resources

Auxiliary power unit?

Usually "color model" is used to mean "family of color spaces", e.g. RGB and CMYK are two different color models but they both can mean many things, i.e. contain many color spaces. The only thing that is fixed really is the vague meaning of the components. A "color space" is something with an exact colorimetric interpretation, e.g. sRGB or Rec.2100PQ, or U.S. Web Coated SWOP v2. XYB, CIE XYZ, CIE Lab: these are color models and also color spaces. RGB, CMYK, LMS: color models but not by themselves a color space (you need to be more specific and define more stuff to define a color space). YCbCr, YCoCg, HSV/HSB/HSL: these are color transforms that can be applied relative to any RGB color space (or even to CMYK color spaces)

It is, and I re-implemented it. cjpegli subsamples the B channel by default, but specifying 420, ect would subample Y due to it being the second channel in XYB. I fixed that in my fork, but I'll try subsampling X too, since single channel subsampling isn't doing much for density. jpegli used XYB instead of YBX because the internal RGB maps best to XYB R = Green - Magenta G = Luminance B = Blue - Yellow And the others explained why YCbCr XYB is a bad idea

I thought you were always supposed to downscale in linear RGB and then rechange color space so how would you do you do XYB -> -Y- |-> linRGB -> downsapled lin RGB -> X-B then you assemble the planes?

That's ideal, yes.

rgb565 mfs living it up rn

Considering how harshly B gets crunched, it might as well be XYB682

what else than CIE XYZ can it refer to?

~~heretics~~ people sometimes apply arbitrary transforms and stuff onto it like transfers, gamut limitations and other weird things

urk

Ah so colour model is more like the philosophy and the space is the specific numerical values used?

```byte sec command ---- 15,322,826 0.308 oxipng -a -f 0 --zc 1 ---- 10,070,544 0.321 qoi 8,256,669 6.875 oxipng -o 4 7,352,613 0.173 cjxl -d 0 -e 1 6,242,268 37.836 cwebp -lossless -m 6 -q 100 5,570,090 2.190 cjxl -d 0 5,323,164 311.01 cjxl -d 0 -e 10 -E 4 -I 100 -g 3```

isn't CIE XYZ really just an RGB color space? i don't see how it's fundamentally different from any other RGB color space with linear transfer function and imaginary primaries

pretty much

it’s similar to the older CIE RGB but the matching functions have only positive values

well, not that much older apparently (same year)

https://commons.wikimedia.org/wiki/File:CIE1931_RGBCMF2.png CIE RGB’s matching functions, vs XYZ’s: https://commons.wikimedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg

if you take a vertical line and run it from one end to the other, the triplets you encounter form the spectral locus in the chromaticity diagram (the curved part of the outline https://commons.wikimedia.org/wiki/File:PlanckianLocus.png)

https://ars.els-cdn.com/content/image/3-s2.0-B9781845699727500011-f01-04-9781845699727.jpg

nice illustration

JXL works pretty good on this image

When you have some time, would you mind trying `cjxl -d 0 -p` with this PR on a large image and comparing it to main? We're assuming a near linear speed increase with thread count, but it'd be nice to confirm it https://github.com/libjxl/libjxl/actions/runs/14654098262

Much faster on my 7950x ``` main $ time cjxl -d 0 -p OpenTTD_16K.png OpenTTD_16K_main.jxl JPEG XL encoder v0.11.1 794a5dcf [AVX2,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 52390.6 kB (3.158 bpp). 15360 x 8640, 2.924 MP/s [2.92, 2.92], , 1 reps, 32 threads. real 0m46,823s user 1m3,303s sys 0m5,618s ------------------- PR time cjxl -d 0 -p OpenTTD_16K.png OpenTTD_16K_pr.jxl JPEG XL encoder v0.12.0 2695d26 [_AVX2_,SSE4,SSE2] Encoding [Modular, lossless, effort: 7] Compressed to 24022.1 kB (1.448 bpp). 15360 x 8640, 8.916 MP/s [8.92, 8.92], , 1 reps, 32 threads. real 0m16,344s user 0m54,789s sys 0m5,524s ``` PR cjxl also improves the loading times ``` [Loader::qt] OpenTTD_16K_main.jxl "image/jxl" QImage::Format_RGBX64 "sRGB" transform:none 1279ms [Loader::qt] OpenTTD_16K_pr.jxl "image/jxl" QImage::Format_RGBX64 "sRGB" transform:none 595ms ```

The "Compressed to 52390.6 kB (3.158 bpp)" for your version is incorrect btw, the image is only 23M large

Which may actually be the reason why the loading times are improved

Yeah I... Don't know what happened there. The readout is correct for us and is around half the size of main too

Looks like your terminal is duplicating the output for some reason?

Ah, it may be due to a crash I've had before pasting this

RAM ran out lol

So safe to disregard I guess

I corrected my post with the values from a rerun

3x faster and 2x smaller, nice

I wonder how it scales with veluca's Threadripper

We did try reducing memory usage too, but it completely broke the compression

Maybe in a future PR

Memory usage was about the same as main, so nothing to complain about in my book

Your build is also around 0.5 seconds faster in non-progressive, so 3.5 seconds instead of 4 seconds

compare via ssimulacra2 or someth

my experience is a DRASTIC change in file size is more often than not just a bug

They were the same, it was an error on my part, I had tried my hand at a very large image and crashed. So just an error copy pasting by me

well a crash would make it smaller <:KEK:1283989161111715913>

xd

Is this an AMD cpu?

Yes

16 cores 32 threads

Would you do me a solid and test Hydrium?

I only have Intel

sure

it's lossy ofc

but im just curious the single threaded perf

Should I compile or just download latest?

compile

no published since some changes

Considering creating a way to allow hydrium to multithread

currently the library is not thread-safe wrt the same encoder instance. (it's stateless so it's thread safe in that regard)

It's compiled now, but how do I actually use this? I have no binary after building. I assume this is an error on my part

Ah, nvm, I forgot to run ninja

you may also want to configure with -Dbuildtype=release

compiler opts matter a lot

particularly automatic fma

Where do I put this flag? into meson.build?

cli

`meson setup build/ --reconfigure -Dbuildtype=release`

`ninja -C build/`

Done

Ok, I'll test now

Id probably implement it so there's a subencoder struct and each tile can be sent on a separate thread which the caller must set up, and then once they send all the tiles and join all the threads they can call finalize or someth

For a 15360x8640 image it took 6,563s to encode with default settings, but this would not load in my image viewer and ate up around 6GB of RAM. Encoding with --one-frame was slightly slower, at 7,984s, but the image loaded quite fast in my image viewer. Should I try a smaller image? Or is this expected?

Here's the image

Hydrium's encoded JXL was 38MB

OpenTTD my beloved

The encoded JXL can also not be decoded with djxl

So something is very wrong with it

A reencode does not fix this

actually cannot be decoded or just takes too many resources? it was known some time ago that hydrium takes major resources for decode

but I have not kept up with it

In this case, it was fixing a bug. Progressive lossless was causing a severe issue with palette and squeeze, seemingly triggering pallete on the smallest squeeze step and causing it to double the bpp on the rest of the file. Then we also enabled YCoCg for an extra 0.6 bpp or so

I vaguely recall using an 8K test file and it used 12GB of memory, 16K is likely hitting a limit

Well, could be that it takes some time, but I waited for 5 minutes and it didn't decode, so I assume it will not even if I wait longer

I think that is an incorrect assumption. it just takes an impractically long time in my experience

Could certainly be the case

whatbabout --tile-size=3?

surprised one frame is slower

Maybe it's slower because the encoder fails at encoding the image?

default setting hydrium encodes decode very slowly with libjxl

I have encoded and will now try decoding

Ok, this one decoded quite fast and works as expected

Encode time was 7,075s

Decode time in my image viewer was a whopping 24.5 seconds

That's around 30 times higher than the 800ms it takes with libjxl

interesting

that's somewhat what I expected

7s for a 16k image though is a bit much

how long does it take to encode it with `cjxl -e 3 --num_threads=0`

7,155s, almost the same

I keep misreading it as thousands because of the comma, thinking "damn I know hydrium is slow but 2 hours seems a bit much" xD

That's due to my locale :p

And I am too lazy to replace it every time

I know what u meant so it's fine

ah okay. atm my tests are that it's comparable to cjxl -e 3 on a single thread

speed-wise

but uses considerably less memory

So around same result for time I got

ye

what happens if you wrap it in memusage

specifically heap peak

cjxl: Memory usage summary: heap total: 13113988389, heap peak: 1889278942, stack peak: 34032 hydrium: Memory usage summary: heap total: 2709580194, heap peak: 425811326, stack peak: 4944

Significantly less

my guess is that a good fraction of that 425 MB is buffered by the frontend