Google set to deprecate JPEG XL support in Chrome 110 | Hacker News Reader

Google set to deprecate JPEG XL support in Chrome 110

phoronix.com

146 pointsberkut93 comments

Open articleView on HN

We've been planning to move all our image storage (business SaaS) over to JPEG-XL internally, for a few reasons:

- 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!

You planned to move your entire business to a feature that has thus far never been shipped by any browser?

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.

And sometimes that's what provides the edge over your competition.

Planned is the keyword here.

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.

And yet here we are. There are no-demand for it.

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.

> Once I hit the limit with jpg I switched to png

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 :(

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.

AOM = https://en.wikipedia.org/wiki/Alliance_for_Open_Media

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.

[1] https://mobile.twitter.com/jonsneyers/status/155021585930558...

All good reasons. But the complexity/ decision on how to behave with certain features could be a compelling reason to stop supporting.

In reality, they have webp which is enough for most of the use cases

> 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

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.

If it was the case, it is enough to say that. They didn't.

Everyone else support the other format? No one supports JXL

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.

[1] https://twitter.com/slightlylate/status/1587030785197953024

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.

This apparently goes nicely with the other article currently on the frontpage ...

> 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/

JPEG XL apparently never shipped, so the title of this post is misleading. You can’t deprecate something that never shipped.

chrome://flags/#enable-jxl

Since v91 or so.

It's not misleading, it's wrong. Deprecation means you can still use the thing. This is removal.

While it seems JPEG XL is very nice, I think the comment 72 from Kornel Lesinski is spot on:

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.

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.

Thanks for clarification! Are those truly independent implementations? (i.e. not derived from each other? I'm not deep into the subject.)

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.

This seems very odd given that the previous discussion [1] seemed like adoption was increasing.

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

Most likely they want to push their own "WebP" format.

If anything it would be AVIF nowadays, which is a format that all big browser vendors stand behind, including Apple and Google

WebP2 also got "demoted" (https://chromium.googlesource.com/codecs/libwebp2/+/1251ca74...):

    -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.

> - There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL

Gee. Maybe there's no interest because nobody can use it yet because it's behind a feature flag.

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.

> 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.

I mean, you're still talking about it, now, much later. If it was really no struggle people would have forgot about it at this point.

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.

True, because I saw how it was just being added to software/frameworks. Some parts of the web move slower than Google expects, I have a feeling.

Previous discussion: https://news.ycombinator.com/item?id=33383880

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.

JPEG-XL is a

> 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.

> AVIF has nothing to do with Google,

That's where we disagree, then.

I really hope this is revisited - JXL seems to be faster and better compression than HEIC/AVIF.

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.

> 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.

I'm so glad I've never worked in these kind of companies... It sounds like an awful workplace.

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.

I said nearly-proprietary. WebP is technically open but nobody would give a crap about it if Google weren't promoting it.

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.

You do know that Google was one of the main contributors to JPEG XL (see https://github.com/google/pik ) ?

We changed the URL from https://chromium-review.googlesource.com/c/chromium/src/+/39... to an article that has (a bit) more background.

(via https://news.ycombinator.com/item?id=33400436, but no comments there)

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.

Could you provide a link to this WASM implementation? I can find JXL-WASM decoder, which is 1.23 MB: https://unpkg.com/browse/jxl-wasm@0.7.0/lib/

How disappointing. JPEG XL is a much nicer format than AVIF, but Youtube forcing AV1 through meant AVIF is an easy ride-along.

Bummer, I liked jxl better than heic or avif. Guess avif will be the eventual winner then. At least I hope heic dies someday.

I hope heic dies someday

Not anytime soon.

Every picture taken with the stock iOS Camera app is saved in HEIC. That’s billions of HEIC files.

Yeah, it's unfortunate, but they are often converted before sharing.

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.

WebKit supports JPEG XL behind a build flag.

The images I've set up for web use are not very large. I don't have a RAW workflow.

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?

The internet is what G tells you the internet is. So get in line.

Screw that.

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.

Startup idea, WASM decoder for JXL format!

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.

[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...

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:

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.

To be fair, if there's a need Mozilla and Apple could inplement JXL support and then Google would very likely follow.

It doesn't have to be or should be Google to lead the adoption of something.

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.

Reply on news.ycombinator.com