JPEG XL

0.5 $K for enter price? Just kidding, right?

Their tiers lmao

IMHO, there's not much of a point of talking about manually installable linux packages, that's not "support", that's just how external non-OS software works there. And third-party plugins are not OS itself.

Definition of the support might be blurred. But the real problem is creating sustainable open source software.

it's not so clear where to draw the line in some linux distros — in many distros, technically almost everything is "optional" and the bare minimum install doesn't include much at all...

I think the main thing is to be in the default repos of the default package manager so either you'll end up having libjxl installed automatically in many cases because something dragged it in as a dependency (e.g. gimp or imagemagick), or it's easy enough to get it installed (just `apt install jpeg-xl` or whatever).

SYN+ACK

ACK

I am wondering if the whole site is a spoof of those types of developer subscription services.

> By using our free tier, you agree to `console.log` our sponsor message. This requirement is waived for Enterprise customers, giving you complete control over your browser console. Me: ```js console.log(response.sponsor) console.clear() ```

i think it is

it's absolutely that

looking at the TOC, it seems to start by briefly explaining about coding tools of lossy compression, like DCT, quantization, entropy coding and chroma subsampling

maybe I'll give it a read

Maybe it would be less wordy if it merely mentioned the support being added to the backend libraries gdk-pixbuf/kimageformats used by gnome/kde and distributed by Red Hat, Debian, Arch, BSD, Slack, whatev version 123.45

That would be the simplest way to say it and more laconic.

Instead of listing so many different small distros, just focus on "support was quickly added to the backend libraries gdk-pixbuf and kimageformats used by GNOME/KDE, as early as X, as distributed by Red Hat version Y, Debian Z, BSD XYZ..."

We found JXK-tan

Please do not forget OIIO = https://github.com/AcademySoftwareFoundation/OpenImageIO

Some distros have several "tiers": minimal, full, etc. If jxl pixbuf is installed by default on full but not minimal, and minimal is the main tier, it is still support, just not on all tiers.

Is it only in Japanese or is it English

I wouldn't spend too much space talking about Linux workstations that are not very common to begin with. It seems kinda desperate to me.

I would keep the linux support as simple and brief and direct as you can.

Of course it's nice that kde and gnome have great support sooner than anyone else. But leave it at that, no need to spend too many words on it since it's not a common workstation product

Good for Steam Deck users

The Steam Deck comes with it ootb

in which ways does it seem desperate?

Well, mentioning so many different obscure desktop Linux configurations such as Solus OS which seems to be semi-abandoned

It seems a little too desperate to list so many different Linux distros instead of keeping it short

I don't get it, desperate for what

Btw I was surprised to find libjxl is preinstalled on the Steam Deck

I don't know if most people here are aware but you can add that to the list of commercial products and platforms that ship with jxl support

as I see it, it's just documentation, it doesn't seem desperate for anything, at worst it's going to not apply to a lot of people, but that doesn't mean it's not interesting to read or useful to document

It's not that noteworthy at all to mention if a very obscure Linux distro packages and distriutes libjxl

There are countless very obscure Linux distros that package a very wide, broad scope of software and mentioning each one is not necessary.

You reminded me https://github.com/ValveSoftware/gamescope/issues/1525

Trust this will be implemented at some point

I wasn't trying to mention all Linux distros, for example there are a lot that are derived from Debian but I didn't mention any of them (except Ubuntu) since it's kind of implicit that they also have a libjxl package. The smaller ones I listed are independent (as far as I understand) so it's somewhat relevant that they have libjxl packages.

Well, it's just my opinion. Brevity is a virtue, and I think the sentence could be restructured for brevity by focusing on support being added to the underlying libraries in GNOME/KDE, as distributed by major distributions.

Yes, good point to add something about gnome/KDE/qt/gdk-pixbuf/kimageformats

Yep. Mention the upstream first before the downstream distributors, of which there are too many to list them all.

JXL support in kimageformats is optional. Sometimes packagers built it without libjxl dependency. For example, recently I used "pkg install kf6-kimageformats" on FreeBSD and only limited version of kimageformats was installed. However when I compiled it from "the Ports" using "cd /usr/ports/graphics/kf6-kimageformats/ && make install clean" JXL started to work in KDE.

Cursed jxl logo here: https://www.leproton.com/2025/03/le-jpeg-xl-sur-apple-et-windows-11-pour-l-instant.html

https://image.over-blog.com/LBZze1EdbyMhMqosIycioj5Ec0s=/filters:no_upscale()/image%2F0576035%2F20250309%2Fob_287611_presse-papiers-1.jpg

A nice apple green xdd

How does that even happen, I wonder

"Le JPEG XL" feels so weird (and my motherlanguage is French)

Le jépègue excellent

we pronounce it gipeg

from saying it so often in English, I say it that way in French too

djèï pègue excèle

well, not quite – I think that ‘L’ in “XL” is dark? (https://en.wikipedia.org/wiki/Voiced_dental,_alveolar_and_postalveolar_lateral_approximants#Velarized_or_pharyngealized_alveolar_lateral_approximant)

which French doesn’t have

so “excèle” is not quite it

<@245794734788837387> new soundboard just dropped, and it's a silky smooth one

took me a bit to understand what you meant lol (I've been awake quite long)

Same

got the colour space wrong maybe?

le JPEG XR

<@794205442175402004> maybe this is something that could be addressed about the graphic?

it is implied that what's being shown is how many bytes it takes to encode the gradient. it might be good to specify whether the header or other data not used specifically to encode the visuals, is included, and if it is, maybe you could do something along the lines of > 523 bytes + 12 bytes (header) also: it might be interesting to show what that gradient would have looked like in JPEG XL without adaptive LF smoothing :3

I think the least confusing way would be **535 bytes (12 byte minimal jxl header)** **700 bytes (150 byte minimal avif header)**

just putting it in parentheses doesn't make it all that clear whether the header is included in the first byte count

(inc. X bytes minimal Y header)

that works but then people are gonna have to do math when they wanna know how much bytes it took to encode the gradient. this graphic is a visual aid specifically for the section about how adaptive LF smoothing can preserve slow gradients at low quality settings; IMO it doesn't make much sense to include header bytes (or other metadata if applicable) at all. the paper has a different section which specifically talks about the header size

It's debatable whether including the header size at all is even relevant and expected in the first place

I think it's more confusing not to put the total file size first.

X bytes (y payload + z minimal header) This might be closer to what you like. X bytes (y-byte minimal header) This keeps the focus on the total file size, with insight into the header overhead for the curious.

The way I see it, it's the problem of formats with verbose headers that they waste bytes on them, not my problem 🙂

to be honest that does bother me a bit, it feels like that's nearing "intentionally misleading" territory 🫤

however the thing about the headers is that it only really affects small images

even if AVIF's header is 1 kB, if its a 2 MB image that's 0.049% of the filesize

Wouldn't 1K be exactly 0.05% of 2M?

JEDEC/IEC units don't exist and should never be used ever

no they are based because we should all be using binary instead of decimal in our daily lives anyway :)

It is only misleading if you assume small images do not matter. If you look at histograms of image file sizes on the web, that's not a valid assumption.

*fine*, even if AVIF's header is 1 K**i**B, if its a 2 M**i**B image that's 0.049% of the filesize

sure, the web has many small images but i would say it would be around 10-100 KiB would be small, not < 1 KiB

the median web image is 0.058 megapixels: https://almanac.httparchive.org/en/2024/media#image-dimensions

the median file size is 12 kilobytes: https://almanac.httparchive.org/en/2024/media#byte-sizes

What size header is AVIF actually again? Was it around 300 bytes?

that is excluding the 6% of images on the web that are just 1 pixel tracking images / spacer images

what is the smallest possible 1x1 image?

I guess it would just be "which image has the smallest header"?

https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit#slide=id.gde87dfbe27_0_43

what is the point of a tracking image anyway?

what does it track?

is it a way to snatch headers without js?

Only SI multiples of 1000 are a valid way to count

1024 nonsense is the dumbest mistake of computers. Dumber than null terminated strings.

Dumber than Objective C

Dumber than GNU/Linux

usually it's basically to let some third party analytics thing get logs on your traffic, including e.g. things like html email where adding a tracking pixel is a simple way to get an idea of how many times it gets read

Kilo always =1000

yes, kilo should always be 1000. It does make sense to design stuff like cpu cache lines etc in multiples of 1024 though (or whatever other power of two) since many things are more convenient that way.

they should be used with their correct prefixes “I bought a 500GB [SI] hard drive to complement my 4 GiB [IEC] of RAM”

“that’s about 465.7 GiB”

kB = 1000B KiB = 1024B KB = abomination

There's almost never a good reason to ever use kiB instead of kB. Especially for file sizes, it should never ever be used

(KiB, uppercase)

File sizes are properly expressed in bytes. Not in some bizarre multiple

i raise you: https://www.youtube.com/watch?v=rDDaEVcwIJM

Eh. Technically the best radix is the natural base, *e*

2.7...

So ternary is actually closer to ideal than binary

I think I misinterpreted your intent. it would be intentionally misleading if you were counting on the idea that people would think those bytes go towards the encoding of the gradient directly. if your intent was to show how large those are as actual image files then it's not intentionally misleading :)

chapter 1 of this video goes into how this is a misconception, if you're interested

I will also say that there are many more subjective and objective benchmarks in addition to radix economy, and the authors found binary ticks the most of these for any base, making it the overall best

If the implicit assumption is that the gradient would be a part of a larger image, then comparing at same payload size (ignoring headers) would be the more correct way to do it, but if you're just comparing that particular small image of a gradient, then comparing at the same file size is not wrong. Either way: if you'd make a comparison at same payload size, excluding headers, the result would not be hugely different: jxl would still look better than the rest, the difference would just be a little smaller. So in that sense I don't think it's misleading: it's not like the avif gradient will look better than the jxl one if the avif header overhead is ignored...

I see... But the Soviet Union found ternary computers to be ridiculously more efficient than the counter-revolutionary plot by the bourgeoisie American capitalist pigs to promote binary

This video is clearly another one of their schemes to keep the working class divided

Perhaps <#806898911091753051> now that the Soviet Union is involved? xD

I took a closer look at that section. They are actually cheating by saying the first digit carries no information since the first digit is always one.

If the first digit is always one, then this only applies for numbers of the same magnitude. Not for numbers of different digit lengths

You can't just cheat by getting a free digit

If it carries no information and is always the same value then you can't compare it and count it in the comparison because otherwise the comparison is only valid with numbers of the same magnitude/number of digits

Then you're right back where you started anyways, with leading zeroes

how do you mean?

wait let's move to off topic

Transcribed & Translated "Bienvenue sur ce serveur Discord dédié à Jpeg XL." "Welcome to this Discord server dedicated to Jpeg XL."

It's a single line mention of JPEG XL, but I stumbled across this <https://assets.publishing.service.gov.uk/media/67d1abd1a005e6f9841a1d94/Final_decision_report1.pdf#page=153>

(small correction: dédié à JPEG XL)

I got pretty close for somebody who doesn't speak French 😅

so you're saying we should write the number 3 as 100200112000001...[it goes on forever]?

No mention of Jpeg xl <:PepeSad:815718285877444619>

Make an edit😎

Hmm, depends on how much precision you want I suppose 😂

The most efficient integer base would be 3 since it's closer to *e* than 2... This applies to telephone driven menu systems for example. If you want to waste the least amount of time listening to the options, give 3 choices for each level of the menu.

You'll waste less time getting to the desired choice compared to a binary tree

https://freedium.cfd/https://medium.com/@arnoldgunter/your-website-needs-this-image-format-in-2025-not-png-jpeg-740978a2526f

https://discord.com/channels/794206087879852103/803574970180829194/1354054294533308427

new slop article just dropped > Basically, it's like going from a flip phone camera to a DSLR — without slowing down your website. - unnecessary analogy to explain the concept of "better" > Let me prove you wrong. There's an image format called AVIF that outperforms all the others by 10 times — faster, smaller, and sharper! - it doesn't > AVIF stores high-quality images at much smaller file sizes than JPEG or PNG - it doesn't, this is only true for JPEG, not PNG > since the ྖs, AV1 - since the what

this article is horrid lol

It is terrible. Like most Medium posts.

> And they thought, "Hey, if we can make videos better, why not images too?" they thought wrong

that weird symbol seems to return pages that include '1990' when searched. I'm not sure AV1 has been around for quite that long

Why do these numbers feel made-up?

If those numbers are close to something real, then it cannot be a photographic image, since then the PNG would be much larger compared to lossy formats with SSIM values that low

But I suspect they're just completely made up

On photographic images, JPEG is actually slightly better than WebP in most of the quality range — you need to go down to ridiculously low quality for WebP to beat JPEG, since at some point JPEG becomes a blocky mess while WebP is a more acceptable blurry mess.

huh, genuinely surprised JPEG beats WebP like at all

I mean good jpeg encoders like jpegli and mozjpeg

Unoptimized libjpeg-turbo doesn't beat webp

AVIF does beat JPEG by 15% or so on average, more for non-photographic images or photos with lots of high-contrast edges. On some images though, it doesn't beat JPEG and performs slightly worse.

For example on that bottom image, AVIF is actually 30% larger than JPEG at 1 JND

> U+0F96 Tibetan Subjoined Letter Cha > "since the Chas, AV1" Hope that clears it up.

They aren't consciously made up

Someone made an LLM to write an article about this and the LLM generated those numbers based on marketing materials like "avif is 40% the size of JPEG and higher quality!"

It's not an act of conscious deception, just your standard issue AI generated slop

1 JND = the threshold of visual transparency? In a side by side test?

Or flicker test?

In this test, 1 JND is in a pairwise comparison with in-place switching between orig and distorted, so you see (A vs B), you can switch between that view and (orig vs orig) as many times as you want but no faster than 2 Hz, and have to select which is the most distorted, A or B.

(that's called the PTC protocol)

But the BTC protocol was also used, which is similar but with 10 Hz flickering, 2x zoom and a 2x artifact amplification (per-pixel sample differences between orig and distorted are artificially made larger). This allows getting precise results below 1 JND, since it makes more artifacts noticeable. But the scale is based on PTC conditions, not BTC.

PTC = plain triplet comparison BTC = boosted triplet comparison

So how many PTC is one BTC?

All I know is 1 BTC is 88047.85 USD

Or are they not units specifically

It depends on the overall distortion, but roughly 1 JND in BTC conditions is 0.5 JND or so in PTC conditions.

so around 2:1 on avg?

Yeah but the gain is larger at low distortion and lower at high distortion

I don't see how limiting the speed of switching between them would matter for the test at all. Best is to avoid flickering altogether and just have 3 images side by side, the first image is always the original and the last 2 are shuffled so you have to choose which image does not match the others.

And it also depends on the type of boosting that was done, e.g. in the HDR experiment we didn't do artifact amplification, only flicker and zoom.

Doing in-place switching makes artifacts a lot easier to detect than if your eyes need to travel

Flicker makes it easier for a human to distinguish

The test would be too easy with flicker.

Easy is good, the goal is to measure quality, not to punish the test subjects 🙂

Well if you can't tell which one is more distorted or which image doesn't match when you have 3 of them side by side, then it's probably good quality!

Not for production workflows!

Basically you would have 3 identical views side by side, the first one would always be the original, the last two would be shuffled, and you have to guess which one is the bad one. If you can't guess then it's not bad!

"One of these things is not like the others" is easy

You need a quality score that doesn’t end at “humans can’t see the difference”

Then you can have 2 views where one side is the original and the other side is the flicker view, like what _wb_ described. That's the flicker test which is easier.

The problem with side-by-side protocols for still images is that they cannot provide a fine grained quality scale, especially not in the range above say libjpeg q50. Basically anything above q50 will be noisy data with confidence intervals that largely overlap.

That's only a slight modification

Instead of 3 views you have 2 views where the last two shuffled images are combined into one flicker view.

A test like that would be trivially easy for all but the most indistinguishably transparent algorithms

Many variations are possible

If you want the 3 view method I described to be even harder, for judging images that are lower quality, you can make it harder by resizing the images smaller. Or start fading the image out with alpha transparency on a white background, so errors and distortion are less significant.

As long as you do the exact same thing to all 3 images.

But median test subjects tend to be less good at detecting artifacts than professionals, that's also something to take into account. 1 JND is a difference that can be noticed by half of the observers and not by the other half, or in a forced choice pairwise comparison, you have 75% selecting the distorted image and 25% selecting the original image. So we call it "visually lossless" at 1 JND or below, but actually by definition half of the population can actually see a visual difference.

I am always surprised at how low quality 1 JND actually is, even in testing conditions that make it easy to notice differences.

Why white? So it makes it evenly-harder to see all parts of the image, instead of a greater disadvantage on darker areas

Hmm, yeah that's a problem. The test methods I am proposing assume the test subject knows what differences to look for.

You don't need to make it harder, standard bt.500 test protocols like DSIS already work well enough if you're interested in very low to medium quality images

You might need to make it harder for yourself if you are tuning a codec by yourself and want to give yourself a disadvantage since you know what to look for and better at spotting differences than the median.

The challenge is to test in the high fidelity range while being able to use naive test subjects — paying professional photographers or other eagle eyes to do quality assessment tasks is quite expensive 🙂

Double blind testing is sacred

Also naive test subjects are more representative for the general population so more relevant for most use cases

But it's not good enough to build a product that caters to the utterly clueless.

Setting standards so low is not enough to be competitive. A good product satisfies professionals too.

You never know who's going to depend on your technology.

Which is why we are using the AIC-3 methodology which can go below 1 JND

Like for example, people with medical or astronomical sensors or even cameras shooting RAW, they need a codec that doesn't only perform well perceptually at a single predefined intensity scale, but rather, something that performs equally well at different scales when they adjust the levels and gamma curve.

It took me a couple of years to get the rest of the JPEG committee to understand that "below 1 JND" is actually a very relevant quality range. They understand it now, but it took time to get the AIC-3 project going

Yeah or just normal photographers who want to keep some room for postproduction

So in other words you convinced them that there actually is demand for high fidelity. By pointing out for example the average jpeg bitrate on the internet is surprisingly high.

I think libjxl has a lot of room for improvement when it comes to making it simpler for people who need gamma-scalable compression

Idk if you would call it that.

But you know what I mean

Like the recent question from the one with astronomical TIFF

In that situation perceptual coding is a clumsy tool

There should be an obvious "scalable mode" for those users

Maybe we should add some option to indicate a range of max nits that has to be taken into account, not just a single value. It's a subtle difference from using the highest max nits value as the intensity target

There's an option called "disable perceptual" but idk if that's the same thing

idk what that actually does in libjxl

Is there a mode that performs equal at high and low intensity scaling?

Like a "logarithmic quantization" mode or whatever you would name that type of idea

Floating point quantization behaves like this. The larger the number the larger the error.

Human eyes also. Less sensitive to large changes at high intensity, more sensitive to small changes at low intensity.

Disable perceptual is what you may want to do if the data is not visual at all. It is supposed to just optimize for PSNR. But that's not really what you want in use cases where the image is visual but it may be viewed at (or postprocessed to) different brightness levels...

optimize_psnr would be a clearer and more accurate name. Maybe even a new option like x264's "tune=" knob

What would be better than PSNR for that?

I think psnr should scale at high and low intensities, right?

As Jon said, sometimes it actually beats AVIF <https://giannirosato.com/blog/post/jpegli-xyb/>

Should probably make cjpegli use 444 by default to avoid the drop-off, and give it JXL transcoding compatibility

It's funny because the API has different defaults compared to the CLI

<@862810094734934036>

I mentioned it before, but having an option like `--intensity_target` that only influences the encoder, not the set brightness in the resulting JXL, would be a decent work around until something more thorough can be done

it seems like it would be nifty

I think it should just scale in linear light for chroma subsampling...

like the sharpyuv option does for libwebp and libavif

does it not already?

Before I forget again https://github.com/libjxl/libjxl/issues/4163

When using XYB

Yeah

I tested Jpegli + XYB before and the file size actually decreased further more significantly

It's surprising that the bug with cjpegli still remains and it still doesn't use 444 by default in xyb when it's a one liner fix

I think the problem is that it's not clear where the decision making happens because of the confusing layout of the spaghetti code

But still it's not hard to find with basic ctrl+f skills

It kinda boggles my mind sometimes, libjxl

I wish the official reference software for the ultimate new format, wasn't such a mess...

Not to undermine my appreciation and gratitude that it exists at all.

https://old.reddit.com/r/Android/comments/1jjq3cr/when_will_google_stop_holding_back_innovation_and/ Clueless people who blindly trusted the online dark propaganda to suppress and slow adoption of jxl really want the world stuck on decades old JPEG for more decades...

Odd its not known that apple ecosystem' support is not just ios or dng. according to napkin math and due to apple's longterm support for devices, its now closer to *almost 90% of all apple devices* in active use that have succesfully connected to the apple store at least once in the last 12 months - meaning including ipados, macos, visionos, and *not just safari* - every app on those oses can read, use and generate jxl without needing to add their own library

According to caniuse, almost 43% of all **mobile** devices actively used in the US can decode jxl (UK, canada, japan and germany trail closely - big markets whose digital sector and datacenters needs more efficiency - if your content is local or accessible only through your own apps, you would gain from earlier adoption). Focusing on the total % overlooks the fact implementation on chromium would have it gain an extra 65%

wait for jxl-rs

realistically I dont see much happeneing until it does come

why wait? like what does it change to the discussion compared to what we already got ?

is there an ambassador committee working behind the scenes to support flawless integrations into big business' workflows and web services?

well to begin with, I doubt aosp nor chromium teams will actually care until jxl-rs releases because c++ is a security issue

jxl-rs is the saviour library for the entire world of image formats 🤔

c++ was always an excuse. its just they had no idea a rewrite could actually be completed quick and destroy even more of the excuses before they could prepare new ones

well mozilla has already said they would implement jxl support when jxl-rs lands, aosp is pushing hard for rust right now and is in a mad dash to rustify everything they possibly can, as for chromium, wait until the pressure builds up, but that wont happen until jxl-rs

this is not true, like it or not, history has proven without a doubt that C/C++ **are** security issues

and images have historically been a massive issue for security

that and videos

code aside, they could always have given vocal support and flattering blog posts in support - jxl is a format, not specific libraries

why bother with that?

its the silence and innuendos that cause the rest of the imaging ecosystem to stick with what they got. like, 'maybe they know something we dont - adopting could be bad'

myths should be debunked

I dont think so, I mean, look at what is already happening, apple implement jxl support and its been working fine, mozilla will be implementing jxl soon, windows and osx have it, linux has it depending on distro and config ofc

right now the bottleneck is jxl-rs

Not really working fine. Opening JXL is significantly slower on macOS (not that f*cking "osx")

Using "osx" is as horrible as using "JPEG-XL"

> The iPhone only supports it because of DNG. riiight

which is why they went all the trouble of implementing non-DNG jxl support throughout their OS and browser

Most people aren't waiting for JXL IMO; they're instead waiting for the day they can upload HEIC/HEIF images to social media instead.

And throughout the entire ecosystem

more efficient storage of photos on their phones is a pretty concern id say. thats why derivatives of bloated jpeg dont exactly thrill (including hdr at no extra filesize isnt a win when jxl can too include hdr in either true hdr or gainmap and sill be half as small and with higher visual quality)

people cant keep getting even larger capacity mobiles and ever-bigger sdcards to compensate

Like how almost all 4K content is HEVC/AV1 ?

People can't wait for something they don't even know

jxl-rs is going to be mostly SIMD code

If it's faster than libjxl then maybe apple will upgrade to it later

Along with everyone else... libjxl might be left in the dust before long

Which is not a bad thing. It was due for a major rewrite/refsctor anyways...

heic is such a meme format... I hope apple's camera app starts capturing jxl soon instead. I notice apple heic is much larger than an equivalent jxl.

libjxl should reach 1.0 first; projects are still waiting for a fully-stable 1.0 release.

Eh, it might not ever? And it would be perhaps less effort at this point to rewrite from scratch compared to cleaning up all the messiness.

It's the messiest and most disorganized codec library I have ever seen honestly

Compared to the libraries for other audio and image codecs

It NEEDs to at the very least; projects will just move on from this JPEG standard as well like JXR if it takes way too long to release 1.0.

Not counting motion video. Haven't taken a look at those

We don't necessarily need a libjxl 1.0. A jxl-rs 1.0 would be almost the same thing. Or a libjxl-ng fork/rewrite

At the very least this image format should not suffer the same fate that befell JPEG 2000 and JPEG XR.

Even lossless JPEG support is not exactly guaranteed.

Lots of people abandon the reference encoder. No one uses the MP3 reference encoder.

Agreed, but if something shows up that completely outclasses the reference library in every way, people typically just abandon the reference library. Like people abandoning libjpeg for libjpeg-turbo

As long as a very strong replacement shows up.

If it's strong enough, the reference library eventually fades into irrelevance.

A decoder only rust implementation isn't 'almost the same thing'

libjxl is not easy to compile with all of its dependencies and lack of separation in the build system. The rust rewrite might actually be more convenient to compile, let alone contribute to, simply by virtue of being written simpler from scratch.

And you also forget that writing a decoder is a lot more work than an encoder.

It's not guaranteed that jxl-rs will remain "decoder-only" for long

It makes sense to focus on a complete, compliant decoder first.

A decoder has to be complete and thorough and flexible enough to handle all possible valid jxl files, whereas an encoder gets to define its own rules and complexity.

writing “an” encoder, sure; writing a good one is another question

in a sense, writing a decoder is more “mechanical”

whereas an encoder is more of an open-ended problem

libjxl includes multiple different encoders, you could say. The lossy modular+dct encoder is merely "okayish" compared to what the format is capable of. The fast-lossless encoder is phenomenal. And the regular lossless encoder is also "decent but lacking many specific special case optimizations"

Actually you could say the regular lossless encoder is very inefficient with time.

Lacking special-case optimizations, you get terrible performance and surprisingly ineffective compression sometimes.

The only encoder I would say is phenomenal is fast-lossless and it's much, much simpler and smaller than a decoder. And it was written by Luca who is also in charge of jxl-rs

The other encoders in libjxl is what you would expect from a rough first draft that gets replaced later.

A good first-exercise in some of the main strengths and capabilities of the new format, but something you replace with a second draft.

I mean, that's what libjxl is. A testbed of the past 6 years turned into a viable product. It's up to future implementations to focus on their requirements

Maybe someone should make like some kind of "JXL encoder boilerplate" library for people to experiment with designing different possible encoding models

Wouldn't be the most performant but would allow for experimentation

it would have functions for things that are effectively "intrinsics" for JXL, such as the structure of the data, writing an ANS codestream, etc

while leaving high level decisions like Varblock size and modular tree to the developer

JPEG 2000 and JPEG XR had different problems which hampered their adoption. For J2K, it was the lack of a fast encoder which gave people the false perception that it was slow. For JXR the encoder just sucked, which gave the perception that the format itself was limited (being made by Microsoft didn't help things either). JPEG XR just wasn't production ready.

JPEG XL is in a unique position where the only thing holding it back is basically company politics (chromium team 😔).

Company politics and complex integration I'd say. Seems to be a lot of build/config issues making adoption slack behind in Github repos

We can always overcome technical hurdles, but we can't do anything about company politics.

Of all the people here, Youtubers, Discord staff, Researchers. It's a shame we don't have anyone from inside the Chromium team to give real answers

JXR has regained some popularity thanks to some gaming utilities and HDR wallpapers for Windows 11

Namely because it was the only native HDR format in Windows, so games had to save using it

Hmm does Photos support HDR JXL?

i asked someone to test it before photos actually supported .jxl (so files had to be renamed to e.g. .png) and it was only displaying it in sdr

might be different now

I save literal gigabytes on my phone by using jxl

indeed, a lot of people dont want to also wind up pulling other deps like hwy

is jpegxl good at deduplicating two or more same spots

format/spec wise yes (via "patches" and such) however the current libjxl encoder can't really deduplicate stuff that well

The code for better patch detection was lost 😭

No

It can, but not currently https://discord.com/channels/794206087879852103/803645746661425173/1280929625555603480 https://discord.com/channels/794206087879852103/803645746661425173/1247714711777054730

I thought it was good at that

Like screenshots

Like that discord screenshot where it deduplicated almost everything but <@386612331288723469>'s avatar

Is there even a JXR encoder that doesn't have far worse quality than jpeg-turbo?

it is good at extracting areas of contrast completely surrounded by flat color, often text. if you had an image of a script with connected letters, they wouldn't be individually extracted.

Creator of TestUFO left a comment https://issues.chromium.org/issues/40168998#comment471

I tried to clear up some misconceptions they made

AVIF as a successor to... PNG? 💀 God where does misinformation like this spread?

I was gonna link the Valve gamescope issue and AVIF being awful at lossless, but I'm on my phone and didn't want to loose the draft switching tabs

Would it be accurate to say AVIF is successor to WebP

That would be a more accurate statement

> Even though AVIF (usually) tends to be a better off-the-web format than WEBP is generally as a potential successor to PNG that has more capabilities (e.g. HDR).

going back the original videos for animations also isnt conversion but substituting source. jxl losslessly converts gifs, avif is inefficient at that

> I'd love to play a bit more with JXL now that HDR JXL is supported by Safari Tech Preview 125 it is? 🥰

oh really?

Preview on 15.4 beta doesn't support HDR JXL, it even shows severe banding which was not there before. maybe something is broken at some point. but I can update to 15.4 RC, I hope this is fixed there

Can you send me the hdr jxl

Was this already posted? https://www.reddit.com/r/Android/comments/1jjq3cr/when_will_google_stop_holding_back_innovation_and/

https://arstechnica.com/science/2025/03/scientists-are-storing-light-we-cannot-see-in-formats-meant-for-human-eyes/

The paper was posted in here earlier this month but Ars gets a lot of readers.

Popular comment > Of course, Google in its infinite wisdom decided to deprecate support for JPEG XL in Chrome.

Really wish they'd contacted us for assistance on that paper... Could've been even better

Discord doesn't look academic

> And while Spectral JPEG XL dramatically reduces file sizes, its lossy approach may pose drawbacks for some scientific applications. Or, just set JPEG XL to Lossless....

Is "Spectral JPEG XL" a formal term for JPEG XL?

still havent seen a PR from anyone for aosp, and sadly, we wont be able to see internal development going forwards so I we wont even know if there is internal work until the next AOSP release

its funny, if you submit a PR to aosp now, google devs will tell if it is accepted or not, but you wont actually know until the next code drop

<:kekw:808717074305122316>

Upstreaming in AOSP would only be ideal and reduce duplicated work for OEMs. OEMs' gallery apps can implement the support and itd be as good, since theyre both preinstalled and separately updated as apps

not really, you also need aosp to support it so things like documentsui has thumbnails, nearby share so on and so forth

you really do need the whole shebang

> And they've been blasted for it in github for years, and they kept marching on with that. > > They moved to support a newer "format", jpeg_r (ultrahdr) instead. > > Its baffling.

And this disgusting comment > OpenEXR has some really great lossy formats too - DWAA and DWAB. And OpenEXR can support 100s of channels. Not sure why they have to jerry-rig JPEG-XL to do that.

where is the context for this?

oh nvm

It's just too bad they didn't combine the channels into one file using an RGB visual base image with extra "spectral separation" channels in between

But there were libjxl limitations in the number of extra channels I think

Blue spectral channels can be encoded as "difference from blue" etc

can other channels be paired in xyb too? as in xyb+xyb+xyb+xyb? to get the same encoding benefits or is that better left to layers?

that was already the case for years lol

going "fully private" just means going from 99% private to 100% private..

nah, for aosp most of the stuff was in the open, only proprietary stuff like gms was private

it wasn't developed in the open, they just did periodic code dumps

that's not true though ?

a lot of review can be found here https://android-review.googlesource.com/q/status:open+-is:wip

You don't use layers, you put spectral info in extra channels. But there isn't a specified way to do it.

Im not necesairly talking about spectral info

My understanding was that extra channels are always losslessly compressed. Am I mistaken? If not, how would you produce a lossy multispectral image?

No, they can still be lossy, and you can specify the quality separately. The extra channels just aren't DCT though.

So you have all the modular coding tools but not DCT

Which is fine because jxl is still very powerful even without DCT and has a lot of useful lossy compression tools without DCT, like a haar wavelet transform.

I was misremembering the discussion in connection with an observation some weeks ago about extra channels of pixeltype float. The compressed extra channels turned out to be larger than they would have been if they had been stored losslessly, so compressing them was pointless. The argument was that extra channels are mainly used for stuff which compresses well, like alpha and masks.

Yep, it's lossless by default and modular mode is mostly designed for lossless compression but it's good at lossy too.

libjxl has an option to set the quality of extra channels

For photographic data lossy compression makes sense even for modular mode

There's an open issue on the large size of compressed float extra channels on github (#4082)

It makes sense that sometimes lossless is better than lossy. Lossy uses a progressive, wavelet algorithm by default, that is bad on some types of non photo data

Lossless is not progressive by default and uses a typical sequential lossless compression

<@532010383041363969> In regards to [your comment](<https://issues.chromium.org/issues/40168998#comment473>) replying to mine. > I agree that there are deviations from the usual JPEG XL use, but their compromises are well-judged, particularly given the typical time constraints of such research. I believe their compression approach is significantly superior to the most straight-forward application of JPEG XL. When I said 'a standard JXL file', I meant using a single file with the required extra channels storing their spectral data, as opposed to separate files for every channel that they ended up doing. I agree they took the right steps, but it could have been even better given a brief discussion here or with anyone knowledgeable with the format. Using a single file would allow referencing previous channels in MA trees. A lossless test could have been done relatively easily. Seemingly lots of low hanging fruit ripe for the picking if they had been informed.

Ah, it's still moy problematic. AVIF HDR tonemapped by Discord: HDR PNG (tonemapped? or left alone?) by Discord: SKIV tonemapping the AVIF HDR to SDR: Still needs a lot of work, the last time I saw tonemapping that bad with such wildly wrong colors, the Rec 2020 to Rec 709 matrix was transposed.

ok nice, Scott is still working on it a bit more so hopefully it should look properly later

When I searched "openexr vs jpeg xl" on DuckDuckGo, that _JPEG XL, the New Image Format Nobody Wanted or Needed_ was the third result

But the article mentions neither OpenEXR nor EXR

https://rec98.nmlgc.net/blog/2025-04-09

phoronix covered ubuntu 25.04's inclusion of jxl enabled by default https://www.phoronix.com/news/Ubuntu-25.04-JPEG-XL-Default

less known was that all other editions of *buntu (kubuntu, xubuntu, etc) apparently had it out of the box - reason for inconsistency is only base ubuntu swapped around the minimal and normal install, turning them into normal and full

odd how pro critics interested in photography arent aware almost all ios and macos supports jxl, and the top photo managers and image editors (ie pixelmator, serif suite, lightroom subscription and classic, zoner) also do

zoner even supported it since mid-2022 even though it never mentioned it in any changelog

Guess who provides the search disservices 4 DDG?

I don't suppose you remember roughly when that version was made? Curious if I can wedge a newer oxide version in and get better performance. Tried just a WASM swap but it errored saying something about `__wbg_instanceof_Window_def73ea0955fc569`

no it was quite a while ago sadly

Ah well, still works, just a few bugs that would've been nice to fix. I did change the blob mime type to PNG though, since the browser was reading it as text

https://vqeg.org/umbraco/surface/FolderList/GetFile?directory=2025_05_Meta_USA&filename=VQEG_SAM_2025_117.pdf&pageId=1669&m=0

^ VQEG presentation I did last week with Mohsen

What is the VQEG? Video quality expert group or something?

Yes. https://vqeg.org

https://discussion.fedoraproject.org/t/upcoming-switch-to-jxl-format-for-default-wallpaper/153086

I guess we should suggest the new and improved `--faster_decoding` options...

Those aren't released yet though, so not sure if they would

that can be fixed 😄

but also the decoder doesn't need to change for that

Also true, they could just encode with a main version

Are they using libjxl with multithreading?

If decode speed is an issue and lossless is required, besides faster_decoding the other big thing that effects decode speed is the encode effort

e1-3 encodes will decode much faster than e9+ encodes

Well, that's because faster decoding is effectively the same as lower effort settings. It just does more thorough checks with the same coding tools. If someone has an account, could they link to the faster decoding PR and ask them to repeat the tests using it. We've seen decode speeds faster than lossy, but it depends on multithreading and image size

Maybe we should've made a bigger comparison, against all effort levels too. Since it also beats lossless e1 and e2 now

I'll make an account 😄

> JPEG-XL’s support for lossless transcoding is impressive, but requires the input data to be a lossy JPEG image. When using non-JPEG input data, lossless JXL imposes some serious penalties: Much bigger files and slower decoding. That’s a crappy combo. ??? are they holding the size of lossless JXL to the standard of recompressed JPEGs?

"The lossless file is bigger" In other news, the more water you drink, the more it costs

If anyone has accounts for these already, might be worth mentioning the PR here too. Should be up to 4x faster with a 30% density penalty, or 2x and 5%. <https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/6886#note_2440128> <https://discussion.fedoraproject.org/t/f43-change-proposal-switch-to-jxl-format-for-default-wallpaper-self-contained/145923/3>

it is not intuitive for people the fact that reencoding a low quality avif into lossless anything would increase filesize they think that the avif is lossless compared to itself so the result should be equal or smaller to the avif in some way maybe

while the lossless size reduction is compared to the pixel array size

This is using PNG input

I was answering to that

just to be sure

the originals are PNG as far as I understand

They think it's like zip. Put in anything and it gets losslessly compressed.

or at least not larger, like putting a zip in a zip will never increase size much

But this is simply because they don't see how large the image becomes after decoding, before it can be reencoded.

they lack context. take a jpg, losslessly compressing that into any other format is *supposed* to make it several times larger in filesize - jxl is the unique outlier that manages to do a conversion at the highest possible quality (100% pixel exact) yet also guarantee smaller filesize than the original

many conversion scripts and utilities mess conversions by doing full encodes the old way instead of leveraging reversible lossless transcoding's superfast path when the source is a jpeg and is also in an unmodified state (ie not edited after being opened)

i think people expect newer formats to take smaller space than rhe original, even at lossless

Actually I think only e1 and e2 decode fast for lossless, e3 and above are always the same decode speed when I checked

It does, when the input is originally lossless too

It's because 3 is a fixed tree, but it's still the weighted predictor, so it's twice as slow

I get something like this for a random photographic image: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ---------------------------------------------------------------------------------------------------------------------------------------- jxl:d0:1 1084 1382376 10.1963931 768.200 140.849 nan 100.00000000 99.99 0.00000000 0.000000000000 10.196 0 jxl:d0:2 1084 1271944 9.3818477 51.116 185.763 nan 100.00000000 99.99 0.00000000 0.000000000000 9.382 0 jxl:d0:3 1084 1120205 8.2626222 39.143 103.180 nan 100.00000000 99.99 0.00000000 0.000000000000 8.263 0 jxl:d0:4 1084 1106477 8.1613646 4.607 67.287 nan 100.00000000 99.99 0.00000000 0.000000000000 8.161 0 jxl:d0:7 1084 1062487 7.8368947 1.236 44.334 nan 100.00000000 99.99 0.00000000 0.000000000000 7.837 0 Aggregate: 1084 1182855 8.7247286 24.458 95.763 0.00000000 100.00000000 99.99 0.00000000 0.000000000000 8.725 0 ```

So then only e1 and e2 decode super fast. e3 decodes just as fast as e9

For lossless

the last row is not for e9

well 103 Mpx/s is a bit faster than the 37 Mpx/s I get for an e9 encoded image

Hold on I haven't looked at this yet lol

ran it again with e9 included now: ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ---------------------------------------------------------------------------------------------------------------------------------------- jxl:d0:1 1084 1382376 10.1963931 821.328 155.343 nan 100.00000000 99.99 0.00000000 0.000000000000 10.196 0 jxl:d0:2 1084 1271944 9.3818477 52.250 179.652 nan 100.00000000 99.99 0.00000000 0.000000000000 9.382 0 jxl:d0:3 1084 1120205 8.2626222 41.265 105.087 nan 100.00000000 99.99 0.00000000 0.000000000000 8.263 0 jxl:d0:4 1084 1106477 8.1613646 4.330 63.568 nan 100.00000000 99.99 0.00000000 0.000000000000 8.161 0 jxl:d0:7 1084 1062487 7.8368947 1.149 40.994 nan 100.00000000 99.99 0.00000000 0.000000000000 7.837 0 jxl:d0:9 1084 1052224 7.7611949 0.234 37.039 nan 100.00000000 99.99 0.00000000 0.000000000000 7.761 0 ```

But when I was doing testing on my old cpu my experience is that for lossless e3 and above was all the same speed

My old CPU decoded all effort levels at the same speed. Except the first two.

Idk if it being old has something to do with that

Pre haswell

We had similar hardware dependant results for the faster deciding PR. Sometimes making FD3 faster than FD4. The same might be happening for e3

I'll run a test too when I'm home. <@794205442175402004> if you can upload the image and send the command you ran, we can make a direct comparison

`benchmark_xl --input=001.png --codec=jxl:d0:1,jxl:d0:2,jxl:d0:3,jxl:d0:4,jxl:d0:7,jxl:d0:9 --encode_reps=5 --decode_reps=30 --num_threads 0`

lol. most informed tech journalist?

this is only a reasonable expectation when converting from a *lossless* input to a *lossless* output (ie png->lossless webp/jxl). lossy to lossless never made sense, only jxl's reversible transcoding exists at all for media content afaik (nothing for video or audio)

What version was that? I'm getting quite different results, particularly for e3...

yeah but people generally aren't cognizant of that fact

Some recent git version, didn't check

Well, this is what a build from the 28th of March gave me. Faster than usual because of clang ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ---------------------------------------------------------------------------------------------------------------------------------------- jxl:d0:1 1084 1380528 10.1827623 212.832 75.570 nan 100.00000000 99.99 0.00000000 0.000000000000 10.183 0 jxl:d0:2 1084 1272032 9.3824968 18.957 75.326 nan 100.00000000 99.99 0.00000000 0.000000000000 9.382 0 jxl:d0:3 1084 1120295 8.2632860 15.972 45.585 nan 100.00000000 99.99 0.00000000 0.000000000000 8.263 0 jxl:d0:4 1084 1106408 8.1608556 2.499 42.932 nan 100.00000000 99.99 0.00000000 0.000000000000 8.161 0 jxl:d0:7 1084 1064685 7.8531071 0.557 33.294 nan 100.00000000 99.99 0.00000000 0.000000000000 7.853 0 jxl:d0:9 1084 1050079 7.7453734 0.085 31.107 nan 100.00000000 99.99 0.00000000 0.000000000000 7.745 0 ```

Using a build from a week ago. Effort 1 encode is so slow because this is from Github, so no clang ``` Encoding kPixels Bytes BPP E MP/s D MP/s Max norm SSIMULACRA2 PSNR pnorm BPP*pnorm QABPP Bugs ---------------------------------------------------------------------------------------------------------------------------------------- jxl:d0:1 1084 1380528 10.1827623 95.371 67.659 -nan(ind) 100.00000000 99.99 0.00000000 0.000000000000 10.183 0 jxl:d0:2 1084 1272028 9.3824673 17.253 69.709 -nan(ind) 100.00000000 99.99 0.00000000 0.000000000000 9.382 0 jxl:d0:3 1084 1120289 8.2632417 13.716 35.423 -nan(ind) 100.00000000 99.99 0.00000000 0.000000000000 8.263 0 jxl:d0:4 1084 1106561 8.1619841 1.918 31.634 -nan(ind) 100.00000000 99.99 0.00000000 0.000000000000 8.162 0 jxl:d0:7 1084 1062571 7.8375143 0.447 24.742 -nan(ind) 100.00000000 99.99 0.00000000 0.000000000000 7.838 0 jxl:d0:9 1084 1052308 7.7618145 0.100 22.359 -nan(ind) 100.00000000 99.99 0.00000000 0.000000000000 7.762 0 ``` So Weighted seems very dependant on CPU architecture

> It takes over half a second for my machine to load f42-NIGHT_frompng_q100.jxl into a GdkPixbuf.Pixbuf, more than 3× as long as it takes to load the PNG or JPG versions! That’s an awfully stiff performance penalty to pay just for a 50% smaller file. This is very slow! What's up with that?

``` $ time djxl f42-01-night.jxl --disable_output JPEG XL decoder v0.12.0 6bd5a2ce [_AVX2_] Decoded to pixels. 4032 x 3024, 68.130 MP/s [68.13, 68.13], , 1 reps, 8 threads. real 0m0.190s user 0m1.361s sys 0m0.040s ```

it has an alpha channel too which is a bit strange

also this is strange

``` $ umbrielpng -v night.png PNG signature found: night.png Chunk: IHDR, Size: 25, Offset: 8, CRC32: c0f5cea0 Chunk: iCCP, Size: 8729, Offset: 33, CRC32: 0164f360 Chunk: IDAT, Size: 8204, Offset: 8762, CRC32: 71bbb7ff Chunk: 536 more IDAT chunks Chunk: IEND, Size: 12, Offset: 4407155, CRC32: ae426082 Size: 4032x3024, Color: 8-bit RGB + Alpha ICC Profile Length: 9080 ICC profile represents a non-sRGB profile with sRGB primaries iCCP: wp: 34570, 35853, r: 64843, 33086, g: 32117, 59787, b: 15589, 6605 ```

hm, libjxl detects it as an sRGB profile

huh

my own code is lacking then

displaycal says it's a 4096-entry curve, I wonder if that means it's a LUT

could be a very inefficient sRGB profile. 9080 bytes is kind of silly to just represent sRGB.

avoiding trivial alpha is a simple way to get some decode speedup

the question was more "why does my code not detect it as sRGB but libjxl does" but upon inspecting, it it uses a 4096-entry LUT for rTRC/gTRC/bTRC

and my code only looks at `para`, not `curv` LUTs

and libjxl probably handles the `curv` case

libjxl does handle tabled transfer curves and checks if it's close enough to the parametric curve, yes

so that's mystery is solved, but it's got a trivial (i.e. fully opaque) alpha channel

I'm not sure what's more worrying, not encoding it properly to a JXL, or the original PNGs for distribution not being optimized themselves

the `.src.rpm` contains a lossless JXL

I just decoded it to `night.png` so I could inspect it

ideally they should strip the trivial alpha channel though

yeah they should — it's a pity we cannot make libjxl do it automatically, since that would break layered images with an opaque background layer (which is a pretty common case for layered images) and animations that start with an opaque frame.

trivial alpha doesn't cost much in terms of compression, but it does cost quite a bit in terms of decode speed. Maybe we could do something clever in the decoder to detect this case and avoid allocating buffers that will only store trivial alpha, but that's probably not so easy to do...

I was exploring how to minimize alpha impact a few weeks ago. Trying squeeze, different group size, predictors, ect to find the minimal decode speed impact and density. Since it's empty anyway, more tricks can be used

I think for the coding itself, probably best is to use an empty subtree for the alpha channel with a leaf node that represents `- Set 255`, and then a decoder fast path that detects this case and does a `memset`. But some of the decode speed impact is also coming from the extra buffer (first an int32 one, which then gets converted to a float32 one, and then to an interleaved RGBA buffer with whatever sample type the application requests).

AFAIK Oxide has a single/no predictor fastpath while libjxl doesn't. Could be a speedup for many cases and open new avenues for faster decoding

you'd probably have to both check the entropy stream for one-symbol and also check the MA tree

of course it wouldn't catch all scenarios but it could be a fast-path

Found it https://github.com/libjxl/libjxl/issues/1097

Seems like at some point it became singlethreaded

https://cloudinary.com/labs/aic-3-and-hdr

uh oh, confidence intervals

my nemeses

the windmills to my Don Quixotte

What's wrong with confidence intervals? Assuming you interpret them correctly I think they do convey useful information.

sadly not https://link.springer.com/article/10.3758/s13423-015-0947-8

> The benefits that modern proponents see CIs as having are considerations outside of confidence interval theory; hence, if used in the way CI proponents suggest, CIs can provide severely misleading inferences. For many CIs, proponents have not actually explored whether the CI supports reasonable inferences or not. For this reason, we believe that appeal to CI theory is redundant in the best cases, when inferences can be justified outside CI theory, and unwise in the worst cases, when they cannot. > […] > Once one has collected data and computed a confidence interval, how does one then interpret the interval? The answer is quite straightforward: one does not – at least not within confidence interval theory. [8] As Neyman and others pointed out repeatedly, and as we have shown, confidence limits cannot be interpreted as anything besides the result of a procedure that will contain the true value in a fixed proportion of samples. Unless an interpretation of the interval can be specifically justified by some _other_ theory of inference, confidence intervals must remain uninterpreted, lest one make arbitrary inferences or inferences that are contradicted by the data.

> Bayesian credible intervals differ from frequentist confidence intervals by two major aspects: > > - credible intervals are intervals whose values have a (posterior) probability density, representing the plausibility that the parameter has those values, whereas confidence intervals regard the population parameter as fixed and therefore not the object of probability. Within confidence intervals, confidence refers to the randomness of the very confidence interval under repeated trials, whereas credible intervals analyse the uncertainty of the target parameter given the data at hand. > - credible intervals and confidence intervals treat nuisance parameters in radically different ways. (https://en.wikipedia.org/wiki/Credible_interval#Contrasts_with_confidence_interval)

In an application like this, it is reasonable to assume the population parameter (i.e. the 'real' JND value you would get hypothetically by getting pairwise comparison responses from the entire world population) is indeed fixed: for every distorted image, the actual JND distance to the source image in principle has a fixed value and is not the object of probability. So I think that in this particular application, confidence intervals coincide with credible intervals...

Bayesians also regard the parameter as fixed, just unknown

and they allow themselves to use probability to express that uncertainty

frequentists don’t, so they come up with this sort of workaround where they answer a different question than the one they really would like to have answered

p-values: instead of “probability that the hypothesis is true, given the data” (nonsensical for a frequentist: either the hypothesis is true or it isn’t), compute “frequency at which we would obtain data that extreme, given that the null hypothesis is true” confidence intervals: instead of an interval such that the true parameter has a given probability of being in the interval (nonsensical for a frequentist if both the interval and the parameter are fixed), come up with a method such that in repeated sampling, a given proportion of samples will lead to the creation of an interval that encompasses the true parameter; such intervals are called “confidence intervals” by virtue of how they were created but the individual intervals are not intrinsically imbued with any property whatsoever

https://sami.boo/jaynes/whats-wrong-with-bayesian-methods/#:~:text=For%20decades%20Bayesians,to%20be%20made%2E > For decades Bayesians have been accused of “supposing that an unknown parameter is a random variable”; and we have denied, hundreds of times and with increasing vehemence, that we are making any such assumption. We have been unable to comprehend why our denials have no effect, and that charge continues to be made.

Right. So it generally makes more sense to consider credible intervals (an interval such that the probability that the real value is within the interval is N%) than to consider confidence intervals (an interval that is constructed in a way that has a N% probability of being an interval that contains the real value).

I am at least of that opinion 😄

https://sami.boo/jaynes/confidence-intervals-vs-bayesian-intervals/ has a couple of examples where they might diverge (I especially like the truncated exponential)

Question is how different these intervals are in this case (confidence interval computed by bootstrapping; parameter estimation procedure based on maximum likelihood estimation of a JND scale according to Thurstonian Case V). It may very well boil down to the same thing. I do agree though that it makes more sense to talk about credible intervals instead of confidence intervals; the only reason why confidence intervals were computed is that "this is what is usually done in the literature" but that's of course a bad argument — there are plenty of examples of "tradition" being just wrong.

The long paper on JXL is publicly available now: https://arxiv.org/abs/2506.05987