13 ms·

Chrome still hasn't changed its opinion about dropping JPEG XL support

288 points by ciccionamente 3y ago

JyrkiAlakuijala 3y ago
Mark the bug with a star to indicate interest. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... Apple adding JPEG XL was one of the happiest days in my life. Thank you Apple!
chrismorgan 3y ago
Discussed when it happened seven months ago: https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 (2022-10-30, 146 points, 95 comments) Also a few more submissions of issue 1178058: https://news.ycombinator.com/item?id=33403430 https://news.ycombinator.com/item?id=33403430 (2022-10-31, 13 points, 2 comments) https://news.ycombinator.com/item?id=33412340 https://news.ycombinator.com/item?id=33412340 (2022-11-01, 60 points, 42 comments) https://news.ycombinator.com/item?id=33705725 https://news.ycombinator.com/item?id=33705725 (2022-11-23, 32 points, 1 comments)
- est31 3y ago
  I think the big difference since the recent threads is the news that Apple is adding support for JPEG XL to Safari. For HEIC, I understand, but it's weird that they are the only ones supporting JPEG XL while it is a royalty free open standard and the open source browsers don't support it.
  - AprilArcus 3y ago
    WebKit (Safari's rendering engine) is open source. WebKit is a fork of KHTML and Blink (Chromium's rendering engine) is a fork of WebKit.
    - est31 3y ago
      I am aware, but note that Safari relies on ImageIO for image decoding and AVFoundation for video decoding, two components of the proprietary OS. Chrome and Firefox on the other hand ship a lot of their own decoders. Those parts are not open source (nor is the GUI, while Chrome is open source also from the GUI point of view, it's really just a bunch of google-custom modifications/extensions that are closed).
Demmme 3y ago
Still never seen or used jpeg xl and I don't know anyone using it ever. I'm surprised that this is a problem at all.
- iopq 3y ago
  Yeah, since Chrome doesn't support it, why would anyone use it? It's a chicken and egg problem
  - spiralpolitik 3y ago
    If you use a service like Cloudinary then it will detect the appropriate image format to serve to the browser based on the request. I would expect JPEG-XL to start being served to Safari clients once macOS 14 and iOS 17 are released. Chrome can hold out but ultimately all they are doing is hurting their users.
    - llm_nerd 3y ago
      You don't even have to use a service. A picture element containing sources by priority, and then finally an img fallback for the obsolete browsers, allows you to use the best possible codec that the client supports.
- hirako2000 3y ago
  Certain company that commented on the thread already turned their image processing pipelines to use jpeg xl instead, given the significant bandwidth savings. Now all they got is the significant hole in budgets since it may never pay off. We can't know how many are using jpeg xl since there is no available metrics to find out.
  - Demmme 3y ago
    We can easily scrap the internet. There should be a statistic about it. But for companies they should have two formats anyway: the original file and the optimized file. Changing the optimized file should be an existing batch process
PaulHoule 3y ago
I was talking with a Googler on Mastodon the other day who was astonishingly ignorant about how his own product works and blaming me for it. If they were going to put a definition for "gaslighting" in the dictionary it might be good to put in Google's product evangelism in as an example. There was that time I met Bing's developer evangelist for search at a conference and told him that if he was Matt Cutts I would have called room service and ordered a cream pie.
- kyrra 3y ago
  Was it someone that works on Chrome, or just a random Googler? As a reminder, Google employs 190,711 people (as of last SEC filing).
  - PaulHoule 3y ago
    A "dev evangelist" for Chrome. Amazing that somebody with a job that involves communicating with the public would be so rude. Seems to have stolen his playbook from the bullies that chased me around the playground in elementary school.
    - wh0thenn0w 3y ago
      Link to conversation?
      - jonas-w 3y ago
        Quick search showed this thread (maybe its that one?): https://mastodon.social/@UP8/110492207881449484 https://mastodon.social/@UP8/110492207881449484
        marcosdumay 3y ago
        Ouch. If somebody told me that account is a bot, I wouldn't think twice about it. But it doesn't look hostile. It's just random noise.
guardiangod 3y ago
This is starting to feel like the IE6 situation. 1. Someone comes up with a cool feature. 2. Browser developer refuses to incorporate it since "No one uses it!". Pushes developed in-house technology instead. 3. No one uses the feature as a result. "See no one wants it!" 4. Competitors start to implement the feature 5. ??? And no, pollyfill is again not the (right) solution.
- chrischen 3y ago
  It’s like QR codes too. First it was invented… but no phone platform supported it natively, then WeChat in China built a platform and ecosystem within phone platforms and bundled a QR code reader which made it take off in China, then something like 10 years later Apple adds QR scanning to the camera app and we get pervasive QR codes finally. Saying “nobody uses it” is a copout if you are a de-facto monopoly.
  - vlovich123 3y ago
    That's not correct. Firstly, it had taken off in Japan a long time ago. Blackberry supported it in fact and I remember being at an intern recruiting event where the recruiter was smug about QR codes being on the cusp of mass adoption (being more than a decade early is wrong for this kind of stuff). The problem was that the UX sucked. The UX today still kind of sucks but it's infinitely better than what was available when QR codes were first around by being integrated into the camera app.
    - throw0101c 3y ago
      > That's not correct. Firstly, it had taken off in Japan a long time ago. It was in fact invented in Japan: * https://en.wikipedia.org/wiki/QR_code https://en.wikipedia.org/wiki/QR_code
  - mlindner 3y ago
    Pretty sure China had no part in popularizing it and third party apps had support for it on iPhone a long time ago. I was seeing and using QR codes here in the US back in 2010 or so pretty commonly. They were limited to college campuses and SF bay area then but still were around plenty. I remember being frustrated that my non-smartphone flip-phone didn't support them (and no way to add support for them either).
botanical 3y ago
macOS 14 will support JPEG XL: https://news.ycombinator.com/item?id=36202088 https://news.ycombinator.com/item?id=36202088
- tomstockmail 3y ago
  Firefox has an open item regarding support, also available in Nightly editions behind a flag: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
  - PrimeMcFly 3y ago
    I hope they do support it. Edge as well. The more browsers/OSes that do the more demand there will be for Chrome to support it.
    - samtheprogram 3y ago
      Edge et al are not going to support it unless Blink does. Firefox and Apple will have to lead the way here if Google doesn't.
      - PrimeMcFly 3y ago
        MS can extend Edge (and its version of Blink) with whatever support they want. I could see them supporting it to hinder Chrome/Google honestly.
        samtheprogram 3y ago
        Good point (embrace, extend, extinguish), but if they try I doubt they could compete with Google on Blink development here.
        kasabali 3y ago
        It isn't competing with Google on Blink development, it's simply adding support for the new JPEG image standard (which they're probably going to have as a system codec anyway in that case). Note that they've had HEVC playback support in Edge before Chrome.
sys42590 3y ago
How does JPEG XL compare to e.g. WebP?
- tourmalinetaco 3y ago
  Better compression, similar to AVIF, with even more features.
- brucethemoose2 3y ago
  Its "competitor" is AVIF, not webp. The TLDR version is AVIF is better at low bitrates/quality, JXL is better at higher bitrates/quality. And JXL has some other niches, like easier encoding/decoding, lossless conversion of JPEG, and support for some exotic formats that AVIF does not support. In other words, we need both.
- peterangular 3y ago
  Another important thing to mention is that WebP, HEIC, and AVIF are all based on video codecs whereas JPEG XL is a traditional image codec. I find this article describes the differences and pluses/minuses incredibly well: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... TLDR in the article is that both technologies are valid and have a significant use case. I still work plenty with the browser and would _absolutely_ use JPEG XL as a replacement for WebP images, traditional JPEGs, and PNGs if I could. It's a shame Google/Chrome is not supporting the tech. It would be a major improvement in the landscape.
- spiralpolitik 3y ago
  See the link below for benefits and examples: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... The big one is that you can transcode existing JPEG files effectively and reversibly to JPEG XL without any additional loss. So you can get the benefits of the new format without having to re-sample your existing JPEG images.
- fold3 3y ago
  webP and avif are basically video codecs that can eventually render a frame as a static image and are good at masking low res artifacts. On the other hand, JPEG XL is for static images only and is way better at rendering fine details. It has a bunch of specific features and optimizations. if you want to know more in details, check this post: https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl
jacksgt 3y ago
I would really like to start converting some of my personal media and websites to use JPEG XL, but the momentum doesn't seem there yet - despite clear technical and practical benefits.
- aimor 3y ago
  I just went ahead and did it, then included fallbacks to supported formats. What I really want is a standard way to let the browser request lossy or lossless images.
ranting-moth 3y ago
Does anyone have a quick summary what this is all about?
- devmor 3y ago
  JPEG XL is a file format for large raster images that provides a better compression ratio and higher quality than JPEG. Google owns the license to another proprietary image format for large raster images (WEBP). Google used to support JPEG XL in chromium, but dropped support for it. Many people believe this is specifically to manipulate a market advantage for WEBP.
  - chrismorgan 3y ago
    > Google used to support JPEG XL in chromium No, they had an experimental implementation, behind a flag. No stable version of Chromium has ever supported JPEG XL. (The claimed reasons for the removal: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805.... This is the last comment by an @chromium.org account.)
    - altairprime 3y ago
      Those reasons, lifted from the wasteland of the bug linked: - 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
  - jonatron 3y ago
    What about WebP is proprietary?
    - spiralpolitik 3y ago
      Only Google can make changes to the WebP specification and can do so unilaterally. The JPEG-XL specification is governed by a recognized standards body (ISO).
jamesfmilne 3y ago
Posting obnoxious, demanding messages on the Chromium bug tracker is not the way to win friends & influence people. It's just an image file format for Pete's sake.
- paulddraper 3y ago
  [flagged]
- pikelet 3y ago
  Way to be reductive. It's a very thorough summary of the situation, hardly low effort or obnoxious. If you think it's 'just an image format' then you aren't the target audience. Move on. This was a very controversial decision that could have long lasting effects on the industry. See the rest of the linked thread if you are actually interested in why that is. If not, why comment?
- Fauntleroy 3y ago
  If we followed this line of thinking, we'd all still be using BMP and GIF for everything.
  - pornel 3y ago
    Well, Chrome couldn't be convinced to support for MP4 in <img> like Safari does.
- peppermint_gum 3y ago
  > Posting obnoxious, demanding messages on the Chromium bug tracker is not the way to win friends & influence people It's true, although it should be noted that this is the result of the Chromium team acting in bad faith and gaslighting the users. These are the stated reasons for the removal of JPEG XL: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... "Experimental flags and code should not remain indefinitely" Why wasn't AVIF hidden behind an experimental flag? "There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL" This is gaslighting. The representatives of companies such as Adobe, Facebook, Intel, The Guardian or Shopify have voiced their support for the format. Not to mention the countless individuals. I don't recall AVIF getting anywhere near this level of interest. "The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default" Really? https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl BTW, this article doesn't even mention all of the JPEG XL's advantages. For instance, it doesn't mention the high resolution support. AVIF images are limited to 65536x65536, but images larger than 8192x4352 must be tiled, which results in border artifacts between the tiles. JPEG XL, on the other hand, has no problems with images up to 1073741823x1073741823.
we_never_see_it 3y ago
[flagged]
- webmobdev 3y ago
  In that case Vivaldi browser is a much better Chrome clone as you can avoid both Google and Microsoft malware.
  - brucethemoose2 3y ago
    Thorium is the Chrome fork de jure for me. It strips most of the bad and its and fast. I like Vivaldi, but I dont really need all its extra stuff.
- vlovich123 3y ago
  Huh? This is the same engine no? Is Edge implementing it even though Blink isn't?
- bornfreddy 3y ago
  Interesting, do you prefer Microsoft malware to Google malware?
- deleted 3y ago
  [deleted]
baggy_trough 3y ago
Now what would really be great is if Microsoft Edge could support AVIF. That's the last holdout.
- webmobdev 3y ago
  AVIF is more compute intensive than HEVC.
- Timon3 3y ago
  It seems it just got implemented behind a CLI flag: https://winaero.com/avif-support-is-now-available-in-microsoft-edge/ https://winaero.com/avif-support-is-now-available-in-microso... So, hopefully not too much longer!
  - baggy_trough 3y ago
    Unfortunately I think there's some patent/legal headache involved.
    - Timon3 3y ago
      That's rather unlikely, otherwise they wouldn't already ship it behind a feature flag.
      - baggy_trough 3y ago
        Apparently there isn't really anything behind that flag. See: https://stackoverflow.com/questions/75459594/why-doesnt-edge-support-avif-images https://stackoverflow.com/questions/75459594/why-doesnt-edge...
        Timon3 3y ago
        If you're referring to the first answer, the last update is almost a month older than the article I posted. Are you referring to something else? If not, are you suggesting the article I posted is lying? There are a bunch of articles on this topic/flag, which were posted on the same day as the link I wrote earlier (17th of April).
brucethemoose2 3y ago
As said before, the commiter of the JXL removal is an AOM contributor, and the manager who approved it has given presentations on AV1. This is politics, not a technical discussion.
- shadowgovt 3y ago
  Half of tech is politics. Why else are all the measurements around here in feet instead of meters?
  - paulddraper 3y ago
    Does "here" mean HN? YC is an US company, and its network is US-based.
- orra 3y ago
  That's frustrating. Having a royalty free, high quality, video codec is great. But it shouldn't prevent us having a significantly better still image format.
- jonas-w 3y ago
  What is AOM in this context?
  - lonjil 3y ago
    Alliance of Open Media, the multi-company consortium that develops and promotes AV1 and AVIF.
- pornel 3y ago
  There are very few people working with image codecs, and you will not find a codec "virgin" among people responsible for these subsystems. One of the main JPEG XL contributors is a WebP contributor and a Google employee. If JPEG XL got shipped first you could make the opposite conspiracy from that!
  - brucethemoose2 3y ago
shadowgovt 3y ago
It's an open source browser, right? If it's important, someone should just implement support for it.
- zarlss43 3y ago
  Chromium is an open-source browser, not Chrome.
  - shadowgovt 3y ago
    So implement it in chromium, and the conversation can move to "why is Chrome not adopting this feature that is already compatible with the codebase?"
    - lonjil 3y ago
      Chrome and Chromium are the same dev team. Open source doesn't mean that they'll accept any pull request. It was implemented in Chromium, as an experimental feature, and then removed.
      - lopkeny12ko 3y ago
        Have you never heard of forking?
        spider-mario 3y ago
        Like this? https://github.com/Alex313031/thorium-libjxl/tree/67097321232ff849b8877c6329688f06fad69d35 https://github.com/Alex313031/thorium-libjxl/tree/6709732123...
        shadowgovt 3y ago
        Excellent. This is a good approach. The most hilarious way to deal with Google's lack of leadership would be to build out a browser that rivals their offering on top of their own core.
lonjil 3y ago
I don't see any comments from any Chrome developer since the Safari news, so the headline here on HN doesn't make a whole lot of sense.
- altairprime 3y ago
  macOS Sonoma will support JPEG XL, so presumably all Apple platforms will, come September or so. OP is blogging by title edit, less than 24 hours later, about how Chrome hasn’t reversed their decision.
  - jdiff 3y ago
    Saying they haven't reversed their decision sounds like they affirmed their previous decision in spite of changing circumstances. Nobody popping up and saying something is more "nothing's stirred publicly on the Chrome front" than "Chrome still hasn't changed their opinion."
    - altairprime 3y ago
      I agree that it’s a misleading headline, but sadly there’s nothing more I can do to remedy that, other than clarify for others in a comment (and flag the post).
modeless 3y ago
Give it a minute. The news that Safari would add JPEG XL just dropped yesterday. Given that big change the decision may be reconsidered, but not in one day.
- taylorbuley 3y ago
  Patience is a well-measured response.
mike_hearn 3y ago
[flagged]
- shkkmo 3y ago
  Egregious off topic self promotion going on here.
  - altairprime 3y ago
    Please email the mods about perceived guidelines violations, using the footer contact link.
  - mike_hearn 3y ago
    Well, sorry you think that. I wrote the product exactly because I was tired of hitting browser limitations in previous projects, but the alternatives were too difficult and so people would sometimes just give up rather than tackle the deployment problem. This thread is about people upset about browser limitations, something that's trivial to fix when not writing web apps - just add libjxl into your app and use it. So that's why it seems relevant to me. Yes, it doesn't help if what you're doing has to be a web page, but often there's a choice.
eimrine 3y ago
Why browsers can not have features as binaries on OS? For example, I can drop Ogg Vorbis support from my Debian but one is a nightmare - if Debian's devs would manage to dictate me what codecs I can use and what I can not.
- modeless 3y ago
  Linux distributions are free to distribute their own builds of Chromium with whatever features they want. It's just that distributing a fork of Chromium, even with minimal changes, is a full time job for several people at least, due to the fast pace of updates and the security critical nature of browsers. And people prefer Chrome anyway due to the features that rely on Google servers like sync or translation.
- nimish 3y ago
  We had binary plugin support before. It didn't work out well.
qwertfisch 3y ago
The referenced comment does not even take into account that also the lossless compression is more efficient than PNG. This and the easy handling and efficient storing of (short) animations could in total combine the three major image formats: JPG, PNG and GIF. Even when gifs are now mostly replaced by webm and HTML5 viideo tag, the unification of image formats for both orthogonal uses (natural images vs. technical or generated images) is a big advantage.
- account42 3y ago
  I'm still disappointed that you can't use (silent) videos in <img> tags or CSS properties where you can use images. Animated webp is so much less efficient than webm its not even funny. There are many places where you can already embed images (including GIF and animated WEBP) but video is not supported or has other restrictions.
  - ed25519FUUU 3y ago
    But you have to acknowledge the psychological expectations are not the same with the two formats. A GIF? Looping video, maybe 3 seconds long. A silent video? Hours and hours.
    - lonjil 3y ago
      But you can already do that. AVIF animations are regular AV1 videos. There is zero end user visible difference between what the above user is proposing and what AVIF does. Allowing webm in img tags would be identical.
sitkack 3y ago
Polyfill using Wasm. I see almost no downsides. you can even use the original code.
- themerone 3y ago
  The wasm implementation is too slow for mainstream adoption. It also has to decode the image to a format supported by Chrome, which means you lose a lot HDR abilities. JpegXL can go to 32bit, but the supported formats max out at 12.
  - sitkack 3y ago
    Between WebGPU and WasmSIMD, I think much could be done to make it performant enough.
rcme 3y ago
Is there any benefit to JPEG XL (over other formats) other than old JPEGs can be losslessly re-encoded?
- pikelet 3y ago
  Doesn't the linked comment answer that exact question?
- quikoa 3y ago
  Compared to JPEG: JPEG has been hitting its limits for an extended period: JPEG can only do 8-bit color depth, no HDR. JPEG can only do lossy, with no lossless support JPEG lacks good compression for graphics images JPEG cannot do alpha transparency JPEG cannot do animations JPEG does not support multiple layers JPEG compression efficiency is 30 years old and not as good JPEG comes with annoying compression artifacts we all love Banding, Noise, Blockiness, and more banding. For much more, here is a comprehensive overview: https://jpegxl.io/articles/faq/ https://jpegxl.io/articles/faq/
  - rcme 3y ago
    I didn't mean to compare JPEG XL to JPEG. I'm more curious if there is any advantage to JPEG XL over WebP or AV1.
    - jonsneyers 3y ago
      Here's a summary of the main points: https://jpegxl.info/why-jxl.html https://jpegxl.info/why-jxl.html Basically lossy WebP and AVIF are video codecs, which are designed for the kind of quality you want when you can only see an image for 40 milliseconds or less. For still images, higher fidelity is usually desired but the video codecs tend to struggle to even keep up with the old JPEG at those operating points. Similarly, video codecs are not designed for progressive decoding (rendering previews of a frame based on partial data), because that's a feature that doesn't make much sense for video. For still images on the web, progressive decoding is considered a desirable feature though to improve the user experience.
lopkeny12ko 3y ago
This terse comment from the bug is an accurate summary of how projects work at Google, whose side effect was JPEG XL's removal: > The code has been removed from Chromium (comment #281), I'm closing this bug for now. If leadership revisits the decision [1] it can be reopened. There you have it--the people making decisions are out-of-touch, likely-non-technical managers, not engineers. Engineers are the ones writing the code and shipping features. Why not empower them to make these decisions?
- ed25519FUUU 3y ago
  Non-technical leadership is no longer a byword to me. I’ve sat through too many bikeshed meetings. Maybe JPEG-XL is more important to technical users than chromes actual users?
  - jdiff 3y ago
    Without a doubt. If you're lucky, they might know the difference between a JPEG and a PNG. This is a technical discussion at its core, you wouldn't expect Chrome's actual users to know about Flexbox or ES6, either. There's little you can't do without these, but things are transparently better with them anyway.
  - pikelet 3y ago
    Just because they don't understand something or don't know about it doesn't mean it doesn't benefit them.
dang 3y ago
Related: JPEG XL support has officially been removed from Chromium - https://news.ycombinator.com/item?id=33933208 https://news.ycombinator.com/item?id=33933208 - Dec 2022 (378 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) More at https://news.ycombinator.com/item?id=33935571 https://news.ycombinator.com/item?id=33935571
skrowl 3y ago
[dead]
sandstrom 3y ago
Here is a recent (today) blog post from the Safari team, spelling out JXL support: https://www.webkit.org/blog/14205/news-from-wwdc23-webkit-features-in-safari-17-beta/ https://www.webkit.org/blog/14205/news-from-wwdc23-webkit-fe...
deleted 3y ago
[deleted]
gandalfff 3y ago
"It's open source, just fork it."
cendyne 3y ago
Looking forward to when edge services like Cloudflare, Cloudimage, imgix, etc. support JXL too. AVIF has such a harsh encoding time. It is also a bit too bulky in wasm on the edge to encode yourself too.
- pornel 3y ago
  So far the blocker has been lack of alternative implementations of JPEG XL. A big complex format implemented in young C++ codebase is scary to deploy. Additionally, everyone using exact same code creates a risk of files being "bug-compatible" with that code, rather than conforming to the spec. There are now multiple alternative implementations in the works, including in safer languages, so hopefully it will be easier to deploy in the near future.
bawolff 3y ago
I don't know why HN is so obsessed with this particular image format. Adding image formats on the web has a really high maintainability cost and there is a fairly reasonable argument that it wasn't worth it in this case.
- jeroenhd 3y ago
  It's better WebP, without patents and license fees (so unlike HEIC). There are also advantages to encode and decode speeds compared to other formats. It's a superior format compared to most alternatives in many situations. Adding the format and maintaining it requires some work, but the potential for load speeds and data savings is huge. It's also finally a somewhat efficient format for bitmap animations after all these years of GIF and APNG. I've also run into the 16k size limit while converting some PNGs to WebP myself, to JPEG XL would be a nice way to losslessly compress those images more efficiently as well. That said, so far WebP is serving me fine in most cases, I don't really care if it takes two weeks or two years for JPEG XL to make it into the mainstream.
  - pornel 3y ago
    It doesn't matter that it's better than WebP, because that isn't the alternative. The alternative that browsers have shipped is AVIF. JPEG XL's advantage over AVIF is less significant. It's not a clear win, but diminishing returns and nice-to-have features vs AVIF's wider deployment and head start in AV1 implementations.
- padjo 3y ago
  It’s a litmus test for some people of how much google is turning into 90s era Microsoft
  - jsnell 3y ago
    The analogy makes no sense, given JPEG XL was primarily created by Google. That's what makes the reaction so strange. If JPEG XL had been enabled by default in Chrome instead of removed, would HN be happy? Or would we be up in arms about how Google is trying to force yet another image format on the browser ecosystem?
jeroenhd 3y ago
For the next few months at least, it looks like JPEG XL is just going to be one of those formats for Apple users, like HEIC. With people complaining about programs not supporting WEBP all the time, JPEG XL isn't going to gain much popularity in the mainstream either. At least people supporting Safari will be able to make use of the format for faster load times soon; the <picture> element makes the transition quite painless after all.
- lonjil 3y ago
  An interesting difference with the WebP situation is that any app that uses Apple's codec framework on iOS/iPadOS, which is almost all apps that deal with images, will support JXL automatically. Actually, I just downloaded a JXL via Safari, and after confirming that it was still a JXL, I tried using it in a context where JXL isn't supported, and it automatically turned into a JPEG.
IvyMike 3y ago
Half joking: in the world where Google added JPEG XL using the normal process, the reaction would vary from mild disinterest to outright disapproval. "Google is forcing yet another image format down our throats!" But by adding and then removing the feature, they've made it a competition. Now JPEG XL is building grass-roots support, and if/when Google relents and adds JPEG XL back, the feature will have much higher support than the boring way.
pornel 3y ago
I'm curious whether Apple will eventually move away from HEIC for their camera roll and other internal uses. Now that would be an incredible win for royalty-free codecs. As for browsers, this looks like the competition that's needed to convince Chrome. If it gains adoption and gives Safari a performance/quality edge that users notice, Chrome will have to follow. For browser vendors, all web-exposed code is a maintenance cost, security risk, and compatibility risk, so they generally don't add stuff just because it's nice. But they do add stuff to beat their competitors.
- jonsneyers 3y ago
  We may have to wait for hw jxl encoders for that. Which is likely to happen, but it will definitely take time. Meanwhile there will be software options for authoring, e.g. Adobe Camera Raw. For the web, the trade-offs between encode speed, compression , and fidelity consistency are quite clearly in jxl's favor. Avif still has the advantage in terms of support of course, but deploying jxl just for Safari already makes sense for many use cases. When Chrome follows, it will become a no-brainer.

288 points by ciccionamente 3y ago

Mark the bug with a star to indicate interest. https://bugs.chromium.org/p/chromium/issues/detail?id=1178058 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... Apple adding JPEG XL was one of the happiest days in my life. Thank you Apple!

chrismorgan 3y ago

Discussed when it happened seven months ago: https://news.ycombinator.com/item?id=33399940 https://news.ycombinator.com/item?id=33399940 (2022-10-30, 146 points, 95 comments) Also a few more submissions of issue 1178058: https://news.ycombinator.com/item?id=33403430 https://news.ycombinator.com/item?id=33403430 (2022-10-31, 13 points, 2 comments) https://news.ycombinator.com/item?id=33412340 https://news.ycombinator.com/item?id=33412340 (2022-11-01, 60 points, 42 comments) https://news.ycombinator.com/item?id=33705725 https://news.ycombinator.com/item?id=33705725 (2022-11-23, 32 points, 1 comments)

est31 3y ago
I think the big difference since the recent threads is the news that Apple is adding support for JPEG XL to Safari. For HEIC, I understand, but it's weird that they are the only ones supporting JPEG XL while it is a royalty free open standard and the open source browsers don't support it.
- AprilArcus 3y ago
  WebKit (Safari's rendering engine) is open source. WebKit is a fork of KHTML and Blink (Chromium's rendering engine) is a fork of WebKit.
  - est31 3y ago
    I am aware, but note that Safari relies on ImageIO for image decoding and AVFoundation for video decoding, two components of the proprietary OS. Chrome and Firefox on the other hand ship a lot of their own decoders. Those parts are not open source (nor is the GUI, while Chrome is open source also from the GUI point of view, it's really just a bunch of google-custom modifications/extensions that are closed).

Demmme 3y ago

Still never seen or used jpeg xl and I don't know anyone using it ever. I'm surprised that this is a problem at all.

iopq 3y ago
Yeah, since Chrome doesn't support it, why would anyone use it? It's a chicken and egg problem
- spiralpolitik 3y ago
  If you use a service like Cloudinary then it will detect the appropriate image format to serve to the browser based on the request. I would expect JPEG-XL to start being served to Safari clients once macOS 14 and iOS 17 are released. Chrome can hold out but ultimately all they are doing is hurting their users.
  - llm_nerd 3y ago
    You don't even have to use a service. A picture element containing sources by priority, and then finally an img fallback for the obsolete browsers, allows you to use the best possible codec that the client supports.
hirako2000 3y ago
Certain company that commented on the thread already turned their image processing pipelines to use jpeg xl instead, given the significant bandwidth savings. Now all they got is the significant hole in budgets since it may never pay off. We can't know how many are using jpeg xl since there is no available metrics to find out.
- Demmme 3y ago
  We can easily scrap the internet. There should be a statistic about it. But for companies they should have two formats anyway: the original file and the optimized file. Changing the optimized file should be an existing batch process

PaulHoule 3y ago

I was talking with a Googler on Mastodon the other day who was astonishingly ignorant about how his own product works and blaming me for it. If they were going to put a definition for "gaslighting" in the dictionary it might be good to put in Google's product evangelism in as an example. There was that time I met Bing's developer evangelist for search at a conference and told him that if he was Matt Cutts I would have called room service and ordered a cream pie.

kyrra 3y ago
Was it someone that works on Chrome, or just a random Googler? As a reminder, Google employs 190,711 people (as of last SEC filing).
- PaulHoule 3y ago
  A "dev evangelist" for Chrome. Amazing that somebody with a job that involves communicating with the public would be so rude. Seems to have stolen his playbook from the bullies that chased me around the playground in elementary school.
  - wh0thenn0w 3y ago
    Link to conversation?
    - jonas-w 3y ago
      Quick search showed this thread (maybe its that one?): https://mastodon.social/@UP8/110492207881449484 https://mastodon.social/@UP8/110492207881449484
      - marcosdumay 3y ago
        Ouch. If somebody told me that account is a bot, I wouldn't think twice about it. But it doesn't look hostile. It's just random noise.

guardiangod 3y ago

This is starting to feel like the IE6 situation. 1. Someone comes up with a cool feature. 2. Browser developer refuses to incorporate it since "No one uses it!". Pushes developed in-house technology instead. 3. No one uses the feature as a result. "See no one wants it!" 4. Competitors start to implement the feature 5. ??? And no, pollyfill is again not the (right) solution.

chrischen 3y ago
It’s like QR codes too. First it was invented… but no phone platform supported it natively, then WeChat in China built a platform and ecosystem within phone platforms and bundled a QR code reader which made it take off in China, then something like 10 years later Apple adds QR scanning to the camera app and we get pervasive QR codes finally. Saying “nobody uses it” is a copout if you are a de-facto monopoly.
- vlovich123 3y ago
  That's not correct. Firstly, it had taken off in Japan a long time ago. Blackberry supported it in fact and I remember being at an intern recruiting event where the recruiter was smug about QR codes being on the cusp of mass adoption (being more than a decade early is wrong for this kind of stuff). The problem was that the UX sucked. The UX today still kind of sucks but it's infinitely better than what was available when QR codes were first around by being integrated into the camera app.
  - throw0101c 3y ago
    > That's not correct. Firstly, it had taken off in Japan a long time ago. It was in fact invented in Japan: * https://en.wikipedia.org/wiki/QR_code https://en.wikipedia.org/wiki/QR_code
- mlindner 3y ago
  Pretty sure China had no part in popularizing it and third party apps had support for it on iPhone a long time ago. I was seeing and using QR codes here in the US back in 2010 or so pretty commonly. They were limited to college campuses and SF bay area then but still were around plenty. I remember being frustrated that my non-smartphone flip-phone didn't support them (and no way to add support for them either).

botanical 3y ago

macOS 14 will support JPEG XL: https://news.ycombinator.com/item?id=36202088 https://news.ycombinator.com/item?id=36202088

tomstockmail 3y ago
Firefox has an open item regarding support, also available in Nightly editions behind a flag: https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
- PrimeMcFly 3y ago
  I hope they do support it. Edge as well. The more browsers/OSes that do the more demand there will be for Chrome to support it.
  - samtheprogram 3y ago
    Edge et al are not going to support it unless Blink does. Firefox and Apple will have to lead the way here if Google doesn't.
    - PrimeMcFly 3y ago
      MS can extend Edge (and its version of Blink) with whatever support they want. I could see them supporting it to hinder Chrome/Google honestly.
      - samtheprogram 3y ago
        Good point (embrace, extend, extinguish), but if they try I doubt they could compete with Google on Blink development here.
        kasabali 3y ago
        It isn't competing with Google on Blink development, it's simply adding support for the new JPEG image standard (which they're probably going to have as a system codec anyway in that case). Note that they've had HEVC playback support in Edge before Chrome.

sys42590 3y ago

How does JPEG XL compare to e.g. WebP?

tourmalinetaco 3y ago
Better compression, similar to AVIF, with even more features.
brucethemoose2 3y ago
Its "competitor" is AVIF, not webp. The TLDR version is AVIF is better at low bitrates/quality, JXL is better at higher bitrates/quality. And JXL has some other niches, like easier encoding/decoding, lossless conversion of JPEG, and support for some exotic formats that AVIF does not support. In other words, we need both.
peterangular 3y ago
Another important thing to mention is that WebP, HEIC, and AVIF are all based on video codecs whereas JPEG XL is a traditional image codec. I find this article describes the differences and pluses/minuses incredibly well: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... TLDR in the article is that both technologies are valid and have a significant use case. I still work plenty with the browser and would _absolutely_ use JPEG XL as a replacement for WebP images, traditional JPEGs, and PNGs if I could. It's a shame Google/Chrome is not supporting the tech. It would be a major improvement in the landscape.
spiralpolitik 3y ago
See the link below for benefits and examples: https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_im... The big one is that you can transcode existing JPEG files effectively and reversibly to JPEG XL without any additional loss. So you can get the benefits of the new format without having to re-sample your existing JPEG images.
fold3 3y ago
webP and avif are basically video codecs that can eventually render a frame as a static image and are good at masking low res artifacts. On the other hand, JPEG XL is for static images only and is way better at rendering fine details. It has a bunch of specific features and optimizations. if you want to know more in details, check this post: https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl

jacksgt 3y ago

I would really like to start converting some of my personal media and websites to use JPEG XL, but the momentum doesn't seem there yet - despite clear technical and practical benefits.

aimor 3y ago
I just went ahead and did it, then included fallbacks to supported formats. What I really want is a standard way to let the browser request lossy or lossless images.

ranting-moth 3y ago

Does anyone have a quick summary what this is all about?

devmor 3y ago
JPEG XL is a file format for large raster images that provides a better compression ratio and higher quality than JPEG. Google owns the license to another proprietary image format for large raster images (WEBP). Google used to support JPEG XL in chromium, but dropped support for it. Many people believe this is specifically to manipulate a market advantage for WEBP.
- chrismorgan 3y ago
  > Google used to support JPEG XL in chromium No, they had an experimental implementation, behind a flag. No stable version of Chromium has ever supported JPEG XL. (The claimed reasons for the removal: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805.... This is the last comment by an @chromium.org account.)
  - altairprime 3y ago
    Those reasons, lifted from the wasteland of the bug linked: - 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
- jonatron 3y ago
  What about WebP is proprietary?
  - spiralpolitik 3y ago
    Only Google can make changes to the WebP specification and can do so unilaterally. The JPEG-XL specification is governed by a recognized standards body (ISO).

jamesfmilne 3y ago

Posting obnoxious, demanding messages on the Chromium bug tracker is not the way to win friends & influence people. It's just an image file format for Pete's sake.

paulddraper 3y ago
[flagged]
pikelet 3y ago
Way to be reductive. It's a very thorough summary of the situation, hardly low effort or obnoxious. If you think it's 'just an image format' then you aren't the target audience. Move on. This was a very controversial decision that could have long lasting effects on the industry. See the rest of the linked thread if you are actually interested in why that is. If not, why comment?
Fauntleroy 3y ago
If we followed this line of thinking, we'd all still be using BMP and GIF for everything.
- pornel 3y ago
  Well, Chrome couldn't be convinced to support for MP4 in <img> like Safari does.
peppermint_gum 3y ago
> Posting obnoxious, demanding messages on the Chromium bug tracker is not the way to win friends & influence people It's true, although it should be noted that this is the result of the Chromium team acting in bad faith and gaslighting the users. These are the stated reasons for the removal of JPEG XL: https://bugs.chromium.org/p/chromium/issues/detail?id=1178058#c84 https://bugs.chromium.org/p/chromium/issues/detail?id=117805... "Experimental flags and code should not remain indefinitely" Why wasn't AVIF hidden behind an experimental flag? "There is not enough interest from the entire ecosystem to continue experimenting with JPEG XL" This is gaslighting. The representatives of companies such as Adobe, Facebook, Intel, The Guardian or Shopify have voiced their support for the format. Not to mention the countless individuals. I don't recall AVIF getting anywhere near this level of interest. "The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default" Really? https://cloudinary.com/blog/the-case-for-jpeg-xl https://cloudinary.com/blog/the-case-for-jpeg-xl BTW, this article doesn't even mention all of the JPEG XL's advantages. For instance, it doesn't mention the high resolution support. AVIF images are limited to 65536x65536, but images larger than 8192x4352 must be tiled, which results in border artifacts between the tiles. JPEG XL, on the other hand, has no problems with images up to 1073741823x1073741823.

we_never_see_it 3y ago

[flagged]

webmobdev 3y ago
In that case Vivaldi browser is a much better Chrome clone as you can avoid both Google and Microsoft malware.
- brucethemoose2 3y ago
  Thorium is the Chrome fork de jure for me. It strips most of the bad and its and fast. I like Vivaldi, but I dont really need all its extra stuff.
vlovich123 3y ago
Huh? This is the same engine no? Is Edge implementing it even though Blink isn't?
bornfreddy 3y ago
Interesting, do you prefer Microsoft malware to Google malware?
deleted 3y ago
[deleted]

baggy_trough 3y ago

Now what would really be great is if Microsoft Edge could support AVIF. That's the last holdout.

webmobdev 3y ago
AVIF is more compute intensive than HEVC.
Timon3 3y ago
It seems it just got implemented behind a CLI flag: https://winaero.com/avif-support-is-now-available-in-microsoft-edge/ https://winaero.com/avif-support-is-now-available-in-microso... So, hopefully not too much longer!
- baggy_trough 3y ago
  Unfortunately I think there's some patent/legal headache involved.
  - Timon3 3y ago
    That's rather unlikely, otherwise they wouldn't already ship it behind a feature flag.
    - baggy_trough 3y ago
      Apparently there isn't really anything behind that flag. See: https://stackoverflow.com/questions/75459594/why-doesnt-edge-support-avif-images https://stackoverflow.com/questions/75459594/why-doesnt-edge...
      - Timon3 3y ago
        If you're referring to the first answer, the last update is almost a month older than the article I posted. Are you referring to something else? If not, are you suggesting the article I posted is lying? There are a bunch of articles on this topic/flag, which were posted on the same day as the link I wrote earlier (17th of April).

brucethemoose2 3y ago

As said before, the commiter of the JXL removal is an AOM contributor, and the manager who approved it has given presentations on AV1. This is politics, not a technical discussion.

shadowgovt 3y ago
Half of tech is politics. Why else are all the measurements around here in feet instead of meters?
- paulddraper 3y ago
  Does "here" mean HN? YC is an US company, and its network is US-based.
orra 3y ago
That's frustrating. Having a royalty free, high quality, video codec is great. But it shouldn't prevent us having a significantly better still image format.
jonas-w 3y ago
What is AOM in this context?
- lonjil 3y ago
  Alliance of Open Media, the multi-company consortium that develops and promotes AV1 and AVIF.
pornel 3y ago
There are very few people working with image codecs, and you will not find a codec "virgin" among people responsible for these subsystems. One of the main JPEG XL contributors is a WebP contributor and a Google employee. If JPEG XL got shipped first you could make the opposite conspiracy from that!
- brucethemoose2 3y ago

shadowgovt 3y ago

It's an open source browser, right? If it's important, someone should just implement support for it.

zarlss43 3y ago
Chromium is an open-source browser, not Chrome.
- shadowgovt 3y ago
  So implement it in chromium, and the conversation can move to "why is Chrome not adopting this feature that is already compatible with the codebase?"
  - lonjil 3y ago
    Chrome and Chromium are the same dev team. Open source doesn't mean that they'll accept any pull request. It was implemented in Chromium, as an experimental feature, and then removed.
    - lopkeny12ko 3y ago
      Have you never heard of forking?
      - spider-mario 3y ago
        Like this? https://github.com/Alex313031/thorium-libjxl/tree/67097321232ff849b8877c6329688f06fad69d35 https://github.com/Alex313031/thorium-libjxl/tree/6709732123...
        shadowgovt 3y ago
        Excellent. This is a good approach. The most hilarious way to deal with Google's lack of leadership would be to build out a browser that rivals their offering on top of their own core.

lonjil 3y ago

I don't see any comments from any Chrome developer since the Safari news, so the headline here on HN doesn't make a whole lot of sense.

altairprime 3y ago
macOS Sonoma will support JPEG XL, so presumably all Apple platforms will, come September or so. OP is blogging by title edit, less than 24 hours later, about how Chrome hasn’t reversed their decision.
- jdiff 3y ago
  Saying they haven't reversed their decision sounds like they affirmed their previous decision in spite of changing circumstances. Nobody popping up and saying something is more "nothing's stirred publicly on the Chrome front" than "Chrome still hasn't changed their opinion."
  - altairprime 3y ago
    I agree that it’s a misleading headline, but sadly there’s nothing more I can do to remedy that, other than clarify for others in a comment (and flag the post).

modeless 3y ago

Give it a minute. The news that Safari would add JPEG XL just dropped yesterday. Given that big change the decision may be reconsidered, but not in one day.

taylorbuley 3y ago
Patience is a well-measured response.

mike_hearn 3y ago

[flagged]

shkkmo 3y ago
Egregious off topic self promotion going on here.
- altairprime 3y ago
  Please email the mods about perceived guidelines violations, using the footer contact link.
- mike_hearn 3y ago
  Well, sorry you think that. I wrote the product exactly because I was tired of hitting browser limitations in previous projects, but the alternatives were too difficult and so people would sometimes just give up rather than tackle the deployment problem. This thread is about people upset about browser limitations, something that's trivial to fix when not writing web apps - just add libjxl into your app and use it. So that's why it seems relevant to me. Yes, it doesn't help if what you're doing has to be a web page, but often there's a choice.

eimrine 3y ago

Why browsers can not have features as binaries on OS? For example, I can drop Ogg Vorbis support from my Debian but one is a nightmare - if Debian's devs would manage to dictate me what codecs I can use and what I can not.

modeless 3y ago
Linux distributions are free to distribute their own builds of Chromium with whatever features they want. It's just that distributing a fork of Chromium, even with minimal changes, is a full time job for several people at least, due to the fast pace of updates and the security critical nature of browsers. And people prefer Chrome anyway due to the features that rely on Google servers like sync or translation.
nimish 3y ago
We had binary plugin support before. It didn't work out well.

qwertfisch 3y ago

The referenced comment does not even take into account that also the lossless compression is more efficient than PNG. This and the easy handling and efficient storing of (short) animations could in total combine the three major image formats: JPG, PNG and GIF. Even when gifs are now mostly replaced by webm and HTML5 viideo tag, the unification of image formats for both orthogonal uses (natural images vs. technical or generated images) is a big advantage.

account42 3y ago
I'm still disappointed that you can't use (silent) videos in <img> tags or CSS properties where you can use images. Animated webp is so much less efficient than webm its not even funny. There are many places where you can already embed images (including GIF and animated WEBP) but video is not supported or has other restrictions.
- ed25519FUUU 3y ago
  But you have to acknowledge the psychological expectations are not the same with the two formats. A GIF? Looping video, maybe 3 seconds long. A silent video? Hours and hours.
  - lonjil 3y ago
    But you can already do that. AVIF animations are regular AV1 videos. There is zero end user visible difference between what the above user is proposing and what AVIF does. Allowing webm in img tags would be identical.

sitkack 3y ago

Polyfill using Wasm. I see almost no downsides. you can even use the original code.

themerone 3y ago
The wasm implementation is too slow for mainstream adoption. It also has to decode the image to a format supported by Chrome, which means you lose a lot HDR abilities. JpegXL can go to 32bit, but the supported formats max out at 12.
- sitkack 3y ago
  Between WebGPU and WasmSIMD, I think much could be done to make it performant enough.

rcme 3y ago

Is there any benefit to JPEG XL (over other formats) other than old JPEGs can be losslessly re-encoded?

pikelet 3y ago
Doesn't the linked comment answer that exact question?
quikoa 3y ago
Compared to JPEG: JPEG has been hitting its limits for an extended period: JPEG can only do 8-bit color depth, no HDR. JPEG can only do lossy, with no lossless support JPEG lacks good compression for graphics images JPEG cannot do alpha transparency JPEG cannot do animations JPEG does not support multiple layers JPEG compression efficiency is 30 years old and not as good JPEG comes with annoying compression artifacts we all love Banding, Noise, Blockiness, and more banding. For much more, here is a comprehensive overview: https://jpegxl.io/articles/faq/ https://jpegxl.io/articles/faq/
- rcme 3y ago
  I didn't mean to compare JPEG XL to JPEG. I'm more curious if there is any advantage to JPEG XL over WebP or AV1.
  - jonsneyers 3y ago
    Here's a summary of the main points: https://jpegxl.info/why-jxl.html https://jpegxl.info/why-jxl.html Basically lossy WebP and AVIF are video codecs, which are designed for the kind of quality you want when you can only see an image for 40 milliseconds or less. For still images, higher fidelity is usually desired but the video codecs tend to struggle to even keep up with the old JPEG at those operating points. Similarly, video codecs are not designed for progressive decoding (rendering previews of a frame based on partial data), because that's a feature that doesn't make much sense for video. For still images on the web, progressive decoding is considered a desirable feature though to improve the user experience.

lopkeny12ko 3y ago

This terse comment from the bug is an accurate summary of how projects work at Google, whose side effect was JPEG XL's removal: > The code has been removed from Chromium (comment #281), I'm closing this bug for now. If leadership revisits the decision [1] it can be reopened. There you have it--the people making decisions are out-of-touch, likely-non-technical managers, not engineers. Engineers are the ones writing the code and shipping features. Why not empower them to make these decisions?

ed25519FUUU 3y ago
Non-technical leadership is no longer a byword to me. I’ve sat through too many bikeshed meetings. Maybe JPEG-XL is more important to technical users than chromes actual users?
- jdiff 3y ago
  Without a doubt. If you're lucky, they might know the difference between a JPEG and a PNG. This is a technical discussion at its core, you wouldn't expect Chrome's actual users to know about Flexbox or ES6, either. There's little you can't do without these, but things are transparently better with them anyway.
- pikelet 3y ago
  Just because they don't understand something or don't know about it doesn't mean it doesn't benefit them.

dang 3y ago

Related: JPEG XL support has officially been removed from Chromium - https://news.ycombinator.com/item?id=33933208 https://news.ycombinator.com/item?id=33933208 - Dec 2022 (378 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) More at https://news.ycombinator.com/item?id=33935571 https://news.ycombinator.com/item?id=33935571

skrowl 3y ago

[dead]

sandstrom 3y ago

Here is a recent (today) blog post from the Safari team, spelling out JXL support: https://www.webkit.org/blog/14205/news-from-wwdc23-webkit-features-in-safari-17-beta/ https://www.webkit.org/blog/14205/news-from-wwdc23-webkit-fe...

deleted 3y ago

[deleted]

gandalfff 3y ago

"It's open source, just fork it."

cendyne 3y ago

Looking forward to when edge services like Cloudflare, Cloudimage, imgix, etc. support JXL too. AVIF has such a harsh encoding time. It is also a bit too bulky in wasm on the edge to encode yourself too.

pornel 3y ago
So far the blocker has been lack of alternative implementations of JPEG XL. A big complex format implemented in young C++ codebase is scary to deploy. Additionally, everyone using exact same code creates a risk of files being "bug-compatible" with that code, rather than conforming to the spec. There are now multiple alternative implementations in the works, including in safer languages, so hopefully it will be easier to deploy in the near future.

bawolff 3y ago

I don't know why HN is so obsessed with this particular image format. Adding image formats on the web has a really high maintainability cost and there is a fairly reasonable argument that it wasn't worth it in this case.

jeroenhd 3y ago
It's better WebP, without patents and license fees (so unlike HEIC). There are also advantages to encode and decode speeds compared to other formats. It's a superior format compared to most alternatives in many situations. Adding the format and maintaining it requires some work, but the potential for load speeds and data savings is huge. It's also finally a somewhat efficient format for bitmap animations after all these years of GIF and APNG. I've also run into the 16k size limit while converting some PNGs to WebP myself, to JPEG XL would be a nice way to losslessly compress those images more efficiently as well. That said, so far WebP is serving me fine in most cases, I don't really care if it takes two weeks or two years for JPEG XL to make it into the mainstream.
- pornel 3y ago
  It doesn't matter that it's better than WebP, because that isn't the alternative. The alternative that browsers have shipped is AVIF. JPEG XL's advantage over AVIF is less significant. It's not a clear win, but diminishing returns and nice-to-have features vs AVIF's wider deployment and head start in AV1 implementations.
padjo 3y ago
It’s a litmus test for some people of how much google is turning into 90s era Microsoft
- jsnell 3y ago
  The analogy makes no sense, given JPEG XL was primarily created by Google. That's what makes the reaction so strange. If JPEG XL had been enabled by default in Chrome instead of removed, would HN be happy? Or would we be up in arms about how Google is trying to force yet another image format on the browser ecosystem?

jeroenhd 3y ago

For the next few months at least, it looks like JPEG XL is just going to be one of those formats for Apple users, like HEIC. With people complaining about programs not supporting WEBP all the time, JPEG XL isn't going to gain much popularity in the mainstream either. At least people supporting Safari will be able to make use of the format for faster load times soon; the <picture> element makes the transition quite painless after all.

lonjil 3y ago
An interesting difference with the WebP situation is that any app that uses Apple's codec framework on iOS/iPadOS, which is almost all apps that deal with images, will support JXL automatically. Actually, I just downloaded a JXL via Safari, and after confirming that it was still a JXL, I tried using it in a context where JXL isn't supported, and it automatically turned into a JPEG.

IvyMike 3y ago

Half joking: in the world where Google added JPEG XL using the normal process, the reaction would vary from mild disinterest to outright disapproval. "Google is forcing yet another image format down our throats!" But by adding and then removing the feature, they've made it a competition. Now JPEG XL is building grass-roots support, and if/when Google relents and adds JPEG XL back, the feature will have much higher support than the boring way.

pornel 3y ago

I'm curious whether Apple will eventually move away from HEIC for their camera roll and other internal uses. Now that would be an incredible win for royalty-free codecs. As for browsers, this looks like the competition that's needed to convince Chrome. If it gains adoption and gives Safari a performance/quality edge that users notice, Chrome will have to follow. For browser vendors, all web-exposed code is a maintenance cost, security risk, and compatibility risk, so they generally don't add stuff just because it's nice. But they do add stuff to beat their competitors.

jonsneyers 3y ago
We may have to wait for hw jxl encoders for that. Which is likely to happen, but it will definitely take time. Meanwhile there will be software options for authoring, e.g. Adobe Camera Raw. For the web, the trade-offs between encode speed, compression , and fidelity consistency are quite clearly in jxl's favor. Avif still has the advantage in terms of support of course, but deploying jxl just for Safari already makes sense for many use cases. When Chrome follows, it will become a no-brainer.