39 ms·

JPEG XL support has officially been removed from Chromium

292 points by frankjr 4y ago

gjsman-1000 4y ago
I guess that’s that then. AVIF wins the format war for the next JPEG.
- LeoPanthera 4y ago
  AVIF? The war was lost when Apple set the default iPhone photo format to HEIF. You can't compete with that.
  - Ennea 4y ago
    AVIF lives inside an HEIF container, too.
    - CharlesW 4y ago
      To add a bit more detail, both AVIF and HEIF use the same file/container format: ISO Base Media File Format¹ — a.k.a. "ISOBMFF", ISO/IEC 14496-12. ISOBMFF is also used for MPEG-4, AV1, etc. If nothing else, the world appears to have settled on a flexible, extensible container format that can support any future media formats we can come up with. ¹ https://en.wikipedia.org/wiki/ISO_base_media_file_format https://en.wikipedia.org/wiki/ISO_base_media_file_format
  - theandrewbailey 4y ago
    HEIF can't compete while being bogged down by patent licensing costs.
  - masklinn 4y ago
    Apple is on the AOM board, and introduced HEIF before AVIF even existed (HEIF shipped in 2017 in iOS 11 and macOS 10.13, the first AVIF images were published late 2018, and the format was finalized early 2019). Apple has also shipped AVIF support in iOS 16 and Ventura, and AVIF-enabled Safari in the same. HEIF support was never enabled in Safari. Still isn't. There is no war. HEIF support was mostly a way to optimise storage on iPhones.
  - postalrat 4y ago
    Your HEIF are insignificant compared to JPEG.
  - mort96 4y ago
    Not even Safari on iPhone supports HEIF. Compare HEIF support with AVIF support: https://caniuse.com/?search=heif https://caniuse.com/?search=heif, https://caniuse.com/?search=avif https://caniuse.com/?search=avif. I don't see this changing either, most browser vendors are going to decide that AVIF is good enough and not pay to license the HEIF patents from the MPEG group.
- gsich 4y ago
  Only JPEG can surpass JPEG.
- ajross 4y ago
  Pretty sure that JPEG won the format war for the next JPEG, decades ago. No one wants this. The benefits just don't outweigh the headaches in compatibility and content duplication. JPEG is good enough, and always has been. We'll all be happier by celebrating such a impactful technology than grousing and constantly trying to fix what ain't broken.
  - simplotek 4y ago
    > Pretty sure that JPEG won the format war for the next JPEG, decades ago. JPEG for lossy image formats, PNG for lossless.
    - m-p-3 4y ago
      and SVG for vector-vased.
      - masklinn 4y ago
        Yeah nah. The scripting support (both direct and via styling) makes shipping SVG a complete hell. Aggressive (restrictive) CSP policies actually degrade and break SVG styling because of that. And it's absolutely necessary if you allow direct SVG linking / opening. If anything, SVG is the one image format most in need of replacement.
- JyrkiAlakuijala 4y ago
  No loss there, just slowdown and additional complexity for the web devs to deal with. Jpeg xl covers several important domains that are not served by AVIF. Jpeg xl will anchor in these domains and where AVIF cannot provide sufficient quality or speed. Eventually it cannot be ignored any more and will be made available in browsers, too. Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.
  - deleted 4y ago
    [deleted]
  - CharlesW 4y ago
    > Jpeg xl covers several important domains that are not served by AVIF. I'm not finding any. Mind listing them? > Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again. Unfortunately, JPEG XL wasn't "better enough" to have a unique selling proposition. And AVIF is the format that actually simplifies things, because it uses the same compressed media format (AV1) as the next-gen video distribution format.
    - mort96 4y ago
      >> Jpeg xl covers several important domains that are not served by AVIF. > I'm not finding any. Mind listing them? I don't know much about JXL vs AV1 from a technical perspective, both seem significantly better than JPEG. But JXL has the practical advantage that it can losslessly recompress JPEG images for a size improvement without an image quality improvement. When converting JPEG to AV1, you're stuck decompressing the JPEG into raw pixel data, with JPEG artefacts and all, and then compress that pixel data with AV1, so you get the artefacts from JPEG and the artefacts from AV1. Decompressing the resulting AV1 image will result in different and almost certainly worse quality pixel data. So the ability to do a risk-free lossless conversion from JPEG to a better format and get a size improvement is a pretty darn big domain that's not served by AV1.
      - CharlesW 4y ago
- PaulHoule 4y ago
  It’s a tough battle. For about 10 years I have been thinking about new file image file formats, it wasn’t until last year that I started really using them. For the web there is the cost of data transfer and the cost of data storage. You can save on data transfer by adding more files in more formats but you pay more in storage cost. To fully realize the economy of better file formats you need to retire JPEG and not add more files. I finally got convinced that WEBP was supported well enough that it was worth using 𝐚𝐧𝐝 that the image quality was really good with small files. I learned that the disadvantages of new file formats that claim to compress better are real but the better compression isn’t always real. I see people write a blog post where they compress three sample images but a real evaluation project is a lot more than that. So the world may well be better off with a second-best file format that people really use than being stuck with JPEG because people are struggling to make up their mind about what new format to use, support, etc.
- JyrkiAlakuijala 4y ago
  I believe current AVIF decoders and encoders are not competitive against JPEG1 codecs from the libjxl project. Check out the 'jpegli' effort. My guesswork is that jpegli is likely 5-10 % better for photography use case than AVIF. Jpegli also allows for similar HDR dynamics, 10-12 bits, like AVIF.
  - JyrkiAlakuijala 4y ago
    Jpegli can be further compressed by lossless jpeg1 support in jpeg xl, and some more by using full lossy jpeg xl.
- mort96 4y ago
  I don't see why you're getting downvoted. With Chrome removing JXL and all the browser vendors' expressed intentions to get behind AVIF, it certainly seems like AVIF is the clear winner in this round of the image format wars.
- sb057 4y ago
  An image file format with a maximum resolution of 8193x4320 (without hacking pieces together) can never win a format war, let alone one in 2022 for pete's sake.
vonbon 4y ago
Do we know why they chose to remove it? I can't see any rationale posted on the linked page, or the comment threads it links to. Maybe I missed it though.
- nikanj 4y ago
  It was no longer unstable beta
- shaicoleman 4y ago
  The reasons stated are: - Experimental flags and code should not remain indefinitely - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL - The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default - By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reason...
  - vonbon 4y ago
    Thanks, that all sounds fairly reasonable then.
    - gsich 4y ago
      Not really. It was hidden behind a flag, so where should the "entire ecosystem" (who?) show interest?
      - vonbon 4y ago
        Couldn't any interested parties just enable the flag for testing? That doesn't seem a insurmountable challenge, given that the code is, or was, already in there.
        hmry 4y ago
bricss 4y ago
FFS :/
deleted 4y ago
[deleted]
bricss 4y ago
De most advance image compression technology that humanity managed to master out, and yet they removing it entirely... What kinda conspiracy hafta be behind of all of that?
- xkapastel 4y ago
  did you tell chatgpt to act like jar jar binks or what?
hmry 4y ago
Sad day for image formats. JXL really looked like the future, it could have replaced all the image formats I use on my websites. Especially the lossless JPEG recompression mode, for which there is no existing option. I think I will continue using it with WASM polyfills, in hopes that Google will change their mind once the rest of the industry has switched to JXL.
- iLoveOncall 4y ago
  JPEG XL was not used anywhere which is why it got deprecated. It was never gonna be the future of anything.
  - ck45 4y ago
    I linked https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl in another comment which links to several big players requesting full JPEG XL support. It seems the reason why it wasn't adopted more broadly is that there was no full support for it in Chrome. I wouldn't even consider it a chicken and egg situation.
    - iLoveOncall 4y ago
      Your link doesn't mention anyone asking for it. Also AVIF is more performant for most cases. Lossless is not what matters on the web.
      - ksec 4y ago
        >Also AVIF is more performant for most cases. Source? JPEG XL has already shown, over 10,000 sample size and over a wide variety of BPP to be better than AVIF, on latest JPEG And AVIF versions. AVIF, on the other hand, has yet to shown anything similar.
      - ck45 4y ago
        It contains 8 links to the Chromium bugtracker in this paragraph: However, if the enthusiastic support in the Chromium bugtracker from Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, and Shopify is any indication, it seems baffling to conclude that there would be insufficient ecosystem interest. That's why I assumed there was demand for JPEG XL.
sebzim4500 4y ago
Does this mean that some Googler is going to get a promotion in six months by adding it back? It's my understanding that a lot of bizarre changes Google makes are best explained this way.
- youngtaff 4y ago
  There are people at Google still fighting for JXL
ck45 4y ago
I quite liked this article from about a month ago on "The Case for JPEG XL": https://news.ycombinator.com/item?id=33442281 https://news.ycombinator.com/item?id=33442281
- jmull 4y ago
  The case is not that compelling to me… > * Lossless JPEG recompression Obviously, jpeg has this. I know it is supposed to be a 20% reduction in size, but that is a relatively small incremental improvement. > * Progressive decoding jpeg also has this, and it’s a niche feature these days. > * Lossless compression performance png covers this > * Lossy compression performance Nice, but a relatively small incremental improvement in the general case. > * Deployable encoder This isn’t a case for jpeg xl, just table stakes for any format. > * Works across the workflow Not really a reason to include jpeg xl in the browser unless it actually is being widely used across workflows. Actually, this is something of a negative considering the resulting complexity of the codec and image format and that it muddles the distinction between the authoring and published form of an image. There are negatives too, so it’s not enough to be a little better for some cases..codecs are attack vectors. An all-new complex codec is an all-new broad attack surface. And, of course, it’s yet another feature to test and maintain, which costs time and necessarily pulls focus away from other things.
  - Avamander 4y ago
    > Obviously, jpeg has this. I know it is supposed to be a 20% reduction in size, but that is a relatively small incremental improvement. Let's not forget that a 20% reduction across the entire internet is very significant. > jpeg also has this, and it’s a niche feature these days. Because we can't rely on it, I'd suspect? > png covers this Without covering the rest. > Not really a reason to include jpeg xl in the browser unless it actually is being widely used across workflows. This line of thinking will inevitably lead to a chicken-and-egg problem. Just like with EdDSA certificates and for example H/2 PUSH (support of which got deprecated basically the same time some frameworks just added support). I think the web doesn't move as fast as Google thinks or hopes it does, and it has and will make people reluctant on adopting next new features.
yakubin 4y ago
Chromium is in the business of adding things websites should have no business concerning themselves with, like Bluetooth support, while removing support for useful things: now JPEG XL, previously RSS, MathML.
- dieulot 4y ago
  MathML is making a return next month. https://chromestatus.com/roadmap https://chromestatus.com/roadmap
  - lol768 4y ago
    > MathML is making a return next month Yeah, and that's arguably thanks to Igalia and all of their sponsors. They've put a colossal amount of work into this project. If you have the means, it's worth donating for ongoing support, too: https://opencollective.com/mathml-core-support https://opencollective.com/mathml-core-support Google just removed it and would've been content with it staying gone. They said "it wouldn’t have been a good return on investment for us to do it".
- thehappypm 4y ago
  If JPEG XL was actually utilised they would not be deprecating it
  - yakubin 4y ago
    How would a web developer use a feature, which is disabled by default? Should they put up a banner saying "in order to view this page, restart your browser with this command line parameter"?
    - lopkeny12ko 4y ago
      You'd use it the same way any other web feature without widespread browser support is rolled out--progressive enhancement, i.e. load it at runtime if heuristics indicate the necessary browser APIs are available, otherwise fall back to a "degraded" version.
JyrkiAlakuijala 4y ago
https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... Star this bug to express support for JPEG XL.
- youngtaff 4y ago
  So obviously not all of Google agrees with the decision to remove support then!
  - masklinn 4y ago
    This is the original issue which led to the feature being added behind a flag. Then it was removed.
Gordonjcp 4y ago
I wanted to post a JPEG XL pic of some Sony Betamax tapes, but I couldn't find anything to support encoding it.
- hmry 4y ago
  Some options: ffmpeg, GIMP, Krita, Photoshop (if you enable it in the settings), and the reference implementation cjxl which you probably already have installed if you use Linux (because QT and GTK depend on it).
  - johnny22 4y ago
    the mention of betamax probably meant that you replied to a joke. either the fact that betamax was just dead, or that technically superior options don't always win the market
    - Gordonjcp 4y ago
      You'd think more people would have got that, wouldn't you?
    - Dylan16807 4y ago
      Being a joke doesn't make a comment immune to having wrong parts. Those obvious jokes are not improved by saying you can't find an encoder unless it's actually true. Can you explain how that is clearly part of the joke? Otherwise the correction makes plenty of sense. Despite the comment being a joke.
      - Gordonjcp 4y ago
        If you don't understand it, you could always try just being quiet until you figure it out.
        Dylan16807 4y ago
        Yeah that's how conversations work. Good second joke.
js4ever 4y ago
A very good format killed by it's license
- croes 4y ago
  JPEG XL is royalty-free
- jrochkind1 4y ago
  Are you thinking of JPEG 2000? Different thing.
nimish 4y ago
Sad. Being able to immediately upgrade all JPEGS to jxl without any reencode loss is huge. And no royalty issues either, plus no need for a much more complex decoder.
- arglebargle123 4y ago
  Yeah, jxl support is a huge win for anyone working with large quantities of jpeg files; aka basically everyone now that we all have smartphones with cameras and jpeg is the default format. Jxl is a huge upgrade for simpler images as well, I think I save something like ~60% of the space used by my comics collection with no visual detail loss by converting to jxl.
  - yardstick 4y ago
    Minor point: JPEG is not the default format for Apple iPhone cameras, they’ve used HEIC by default for quite a while now.
bvhvhfcgxfdf 4y ago
PaulHoule 4y ago
My main boggle with images today is that I am making red/cyan anaglyphs that perform well on older displays but have crosstalk on ‘wide gamut’ displays because wide gamut displays turn a (0,180,0) green in sRGB into (16,176,16) on the display in an effort to make the saturation closer to the sRGB green and less like the color you see when you get hit with a green laser pointer. The extra red shines through the right filter though and makes a ghost image. I am thinking it ought to be possible to have a sRGB and a wide gamut image and have the front end pick the right image. What I really want to do do the anaglyph processing with WebGL but that involves telling the web browser to render a wide gamut color space directly.
- zamadatix 4y ago
  You're correct it's possible to have the front end select the right image. That can be done in CSS via "@media(color-gamut: srgb) {}" (p3 and rec2020 are the other supported options) for the different pre-rendered images. In this way you don't need to script anything and the client still only loads the required image. WebGL/Canvas methods will be possible one day but right now how that will all get implemented is still being worked on. https://github.com/WICG/canvas-color-space/blob/main/CanvasColorSpaceProposal.md https://github.com/WICG/canvas-color-space/blob/main/CanvasC... the same can be said for general CSS support or any other interface in the browser beyond images and video at the moment https://w3c.github.io/ColorWeb-CG/ https://w3c.github.io/ColorWeb-CG/.
- jiggawatts 4y ago
  You are trying to do colour management on the web, and also likely in the general consumer PC space. This is impossible, and will remain so for at least a decade. No vendor other than Apple has the slightest interest in getting colour even vaguely right, because they're all run either by colorblind lizards, or have corporate drones that are given identical monitors. The cheapest monitors possible that are basically greyscale. Recently, Windows has taken several steps back from Vista's fairly good colour management. For example, the newer Win UI 3 SDK is 8-bit sRGB SDR only. Similarly, HDR support on Windows 11 is totally broken, and every semi-annual release does random things to it. When bugs are identified by consumers (not Microsoft!), they delay the fixes to the next semiannual release... at which they break other things. There hasn't been a release of Windows ever that can correctly drive a directly attached HDR display, such as the type used in a laptop. None of these corporate drones understand the problem because they literally cannot see it.
gpvos 4y ago
Reading the comments on the bug, supporting comments for JPEG XL started flowing in there around 24 August 2022 (with a couple early ones on Aug 16 and 17). Was there some publicity about JPEG XL around that time, and did someone urge others to request Google to enable it by default? I can imagine that that was when the decision process at Google started whether to keep or remove it. The reasons for removal given on October 31 are rather vague and seem to underestimate the interest in the format.
- erk__ 4y ago
  That was around the time the the final parts of the standardization procedure was getting finished: https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status
- lifthrasiir 4y ago
  That's when Adobe formally expressed a support for JPEG XL (comment 61), which is a big milestone by its own and people started to push Google to finish the experiment in lieu of that event, as everyone expected that it will land at some point, most likely shortly after libjxl reaches 1.0.
pornel 4y ago
Browser vendors have other priorities besides having the latest-greatest compressor: code size, attack surface, long-term maintenance and compatibility risks, and interoperability. Having a format that is a few percent smaller than the formats they already have is just not a high priority. This isn't a conspiracy against JPEG XL. Browser vendors (other than Google) have been resisting shipping WebP for 10 years, until Chrome-only websites forced them to. GIF still is a thing despite being by far the worst in every image benchmark. Every few years browser vendors are asked to adopt a new format, which is then beaten by an even newer format, but the vendors are stuck supporting the old one forever. They've dodged the bullet on JPEG 2000 and JPEG XR, but are now stuck with WebP (and AVIF, if they were to replace it). If in a few years it turns out everyone uses JXL and other vendors have it, Chrome can re-add it.
- trasz2 4y ago
  >Browser vendors have other priorities besides having the latest-greatest compressor: code size, attack surface, long-term maintenance and compatibility risks, and interoperability. You’ve missed two most important ones: “business reasons”, eg trying to harm some (potential) competitor, and someone trying to get promoted. Don’t assume there are valid technical reasons behind every corporate decision like those; usually there aren’t.
  - pornel 4y ago
    Maybe if JPEG XL had a chat functionality, Google would have a motivation to include it… But seriously, it's an ISO standard with a free implementation. There's no Google competitor attached to it. Nobody gets prompted for failing to add features. Google is even missing out on a chance to make Safari look outdated again. There's no reason to interpret indifference as a conspiracy. BTW: I've worked on the HTML5 spec and codecs for many years, so I've seen how the sausage is made on both sides.
    - nirvanaman2k13 4y ago
      Incorrect. Facebook have said they want to use JPEG-XL. Facebook/instagram is definitely a big tech competitor to google, especially in regards to ads.
trasz2 4y ago
Daily reminder that Chrome (and Chromium) is not unlike other Google projects: users are its cattle, not its clients. It’s naive to assume good intentions here.
coding123 4y ago
Competition with webp. Elephant. Room.
croes 4y ago
Google's justification for removing this feature sounds like Tesla's for removing Radar.
jl6 4y ago
JPEG XL needs some support from the camera manufacturers. They’ve mostly gone with HEIF so far and seem unmotivated to do anything different.
- quikee 4y ago
  Camera manufacturers are old spineless companies. In all those years they have done nothing for digital image formats and it is the most important thing in a camera. They weren't even able to come up or attempt to make a standard RAW format. All that came from Adobe (DNG), which the camera manufacturers happily ignored for their own proprietary solution until this day.
  - kasabali 4y ago
    Can't really blame camera manufacturers when RED is suing everyone who's shipped a feature even remotely resembling their patent portfolio.
    - quikee 4y ago
      Well RED is mostly suing for their RAW video compression patents, which are just dumb an should never be allowed to be passed in the first place (and AFAIK Nikon is currently battling to invalidate that). But this is also their own problem - they haven't put almost no R&D into the software side of digital photography and videography like formats, processing. They have a nice camera which outputs 12-bit and higher images - they should be the first ones requesting and defining a new image format for consumption, which can handle that.
- erk__ 4y ago
  JPEG XL was finalized 6-7 years after HEIF so I am not sure it is a good comparison. Especially seeing that JPEG XL was first finalized this and last year.
  - jl6 4y ago
    I know, I’m just saying that HEIF is the next-gen incumbent to beat. A lot of comparisons are being done with WebP and AVIF and legacy JPEG, which aren’t the real competition.
ur-whale 4y ago
Pure politics is clearly and officially the only reason why Google does things these days. Best image codec on the planet has "not enough interest from ecosystem". Being able to say this on a public mailing list with a straight face goes a very long way in showing how disconnected from reality folks at Google now are. And it seems that comment comes from someone who claims to be an engineer ... that also goes to show the quality of engineers who still work there, where reality doesn't seem to factor in decision making anymore. There was a time where one of Google's motto was "put the user first and everything else will follow". LOL, how things have changed.
- bioemerl 4y ago
  You should see what they said about supporting DCHP on Android for ipv6. They have simply opted not to support it because you "should be using something else"
  - vetinari 4y ago
    And they were right; nobody should use DHCP with IPv6. It is like bringing horse carts into space age.
- deleted 4y ago
  [deleted]
- youngtaff 4y ago
  There’s also the politics of them not supporting img=*.mp4 too https://bugs.chromium.org/p/chromium/issues/detail?id=791658 https://bugs.chromium.org/p/chromium/issues/detail?id=791658
josephscott 4y ago
This is disappointing to see, I had high hopes for JXL.
YetAnotherNick 4y ago
What's up with this JPEG XL cult in hacker news? I think the Chrome team pretty much handled this in the best way possible. They put everything in public and allowed anyone to comment on their main thread. They responded to lot of the comments. They seems to have their best intention in having JPEG XL implementation in chrome but the team decided it's not worth it, which is a valid decision for someone doing ROI analysis, after all engineers specialising in this are not cheap. It's like everyone is hinting at some conspiracy by Google here that is not there as they spent time in the spec and wanted to promote this. Even I think the incremental 20% gain of JPEG XL is probably not worth the security risk and increased maintenance. JPEG decoders had been targeted so many times in the past even though it had been audited by best security folks.
- ksec 4y ago
  I am probably the first few if not the first to put JPEG XL on HN's radar. I am definitely not in an JPEG XL Cult. Although I do dislike Google. I am simply a supporter of Better Tech. (And I am already omitting WebP hate here. ) And I suspect a lot of us are. And IMO neither WebP nor AVIF are better than JPEG XL. Had Google actually posted a thorough analysis, as they stated that JPEG XL is not better or even inferior to AVIF, and suggest they decide not to go with it. It would have been fine. ( I may disagree with their take, but at least you can see it from their POV ). Not only did they not do that, they provided the Data with out of date version of JPEG XL [1] and a set of test that does not represent the actual internet usage. Compared to [2], where JPEG XL is surprisingly better when they wont expected. So if, a) everything JPEG XL released and tested were true, and truly better than AVIF, then b) Why isn't Google supporting the better Image codec? I am also perfectly fine with Google saying, I dont like it. I hate it because It is not AOM even if JPEG XL is better. Fine. Chrome is Google's browser. Do what ever you want with it. Just dont ever come out again and say everything you do is better for the Web. [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html [2] https://twitter.com/jonsneyers/status/1563442356493230080 https://twitter.com/jonsneyers/status/1563442356493230080
  - deleted 4y ago
    [deleted]
dang 4y ago
Related: Chrome team released the data for the decision to remove JPEG XL support - https://news.ycombinator.com/item?id=33866388 https://news.ycombinator.com/item?id=33866388 - Dec 2022 (1 comment) Revert “flag_descriptions: Add note about JPEG XL removal” - https://news.ycombinator.com/item?id=33803941 https://news.ycombinator.com/item?id=33803941 - Nov 2022 (17 comments) What Is JPEG XL? - https://news.ycombinator.com/item?id=33646153 https://news.ycombinator.com/item?id=33646153 - Nov 2022 (7 comments) Chrome Responds "No" to JPEG XL - https://news.ycombinator.com/item?id=33563378 https://news.ycombinator.com/item?id=33563378 - Nov 2022 (55 comments) The case for JPEG XL - https://news.ycombinator.com/item?id=33442281 https://news.ycombinator.com/item?id=33442281 - Nov 2022 (209 comments) Removing the JPEG XL code and flag from Chromium - https://news.ycombinator.com/item?id=33412340 https://news.ycombinator.com/item?id=33412340 - Oct 2022 (42 comments) Chrome drops JPEG XL, “not enough interest” - https://news.ycombinator.com/item?id=33404840 https://news.ycombinator.com/item?id=33404840 - Oct 2022 (4 comments) Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 - Oct 2022 (93 comments) Google Chrome Is Already Preparing to Deprecate JPEG-XL - https://news.ycombinator.com/item?id=33383880 https://news.ycombinator.com/item?id=33383880 - Oct 2022 (20 comments) What’s the best lossless image format? - https://news.ycombinator.com/item?id=31657006 https://news.ycombinator.com/item?id=31657006 - June 2022 (164 comments) FFmpeg now supports JPEG XL - https://news.ycombinator.com/item?id=31177098 https://news.ycombinator.com/item?id=31177098 - April 2022 (91 comments) The JPEG XL standard has now been formally approved - https://news.ycombinator.com/item?id=29598090 https://news.ycombinator.com/item?id=29598090 - Dec 2021 (17 comments) Using Saliency in progressive JPEG XL images - https://news.ycombinator.com/item?id=28468284 https://news.ycombinator.com/item?id=28468284 - Sept 2021 (44 comments) JPEG XL - https://news.ycombinator.com/item?id=27577328 https://news.ycombinator.com/item?id=27577328 - June 2021 (234 comments) JPEG XL would be Turing-complete without the 1024×1024 pixel limitation - https://news.ycombinator.com/item?id=27559748 https://news.ycombinator.com/item?id=27559748 - June 2021 (36 comments) JPEG XL - https://news.ycombinator.com/item?id=26186707 https://news.ycombinator.com/item?id=26186707 - Feb 2021 (1 comment) Overview of JPEG XL - https://news.ycombinator.com/item?id=25560683 https://news.ycombinator.com/item?id=25560683 - Dec 2020 (1 comment) Brunsli: Practical JPEG repacker (now part of JPEG XL) - https://news.ycombinator.com/item?id=22456764 https://news.ycombinator.com/item?id=22456764 - March 2020 (72 comments) JPEG XL: Next-Generation of Image Format for the Internet [video] - https://news.ycombinator.com/item?id=21612708 https://news.ycombinator.com/item?id=21612708 - Nov 2019 (3 comments) JPEG XL Reaches Committee Draft - https://news.ycombinator.com/item?id=20603501 https://news.ycombinator.com/item?id=20603501 - Aug 2019 (2 comments) JPEG XL is coming to store our photos at 1/3 size - https://news.ycombinator.com/item?id=19816485 https://news.ycombinator.com/item?id=19816485 - May 2019 (2 comments) JPEG XL could let you pack twice as many photos into your phone - https://news.ycombinator.com/item?id=17356913 https://news.ycombinator.com/item?id=17356913 - June 2018 (57 comments) JPEG XL could let you pack twice as many photos into your phone - https://news.ycombinator.com/item?id=17345470 https://news.ycombinator.com/item?id=17345470 - June 2018 (6 comments)
ProgramMax 4y ago
I don't speak for Google/Chrome but I really need to clarify something that keeps being misstated: The test of JPEG XL support has been removed. It was always behind a flag and never actually supported. That is not to say that Chrome will not ever support JPEG XL. The two concepts are fundamentally unrelated. So we should stop conflating them. In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case. And the thing they should be waiting on IMHO is wide spread support. Adding image formats to the web should be the last step because it is so difficult to remove them. I bet other browser devs in the image space wish they could remove ico support. Oh well. "So why add it in a test just to later remove it?" I hear someone ask. Because you want to make sure that path is clear and you're in position long before it is needed. Once you know the path is clear, you don't want to keep dead code around. It is easy enough to dig it out of old commits when the time comes. Heck, it could even be as simple as someone wanted to add a big item to their promo packet. Who knows. But at the end of the day, Chrome did not remove JPEG XL support. And I haven't seen anything saying Chrome wouldn't later add it. If we all want JPEG XL (I do), we should continue to help its adoption grow. Using it via WASM is a strong indicator. Get it to the point where "of course Chrome will add support -- it is everywhere".
- ksec 4y ago
  >Adding image formats to the web should be the last step because it is so difficult to remove them. Not from a company that added WebP to its browser and wanted a new video codec every 2 years.
- dmitriid 4y ago
  > In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case. If Chrome deems that something is useful (to them, for some definition of useful), they just release it (and if this something was on a standards track, too bad, it's out now).
- chungy 4y ago
  > In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. Waiting for libjxl 1.0 is reasonable. Though I can't help but to think it would be less work to just keep the experimental feature in there until it is stable.
cesarb 4y ago
Back in the good old days, things like these could be added through plugins, instead of requiring everything to go through the browser manufacturer. Plugins were removed mostly due to security issues (and also maintainability and portability worries), but nowadays that could be avoided by using WASM (see also https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...).
- niutech 4y ago
  Have a look at WASM decoder JXL.js: https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js
supermatt 4y ago
Please feel free to "star" the issue for jpegXL support. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... From reading through the justification for the removal it seems this decision was (in part) due due to some erroneously compiled benchmarks: > http://storage.googleapis.com/avif-comparison/index.html http://storage.googleapis.com/avif-comparison/index.html "That test was done in Chrome without even using the latest version of chrome! There were many performance improvements since. Additionally, the color format (yuvj444p) used is a color format no sane person would use for JpegXL. If they were to test different color formats, they would see JpegXL wins in all of them, except the exact one they used!" (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c288 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...)
return_to_monke 4y ago
seems like they backtracked on the issue just a hour ago; https://chromium-review.googlesource.com/c/chromium/src/+/4095497 https://chromium-review.googlesource.com/c/chromium/src/+/40...
- jsnell 4y ago
  No. It's some random person sending a pull request, which has not been accepted. Looking at their history [0], the account was created two weeks ago and the only contributions were attempts to revert earlier JPEG XL removal commits. Those requests were not accepted. [0] https://chromium-review.googlesource.com/q/owner:ayz.out%2540gmail.com https://chromium-review.googlesource.com/q/owner:ayz.out%254...
  - return_to_monke 4y ago
    oh, okay. thanks for clarifying!
a1369209993 4y ago
Good riddance to bad rubbish. PNG 'optimizers' that change the image data rather than the compression and framing settings were bad enough; the last thing we need is to displace JPG/PNG entirely with a format that doesn't distinguish[0] between lossy and lossless compression in the first place. 0: No, embedded metadata doesn't count; the same format is being used for two incompatible kinds of compression.
- lifthrasiir 4y ago
  Unfortunately, if the format supports at least lossless compression (i.e. able to represent all uniform range in the pixel domain with a reasonable compression rate, amortized) then there is no practical way to distinguish lossy compression from lossless compression. PNG -> JPEG -> PNG is a lossy compression but the resulting output is seemingly lossless while it isn't.
  - a1369209993 4y ago
    Sufficiently badly behaved software can definitely still screw you over, but with separate formats you at least have a chance to notice that there's a problem during the PNG -> JPEG part of the process. Decoders like libpng will outright refuse to handle JPGs, image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". With JPEG XL, images can get switched to lossy mode silently, without breaking anything, and then back, also silently, also without breaking anything. JPEGXL -> JPEGXL -> JPEGXL is a lossy compression that doesn't give you any intermediate state where touching the images will loudly scream "something is wrong here"; you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image.
    - lifthrasiir 4y ago
      > image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". As you have noticed, the latter behavior is slowly becoming a norm even for user-facing applications (paint.net for example can handle them) because users have no idea how .png and .jpg can differ. And good JPEG encoders have made a visual inspection a lot harder. It's kinda futile. > you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image. I should note that, while this is hardly an ideal situation, generation loss in modern image formats is much harder to spot in the intended bits-per-pixel range. And JPEG XL is one of the best performing image formats in terms of generation loss, so repeated lossy compression is not a big issue for it.

292 points by frankjr 4y ago

gjsman-1000 4y ago

I guess that’s that then. AVIF wins the format war for the next JPEG.

LeoPanthera 4y ago
AVIF? The war was lost when Apple set the default iPhone photo format to HEIF. You can't compete with that.
- Ennea 4y ago
  AVIF lives inside an HEIF container, too.
  - CharlesW 4y ago
    To add a bit more detail, both AVIF and HEIF use the same file/container format: ISO Base Media File Format¹ — a.k.a. "ISOBMFF", ISO/IEC 14496-12. ISOBMFF is also used for MPEG-4, AV1, etc. If nothing else, the world appears to have settled on a flexible, extensible container format that can support any future media formats we can come up with. ¹ https://en.wikipedia.org/wiki/ISO_base_media_file_format https://en.wikipedia.org/wiki/ISO_base_media_file_format
- theandrewbailey 4y ago
  HEIF can't compete while being bogged down by patent licensing costs.
- masklinn 4y ago
  Apple is on the AOM board, and introduced HEIF before AVIF even existed (HEIF shipped in 2017 in iOS 11 and macOS 10.13, the first AVIF images were published late 2018, and the format was finalized early 2019). Apple has also shipped AVIF support in iOS 16 and Ventura, and AVIF-enabled Safari in the same. HEIF support was never enabled in Safari. Still isn't. There is no war. HEIF support was mostly a way to optimise storage on iPhones.
- postalrat 4y ago
  Your HEIF are insignificant compared to JPEG.
- mort96 4y ago
  Not even Safari on iPhone supports HEIF. Compare HEIF support with AVIF support: https://caniuse.com/?search=heif https://caniuse.com/?search=heif, https://caniuse.com/?search=avif https://caniuse.com/?search=avif. I don't see this changing either, most browser vendors are going to decide that AVIF is good enough and not pay to license the HEIF patents from the MPEG group.
gsich 4y ago
Only JPEG can surpass JPEG.
ajross 4y ago
Pretty sure that JPEG won the format war for the next JPEG, decades ago. No one wants this. The benefits just don't outweigh the headaches in compatibility and content duplication. JPEG is good enough, and always has been. We'll all be happier by celebrating such a impactful technology than grousing and constantly trying to fix what ain't broken.
- simplotek 4y ago
  > Pretty sure that JPEG won the format war for the next JPEG, decades ago. JPEG for lossy image formats, PNG for lossless.
  - m-p-3 4y ago
    and SVG for vector-vased.
    - masklinn 4y ago
      Yeah nah. The scripting support (both direct and via styling) makes shipping SVG a complete hell. Aggressive (restrictive) CSP policies actually degrade and break SVG styling because of that. And it's absolutely necessary if you allow direct SVG linking / opening. If anything, SVG is the one image format most in need of replacement.
JyrkiAlakuijala 4y ago
No loss there, just slowdown and additional complexity for the web devs to deal with. Jpeg xl covers several important domains that are not served by AVIF. Jpeg xl will anchor in these domains and where AVIF cannot provide sufficient quality or speed. Eventually it cannot be ignored any more and will be made available in browsers, too. Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again.
- deleted 4y ago
  [deleted]
- CharlesW 4y ago
  > Jpeg xl covers several important domains that are not served by AVIF. I'm not finding any. Mind listing them? > Once jpeg xl is made available there is no reason to use jpeg1, WebP or AVIF anymore. Then we can simplify again. Unfortunately, JPEG XL wasn't "better enough" to have a unique selling proposition. And AVIF is the format that actually simplifies things, because it uses the same compressed media format (AV1) as the next-gen video distribution format.
  - mort96 4y ago
    >> Jpeg xl covers several important domains that are not served by AVIF. > I'm not finding any. Mind listing them? I don't know much about JXL vs AV1 from a technical perspective, both seem significantly better than JPEG. But JXL has the practical advantage that it can losslessly recompress JPEG images for a size improvement without an image quality improvement. When converting JPEG to AV1, you're stuck decompressing the JPEG into raw pixel data, with JPEG artefacts and all, and then compress that pixel data with AV1, so you get the artefacts from JPEG and the artefacts from AV1. Decompressing the resulting AV1 image will result in different and almost certainly worse quality pixel data. So the ability to do a risk-free lossless conversion from JPEG to a better format and get a size improvement is a pretty darn big domain that's not served by AV1.
    - CharlesW 4y ago
PaulHoule 4y ago
It’s a tough battle. For about 10 years I have been thinking about new file image file formats, it wasn’t until last year that I started really using them. For the web there is the cost of data transfer and the cost of data storage. You can save on data transfer by adding more files in more formats but you pay more in storage cost. To fully realize the economy of better file formats you need to retire JPEG and not add more files. I finally got convinced that WEBP was supported well enough that it was worth using 𝐚𝐧𝐝 that the image quality was really good with small files. I learned that the disadvantages of new file formats that claim to compress better are real but the better compression isn’t always real. I see people write a blog post where they compress three sample images but a real evaluation project is a lot more than that. So the world may well be better off with a second-best file format that people really use than being stuck with JPEG because people are struggling to make up their mind about what new format to use, support, etc.
JyrkiAlakuijala 4y ago
I believe current AVIF decoders and encoders are not competitive against JPEG1 codecs from the libjxl project. Check out the 'jpegli' effort. My guesswork is that jpegli is likely 5-10 % better for photography use case than AVIF. Jpegli also allows for similar HDR dynamics, 10-12 bits, like AVIF.
- JyrkiAlakuijala 4y ago
  Jpegli can be further compressed by lossless jpeg1 support in jpeg xl, and some more by using full lossy jpeg xl.
mort96 4y ago
I don't see why you're getting downvoted. With Chrome removing JXL and all the browser vendors' expressed intentions to get behind AVIF, it certainly seems like AVIF is the clear winner in this round of the image format wars.
sb057 4y ago
An image file format with a maximum resolution of 8193x4320 (without hacking pieces together) can never win a format war, let alone one in 2022 for pete's sake.

vonbon 4y ago

Do we know why they chose to remove it? I can't see any rationale posted on the linked page, or the comment threads it links to. Maybe I missed it though.

nikanj 4y ago
It was no longer unstable beta
shaicoleman 4y ago
The reasons stated are: - Experimental flags and code should not remain indefinitely - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL - The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default - By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reasons https://www.phoronix.com/news/Chrome-Dropping-JPEG-XL-Reason...
- vonbon 4y ago
  Thanks, that all sounds fairly reasonable then.
  - gsich 4y ago
    Not really. It was hidden behind a flag, so where should the "entire ecosystem" (who?) show interest?
    - vonbon 4y ago
      Couldn't any interested parties just enable the flag for testing? That doesn't seem a insurmountable challenge, given that the code is, or was, already in there.
      - hmry 4y ago

bricss 4y ago

FFS :/

deleted 4y ago

[deleted]

bricss 4y ago

De most advance image compression technology that humanity managed to master out, and yet they removing it entirely... What kinda conspiracy hafta be behind of all of that?

xkapastel 4y ago
did you tell chatgpt to act like jar jar binks or what?

hmry 4y ago

Sad day for image formats. JXL really looked like the future, it could have replaced all the image formats I use on my websites. Especially the lossless JPEG recompression mode, for which there is no existing option. I think I will continue using it with WASM polyfills, in hopes that Google will change their mind once the rest of the industry has switched to JXL.

iLoveOncall 4y ago
JPEG XL was not used anywhere which is why it got deprecated. It was never gonna be the future of anything.
- ck45 4y ago
  I linked https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl in another comment which links to several big players requesting full JPEG XL support. It seems the reason why it wasn't adopted more broadly is that there was no full support for it in Chrome. I wouldn't even consider it a chicken and egg situation.
  - iLoveOncall 4y ago
    Your link doesn't mention anyone asking for it. Also AVIF is more performant for most cases. Lossless is not what matters on the web.
    - ksec 4y ago
      >Also AVIF is more performant for most cases. Source? JPEG XL has already shown, over 10,000 sample size and over a wide variety of BPP to be better than AVIF, on latest JPEG And AVIF versions. AVIF, on the other hand, has yet to shown anything similar.
    - ck45 4y ago
      It contains 8 links to the Chromium bugtracker in this paragraph: However, if the enthusiastic support in the Chromium bugtracker from Facebook, Adobe, Intel and VESA, Krita, The Guardian, libvips, Cloudinary, and Shopify is any indication, it seems baffling to conclude that there would be insufficient ecosystem interest. That's why I assumed there was demand for JPEG XL.

sebzim4500 4y ago

Does this mean that some Googler is going to get a promotion in six months by adding it back? It's my understanding that a lot of bizarre changes Google makes are best explained this way.

youngtaff 4y ago
There are people at Google still fighting for JXL

ck45 4y ago

I quite liked this article from about a month ago on "The Case for JPEG XL": https://news.ycombinator.com/item?id=33442281 https://news.ycombinator.com/item?id=33442281

jmull 4y ago
The case is not that compelling to me… > * Lossless JPEG recompression Obviously, jpeg has this. I know it is supposed to be a 20% reduction in size, but that is a relatively small incremental improvement. > * Progressive decoding jpeg also has this, and it’s a niche feature these days. > * Lossless compression performance png covers this > * Lossy compression performance Nice, but a relatively small incremental improvement in the general case. > * Deployable encoder This isn’t a case for jpeg xl, just table stakes for any format. > * Works across the workflow Not really a reason to include jpeg xl in the browser unless it actually is being widely used across workflows. Actually, this is something of a negative considering the resulting complexity of the codec and image format and that it muddles the distinction between the authoring and published form of an image. There are negatives too, so it’s not enough to be a little better for some cases..codecs are attack vectors. An all-new complex codec is an all-new broad attack surface. And, of course, it’s yet another feature to test and maintain, which costs time and necessarily pulls focus away from other things.
- Avamander 4y ago
  > Obviously, jpeg has this. I know it is supposed to be a 20% reduction in size, but that is a relatively small incremental improvement. Let's not forget that a 20% reduction across the entire internet is very significant. > jpeg also has this, and it’s a niche feature these days. Because we can't rely on it, I'd suspect? > png covers this Without covering the rest. > Not really a reason to include jpeg xl in the browser unless it actually is being widely used across workflows. This line of thinking will inevitably lead to a chicken-and-egg problem. Just like with EdDSA certificates and for example H/2 PUSH (support of which got deprecated basically the same time some frameworks just added support). I think the web doesn't move as fast as Google thinks or hopes it does, and it has and will make people reluctant on adopting next new features.

yakubin 4y ago

Chromium is in the business of adding things websites should have no business concerning themselves with, like Bluetooth support, while removing support for useful things: now JPEG XL, previously RSS, MathML.

dieulot 4y ago
MathML is making a return next month. https://chromestatus.com/roadmap https://chromestatus.com/roadmap
- lol768 4y ago
  > MathML is making a return next month Yeah, and that's arguably thanks to Igalia and all of their sponsors. They've put a colossal amount of work into this project. If you have the means, it's worth donating for ongoing support, too: https://opencollective.com/mathml-core-support https://opencollective.com/mathml-core-support Google just removed it and would've been content with it staying gone. They said "it wouldn’t have been a good return on investment for us to do it".
thehappypm 4y ago
If JPEG XL was actually utilised they would not be deprecating it
- yakubin 4y ago
  How would a web developer use a feature, which is disabled by default? Should they put up a banner saying "in order to view this page, restart your browser with this command line parameter"?
  - lopkeny12ko 4y ago
    You'd use it the same way any other web feature without widespread browser support is rolled out--progressive enhancement, i.e. load it at runtime if heuristics indicate the necessary browser APIs are available, otherwise fall back to a "degraded" version.

JyrkiAlakuijala 4y ago

https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... Star this bug to express support for JPEG XL.

youngtaff 4y ago
So obviously not all of Google agrees with the decision to remove support then!
- masklinn 4y ago
  This is the original issue which led to the feature being added behind a flag. Then it was removed.

Gordonjcp 4y ago

I wanted to post a JPEG XL pic of some Sony Betamax tapes, but I couldn't find anything to support encoding it.

hmry 4y ago
Some options: ffmpeg, GIMP, Krita, Photoshop (if you enable it in the settings), and the reference implementation cjxl which you probably already have installed if you use Linux (because QT and GTK depend on it).
- johnny22 4y ago
  the mention of betamax probably meant that you replied to a joke. either the fact that betamax was just dead, or that technically superior options don't always win the market
  - Gordonjcp 4y ago
    You'd think more people would have got that, wouldn't you?
  - Dylan16807 4y ago
    Being a joke doesn't make a comment immune to having wrong parts. Those obvious jokes are not improved by saying you can't find an encoder unless it's actually true. Can you explain how that is clearly part of the joke? Otherwise the correction makes plenty of sense. Despite the comment being a joke.
    - Gordonjcp 4y ago
      If you don't understand it, you could always try just being quiet until you figure it out.
      - Dylan16807 4y ago
        Yeah that's how conversations work. Good second joke.

js4ever 4y ago

A very good format killed by it's license

croes 4y ago
JPEG XL is royalty-free
jrochkind1 4y ago
Are you thinking of JPEG 2000? Different thing.

nimish 4y ago

Sad. Being able to immediately upgrade all JPEGS to jxl without any reencode loss is huge. And no royalty issues either, plus no need for a much more complex decoder.

arglebargle123 4y ago
Yeah, jxl support is a huge win for anyone working with large quantities of jpeg files; aka basically everyone now that we all have smartphones with cameras and jpeg is the default format. Jxl is a huge upgrade for simpler images as well, I think I save something like ~60% of the space used by my comics collection with no visual detail loss by converting to jxl.
- yardstick 4y ago
  Minor point: JPEG is not the default format for Apple iPhone cameras, they’ve used HEIC by default for quite a while now.

bvhvhfcgxfdf 4y ago

PaulHoule 4y ago

My main boggle with images today is that I am making red/cyan anaglyphs that perform well on older displays but have crosstalk on ‘wide gamut’ displays because wide gamut displays turn a (0,180,0) green in sRGB into (16,176,16) on the display in an effort to make the saturation closer to the sRGB green and less like the color you see when you get hit with a green laser pointer. The extra red shines through the right filter though and makes a ghost image. I am thinking it ought to be possible to have a sRGB and a wide gamut image and have the front end pick the right image. What I really want to do do the anaglyph processing with WebGL but that involves telling the web browser to render a wide gamut color space directly.

zamadatix 4y ago
You're correct it's possible to have the front end select the right image. That can be done in CSS via "@media(color-gamut: srgb) {}" (p3 and rec2020 are the other supported options) for the different pre-rendered images. In this way you don't need to script anything and the client still only loads the required image. WebGL/Canvas methods will be possible one day but right now how that will all get implemented is still being worked on. https://github.com/WICG/canvas-color-space/blob/main/CanvasColorSpaceProposal.md https://github.com/WICG/canvas-color-space/blob/main/CanvasC... the same can be said for general CSS support or any other interface in the browser beyond images and video at the moment https://w3c.github.io/ColorWeb-CG/ https://w3c.github.io/ColorWeb-CG/.
jiggawatts 4y ago
You are trying to do colour management on the web, and also likely in the general consumer PC space. This is impossible, and will remain so for at least a decade. No vendor other than Apple has the slightest interest in getting colour even vaguely right, because they're all run either by colorblind lizards, or have corporate drones that are given identical monitors. The cheapest monitors possible that are basically greyscale. Recently, Windows has taken several steps back from Vista's fairly good colour management. For example, the newer Win UI 3 SDK is 8-bit sRGB SDR only. Similarly, HDR support on Windows 11 is totally broken, and every semi-annual release does random things to it. When bugs are identified by consumers (not Microsoft!), they delay the fixes to the next semiannual release... at which they break other things. There hasn't been a release of Windows ever that can correctly drive a directly attached HDR display, such as the type used in a laptop. None of these corporate drones understand the problem because they literally cannot see it.

gpvos 4y ago

Reading the comments on the bug, supporting comments for JPEG XL started flowing in there around 24 August 2022 (with a couple early ones on Aug 16 and 17). Was there some publicity about JPEG XL around that time, and did someone urge others to request Google to enable it by default? I can imagine that that was when the decision process at Google started whether to keep or remove it. The reasons for removal given on October 31 are rather vague and seem to underestimate the interest in the format.

erk__ 4y ago
That was around the time the the final parts of the standardization procedure was getting finished: https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status https://en.wikipedia.org/wiki/JPEG_XL#Standardization_status
lifthrasiir 4y ago
That's when Adobe formally expressed a support for JPEG XL (comment 61), which is a big milestone by its own and people started to push Google to finish the experiment in lieu of that event, as everyone expected that it will land at some point, most likely shortly after libjxl reaches 1.0.

pornel 4y ago

Browser vendors have other priorities besides having the latest-greatest compressor: code size, attack surface, long-term maintenance and compatibility risks, and interoperability. Having a format that is a few percent smaller than the formats they already have is just not a high priority. This isn't a conspiracy against JPEG XL. Browser vendors (other than Google) have been resisting shipping WebP for 10 years, until Chrome-only websites forced them to. GIF still is a thing despite being by far the worst in every image benchmark. Every few years browser vendors are asked to adopt a new format, which is then beaten by an even newer format, but the vendors are stuck supporting the old one forever. They've dodged the bullet on JPEG 2000 and JPEG XR, but are now stuck with WebP (and AVIF, if they were to replace it). If in a few years it turns out everyone uses JXL and other vendors have it, Chrome can re-add it.

trasz2 4y ago
>Browser vendors have other priorities besides having the latest-greatest compressor: code size, attack surface, long-term maintenance and compatibility risks, and interoperability. You’ve missed two most important ones: “business reasons”, eg trying to harm some (potential) competitor, and someone trying to get promoted. Don’t assume there are valid technical reasons behind every corporate decision like those; usually there aren’t.
- pornel 4y ago
  Maybe if JPEG XL had a chat functionality, Google would have a motivation to include it… But seriously, it's an ISO standard with a free implementation. There's no Google competitor attached to it. Nobody gets prompted for failing to add features. Google is even missing out on a chance to make Safari look outdated again. There's no reason to interpret indifference as a conspiracy. BTW: I've worked on the HTML5 spec and codecs for many years, so I've seen how the sausage is made on both sides.
  - nirvanaman2k13 4y ago
    Incorrect. Facebook have said they want to use JPEG-XL. Facebook/instagram is definitely a big tech competitor to google, especially in regards to ads.

trasz2 4y ago

Daily reminder that Chrome (and Chromium) is not unlike other Google projects: users are its cattle, not its clients. It’s naive to assume good intentions here.

coding123 4y ago

Competition with webp. Elephant. Room.

croes 4y ago

Google's justification for removing this feature sounds like Tesla's for removing Radar.

jl6 4y ago

JPEG XL needs some support from the camera manufacturers. They’ve mostly gone with HEIF so far and seem unmotivated to do anything different.

quikee 4y ago
Camera manufacturers are old spineless companies. In all those years they have done nothing for digital image formats and it is the most important thing in a camera. They weren't even able to come up or attempt to make a standard RAW format. All that came from Adobe (DNG), which the camera manufacturers happily ignored for their own proprietary solution until this day.
- kasabali 4y ago
  Can't really blame camera manufacturers when RED is suing everyone who's shipped a feature even remotely resembling their patent portfolio.
  - quikee 4y ago
    Well RED is mostly suing for their RAW video compression patents, which are just dumb an should never be allowed to be passed in the first place (and AFAIK Nikon is currently battling to invalidate that). But this is also their own problem - they haven't put almost no R&D into the software side of digital photography and videography like formats, processing. They have a nice camera which outputs 12-bit and higher images - they should be the first ones requesting and defining a new image format for consumption, which can handle that.
erk__ 4y ago
JPEG XL was finalized 6-7 years after HEIF so I am not sure it is a good comparison. Especially seeing that JPEG XL was first finalized this and last year.
- jl6 4y ago
  I know, I’m just saying that HEIF is the next-gen incumbent to beat. A lot of comparisons are being done with WebP and AVIF and legacy JPEG, which aren’t the real competition.

ur-whale 4y ago

Pure politics is clearly and officially the only reason why Google does things these days. Best image codec on the planet has "not enough interest from ecosystem". Being able to say this on a public mailing list with a straight face goes a very long way in showing how disconnected from reality folks at Google now are. And it seems that comment comes from someone who claims to be an engineer ... that also goes to show the quality of engineers who still work there, where reality doesn't seem to factor in decision making anymore. There was a time where one of Google's motto was "put the user first and everything else will follow". LOL, how things have changed.

bioemerl 4y ago
You should see what they said about supporting DCHP on Android for ipv6. They have simply opted not to support it because you "should be using something else"
- vetinari 4y ago
  And they were right; nobody should use DHCP with IPv6. It is like bringing horse carts into space age.
deleted 4y ago
[deleted]
youngtaff 4y ago
There’s also the politics of them not supporting img=*.mp4 too https://bugs.chromium.org/p/chromium/issues/detail?id=791658 https://bugs.chromium.org/p/chromium/issues/detail?id=791658

josephscott 4y ago

This is disappointing to see, I had high hopes for JXL.

YetAnotherNick 4y ago

What's up with this JPEG XL cult in hacker news? I think the Chrome team pretty much handled this in the best way possible. They put everything in public and allowed anyone to comment on their main thread. They responded to lot of the comments. They seems to have their best intention in having JPEG XL implementation in chrome but the team decided it's not worth it, which is a valid decision for someone doing ROI analysis, after all engineers specialising in this are not cheap. It's like everyone is hinting at some conspiracy by Google here that is not there as they spent time in the spec and wanted to promote this. Even I think the incremental 20% gain of JPEG XL is probably not worth the security risk and increased maintenance. JPEG decoders had been targeted so many times in the past even though it had been audited by best security folks.

ksec 4y ago
I am probably the first few if not the first to put JPEG XL on HN's radar. I am definitely not in an JPEG XL Cult. Although I do dislike Google. I am simply a supporter of Better Tech. (And I am already omitting WebP hate here. ) And I suspect a lot of us are. And IMO neither WebP nor AVIF are better than JPEG XL. Had Google actually posted a thorough analysis, as they stated that JPEG XL is not better or even inferior to AVIF, and suggest they decide not to go with it. It would have been fine. ( I may disagree with their take, but at least you can see it from their POV ). Not only did they not do that, they provided the Data with out of date version of JPEG XL [1] and a set of test that does not represent the actual internet usage. Compared to [2], where JPEG XL is surprisingly better when they wont expected. So if, a) everything JPEG XL released and tested were true, and truly better than AVIF, then b) Why isn't Google supporting the better Image codec? I am also perfectly fine with Google saying, I dont like it. I hate it because It is not AOM even if JPEG XL is better. Fine. Chrome is Google's browser. Do what ever you want with it. Just dont ever come out again and say everything you do is better for the Web. [1] https://storage.googleapis.com/avif-comparison/index.html https://storage.googleapis.com/avif-comparison/index.html [2] https://twitter.com/jonsneyers/status/1563442356493230080 https://twitter.com/jonsneyers/status/1563442356493230080
- deleted 4y ago
  [deleted]

dang 4y ago

Related: Chrome team released the data for the decision to remove JPEG XL support - https://news.ycombinator.com/item?id=33866388 https://news.ycombinator.com/item?id=33866388 - Dec 2022 (1 comment) Revert “flag_descriptions: Add note about JPEG XL removal” - https://news.ycombinator.com/item?id=33803941 https://news.ycombinator.com/item?id=33803941 - Nov 2022 (17 comments) What Is JPEG XL? - https://news.ycombinator.com/item?id=33646153 https://news.ycombinator.com/item?id=33646153 - Nov 2022 (7 comments) Chrome Responds "No" to JPEG XL - https://news.ycombinator.com/item?id=33563378 https://news.ycombinator.com/item?id=33563378 - Nov 2022 (55 comments) The case for JPEG XL - https://news.ycombinator.com/item?id=33442281 https://news.ycombinator.com/item?id=33442281 - Nov 2022 (209 comments) Removing the JPEG XL code and flag from Chromium - https://news.ycombinator.com/item?id=33412340 https://news.ycombinator.com/item?id=33412340 - Oct 2022 (42 comments) Chrome drops JPEG XL, “not enough interest” - https://news.ycombinator.com/item?id=33404840 https://news.ycombinator.com/item?id=33404840 - Oct 2022 (4 comments) Google set to deprecate JPEG XL support in Chrome 110 - https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 - Oct 2022 (93 comments) Google Chrome Is Already Preparing to Deprecate JPEG-XL - https://news.ycombinator.com/item?id=33383880 https://news.ycombinator.com/item?id=33383880 - Oct 2022 (20 comments) What’s the best lossless image format? - https://news.ycombinator.com/item?id=31657006 https://news.ycombinator.com/item?id=31657006 - June 2022 (164 comments) FFmpeg now supports JPEG XL - https://news.ycombinator.com/item?id=31177098 https://news.ycombinator.com/item?id=31177098 - April 2022 (91 comments) The JPEG XL standard has now been formally approved - https://news.ycombinator.com/item?id=29598090 https://news.ycombinator.com/item?id=29598090 - Dec 2021 (17 comments) Using Saliency in progressive JPEG XL images - https://news.ycombinator.com/item?id=28468284 https://news.ycombinator.com/item?id=28468284 - Sept 2021 (44 comments) JPEG XL - https://news.ycombinator.com/item?id=27577328 https://news.ycombinator.com/item?id=27577328 - June 2021 (234 comments) JPEG XL would be Turing-complete without the 1024×1024 pixel limitation - https://news.ycombinator.com/item?id=27559748 https://news.ycombinator.com/item?id=27559748 - June 2021 (36 comments) JPEG XL - https://news.ycombinator.com/item?id=26186707 https://news.ycombinator.com/item?id=26186707 - Feb 2021 (1 comment) Overview of JPEG XL - https://news.ycombinator.com/item?id=25560683 https://news.ycombinator.com/item?id=25560683 - Dec 2020 (1 comment) Brunsli: Practical JPEG repacker (now part of JPEG XL) - https://news.ycombinator.com/item?id=22456764 https://news.ycombinator.com/item?id=22456764 - March 2020 (72 comments) JPEG XL: Next-Generation of Image Format for the Internet [video] - https://news.ycombinator.com/item?id=21612708 https://news.ycombinator.com/item?id=21612708 - Nov 2019 (3 comments) JPEG XL Reaches Committee Draft - https://news.ycombinator.com/item?id=20603501 https://news.ycombinator.com/item?id=20603501 - Aug 2019 (2 comments) JPEG XL is coming to store our photos at 1/3 size - https://news.ycombinator.com/item?id=19816485 https://news.ycombinator.com/item?id=19816485 - May 2019 (2 comments) JPEG XL could let you pack twice as many photos into your phone - https://news.ycombinator.com/item?id=17356913 https://news.ycombinator.com/item?id=17356913 - June 2018 (57 comments) JPEG XL could let you pack twice as many photos into your phone - https://news.ycombinator.com/item?id=17345470 https://news.ycombinator.com/item?id=17345470 - June 2018 (6 comments)

ProgramMax 4y ago

I don't speak for Google/Chrome but I really need to clarify something that keeps being misstated: The test of JPEG XL support has been removed. It was always behind a flag and never actually supported. That is not to say that Chrome will not ever support JPEG XL. The two concepts are fundamentally unrelated. So we should stop conflating them. In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case. And the thing they should be waiting on IMHO is wide spread support. Adding image formats to the web should be the last step because it is so difficult to remove them. I bet other browser devs in the image space wish they could remove ico support. Oh well. "So why add it in a test just to later remove it?" I hear someone ask. Because you want to make sure that path is clear and you're in position long before it is needed. Once you know the path is clear, you don't want to keep dead code around. It is easy enough to dig it out of old commits when the time comes. Heck, it could even be as simple as someone wanted to add a big item to their promo packet. Who knows. But at the end of the day, Chrome did not remove JPEG XL support. And I haven't seen anything saying Chrome wouldn't later add it. If we all want JPEG XL (I do), we should continue to help its adoption grow. Using it via WASM is a strong indicator. Get it to the point where "of course Chrome will add support -- it is everywhere".

ksec 4y ago
>Adding image formats to the web should be the last step because it is so difficult to remove them. Not from a company that added WebP to its browser and wanted a new video codec every 2 years.
dmitriid 4y ago
> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. I would argue this is likely the case. If Chrome deems that something is useful (to them, for some definition of useful), they just release it (and if this something was on a standards track, too bad, it's out now).
chungy 4y ago
> In fact, it could be that the test was successful and now Chrome is waiting on something else before it adds proper support. Waiting for libjxl 1.0 is reasonable. Though I can't help but to think it would be less work to just keep the experimental feature in there until it is stable.

cesarb 4y ago

Back in the good old days, things like these could be added through plugins, instead of requiring everything to go through the browser manufacturer. Plugins were removed mostly due to security issues (and also maintainability and portability worries), but nowadays that could be avoided by using WASM (see also https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/ https://hacks.mozilla.org/2020/02/securing-firefox-with-weba...).

niutech 4y ago
Have a look at WASM decoder JXL.js: https://github.com/niutech/jxl.js https://github.com/niutech/jxl.js

supermatt 4y ago

Please feel free to "star" the issue for jpegXL support. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... From reading through the justification for the removal it seems this decision was (in part) due due to some erroneously compiled benchmarks: > http://storage.googleapis.com/avif-comparison/index.html http://storage.googleapis.com/avif-comparison/index.html "That test was done in Chrome without even using the latest version of chrome! There were many performance improvements since. Additionally, the color format (yuvj444p) used is a color format no sane person would use for JpegXL. If they were to test different color formats, they would see JpegXL wins in all of them, except the exact one they used!" (https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c288 https://bugs.chromium.org/p/chromium/issues/detail?id=117805...)

return_to_monke 4y ago

seems like they backtracked on the issue just a hour ago; https://chromium-review.googlesource.com/c/chromium/src/+/4095497 https://chromium-review.googlesource.com/c/chromium/src/+/40...

jsnell 4y ago
No. It's some random person sending a pull request, which has not been accepted. Looking at their history [0], the account was created two weeks ago and the only contributions were attempts to revert earlier JPEG XL removal commits. Those requests were not accepted. [0] https://chromium-review.googlesource.com/q/owner:ayz.out%2540gmail.com https://chromium-review.googlesource.com/q/owner:ayz.out%254...
- return_to_monke 4y ago
  oh, okay. thanks for clarifying!

a1369209993 4y ago

Good riddance to bad rubbish. PNG 'optimizers' that change the image data rather than the compression and framing settings were bad enough; the last thing we need is to displace JPG/PNG entirely with a format that doesn't distinguish[0] between lossy and lossless compression in the first place. 0: No, embedded metadata doesn't count; the same format is being used for two incompatible kinds of compression.

lifthrasiir 4y ago
Unfortunately, if the format supports at least lossless compression (i.e. able to represent all uniform range in the pixel domain with a reasonable compression rate, amortized) then there is no practical way to distinguish lossy compression from lossless compression. PNG -> JPEG -> PNG is a lossy compression but the resulting output is seemingly lossless while it isn't.
- a1369209993 4y ago
  Sufficiently badly behaved software can definitely still screw you over, but with separate formats you at least have a chance to notice that there's a problem during the PNG -> JPEG part of the process. Decoders like libpng will outright refuse to handle JPGs, image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". With JPEG XL, images can get switched to lossy mode silently, without breaking anything, and then back, also silently, also without breaking anything. JPEGXL -> JPEGXL -> JPEGXL is a lossy compression that doesn't give you any intermediate state where touching the images will loudly scream "something is wrong here"; you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image.
  - lifthrasiir 4y ago
    > image viewers will usually refuse to handle JPGs named "image.png" (invalid png file), and even some web browsers at least say "image.png (JPEG Image)". As you have noticed, the latter behavior is slowly becoming a norm even for user-facing applications (paint.net for example can handle them) because users have no idea how .png and .jpg can differ. And good JPEG encoders have made a visual inspection a lot harder. It's kinda futile. > you just get compression artifacts, for no obvious reason, with no indication that they weren't already like that in the original image. I should note that, while this is hardly an ideal situation, generation loss in modern image formats is much harder to spot in the intended bits-per-pixel range. And JPEG XL is one of the best performing image formats in terms of generation loss, so repeated lossy compression is not a big issue for it.