JPEG XL

No idea how accurate that image is, also note that sRGB does not cover the full gamut of visible colors

https://artifacts.lucaversari.it/libjxl/libjxl/latest/ For a supposed "static" build, it seems like it's missing some DLLs.

See: https://discord.com/channels/794206087879852103/804324493420920833/1071129331448942767

<@179701849576833024> <@987371399867945100> VarDCT e3 (and libjxl-tiny) are still using ANS, not Huffman, right? How much trouble would it be to make them use Huffman and do entropy coding fjxl style? (sample some blocks to estimate a distribution, then do the main encoding in one pass instead of first tokenizing everything)

Eh, it would be some problem

to me it looks like a big code plumbing headache since basically everything is designed around "first tokenize everything, then compute histograms and context map, and only then spit out bitstream"

maybe an easier route is to make a "lossy fjxl" as a separate project, also to see if it is even worth doing in the first place (if compression sucks when not using ANS, it may not be something we should add to libjxl)

IIRC it loses 7-11% from Huffman

Likely all the symbols you'll need to entropy code in vardct fit within 16-bit (probably even in 12-bit or so when d > 0.5), so the huffman writer of fjxl could be used...

that's easy to try though

I would imagine the gap to shrink as quality goes up, since the benefit of being able to represent 0 in less than one bit gets smaller when 0 occurs less often...

https://github.com/libjxl/libjxl/blob/main/lib/jxl/enc_ans.cc#L1556 set this to true and try 😛

But then again fast lossy encode imo mostly makes sense at high quality, so you can later do a transcode at the actual quality you want. Doing e1 lossy d3 doesn't make that much sense to me...

That will still use exact histograms though - what I would propose is to avoid tokenization completely and use fixed or sampled histograms, which will have some additional cost besides the cost of huffman vs ans...

meh, that's not going to be a huge difference

in fjxl sampling 100% makes pretty much no difference wrt sampling 2%

Yeah but lossy might have more skewed histograms than lossless, or something

Anyway maybe it could also be interesting to try sampling histos when using ANS, and encoding backwards, to avoid two passes and the extra memory needed to tokenize everything

(just as a tangential FYI, CMOS overtook CCD 15 years ago)

Don't mind I'm late to the convo... You're not wrong there, however, human visual perception occurs at the brain, not the eyes. Notice "visual" here is an adjective, not the subject.

I should probably take some more photographs and test the performance of JXL in retaining detail in dark shadows, since it seems the encoder is currently surprisingly poor at that.

Maybe the image I posted is too obnoxiously large and it's too difficult for most people to concatenate the f ile

hopefully others can notice that this AVIF is retaining substantially more detail and texture in the shadows compared to the JXL. Every other part of the JXL looks visually lossless except for the shaded regions.

So it's not perceptually uniform quantization since some parts of the image look noticeably degraded compared to other parts that look transparent

djxl says -v gives more information with -h but -v is not accepted as an argument to djxl at all

also djxl -h does not say what argument to use if you do not want to write an output file

perhaps one way to approach this would be: for each wavelength λ, take XYZ = (x̄(λ), ỹ(λ), z̄(λ)) (https://en.wikipedia.org/wiki/CIE_1931_color_space#Color_matching_functions), and gamut-map that to your monitor’s colorspace

This seems like a bug, for djxl there are not that many options and all are displayed with `-h`, and `-v` does not work as you pointed out. Let me fix that...

Removing two characters should fix it: https://github.com/libjxl/libjxl/pull/2181

It would also be a good idea to remove the misleading help message encouraging the use of a flag that doesn't exist

looks like it was already removed...

actually no it wasn't...

Just a follow up on the picture I took... I encoded a HEIC version and a JXL -q 85 version. Even at such a high quality setting, JXL noticeably destroys the texture of the shaded regions in the image compared to other codecs such as AVIF and HEIC.

It's unexpected because even since JPEG-XR, codecs started to focus on retaining detail in dark areas and getting a lot better at that.

Maybe next I'll have to compare JXL to JXR ;(

it very depends on the display settings, also maybe `--intensity_target=` will help

No idea how to use that setting...

I know it takes an integer but I don't know what the scale is.

Hmm, seems to be measured in nits.

Well I still don't know what the scale of that is.

forgive my ignorance.

`Upper bound on the intensity level present in the image in nits. Leaving this set to its default of 0 lets libjxl choose a sensible default value based on the color encoding.` the default is 300 or 400, maybe trying to raise it to like 600-1000 and compare or maybe even more, just for the experiments

If that doesn't help, then just increase the quality, because quality for jxl is still optimized for distance and if comparing from a closer distance, the difference is likely to be noticeable

The default is 80, no? Quite low iirc

Could you share the original image?

Wow I cannot find any software for reading or writing JXR

Yes, I shared the original image earlier, it's large so I truncated it into 2 parts so you can restore it by concatenation

https://discord.com/channels/794206087879852103/804324493420920833/1071730694147035216

Ah ok thanks. No time to look at it now, but it would be worth looking into, it's weird if you're saying jxl is destroying darks while avif/heic work well, that's the opposite of what should happen

<@532010383041363969> also might want to take a look

probably, I just remember how it is typically used in libaom for `--tune=butteraugli`

Well I posted an AVIF version as well as a HEIC encode. Sorry the file is so obnoxiously large.

But you can clearly see that JXL is by far the worst at retaining texture in the shaded area.

Maybe something changed recently

with libjxl's tuning

It is basically how bright your display goes. 'Officially', sRGB assumes a display where the brightest white is 80 nits. Current displays tend to go significantly brighter than the displays of the 1990s for which sRGB was designed. E.g. my laptop goes to 400 nits, and HDR screens can go to 1000 nits or more. Since everything gets scaled to the display brightness, artifacts in the darks will become a lot more visible on a brighter display than on a dim one.

Makes sense to me. So it sounds like a sensible scale would be near the range of 400-1000, give or take.

It all depends on the expected viewing conditions and the intended meaning of the image. If you set the intensity target to 1000, it will also make the brights very bright on an HDR screen, so that's probably not what you want to do.

lol I have to convert JXR to BMP in order to even view it...

But anyways luckily JXL is not worse than JXR

That would be pretty embarrassing

Really, that option will change the perceived brightness of the image as well as change the psymodel?

I tried intensity_target 400 and it significantly increased the filesize

It also significantly reduced the blurry awfulness.

Even setting it to 500 and adjusting the distance to match the same bitrate again, heic still looks less blurry.

I think it just needs better RDO and noise masking heuristics.

<@604964375924834314> can explain better but afaik yes, it defines how bright white is supposed to be, which will affect both how it is supposed to be displayed and how things are compressed. But for "non HDR" values, I think it doesn't really change how the image gets displayed, since SDR screens don't have a defined brightness anyway.

It just, for some reason, is treating the whole image really good except for my shadow. It's encoding the rest of the image at d1.45 but it's encoding my shadow at -d 3 or something.

It's discriminating and treating my shadow different than the rest of the image :(

right, the intensity target is the peak luminance of the image (which for an SDR image is the luminance (1, 1, 1)), with the default for SDR images being 255

when displaying a JXL image “as SDR”, that luminance range is mapped back to 0-1, so it has no impact on the brightness of the SDR output

but using a higher intensity target for an SDR image encodes it as a brighter image for HDR displays

Well, Windows can read and write it natively using the Photos app on Windows 11. And yes, that's because Microsoft made the format.

If you aren't on windows it's basically impossible to find any image viewers that support it.

I downloaded jxrlib, it seems to be some java thingy?

No, it's not java, it's just weird

Like the binary name has WeirdCamelCaseCapitalization for some reason

I think that’s a common .NET convention

for some reason, `eog` does not display that image. I can convert it with imagemagick though, no idea why eog is complaining

hmm, gwenview seems to work fine for me on my weird system. I might have mozjpeg installed...

It probably has to do with arithmetic coding.

Some JPEG viewers have a hard time with that.

ah lol yes, pretty much most of them

I don't consider arithmetic coding to be part of the de-facto jpeg format — like 12-bit, lossless, hierarchical and all the other stuff that's in the original spec but is not implemented in the widely deployed decoders

so that's the shadow you're talking about, in the original image?

and this is the decoded jxl

ugh why am I still using this imagemagick that creates buggy png files

this is the actual original image at that location

ok so yes, the q85 jxl does smooth things a little in those very dark areas

When viewing at 2x zoom I can see it quite clearly, though I wouldn't particularly say it's a very problematic amount of smoothing. Viewing at 1:1, it's not that obvious, and q85 isn't supposed to be fully visually lossless, it's a somewhat lower quality than that.

correcto. Also apparently libvips blows both imagemagick and graphicsmagick out of the water I hear.

I understand but compared to other codecs (hevc and av1) jxl is performing poorly here relatively speaking, also it seems like the quality in that shaded region is noticeably worse than the rest of the image.

it could be that there is some generation loss aspect at play here too. you're starting from a q95 jpeg or so, which is quite good quality but it's not pristine. avif/hevc stay in the same colorspace (8-bit ycbcr) while jxl uses a different one, which can make a difference

I am sure that it will only get more noticeable when the image is viewed with a brighter monitor. Or by an image viewer that applies post processing. Or by a "gaming" monitor that brightens shadows.

It might look subtle, but I think that it's not a good sign if JXL is too eager to smooth and blur details away just because it's at a darker part of the image. The more crisp and detailed the shadows look, the more images tend to appear to "pop" out. So it's very bad for fidelity for an encoder to give shadows not enough weight.

Not only that, but the type of artifacts here are also troubling.

q85 is well within the range where libjxl is normally very strong and competitive. But the type of artifacts it's showing here, compared to the other codecs, looks almost like 2x2 subsampling.

It looks very crude instead of trying to use any clever psychovisual tricks to mask the distortion.

I'm not anything like an image coding expert, but I believe, in the expressive bitstream, there are different ways the image data can be quantized and rounded to increase compression, different ways that produce different types of artifacts, sometimes noise, sometimes blurring, sometimes this weird 2x2 effect...

yeah this is a matter of encoder heuristics, it is assuming it can be more lossy there since you wouldn't notice, but I guess it's kind of wrong there 🙂

x264 and x265 have a lot of very clever masking tricks that add extra distortion for the sake of preserving detail and texture.

Because noise often helps preserve detail since our brain is pretty good at removing it.

possibly gaborish is responsible for some of this smoothing, have you tried with gaborish=0?

No, but I'll give it a shot.

The file is noticeably smaller and noticeably better quality too.

Not quite the level of the heic though but I will give it a shot at the same bitrate

turning off gaborish made a shockingly huge improvement to this photograph.

It's still pretty subtle. And I think gaborish isn't the main problem because allocating more bits for the shadows will improve things more with gaborish on or off.

But still, maybe the heuristics for when to enable gaborish should be re-evaluated...

Even after turning gaborish off and matching the bitrate (d=1.3), it certainly looks a lot better but heic still has a leg up.

But it definitely closed most of the gap.

"yes" is not much of a heuristic 😛

(well, "yes if not trying to be super fast" but still)

are there some improvements to the help messages of cjxl and djxl left todo?

cjxl and djxl both use the same function to print the help message.

And so djxl also says "try using -v with -h" even though that doesn't apply to djxl

It checks the verbosity level before printing the suggestion

Who are these assholes charging $30 for a scientific journal published in 2000?

Sorry, kind of an offtopic question. Just kind of amazed how 23 year old research papers are being so fiercely guarded by numbskulls trying to make a buck.

I wonder what the reason is, that research papers are always behind paywalls with $30 PDF download buttons, instead of being freely distributed to all curious minds...

It doesn't really seem to be in the spirit of science at all...

That problem was fixed yesterday, at the current head it should be ```[I] firsching@bernoulli ~/libjxl ((6280645e…))> ./build/tools/djxl -h JPEG XL decoder v0.9.0 6280645e [AVX3,AVX2,SSE4,SSSE3,Unknown] Usage: ./build/tools/djxl INPUT OUTPUT [OPTIONS...] INPUT The compressed input file. OUTPUT The output can be (A)PNG with ICC, JPG, or PPM/PFM. -V, --version Print version number and exit. [...] --quiet Silence output (except for errors). -h, --help Prints this help message. ``` Thanks for reporting it

Ah neat. Glad I could help.

I have come across articles that _used_ to be freely accessible and are now paywalled… 🤦 🙄

archive.org to the rescue (no need for sci-hub in this case)

Academic publishers are the worst leeches in society, taking typically publicly funded research, written and edited by researchers, and then putting it behind a paywall so they get to charge a lot of (mostly public) money for basically hosting a website that for some reason is "prestigious".

If scientists are so smart why don't they create a free way to distribute their papers? :P

All problems can be solved with science!

I feel like Cave Johnson saying that lol.

We do what we must, because we can

why they would be smart about everything at once?

Humans never are.

taking upon everything is not a smart thing to do

question of the time and resources

Certainly. Such lowly mortals cannot be trusted.

individually, yes

some corners of academy aint that bad, like cryptography (they tend to use public journals like iacr's ePrint)

openbsd guys are pretty nice :)

So I just switched over to waterfox on one of my computers. Good riddance firefox.

TBF the ArXiv is sort of that for some fields.

Here is another example of what I was talking about earlier. How the quality and the characteristic compression artifacts and smearing are radically different in different regions of the same image compressed at a single quality level.

I was looking at this and decided to do some testing of my own. https://forum.vivaldi.net/topic/61006/support-for-jxl-image-format?lang=en-US

Here's the original.

I tried to experiment with how far I could compress the image before I start noticing something wrong with the image.

I used photon_noise_ISO800 to approximate the noise level of the original image. I got this number by pulling it out of thin air.

Here it is at d3.

Problem is, the quality varies a lot throughout the same image at the same quality setting. Darker areas are punished a lot more than brighter areas.

d3 is the lowest I tested but even at higher settings, darker areas always get hit first and the level of quality varies a lot depending on the brightness.

It's not perceptually uniform and it's a pretty extreme difference.

I think that if people were to mass-compress a whole bunch of images at any lossy quality setting, whether it be d1 or d2 or d3, they will not get consistent results if some images contain darker content.

Some images it will be impossible to notice any artifacts and will look totally transparent and other images will be noticeably altered. Maybe not for d1 since d1 tends to be extremely conservative, but definitely for anything less than d1. And this also means that d1 could be made more efficient too, since it's probably wasting more bits than it needs to on bright high contrast areas.

It's been quite a while since I've been involved, but I'm back for a few moments.

Yes, I'm trying to update libjxl in Squoosh. Again.

``` wasm-ld: error: duplicate symbol: skcms_DisableRuntimeCPUDetection >>> defined in node_modules/jxl/build/mt/lib/libjxl.a(skcms.cc.o) >>> defined in node_modules/jxl/build/mt/third_party/libskcms.a(skcms.cc.o) wasm-ld: error: duplicate symbol: powf_ >>> defined in node_modules/jxl/build/mt/lib/libjxl.a(skcms.cc.o) >>> defined in node_modules/jxl/build/mt/third_party/libskcms.a(skcms.cc.o) wasm-ld: error: duplicate symbol: skcms_TransferFunction_isSRGBish >>> defined in node_modules/jxl/build/mt/lib/libjxl.a(skcms.cc.o) >>> defined in node_modules/jxl/build/mt/third_party/libskcms.a(skcms.cc.o) wasm-ld: error: duplicate symbol: skcms_TransferFunction_isPQish >>> defined in node_modules/jxl/build/mt/lib/libjxl.a(skcms.cc.o) >>> defined in node_modules/jxl/build/mt/third_party/libskcms.a(skcms.cc.o) wasm-ld: error: duplicate symbol: skcms_TransferFunction_isHLGish >>> defined in node_modules/jxl/build/mt/lib/libjxl.a(skcms.cc.o) >>> defined in node_modules/jxl/build/mt/third_party/libskcms.a(skcms.cc.o) wasm-ld: error: duplicate symbol: skcms_TransferFunction_makeScaledHLGish >>> defined in node_modules/jxl/build/mt/lib/libjxl.a(skcms.cc.o) >>> defined in node_modules/jxl/build/mt/third_party/libskcms.a(skcms.cc.o) wasm-ld: error: duplicate symbol: skcms_ParseWithA2BPriority >>> defined in node_modules/jxl/build/mt/lib/libjxl.a(skcms.cc.o) >>> defined in node_modules/jxl/build/mt/third_party/libskcms.a(skcms.cc.o) ```

``` em++: error: '/emsdk/upstream/bin/wasm-ld -o dec/jxl_dec.wasm /tmp/emscripten_temp_yont4_9_/jxl_dec_0.o node_modules/jxl/build/mt/lib/libjxl.a node_modules/jxl/build/mt/third_party/brotli/libbrotlidec-static.a node_modules/jxl/build/mt/third_party/brotli/libbrotlienc-static.a node_modules/jxl/build/mt/third_party/brotli/libbrotlicommon-static.a node_modules/jxl/build/mt/third_party/libskcms.a node_modules/jxl/build/mt/third_party/highway/libhwy.a -L/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto --whole-archive /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libembind-rtti.a --no-whole-archive /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libgl.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libal.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libhtml5.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libc.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libcompiler_rt.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libc++-noexcept.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libc++abi-noexcept.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libdlmalloc.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libc_rt_wasm.a /emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/lto/libsockets.a -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --allow-undefined --strip-debug --export main --export stackSave --export stackRestore --export stackAlloc --export __wasm_call_ctors --export __errno_location --export malloc --export free --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-table -z stack-size=5242880 --initial-memory=16777216 --no-entry --max-memory=2147483648 --global-base=1024' failed (returned 1) make: *** [Makefile:39: dec/jxl_dec.js] Error 1 ```

<@281115117884801025> IIRC you've been messing with that stuff

https://github.com/ziemek99/squoosh/tree/jxl-081

<@1028567873007927297> it's a piecewise function

unfortunately discontinuous

lemme find where it is in the cjxl code

ah nvm they found it

here it is plotted

wrong channel though 😄 the question was raised in <#794206170445119489>

yes, but accompanied with the comment “oh, meant to ask this in the <#804324493420920833> channel.”

I thought Iit was adapted to be continous, even C_1, https://github.com/libjxl/libjxl/pull/1824

I didn't remember that being fixed, excellent

logscale butteraugli, grid

I don't really see use cases for q<50 tbh, so the shape below q30 doesn't matter that much imo. For "web quality", q60-90 is the relevant range. For "camera quality", q90-97 is the relevant range.

maybe if you want to have images at 1:1 on dpr3 phones (as opposed to just sending them a 2x image and calling it a day), lower qualities might be relevant for the web... though it's a weird mix of priorities to me if you want to simultaneously send a high-res image to such phones (which I presume is because you care about image fidelity) and then use a low quality (which I presume is because you care about bandwidth/webperf).

Realistically, based on my experience (which might be limited and not representative since most of that is based on what Cloudinary customers want/do), I think about 40% of the web use cases use a 'good but not perfect' quality around jxl q80, then about 30% of the web use cases are more bandwidth-conscious (typically media/social media) and use a quality around jxl q72, then about 20% of the web use cases (typically e-commerce, especially luxury brands) are more fidelity-conscious and use a quality around jxl q90, and then about 10% of the web use cases are ok with serious fidelity sacrifices and go down to about jxl q65, or even lower on some important images if they can manually check that they still look somewhat acceptable.

so if I would do a benchmark to compare codecs from the point of view of the web, I would check performance at those fidelity points and weigh the results accordingly (i.e. most weight going to the q70-90 range)

Hmm, it does indeed look discontinuous and what's more, I think ffmpeg has their own, separate algebra for it.

I guess it doesn't REALLY matter if it's discontinuous or not

neither is a discontinuous function tho?

Hi! Could someone please point me to some guide on how to use the pre-build dll's in my Visual Studio 22 project? I believe I should build some library to be able to link to them, but I have no clue on where to start

Well, the graph looks linear at higher q-levels and nonlinear at around 30

I got no idea what ffmpeg is doing but they have their own independent formula for converting q to d

correct

Just wanted to add, this image is another good example of how libjxl is not achieving perceptually-uniform quantization. If you save this image at d=1 or higher, you will notice that the grain present in the dark sky, gets blurred/smeared with blocky DCT artifacts very soon before anything else in the image suffers. Whereas even if you lower the quality to extremely low settings, the level of detail of the city and buildings and streets and people, basically everything except for the sky, is retained nearly transparent even at EXTREMELY low quality settings.

Maybe it has something to do with this being taken at night? Maybe it is a color profile thing?

This image was originally a high-quality JPEG

If you decompress the image and recompress at lower quality settings you will notice easily that the quality of the sky is not perceptually uniform with the quality of the rest of the image and the quality of the rest of the image remains nearly transparent even at absurdly low quality settings

Please see for yourself if you think you might know why this might be happening.

Have you tried decoding to 16-bit and displaying with a viewer that does proper dithering (e.g. MacOS Preview does it right)?

8-bit without dithering can be a bit blocky/bandy, especially in the darks

I do not use Mac OS anymore.

I have not tried decoding to a 16 bit PNG or anything like that, but shouldn't libjxl dither if decoding to an 8 bit buffer?

If not, that sounds like something that can be fixed in libjxl

djxl default for PNG is 8-bit as well. Flattening away details by not dithering when decoding to 8-bit is an oversight in the decoder

...Still, I just tested decoding to a 16 bit PNG just now, and the difference is pretty subtle and doesn't really add any depth or detail or texture that was not there before.

Still there is an incongruity between the quality of the sky and the quality of the rest of the image.

When I open the image in viewers with poor color profile support, the image looks a lot darker than normal, too. So maybe that has something to do with why the sky is over-quantized.

In sum, I tried just now and it makes no difference. The sky quickly becomes blocky and flattened while the rest of the image retains transparency at absurdly high distance settings

Is there already an issue about this on github? If not, then could you open one?

Sometimes I think maybe I'm crazy picking at pixels like this.

I would if I had a github account... I might create one later...

No, that's exactly how bugs are found! Xiph.org team responsible for Opus Codec couldn't stress enough that any "killer samples" from HydrogenAudio forum are appreciated.

BTW plz anyone help me with Squoosh build ;_;

well well... I have no idea how to help, but i'll fork your depot and try ...

I think opus development has been abandoned, and harpsichord is still an opus-killer.

which is a shame because I love harpsichord

There's always Vorbis, I guess...?

Most of the stuff (features, stability etc.) is already here. Remember that Opus is over 10 years old, it had its time to mature.

`benchmark_xl` can sometimes fail when built with `-D_GLIBCXX_ASSERTIONS`, as Arch does by default.

The weird thing is, it doesn't fail *all* the time, but only sometimes, at some qualities. I don't know if I can replicate this consistently with other images.

Okay, nevermind, I can pretty easily replicate it with the JPEG XL image from the JPEG website. I'll open a GitHub issue later when I have the time.

i wanted to have some fun and see if i could compile cjpeg with jpegli, i *almost* got there after a bit of tweaking and some very hacky patches for the missing symbols (jpeg\_write\_marker, jpeg\_float\_quality\_scaling, and some jpeg\_c\_\* symbols)

If it hasn't gotten any updates during that time then it's not exactly maturing...

<@532010383041363969> Here's an example file that exhibits some compression artifacts. Under vertical features there can appear a visible "dot" (lighter or darker). jpegli with distance 3 under the second leg of the "h" in "Irish", and a darkish line under the "r" in "Irish" jpegli with distance 4 there are light spots under the "h" in "Irish" and also under the "i" in English.

(dunno if discord recompresses these files...)

discord doesn't recompress stuff they only remove metadata

Yeah, if I zoom in the artifacts are still visible in the 2nd and 3rd image.

although the thumbnails of images in discord are separate so you sometimes need to open the image to get the actual thing instead of a generated thumbnail

I consider low 'web quality' starts at q70 -- the use of q60 is a below web quality that occasionally but rarely occurs in the web

I see these problems -- I'll discuss about a mitigation with Zoltan -- did you see similar problems if the background is gray or does it mostly occur on reddish backgrounds (perhaps also on greenish)

I've only noticed it on this image, but I haven't looked very closely at other backgrounds. This particular image has been an excellent test for evaluating various compressors and their quality settings, since these color combinations and thin features make artefacts show up very well.

When I found similar artefacts with the AVIF compressor it was black/red text on a light brown-grayish background.

> though it's a weird mix of priorities to me if you want to simultaneously send a high-res image to such phones (which I presume is because you care about image fidelity) and then use a low quality (which I presume is because you care about bandwidth/webperf) Yep, that’s exactly what I do. Extra details are worth it. Ideally, there wouldn’t be any, but they are worth some artifacting to me. I never go beyond dpr2, though. This always seemed to me convincing (but I trust my eyes too): https://observablehq.com/@eeeps/visual-acuity-and-device-pixel-ratio#cell-220

So, hypothetically, if there would an encoder which decides for me to lower the resolution when I ask for lower quality, such an encoder would be entirely useless to me.

Mozjpeg q60 still gets used on the web in my experience. Even down to q50 in some cases. But only when the image content allows it (in particular, no non-photo) and when there is no brand reputation involved.

FWIW, 85 for dpr1 and, ekhm, 45 for dpr2 (effective from, IIRC, dpr>1.3) here. And yes, it results in quite noticeable artifacting on minority of images (posterisation in large area+subtle gradients)

I've seen a Cloudinary competitor use q30, but I dunno if they were successful with that. Sure, they beat us in filesizes, but other than that...

q40 can be ok for dpr2 but only for 80-90% of the images. 1 in 20 images will look quite bad.

Both images look pretty impractically poor.

In particular the color.

The shape of the flower is destroyed. The hue of the top right text is destroyed.

In one of them the entire color of the sign itself is different.

I wonder if encoding at a higher bitrate would make a difference

I don't see significant q50-q60 in my data analysis, less than 2 %

[slightly facetious comment, but only slightly] Maybe that’s because not many sites care about image quality providing separate high DPR-specific imagery? 😜

I have repeated such analysis by manually surfing using an 8k monitor and a 4k monitor as well as done more thorough data analysis about images, I have tried to repeat the analysis during the development trajectory -- so I did it about every two years since 2014

of course initially I didn't have 4k/8k monitors 😛

there is one major site that I was able to find that has really low quality images, down to webp q45 (which is likely like jpeg q40), but I just absolutely don't like how their images look and I consider them ill-advised so I just ignore that site in manual analysis

automated analysis looks at many images and is consistent with manual analysis

last round of analysis I asked a colleague to do and it produced similar results with my previous approaches

I would assume that most of the ones that go to quite low qualities, would typically not be using jpeg but rather webp or avif.

The median avif is 1 bpp, the median jpeg is 2 bpp. But to get the same quality as 2 bpp jpeg, you would need 1.7 bpp avif or so. So basically the median avif user is using a lower fidelity target than the median jpeg user.

making your browser lie 'no webp, no avif' could then lead to better image quality? :----D

It is like early digital television looked worse than the last phases of analog television. Making things worse by busy-busy engineering a lot is something that I don't want to spend my life doing... I love to improve things 🙂

also, we were able to afford good looking images with old JPEG

then we made things more affordable by improving compression

as a result of making things more affordable, we no longer can afford to have good looking images

it is like if the Swiss would have found an even better and cheaper recipe for chocolate, and once it is offered to the world, everyone would just eat mud instead of chocolate -- commonly decided 😛

ideas/votes on what should be next after jpegli: opusli, avifli, x264li, av1li, av2li, weppeli, something else?

bmpli

jxlli <:PauseChamp:755852977574510632>

opusli 🙂

pngli :P

or gifli

for png has already been done enough and if combine all these efforts, it's basically pngli (from the jxl team): <https://github.com/google/zopfli> <https://github.com/veluca93/fpnge> <https://github.com/lvandeve/lodepng> and the best thing that can be done for the gif is not using it at all, in my opinion improving gif is just making things worse to see how x264 could be improved from a different perspective would be interesting because avc is still a sort of jpeg for video and x264 is an encoder which got a lot of improvements staying within the same format and compatibility but i doubt there's much room for improvement (maybe something for high fidelity) but, opus and x264 in the later development years are rather a lot of manual fine-tunings than new methods it will be very difficult to re-tune it with much better results, unless there will be some revolutionary ideas and much more efficient methods

(fwiw, lodepng predates the jxl team)

yeah, i meant the same people who were also involved in jxl

It could be interesting to have better intra in jxl (e.g. using cropping, patches and blend modes, which are currently not used at all for multi-frame purposes) and see if we can improve the state of the art for digital cinema and video archival use cases — i.e. lossless or very high fidelity lossy, where the usual video codecs are not very effective and currently things like intra-only j2k and ffv1 are what they use.

So mjxli?

and avifli might be also interesting, but prioritizing avif improvements over jxl would be somewhat strange and maybe then it would be better to be involved in the avif2 development at earlier stages, so that it would be better as a format from the beginning?

(doing that re avif2)

the AV1 entropy coder is... slightly embarassing... for images

(I will deny ever saying this if somebody tries to quote me xD)

it's not designed for still images, it's supposedly designed for hw encode/decode of video (i.e. mostly low amplitude symbols)

yeah, clearly xD

(in case you are wondering, NUM_BASE_LEVELS is ... 3)

last build <:Thonk:805904896879493180>

hmm. the build that is made here https://artifacts.lucaversari.it/libjxl/libjxl/2023-02-22T14%3A22%3A27Z_5b530446dc8ed8db0d3586986d15e18986c8793c / 1 minute ago works fine

maybe I have some problems with the MSYS2 build

h.264 stuff could be made better if you could reencode baseline videos into high videos to benefit from the improved entropy coder.

oh yea, cabac is much better than cavlc

and you could in theory do that without dequanting

Yes. The only concern would be decoders on older devices, but it doesn't matter too much since you could design a tool that does the inverse.

decoders on older devices should still be able to handle High profile

unless they're hardware decoders, but High profile is c. 2004

and Main is 2003

there should be very few hardware decoders that can't handle the High profile

yeah, but it's more like optimizers, I even heard that there are commercial compressors that can reduce h264 bitstream by 20-30% losslessly, it will be a different, incompatible format, but still playable but I was talking about encoder improvements

like `-tune butteraugli` for x264/x265

but, just adding more complex metrics is only a small part, without proper manual tuning and lots of visual comparisons it may work worse than simple metrics and methods that the encoder is already well tuned for

ah, or maybe -tune ssimulacra2 or something?

yeah, but from what I hear from some experiments with the av1 encoder, ssimulacra2 is much slower (but maybe not with the same optimizations) and butteraugli is easier to use as a metric for encoding in a specific quality

Let me clarify: both metrics are too slow for direct use in a video encoder pipeline, and need a lot of internal tweaks to make them viable(more so butteraugli than ssimu2 since ssimu2 is just faster, but since no encoder currently uses ssimu2, it's a moot point).

slow according to who

not slow for me

<:monkaMega:809252622900789269>

considering how long butteraugli has been around, I think the x264 developers would have *screwed *it to the encoder long ago. yes, just for fun. But I haven't heard about it. as I understand it, this is a technical implementation problem.

there is no technical problem here, but it will require a lot of effort to retune the encoder for that metric, as I said, just adding a new metric is only a small part, most likely the quality will be even worse x265 also has some experimental modes with higher use of metrics, but since these modes are not as tuned as the old ones, they are very unstable in quality and rarely used and x264 has had no real progress for almost like 10 years now (since Dark Shikari stopped being active), just some bug fixes and minor improvements

Butteraugli is more that a decade younger that x264. You can not tune for a metric that does not yet exists.

I don't think this is a metric problem.

Not in the subject at all. But I remember how windows XP could not open files on an android smartphone. Because there were no built-in drivers. I think there is a direct analogy here. In order for the new metric to work, it is necessary to strongly add the encoder code.

I generally understand this. I also realized that metrics can't be done just once and done. Although in the case of butteraugli on av1 it looks like this... it was just added in minor version 3.1.0 as if there were no problems in this.

Where can I follow the latest developments of the new JPEG encoder? :)

Hi! I've just integrated libjxl into my game that needs to work with hundreds of thousands of images. Before I was using webp and JXL definitely shows the substantial improvement in compression rate and the quality. But looks like something is wrong with decoding speed. It is something like 3-5 times slower than webp decoding. I use default parameters for lossy encoding, except for Quality settings that I set to 3.0 (works fine on my specific data - visually perfect). The images are 512x256 px in size, with alpha. Where should I look to check what is going wrong with the decoding speed?

as far as I know, with lossy+alpha, it is likely that alpha takes up most of the decoding time, so perhaps this would be what to look into speeding up

but I’m afraid that my wisdom pretty much stops here

maybe subsampled alpha if that’s a practical option?

in general encoding with --faster-decoding might help

alpha decoding might also be faster when not using lossy alpha (which uses squeeze) and when encoding for specialized decode paths (e.g. `-D 0 -e 2` could help, maybe)

squeeze is a naive unoptimized implementation with no simd right?

I did try to optimize it, it does have some simd

in my experience, at least on the decode benchmark web page, faster-decoding doesn't really make much difference.

not sure how much room for improvement there is — probably faster paths are possible for bitdepths below 14-bit or so

best way to benchmark decode speed is `djxl --num_reps=30 --num_threads=[whatever you want to test]`

Also for some reason these timings seem absolutely absurdly low

because when I use djxl I get 100 MP/s

I was just about to mention that lol

why is this browser test reporting such ridiculously slow speeds?

I'm using waterfox...

the browser test includes whatever overhead the integration code has, I suppose. Also that benchmark might be too harsh on the browser scheduling, since it basically starts 100 decodes at the same time and counts the time until they're all done

Thanks! In terms of libjxl, how this should look like? Should I set some fields in JxlEncoderFrameSettings?

BTW on my images it looks like the lib does not benefit from multiple cores, as the images are too small - they are 512x256. Maybe it is possible to launch JxlDecoderSetParallelRunner that can handle several frames instead?

`JxlEncoderSetExtraChannelDistance(settings, /*index of alpha channel*/ 0, /*distance setting for this channel*/ 0)`

I don't think we already have a way to encode multiple frames in parallel, but I might be wrong

Thanks, will try! Is the decoder itself thread-safe? Can I safely run several decoders in parallel?

yep

well

you can create multiple decoder objects, but you can't use a single decoder object from multiple threads

Several decoder objects will work just fine. The examples however suppose creating ParallelRunner for the decoder - is there a way not to use the ParallelRunner, but run the decoder in a single thread?

just pass it `nullptr`

for relatively small images it should even be a bit faster

Ok, thanks!

(also recycling decoders *might* help)

Good idea, as I always have a stream of images to decode, so pre-allocating several decoders for the lifetime of the game makes sense. To re-use a decoder , should I somehow reset it?

I think there is a way to do so

but maybe there isn't xD

Will check

The images are all of the same size and encoding, so should be relatively simple to reset

`JxlDecoderReset()` is part of the API

Thanks!

JxlEncoderSetExtraChannelDistance - is it from 0.8.1 ? I use 0.8.0 from vcpkg build and there is no such func 😦

It's not even in 0.8.1 I think, only in current git head. It's a recent addition to the encode api...

Well now I have a whole collection of pictures (album covers) which have disgusting and unacceptable JPEG XL artifacts in high compression quality original | d1 | d 2

original for <@532010383041363969>

All artifacts, apparently, have the same principle of origin, as I think it's all connected with what I've talked about a lot before. The passage of the artifact through the blocks https://discord.com/channels/794206087879852103/794206170445119489/1074362924484788306

this is fantastic work DZgas, thank you so much

I'll study these with care

I feel -tune butteraugli would be great for x264, possibly give another 25 % there -- I don't want to improve x265 since it is covered with gloomy IP 👻 -- I don't want to explore the possibility if SSIMULACRA2 can be used for guiding quality since it wasn't developed for that purpose and in butteraugli I had to make 10 rounds of tuning to make it suitable for guiding quality decisions, I'm guessing SSIMULACRA2 would likely need similar incremental improvements (which often make it slightly worse for measuring quality itself)

could you also describe the errors that you find most irritating in each image? (of course I see that there are severe problems, but it would be nice if we can agree which should be improved)

I see these...but in fact, it will be much more efficient to use the e 3 parameter to **see **which artifacts are not there.

it all refers to the fact that inside a block that does not have such a color, such color appears from neighboring blocks, and spreads over the entire area

it is interesting that there shouldn't be much interest for the codec to put red pixels in the upper left hand corner, but it does it anyways -- this is the V-channel for that image, it should be more green than red there

it will be a lot of fun to debug this

would this be better at d2 ?

I found the broken algorithm -- it is in 'chroma from luma'

dzgas providing color samples doing very well

both the fast and the slow version are broken in similar ways, I'll need to rework them...

It is so great to have a caring community so that we can get all details right

persistent and caring 😄

especially noticeable for red, even for photographic images, like I showed some example here https://discord.com/channels/794206087879852103/848189884614705192/1069777174170714152

surprisingly this also applies to jpegli, but to a different extent, where the red tones have a noticeable blockiness or perhaps because human eyes are more sensitive to it

We will pay more attention to jpegli artefacts end of March, we are still figuring basic things there

How broken is it? Fixing this might result in a nice encoder improvement...

I have some difficulties to assess the level of irony on this one 😄

I don't think there was any irony/sarcasm in that statement.

I just hope that encoder improvements never are declared "done" like what happened to libopus after opus achieved success

lossy compression is never "done"

I moved link to benchmarks

libjpeg is still getting huge quality improvements all these years later, with mozjpeg and now jpegli

even though jpeg already achieved its success

🙏

will wait <:JXL:805850130203934781> rework

For images that have an exotic color profile, shouldn't libjxl transparently perform color profile conversion before LOSSY compression? for lossy, there is really no reason to keep the original color profile.

It would completely screw up all of the psychovisual model's assumptions

It does that.

Does it? Hmm...

yes, it converts whatever color space the input is in to XYB. When doing lossy, the color profile / color space enum is just metadata so a decoder knows what space it comes from (so it could be a good idea to convert the decoded image back to that space), but it doesn't influence the actual interpretation of the image data, which is always in XYB when using lossy.

the advantage of this approach is also that a viewer application can do color management without having to do a potentially different and expensive transform for every image. XYB to display space is the only transform that is needed for viewing, regardless of what the original color spaces were.

For lossless and for cmyk, viewers still need to do arbitrary color management, but that's kind of inevitable. But for lossy, in particular for typical web delivery, I think it's nice that there's this 'automatic normalization' which could in principle help a little to speed up color management since you can directly decode to display space regardless of what the display space is.

something that does bother me is that libjxl always performs clip-tone-mapping

I didn't attempt to put irony/sarcasm there. I just love to get feedback from actual users and work towards better solutions for all.

I suppose "relative" rendering intent implies clip tone mapping

it is in cfl, so no one actually understands how to get it right -- my best attempt is to remove the system altogether which reduces numbers by ~1 % -- I still have some hopes of finding something slightly better than removing it, but this one feels more complicated than anything else in jpeg xl and I'll probably need to keep trying for two weeks or so

consider the following JXL:

my monitor is sRGB, as far as I'm aware. (It's not wide-gamut)

if you request sRGB from libjxl when decoding this image, you get the following:

https://0x0.st/Hzmy.png

It's noticeably darker than the PQ image when viewed from chromium or mpv

I suppose it isn't actually doing clipping but just scaling everything down so the brightest white becomes SDR white? <@604964375924834314> understands this stuff better than me

this is the same thing that jxlatte does when you request SDR btw, it just takes the XYB and uses the default opsin matrix to convert it to linear sRGB, and then applies the forward sRGB transfer function

and afterward it clamps to `[0, 1]`

I wonder if this is an issue with the intensity target?

Seems like it is worth documenting the observed (mis)behaviour in an issue

It don't think it's technically "incorrect" behavior but it is undesirable

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

The problem with sRGB is that it only defines primary colors / white point / transfer function, but not how bright #FFFFFF is supposed to be. So there isn't really any "correct" way to translate HDR images to SDR spaces like sRGB. But I do think we should aim to produce something nice-looking 🙂

yea, it is display-referred, but it should still have a sane-default IMO

at least for the default Intensity Target, which is 255

well, it appears to be tonemapping it to some subset of the 0-65535 range

Identify -verbose reports these channel statistics

``` Channel statistics: Pixels: 8294400 Red: min: 0 (0) max: 32740 (0.49958) mean: 6524.4 (0.099556) median: 5916 (0.0902724) standard deviation: 5019.01 (0.0765851) kurtosis: 0.54006 skewness: 0.894579 entropy: 0.946897 Green: min: 0 (0) max: 30019 (0.458061) mean: 7113.79 (0.10855) median: 6916 (0.105531) standard deviation: 5159.37 (0.078727) kurtosis: -0.27073 skewness: 0.513194 entropy: 0.955864 Blue: min: 0 (0) max: 29593 (0.45156) mean: 7540.07 (0.115054) median: 3124 (0.0476692) standard deviation: 8041.49 (0.122705) kurtosis: -1.54838 skewness: 0.493819 entropy: 0.800535 ```

note that the max value (in float) is ~0.5

except alpha which is constant full 65535

(this image has a superfluous alpha channel at a constant 1.0)

it doesn’t do any tone mapping by default

it maps [0, intensity_targets] cd/m² to 0-1 in sRGB

to get tone mapping, you can call e.g. `JxlDecoderSetDesiredIntensityTarget(dec, 255);`

the djxl equivalent is `--display_nits=255`

that would tone-map the image to 0-255 cd/m² and then map _that_ to 0-1

the output, in that case, looks like this:

Does the original image have a hint on the nits value to be picked by default?

No, it has the nits that the image actually represents but not the nits of your display

I'm pointing out that for SDR color spaces, which are *display-referred* we should always map to display-nits of 255

Anyway, <@604964375924834314>, wouldn't it make sense to have a lower default display nits when outputting to sRGB?

^ sRGB 1.0 is defined to be whatever the max of your display is

Technically that is a more lossy thing to output than a 16-bit non-tonemapped image that has the whole dynamic range, but it would look a lot better

we should perhaps only do that if `original_colorspace.tf.IsPQ()` or something along those lines

for context, libplacebo assumes SDR displays have a brightness of 200 nits and 1:1000 contrast ratio of black level to white level

HLG, for example, is not really meant to be tone-mapped in this way

this is a PQ image, data was PQ before being cjxl-ed

yep, just thinking out loud about how to go about generalising it

hm

this image is mapping to ~50% in sRGB space which is ~21% in linear space

the intensity_target of that image is 10 000 which may well be much higher than necessary

it is likely that it does not actually reach 10 000 cd/m² anywhere

well, considering that its maximum in linear light is ~21%

I'm guesing that it actually reaches around 2100 or so

It looks like chromium and mpv both do peak detection

in order to map HDR -> SDR

so I've added peak detection to jxlatte to make that work better

Around 2015-2018 I had a high-quality NEC 'photo editing' monitor (at the time when I was developing butteraugli). To extend the experience to HDR I used it at nominal 250 nits instead of -- for example -- the more boring 80 nits of sRGB. Later a more technical engineer (IIRC Jan) intepreted that it is 255 for 8-bit values (like we often have for old 8-bit graphics), and that's how 255 nits became default.

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

at d2

It was a coding session like: "I kept pressing buttons on the keyboard until it worked"

but it was fun nonetheless

oh that's nice

for SDR to HDR they assume 203 nits and contrast ratio of 1:1000

placebo does, at least

this sounds kind of debatable

BT.2408, which proposes the 203 cd/m² level for “HDR Reference White”, says: > NOTE – The signal level of “HDR Reference White” is not directly related to the signal level of SDR “peak white”

and in its annex 8, proposes a HDR->SDR mapping that maps 75% HLG (reference white) to 90% SDR, not 100%

with that mapping, it’s 260 cd/m² on a 1000 cd/m² HLG display that would correspond to (1, 1, 1) sRGB, not 203 cd/m²

and if 203 cd/m² is diffuse white, I do feel that it should give better results

you likely don’t want diffuse white to be too deep into the highlight roll-off

it seems to me that people tend to hear “203 cd/m² - white” and jump to hasty conclusions

interesting, I've forwarded the question to haasn

Jyrki the hero

The unstoppable, ascended warlock priest of image coding

Haha, that made my day 😄

this is one exciting thing of encoding ! despite the bitstream is frozen tricks can still/will be found to improve the encoding 🙂 (like for jpegli 😅 )

google/butteraugli is an earlier version, libjxl butteraugli includes optimizations that make it work with machine learning and also improvements that help with jpeg xl

very likely google/butteraugli is more precise against humans

it is possible that libjxl butteraugli works better with larger errors, as this wasn't my goal when I was building google/butteraugli -- the jpeg committee wanted much lower quality than what was interesting to me

How much versions of butteraugli exists?

I'm asking because in Google PIK is a version of butteraugli too https://github.com/google/pik/tree/master/pik/butteraugli

that's weird

IDK, I kinda lost count

Are the jpegs RGB or YCbCr?

And how do you decode them?

use libjxl's butteraugli when you want the latest stuff -- I suspect there are about five versions (one in google/guetzli, one in google/butteraugli, one in pik, one in libjxl, etc.)

great!... no... not quite. the result is not very good, artifacts of this kind have not gone anywhere. but they have weakened a lot... and I also discovered new artifacts that didn't exist before 🤭

now I'm going to do a full test and give you new album covers. but I can inform you in advance that problems with the yellow color have begun

but I also noticed that there were much fewer problems with red, even where I hadn't noticed artifacts before, now there are none at all

I also want to note that the artifact from the last image was not solved at all. apparently this refers to some other area that needs to be fixed

<@532010383041363969> oh well

the first 6 images have new artifacts after the update (I'll make a comparison now), image 7 here, it shows that the new update works much better on it, then 3 past images for comparison, and at the end 2 images with very small artifacts of unknown origin

—Original —old (27 feb build v0.9.0 8137953) -e 9 -d 2 —new (2 mar build v0.9.0 b931fc5) -e 9 -d 2 —new with marked where is the NEW artifact

I want to note that the artifact I wanted to show has disappeared from the pre-last image. obviously, it arose because of the location of the image, most likely the problem was in the shift of pixels inside the block.

I hope that soon I will not have all your album covers in an emergency test corpus, but I'll be able to solve problems faster than new emerge 😅

as far as I am aware, GIMP uses mozjpeg internally

I ran `cjpeg -q 98 <lenna.png >lenna.jpg`

and in GIMP opened lenna.png, unchecked all the metadata, set the quality to 98, and used integer 4:4:4 optimized progressive export to lenna2.jpg

then `magick compare -verbose -metric pae lenna.jpg lenna2.jpg comparison.png` reported zero for PAE

i.e. identical pixels returned from the decoder

here `cjpeg` is mozjpeg

does it not use system libjpeg, whichever that might be?

I don't know, I think on windows it uses Mozjpeg, not the Windows image codec API

on linux it might just default to /usr/lib/libjpeg.so, which for *me* is mozjpeg

Is libjxl not available in the Ubuntu apt repos?

Maybe only in future version 23.04 https://packages.ubuntu.com/source/lunar/jpeg-xl

--progressive_dc=2 breaks the color

why am I not surprised

ubuntu is just debian

That means, they never update anything.

idk why everyone is so attracted to that

there are much better "server" distros out there

some update about the decoding speed - alpha really makes a difference. The same image, both with alpha channels but one having it completely uniform 255. With "complex" alpha - 11.73 MP/s With "plain" alpha - 24.66 MP/s BTW, encoding with -d 0 -e 2 makes decoding speed worse

cannot check with lossless alpha yet - waiting for this option to appear in the stable build

But overall, the decoding speed even without alpha is still several times slower than webp 😦

<@532010383041363969> I observe global problems with color DIM with yellow and green, even with high quality -d 1

Several times? I think single-core vardct decode speed should be not that much slower than webp decoding. What kind of MP/s are you getting?

I made pixel difference maps for the old and new version to show this

these are 5 more covers of my albums that looked definitely better on the version from Feb 27 than from the current one from Mar 4

well, probably something is seriously wrong with my code. I've just compared the time for 100 decodes of the same image (2048x1024) from JXL and WebP. jxl: 3290.0590000ms webp: 985.8875000ms

Single-core JXL: jxl: 8899.4905000ms webp: 966.2073000ms

Test images

so, about 9 times slower when single-core

Are you excluding the time to encode the decoded image?

just decoding from memory.

Decoding from and to memory?

loading time excluded.

yes, from and to memory. Actually, for WebP I do one more conversion - converting the pixel format, while for JXL I just leave it as is

Hm, what kind of cpu are you running this on? Does it have avx2?

Intel i9 11980HK

Did you compile libjxl yourself? Can you check what SIMD it is using? E.g. running cjxl it should say that in the first line of output iirc

no, I get it using vcpkg

cjxl reports [AVX2, SSE4, SSSE3, Unknown]

but it's a separately downloaded cjxl. Can I query libjxl somehow to get this info?

Good question, I don't think so

vcpkg, is that using msvc?

Profiler shows static void jxl::N_AVX2::FromLinearStage<...>::ProcessRow(const class std::vector<...> & const, const class std::vector<...> & const,

Clang compiles are quite a lot faster than msvc ones, iirc