-WebP 2 is the successor of the WebP image format, currently in development. It
-is not ready for general use, and the format is not finalized so changes to the
-library can break compatibility with images encoded with previous versions. \
-USE AT YOU OWN RISK!
+WebP 2 is an experimental image codec based on WebP. WebP 2 will not be released
+as an image format but is used as a playground for image compression
+experiments.
I dont see why its so odd. Looks like it was behind a feature flag. I imagine the time came where someone had to make a go/no-go call, and they decided no-go.
It wouldnt make sense to keep it as a feature flag forever, and once it is not a feature flag it becomes much harder to backout.
Don't hold your breath. Big G would prefer you use WebP and their other nearly-proprietary formats nobody wanted but they are pushing into wide use through the might of operating the most widely used browser.
But maybe if enough people finally stop using their spyware browser, there will be some hope.
I have other things I judge companies for. I just assume I'm not allowed to do anything personal on a work laptop if they manage every aspect of it. I understand why they do it, however, the only thing I find unethical about it is how much companies have balked at explaining the depths to which they track internal employees.
What proprietary video/image formats does Google have? As far as I know all their image and video formats are open, including WebP. Heck, according to Wikipedia JPEG XL was also partly driven by Google.
WebP was only developed by Google or a company Google ended up buying. Yes, the standard is freely available, but there was no collaboration, no open process of asking people's input, etc.
I tried WebP because lighthouse heavily pushes it claiming big size reductions, the asterisk for those claims is of course way worse quality. Visually identical quality to JPEG only gave irrelevant improvements or none at all - 10 % or so are not worth the hassle over JPEG. Lighthouse also pushes WebP for PNGs but that of course falls flat on its face due to chroma subsampling.
Maybe WebP is better than JPEG at low quality levels, but that’s not something I care about, what with not being in the streaming video biz.
It is unbelievable that it gives big red scores for not using WebP but apparently it's not an honest judgement but an attempt to push the format by abusing its search market share.
Should be noted that it's also behind a feature flag in Firefox (only in nightly!) and while basic support is there(no color profile support), further development doesn't appear to be happening and it's low priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
EDIT: Why the downvotes? This is the status on Mozilla's end for at least a year. If none of the browser developers care to push support, then the format is effectively dead.
Frankly, the official justification[1] for the deprecation is ridiculous.
> There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
In the very same ticket that comment was made, the companies such as Adobe, Facebook, The Guardian and Shopify voiced their support for the format. In fact, Adobe has just added support for JPEG XL to Camera Raw[2]. Also, Cloudflare[3] and Flickr[4] endorsed JXL in Mozilla's bugtrackers.
Plenty of open-source projects have implemented support for JXL images. For example: ExifTool[5], FFmpeg[6], GIMP[7], ImageMagick[8], Krita[9].
Is this really "not enough interest"?
> The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
The ability to losslessly recompress already exisiting JPEG images is the killer feature of JPEG XL. It allows seamless transition to the new format by converting old images. AVIF can't do that.
To be honest, their explanations feel like post-hoc rationalizations. It seems Google invested too much into an inferior format (AVIF) and now because of the sunk cost fallacy they can't pivot to JPEG XL.
In the very same ticket that comment was made, the companies such as Adobe, Facebook, The Guardian and Shopify voiced their support for the format.
Notice that Apple and Mozilla are not on this list. Unless other browser makers are onboard, it’s probably not going to happen.
Also, neither W3C or WHATWG, the web standards bodies are on the list. Also not a good sign.
Of course, Google just ships what they feel like all the time; if they really wanted JPEG XL, they would just do it. But they obviously don’t feel that strongly about it.
If you want to wait for W3C to approve a new codec, good luck with that.
Looking at https://www.w3.org/Graphics/, I see only PNG, JPEG, GIF and SVG mentioned. For adding WebP and AVIF to Chrome this was not an issue.
Regarding Mozilla: there is preliminary JXL support in Firefox, also behind a flag. So if Chrome would enable it, Firefox would likely follow quickly. But given their respective market shares, it is not surprising to me that Firefox does not have the audacity to push JXL when Chrome devs are clearly trying to block it.
As for Apple/Safari: there is JXL support in WebKit behind a compile flag, so if Chrome would enable, they could also follow quickly. It does not surprise me that Apple is not taking any public position on this — they rarely announce their plans before they are ready to ship.
In any case, if the list of supporters in that bugtracker is considered "insufficient", then I think Chrome devs have unreasonably high expectations. The issue is not that "the ecosystem" is not interested. The issue is that the Chrome decision makers don't want it to get traction, for whatever reasons they clearly don't really want to disclose but that can be guessed:
Firefox has had basic support behind a flag for a good while, but it needs some work -- their code is missing things like transparency and colour profiles. Sadly mozilla have laid off a lot of their dev team and they don't have much capacity right now.
Safari have support as a build-time option, apparently.
libvips has had libjxl support for a couple of years now, including in our fuzzing and build systems. Everything is pretty much ready to roll, and would have brought support to downstream projects and users like sharp, ActiveRecord, imaginary, Shopify, etc.
We've just been waiting for Chrome to flip the switch and start deployment, To have support pulled like this at the last second is extremely disappointing.
It so much amazes me. 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 software limitations we're still cutting off all the HDR data when saving our precious memories as JPEG. All whites become #fffff. The color 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.
Insufficient adoption is the cudgel that murders most good web work. Another fine effort given an order of magnitude less soak time & exploration time than it deserves.
The web platform cannot be run like an app platform: hockeystick adoption in 18 months or death. But right now we rely on corporate patrons (browser makers) to invest in & support the vast vast majority of progress on the web. The time domains don't match up. Yet there are no examples of alternative ways we might support & fund such core vital human communications.
There are actually good reasons for not shipping JPEG XL in web browsers, but the comment doesn't list one. In particular it compares JPEG XL with "existing formats", which seemingly include AVIF, but almost identical arguments could have been used to not ship AVIF in web browsers after all. Essentially it says that they happened to pick AVIF for no apparent reason and because of that they can't pick JPEG XL for no apparent reason again. The comment lacks substances, if not dishonest.
> Essentially it says that they happened to pick AVIF for no apparent reason and because of that they can't pick JPEG XL for no apparent reason again
Sounds pretty valid to me. Sometimes you just have to pick a solution. Having every possible format supported does not make sense. If AVIF fills the usecase, no point having both.
It would make sense for Chrome not to include JPEG XL in the first place with some list of explicit reasons. It does not make sense to implement it, hide behind a flag, and then remove, claiming there is not enough interest -- when there's no way to reliably gauge interest from this "experiment".
Indeed, the proper way to gauge the interest would be Origin Trial (OT), as noted by one of Blink API owners [1] who is also responsible for Edge at Microsoft.
If one wants to speculate, timing wise, this correlates with the recent release of iOS 16 (September 2022) and macOS 13 (October 2022), which have added AVIF support to Safari. That event in turn means that now most browsers support AVIF.
This is indeed one of "good reasons" that can prefer AVIF over JPEG XL (but not a good reason to not ship JPEG XL). Safari is the most difficult vendor to work with, so if Safari can be convinced there is no bigger obstacle waiting. But it should be noted that Safari still does not support AV1 on which AVIF is based and that fact didn't prevent other browsers from adding support for that video format anyway.
Here's some of the features I am looking forward to in JXL.
Better lossy compression than JPG, similar compression to AVIF. AVIF ekes out a little more quality at the very low end, and JXL excels at the very high end.
Better lossless compression than PNG.
Supports alpha channels.
Supports parallel decoding.
Significantly faster encoding than other formats like AVIF.
Supports multiple colour spaces and formats, allowing for HDR images.
The colour in JXL is stored in the XYB colour space. A dev states that this colour space gives more bits to darker colours, leading to better encoded dark skin at similar filesizes to other codecs [1].
Supports up to 4096 channels. A practical use of this is in 3D workflows with Physically Based Rendering textures, where a texture has channels for albedo, normal map, reflection, roughness, metalness, and others. They could be compressed into one JXL, much smaller than an EXR with the same channels.
Supports losslessly recompressing existing JPGs into JXL to save space. Those files can also be losslessly (ie byte exact) converted back to JPGs.
Supports progressive decoding. AVIF crucially does _not_ have this.
Progressive decoding also allows for Responsive Images. No longer would you have to encode two images, like 1x or 2x. Encode the 2x image once – you can serve the 1x image _from the 2x image_. Huge feature if browsers were on board.
Supports rudimentary animation (similar to MJPEG, ie only i-frames). Use AVIF for animations.
Has frames/layers. This is a pretty cool feature for an image format. I can see two main uses of this:
1. Non-destructive editing. If you want to add an overlay to a JPG, you have to re-encode the image. JXL allows you to add another frame on-top of the other image, without touching the original.
2. Hybrid lossless/lossy images. For example, a screenshot of a UI that contains a photograph. The UI could be losslessly compressed, and the photo could be lossy-ly compressed. There is already an experimental program within the JXL source that does this.
> Supports progressive decoding. AVIF crucially does _not_ have this.
How important is this in the modern world? Like, GIF, PNG, (progressive) JPG all support this, yet i dont think i have ever noticed this in practise in modern times unless artificially rate limiting my connection. It seems more like a relic from the time of dial up internet.
> i dont think i have ever noticed this in practise in modern times unless artificially rate limiting my connection.
I see a lot of loading even when I'm using a pretty fast broadband (fast.com says that my ISP is 350 Mbps down and 450 Mbps up). The network speed is a function of your ISP and the target host's ISP (and everything in between), and you can't control the latter. If you haven't actually noticed anything, you may well have avoided websites that are slow from your ISP, either by a luck or unconsciously.
Anyway, srcset is the very obvious evidence that progressive decoding is actually needed but hindered by the lack of image format features or browser supports so it settled on a compromise.
Do you sometimes go outdoors to an area that has poor connectivity?
Not all of the modern world has the same kind of network speed.
If all pages would always load in less than 0.1 seconds for every web user, I would agree with you. But this is not the case, and I doubt it ever will be considering that web pages seem to get heavier faster than how quickly the network is getting faster for the median web user.
here is FUIF (one of JXL parents) author writing about benefits of progressive: https://github.com/cloudinary/fuif
In short, unlike progressive JPEG, you can serve truncated image files to get lower resolutions
This is pure politics. The AOM want proof of loyalty and shipping a competing image format threatens that loyalty pact.
It’s also incrementalism at its finest. “We already shipped av1, adding a single frame decode is minor overhead” is the likely rationale. But it misses the point that images are gazed at while video is moving and can get away with a lot of quality sins that you can’t with images. But worse is that av1 is full of optional features. Sure the client could implement it, but how can you know? Even the lauded animated avif is horribly broken across the ecosystem because of this optionality — and there isn’t any way to tell a priori if the browser can support animated avif. Or 444 avif. Or ycocg avif. It’s just down right broken as an image format falling to the lowest common denominator.
While I agree that it is too early to turn to a conspiracy theory, the supposed rationale against JPEG XL is also pretty unsubstantiated and it does feel that the Chrome team doesn't want to share the actual rationale for whatever reason.
Google's rationale is very weak, yes. But it makes no sense to say that this is the AOM pushing Google to do this as a proof of loyalty. Why wouldn't the same apply to Apple and Mozilla? In fact, if deprecating JPEG-XL is something the AOM wants, wouldn't you expect the browser vendors (all of whom are AOM founders) to all conspire to kill JPEG-XL? The right conspiracy theory here isn't even that AOM is forcing Google to do this as a proof of loyalty, the conspiracy theory which at least makes some semblance of sense is that Apple, Google and Mozilla are working to kill JPEG-XL to help their own image format win. But then it's just a group of companies acting in their own self interest and not some coercion, so I suppose that story isn't as sexy.
Any time the AOM is mentioned people keep talking about how evil AV1 is and how evil Google is for pushing AV1 through YouTube, and those comments are consistently among the most upvoted comments. I'd say it's safe to say there's a decent amount of hatred being expressed, and I just don't understand it. It's almost as if a decent chunk of the HN audience has a vested interest in eliminating open patent-free media codecs.
> HN audience has a vested interest in eliminating open patent-free media codecs.
Well, first, because in the case of AV1, a self claimed patent free Video Codec is not, and never was, patent free. ( They stopped claiming to be one since around 2019 ).
Second, the AV1 is evil or evil Google ( I dont think they said it but you could argue they do implied that ) you were referring to is very recent. To the point it was this month on HN. But yes, it has grown, quite a bit in the past year or so.
Third, because a few HN audience actually cares about quality and trade offs. One could argue VP9 being a royalty free codec is actually a better fit than AV1. And despite being so called Open, Google isn't very receptive to criticism of AV1. Whether it was the codec itself or its development model.
Had Google ( or AOM ) actually worked on AV2 [1] with all these in mind, may be there wouldn't be as much backlash.
[1] AV2 was originally promised to be out by 2020.
I don't understand why you and everyone else put so much focus on Google. AV1 is developed by the AOM, so why would Google be receptive to criticism of AV1? Why is it Google's responsibility to develop AV2? People keep directing (well-deserved) criticism of Google towards AV1/AOM, and in your comment you're directing criticism of AV1/AOM towards Google. Is Amazon, Cisco, Intel, Mozilla, Apple, Microsoft, Nvidia, ARM, Netflix, Samsung, Facebook, etc etc. truly so insignificant in this that AOM and Google are basically one and the same? Why would that huge group of absolutely enormous companies let themselves be bossed around by Google?
Regarding patents: my understanding is that AV1, like VP9 but unlike H.265, is unencumbered by patents, and you can use AV1 in products and FOSS projects without paying a license/royalties. Is this incorrect? If so, why has nobody updated Wikipedia? They still list AV1 as a royalty-free codec. If it truly is just as parent encumbered as H.265 then I agree with all the criticism, and our best bet is to stick with the very first version of H.264 (whose parents will expire next year) and JPEG. Because surely any patents which apply to AV1 also apply to its predecessors VP8 and VP9.
>Why would that huge group of absolutely enormous companies let themselves be bossed around by Google
Well first AV1, is practically 90% VP10, On2 hence Google. Second Those companies didn't contribute to AV1 development. They are merely supporting it.
>unencumbered by patents
unencumbered by patents is not patent free. Which is what confuse a lot of people. ( I guess, or I hope ). Google has lots of patents on AV1. Even when creators of the technique dont want it to be patented [1]. The AOM as group are there together so they dont sue each other on patents, and will sue ( cough defense ) anyone who challenge them on patents.
If I were a competitor browser vendor, I'd retaliate by removing Webp and AVIF support. But of course, who are we kidding? There are no competitors, only paint jobs and a dog on leash.
Why? The other browser vendors don't ship JPEG-XL either, and all the other browser vendors are fully on board with AVIF. Why would it be in their interest to remove AVIF support?
It wouldn't be in their interest, but wouldn't be in their disinterest, either. Thus why it'd be an appropriate retaliation... in a hypothetical competitive environment... which we don't have. Because as I said, only paint jobs and a leash dog.
It is in the entire web community's interest to have a good, non-patent-encumbered, open image (and video) encoding standard. Killing off the only shot we currently have at that seems to be in the disinterest of the minority browser vendors.
People are speculating that this is in preparation of Google introducing their own Google-controlled replacement for JPEG-XL, or pushing WebP harder. I don't know if I buy that, but the more widespread AVIF is, the less power does Google have to unilaterally develop a replacement. And it's in the other vendors' disinterest to give Google unilateral control over even more of the web.
> good, non-patent-encumbered, open image encoding standard
yet they won't be supporting it.
Whether you want to buy it or not, de-facto format on the web is JPEG and only JPEG, thanks to the historical momentum. Even webp is still expendable, because Mozilla and Microsoft hold long enough. And AVIF isn't being used anywhere, yet. So no, it isn't in other vendors' disinterest to drop support for Webp and AVIF, because JPEG would continue to be de-facto in that case.
Of course JPEG-XL is a good, (maybe?) non-patent-encumbered, open image encoding standard, but with this move from Google, it's no longer a candidate to be a universal one (unless Google reverses their decision when the reference implementation library becomes more mature). AVIF is still a candidate for a universal, good, non-patent-encumbered open image encoding standard.
> AVIF is still a candidate for a universal, good, non-patent-encumbered open image encoding standard.
Yes, which is why it'd be appropriate by others to remove it as a retaliation which would make JPEG continue its defacto status.
And I've repeated it again and again it is an hypothetical scenario and I'm aware we're unfortunately not the reality we're living in, so I'm not sure what you're gaining from still arguing with me. You should've read my first comment as if it's old man yelling at clouds and move on.
Why is it a better situation to continue with JPEG as the ubiquitous standard than to replace it with a technically superior but equally open alternative? I'm not understanding what you want, or who you think gains something by shooting down the best candidate to replace JPEG.
> Why is it a better situation to continue with JPEG
As a retaliation. Retaliation isn't supposed to be a good thing or move things forward. It is supposed to be a calculated action against your opponent. I'm not talking in business context, I'm talking about in diplomacy context.
In this case it'd mean "if Google doesn't want to go with the industry standard replacement JPEG-XL route we won't be going with Webp or its descendant AVIF and instead and keep the JPEG-only statuesque." (and it's not that they'd be losing anything in business context either, by supporting jpeg-only de-facto)
I don't know how can I be more clear than that, so please I beg you to move on.
That's exactly what I don't understand I suppose. AVIF has nothing to do with Google, so I'm not sure why it's a retaliation. Dropping support for WebP and WebM would be more of a retaliation, since those are actually formats developed and pushed by Google. But Google has nothing to lose and everything to gain if other browsers kill AVIF and leave WebP as the only JPEG replacement.
But alright, I will move on. You don't have to respond.
Twenty years ago, PNG wasn't really supported by any popular browsers of the day, but it showed its capabilities (especially compared to GIF) and was eventually incorporated. I'm assuming that you'll also say to me "You planned to move your entire business to a feature that has thus far never been shipped by any browser?"
In a more serious manner, JXL has features that both WebP and AVIF don't. Lossless images simply compress better with JXL than WebP (and if you in these circles you know to not bother with AVIF's lossless mode - even PNG beats AVIF in that arena). I know Google uses near-lossless images for their icons, but near-lossless wouldn't cut when it comes for medical diagnostics or meteorological uses. It has progressive loading, which WebP and AVIF don't really have. Speaking of near-lossless, WebP don't support 4:4:4 chroma subsampling while AVIF technically does but no encoder AFAIK focuses on it. Also, WebP only allows 16,384 pixels per side and AVIF only allows 65,536 pixels per side (which to be fair is the same as the original JPEG), while JXL allows 1,073,741,824 pixels per side (which is ludicrous, but considering that JPEG's 65,536 pixels per side was ludicrous at the time is good for future-proofing). There are also niche features which both WebP and AVIF don't have.
While I think that someone at Google was thinking that since AVIF beats JXL on compression at low bitrates there is no demand for JXL, that is a very narrow way of thinking. Not everyone is looking for bandwidth savings, some are looking that current image formats simply don't represent the things that they need (especially that most large companies have focused on "squeeze up the quality for lower bits").
> Twenty years ago, PNG wasn't really supported by any popular browsers of the day, but it showed its capabilities (especially compared to GIF) and was eventually incorporated. I'm assuming that you'll also say to me "You planned to move your entire business to a feature that has thus far never been shipped by any browser?"
That's rewriting history a bit. There was a long gap between 1997 when png was added and when people started to really use it. A lot of it due to issues with transparency in internet explorer.
But yes, if you in 1996 said you were moving your entire business to png, i would similarly think that is an odd move.
More generally moving your business to something that doesn't exist yet is usually pretty dangerous. Moving your business to something that both doesn't exist and that nobody has promised to for sure implement seems downright risky.
We've evaluated AVIF and JPEG XL, with JXL coming out on top.
As others (Shopify for example) has mentioned, JPEG XL has some advantages (quick decoding, lossless conversion from JPEG, progressive decoding).
My point was that Google says there is "no demand", and we (as an example) have planned moving to a new image format, with JPEG XL as the front-runner. Them saying there is "no demand" is just because there isn't a browser yet that supports the format.
But as soon as there is one, we (and many others) could pull the trigger and suddenly there would be a lot of demand and usage (since other browsers can still be served with other image formats).
>We've evaluated AVIF and JPEG XL, with JXL coming out on top.
I would love to see blog post on it. ( Or against it even, we just need good discussions ) But as far as I am know, regardless of politics or ideology, JPEG XL is technically superior to AVIF. And its current reference implementation, isn't even tuned for the best case in many scenarios.
Not a common need but I appreciated the larger supported size (over the 65K limit of jpeg). Once I hit the limit with jpg I switched to png, since JPEGXL is not yet ready, and had to resort to png optimizer to get the size to something close to jpg. So I was looking forward to JPEGXL.
Since that it seems that you're okay with lossy images, have you've tried RDOPNG (https://github.com/richgel999/rdopng)? It won't be as great as JPEG or JXL but it should eke out better-compressed images.
I use tiled TIFF with jpeg compression for things like this. You get good compression, support for huge sizes, and wide compatibility. TIFF supports image pyramids too, so you can even get good interactive performance.
No direct web browser support is the only big downside :(
> In terms of compression performance JPEG XL is really good, but I'm concerned that it does not have more than a single implementation.
> W3C's bar for web standard recommendations is having at least two independent implementations. AVIF has multiple interoperable implementations in multiple languages. JPEG XL doesn't have yet.
> Given the substantial complexity and scope of the JPEG XL format, I'd like to see a proof that a second implementation is possible, and that it's interoperable, so that the Web platform doesn't end needing bug-compatibility with a single C++ codebase.
It is not entirely correct. There is a C (j40.c) and two C++ implementations (libjxl and libjxl-tiny). Kornel would love to see a Rust implementation I believe.
I'm the author of J40 and it was intentionally developed from scratch exactly in order to remedy the situation where libjxl serves as a de facto specification as opposed to the actual specification.
A Wasm implementation of JPEG XL is 174 kB, and a minimal implementation (reflecting the libjxl-tiny encoder) can be done in somewhere around 25-50 kB. Wasm is rather performant and can render both normal and HDR JPEG XL's in browsers.
97 comments
[ 3.0 ms ] story [ 168 ms ] thread[1] https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
Gee. Maybe there's no interest because nobody can use it yet because it's behind a feature flag.
It wouldnt make sense to keep it as a feature flag forever, and once it is not a feature flag it becomes much harder to backout.
They didn't struggle with removing H2 PUSH though.
H2 push is also something that degrades much more gracefully if missing compared to an image codec.
Nonetheless, people haved removed image codecs before (rip XBM). Harder is not the same as impossible.
Not anytime soon.
Every picture taken with the stock iOS Camera app is saved in HEIC. That’s billions of HEIC files.
But maybe if enough people finally stop using their spyware browser, there will be some hope.
Nearly every company I've worked for requires the use of Chrome because they can manage it.
Maybe WebP is better than JPEG at low quality levels, but that’s not something I care about, what with not being in the streaming video biz.
Since v91 or so.
EDIT: Why the downvotes? This is the status on Mozilla's end for at least a year. If none of the browser developers care to push support, then the format is effectively dead.
> There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL
In the very same ticket that comment was made, the companies such as Adobe, Facebook, The Guardian and Shopify voiced their support for the format. In fact, Adobe has just added support for JPEG XL to Camera Raw[2]. Also, Cloudflare[3] and Flickr[4] endorsed JXL in Mozilla's bugtrackers.
Plenty of open-source projects have implemented support for JXL images. For example: ExifTool[5], FFmpeg[6], GIMP[7], ImageMagick[8], Krita[9].
Is this really "not enough interest"?
> The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
The ability to losslessly recompress already exisiting JPEG images is the killer feature of JPEG XL. It allows seamless transition to the new format by converting old images. AVIF can't do that.
To be honest, their explanations feel like post-hoc rationalizations. It seems Google invested too much into an inferior format (AVIF) and now because of the sunk cost fallacy they can't pivot to JPEG XL.
[1] - https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
[2] - https://helpx.adobe.com/camera-raw/using/hdr-output.html
[3] - https://github.com/mozilla/standards-positions/issues/522#is...
[4] - https://bugzilla.mozilla.org/show_bug.cgi?id=1539075#c23
[5] - https://github.com/exiftool/exiftool/blob/master/Changes#L44...
[6] - https://git.videolan.org/?p=ffmpeg.git;a=commit;h=0008c15956...
[7] - https://www.gimp.org/news/2021/10/20/gimp-2-99-8-released/#i...
[8] - https://imagemagick.org/script/formats.php
[9] - https://docs.krita.org/en/general_concepts/file_formats/file...
Notice that Apple and Mozilla are not on this list. Unless other browser makers are onboard, it’s probably not going to happen.
Also, neither W3C or WHATWG, the web standards bodies are on the list. Also not a good sign.
Of course, Google just ships what they feel like all the time; if they really wanted JPEG XL, they would just do it. But they obviously don’t feel that strongly about it.
Regarding Mozilla: there is preliminary JXL support in Firefox, also behind a flag. So if Chrome would enable it, Firefox would likely follow quickly. But given their respective market shares, it is not surprising to me that Firefox does not have the audacity to push JXL when Chrome devs are clearly trying to block it.
As for Apple/Safari: there is JXL support in WebKit behind a compile flag, so if Chrome would enable, they could also follow quickly. It does not surprise me that Apple is not taking any public position on this — they rarely announce their plans before they are ready to ship.
In any case, if the list of supporters in that bugtracker is considered "insufficient", then I think Chrome devs have unreasonably high expectations. The issue is not that "the ecosystem" is not interested. The issue is that the Chrome decision makers don't want it to get traction, for whatever reasons they clearly don't really want to disclose but that can be guessed:
The key Chrome decision maker on codec related things seems to be this person: https://www.linkedin.com/in/jimbankoski/ This is the same person that was also heavily involved in VP8/WebP and AV1/AVIF: https://research.google/people/105284/ To me this looks like a rather obvious conflict of interest.
It doesn't have to be or should be Google to lead the adoption of something.
Safari have support as a build-time option, apparently.
We've just been waiting for Chrome to flip the switch and start deployment, To have support pulled like this at the last second is extremely disappointing.
All the hardware is there ready for the future. Yet due to software limitations we're still cutting off all the HDR data when saving our precious memories as JPEG. All whites become #fffff. The color 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.
> I’d still recommend including JPEG XL versions of your images, because chances are that browser support will come eventually.
https://jfhr.me/optimizing-images-with-the-html-picture-tag/
So maybe I'm missing something.
I've found it very challenging to get better compression than optimized JPEG via Squoosh.
https://squoosh.app/
Of course, JPEG XL has alpha channels, and I'm comparing a new format against a standard that's had 20 years of refinement in implementation.
Are we cutting ourselves off from a similar future with JPEG XL?
(via https://news.ycombinator.com/item?id=33400436, but no comments there)
The web platform cannot be run like an app platform: hockeystick adoption in 18 months or death. But right now we rely on corporate patrons (browser makers) to invest in & support the vast vast majority of progress on the web. The time domains don't match up. Yet there are no examples of alternative ways we might support & fund such core vital human communications.
Sounds pretty valid to me. Sometimes you just have to pick a solution. Having every possible format supported does not make sense. If AVIF fills the usecase, no point having both.
[1] https://twitter.com/slightlylate/status/1587030785197953024
Better lossy compression than JPG, similar compression to AVIF. AVIF ekes out a little more quality at the very low end, and JXL excels at the very high end.
Better lossless compression than PNG.
Supports alpha channels.
Supports parallel decoding.
Significantly faster encoding than other formats like AVIF.
Supports multiple colour spaces and formats, allowing for HDR images.
The colour in JXL is stored in the XYB colour space. A dev states that this colour space gives more bits to darker colours, leading to better encoded dark skin at similar filesizes to other codecs [1].
Supports up to 4096 channels. A practical use of this is in 3D workflows with Physically Based Rendering textures, where a texture has channels for albedo, normal map, reflection, roughness, metalness, and others. They could be compressed into one JXL, much smaller than an EXR with the same channels.
Supports losslessly recompressing existing JPGs into JXL to save space. Those files can also be losslessly (ie byte exact) converted back to JPGs.
Supports progressive decoding. AVIF crucially does _not_ have this.
Progressive decoding also allows for Responsive Images. No longer would you have to encode two images, like 1x or 2x. Encode the 2x image once – you can serve the 1x image _from the 2x image_. Huge feature if browsers were on board.
Supports rudimentary animation (similar to MJPEG, ie only i-frames). Use AVIF for animations.
Has frames/layers. This is a pretty cool feature for an image format. I can see two main uses of this:
1. Non-destructive editing. If you want to add an overlay to a JPG, you have to re-encode the image. JXL allows you to add another frame on-top of the other image, without touching the original.
2. Hybrid lossless/lossy images. For example, a screenshot of a UI that contains a photograph. The UI could be losslessly compressed, and the photo could be lossy-ly compressed. There is already an experimental program within the JXL source that does this.
[1] https://mobile.twitter.com/jonsneyers/status/155021585930558...
In reality, they have webp which is enough for most of the use cases
How important is this in the modern world? Like, GIF, PNG, (progressive) JPG all support this, yet i dont think i have ever noticed this in practise in modern times unless artificially rate limiting my connection. It seems more like a relic from the time of dial up internet.
I see a lot of loading even when I'm using a pretty fast broadband (fast.com says that my ISP is 350 Mbps down and 450 Mbps up). The network speed is a function of your ISP and the target host's ISP (and everything in between), and you can't control the latter. If you haven't actually noticed anything, you may well have avoided websites that are slow from your ISP, either by a luck or unconsciously.
Anyway, srcset is the very obvious evidence that progressive decoding is actually needed but hindered by the lack of image format features or browser supports so it settled on a compromise.
Not all of the modern world has the same kind of network speed.
If all pages would always load in less than 0.1 seconds for every web user, I would agree with you. But this is not the case, and I doubt it ever will be considering that web pages seem to get heavier faster than how quickly the network is getting faster for the median web user.
It’s also incrementalism at its finest. “We already shipped av1, adding a single frame decode is minor overhead” is the likely rationale. But it misses the point that images are gazed at while video is moving and can get away with a lot of quality sins that you can’t with images. But worse is that av1 is full of optional features. Sure the client could implement it, but how can you know? Even the lauded animated avif is horribly broken across the ecosystem because of this optionality — and there isn’t any way to tell a priori if the browser can support animated avif. Or 444 avif. Or ycocg avif. It’s just down right broken as an image format falling to the lowest common denominator.
Fierce hatred? Literally 95%+ ( if not 99% ) of HN called for AV1 and AVIF support in browser for the past 5+ years.
AOM, Rust and RISC-V, any discussions of alternatives are deemed to be not worthy or evil.
Well, first, because in the case of AV1, a self claimed patent free Video Codec is not, and never was, patent free. ( They stopped claiming to be one since around 2019 ).
Second, the AV1 is evil or evil Google ( I dont think they said it but you could argue they do implied that ) you were referring to is very recent. To the point it was this month on HN. But yes, it has grown, quite a bit in the past year or so.
Third, because a few HN audience actually cares about quality and trade offs. One could argue VP9 being a royalty free codec is actually a better fit than AV1. And despite being so called Open, Google isn't very receptive to criticism of AV1. Whether it was the codec itself or its development model.
Had Google ( or AOM ) actually worked on AV2 [1] with all these in mind, may be there wouldn't be as much backlash.
[1] AV2 was originally promised to be out by 2020.
Regarding patents: my understanding is that AV1, like VP9 but unlike H.265, is unencumbered by patents, and you can use AV1 in products and FOSS projects without paying a license/royalties. Is this incorrect? If so, why has nobody updated Wikipedia? They still list AV1 as a royalty-free codec. If it truly is just as parent encumbered as H.265 then I agree with all the criticism, and our best bet is to stick with the very first version of H.264 (whose parents will expire next year) and JPEG. Because surely any patents which apply to AV1 also apply to its predecessors VP8 and VP9.
Well first AV1, is practically 90% VP10, On2 hence Google. Second Those companies didn't contribute to AV1 development. They are merely supporting it.
>unencumbered by patents
unencumbered by patents is not patent free. Which is what confuse a lot of people. ( I guess, or I hope ). Google has lots of patents on AV1. Even when creators of the technique dont want it to be patented [1]. The AOM as group are there together so they dont sue each other on patents, and will sue ( cough defense ) anyone who challenge them on patents.
[1] https://arstechnica.com/tech-policy/2018/06/inventor-says-go...
If I were a competitor browser vendor, I'd retaliate by removing Webp and AVIF support. But of course, who are we kidding? There are no competitors, only paint jobs and a dog on leash.
People are speculating that this is in preparation of Google introducing their own Google-controlled replacement for JPEG-XL, or pushing WebP harder. I don't know if I buy that, but the more widespread AVIF is, the less power does Google have to unilaterally develop a replacement. And it's in the other vendors' disinterest to give Google unilateral control over even more of the web.
> good, non-patent-encumbered, open image encoding standard
yet they won't be supporting it.
Whether you want to buy it or not, de-facto format on the web is JPEG and only JPEG, thanks to the historical momentum. Even webp is still expendable, because Mozilla and Microsoft hold long enough. And AVIF isn't being used anywhere, yet. So no, it isn't in other vendors' disinterest to drop support for Webp and AVIF, because JPEG would continue to be de-facto in that case.
Yes, which is why it'd be appropriate by others to remove it as a retaliation which would make JPEG continue its defacto status.
And I've repeated it again and again it is an hypothetical scenario and I'm aware we're unfortunately not the reality we're living in, so I'm not sure what you're gaining from still arguing with me. You should've read my first comment as if it's old man yelling at clouds and move on.
As a retaliation. Retaliation isn't supposed to be a good thing or move things forward. It is supposed to be a calculated action against your opponent. I'm not talking in business context, I'm talking about in diplomacy context.
In this case it'd mean "if Google doesn't want to go with the industry standard replacement JPEG-XL route we won't be going with Webp or its descendant AVIF and instead and keep the JPEG-only statuesque." (and it's not that they'd be losing anything in business context either, by supporting jpeg-only de-facto)
I don't know how can I be more clear than that, so please I beg you to move on.
But alright, I will move on. You don't have to respond.
That's where we disagree, then.
- Technically a compelling format.
- Parallel decoding.
- Progressive decoding (no need for 'placeholder images').
- Lossless better than PNG and lossy better than JPG.
- Better than AVIF in the 'high quality' end of the spectrum.
- Lossless recompression of JPEG into JXL.
- Fast enough for on-the-fly conversion to JPEG for backwards compatibility.
People from Facebook, Shopify, Adobe, Intel and other huge companies have also voiced their support and said it's on various internal roadmaps.
I hope this decision gets reverted. Seems like a huge mistake!
In a more serious manner, JXL has features that both WebP and AVIF don't. Lossless images simply compress better with JXL than WebP (and if you in these circles you know to not bother with AVIF's lossless mode - even PNG beats AVIF in that arena). I know Google uses near-lossless images for their icons, but near-lossless wouldn't cut when it comes for medical diagnostics or meteorological uses. It has progressive loading, which WebP and AVIF don't really have. Speaking of near-lossless, WebP don't support 4:4:4 chroma subsampling while AVIF technically does but no encoder AFAIK focuses on it. Also, WebP only allows 16,384 pixels per side and AVIF only allows 65,536 pixels per side (which to be fair is the same as the original JPEG), while JXL allows 1,073,741,824 pixels per side (which is ludicrous, but considering that JPEG's 65,536 pixels per side was ludicrous at the time is good for future-proofing). There are also niche features which both WebP and AVIF don't have.
While I think that someone at Google was thinking that since AVIF beats JXL on compression at low bitrates there is no demand for JXL, that is a very narrow way of thinking. Not everyone is looking for bandwidth savings, some are looking that current image formats simply don't represent the things that they need (especially that most large companies have focused on "squeeze up the quality for lower bits").
That's rewriting history a bit. There was a long gap between 1997 when png was added and when people started to really use it. A lot of it due to issues with transparency in internet explorer.
But yes, if you in 1996 said you were moving your entire business to png, i would similarly think that is an odd move.
More generally moving your business to something that doesn't exist yet is usually pretty dangerous. Moving your business to something that both doesn't exist and that nobody has promised to for sure implement seems downright risky.
We've evaluated AVIF and JPEG XL, with JXL coming out on top.
As others (Shopify for example) has mentioned, JPEG XL has some advantages (quick decoding, lossless conversion from JPEG, progressive decoding).
My point was that Google says there is "no demand", and we (as an example) have planned moving to a new image format, with JPEG XL as the front-runner. Them saying there is "no demand" is just because there isn't a browser yet that supports the format.
But as soon as there is one, we (and many others) could pull the trigger and suddenly there would be a lot of demand and usage (since other browsers can still be served with other image formats).
I would love to see blog post on it. ( Or against it even, we just need good discussions ) But as far as I am know, regardless of politics or ideology, JPEG XL is technically superior to AVIF. And its current reference implementation, isn't even tuned for the best case in many scenarios.
And yet here we are. There are no-demand for it.
Since that it seems that you're okay with lossy images, have you've tried RDOPNG (https://github.com/richgel999/rdopng)? It won't be as great as JPEG or JXL but it should eke out better-compressed images.
No direct web browser support is the only big downside :(
https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
> In terms of compression performance JPEG XL is really good, but I'm concerned that it does not have more than a single implementation.
> W3C's bar for web standard recommendations is having at least two independent implementations. AVIF has multiple interoperable implementations in multiple languages. JPEG XL doesn't have yet.
> Given the substantial complexity and scope of the JPEG XL format, I'd like to see a proof that a second implementation is possible, and that it's interoperable, so that the Web platform doesn't end needing bug-compatibility with a single C++ codebase.