Chromium Has Merged JpegXL

https://chromium-review.googlesource.com/c/chromium/src/+/7184969

by thunderbong • 6 months ago

451 186 6 months ago

chromium-review.googlesource.com

jakkos• 6 months ago

I've been hearing about fights over JpegXL and WebP (and AVIF?) for years, but don't know much about it.

From a quick look at various "benchmarks" JpegXL seems just be flat out better than WebP in both compression speed and size, why has there been such reluctance from Chromium to adopt it? Are there WebP benefits I'm missing?

My only experience with WebP has been downloading what is nominally a `.png` file but then being told "WebP is not supported" by some software when I try to open it.

speps• 6 months ago

It was an issue with the main JPEGXL library being unmaintained and possibly open for security flaws. Some people got together and wrote a new one in Rust which then became an acceptable choice for a secure browser.

a-french-anon• 6 months ago

Unmaintained? You must be mistaken, libjxl was getting a healthy stream of commits.

The issue was the use of C++ instead of Rust or WUFFS (that Chromium uses for a lot of formats).

spider-mario2• 6 months ago

It’s largely the same people.

jacobp100• 6 months ago

JpegXL and AVIF are comparable formats. Google argued you only needed one, and each additional format is a security vulnerability.

londons_explore• 6 months ago

And more importantly, an additional format is a commitment to maintain support forever, not only for you, but for future people who implement a web browser.

I can completely see why the default answer to "should we add x" should be no unless there is a really good reason.

out_of_protocol2• 6 months ago

- avif is better at low bpp (low-quality images), terrible in lossless

- jxl is better at high bpp, best in lossless mode

jmillikin2• 6 months ago

Most of the code in WebP and AVIF is shared with VP8/AV1, which means if your browser supports contemporary video codecs then it also gets pretty good lossy image codecs for free. JPEG-XL is a separate codebase, so it's far more effort to implement and merely providing better compression might not be worth it absent other considerations. The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes.

Also from a security perspective the reference implementation of JPEG-XL isn't great. It's over a hundred kLoC of C++, and given the public support for memory safety by both Google and Mozilla it would be extremely embarrassing if a security vulnerability in libjxl lead to a zero-click zero-day in either Chrome or Firefox.

The timing is probably a sign that Chrome considers the Rust implementation of JPEG-XL to be mature enough (or at least heading in that direction) to start kicking the tires.

latexr• 6 months ago

The continued widespread use of JPEG is evidence that many web publishers don't care that much about squeezing out a few bytes.

I agree with the second part (useless hero images at the top of every post demonstrate it), but not necessarily the first. JPEG is supported pretty much everywhere images are, and it’s the de facto default format for pictures. Most people won’t even know what format they’re using, let alone that they could compress it or use another one. In the words of Hank Hill:

Do I look like I know what a JPEG is? I just want a picture of a god dang hot dog.

https://www.youtube.com/watch?v=EvKTOHVGNbg

coppsilgold• 6 months ago

JPEG XL has progressive decoding

https://www.youtube.com/watch?v=UphN1_7nP8U

archerx7• 6 months ago

Google created webp and that is why they are giving it unjustified preferential treatment and has been trying to unreasonably force it down the throat of the internet.

breppp4• 6 months ago

unjustified preferential treatment over jpegxl a format google also had created

adzm9• 6 months ago

WebP gave me alpha transparency with lossy images, which came in handy at the time. It was also not bogged down by patents and licensing. Plus like others said, if you support vp8 video, you pretty much already have a webp codec, same with AV1 and avif

MrDOS• 6 months ago

You're getting downvoted, but you're not wrong. If anyone else had come up with it, it would have been ignored completely. I don't think it's as bad as some people make it out to be, but it's not really that compelling for end users, either. As other folks in the thread have pointed out, WebP is basically the static image format that you get “for free” when you've already got a VP8 video decoder.

The funny thing is all the places where Google's own ecosystem has ignored WebP. E.g., the golang stdlib has a WebP decoder, but all of the encoders you'll find are CGo bindings to libwebp.

rdsubhas• 6 months ago

various "benchmarks" JpegXL seems just be flat out better than WebP

The decode speed benchmarks are misleading. WebP has been hardware accelerated since 2013 in Android and 2020 in Apple devices. Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp.

JXL is more about future-proofing. Bit depth, Wide gamut HDR, Progressive decoding, Animation, Transparency, etc.

JXL does flat out beats AVIF (the image codec, not videos) today. AVIF also pretty much doesn't have hardware decoding in modern phones yet. It makes sense to invest NOW in JXL than on AVIF.

For what people use today - unfortunately there is no significant case to beat WebP with the existing momentum. The size vs perceptive quality tradeoffs are not significantly different. For users, things will get worse (worser decode speeds & battery life due to lack of hardware decode) before it gets better. That can take many years – because hey, more features in JXL also means translating that to hardware die space will take more time. Just the software side of things is only now picking up.

But for what we all need – it's really necessary to start the JXL journey now.

Dylan168073• 6 months ago

Due to existing hardware capabilities, real users will _always_ experience better performance and battery life with webp.

Extra data transfer costs performance and battery life too.

chocolatkey• 6 months ago

Where can I learn more about hardware acceleration of WebP on mobile OSes? I haven’t yet come across a resource that confirms this is actually the case. I know it should theoretically be possible using the VP8 hardware decoders but I thought those were expensive to warm up just for images

3OCSzk• 6 months ago

1 black pixel of .webp is smaller than 1 black pixel of .jpegxl that is also smaller than 1 black pixel of .png

so webp > jpegxl > png

viktorcode• 6 months ago

Anyone knows if their implementation supports animations? This is a feature missing from Apple's

adzm9• 6 months ago

According to the chrome platform status page, yes! https://chromestatus.com/feature/5114042131808256

>>

  - Progressive decoding for improved perceived loading performance
  - Support for wide color gamut, HDR, and high bit depth
  - Animation support

nar001• 6 months ago

It does, I just tried it in Canary and the jxl test page did also show animations

actionfromafar2• 6 months ago

What, isn't this the cue for someone to explain that it's ironic webp is really a video format which is a bad image format, and now we have symmetry that JpegXL is a good image format which is bad video format? :-D

(I don't know if any of this is true, but it sounds funny...)

account427• 6 months ago

Webp is also an incredibly bad animation format since it drops most of the inter-frame compression features of the video codec it was derived from.

Latitude79732• 6 months ago

Yes, but it's not recommended - it does not have inter-frame compression, so it is significantly less efficient than just having a regular video file and slapping 'gif' on it.

1122332• 6 months ago

Do you know of a video format that supports progressive decoding?

ignaloidas• 6 months ago

That's not strictly correct, it's rather that the current encoder does no inter-frame compression. Patches (and the frame system in general) does give tools to do some inter-frame compression (not as many as in video, but still quite expressive), just nobody stepped up to implement compression using them for animations yet.

account427• 6 months ago

Video files are not supported in <img> tags.

adzm9• 6 months ago

https://github.com/libjxl/jxl-rs jxl-rs is the underlying implementation. It's relatively new but Rust certainly calms security fears. This library wasn't really an option last time this came around in chromium.

quikoa• 6 months ago

Didn't Google refuse adding JpegXL because they claimed there wasn't enough interest? I don't think they refused out of security concerns but maybe I'm misremembering that.

pixelesque• 6 months ago

Google argued that duplicating largely (I know JpegXL does support a bit more, but from most users' perspectives, they're largely right) what AVIF provided while being written in an unsafe language was not what they wanted in terms in increasing the attack surface.

gcr• 6 months ago

Google refused to merge JpegXL as a strategy play to promote AVIF, which was in use by other teams (i think Photos?). Internally, chrome engineers were supportive of jxl but were overridden by leadership.

WhereIsTheTruth• 6 months ago

Rust certainly calms security fears

No, memory safety is not security, Rust's memory guarantees eliminate some issues, but they also create a dangerous overconfidence, devs treat the compiler as a security audit and skip the hard work of threat modeling

A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language

rkangel• 6 months ago

A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language

I agree with this. But for a component whose job is to parse data and produce pixels, the security worries I have are memory ones. It's not implementing a permissions model or anything where design and logic are really important. The security holes an image codec would introduce are the sort where it a buffer overun gave an execution primitive (etc.).

estebank• 6 months ago

A vigilant C programmer who manually validates everything and use available tools at its disposal is less risky than a complacent Rust programmer who blindly trust the language

What about against a vigilant Rust programmer who also manually validates everything and uses available tools at its disposal?

whatevaa• 6 months ago

History shows that either vigilance of most C programmers is not enough, or they are not vigilant at all. C/C++ and RCE via some buffer overflow is like synonyms.

cyberax• 6 months ago

A vigilant C programmer who manually validates everything

So, a fairy-tale character?

g947o• 6 months ago

I can't believe someone is still using this argument. Is this sarcasm?

rafram• 6 months ago

It's relatively new but Rust certainly calms security fears.

https://github.com/search?q=repo%3Alibjxl%2Fjxl-rs%20unsafe&...

dubi_steinkek• 6 months ago

That looks pretty good to me. Every `unsafe` function has clearly stated safety requirements, and every `unsafe` blocks justifies why the requirements are met.

12_throw_away• 6 months ago

So, I had no reason to use "unsafe" for a very long time, and had developed a bit of an aversion to it. Then I actually needed to use it, first to interface with some C code, and then to deal with a device's mmap'd memory as raw `&[u8]`s.

And my discovery (which basically anyone could have told me beforehand) was that ... "unsafe" rust is not really that different from regular rust. It lets you dereference pointers (which is not a particularly unusual operation in many other languages) and call some functions that need extra care. Usually the presence of "unsafe" really just means that you needed to interface with foreign functions or hardware or something.

This is all to say: implying that mere presence of an "unsafe" keyword is a sign that code is insecure is very, very silly.

LtdJorge4• 6 months ago

I’ve recently compared WebP and AVIF with the reference encoders (and rav1e for lossy AVIF), and for similar quality, WebP is almost instant while AVIF takes more than 20 seconds (1MP image).

JXL is not yet widely supported, so I cannot really use it (videogame maps), but I hope its performance is similar to WebP with better quality, for the future.

adzm9• 6 months ago

You have to adjust the CPU used parameter, not just quality, for AVIF. Though it can indeed be slow it should not be that slow, especially for a 1mp image. The defaults usually use a higher CPU setting for some reason. I have modest infrastructure that generates 2MP AVIF in a hundred ms or so.

LtdJorge4• 6 months ago

I tested both WebP and AVIF with maximum CPU usage/effort. I have not tried the faster settings because I wanted the highest quality for small size, but for similar quality WebP blew AVIF out of the water.

I also have both compiled with -O3 and -march=znver2 in GCC (same for rav1e's RUSTFLAGS) through my Gentoo profile.

fishgoesblub• 6 months ago

rav1e has not had an actual update in performance or quality in years since funding got dropped. Use an encoder like aom, or svt-av1.

LtdJorge4• 6 months ago

I tried both AOM and rav1e, same quality with rav1e producing 20% larger image, same performance more or less (too long)

spartanatreyu• 6 months ago

Other comments here are good, but one thing that's worth pointing out:

Encoding time isn't as important as decoding time since encoding is generally a once-off operation.

Yeah, we all want faster encodes, but the decodes are the most important part (especially in the web domain).

LtdJorge4• 6 months ago

I know, thats why I used max CPU settings. But when processing map tiles with a final total compressed size of half a terabyte, and each one is 200kB, taking 20s per tiles is prohibitively expensive.

carra3• 6 months ago

Thanks, but just like WEBP I'll try to stick to regular JPEGs whenever possible. Not all programs I use accept these formats, and for a common user JPEG + PNG should mostly cover all needs. Maybe add GIF to the list for simple animations, while more complex ones can be videos instead of images.

Sammi• 6 months ago

You can really treat WebP as a universally available format in 2026. It is an old, boring, and safe format to use now.

Browser support for WebP is excellent now. The last browser to add it was Safari 14 in September 16, 2020: https://caniuse.com/webp

It got into Windows 10 1809 in October 2018. Into MacOS Big Sur in November 2020.

Wikipedia has a great list of popular software that supports it: https://en.wikipedia.org/wiki/WebP#Graphics_software

Y-bar3• 6 months ago

Webp can be really annoying once you hit certain encoding edge cases.

One customer of mine (fashion) has over 700k images in their DAM, and about 0.5% cannot be converted to webp at all using libwebp. They can without problem be converted to jpeg, png, and avif.

carra3• 6 months ago

Unfortunately being universal implies way more than just having good browser support. There are quite a few image processing programs without webp or jpeg-xl support. I'm using Windows 11 and the default image viewer can't even open webp... Also, keep in mind that due to subscription models there are many people stuck with older Photoshop versions too.

ashirviskas• 6 months ago

You should never use GIF anymore, it is super inefficient. Just do video, it is 5x to 10x more efficient.

https://web.dev/articles/replace-gifs-with-videos

jdiff2• 6 months ago

There's odd cases where it still has uses. When I was a teacher, some of the gamifying tools don't allow video embeds without a subscription, but I wanted to make some "what 3D operation is shown here" questions with various tools in Blender. GIF sizes were pretty comparable to video with largely static, less-than-a-second loops, and likely had slightly higher quality with care used to reduce color palette usage.

But I fully realize, there are vanishingly few cases with similar constraints.

gsich2• 6 months ago

only if looping information is stored inside the container.

SahAssar4• 6 months ago

Videos and images are treated very differently by browsers and OS:es. I'm guessing the better suggestion would be to use apng or animated avif if you are looking for a proper gif alternative.

account427• 6 months ago

Unfortunately browser vendors didn't want to support silent looping videos in <img> tags so gif stays relevant.

striking2• 6 months ago

"JPEG XL" is a little bit of a misnomer as it's not just "JPEG with more bits". It supports lossless encoding of existing content at a smaller file size than PNG and allows you to transcode existing JPEGs recoverably for a 20% space savings, the lossy encoding doesn't look nearly as ugly and artifacted as JPEG, it supports wide gamut and HDR, and delivers images progressively so you get a decent preview with as little as 15% of the image loaded with no additional client-side effort (from https://jpegxl.info/).

It is at least a very good transcoding target for the web, but it genuinely replaces many other formats in a way where the original source file can more or less be regenerated.

AlienRobot• 6 months ago

Honestly, I don't like how webp and now jpegxl support both a lossless and lossy mode.

Let's say you want to store images lossless. This means you won't tolerate loss of data. Which means you don't want to risk it by using a codec that will compress the image lossy if you forget to enable a setting.

With PNG there is no way to accidentally make it lossy, which feels a lot safer for cases you want lossless compression.

out_of_protocol2• 6 months ago

https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front

Oldie goodie article with charts, comparing webp, jpegxl, avif, jpeg etc. avif is SLOW

xnx• 6 months ago

This consolidates JPEG XL’s position as the best image codec currently available, for both lossless and lossy compression, across the quality range but in particular for high quality to visually lossless quality. It is Pareto-optimal across a wide range of speed settings.

Wow. Nice. Big improvement if JPEG and PNG can be replaced by one codec.

lambdaone2• 6 months ago

And even better if someone can implement the whole massive spec securely...

adgjlsfhk13• 6 months ago

The part I'm more excited for is all the image-like/bundle of image like data that until Jpeg-xl didn't have any good codecs (usually implemented as folders of images). One clear example of this is PBR in blender and friends. (e.g. a combo of normal map, roughness, color, metalness etc)

hulitu• 6 months ago

Big improvement if JPEG and PNG can be replaced by one codec.

By one ? Ten maybe: webp, avif, ...

charcircuit• 6 months ago

This doesn't use hardware accelerated decoders and encoders.

Nathanba• 6 months ago

what exactly is this website trying to do? https://i.imgur.com/Q8JGYK3.png

MrGilbert• 6 months ago

Maybe some form of fingerprinting for ads?

stronglikedan• 6 months ago

I don't get any of that. Maybe you have a malicious extension installed?

smusamashah• 6 months ago

JPEG at lowest quality looks much better here https://cloudinary.com/blog/jpeg-xl-and-the-pareto-front#wha...

daemonologist• 6 months ago

Keep in mind that lowest JPEG is 3-4x the size of the lowest JXL and AVIF - similar to the size of their "med-low" (top row).

cfreksen• 6 months ago

That means that SSIMULACRA2 does not capture quality perfectly.

Note that in that figure the formats are compared at the same SSIMULACRA2 score, not at the same file size. In the "very low quality" category, JPEG uses ~0.4 bpp (bits per pixel), while JPEG-XL and AVIF use ~0.13 bpp and ~0.1 bpp, respectively, so JPEG is roughly given 4 times as much space to work with. In the "med-low quality" category, JPEG-XL and AVIF use around 0.4 bpp, so perhaps you should compare the "very low quality" JPEG with "med-low quality" JPEG-XL and AVIF.

After reading your comment, I assumed you had missed the bpp difference. Please excuse me if I assumed incorrectly.

lern_too_spel5• 6 months ago

Chromium is not using libjxl, which is the decoder that is evaluated in this article. The SVT encoder is much faster than the AOM encoder for AVIF.

einpoklum• 6 months ago

Unfortunately, with Chromium dropping support for manifest-v2 extensions, and through that dropping proper support for uBlock Origin, I'm moving away from it. Not that that's easy, of course...

YmiYugy• 6 months ago

With Chrome being by far the most popular browser, it gaining support is almost a precondition for jxl gaining traction on the web. Few would bother converting their images for Safari (and when it becomes enabled without a flag Firefox). So this is good news even for people who don't use Chromium.

bla3• 6 months ago

It's a shame that JpegXL doesn't have a freely available spec.

Latitude79732• 6 months ago

In general terms, it is a shame that thousands of ISO, IEC etc specifications and documents are behind a paywall.

bionhoward• 6 months ago

Yes! The paywalled SQL documents are a big annoyance

nathancahill• 6 months ago

I'm surprised there hasn't been a Z-Lib/Anna's like movement for spec documents. Given how tech savvy the default audience of those documents are.

master-lincoln• 6 months ago

You could also say it's a sham to have non-public standards

ksec3• 6 months ago

IIRC it doesn't have a freely available "Final" spec. The Final Draft is available for free.

Findecanor• 6 months ago

From my (limited) understanding, there is still a lot shared between JPEG and JPEG-XL.

I wonder if this new implementation could be extended to incorporate support for the older JPEG format and if then total code size could be reduced.

dabinat• 6 months ago

Not sure why you’re being downvoted… there is an issue open on the JPEG-XL Rust repo for this very feature.

https://github.com/libjxl/jxl-rs/issues/513

hbn• 6 months ago

So is this another image format I'll download and be unable to use without converting because nothing supports it a la .webp?

caminanteblanco• 6 months ago

I mean even Microsoft (that Titan of Lightning-Fast Development) has implemented a JPEG XL add-on, so now that Google's giving up the ghost, i think JPEG XL has a real chance.

https://apps.microsoft.com/detail/9MZPRTH5C0TB?hl=en-us&gl=U...

RobotToaster2• 6 months ago

Only for win11

thunderfork2• 6 months ago

Yes, just like any new format, there's going to be an adoption period of about a decade before it reaches "ubiquitous-enough" support.

llm_nerd• 6 months ago

What do you think doesn't support it?

Affinity supports it. Photoshop supports it. Microsoft Photos supports it. Gimp supports it. Apple has had systemwide support for it since iOS 17+ / macOS 12+, including in Safari and basically any app that uses the system image functions.

Chromium isn't on the bleeding edge here. They actually were when it first came out, but then retreated and waited, and now they're back again.

aniviacat• 6 months ago

Lots of stuft still doesn't support it, for example WhatsApp and Discord.

WhatsApp doesn't even support WebP though. Hopefully, if they ever get around to adding WebP, they'll throw JXL in, too.

jiggawatts3• 6 months ago

Half the point of JPEG XL is support for HDR and higher than 8 bits per channel. Most of the apps you listed don’t support that fully, especially iOS, which converts everything to SDR or shows garbage — except for their own proprietary gain map encoding that their camera app produces.

account427• 6 months ago

Use better software - ideally open source software so that in the worst case you can just add support yourself.

RobotToaster2• 6 months ago

Reading the feature list of JpegXL on Wiki, it includes some interesting stuff like arbitrary numbers of channels for multi-spectral imaging and multi page documents, which for both better and worse starts to sound a lot like TIFF.

Mr_Minderbinder• 6 months ago

Why does the current design paradigm in image coding formats emphasise supporting as many features as possible in order to have “one image format to rule them all”? You do not see this in audio and does anybody think that Opus and FLAC should be combined into one format? Does the fact that Opus does not support lossless encoding make it worse?

upbeat_general• 6 months ago

From a user perspective it is nice to know that the person decoding will likely support a given format, both now and in the future.

More use cases for a single popular format makes this more likely.

Chromium Has Merged JpegXL

Related Stories