JPEG XL

on windows, it uses the display profile you set in OS settings

I thought that feature was not here yet?

and I think you need to set `gfx.color_management.mode` to 1 or else it will only use it for tagged images

iirc Firefox doesn't really have that much stuff needed to target displays or color spaces however it will properly color manage images with embedded icc profiles

sometimes™️

on OSX to get colormanagement you need to use https://addons.mozilla.org/en-CA/firefox/addon/extended-color-management/

on windows, you can try and use it and pray I guess

it has had a full color management pipeline based on icc for a while

isn't firefox's ICC handling a bit of a joke? last I saw it, it was

what are the issues?

video support?

yeah I meant only for images. I think they have made progress on video recently but not sure how much

not just videos, I can't remeber exactly what the issue with qcms was but I remeber looking into it recently and it was super limiting in what it can do

one of the tests here fails: https://littlecms.com/blog/2020/09/09/browser-check/

v4 support?

firefox supports v4 but apparently rejects some valid v4 profiles

yeah that was my second guess

for flaws of firefox color management

that said, how widely adopted is icc v4?

I hope when servo lands it has good color management support T.T

also I'm reading it does not support cLUTs... which is a bit strange. I thought it did...

sorta off-topic but does anyone know if there are any programs that do multi monitor color managed rendering besides the classic/old Windows Photo Viewer?

I think chrome might have support for that

didn't seem to work when I tested it

oh interesting. I thought I remembered seeing some code for that a long time ago

maybe it only works on video or something...

classic Windows Photo Viewer will literally split it's rendering across every monitor on the same image, so for example if you have an image open in a single windows that's being displayed on like 4 monitors at once each section of the image will have different colors

only for 8 bit images. It doesn't manage 10 bit images AFAIK.

yeah, I have no idea how it handles anything 10-bit or HDR related

IME 8-bit HDR-tagged JPEGs get tonemapped fairly well

but a 10-bit AVIF just, won't be color managed at all

isn't this just automatic? like in the sense that Firefox doesn't really have to do anything at all to get a tonemapped result?

without color management they look completely wrong

for example, look at this image: https://cdn.lonjil.xyz/fdbcefe61c89d335/pfW9ODQ.jpg

when discord generates the preview image, the ICC profile is stripped but the color data is kept as is, so it's interpreted as sRGB, and looks washed out. But Firefox's tonemapping makes it look like this:

far from perfect, but it is actually doing tone mapping

anything based on libplacebo should

Firefox is not doing tone mapping, that's just the normal ICC profile handling you're seeing

the SDR image is using Rec2020 primaries in that image

ignoring the icc profile like discord does will make it look desaturated

Firefox is not ignoring the icc profile, but it is ignoring the HDR gain map

on the left: firefox on the right: safari

both are only rendering an SDR image, but firefox shows just the fallback SDR image, while safari does interpret the HDR gain map and then tone maps it down to SDR again

and Chrome shows it in actual HDR

I must be an idiot, but I can’t see gainmap via exiftool in pfW9ODQ.jpg (~~and Photoshop and CameraRaw looks like Firefox~~*). But indeed, Chrome looks like this:

well, the simple "clip" tonemapping is tonemapping as well I think... Just not very good one, as it destroys all detail in the highlights.

Sorry, setting Photoshop’s Precise Colour Management for HDR… makes it look better on a HDR display (still bad on SDR). If I’m correct (?), and there is no “UltraHDR”-like gainmap here, why Chrome looks so different to Firefox and Photoshop SDR? Would that be what Eric Chan cites as argument for “UltraHDR” (“Provide consistency and predictability for how HDR content is displayed across apps, devices, and platforms”)? Is tone mapping to SDR that inconsistent? Or is it just that Firefox and Photoshop SDR haven’t **yet** built support for what Chrome has and it will be consistent one day?

the Firefox rendering looks like plain clipping

and the ICC profile (“Rec. ITU-R BT.2100 PQ”, copyright Apple Inc.) has a CICP tag

interestingly, it shows as HDR in the Discord app for iOS

apps on Android and iOS are much more likely to use shared system libraries for lots of stuff

Maybe the Discord app is loading the full size image? The preview image Discord generates simply strips the ICC profile, and so can't be displayed correctly no matter what.

right...

the preview is this webp image

So this CICP tag in the ICC profile signals something that Firefox doesn’t see (yet)? Like range or transfer function? Do you know how can I see what this CICP contains in this JPEG’s ICC profile (ColorSync Utility, exiftool won’t print its contents out…)?

not sure about a convenient way to extract it, but libjxl will read it 😶 so maybe compressing it to jxl and running `jxlinfo` on the result?

that's kinda funny, I got that image by putting an HDR JXL on my iPad and then exporting it as a jpeg

(I’m not fully sure we read it when recompressing jpegs losslessly, so you might have to compress it lossily)

It's not quite doing that, it's ignoring the gain map. In this case the SDR image looks like a clip tone mapped image, but it could be anything else (with the gain map adjusted to keep the HDR the same).

Oh, I didn't actually check, maybe it's not a gain map jpeg but just a regular one?

pretty sure it isn't a gainmap jpeg

Pure curiosity: how did you export it? (just want to know which app is so clever to write this CICP only Chrome seems to correctly (?) interpret)

I think it's the OS's media framework. I just tried using the JXL in a context where it isn't supported, just like how HEIC photos on an iPhone become JPEGs when you try to share them on social media. In this case I used a reddit app and used the "post an image" feature and selected the JXL file.

so, --streaming_input is supposed to have larger output compared to not using it, right?

it's 2B larger than not using it, at least for this image I'm testing it with

well, for other images they're the same 🤔

not using it only takes about 36% more memory, too (when doing lossy)

what size of images are you using?

well, first test was with 4K UHD (so 3840x2160), where the streaming one was 2B larger, but with a 16K image (15360x8640) their output is identical in size

actually the memory use is only ~30% worse when using lossless without --streaming_input

weird...

input format?

ppm

are they supposed to produce identical output?

ooooooh, wait

does it embed the output file name in the file itself, as metadata?

no no

ah, I see

what changes filesize is actually `--streaming_output`

streaming input should have very minimal impact

well 2B is very small (considering that image was 4.1 MB when compressed losslessly with `-e 9`)

what memory usage are you seeing?

for 16K, lossless, with no streaming, e 7, peak mem (as reported by `time`) was: `1,670,552 KB` exact same thing, but with `--streaming_input`, was: `1,284,436 KB`

I haven't played around with `--streaming_output` but that's next <:PepeOK:805388754545934396>

Weird, I'd expect less ... How big is the output file?

101,280,678 bytes

using both `--streaming_input` and `--streaming_output` gets the lowest memory use: 775,844 KB

and any combination of those (i.e. none, just input, just output, or both) all results in the same file output size

same file output size is odd

but I will not complain about it

700ish mb is at least reasonably close to what I saw before

unsure why we use 500mb to store a 100mb file though...

yeah, even uncompressed the file is only ~400 MB

There's also the constant cost of the code itself, I guess. Libjxl and other dependencies of cjxl, are they included in the numbers `time` reports?

I believe so, but they're not 400 MB: ```ldd `which cjxl` | cut -d' ' -f 3 | sort | uniq | xargs stat -c %s 216192 1948832 75608 728120 15 22 28 22 16 965016 26 30 30 19 19 11 24 21 21 20 29 16 24```

and cjxl is only 164984 bytes... so add that all up and you get ~4MB and some change

in any case, we're talking about a difference with everything the same except for two params, so the code size shouldn't matter whether it's counted or not

Could be worthwhile to do some memory profiling to see where it is going...

To be honest, I don't see any reason to *not* use `--streaming_input` or `--streaming_output` so far. Maybe for really small images they don't make sense, but for everything else, they reduce memory, speed up encoding, and carry only a very minor size/BPP penalty (if any)

I kind of wonder if they should be on by default 🤔

Streaming output is on by default in 0.10.

doesn't appear to be

`cjxl -h` output: ``` -e EFFORT, --effort=EFFORT Encoder effort setting. Range: 1 .. 9.````cjxl foo.png bar.jxl -e 0` output: `Invalid flag value for --effort: Valid range is {1, 2, ..., 10}.` <:Thonk:805904896879493180>

10 seems to work, so looks like `-h` is wrong and not the error message

wat

I meant version 0.10

has anyone tried recording streaming_output vs without it using massif? it would be a neat thing to check

with the current libjxl-git this is encoding a `7432x3877` png ```ps memusage -p stream.png -t cjxl mona.png stream.jxl -e 7 -d 0.5 --streaming_output memusage -p nostream.png -t cjxl mona.png nostream.jxl -e 7 -d 0.5 memusage -p stream-2thread.png -t cjxl mona.png stream-2thread.jxl -e 7 -d 0.5 --num_threads=2 --streaming_output memusage -p nostream-2thread.png -t cjxl mona.png nostream-2thread.jxl -e 7 -d 0.5 --num_threads=2 ``` PNGs are in order of above

v0.9.2 had 3098m allocated no matter what, it's worth noting that memusage doesn't monitor full pages so other programs may report differently

What exactly does streaming do?

afaik it writes the output/input as it can instead of storing it in memory, it doesn't really seem to change much for me

nostream vs streaming with `memusage -p {nostream,stream}-0.10.0.png -t cjxl windwaker35xnative.jpg windwaker.jxl --lossless_jpeg=0 { ,--streaming_output} -e 5 -d 0.5`

`cjxl windwaker35xnative.jpg windwaker-no.jxl --lossless_jpeg=0 -e 5 -d 0.5 230.81s user 38.20s system 729% cpu 36.857 total`

this is neat, libjxl-git can now actually encode this `23164x18480` jpeg without reconstruction without OOMing

basically this is kinda massive image lol

guys ... e7 compresses better than e11

That is unexpected but not impossible

Doing local tree learning (as is needed when doing streaming encode) gives different results than doing it globally (which we used to always do, and now only at e10+)

In principle global trees can be better, but considering that in both cases greedy search is used, which does not find optimal solutions, it can go either way.

it's a 64x64 px image, so something else

ok only v0.9 e7 compresses better than v0.9 e10 (v0.10 produces smaller output ... but I still consider this a victory <:PeepoDiamondSword:805394101340078092>)

I think that the corelation between size and effort is meant to be "on average". You will always find samples which do not follow the rule

yes

but e11 is stupidly resource intensive, so when it fails, it's phenomenal

yes, in 0.10.0

if you're on some random pre-release version, you need the latest release

there were pre-release versions?

git master

I only use tagged releases

does anyone have a image that compresses losslessly better by cwebp than any effort of cjxl 0.10?

nvm, I found one

@Orum this sheet can help you find what you are looking for : https://docs.google.com/spreadsheets/d/1ju4q1WkaXT7WoxZINmQpf4ElgMD2VMlqeDN2DuZ6yJ8/edit

this is pretty old, but as I said, I already found such an image

if you want another one 😄

I see there is a new encoding effort 10. Were there any changes to previous efforts? -e 9 seems to yield the same results as before. Was the old hidden -e 10 just split into new 10 and 11?

no no, -e 9 is much faster now

-e 10 is the old -e 9, more or less

When exactly this change took place?

https://github.com/libjxl/libjxl/pull/3248

https://github.com/libjxl/libjxl/pull/3337

I'm using settings -d 0 -e 9 -I 100 -E 3 -g 3, the latest build produces the exact same files as build from January. Do the other arguments override the changes done to -E 9? Anyhow, -d 0 -e 10 -I 100 -E 3 -g 3 produces smaller files.

Where are you getting the builds? #3337 was just merged, it made `-e 9` way faster and worse at compression. And with 0.10.0 `-e 9` does not use global optimisations.

See https://www.reddit.com/r/jpegxl/comments/1axpyjf/_/ and https://github.com/libjxl/libjxl/issues/3323#issue-2151216970

I was testing a build from earlier today. Now there's a new one, I'll give it a try.

Same results, however it still doesn't include #3337 https://artifacts.lucaversari.it/libjxl/libjxl/latest/

https://github.com/libjxl/libjxl/actions/runs/8054036781

Should probably work, but haven't tested

Thank you, I will try it.

Ah yes, so now -e 9 is slightly less efficient than before. So now I'm going to be using -e 10, it's more efficient than the previous -e 9 anyway.

try `--patches 1` too with `-e 9`

Patches seem to be turned on by default.

for `-e 10` it is, not for `-e 9`, I think

Yup

the new -e 10 is faster than the old -e 9 anyway

that MT encoding support <:FeelsAmazingMan:808826295768449054>

I see little reason for WebP's continued existence, now that cjxl is significantly faster, usually compresses better, and has comparable memory consumption

I'd say lossless WebP had good results because PNG is pretty bad.

I'm late but you tried to use `-e 0`? Was that a typo or...? `--streaming_input` can be considered a flat, fixed, memory reduction per input file. It will take away the memory use of the entire image, and only load 2048x2048 areas at a time for encoding In 0.10.0 the encoding is now streaming by default up to `-e 10`, but will keep the entire image loaded at once. The 30% difference you noticed was likely the image data being removed by using `--streaming_input` Others can feel free to correct me, my info is a few PRs behind

depends on content ⌨️

`--intensity_target=N Upper bound on the intensity level present in the image, in nits. Default is 0, which means 'choose a sensible default value based on the color encoding.` Does anybody know how the intensity target is chosen?

no, the whole point of that message was just to illustrate that `cjxl -h` is wrong about the range of efforts available

I already submitted an issue on GH about it

Is this what the dice are meant to look like?

I'm on Firefox Nightly

it seems not

Firefox nightly is not handling alpha properly

That's what I assumed

There are patches to fix it for two years or so, but Mozilla has no resources to click the merge button.

Lmao, hoping one day it'll be supported on most if not all modern browsers

iirc only Safari has it right (and a few FF forks)

just use safari

I'm on Windows

or Linux (fedora) when I need to compile some stuff

I got opposite results, 0.10 -e 10 is always a bit worse than 0.9 -e 9

What is the the intensity target anyway? I suppose it has something to do with color profiles.

10 000 for PQ, 1000 for HLG, `whiteLuminance` EXR header if present, otherwise `kDefaultIntensityTarget`

So if I understand correctly, PNG input always uses kDefaultIntensityTarget

Ah, my bad, I saw that issue but assumed it was unrelated

no worries

not necessarily – PNG is able to signal PQ and HLG thanks to either its new cICP chunk, or the new cicp tag in ICCv4.4

I see, so it is color profiles after all, but it has nothing to do with bit depth etc.

right, it’s pretty much about how bright the image is

it's really interesting to see where webp beats all levels of <:JXL:805850130203934781>

for my screenshot tests, it seems to be largely in pixel art games (e.g. Skul: The Hero Slayer) or games with very fine detail/noise (Age of Empires 2, both the Definitive Edition and the HD Edition)

Metro 2033 as well, but again, I think that has a lot of fine noise in the images

I wonder why it does so poorly on pixel art though (or perhaps cwebp is just really good at that 🤔)

probably because lz77 for the whole image is better for some cases and jxl is limited by block/group size, even though it can reuse the same thing from webp

Here's a good example. Best cjxl could do was 81,570 B, more than 43% more than cwebp's best.

also patch detection is pretty bad for lossless 😛

nice screenshots, is this the kind of screenshots you have in you corpus ? I heard that webp lossless did some tricks a bit better than jxl, especially on paletisable content (which doesn't mean that the cjxl will not be able to mimic these tricks)

I can't find the messages, but I know wb has said in the past that WebPs pallete ordering is much better than JXL's simple sorting currently, which has a large effect for pixel art

I did manage to do `62442 bytes` with patches though

what arguments did you used ?

There's an issue open of a Nintendo DS emulator, has both screens showing the same image apart from a text box on one if I recall, but patches only copies about 10 pixels from the corner of a desk out of the entire image xP https://github.com/libjxl/libjxl/issues/3109

Yeah. The bulk of the screenshots are smallest in JXL (372 of them), but several are still smallest in WebP (50 of them).

`-d 0 -e $c --streaming_input --streaming_output --quiet`

maybe I should do lz77-style patch detection at some point

Huh... Nice idea

using say 2x2 pixel areas

is this related? https://discord.com/channels/794206087879852103/794206170445119489/1126433055540785172

Bit packing is a separate technique, for example putting 4, 2 bit pixels into 1 byte

Good to know I've been spelling palette wrong this entire time https://discord.com/channels/794206087879852103/794206170445119489/1128666609955909683 https://discord.com/channels/794206087879852103/803663417881395200/1150779618433962104

But either way, I found the messages

still larger 😭

also that's a lot of manual tweaking to get there... <:KekDog:805390049033191445>

not that much of tweaking, but there are some settings that may give better compression `-e 11` will probably be able to do even better, sadly that it's not possible to know what settings were used

sure, but most people aren't even willing to try more than one effort when compressing an image, let alone tweaking `-I` and `-E`

A general rule of thumb is to tag on `-E 3 -g 3 -I 100` if you want *generally* the best compression without increasing effort. But for different kinds of images it will naturally have different effects. For instance a while ago I had an image that was half the size at `-g 2` than any other setting

oh wow, I have images where the best I got out of cjxl was 347% the size of the cwebp output <:monkaMega:809252622900789269>

this one, to be specific:

JXL could take advantage of patches in tiled graphics like this, then the picture could be compressed to few bytes. Unfortunately the encoder doesn't seem to be smart enough to determine the boundaries of the tiles.

yeah <:PepeSad:815718285877444619>

yeah that's definitely a great example of improvement opportunities for patches

there are some examples where cjxl is noticeably better though, too

yeah, for any images with repeating patterns or large same pixels areas webp is likely to be better, for now

despite being pixel art, this was notably better in <:JXL:805850130203934781>

AI bros are salivating right now

does sound like the job for machine learning

we should open an issue with all pathological files 😄

I would agree with you except I think there are already a bunch of issues open for each individual case

sounds like the time you make a meta issue

nn downsizing would be also helpful for pixel art and i even saw a pr for that somewhere

Pictures, where all pixels are arranged in 2x2 squares (double pixels) could be losslessly downscaled, although that is a kind of specific case.

yeah, a lot of pixel art games actually have non-pixel effects placed on top of them

if we could have access to the state of the SNES when the screenshot was taken, that would open up a lot of possibilities

https://cdn.shopify.com/s/files/1/0444/0919/2598/files/pasted_image_0_1_large_927cb3cf-8de9-4527-a5e4-01a1485ef2d3_480x480.png?v=1601875582

few can actually be integer scaled down and back up to the screenshot resolution (without any changes)

modern pixel art style games, anyway

obviously those that were actually created for low resolution systems can't have non-pixel effects on top of their pixel art

https://github.com/libjxl/libjxl/pull/2571

It works well, but is a bit of a hassle to get it to trigger properly sometimes https://github.com/libjxl/libjxl/issues/2738

I'm sure I had a case where trying to change upsampling resulted in an error, but I was also using GIF animations and had frame blending cause issues too

Sounds like a PR for an emulator will be in order one day

I have a screenshot of the end from minecraft. like 50% is the skybox, which is extremely noisy it took like 40 minutes, but jxl is by far the best compression for that image: ``` 9545 1.jxl 11179 1.zpaq 11250 1.7z 18112 1.png 20253 1.webp 172801 1.ppm ``` https://www.mediafire.com/view/v8ppwztxuqs5f4v/1.png/file

10240x5760

yeah, it very much depends on the image itself

my bad, webp is actally 20253 K, didn't use `-lossless`. also changed to `-m 6`

Another fun case: ``` 21K 1.jxl 45K 1.webp 59K 1.7z 106K 1.png 114K 1.zpaq 169M 1.ppm ``` Image scaled down to 1080p

should probably use `-z 9` with cwebp to get the max lossless effort because the effort for lossless encoding is based on a combo of `-q` and `-m` with `-z` setting both of them, also I would recommend using `-mt` with cwebp as well since it speeds things up for the same final output.

I did. that's the first time I used cwebp, so if there are other flags, please let me know ` cwebp -mt -z 9 -lossless -o 1.webp -m 6 1.ppm`

``` zpaq -m511.1 a 1.zpaq 1.ppm 7z a -t7z -m0=lzma2:d1024m -mx=9 -mfb=64 -md=32m -ms=on -mhe 1.7z 1.ppm zopflipng -m 1.png 1.png ```

other useful flags I would say are `-alpha_filter best` and `-metadata icc`

The fastest speed I've seen that produced the smallest <:JXL:805850130203934781> image (of any speed, for a given image) is 4 so far, but perhaps most interesting is I've yet to find an image where 5 or 6 were the smallest <:Thonk:805904896879493180>

saves 1 kB on the second image no alpha in the source

On lossy I assume?

lossless

perhaps most notable is I've found an image where `cwebp -z 0` is smaller than any other level of `-z`

also found some where `-z 2` is the best, which I hadn't found before, but still haven't seen any where `-z 1` is

very weird how `-e 9` often outperforms `-e 10` though (in terms of compression ratio)

'Wins' of effort *within* each encoder: ``` cjxl -d 0 --streaming_input --streaming_output -e ... 4: 1 7: 2 8: 22 9: 353 10: 44 cwebp -z ... 0: 2 2: 1 3: 5 4: 20 5: 1 6: 1 7: 16 8: 32 9: 349 ```efforts not listed had 0 wins, and sometimes different efforts would tie, which is why they don't add up to the same totals

that 21k jxl was from 2021/06/07. funny thing is I can't recreate it now on the main branch. `-e 10 -I 100 -E 3 -d 0 -g 2 ` takes like 6 minutes and gives 29K `-e 11` crashes on 32 GB ram

with git changes `-e 9` should be slightly worse, also `-e 10` doesn't use streaming mode by default, which is the point why it even exists, because it makes efficiency worse on average and `-e 10` is basically `-e 9` without streaming mode

still, I don't think e 10 should be both slower and worse ratio than e 9, even if streaming mode is forced

but hey, that may have already changed, as you said

get the new build

https://artifacts.lucaversari.it/libjxl/libjxl/latest/

I'll stick on stable tags; I have enough work to do without testing every git commit

yeah, but in the new version so most likely `-e 9` will always be a bit worse than `-e 10`, even with streaming mode

the new one specifically changes `-e 9` to fix that issue

also, wins *between* the different encoders: ``` cjxl 7: 2 8: 14 9: 317 10: 40 cwebp 0: 2 2: 1 3: 1 4: 1 7: 4 8: 4 9: 36```

57596B d0e10P0I0g3

Just use the right parameters for the job.

feel free to help populate this thread https://discord.com/channels/794206087879852103/1187313089612369991

(I guess the name is outdated by now)

did you have to set P0? doesn't E10 "mix everything" and find it itself? I wonder if I need to check that to find the best one

I hope you're joking <:KekDog:805390049033191445>

e 10 was moved to e 11 in 0.10

it will build a tree using various predictors including zero, but in this case it's better not to use tree prediction, which the encoder will not figure out until e11.

nope, this is standard for scaled pixel art, except patches are usually bad when you don't have text.

``` mean colors/px | mean patches/no patches images mean MP | | mean e3/e1 | share | share | | | tag 9 37.50% 0.75 37.14% 0.00 1.00 1.84 DirectClass_sRGB 7 29.17% 0.60 23.42% 0.00 1.00 2.41 DirectClass_sRGB_Alpha 7 29.17% 0.86 33.46% 0.00 0.98 1.77 PseudoClass_sRGB 1 4.17% 1.08 5.98% 0.00 1.01 3.15 PseudoClass_sRGB_Alpha 24 100.00% 0.75 100.00% 0.00 1.00 2.04 all 24 100.00% 0.75 100.00% 0.00 1.00 2.04 pixel_art_scaled 12 50.00% 0.75 50.06% 0.00 1.01 2.03 source_imagemagick 12 50.00% 0.75 49.94% 0.00 0.99 2.05 source_web Pareto front for user+system time and size |included in 'all' mean Mpx/(user+system s) || mean bpp mins | best of U· 0.15808231 100.00% 0.0731772 all UA 0.16293870 58.33% 0.36356 cjxl_0.9.0_d0e9P0I0g3modular_palette_colors10000patches0num_threads0 UA 0.16759048 4.17% 0.60918 cjxl_0.9.0_d0e9P0I1g3patches0num_threads0 UA 0.16986516 8.33% 0.82549 cwebp_1.2.4_z9 UA 0.17222839 4.17% 30.9 cwebp_1.2.4_z7 ·A 0.17234923 4.17% 0.46346 cjxl_0.9.0_d0e9P0I100g3patches0num_threads0 U· 0.17480589 ····· 31.9 cwebp_1.2.4_z6 U· 0.17822351 ····· 34.5 cwebp_1.2.4_z4 UA 0.18057047 8.33% 34.5 cwebp_1.2.4_z3 UA 0.18661758 4.17% 40.1 cwebp_1.2.4_z2 ·A 0.19439822 4.17% 0.57685 cjxl_0.9.0_d0e9E3I100g3Y0patches0num_threads0 ·A 0.19771261 4.17% 1.1405 cjxl_0.9.0_d0e9g3num_threads0 U· 0.20444330 ····· 50.8 cwebp_1.2.4_z1 U· 0.40893762 ····· >7.5e+02 original```

my point is users shouldn't have to tune 4 different parameters to get a decent result

Yeah, manual tweaking is just a mitigation, the decisions the encoder makes can always be improved

It might be cool if the encoder had tuning modes like x264 does

photo mode vs pixel art mode etc

in the help message, "mix everything" is paired with `-e 9`, so it should now happen with `-e 10`

Oh, I thought by "find it itself" you meant the brute force mode that tries every combo of settings

The encoder seems good to me

24,6% better than webp at e10

Fb on some images ard optimized by me still is amazing

fab is at work again.

why are fuzzerbugs being tagged as unrelated-to-1.0?

I feel like those are important bug fixes

for a final release

sometimes I wonder why we even have image codecs 😮‍💨 ```769M ./factorio.ppm 121M ./factorio.ppm.xz 368M ./factorio-8.jxl 366M ./factorio.png```

that's such a strangely large difference, any way I can download that image and toy with it too?

possibly relevant: https://github.com/Traneptora/xz-pixbuf-loader

it's because factorio screenshots have a lot of reused sprites (as this image does)

going to try with patches to see if that can redeem <:JXL:805850130203934781> at all

in either case, lossless webp is very good at palette detection and that sort of thing, so try doing `cwebp -z 9 factorio.png -o factorio.webp` and see how it goes

the image is too large for webp

oof

XZ pixbuf loader to the rescue then kekw

jxl also most likely, but with customized settings and without streaming

without streaming is just pain though 💀

would rather always use xz at that point

also with P0 it's fast enough without streaming and it's good for images like this, though not always

This is why Veluca mentioned the idea of lz77 patch detection. So it can find sprites and reuse them across the image

yeah that would be very nice <:BlobYay:806132268186861619>

but it's about 2x2 patches and the like, much smaller than needed for sprites though just improved lz77 could be good too, like in webp

Well, 2x2 was a suggestion, I'd assume it could be increased or other heuristics used

I just meant "start with 2x2 corner, then extend"

right, but for sprite-based graphics I'm not sure how much it would help?

it doesn't matter if it's sprites or not, patches merges all similar patterns

why wouldn't it?

sprites may not be aligned to the corners

He means just start in the corner, then expand to (probably) the entire image

or the entire sprite

i'm curious about this too

how is the format pronounced?

jay peg excel?

jay excel?

jeck-sel?

first 2

the first for the format name and the second for the file format?

Well, whenever you see jpegxl or jxl respectively

Depends on where you live 🙂

Huh Chinese I guess just drop the L?

The confusion between XR and XL in languages that do not have both phonemes is not something that was sufficiently considered.

That’s Japanese I think not Chinese

chinese has distinct L and R

Yeah

Leng: cold

Peng: hit? I can’t fully remember

try qoi

a 769 Mo screenshot ?! what a huge screen you have !

256mpx

Must be some kind of mod

That’s 16k by 16k or something

more than the las vegas sphere !! 16k x 8k

The game's built in screenshot command lets you specify any size.

Yeah, pauses logic and takes tiled captures if I recall

I read the Pareto Front article about JXL which says there's a very significant speedup in libjxl 0.10 from some kind of streaming encoder changes. Do clients need to change anything to benefit from that?

I use libjxl via GDAL, will the GDAL implementation have to change or will it benefit automatically?

I guess GDAL will have to update the libjxl they use, and activate the options when calling the encoding function

I can't see any options that appear to have been added in 0.10?

if it's just flipping a flag I will do it myself

nah, it limits you to 16384²

rip

well that's still not bad, considering it forces you to (initially) encode in png

I wish it would just give me ppm or xz'ed ppm output

qoi is generally worse (in ratio) than png, no?

theoretically this could be used to make infinite resolution screenshots https://github.com/Palats/mapshot

yes, and slower than fpng and fpnge

yeah, I always saw little reason to even bother testing it, based on what I read elsewhere

worse than optimized png, but maybe there are some cases when qoi will be better

I'm so glad this exists, as it saves me the trouble of writing it myself <:CatSmile:805382488293244929>

the reason to add it is that QOI have a LOT of support ! mainly because it can be implemented over a week-end in your favorite language.

that's cool and all from a developer perspective, but from a user perspective, if you're not moving the pareto front then it's hard to get excited about it

but your favorite language probably already has good png library support

the main selling point of QOI is indeed a simplicity, which doesn't exactly correlate to performance in one or another axes 🙂

besides from that though, the fundamental design of QOI does limit its own performance

so while QOI is a really good educational project, it is not very useful as a basis of small but performant codec

this is rather interesting though, as several of my factorio screenshots are definitely better in <:JXL:805850130203934781> than anything else I try (webp, xz'ed ppm, and optimized png)

I suspect it all depends on how much area is of a perfectly regular repeating pattern

should be easy to find a (much smaller than 16k²) pathological case then

probably also `-e 10` + `-I 1 -P 0 -g 3` or `-I 0 -P 0 -g 3` is worth a try, it will perhaps disable streaming mode, but it's faster and less heavy than the normal `-e 10`

I find it's about 50:50 if I don't bother with ect and just use magick or ffmpeg. but it's kinda fast to decode which is neato

well when I tried your patches suggestion it started running illegal instructions <:KekDog:805390049033191445>

for smaller samples, it's simpler to just crop some part of a large screenshot that closely resembles the typical pattern of the entire image

well, it looks like I've managed to do just that: ```8.5M ./factorio-9.jxl 5.6M ./factorio.png 2.6M ./factorio-9.webp 2.3M ./factorio.ppm.xz```

then it probably doesn't do much to reduce memory consumption, just easier to encode <:PepeSad:815718285877444619>

anyway here is the image if people want to play around with it

ppm supremacy confirmed

more like xz supremacy

jxl `-e 0` for advanced ppm <:FeelsAmazingMan:808826295768449054>

make ppm.xz a proper image format [av1_woag](https://cdn.discordapp.com/emojis/852007419474608208.webp?size=48&quality=lossless&name=av1_woag)

oh wow, *not* using streaming results in a *much* smaller <:JXL:805850130203934781>: 2.6M

wild that the streaming one is more than 3 times the size...

still beaten by xz though <:SadOrange:806131742636507177>

pretty predictable because streaming uses smaller independent blocks instead of the whole image, so large single colored images or repeating patterns don't compress well

i wonder if disable compression, put the image in metadata and use brotli for encoding <:FeelsAmazingMan:808826295768449054>

yeah, the problem is utilization drops off a cliff when not using streaming, and memory use goes way up, but I suppose there's no free lunch

and with these settings?

Horrible idea. I love it

Haven't tried yet. Working on a script to redo my testing *without* streaming. You're welcome to though as you can download the image 🥰

<:FeelsAmazingMan:808826295768449054>

slightly larger, but 10x faster to decode than lzma

so it looks like down to `-e 7` encoding is still very parallel (when not using streaming), and then after that is when utilization drops to only ~225%

size was still pretty good at e 7 though, only 2.7 M

zstd btfo

zstd is made for speed, not max ratio

it decodes too fast though T.T

```ps hyperfine --runs 20 'taskset 00000001 brotli -d factorio.ppm.br --stdout > /dev/null' 'taskset 00000001 zstd -d factorio.ppm.zst --stdout > /dev/null' Benchmark 1: taskset 00000001 brotli -d factorio.ppm.br --stdout > /dev/null Time (mean ± σ): 48.4 ms ± 2.2 ms [User: 40.3 ms, System: 7.8 ms] Range (min … max): 45.3 ms … 52.8 ms 20 runs Benchmark 2: taskset 00000001 zstd -d factorio.ppm.zst --stdout > /dev/null Time (mean ± σ): 29.3 ms ± 1.9 ms [User: 18.7 ms, System: 10.4 ms] Range (min … max): 26.8 ms … 35.1 ms 20 runs Summary taskset 00000001 zstd -d factorio.ppm.zst --stdout > /dev/null ran 1.65 ± 0.13 times faster than taskset 00000001 brotli -d factorio.ppm.br --stdout > /dev/null ```

wait I think cpu is bugged

fixed

nope, for this image, it's not better <:FeelsSadMan:808221433243107338>

It will get most of the benefits automatically (assuming it uses an updated libjxl). For the full memory reduction benefits it needs to use the chunked encoding API, but that makes a relatively small difference compared to the improvement you get even when calling the encoder with full buffers.

that's great. I'll just build with an update libjxl then

I have ~100 cores running 24/7 making JXL's of satellite imagery...

(thanks all for JXL!)

100 cores ? can you toast bread at the same time ?

interesting image — it looks a bit like it could be a palette image, but it does have quite a lot of different colors: ``` $ identify -format "%k\n" factorio.ppm 111539 ```

and it looks like it has a lot of repeating patterns but it seems like the repetition is not quite exact

yeah, which surprises me somewhat that xz/LZMA does so well with it

in any case it looks like I will have to abandon streaming input/output for any cases where it's not absolutely necessary <:FeelsSadMan:808221433243107338>

The game uses tiles and sprites, but overlapping sprites, particle effects and lighting mean they're very rarely exact matches

with lzip you can shave 4kb more 😄 (the factorio.ppm.lz lands at 2361189 bytes)

*we have confirmed lzip supremacy*

I could make a quick identification of identical areas (3x3 pixels) and there is many ! Here are only plotted the most frequent repetitions, but I catch many more. For the sake of simplicity, the script only scan the Green channel...

zpaq gets us to 2170558 bytes at max compression

At 1:1 zoom, the sprites are 32x32 max (If I recall) with 64x64 possible with mods

srep is just deduplication without compression

do you mean patches ? what is the minimal size ?

No, I mean in Factorio

oh, oki

The approach I try here (and it seems to work) is to do a first pass and detect identical 3x3 patches (which is relatively fast with a hash table) and then grow around to see if we can grab a bigger area... (not implemented yet)

I hope it could lead to some way to use patches... if not too slow

Scratch that, the game is made of tiles, and each tile can have 64 pixels max, but a sprite can cover many tiles

I see, make sense

I wonder what the minimal size of a patch could be before it becomes useless. I guess it may depends on how many times it is used

lolz v22c4b

Well, .tar.gz is already a "proper format", so .ppm.xz can follow

clearly there is redundancy in that image that can be exploited but libjxl isn't finding it. Between patches and lz77 there should be enough coding tools to do something better, but of course you need an encoder that uses them effectively. Current patch detection heuristics will not do much on an image like this (they require solid background), and it doesn't look like lz77 by itself is doing much either.

$ cjxl factorio.ppm -d 0 factorio.ppm.jxl -g 3 -X 0 -Y 0 -C 5 -e 10 JPEG XL encoder v0.10.0 a070f827 [NEON] Encoding [Modular, lossless, effort: 10] Compressed to 5512.9 kB (5.317 bpp). 3840 x 2160, 0.035 MP/s [0.03, 0.03], 1 reps, 12 threads.

not a great result

oof <:AngryCry:805396146322145301>

I just wanted to see how it'd do

well, you're welcome to download the image above

I don't even have QOI installed

Ah okay, didn't see that

it's not possible for non-stream encoding to produce larger lossless output than stream encoding (with all other options being the same), is it?

Everything is possible

possible, especially on photos

ugh, okay, good to know

well `-e 9` with streaming in/out seems to generally outperform `-e 7` without streaming, at least when it comes to compression ratio

~~and obviously, there are some exceptions, sometimes where non-streaming is **much** better~~ actually nvm, that was webp that was massively outperforming it, not the non-streaming mode

so yeah qoi misses on this one

I'm thinking about using Flutter for an app. It seems it doesn't have jpeg xl support, but a plugin might. If anyone can point me in that direction I'd appreciate it.

the easiest way would probably be jxl-oxide + rinf

is jpegxl.info down for anyone else?

nvm just came back

unfortunate, but doesn't surprise me

seems that the default streaming mode (without i/o) up to e3 can be slightly worse or even better sometimes, but on slower efforts it's mostly worse, sometimes noticeably although it's very quick comparisons and need to recheck, maybe I'm using too old version for the test without streaming mode

yeah, I've noticed it that streaming is almost always better than non-streaming (when going up to e 9 on both), but I need to test on more images

about the conformance test, is it up to date? wondering about the conformance of implementation by the various tools implementing decoding and how they do it (ie integrating a current or old libjxl or imagemagick)

Speaking of implementations, I wonder about their performance, and their API (like support of progressive decoding and stuff)

ty!

anyone have an example image where lossless non-streaming produced smaller output than streaming (excluding e 10)?

most likely qoi_benchmark_suite.tar will have some such images, especially for e4-e8, I haven't checked, but it's happened on pretty similar images https://qoiformat.org/benchmark/

danke

When you say lossless non-streaming Do you mean 0.9 or something else?

0.10.x

just not putting --streaming_input/--streaming_output options in

So, how are you making it non-streaming?

Oh, right

It still streams internally

yeah but not to the same degree

Interesting

well, actually, I'm not sure--it could be there is no difference, and that's why my script is always showing streaming encodes, but it does the streaming encodes first, and only accepts a "new" encode if it's smaller

so they could, in fact, be tied

but so far I've yet to find a non-streaming encode that is smaller than all streaming encodes

``` -R K, --responsive=K Do the Squeeze transform, 0=false, 1=true (default: 1 if lossy, 0 if lossless)``` does squeeze still work on lossless input?

or does it break things?

yea, squeeze works for lossless. it doesn't really save any space though

basically the gist of squeeze is that it splits a channel into two channels of half-size. one of those is effectively a downscaled version of the channel

the other channel encodes the residual information that is lost by the downscale

when doing lossy, you can fudge the residuals (often by zeroing them) in a way that makes things more compressible

with lossless you have to encode the residuals as-is, which is possible, but it isn't really more efficient than encoding the image without squeeze

squeeze is reversible, provided you don't actually fudge the residuals

but, i meant true non-streaming mode, like with a build without streaming by default and just without i/o, I haven't really tested much, unless sometimes e1 can be a bit smaller, but for other efforts it's mostly the same

🤔 yeah, I don't think it's worth testing both, as even if there are those where non-streaming is smaller, they're few and far between

ah yeah, so except for e 10 (non-streaming), there's no difference in size

and e 10 (without streaming) is just too damn slow for me to use <:KekDog:805390049033191445>

Anyway I guess if --streaming_output is on by default as you say afed, how do you turn it off? Is recompiling really the only way?

perhaps the option should be renamed to `--disable_streaming_output`

for some content there is a pretty noticeable difference, sometimes for streaming, sometimes for non-streaming (like in older versions) though for fast presets this is compensated that they are faster with streaming, so it's possible to use a slower preset, but for single-threaded mode it might make some sense

i'm just using an older build

oh <:FeelsSadMan:808221433243107338>

but some option would be much more useful

well AFAICT, `--streaming_output` is on for all efforts *except* e 10 (and probably e 11 but I don't bother testing that), so the option is almost never useful

perhaps it would be better to use some setting for the buffer size or disable it completely (so it will be the old behavior)

https://github.com/libjxl/libjxl/issues/3291

--streaming_output is not on by default 😉

since the buffer size is already there (even if it doesn't work yet), it will be easier to change or disable streaming mode through the same option, also for cli ```jxl:2:d0:buf3 jxl:2:d0``` <https://github.com/libjxl/libjxl/pull/3265>

is there any changes between 0.10.1 and 0.9.2 that affect lossless besides streaming mode?

seems to be for pngimg in qoi_benchmark_suite, streaming mode is better for other sets almost the same or mostly slightly worse <:Thonk:805904896879493180>

and pngimg it's mostly pngs with alpha channel

```effort 1 187 File(s) 187 328 444 bytes effort 1 streaming 187 File(s) 189 384 379 bytes effort 2 187 File(s) 177 703 485 bytes effort 2 streaming 186 File(s) 164 084 623 bytes effort 3 187 File(s) 156 171 092 bytes effort 3 streaming 186 File(s) 148 686 341 bytes effort 4 187 File(s) 152 129 454 bytes effort 4 streaming 186 File(s) 144 612 669 bytes effort 5 187 File(s) 146 048 834 bytes effort 5 streaming 186 File(s) 139 771 137 bytes effort 6 187 File(s) 143 401 887 bytes effort 6 streaming 186 File(s) 137 678 715 bytes effort 7 187 File(s) 139 026 417 bytes effort 7 streaming 186 File(s) 134 263 517 bytes```

hmm, weird, some image for higher efforts doesn't seem to be encoded but, for some reason, it's fine just for effort 1

i'll try again, after some optimizers <:PepeHands:808829977608323112>

this png is not encoded for efforts other than 1 `libpng warning: iCCP: known incorrect sRGB profile` <:FeelsSadMan:808221433243107338>

would squeeze help with progressive decoding lossless images? or is modular already somewhat progressive?

yes. that is the primary reason you'd want to squeeze a lossless image

by default modular goes in raster order within the group

if you use squeeze, you get a downscaled version of the image as a channel

which can be upscaled and rendered, while the residuals are being decoded

then why wouldn't you use Squeeze by default then?

because it increases the size of the image

not by a lot, but by some

progressive rendering tends not to be particularly important when combined with lossless

usually the applications that want to render downscaled previews are the same ones that are likely going to be using lossy

at least, that's why it's off by default. you can always turn it on ofc

ig cause something like websites most likely aren't using Lossless for anything other than logos and stuff

yea, pretty much

and then logos are small enough anyways