Request: Re-open JPEG XL issue
bugs.chromium.org
bugs.chromium.org
I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile.
Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds.
4K TV’s use Rec 2020 which has a huge color gamut, because it is covering a bigger space, 8-bit color is not enough, you need to go to 10-bit, 12-bit or more (I process in 16 bits) and neither JPEG or WEBP can handle that. AVIF can, but so can JPEG XL.
I know people doing synthetic tests (instead of looking at the image they run a program that estimates how bad compression artifacts are) are impressed with AVIF but I’ve done some shootouts with JPEG/WEBP/AVIF/JPEG XL where I look at images with my own eyes.
For pictures that are moderate-low quality (say images for a blog) I think AVIF does very well, but I want to publish pictures I took with my mirrorless where I work really hard to get them “tack sharp” (e.g. sometimes a 4000x6000 image w/ my Sony looks almost like pixel art when you blow it up) and I want people to see something consistent with that on the web. And my experience is that AVIF falls down at that, it does not really save bits compared to JPEG and WEBP at high quality. JPEG XL gives superior compression at high quality and it supports high color depths and it’s an option I’d really like to have.
Also, jpegli can support 10+ bits within the old compatible "8 bit" formalism.
In all the comparisons I've seen, it's not even a contest.
"I picked this image because it's a photo with a mixture of low frequency detail (the road) and high frequency detail (parts of the car livery). Also, there are some pretty sharp changes of colour between the red and blue. And I like F1.
Roughly speaking, at an acceptable quality, the WebP is almost half the size of JPEG, and AVIF is under half the size of WebP. I find it incredible that AVIF can do a good job of the image in just 18 kB."
https://jakearchibald.com/2020/avif-has-landed/
It'd be interesting to see file size comparisons of AVIF lossless images vs. JPEG's "almost lossless" 100% compression, but I haven't run across any yet.
The compression artifacts in the self-shadows of the red bit of the car to the left of the driver's head look awful to me. It's true that the compression artifact blends in pretty well and you might think the car really looks like that but personally I can't unsee things like that once I look at them in comparison.
The thing is that it is that play of reflections and shadows that makes an expensive sports car look so sexy.
All compression is. :^) The additional twist is that our eyes/brains do a great job at glossing over compression artifacts that we're used to.
When you expand the image, you can change the formats on both sides for A/B testing. Comparing "JPEG - 20.7 kB" to "AVIF - 18.2 kB" is an enlightening like-vs-like size comparison.
I'd be happy to do an AVIF encode of a large uncompressed/losslessly compressed image that meets your "near visually lossless" bar. I'm assuming that JPEG must do better in comparison to AVIF at large file sizes, but I can't find good examples of this.
You can't extrapolate that comparison to higher bitrates though - so unless your use case doesn't require preserving image detail (i.e. the images might as well not be there), both formats are inadequate at that size.
They're just showing that it can do a less-offensive job of erasing detail smoothly to take filesizes down to tiny levels than WebP or JPEG? But "tiniest size with least offense" is VERY different than "best size with greatest detail."
For some applications people would be really happy with that F1 car image and I would even be happy with it for some applications (e.g. some random image to give spice to a blog) but for my photograph I'd say that's pretty lossy.
I don't want the internet to look like that F1 car to save a few milliseconds or $0.0000001 for the company sending the pic to me.
I certainly don't want my family photos to look like that.
I don't want the photographs on the internet to become much faster, much cheaper and much worse. I'd like them to become a bit faster, a bit cheaper, but also more crisp, vivid, emotionally engaging, and realistic.
Is defined by some standard to be able to be declared "4K", or is it just what seems to be happening because all/most of the panel makers just threw it in?
My main monitor is a Dell that is very close to Adobe RGB which is great for print work because it covers the CYMK gamut well.
I am interested in getting something better but it is not so clear to me that you can really get a Rec 2020 computer monitor other than a crazy expensive monitor from Dolby. Maybe I gotta download a bunch of monitor profiles so I can know what various monitors really support as I’ve already developed a system for simulating how channel separation works for red-cyan stereograms even on monitors I don’t have.
A better TV has been on the agenda too except somehow people keep giving me free TVs on the railing edge such as a Walmart TV which had great sound (better than many sound bars) that had the backlight burn out, then I got gifted a Samsung which sucks but is working fine in my TV nook downstairs. My main AV room doesn’t have room for anything bigger than what I’ve got unless I move everything which I don’t have a good plan for…
On the other hand, for viewing images on monitors, Adobe RGB is not a desirable color space. The worst primary color of PAL/SECAM and of the closely related SMPTE C and Rec. 709 color spaces is the primary red color.
While in the blue and green regions the colors that are not representable in PAL/SECAM/SMPTE C/Rec. 709 can be represented by reducing their saturation, in the red corner, from purple to yellow, besides colors that can be represented by reducing their saturation there are also colors that can be represented only by reducing both their saturation and their brightness.
Moreover, in the red corner, from yellow to purple, there are many frequently encountered objects with such saturated and bright colors, e.g. flowers, fruits and clothes.
So the really noticeable improvement in color reproduction on monitors is when passing from PAL/SECAM/SMPTE C/Rec. 709/Adobe RGB to monitors with DCI-P3 primary colors.
DCI-P3 keeps the primary blue of PAL/SECAM, but it has much better primary red and primary green colors. The green is not as good as that of Adobe RGB, but the better red provides a much more visible improvement.
Many relatively cheap monitors, e.g. all my Dell monitors, have a menu option to replace the default sRGB color space with the "DCI-P3" color space (and they can display almost 100% of the DCI-P3 color gamut). On any such monitors, by "DCI-P3" is meant the Apple Display P3 color space, i.e. DCI-P3 primary colors combined with the PAL/SECAM D65 white and with the sRGB non-linear transfer function.
In cheap monitors, the DCI-P3 color gamut with 10 bit per color component is the best that can be found. The monitors whose color gamut is a larger fraction of the Rec. 2020 color space are expensive, because they normally must use quantum dots or OLED or both.
Nevertheless, as the output color space for any high-quality photograph, the Rec. 2020 color space is preferable, even if most people who would look at the photograph now would clip its color gamut to the sRGB or DCI-P3 of their monitors. However those who have better monitors, whose numbers will be increasing in the future, will be able to see any color that can be displayed by their monitors, without having the quality of the photograph already degraded by whoever has processed it.
Worth noting that it is physically impossible for current flat panel displays to have full coverage of rec.2020, because the spectral width of each primary is too wide with current flat display tech (LED, LCD, etc.)
Full rec.2020 coverage requires the use of lasers, so you can get a ~spectrally pure primary.
My prediction is that the next big move in display tech after 8K will be a transition from LCD/LED to VCSELs or some other teeny laser pixel, so they can advertise full rec.2020 coverage.
After that, maybe tunable quantum dot lasers so they can get full CIE 1931 coverage, but that's probably at least 15-20 years away.
There are many commercial models which exceed a 90% coverage of the Rec. 2020 color space. However they are expensive, so they are used mostly in high-end TV-sets and only seldom in expensive computer monitors.
In theory you can use any color primaries with any video resolution in computer (NOT on TV as those normally only support mainstream standard) as long as the the color space metadata is properly set, but in practise, some softwares ignore the metadata or the metadata got lost in the video processing chain. So in general, 4K video use Rec 2020, HD/FHD use Rec 709, and SD use Rec 601, for maximum compatibility.
https://afontenot.github.io/image-formats-comparison/#end-of...
It seems AVIF has better compression at lower bit rates. At high bit rates they seem similar. AVIF especially shines for pictures with large homogeneous surfaces like the sky.
However, AVIF is missing some important features, such as progressive image loading. The maximum resolution is apparently also quite limited.
AVIF is missing JPEG XL's ability to re-encode JPEGs losslessly and reversibly with a reduction in file size. It may prove a serious advantage for JPEG XL. AVIF also lacks anything like https://jpegxl.info/art/. :-)
Yeah, AVIF seems to remove noise fairly aggressively, or what it assumes to be noise. I think it looks pretty good in this sky example, although not overly faithful. It's less good when the removed "noise" is actual high frequency detail, e.g. on the fur of animals.
But what I meant with AVIF being good at homogeneous surfaces is that it apparently uses them sometimes to "save" bit rate, and to use it instead in other portions of the picture. Images with large surface portions tend to look significantly better in the rest of the image, e.g.
https://afontenot.github.io/image-formats-comparison/#clovis...
https://afontenot.github.io/image-formats-comparison/#us-ope...
I think here AVIF "small" looks overall better than JPEG XL "medium", e.g. in the details of the middle balloon basket, or the face of the tennis player.
I still think the lack of any progressive image loading makes AVIF completely unsuited for the web. The picture will only show once it was downloaded completely. That's a big step back from JPEG, and even more so from JPEG XL.
You can easily see that AVIF blurs (beautifies faces) and removes properties of the red cloth in the 'end-of-show' image.
Internet average image quality is higher than the 'Large' setting, so those names are not representative of actual internet use. Camera and image processing use is even of much higher quality.
Even cameras often have relatively little detail per pixel, since they do interpolate a lot of information due to the usage of Bayer filters (which record only one primary color per pixel instead of full RGB values), and because anything with less than perfect lighting will be somewhat noisy and blurry anyway.
So it's unsurprising that they have pushed the format optimized for "as few bits as we can get away with before things like too terrible" rather than actually improving quality and extending capabilities.
Can you share some examples of such images/fragments?
Don't get too hung up on picking a file format then. All sorts of middleboxes, CDNs, and edge network acceleration systems can potentially "right-size" your image for what the requesting device can handle optimally.
Or maybe they are just trying to keep feature parity with Safari.
There's a browser joke here somewhere, I'm sure.
At this point adding new {image, audio, video, compression} codecs to browsers is probably a net negative, unless there's a good chance they get deployed across the entire browser ecosystem. Safari is generally the browser that's most conservative about implementing anything new, so their support makes a huge difference in the viability of getting the format universally supported.
I'm not a fan of WebP, mind, but the idea that support for it is dreadful is strange to me.
Personally, the fact that it was Googles idea means I’m going to hold it at arms length, if not avoid it entirely. The web should be built on open standards.
Seems to be a similar level of "works everywhere" for me, with the exception of web browsers this time.
I don't think AVIF is a good example of this though. All major browser makers were members of the consortium that created AVIF.
But it was a tremendous amount of effort and promotion on Google's end for a relatively narrow format.
I love this phrase thank you.
But it still more of a response than Google has given in ages.
With Google's study [1], by Google's Engineer, JPEG XL is no where near good enough compared to AVIF.
None of the above facts have changed since Google Chrome's decision on JPEG XL.
/S
[1] https://storage.googleapis.com/avif-comparison/index.html
Yes that is why I had "/S" at the end.
The fact that we have to get on our knees and plead for their consideration versus just fork and ship should make you ill. No compression without representation or some such.
> @Reporter Could you please confirm the OS details.
> As the issue seems similar to crbug.com/1178058 adding firsching to cc list for more inputs.
I get that most bandwidth goes to video, but it would still be nice to have a great modern standard for images.
WebP is obsolete. It's still based on VP8 codec, which in video has been replaced by VP9 long time ago. AVIF is based on AV1, which is a successor to VP10. So WebP is a few generations behind in the VPx lineage, and is no match for modern codecs.
Webp has been around for over a decade. AVIF will probably get adoption as a faster rate in my estimation.
WebP has the big advantage that the quality setting is meaningful, you can set it at a certain level and then encode thousands of images and know the quality is about the same. This is by no means true about JPEG, if you are trying to balance quality and size you find you have to manually set the compression level on each image. Years back I was concerned about the size of a large JPEG collection and recompressed them which was a big mistake because many of the images were compressed too hard.
In 2023 I think you can just use WebP and it will work well, my experience looking at images is that AVIF does better for moderate to low quality images but for high quality images it doesn’t really beat WebP.
https://archive.smashing.media/assets/344dbf88-fdf9-42bb-adb...
- What is the cross supposed to mean for PNG compression of photographic images? PNG can compress photographic images just fine and for some applications (where you want lossless) it used to be a good choice.
- PNG has animation support, even if everyone except Firefox tried to
- While WEBP and AVIF support lossless compression and animation, those features are not available in all browser versions that support static lossy webp/avif images.
Distortion metrics[0] such as MS-SSIM, MS-SSIM*, SIMM, MSE, and PSNR can be used to define a cut-off or threshold for deciding the point at which the image is "compressed enough" by using one or more of those algorithms and predefining the amount of acceptable/tolerable distortion or quality loss. Each of those algorithms has some trade-offs in terms of accuracy and processing time, but it can definitely work for a large set if you find the right settings for your use-case. It is certainly more productive than manually settings the Q-level per image.
Some SaaS such as https://kraken.io do this on JPG images.
If you're looking for a tool that really smartly optimizes the images (by using SSIM) that is https://shortpixel.com/online-image-compression
and
b) Like any other video codec-based format, webp overcompresses dark areas in images so no, you can't rely on consistent quality across collections of arbitrary images.
Very few sites pay for so much outgoing image bandwidth to make that compatibility cost lower than a 15% savings.
AVIF has gone better because it wasn’t based on a video codec which was never really competitive, was developed collaboratively, and didn’t have feature regressions from JPEG. As with tool support, that last matters a lot at many organizations because the edge experience tends to decide things - even if 95% of your usage is boring 8-bit 4:2:0 the institutional memory tends to be shaped by the times you hit something which can’t be used without more work. If it compressed as well as AVIF, more people might have decided WebP was worth it but since it only marginally outperformed JPEG the case was never that strong.
Part of what I meant by “shipping the prototype” was this kind of stuff: someone at Google wanted to find another use for the On2 IP they’d purchased so they tossed it into a 20 year old container format and shipped it. As with WebM, the benchmarks were fast and loose which meant that anyone who replicated them saw substantially lower performance, which is another great way not to build confidence in your format.
There's always going to be FUD around software patents, because the system is broken, but AVIF is as good as possible in the pathological system.
AV1 was largely based on VP9/VP10 and was developed by a team working in Chrome organization.
JPEG XL main mode (VarDCT) and the JPEG recompression is largely developed by Google Research.
WebP as a format was based on VP8, a video codec built by On2 Technologies. On2 was bought by Google in 2010 -- a year before Google published WebP. The transparency and lossless encoding as well as non-video keyframe-by-keyframe animation were designed at Google. The On2 VP8 codec used initially in WebP lossy was not that suitable (too many artefacts) for photography transmission. Jeff Muizelaar wrote a great blog post about this. The codec for WebP were redesigned (without format) changes at Google, and kept improving significantly until around 2015 when it reached pretty good maturity.
(Personally, I don't like what it does to highly saturated dark colors, such as dark forests or dark red textures, but it is much much better than it was.)
After a bit of searching, it's unclear what degree of "patent risk" comes with JPEG XL. JPEG historically was subject to patent troll lawsuits until the patent expired in 2006.
Please note that it's not enough for there to be a "royalty-free reference implementation" of JPEG XL, even if it's licensed with Apache 2.0, because you can't be sure from a glance that the Apache license patent grant includes all relevant patents. If you care about open source and free formats, you should look for two things: a comprehensive patent pool transferred to the standards body AND a royalty-free patent license to anyone with no strings attached.
The game here is that companies with potential claims over some techniques used within codecs have an incentive to withhold their patents from the official pool until years after adoption. Then they sue the biggest users of the codec (like Google) for obscene sums of money. That's why ALL of the patents used in a codec must be assigned to the standards body for open licensing, and you have to be SURE that none are withheld. This is difficult.
AVIF (and it's standards body, the AOM) was created in part (I believe) to solve this very problem. All the major tech companies are members and they've effectively agreed to a patent truce with regards to codecs.
This is arguably the most important commercial concern in distributing a browser for free that includes codecs. If you ship unlicensed codecs, some random company can crawl out of the woodwork 5 year later and sue you for a billion dollars.
In my view, AVIF only needs to be competitive with compression and quality. It patent risk is so low that it is the obvious choice. AVIF is truly open, there are multiple implementations, and its reason for existing is to solve the codec patent problem.
Source: I was near the activities within Netflix that helped found the AOM.
Disclaimer: I'm not a lawyer and this isn't legal advice; also I'm several years out of date w.r.t. JPEG XL specifically, so I'd be happy to be corrected about the relevant patent risk. Maybe someone has better info?
JPEG XL decides the codes at encoding time and does context modeling the same way as WebP lossless and Brotli, by deciding which entropy codes to use explicitly.
Microsoft's rANS patent is supposedly centralized around updating rANS codes at decoding time (based on past symbols). This is slightly more efficient for density, but much slower and may negate the speed benefits that rANS brings. For practical implementations JPEG XL/Brotli way is quite a bit better.
If the new issue gets closed, then it just reaffirms that the Chromium team doesn't care about this feature request. If the new issue somehow convinces the team to do something about it, then it shows that the team is utterly dysfunctional because their decision-making is more influenced by whether you say "pretty pretty please" in the right way than by the content of the discussion.
The new information here seems to be 'most people thought the previous decision was bad', rather than 'please I really want this'. Changing an old decision because most people think it was bad is not a sign of utter dysfunction.
Using it on the web is one thing, but getting better compression for my family photos would also probably be a win, and I suspect it would be possible to build a pipeline for viewing/editing that would be fairly transparent.
Combined with GNU parallel, I did this:
find -type f -iname \*.jpg -print0 | parallel -0 cjxl --lossless_jpeg=1 {} {.}.jxl
find -type f -iname \*.png -print0 | parallel -0 cjxl -d 0 {} {.}.jxl
find -type f -iname \*.webp -print0 | parallel -0 dwebp -o {.}.png {} \&\& cjxl -d 0 {.}.png {.}.jxl
There are a few holdout programs that I think are missing support (Blender3D springs to mind), but I also think in the rare instances where that's a problem I could probably set up a quick shortcut or some hooks to on-the-fly run cjxl and convert back to jpeg/png temporarily for whatever operation I need to do.
https://www.techspot.com/news/98355-google-deprecating-jpeg-...
Lack of popularity hasn’t stop them from supporting webp and AVIF.
This is a bad argument because with that money they can also afford to do almost anything. They could also add any random file format to the browser, but that increases costs to support the web for more than just Google. Meanwhile adding a polyfill to support the format is performant without adding complexity to the web.
Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis?
If it's the former then I can see this offering a lot of utility over other image formats because you'd be able to disable the DCT on high-contrast macroblocks and finally be done with all those god-awful "checkerboard" artifacts around the edges of objects.
But if it's merely on a per-channel basis then I'm not sure I see what the point of this is since I can already use a different format when I need lossless encoding; If anything JXL would become an annoyance because I can't tell if a JXL image is lossless or not based on the file's extension.
It was discussed here a few weeks ago: https://news.ycombinator.com/item?id=36801448
Tricky but it can be indeed done on a per-macroblock basis. The encoding itself is fixed per frame, but JPEG XL mandates zero-duration frames to be merged with the prior frame, so multiple frames with different encodings can be used for that. In fact I believe patches already work like this.
Two of the 8x8 transforms are extremely local. One is called IDENTITY and the other DCT2x2. It is very difficult to produce ringing artefacts when using these transforms.
When going to higher quality settings in libjxl, it tends to favor the DCT2x2 quite a bit.
This is in VarDCT -- not modular coding.
Now several formats are competing, most notably AVIF (which is basically just single AV1 video compressed frame) and JPEG XL. JPEG XL might be slightly better in some cases (as AVIF is based on a video codec) and most importantly it's backwards compatible with JPEG. So this means we can re-encode 30 years of JPEGs to JPEG XL without image degradation. Having a wide support would help immensely to make the format standard as otherwise everybody will just continue to use JPEGs. Google is somewhat against this as they already have support for AV1 and thus don't need to maintain a separate codec for JPEG XL.
but AVIF is the one Google, Apple, Edge, Firefox are pushing...
Let's not be misleading here :)
All the existing JPEG files can be converted to JPEG XL while gaining 20% size and still having all the exact same data. There are, what, tens or hundreds of billions of JPEG files out there for which the "original" (RAW or anything) is long gone (or never existed) and people don't want a "photocopy of a photocopy".
You can even decompress the JPEG XL back to the original JPEG file, bit for bit.
For that alone there shouldn't be any question: it's a wonderful feature.
In addition to that Apple / Safari are going to support JPEG XL and there are huge number of applications supporting that format.
People don't want this "over" existing formats. They want this in addition to other formats.
And I think they'll get it.
Chrome team themselves quoted no interest of those browsers as the reason for removal of the flagged code. Seems like an obvious way to pressure Google into supporing JXL would be to get Mozilla to launch their support, together with Edge and Safari?
However Mozilla has not completely dropped the feature like Google.
Chromium's JPEG XL feature request is marked wontfix but still possible to comment or express interest (star the bug).
1. Binary size cost, in my experience working on Firefox this is in the 100s of KiB range when adding a new decoder.
2. Ongoing costs increased compile times, new integration tests, functional tests and so forth. Keeping those tests passing and non-flaky.
3. Once something is accepted into the web ecosystem the intention is to support it for 10s of years if not forever. Web feature deprecation is quite slow, ex <keygen> & <blink>. The web has not deprecated a primary image format.
4. Security, a 'new' binary format is a place for security vulnerabilities, crashes and hangs. The web is actively hostile place for web browsers.
That's the cost for the maintainers. Codecs are historically one of the most problematic sources of security issues (they're complex code that handles malicious downloaded files) and supporting a new one is a rather big maintenance burden for everyone involved.
And if Chrome gets backdoored by a JXL library security hole, everyone will blame Google for it.
If, by any chance, supporting JXL becomes too much of a burden, everyone will again blame Google for being evil if they ever remove it from Chrome.
I bet after (re)introduction, most of people yelling for it won't actually convert their JPEGs to XL. Just like almost noone whining about Reader actually uses or pays for any of the alternatives.
The idea is converting workflows to JPEG XL (and particularly to enable uses for which JPEG isn’t suitable and even AVIF is supposedly less optimal), not converting existing JPEGs, mainly.
It's always a pain in the ass when you discover your phone has actually been saving your photos as heic or webp or avif or whatever and hardly anything will open them.
I could understand wanting to improve JPEG in the age of dial-up and 1.44MB floppy disks - 60% smaller images could have been a great benefit in those days. But today, even if I'm taking 30 photos every day at 4k resolution, it'd take 20 years to fill up a $50 1TB disk.
The other benefits of the format might be great for some specialist applications, but options like billion-pixel-wide images, 32 bits per channel and 4099 channels ready for medical imaging only get a shrug from me. I doubt my browser is going to start displaying 4099 channel images.
I just wish we could get rid of heic, webp and avif at the same time.
you also very clearly don't care about the entire internet experience, at all, whatsoever.
Edit: 60% space savings only available in the age of the floppy.... what? 60% cost savings when serving multiple terabytes of image data is useless?
You seem to view everything through the extremely tiny lens of a photographer or something... pun intended
60% smaller images are great for hosting providers. We have ample storage and bandwidth compared to the 90s, but it still ain't that cheap.
Everything about computer imagery is pretty sadly limited when compared to the capabilities of human eyes and brains. And for quite some time now the ends of the pipeline (camera sensors and computer displays) have been improving, but are bottlenecked by the middle of the pipeline (image formats).
AVIF was the first format accepted by the web that supports HDR (not already tone-mapped HDR, true HDR.) Which maybe you don't personally care about, but is something that fundamentally cannot be done with existing JPEG and PNG implementations.
AVIF might not have happened, and the above paragraph might have read "HEIC", if HEVC had had similar licensing terms as H.264. But there's no predicting that stuff before it happens.