The case for JPEG XL | Hacker News Reader

The case for JPEG XL

cloudinary.com

390 pointsKyza209 comments

Beautifully written article -- I couldn't agree more. From my personal point of view the biggest impact are:

1) e-commerce textures such as cloths are more faitfully represented -- more trust in e-commerce, more revenue

2) more equity for selfies, people-of-color skin is better represented in JPEG XL, selfies in general look more people like with less smoothing of skin performed at compression stage -- I'm a great friend of the idea that filtering should not be built into the compression so that all kinds of images can be transmitted

3) more compression, faster and cheaper to load

4) better progression -- unlike I believe AVIF does, JPEG XL progression does not impose more decoding cost for sequential, progression does not make compression density worse

5) thermal camera support -- I believe thermal cameras have huge ecological and cost optimization opportunities and more phones should have thermal cameras in them to facilitate the shift away from fossil fuels

6) small images -- thumbnails and sprites etc. do not necessarily need spriting with JPEG XL. That is a nice increase in system level simplicity. JPEG XL overhead is about 10-20 bytes whereas AVIF overhead seems to be 600 bytes or so.

7) 'it just works, no surprises' -- the worst case image quality degradation in any quality setting are much less severe and much less common than in other formats

> people-of-color skin is better represented in JPEG XL

wait what? What is this woodoo and why it itsn't the case for other image formats in which encodings color in RGB?

Preface: It's difficult to write about stuff like this and I know reading it back to myself after will leave me wanting to redraft it 5 times over but it's 1am already. But, if this post is wrong/incorrect or is missing other factors that are too important to leave out then please let me know and I'll amend or even delete it. My focus is on the technical side of things. So anyway:

> why it itsn't the case for other image formats in which encodings color in RGB?

The term "RGB" doesn't mean anything w.r.t. gamut, gamma, dynamic-range, nor how necessarily non-linear transformations between color-spaces are performed. But all that's irrelevant: JPEG'S colour support is actually quite fine (...if you don't mind chroma subsampling), whereas the problem here relates to how JPEG decides what part of the image are important for high-quality preservation (more bits, more quality) than other areas (less bits, less quality).

Obligatory ADHD relevant-yet-irrelevant diversion: this excellent (fun and interactive!) article about how JPEG works: https://parametric.press/issue-01/unraveling-the-jpeg/

(Caution: incoming egregious oversimplification of JPEG):

Now, just imagine a RAW/DNG photo of the sky with some well-defined cumulus clouds in, and another RAW/DNG photo of equal pixel dimensions and bit-depth (so if they were *.bmp files they'd have identical size), except the second photo shows only a grey overcast sky (i.e. the sky is just one giant miserable old grey duvet that needs washing). Now, the _information-theoretic_ content of the cumulus clouds photo is higher than the overcast clouds photo; the clearly-defined edges of the cumulus clouds are considered "high-frequency" data while the low-constrast bulbous gradients that make-up the overcast photo are considered "low-frequency" data, and less overall information is required to reconstruct or represent that overcast sky compared to the cumulus sky.

This relates to JPEG because JPEG isn't simply a single "JPEG algorithm", it's actually a sequence (or pipeline?) of completely different algorithms that each operate on the previous algorithm's output. The specific step that matters here is the part of JPEG that was designed with the knowledge that human vision perception doesn't need any high-frequency data in a scene where the subject is largely low-frequency data (i.e. we don't need a JPEG to preserve fine details in overcast clouds to correctly interpret a photo of overcast clouds, whereas contrarywise we do need JPEG to preserve fine-details that make-up the high-constrast edges between cumulus clouds and the blue sky behind them, otherwise we might think it's some other cloud formation with less well-defined edges (Altrostatus? Cirrostatus? Cirrus? I'm not a meteorologist - just someone on the spectrum using abusing analogies).

So my point so-far is that JPEG looks for and preserves the details in areas of images (where high-constrast data is) while disregarding high-frequency data in an overall low-frequency scene where it thinks those details don't matter to us humans with our weird-to-a-computer visual perception system. I imagine by now I've made JPEG sound like a very effective image compression algorithm (well, it is...) - so where's the problem?

...well, consider that when a person has a low-level of melanin in their skin they will feature areas of high-contrast on their faces: their skin's canvas is light - while facial-features like folds, creases, crows' legs, varicose veins, spots, etc, are like the hard-edges of those cumulous clouds from earlier: the original (pre-compression) image data will feature a relatively high image constrast where those features lie, and JPEG will try to preserve the details of that constrast by using more bits. So that's neat: JPEG tries to ensure that the parts of us that of us that are detailed remain detailed after compression.

...but what if a person's face is naturally less...contrast-y? That's the problem: when a person simply has darker skin their faces will feature less contrast between the skin-parts of their face compared to the features of their face - as caught by a camera. So if a simplistic JPEG compressor is being run against a United Colors of Benetton coffee-table book or stills taken from the end of a certain Michael Jackson music video that I'm particularly fond of[3] then we will, as you can imagine, unfortunately, see the JPEG image files of people with darker skin will feature less definition and detail of their faces compared to the photos of people with lighter-skin, simply due to how areas of higher, and lower, contrast are _mechanically_ processed by JPEG.

...which means that sloppily applying JPEG[1] to photos of everyone might work great for people who have faces-with-naturally-high-contrast/high-frequency-information on them - but not-so-great for everyone else - and I think we can agree hat we can improve on that.

-----------

Confounding things, the distribution of melanin in the JPEG development working group was not representative of the general population in the US at the time[5], let alone the rest of the world, which in-practice meant that less thought (if any) was paid to JPEG's stock handling of people with lower overall skin feature contrast (i.e. black people) - though no malice or ill-will or anything of the sort is required: like all of us (I assume...) they probably thought "these photographs of me (or people who generally look like me) processed by JPEG are good enough, it's been a long week, let's ship it and go for a pint" - without realising or appreciating that it wasn't "good enough" for large chunks of the population. At least, I hope that's the explanation... (and given Hanlon's Razor too).

The situation can be compared to the... uh... colourful stories about the history of Kodak's colour film, its shortcomings, and the social-consequences thereof[2]. Or for something more recent: the misbehaving face-detecting webcams of the last decade that lead HP to make a certain public statement[3].

-----------

[1] I say carelesslessly because lots of tooling for JPEG, especially at the pro-level (think: Photoshop) gives you a lot of control over how much information-loss is allowed for each macroblock (e.g. Photohop's Save-for-Web dialog (the old, good one, not the new dumbed-down one) lets you use its own paintbrush tool to mask areas that should lose fewer bits (i.e. higher-quality) even if the JPEG compressor doesn't think there's much value in that part of the image. MSPaint, on the other hand, does not.

[2] https://www.nytimes.com/2019/04/25/lens/sarah-lewis-racial-b...

[3] https://www.reuters.com/article/urnidgns852573c4006938800025...

[4] https://www.youtube.com/watch?v=F2AitTPI5U0

[5] I would like to mention that there was at least something for gender representation: the co-inventor of JPEG was a woman (no, I'm not referring to Lena.jpg) - Joan L. Mitchell, who sadly passed-away relatively young a few years ago: https://en.wikipedia.org/wiki/Joan_L._Mitchell

There’s a Twitter thread by a JPEG XL dev who tries to explain some of this in terms of the XYB color space giving more bits to dark tones:

https://mobile.twitter.com/jonsneyers/status/155021585930558...

But I’m not clear if this was a design goal of JPEG XL, or a theoretical side-benefit, or something you would need an HDR screen to appreciate (I couldn’t tell the difference in any of the example images, but those may have been processed by Twitter).

In this case I would say that regardless of intent (which may still be important) we should go for the better image format if we have the option. Like, to take the historical example mentioned in the NYT article linked above, this is obviously bad:

> Concordia University professor Lorna Roth’s research has shown that it took complaints from corporate furniture and chocolate manufacturers in the 1960s and 1970s for Kodak to start to fix color photography’s bias.

.. but without excusing any of that, black people were still better off with the newer films.

Similarly, regardless of the intent of the JXL design, if it is the more "inclusive" tech then that speaks in favor of it.

Also, the difference in the example images requires you to look actively look for JPG artifacts. That's something that usually only codec developers and people who work with images for their day job do. Almost everyone else subconsciously does the opposite: they learn how to "look past" the compression artifacts. But speaking as someone who did spend a lot of time trying to optimize JPG sizes for a short while in his life there is definitely a difference.

The difference is hard to see when compressing an image once, but keep in mind that we live in a world where images go through lossy recompression dozens of times, causing the "needs more JPEG" meme[0][1] to live on even when it should be a thing of the past. If your image is, say, 5% more visually lossy for black people that adds up.

[0] https://knowyourmeme.com/memes/needs-more-jpeg

[1] http://needsmorejpeg.com/

Also not sure if this is a Twitter issue (wait, another reason not to use twitter? So why do people keep using it for something it’s bad at? /rant), but I got a different result.

I can clearly see the differences between the encodings (I shuffled the images and sorted them by perceived quality), and I disagree that JXL looks better / is less racist. For both sides, the AVIF version looks significantly better, but especially for the black woman. The white woman already has fewer visible details that can be lost, the black woman has more, and JXL just smoothes those over, making it look like someone used the smudge tool (in general, but it’s especially bad here [0]).

So going from this example, I’d say AVIF wins by quite some margin.

[0]: https://i.imgur.com/2WU6iKe.png

It was probably a bad idea to put such examples on twitter, since twitter recompression is quite aggressive and makes a big difference.

I don't have the original decoded images nearby but it is best to do these kinds of comparisons without any recompression.

I’d happily look at them again in their actual versions

Besides that jokes you can make at that tweet in how it claims a image codec can be racist. If you know how to limit the image quality range in AVIF (and how to reduce smoothing which can be done), you can get images that have dark areas that are near to that of JPEG-XL.

I have been able to (by both reducing the quality range and turning smoothing off) to get much better results on a high contrast image with most of its details in darker, having far-more details in those dark area with AVIF than JPEG-XL (not small differences either as you could see brick work that was destroyed by compression artifacts in JPEG-XL).

libavif default settings suck.

Can you share the settings that have worked well for high contrast, darker images? I agree the default settings are not great.

Why do you call this “woo” pejoratively right off the bat before admitting you don’t know?

I suppose using a term that colloquially means "black magic" might be a little (skin) tone deaf in this context, but I think it was intended as a positive thing. As in "what kind of magic is JPEG XL using to be better, and what is everyone else doing wrong?"

I admit the wording is kind of ambiguous though

Some of it relates to the modeling of spontaneous excitation bias of opsin molecule releasing their energy in the retina. These are modeled in the compression curve in JPEG XL by a bias before the compression non-linearity, whereas other codecs don't have that bias unless they use sRGB -- sRGB has modeled the bias as a short linear slope, but compresses in wrong directions (RGB) in the color space, not LMS. In JPEG XL, the compression curves happen in the direction of LMS reception directions, not in RGB, that makes reds, browns, oranges, purple colors a lot more uniform in quantization. Finally, more emphasis was spend with visual masking in JPEG XL, to avoid blurring in 'fragile' textures even if they are in the same compression block with sharp edges.

Hi Jyrki, this is all very interesting. A couple questions for you, while you’re in this thread:

- where is the best documentation for the Butteraugli metric? I’ve found it quite difficult to find a high-level rationale/design notes for the metric.

- I also understand that JXL doesn’t try to explicitly optimize against Butteraugli distance unless you invoke the higher effort levels, and then, it uses a slightly different function than the original Butteraugli distance - is that correct?

- One q about the distance parameter -d; if I pass -d 1 -E x for some x, I’m asking for “an image with at most Butteraugli distance 1”, and if I pick another effort level higher than x, am I asking it to introduce a little bit more loss, so that the Butteraugli distance is likely to increase? Ie is the distance parameter more of an “upper bound for acceptable loss”

- I’ve seen Butteraugli values quoted for different “norms/p-norms” - which one do I use?

- How do I learn more about these colorspace transfer functions?

Thanks again for your awesome work!

1) Butteraugli

Butteraugli is largerly a 'learned' metric, just very small with its ~200 parameters. I implemented possible components and tuned them and their interactions using methods similar to machine learning.

Describing it to humans should be possible, but going all the way is going to be the same as describing DNNs.

SSIMULACRA 2 is taking the same approach and getting far better results than a previous effort SSIMULACRA.

2) butteraugli distance invoked in the higher effort levels

JXL heuristics are optimized to give good butteraugli scores. These heuristics are mostly used at speeds 6 and 7.

Speed 8 and 9 no longer trust solely on the heuristics, but they try to optimize a constant butteraugli score. It is important to note that they don't do RD-optimization, so they are quite bad at lower quality -- they will drive the quality bad no matter what. There is a hard limit for not reducing the quality too much in relation to the heuristics at speeds 6 and 7, but it is not RD optimization. Small savings can lead to large degradations. This is ok with near visually lossless (quality 90+), but not good for low quality (< 50).

Butteraugli has slightly evolved through the times, the latest version is available in libjxl and used by cjxl at effort 8 and 9.

3) -d 1 “an image with at most Butteraugli distance 1” ?

It used to work that way, but there was some inflation of this concept, and often the maximum score is twice the asked value. Ideally the maximum should be the given value, but it is very expensive to guarantee. In guetzli we have such guarantees, but it runs 1000x slower.

4) p-norm

usual metrics (SSIM, PSNR, VMAF) aggregate error over the image to a single number using the 2nd norm

we use a higher norm, and actually a combination of norms. If you ask for a 3rd norm, it is an equal combination of 3rd, 6th and 12th norm. Using higher norms puts more emphasis on large errors somewhere than 2nd norm.

The better the quality in image compression, best human rater correlations can be found in higher norms. 3rd norm is a good allrounder, I'd usually use 6th norm myself. A lower norm can be better for automated optimization since the cost function will have less wrinkles.

5) colorspace

we don't have a good write up other than possibly the JPEG XL spec. there is a javascript implementation of xyb here: https://gist.github.com/mattdesl/c0ad8d54b3491c7fd39e222e698...

Please consider joining the JPEG XL discord. I'm available for guiding you to learn more if you like.

Awesome, thank you!

Could you elaborate on 5) thermal camera support? How thermal camera could replace normal camera (this only capture infrared light?)? Why thermal camera are more ecological-friendly?

It would not replace the existing cameras. A thermal camera is a great tool for energy conservation: you can find misbehaving appliances consuming too much electricity idling, compare waste of different appliances, heat leaks at home, find hotspots in devices you maintain (say, a badly connected cable can offer extra resistance and become hot).

Though I don't think thermal cameras will be user affordable for a long while.

There are already cheap (ish) add-on cameras for Android and iOS. For example my review of https://shkspr.mobi/blog/2021/10/gadget-review-seek-infrared...

There are a bunch of Android phones which already have this tech built in. Some are high end, but a surprising number of mid-range devices as well.

I picked up a basic one for about $60 on aliexpress. It's good enough to find heat leaks at home, but only barely, and to get usable results I had to turn the home heating to maximum (to increase the thermal contrast).

The ones that let you just walk into a house and immediately see cold areas cost more like $800.

Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all.

For example, I remember reading somewhere that there are people looking at whether or not it makes sense to convert all of the existing JPEGs to JPEG XL on their servers for storage, then reconstruct the JPEG when needed. If so, then there is a niche where it can find adoption even if browsers don't support it yet. It also looks like it might find a use for medical and scientific imaging.

What I personally really would like to know is if it would be possible to losslessly recompress the RAW files from my camera. It looks like it should support everything required, and the claim that it "is the first serious candidate to become a universal image format that “works across the workflow”, in the sense that it is suitable for the lifecycle of a digital image, from capture and authoring to interchange, archival, and delivery" kind of implies that it is, but I haven't seen anyone say it out loud yet.

Because I must say: DNG is really slow and clunky to work with, and I bet has terrible compression on top of that.

What if Google demand every Android devices to support AVIF and not JPEG XL?

This isn't a fight about whether something is technically superior, it is about marketing, cult and ideology. It wont be long before major force of AOM supporters arrives with new PR points to fight back.

> What if Google demand every Android devices to support AVIF and not JPEG XL?

Has there ever been a case when a company has demanded a device not support a codec that wasn't a patent dispute? And what does it mean for a device not to support an image format? Almost all image decoding is done in software.

This seems like an unfounded concern.

I wouldn't be surprised if a WASM-based polyfill emerges soon enough

> Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all.

Ah, like how Chrome delayed APNG so much that there was a dedicated extension for it? (https://github.com/davidmz/apng-chrome) Sadly the Chrome extension page was removed around June (I assume it's more of cleaning up obsolete extensions rather than something nefarious) but I have recovered its description here:

Support for animated PNG images in Google Chrome browser.

Chrome 59 now have native support of APNG, so you do not need this extension anymore. Goodbye, it was an interesting 6 years!

About APNG format: http://en.wikipedia.org/wiki/APNG

This extension animates IMG elements. Also it animates background images/list style images from css styles (div style="…"), but CSS images support may be incomplete.

You can prevent this extension from work on specific domains (Black List mode, default) or allowed it to work ONLY on specific domains (White List mode).

Source code is available on GitHub: https://github.com/davidmz/apng-chrome

WARNING! CAPTCHA may not work on some sites because of this expansion (it is not always possible to correctly detect captcha images). If captcha does not work on some site, just (temporarily) disable the extension on the it.

---------------------------------- Latest notable changes:

3.1.0 (2017-06-07) Chrome 59 now have native support of APNG, so you do not need this extension anymore. Goodbye, it was an interesting 6 years!

3.0.0 (2016-09-12) IT WORKS AGAIN!!!

In Chrome 48 (Feb 2016) Google turns off getCSSCanvasContext API. It was the critical part of extension, and within six months the Chrome has no technologies to animate images. Fortunately, it has changed recently and now this extension works again.

In version 3 algorithm was changed from canvas animation to APNG → animated WebP conversion.

2.1.4 (2014-11-28) Fixed some incorrect captcha images.

2.1.2 (2014-01-15) Better Reddit support.

2.1.0 (2014-01-12) Partial Reddit emotes support.

2.0.7 (2014-01-12) Redirects support.

2.0.4 (2013-05-26) Ext. was broken because of bug 238071 in Chrome 27. Fixed it.

2.0.3 (2013-03-19) Fixed bug with images with 'auto' height/width in style.

2.0.0 (2012-10-01) Most of the code rewritten. CSS background/list animations is turned off (except inline styles). Fixed slow work in some sites (g+, gmail and so on).

0.7.1 (2012-04-07) animated-gif-captcha images support (strange captchas of wedge.org)

0.7.0 (2011-08-03) fix for facepunch.com (perhaps the only site where this extension is actually used:))

0.6.9 (2011-07-14) data: url support, fixes for google maps images

0.6.8 (2011-07-09) fixed bug with CAPTCHA images

0.6.7 (2011-07-03) support for list-style-images

0.6.6 (2011-06-30) tracking changes in image's 'src'

0.6.2 (2011-06-30) background-image animation for internal and external CSS

>> Personally, even if Chrome goes ahead with removing support I hope JPEG XL will "win" in the long run by being an attractive "universal" format for all other use-cases for image compression. So in other words: that it finds an ecosystem elsewhere, slowly takes over outside of the browsers, and then the browsers will adopt it after all.

> Ah, like how Chrome delayed APNG so much that there was a dedicated extension for it?

No? APNG never caught on like described in the GP.

> A unique feature of JPEG XL is that it is possible to recompress existing JPEG images (of which there are a lot out there!) to a JPEG XL file that is on average about 20% smaller, without introducing any loss. In fact, the bit-exact same JPEG file can be reconstructed from the JPEG XL file.

I wasn't aware of this and this is actually crazy, and freaking brilliant from a migration point of view. I wonder how that was achieved. I didn't care so much about JPEG XL, now thanks to Google derping I want it everywhere.

The journey to JPEG XL started with guetzli (which started with butteraugli to guide loss in JPEG encoding) and brunsli. Guetzli is a great (but very very slow) JPEG encoder. Brunsli is a classic JPEG1 recompressor. We mixed those and got the first version of PIK. We added some forced format-level progression, adaptive quantization, filtering, larger DCTs, integerated HUIF as lossless/super-progressive coder, and adopted some WebP lossless features into HUIF (Select, 2d-LZ77, entropy clustering).

The final version still had brunsli-like features and we surfaced those as a JPEG recompression system.

As a swiss person, all these names of common christmas cookies here are making me hungry.

others are real Swiss cookies, but butteraugli is a made up Pseudo-Swiss word based on voisilmäpulla, a Finnish sweet bread

Interesting... Butteräugli does sound like a swiss cookie though. I can even imagine what it looks like based on the name.

I had regarded the lossless re-compression as an interesting parlor trick, but I get it now.

Coincidentally today I was testing how much we can shrink our archived videos. We have lots of videos recorded with the Intel hardware encoder in H264, so not even the state of the art of H264. I figured: pop it into handbrake, change the codec to H265 (X.265), and boom 30%+ reduction. No, the H265 file got 3X larger. Well the default handbrake quality might be higher than the original video, and now it's going to some spend bits trying to encode the artifacts in the source video, while adding artifacts of its own. Sure you can find a happy medium where the quality won't be too much worse and you reduce the file size in most cases. But it sure would be nice to be able to losslessly recompress those videos!

> But it sure would be nice to be able to losslessly recompress those videos!

And you highlight a crucial thing here: being able to do so without fiddling with parameters for hours to fine-tune it or even just finding something that works at all.

Most online video uses crazily overspecified h.264 bit rates for low complexity content. It's often possible to get 1080p well under 2 Mbit/s with little to no quality loss, and even lower by using 2 pass encoding where that's available. I'm not sure how things are with h.265 in a production setting, but at least for home use it seems to have much of the same flexibility

Do you work for Amazon Video or Netflix?

I get nervous when I see motion artefacts on netflix. This means I'm pretty much always nervous when watching netflix. I use a 1 gbps home connection and pay for the most expensive option netflix has. I'd like to think that the whole concept of motion frames based prediction will disappear in future videos.

Motion JPEG XL would be like in the movies where they have Motion JPEG 2000, but ~35-40 % more dense. We could add usual delta frames without motion without compromising quality criteria. This would get us in the 0.3 BPP range.

4k at 30 Hz would be 3840 x 2160 x 24 x 0.3 should need about 60 mbps (~ 7.5 MB/s), still doable for home internet speeds and would be visually lossless, a better experience than home movie streaming is today. (free startup idea) :-)

60 mbps is easily beyond the limits of many home wifi network setups, and leaves the serving end with capacity for something like 166 users per 10 Gbit port. There are many additional costs to consider beyond the size of the home pipe

I believe this capacity roughly triples every five years -- so when building something for the far future things can look different in bandwidth/quality perspective.

> One final significant benefit of JPEG XL is that it has a broad scope: while it is a great format for web delivery, this is not the only use case it was designed for. JPEG XL can also be used as a capture format, where it can play a role similar to current camera raw formats: high precision, high dynamic range, lossless or minimal lossy compression. It can also be used as an authoring format, supporting named layers, selection masks, multiple alpha channels. It can be used for printing use cases, supporting e.g. CMYK and spot colors. It can be used for medical or scientific applications, supporting high-precision lossless compression and multispectral imaging. And so on. It is a general-purpose format that covers many different use cases for digital imaging.

So that's all impressive and useful and probably quite good, but my first reaction is that sinking feeling from being faced with unexpected complexity. Is the JXL format a nightmare internally? Is it a nightmare to use the library as an inexperienced app developer? Do you need to care about those unusual features if you just want to display an image? I expect that it's all fine, since what little I've heard has been good. If so, kudos to the designers because that's an ambitious feature list. It feels uncommon for a format of any kind to set out to be all things to all people and succeed.

Disclaimer: I co-chaired the JPEG XL working group; opinions are my own.

The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf, 101 for https://www.iso.org/standard/77977.html. Or code sizes: 6.6 MB uncompressed for libjxl (encoder+decoder), 9.5 MB for dav1d (decoder only) plus 34.2 MB for SVT-AV1 (encoder).

Features such as spot colors are mostly just a matter of understanding a wide range of requirements; this particular one just boils down to an extra image layer.

> Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf, 101 for https://www.iso.org/standard/77977.html.

And here we immediately see one important difference between them: the first link is to a 681-page PDF, which opens immediately in my browser. The second link is to a place where one can buy access to what it says is a 101-page PDF, after paying more money than it would cost to buy a basic laptop.

...After seeing this, I no longer care if JXL lives or dies.

> after paying more money than it would cost to buy a basic laptop

No need to be imprecise, unless you are trying to push some agenda. The cost is CHF 198, which is around USD 195.

Yeah, a lot of things cost more than a basic laptop. Last I checked, you can get Chromebooks on the order of $20 or so per machine. That metric isn't useful to anybody.

That's a difference between AOM and ISO: ISO puts specs behind a paywall but anyone interested can participate in the actual standardization process through their national standardization body, AOM makes specs publicly available but participating in the standardization process costs about as much as a nice car. I don't really like either model, but I don't think I particularly prefer AOM's model.

We created avenues for open source / community participation in AOM that did not require people to pay any money. Specifically, Mozilla sponsored the membership of VideoLAN, which in theory anyone could join, and a number of people did and do participate through that organization.

That's good to know, and nice that Mozilla did that!

Is there a "latest draft" standard available legally and for free for wider audiences? C++, also ISO standardized, does this and I believe it has contributed greatly to its adoption and post-C++11 renaissance. See https://en.cppreference.com/w/cpp/links#C.2B.2B_Language_and... . For now, JPEG XL might as well be a proprietary closed format for most hackers here.

Recent drafts do tend to get circulated amongst the image compression community. For wide audiences I don't think this type of document is very readable nor relevant; the number of people who are going to make their own independent implementation is relatively small. In this sense the spec audience is not quite the same as that of a spec for a programming language, which is important not just for compiler implementers but also for programmers in general.

That said, I do hope that ISO will change its policy to put specs behind a paywall.

Any chance of publishing the spec with ECMA in addition to ISO? The C# spec is both an ECMA and an ISO standard, but it started with ECMA.

As one of the authors of the spec, I would be open to also publishing it with another standardization organization that makes specs publicly available, if the legal issues can somehow be sorted out. I think the other spec authors would also be open to that. We certainly have no desire to have a spec that is behind a paywall; that is just the way ISO operates, unfortunately.

JPEG XL format internals are beautiful -- control structures are self-similar and the image coding itself is used to code substructures, similar to WebP lossless.

libjxl C++ implementation is modern high-performance multi-threaded SIMD code, with layering, animation, streaming and progressive features, it can look scary. With some less emphasis on performance it could be written rather elegantly.

I think the solely reason why JPEG XL did not go off is simple: It had no lobby. No large tech company actively promotes it and so, many people hadn't heard of it. Ironically, the deprecation of it in chrome made me aware of it in the first place.

Technically, JPEG XL may be a superior contestant. But from a 'social' point of view? Disastrous, especially considering it already has "JPEG" in it. (To be fair, its also quite young...)

I really hope JPEG XL gets more traction because it seems like a really good successor to the old namesake.

Now imagine that you saw a presentation couple years back with all the nice features that smart people packed in… and here is what it came to, parlor games basically.

Maybe a nimbler PR approach would help, but then we know that standards like websql are shutdown over nothing, even though sqlite eating the world alive…

Personally, the name always turned me off. I saw the option in photoshop when saving files, but my thinking went "jpg bad, jpg XL is a weird name, must be a minor incremental improvement over jpg".

Why would you think "XL" would be minor improvement?

I figured it was marketing speak.

That's fair :)

I don't particularly like the name either, but it already had a name before it existed — that's the way JPEG works, the ones who write the Call for Proposals give it a name, not the ones who actually bring the proposals and design the new codec.

Anyway, I think "jxl" will in practice be the more common way to refer to JPEG XL images, and the full name will at some point become a matter of etymology and trivia questions.

Another argument: JXL actually supports losless compression of RGB bitmaps and cjxl (the JXL reference encoder) actually supports color spaces correctly when converting from PNG unlike Google's WEBP, which only supports losless YUV compression and the conversion from RGB to YUV is not entirely lossless and cwebp (Google's WEBP reference encoder) doesn't support all the ways color spaces can be encoded in PNGs, resulting in washed out images in some cases.

And what could also be an advantage for JXL is animation. WEBP does have animation support implemented in browsers but it came after the freature was enabled and doesn't have a separate mime type so you can't do fallback to .gif without user agent checks. If JXL support either ships with animations enabled or animated JXL gets a separate mime type in browsers it could make it actually useful.

Yeah, if I remember right, when I was converting some high resolution uncompressed TIFF images to lossless HEIF / HEIC on macOS preview, most of them looked off because colour space conversion was happening (I think from RGB to YUV). (Not to mention many actually failed to convert because none of the HEIF / HEVC encoder I tried could handle very large image sizes). I finally opted for JPEG2000 format to archive those images. I've been waiting for JPEG XL for sometime now to be ready - by my rough calculations, I may be able to get an extra 10 GB space by converting these images to JPEG XL, without any quality loss or issues.

WebP lossless is also RGB lossless. I designed it and this was one of the main functional requirements I chose for it.

Particularly, WebP lossless does not use YUV compression. It does (optionally) reduce component correlations by the 'subtract green' transform.

It might be possible to construct an ICC profile in that formalism that would go close to YUV, but that is definitely not supported currently in cwebp.

The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting for good chrome, shouldn't we just fight for more diversity in browserland?

Firefox was slow as hell and resource hungry

Also, the ui doesn’t feel naive at all

No UIs feel native these days, everybody invents their own UI kits.

Somewhat true. Just tried it, yet again. It looks like it improved. I might use it as my social media browser, so it's easier to focus / disable social media and HN on my main browser.

Right click on text, there's no dictionary lookup menu item

The border around input fields look weird

Advertising and branding. Google is a search monopoly, and has (or used to have) the reputation of "we are making high-quality software". We have a web search monopoly, because our search engine is the best, so why not trust us for making the best browser too?

Firefox has no search engine monopoly to advertise and build its brand upon.

> The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind

Reasons why I, a former Firefox promoter switched to Chrome:

1. Speed. Chrome was blazing fast compared to other browser

2. Stability: Chrome could have a tab crash without bringing down your entire browser.

3. Really good developer tools that were superior to Firebug. As a matter of fact, Chrome Dev tools were my gateway drug as I'd use Chrome for work and Firefox for personal browsing, and the gradually shifted entirely to Chrome.

Situation has changed dramatically wrt points 1 and 2 since years, however. As for 3, I'm no web developer so can't comment on this.

The dev tools are really good in Firefox and its browser forks.

One or two devtool features are better in firefox, but when I gave it a good try a year or so back I had the devtools get stuck / crash / fail to find an element that's onscreen moderately often - enough that I'm not keen to use it for work by default.

Chrome is still significantly faster for me on multiple computers. Even now, Firefox can't smoothly scroll though this very page [1] without obvious jitter; no browser should have trouble with that.

[1] https://news.ycombinator.com/item?id=33442281

How is this relevant to this article given that Firefox has never shipped JPEG XL support in a public build? Not even behind an experimental flag like Chrome did.

They did. image.jxl.enabled in about:flags

Warning: this only works in nightly builds of firefox. In stable and beta they have the flag but they're not compiling the code, so it just doesn't work.

It's relevant because there is no doubt that Firefox would not have axed a promising open format despite users asking for it.

It is possible that FF won't continue the work of implementing it if they see no future without the oligarch in the field, but we'll see

Mozilla did not want to ship WebP at all, despite users asking for it, and only added it after too many Chrome-only sites forced them to.

All browser vendors are pretty reluctant to add new codecs, because there's always going to be yet another promising codec to add, but they're left maintaining all of them forever, even after they're not cool and new any more.

I don't think there was ever a good case for WebP, but JPEG XL sounds promising. The problem of course, is the monopoly browser developer made WebP, and the monopoly browser developer sees JPEG XL as a competitor to their in-house format.

That's a bizarre and unfounded accusation. Author of WebP worked on JPEG XL, and Google has shipped AVIF which includes tech from Mozilla, Nokia, and many others.

I consider that WebP lossy was fixed to usable quality level around 2015, five years after the launch. For the first five years it had a tendency to make 4x4 pixel lego-block representations of smooth gradients and lose highly saturated colors.

8-bits per channel and YUV420 only were caused by hurrying it.

With JPEG XL we have the opposing mistake. We had a great format already in 2017, and spent 5 years more for improving it further.

For a while Firefox was slower, and Chrome was quicker. That really was important plus Android/Chrome was a combination as well with the proliferation of the cheap smartphone. A sizeable portions of devs came unto the market with that background, and chrome dev tools had a bit of an edge with a few functionalities.

Firefox never had a monopoly, unless you still count Netscape Navigator in that. IE was big until 2006-08, started dropping off quickly after that, Firefox won a big share in that time, but at some point Chrome just chipped away marketshare for reasons stated above.

I think bundling was a big deal by Google, something Microsoft got punished for, but Google never.

> is why the world has switched over to Chrome leaving Firefox behind

Not all of us have left Firefox behind of course, but we are certainly not what we used to be.

> shouldn't we just fight for more diversity in browserland?

We should; and especially in browser-engine-land. WebKit/Blink are becoming a monopoly..

> The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind

I didn't switch to Chrome. I switched to orher browsers. For me the turning point was when Firefox started deprecating its old GUI and copying more and more the Chrome GUI: no menu, hidden preferencies, messing with the window's titlebar and implementing its own (very small) scrollbars, messing with DNS, etc.

I started using Firefox as my daily browser when the Firefox Photon redesign launched and reluctantly switched to Brave when they removed it. RIP to the best looking default browser skin of all time.

Maybe it's because Chrome does not have a huge memory leak that brings down your system after a few days of uptime.

I use Firefox because Chrome's updater kept trying to sneak past my firewall and one day it succeeded. As soon as it did, I switched. **No.**

I don't like Firefox because of all its issues (including the memory leak), but at least it supports trackpad gestures and overscroll and all that good stuff that Chrome doesn't. And it doesn't keep trying to backdoor my computer using a stupid hard-to-disable updater. One single JSON file and it obeys for good.

For me, the competition there is pretty simple. The browser shouldn't crash.

Until now I used firefox on my home ubuntu box (intel nuc). Yesterday it started crashing, and crashed about 15 times. I downloaded chromium and it didn't yet crash.

Now, I'll probably move to it for home computer browsing, too. Even when I don't agree with their decision on not enabling JPEG XL by default. If there is a browser that has it on by default, then I naturally switch to that instead :-) -- but I'm not aware of such. Perhaps Brave?

>intel nuc

Gemini Lake chip?

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

I switched to Vivaldi (based on Chrome) from Firefox a few months back and am reasonably happy with it. I get far more control over my browsing experience than with Firefox, which keeps removing features that I actually liked and used.

I used Firefox for a long time, starting way back when it was brand-new and IE was the leading browser. I continued using it because they were innovating heavily in the browser space. After they stopped innovating, I kept using it because although Chrome was impressive and fast, they kept nagging you about logging into Google. Now, based on the fact that Mozilla basically seems to just do whatever Chrome does these days, combined with the unnecessary and infuriating UX redesigns, Firefox has no obvious advantages and quite a few drawbacks.

I don't love the fact that Vivaldi is closed-source and based on Chromium but at least I feel like I'm in the driver's seat while I'm using it.

HDR is mentioned only once. Yet this should be the primary case for any new image standard.

I'll repeat a comment I wrote here earlier:

Our camera hardware supports HDR. RAW image formats support HDR. Our display devices support HDR. Videos support HDR. Smartphones can now record in HDR.

All the hardware is there ready for the future. Yet due to (30 year old) software limitations we're still cutting off HDR data when saving our precious memories as JPEG. All whites become #ffffff. The white of paper. The color of Word's document background color.

The gamut of color has expanded and we need image standards to expand with it.

Adobe and Intel seem to share your thinking with HDR driving this generation of image formats.

https://helpx.adobe.com/si/camera-raw/using/hdr-output.html

JPEG XL has HDR always built-in into its modeling, both SDR and HDR images are modeled exactly the same way and give the exactly same visual quality with the same encoding parameters. Compositing SDR and HDR materials does not need conversions between colorspaces -- everything is in absolute color XYB colorspace.

Other codecs (AVIF, HEVC) need a different set of encoding parameters for obtaining the same visual quality when used for SDR or HDR. Compositing SDR and HDR materials necessarily needs color conversions, since they will have different normalizations. Knowing which HDR quality setting corresponds which SDR setting will become additional cognitive load for the users.

From the "Lossless Compression Performance" section of the article:

> JPEG XL can do lossless image compression in a way that beats existing formats (in particular PNG) in all ways: it can be faster to encode, produces smaller files, and more...

Does "in all ways" include any decode (not encode) speed numbers? Such numbers are dependent on the test suite, and I might be holding it wrong, but on my measurements, JPEG XL lossless encodes 10x slower and decodes 12x slower than PNG (the libpng implementation), and decodes 30x slower than PNG (the wuffs implementation). JPEG XL does admittedly win on compression ratio (smaller files), though.

https://github.com/nigeltao/qoir/blob/main/doc/full_benchmar...

Thank you for putting in the effort to benchmark and quantify performance. There is nothing like verifiable numbers to drive a discussion on performance improvements and marketing.

Your benchmark seems to lack options used. JPEG XL has two main knobs for quality and speed, as I've previously mentioned in [1], and the default effort 7 (which is, assuming that you didn't set any other options, presumably used in your benchmark) would definitely prefer compression ratio over compression speed. You will need multiple entries for JPEG XL with varying efforts for a fair compraison.

[1] https://news.ycombinator.com/item?id=33401540

IIUC, the quality knob (not the effort knob) isn't relevant for lossless encoding.

Knobs are also less relevant for lossless decoding, where there's only one correct output for any given input.

In any case, my code (https://github.com/nigeltao/qoir/blob/main/adapter/jxl_adapt...) copy/pastes examples/encode_oneshot.cc from the libjxl repository, plus an additional JxlEncoderSetFrameLossless call.

So I'm using whatever knob values that the libjxl example uses, i.e. the default knob values. If there are better knob values for lossless, let me know.

Just want to mention that modular mode (the encoding technique for lossless mode) does have flags that let you have a bit of loss (by changing a quality flag), though by default what you said is correct, it is fully lossless.

Lossless encoding can be done with various trade-offs between speed and compression density.

At one extreme we have fjxl, see e.g. https://twitter.com/LucaVersari3/status/1485971553892323333?.... This is an extremely fast lossless jxl encoder, which is about 100 times faster than PNG encoding (libpng) and compresses about 10% better.

At the other extreme, there are the slowest settings of the reference encoder libjxl, which are 1000 times slower than libpng but compresses a lot better.

As for decode speed: this depends on whether you consider single-threaded or multi-threaded performance. In single-threaded decode performance, it is hard to beat PNG since it is basically just gunzip. PNG is inherently sequential though (unless you apply trickery at encode time to make parallel decode possible), while JXL is by design decodable in parallel. We are anticipating that in the future, the number of cores available on typical hardware will only grow, so this difference will naturally lead to JXL becoming faster to decode in practice.

The current reference software libjxl is quite optimized for the lossy case, but still has some room for improvement for the lossless case — in particular it does not have fast paths yet for the common case where the full precision of 32-bit per sample is not required.

So in conclusion, I think it is safe to say that JPEG XL beats PNG in all ways.

fjxl is the "JXL_Lossless/f" lines in my full_benchmarks.txt link. It's about mid-table in terms of encode speed. I clocked it at about 10x faster than libpng, not 100x faster.

If you look solely at encode speed, fjxl loses to fpnge (also listed in full_benchmarks.txt) so I'm not convinced yet that JPEG XL beats PNG in all ways.

I believe that Apple have an unofficial PNG extension that facilitates multi-threaded decoding: https://github.com/w3c/PNG-spec/issues/45

Did you compile fjxl with or without SIMD? That makes a big difference.

And yes, fpnge is slightly faster than fjxl but also compresses significantly worse. It is likely that you could make an even faster but slightly worse version of fjxl that would beat fpnge. But I think the speed of fjxl is already good enough in practice.

The problem with PNG extensions for multi-threading is that it only works if you control the encode side too — most existing encoders will not use such an extension. If existing deployments need to be replaced anyway, you can just as well use a new format altogether.

> Did you compile fjxl with or without SIMD?

I had not. Thanks for the tip. Fjxl encoding speed is now about 20x faster than libpng, not 10x, but still mid-table. Decoding speed is unaffected.

https://github.com/nigeltao/qoir/commit/c2fec840

> If existing deployments need to be replaced anyway, you can just as well use a new format altogether.

There's still an operational difference between rolling out multi-threaded PNG versus multi-threaded $OTHER_FORMAT.

At the file format level, MT PNG can be designed to be backwards compatible. Older PNG decoders simply ignore the new non-critical chunk.

At the software level, you can roll out encoders that emit MT-capable PNGs without having to also roll out new decoders everywhere (or 99% everywhere, or 'on all major browsers'). You can roll out new decoders only partially, and those upgraded places enjoy the benefits, but you don't break the decoders you don't control.

Also, in terms of additional code size, upgrading your PNG library from version N to version N+1 is probably smaller than adding a whole new $OTHER_FORMAT library.

PNG is ok if you don't care about the 60 % more bytes to transmit and keep around and legacy is important for you.

If you care about speed or transmission cost, then you try to look elsewhere.

WebP lossless already is quite a big improvement, and JPEG XL gives some more (not yet in decoding speed, though).

I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads.

Anyway, yes, we should improve decode speed — for example, currently every sample value is unnecessarily converted from int to float and then back to int, and obviously that causes some avoidable slowdowns.

I agree that MT PNG does have a gentler transition path than introducing a new format. The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage, which can be hard given how many existing deployments of png there are. Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc.

Also one disadvantage of MT PNG compared to JXL is that it splits the image in stripes, not tiles. For full-image decode, that doesn't matter much, but for region-of-interest (cropped) decode, tiles are a bit more efficient (no need to unnecessarily decode the areas to the left and right of the region of interest).

> I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so,

In case it wasn't clear, the 0.630 fjxl encode speed number in the top level README.md in that commit is after normalization such that QOIR is 1.000. After all, absolute numbers are hardware dependent.

If you look at the doc/full_benchmarks.txt change in the same commit I linked to, fjxl encode speed clocks at 106.48 megapixels per second. It's just that QOIR encode speed clocks at 168.90 megapixels per second (and fpnge at 312.59).

> The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage,

Well, for PNG, Apple have shipped exactly that. It was something they could unilaterally do without e.g. having to get all of the major browser makers on board.

Apple's PNG encoders (i.e iOS dev SDKs) produce multi-thread-friendly PNGs and their decoders (i.e. iOS devices) reap the benefits. And unlike trying to introduce a new but not-backwards-compatible-with-PNG format (JPEG-XL), other PNG decoders can still decode these images. They just don't get the speed benefit.

> Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc.

It's forwards compatible too. Apple's PNG decoder will use MT decode if the PNG image was encoded with MT metadata, but Apple's PNG decoder can still decode arbitrary PNG (using its pre-existing single-thread code path).

And it is better to use Clang, with other compilers libjxl performance can decrease significantly for some reason

Also fjxl has an effort option, with 0 or 1 it will be even faster, but with less compression

Same for libjxl, there are faster efforts 1 and 2, and effort 3 as far as I know works well for photos but not so much for the rest

I believe that density is 100x to 1000x more important for fast experience and computational cost than the near instantaneous decoding speed of common lossless formats.

I agree that compression ratio is the primary metric (but not the only important metric). I just found "[better] in all ways", explicitly calling out encode speed, incongruous with simply ignoring decode speed.

As for which is more important out of encode and decode speed, I would personally rank decode speed higher. For example, app icons on your home screen were encoded once (by the graphic artist) but are decoded zillions of times (by every user every day).

Agree with decode time being more important. There we still can improve.

We have ideas how to make it faster than WebP lossless, but haven't engaged with that yet -- the lossless decoding is already fast enough not to be a blocker.

Also, given how efficient and quality-sure the lossy is, it will become tempting to migrate many of the PNG/GIF/WebP lossless cases to JPEG XL lossy further reducing the priority in JPEG XL lossless. This can be a 4x-5x savings whereas a better lossless is only 10-40 % savings in density.

I'm not really familiar with the space, but the article kind of suggests another reason I could imagine not supporting JPEG XL: if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means?

I don't think having an existing library that all browsers could "just use" is a good argument. That just means that the implementation is the specification, no matter what the official spec says.

Note that I'm not saying that this is a problem or that JPEG XL shouldn't be supported. I just don't know what the real situation is, and this article smelled a little like it might be sweeping some things under the rug. (And for the other other side, the justification in the bug also seemed lacking.) Anyone know more?

There are a few alternative decoder implementations in progress. I believe J40 is the most complete one: https://github.com/lifthrasiir/j40

> if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means?

You have a very good point. In fact I think this is the first time I ever seen such a question, which was also something I wanted to answer by making J40. Of course in the practical standpoint you should just use existing libraries, but I wanted to answer that from the library author's perspective.

I'm happy to report that JPEG XL's design is better than I hoped and it successfully tried to do many things out of a reasonable number of components. This means that library authors can mostly implement those components and they will combine reasonably well. There are still some imperfect edges though. For example JPEG XL splits a full image into multiple tiles to faciliate parallel decoding, and the Table of Contents is used to locate individual tile data. But TOC requires a full entropy coding to decode, so you can't easily determine how many bytes are needed for decoding, say, 1/2 of the full image. Those kind of imperfections are harmless for JPEG XL's main use cases but still something I would definitely fix if I'm even given a chance (not to say that I'm a good person to do so).

I hope Edge and Safari will enable JPEG XL, but not AVIF. AVIF has several disadvantages, for instance, it takes much longer to encode than JPEG XL and it doesn't support progressing decoding.

Google just doesn't like formats created outside their own company. They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

> They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).

This is a common misconception; JPEG XL is jointly created by Cloudinary (which employs the author of FLIP/FUIF) and Google Research Zurich (which previously created PIK, and employs authors of Brotli and WebP lossless format as well) with an official blessing by JPEG (which mostly set the goal for the format). The only difference here is that the authors do not belong to the Chrome team.

Safari has already shipped AVIF support with iOS 16 and macOS Ventura.

Apple is a member of AoM backing AV1/AVIF formats, together with other browser vendors.

Google Brunsli was adopted for JPEG XL.

https://github.com/google/brunsli

https://www.codercto.com/a/103418.html

This may have happened during Steve's era. Who tends to pick the best codec and fight for it.

No under Tim Cook though. They sided with Google already.

This is really sad. I was sincerely hoping for jxl to become a widespread standard. Especially things like formats for 3D materials that have both high but depth color information as well as depth information, we could have a single format that could encode the entire texture easily. Also space-saving storage, etc.

We’re still pretty committed to using jxl as an internal standard for many things.

On one hand numbers do not mean much, but I think that releasing a 1.0 version of official library would at least help with morale and signal some completeness.

I’m sure there are reasons making fresh 0.x releases even after creating a standard format, but it was a bit disappointing after years of waiting, even before this blow by certain browser maker.

libavif is still not at 1.0 (in fact, 0.11.1 at the time of this writing). Having a 1.0 release is good, but not relevant to this matter.

Also libwebp reached 1.0 only about 8 years after it was added to Chrome. So I don't think this is a major criterion.

That said, we are aiming to reach the libjxl 1.0 milestone within a reasonable timeframe, i.e. somewhere in 2023, preferably first half.

And Mozilla waited for libwebp to reach 1.0 before making the plunge to support it in Firefox. One of the main issues was that libwebp was willing and frequently made backwards-incompatible changes to the codec in the 0.x days; Google simply didn't care about breaking images, but Mozilla cared.

Yes, that's a problem when a format is not standardized but controlled by a single entity. JPEG XL is standardized though, and backwards-incompatible changes are essentially impossible.

There really is no good justification for this decision.

Perhaps unrelated but Google seems 'business tone deaf'. With every product release the first question on our minds is 'When will it get deprecated?' - and that is a legitimate question. Their support story is not that impressive. They do not seem to have the history/culture/DNA for support that MS or Amazon has. Their best customer is the browser - a customer that does not ask for support, only ads. I think they have prospered and will continue to for some time but they have to get a better non-browser customer support story.

Ad revenue paved a runway so wide that potholes do not bother them. If the revenues keep coming down they will need a shift in attitude (management and developers).

Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it? I barely heard about it at all. Perhaps if Google wants to create developer enthusiasm for some new feature they want to implement, they should first announce they're NOT going to be implementing said feature, then when the inevitable backlash happens, very publicly backtrack.

Google don't need to resort to such tricks when they can just bludgeon everyone to death. Se how they forced support of VP9 and AV1: https://www.protocol.com/youtube-tv-roku-issues

Not to mention WebP, which I guess is the elephant in the room when they say that JPEG XL "does not bring sufficient incremental benefits over existing formats".

And which is very unconvincing in real world use.... It benchmarks well, but "looks" crap. I really wish they had produced something better than that, if that's what we're going to be stuck with. It's sad.

JPEG XL is the other way around: Okeyish/boring in usual PSNR, SSIM, VMAF benchmarks, great in benchmarks with DSSIM, SSIMULACRA2 and Butteraugli, but looks superb to humans.

And it addresses a very, very real use case of recompressing JPEGs without generation loss. Considering that a vast majority of all pictures being taken even today begin their life as JPEGs, that's very relevant.

I mean, WebP is _okay_ but it leaves a lot to be desired, even when it comes to image quality compared to the old 1992 JPEG standard; coupled with mozjpeg making giant leaps to get old-school JPEG file sizes drastically smaller without costing quality, the original file size advantage WebP pitched is not as large of a selling point.

WebP's best quality is that in lossless mode, it usually results in smaller files than PNGs, but given that it was primarily focused at being a lossy format to replace JPEG, with a 16383×16383 size limit[1], color space fixed at YUV 4:2:0 only[2], marginal space savings, no progressive decoding, it comes up short in a number of scenarios. There's also the breadth of legacy JPEG-encoded files without a good transition story to WebP, especially due to most JPEGs in the world not being of YUV 4:2:0 format.

I sound like I'm hating WebP here and I'm not trying to, but my own personal uses for WebP have been squarely in the lossless mode side with a JPEG-encoded thumbnail to accompany it. WebP's primary selling point were file size benefits, but then mozjpeg really not just improved JPEG 1992, but made it a compelling choice to use instead of WebP.

JPEG XL really stands to be the best of everything. No fixed colorspace model, no image size limits, smaller lossy and lossless files than previous formats, progressive decoding, etc. It's a solid win for JPEG XL, especially if browsers start adopting it for production.

[1] Size limit applies to lossy and lossless mode both.

[2] Lossless mode's color space is fixed at 32-bit BGRA only. Same issue, different spec.

I don't personally know if that's true for JPEG XL, but WebP was kind of underwhelming.

I remember all the same conversations happening now on HN, but for WebP back in the day, and Mozilla being really doubtful it was worth the maintenance effort. FF eventually added it... in 2019, and Safari in 2020. Only two years later we're discussing a format that will completely supplant it, but the browsers will have to maintain WebP forever.

Also brotli - not that its a bad format but its weird how quickly it made it into browsers without proving itself first when there have been so many general purpose compression algorithms better than gzip that were just ignored.

Brotli got into browsers quickly because W3C Web Fonts Working Group knew how to collaborate (instead of have the usual infinite quarrels :-D). I am thankful to Vladimir Levantovsky for somehow having created this atmosphere -- and of course to all the working group members.

Previously some engineers tried to bring bzip2 into content encoding, that failed by HTTP/tv-top-boxes interacting. HTTPS getting more common allowed a safer deployment route.

The W3C WG was trying to bring LZMA in, but that was just too slow for all fonts decoding -- it would have not made fonts load faster in all cases.

> Was there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it?

Not sure if it counts as momentum, but engineers representing Facebook, Intel/VESA, Shopify, Adobe, and more have been asking for JXL to be enabled in Chrome without a flag for quite a while now.

The scoop: a JPEG XL developer explains how JPEG XL is uniquely better than AVIF, webP, and PNG, and laments the Chrome team's decision to drop the experimental support for it.

AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000.

You're seriously underselling the article.

I'm trying to entice reading it! :)

> AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000.

Well, there is this thing https://jpegxl.io/articles/rans/

You're technically correct, but:

> Several variants of the coding procedure Asymmetric Numerical Systems (ANS) may be found in most modern codecs, such as AV1, Z-Standard compression, or even rANS in JPEG XL.

... this is hardly the fault of the JPEG XL developers though, that's the US patent system being ridiculous. Also, in the current discussion context that patent screws over any new compression format, not JPEG XL specifically. Note: general compression, not just image compression (ok, sure, QOI isn't affected. QOI also isn't relevant here).

It's obviously a defensive patent anyway, because between AV1, zstd and JPEG XL Microsoft would have to fight an alliance of literally everyone else out there if they'd plan on suing anyone.

AV1 does not use rANS in any form. The quoted sentence is simply incorrect. However, any necessary patent claims owned by Microsoft, an AOM member, would be freely licensed to everyone for use in AV1 implementations if it actually did use rANS. Which it doesn't.

The quote doesn't state that AV1 uses rANS, it states that it uses a variant of ANS. JPEG XL uses rANS.

I might be wrong, but doesn't AVIF benefit enormously because all the new phones, CPUs, GPUs, etc. support AV1 codec out of the box?

it was often argued, but HW codecs are not used in practice -- they have other compromises (quality, size limitations, setup times, single central resource when there are often 100 images on a web page) that make them difficult to be used for images

simd based software coding if more than fast enough, at least for JPEG and JPEG XL

Tangentially, in his linked page "hall of shame" https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMUL... , he argues humans prefer row A to row C. Personally in most cases I prefer row C. It may have less color accuracy, but is often a lot sharper, which in my eyes stands out a lot more.

Did you read the sentence right after he makes that claim?

> At Cloudinary, we recently performed a large-scale subjective image quality assessment experiment, involving over 40,000 test subjects and 1.4 million scores.

This isn't about your, my or Jon Sneyer's individual opinions on these photos, it's the consensus of 40,000 test subjects. And yeah, I agree with you that for a significant number of photos I disagree with the consensus. But given that we're both posting on HN we're both also likely the kind of people who like to prove other people wrong by actively looking for and overvaluing counterexamples, so also keep that in mind. Because to be honest, for a large number of photos I also agree with the consensus.

Psychovisual image quality tests are difficult and complicated. Selection of the population, methods, guiding text, motivation, etc. can lead to strange things happening.

As an example of the difficulties an academy leading corpora TID2013 has a reversal in quality between categories 4 and 5 -- highest quality images seem to get slightly worse quality ratings than the next highest quality images.

I observed a leading image quality laboratory to produce substantially different results for the same codec when the person conducting the experiments changed.

There are hard opinions if images should be reviewed one image pixel to one monitor pixel, or if images should be zoomed like they are in practical use, particularly on mobile.

Should zooming be allowed? Should people be allowed to move closer to the monitor if they want as part of the viewing? etc. etc.

Yes, I agree it is incredibly hard. On the other hand, if anyone has put in the work to give the "least bad answer so far" to this question it's Jon Sneyers.

I don't have time to dig through Twitter just now, but instead of just picking one image metric they've used all of them to also compare the testing methods themselves.

All my own experience and observations also suggest that Jon did an excellent job on this and is likely the first person to ever do it well with crowd-sourcing. In the past I have seen similar quality of results with hand-picked experts (image quality people, photographers etc.), but not with volunteers or crowd-sourcing.

It's also comparing two overly compresses images with encoders which produce very different kind of artificats (bluriness vs. blocks of wrong colors). Which one is better is always going to be subjective (or at least application-specific). Really, as long as the model rates both as shit it is not necessarily a bad model.

Unrelated to the content, but isn't it silly that browsers start hiding the scroll bar only for websites to implement their own ad-hoc reading progress bars.

I find both solutions to be flawed. The traditional scrollbar introduces layout shift when going from one page without a scrollbar to a page with a scrollbar. The new overlay scrollbar is sometimes harder to click and activate, especially in Chromium. Firefox's overlay scrollbar seems to do the right thing. The reading progress bars are a distraction and probably harmful to one's attention span and reading ability.

I guess scrollbar-gutter can fix the traditional scrollbar but then people have to give up using their fancy banners in headers. I'm (mostly) fine with Firefox's overlay scrollbar for now.

At least on a desktop we have enough horizontal space to always display the vertical scrollbar, which solves all issues. But even without that, the layout difference between pages with or without scrollbar is so tiny that IMO its a nonissue.

Mobile is a tricky tradeoff. There I am mostly used to Firefox, which has a tiny overlay scrollbar that is 50% grey making it almost invisibile in most cases.

> But even without that, the layout difference between pages with or without scrollbar is so tiny that IMO its a nonissue.

It annoyed to me enough to make me activate overlay scrollbar on Firefox and inject custom CSS with scrollbar-gutter on Chromium. Otherwise, when moving from a repo home page (without a scroll bar) to the another page (let's say the contents a folder with a scrollbar), the box containing the contents of the repo experiences layout shift.

This is still an issue on GitHub and many other sites.

> Mobile [...] Firefox

… and unfortunately it's not draggable, either.

Thank you.

On the same website, another blog post [1] compares JPEG XL with other formats.

[1] https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...

Be careful with this website. Cloudinary is a developer of JPEG XL, is an affiliated party, so there is absolutely no reason to expect a fair comparison.

Instead visit https://storage.googleapis.com/demos.webmproject.org/webp/cm... and you will see that JPEG XL has color fringing and ringing artifacts.

There is some irony on calling out benchmarks from an affiliated party and then linking to benchmarks from an affiliated party of the competing format.

> The source images were stripped of any metadata, EXIF, XMP, color profile etc. including the gAMA PNG chunk.

Just so happens that cjxl correctly supports PNG color profile/gamma data while cwebp doesn't.

I'm not suggesting to look at the "benchmark" part of this page. Given that the creators of formats can approximate the result to synthetic metrics for as long as they want, these metrics are secondary to individual perception. Personally, I would have easily sacrificed SSIM just to avoid seeing the green sand on the border of the blue and yellow areas.

"We don't like to implement JPEG XL because this takes code, although barely so since we import a library. Also, we saw little usage in our own browser in which it is actually disabled by default."

If I was king of the web, AVIF wouldn't have been added and JPEG XL would.

Having said that, AVIF did get added and I don't think having some kind of process for adding new image formats beyond "it exists and is better" is a bad thing.

Ideally all the big players would come together and settle on one.

This kind of happened for AV1 video, so it's a shame that as a side effect of that AVIF got added before JPEG XL and split the potential momentum for a next generation image codec in two.

That feels like a mistake that it's not too late to revert though.

JXL developers are understandably upset about being a victim of Worse is Better.

The Web platform is hardly cutting edge here. It took 10 years to add WebP across browsers, and it wouldn't have been added at all if it didn't cause web-compat issues for non-Chrome(ium) browsers.

From browsers' perspective the question isn't "is the new codec better", but "are existing codecs so terrible that they need urgent replacement". Most people still use JPEG, not even WebP or AVIF yet.

With your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from JPEG XL tech into traditional JPEG.

That's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off.

It sucks that the codec with the best quality/filesize ratio doesn't just win. There are many other factors beyond this, e.g.

• There's a lot of inertia keeping old codecs alive, which is from "just works" that has been from merely being old and popular. There's a whole graveyard of JPEG-killers that have beaten it on features and compression. GIF isn't even "good enough" technically, and it still refuses to die, because it's just so old to be universally supported. JPEG XL hasn't done the legwork yet to be everywhere, and isn't old enough yet to be everywhere including old software.

• Browser vendors' default resistance to ever-growing complexity of the platform, code size, and attack surface. I think JPEG XL's ability to be both non-Web editing format and Web format is actually working against it here, because the Web platform doesn't want non-Web features. Browsers haven't even implemented AVIF as specced, only a bare minimum subset. JPEG XL doesn't have a minimal subset.

JPEG XL can be fully implemented in 50-150 kB, and now you tell that AVIF implementations in browsers at 500+ kB are bare minimum subsets.

The major cost is on the AV1 side, which is there for video and which JPEG XL can't replace. The extra cost of recycling existing MP4+AV1 code to handle AVIF is minimal, smaller than JPEG XL can be.

Then again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do be able to do that for jpeg). I think that could reduce the net cost of adding jxl quite a bit — libjpeg-turbo has quite some code and API functions that browsers don't actually need at all, and all it really needs to do is already there in libjxl.

So a variant of the "two for one" argument that justifies AVIF can also be used to justify JXL, since JPEG is needed anyway, even more so than AV1.

Also I am not so sure if the delta between AV1-only and AVIF is _that_ small, after all you do need to take care of alpha, color management, HDR, animation, and I suppose quite different code paths to get the decoded pixels in the right place than what is already there for the video case. Plus it looks like new things are still getting added to avif, like YCoCg-R and progressive previews, so it feels like it's a bit of a "moving target" spec like webp was in the early days. I see quite a few opportunities for bugs, different levels of support between different browser (versions), etc, that are not caused by AV1 itself but just by AVIF.

JXL currently has two levels:

Level 5 (intended for browsers), allows no CMYK, limits the number of channels to 7, limits the maximum lossless bitdepth to 14-bit or so (the actual criterion is that the intermediate buffers can be implemented using int16_t, so the actual bitdepth limit depends on what bitdepth-widening or -narrowing transformations the encoder used), and has some more limits like that.

Level 10 allows nearly anything the bitstream syntax allows, with a few "sanity check" type limits.

All of the coding tools and format features in the jxl spec do have useful potential applications for the Web, except for CMYK and very high precision lossless (and this is why a decoder conforming only to level 5 does not need to handle those). E.g. layers can be useful just for compression too (e.g. a text overlay on a photo background will likely compress better / with less artifacts if it is kept in layers).

The nice thing about jxl is that everything needed to display an image is specced in the codestream and handled by libjxl itself, so no need for a browser (or any other application) to implement these things themselves — and possibly not implement some of them, or not quite correctly. In avif (like in heic), a lot of codestream gaps have to be filled at the file format level (e.g. alpha), and that inevitably leads to bugs and differences between the different browsers/viewers.

> Recently, the Chrome developers announced their decision to remove the behind-a-flag support for JPEG XL.

Given that, is there any reason JPEG XL might be better for privacy / worse for advertising industry scumbags? I have no expectation that Google / Chrome will ever make any decision primarily with their users' best interest in mind.

Browser support:

- JPEG XL: none

- HEIF: none

- AVIF: all but Edge

- WebP: all

JPEG-XL is already implemented in ~95% of browsers in the wild (Chrome, Edge, Opera and Firefox), just only behind a flag.

Chrome Banishes Photo Format That Could Save Space on Your Phone

https://www.cnet.com/tech/computing/chrome-banishes-photo-fo...

And it'll stay unsupported until those flags come on by default.

The point of the article is that Chrome removes the experimental, behind-a-flag support of JPEG XL, which dramatically decreases the reach of JPEG XL, so yo say.

That list seems desktop centric - more browsing happens on the mobile. Hence Safari is a glaring omission on your list... Until Safari for iOS implements JPEG-XL, it is sadly not ready for mass deployment.

Browser support for AVIF and Webp happened when? Browsers evolve over time.

I don't remember claiming otherwise. You just can't use it on web today, that's it.

I was a little surprised about AVIF, so I looked it up and it doesn't seem to be quite there yet (though it's getting there). macOS Safari requires Ventura, and no support yet on Edge.

https://caniuse.com/avif

You're right I missed Edge, but Safari seems to have "partial support" whatever that means.

Safari 16 didn’t support animated AVIF but 16.1 does.

Firefox still doesn't support animated AVIF, or does it now?

that looks really nice, very sad that Edge chooses to go another route here. They use chromium code... if Edge starts supporting AVIF I'll start using AVIF.

The funny thing about AVIF support in Chrome is that, unlike JPEG XL, there was no experimental period. It was enabled by default from the beginning (in Chrome 85).

AVIF practically comes along "for free" by just having AV1 support in the first place.

Why don't Edge support AVIF? Isn't it a downstream of Chromium?

I wonder what is the Mozilla's position on JPEG XL.

Mozilla is one of the founding members of AoM backing AVIF/AV1. They're shipping AVIF support enlabled.

The JPEG-XL bug hasn't received any news or updates for at least a year now and the support is disabled on all stable builds (meaning: you can't even enable it with a flag since it's not compiled in). You can enable a flag on nightlies.

It hasn't received news or updates because it has been locked. Basically Mozilla's position seems to be that they're not going to do anything on this front until Chrome does it first. I can only assume the decision makers at Mozilla feel the need to "prove their loyalty to the AOM", just like the Chrome codec devs, by blocking non-AOM codecs, in particular JXL.

Or, they just don't have the resources, market share, or interest to fight this battle. I can think of many better things FF should do other than try to push forward a new image format.

It is not a battle, everyone wants the same: to create the best experience for all the internet users by using free software.

We can arrive to the best solution by listening, by creating and studying the evidence, and by discussion.

Sad joke was that they are waiting for an “alternative implementation”, yet I’m still shocked that Mozilla people are alluding to that elsewhere in this very thread. Unbelievable…

Mozilla's engineers are enthusiastic about JPEG XL, but their directors less so. Mozilla's director a year ago: "I'm locking this conversation as it has passed the new information stage." This is not a great position, as loads of new information about human rater studies has been obtained, the codecs have advanced further significantly, the ecosystems are developing, industry is developing their stance, and even new objective metrics to evaluate codecs have been developed.

I'd like to highlight two things there:

My arguments for JPEG XL: https://github.com/mozilla/standards-positions/issues/522#is... -- it comes with links to 3rd party evidence of the somewhat outrageous but correct claims.

Jon's arguments for JPEG XL: https://github.com/mozilla/standards-positions/issues/522#is...

I'd have expected HEIF to be implemented in Safari, at the very least mobile Safari. Did Apple really not include their native image format on recent iPhones?

HEIF is the default format for the iOS Camera app and has been since at least 2018.

Yes, exactly. So it's pretty much the standard image format on the iPhone.

So I was wondering if/why it's not also part of Safari.

AVIF is based on HEIF + free codec. Apple's HEIC is HEIF + commercial patent-encumbered codec libre browsers are not allowed to use.

As mentioned above, Safari 16 is shipping with AVIF support so Edge is the last holdout.

Yay, more "fuck the long tail" from lazy-ass Google developers.

Google has a gigantic pile of money. They can afford to keep JPEG XL support.

Take note: This sort of abusive comment is not persuasive. If somebody spoke that way to me, I would not listen to their suggestions, if only out of sheer spite.

Why is this manner of speaking so common?

This is how people actually talk. Maybe not in the gentrified ivory towers of large tech companies, but out here on the ground floor....

This "we think supporting option X is too much work" is just corporate cost-cutting translated into developer-speak that is persuasive to those with no concept of history or user-centricity

People want options and they want diversity. How much maintenance is a JPEG XL decoder in the grand scheme of Chrome's codebase? Especially when it seems to be largely finished?

Although maybe I should have put "lazy-ass product managers" instead.

You're ignoring what the commenter is addressing: a corporation, and a particularly insidious one at that.

It's easy to feel powerless and frustrated in a world where corporations (in this case a blatant monopoly) make decisions that affect people's lives.

Without a second thought, because they arbitrarily deem it harmful to their profits or wasting their human resources. Good will... serving the public interest? Only if it's profitable or works towards the corporation's collective interests.

And it's not democratic: I can't propose or participate in a vote to overturn something that a corporation does or decides that affects my life. A Google employee couldn't even do that: Google is under no obligation to follow what their employees decide.

I can adapt, change my habits, even boycott Google; but ultimately my power as a citizen is limited because I lack the most important elements to affect change in this world: very big piles of money and influence.

It seems that Google's developers are merely cogs in the machine (see: the Stadia fiasco). So I'm sure the commenter was mainly directing their frustration to Google.

If Google's employees had a voice, surely Google would have a support department that handles Google's various services? How would you feel if countless people are despairing because the service you developed/worked on isn't serving them properly?

Locked out of your Gmail and recovery methods don't work? Google flagged your domain for so-called abuse? Take to Twitter if you're a celebrity or well-connected and beg for support, or if not: get fucked.

Google is not a good company, and desperately needs regulated.

This manner of speaking is common because not everybody is born with a silver spoon, or is able or willing to take on an enormous amount of debt to obtain a degree that may or may not pan out into a career that uplifts them out of poverty.

As simplistic as it may sound but Google probably removed it mostly because it's a chunk of c++ that they don't want around. I'm the last person to usually endorse a rewrite but in this case maybe they should consider a Rust port so browsers feel more comfortable including this. The point of an image format is to be adopted by everyone.. it's kind of beneficial if you make that usecase as attractive as possible. Personally I think Rust is actually hard to understand and for that reason dangerous too. But it definitely has some safety over c++.

Chromium is an extremely large C++ code base and I don't think they would reject libjxl only for that reason. That said, as an author of the first significant reimplementation of JPEG XL format (J40), I think a Rust decoder would be a good addition to the format and has a long-term plan to make one [1].

[1] https://github.com/lifthrasiir/j40/issues/10

Some on the Mozilla side did raise this as a specific issue.

One interesting project would be a combined JPEG and JPEG XL decoder, written in rust which might even lead to a reduction in code size and better security since they have some overlap.

This is a valid argument, but which of the contenders are using Rust or similar security minded languages?

WebP appears to be written in C++, perhaps because underlying video codec is also written in C++…

We wrote WebP in C -- in the creative phase of codec and format development I kept it in C++, the feasibility proto was initially launched in C++ (perhaps 0.2 version of the lossless coding, late 2011), but I ported it to C a few months after that and handed it over to the WebP production team (early 2012) who kept making improvements like streaming decoding

My bad, I glanced at “compiling” page and assumed c++ for some reason.

[0] https://developers.google.com/speed/webp/docs/compiling

There is a Rust WebP decoder in image-rs [1], presumably independently written from the specification.

[1] https://github.com/image-rs/image/tree/master/src/codecs/web...

FTR that decoder does not support colors, so for most uses it is not ready yet: https://github.com/image-rs/image/pull/952

Isn't that why they're creating Carbon?

Reply on news.ycombinator.com