7 ms·

It's not just Google, Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains either: https://github.com/mozilla/standards

• jnd-cz 11mo ago
  Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing?
  • arccy 11mo ago
    if you actually read your parent comment: "typical web image quality"
    • ansgri 11mo ago
      Typical web image quality is like it is partly because of lack of support. It’s literally more difficult to show a static HDR photo than a whole video!
      • zozbot234 11mo ago
        PNG supports HDR with up to 16 bits per channel, see https://www.w3.org/TR/png-3/ https://www.w3.org/TR/png-3/ and the cICP, mDCV and cLLI chunks.
        • lonjil 11mo ago
          With incredibly bad compression ratios.
      • mort96 11mo ago
        HDR should not be "typical web" anything. It's insane that websites are allowed to override my system brightness setting through HDR media. There's so much stuff out there that literally hurts my eyes if I've set my brightness such that pure white (SDR FFFFFF) is a comfortable light level. I want JXL in web browsers, but without HDR support.
        • magicalhippo 11mo ago
          There's nothing stopping browsers from tone mapping[1] those HDR images using your tone mapping preference. [1]: https://en.wikipedia.org/wiki/Tone_mapping https://en.wikipedia.org/wiki/Tone_mapping
          • mort96 11mo ago
            What does that achieve? Isn't it simpler to just not support HDR than to support HDR but tone map away the HDR effect? Anyway, which web browsers have a setting to tone map HDR images such that they look like SDR images? (And why should "don't physically hurt my eyes" be an opt-in setting anyway instead of just the default?)
            • spider-mario 11mo ago
              How about a user stylesheet that uses https://www.w3.org/TR/css-color-hdr-1/#the-dynamic-range-limit-property https://www.w3.org/TR/css-color-hdr-1/#the-dynamic-range-lim... ?
              • mort96 11mo ago
                How about websites just straight up aren't allowed to physically hurt me, by default?
                • spider-mario 11mo ago
                  You asked “which web browsers have a setting to tone map HDR images such that they look like SDR images?”; I answered. Were you not actually looking for a solution?
  • CharlesW 11mo ago
    > Can AVIF display 10 bit HDR with larger color gamut that any modern phone nowadays is capable of capturing? Sure, 12-bit too, with HDR transfer functions (PQ and HLG), wide-gamut primaries (BT.2020, P3, etc.), and high-dynamic-range metadata (ITU/CTA mastering metadata, content light level metadata). JPEG XL matches or exceeds these capabilities on paper, but not in practice. The reality is that the world is going to support the JPEG XL capabilities that Apple supports, and probably not much more.
• kps 11mo ago
  Not everything in the world is passive end-of-the-line presentation. JPEG-XL is the only one that tries to be a general-purpose image format.
  • asadotzler 11mo ago
    If that's the case, let it be a feature of image editing packages that can output formats that are for the web. It's a web standard we're talking about here, not a general-purpose image format, so asking browsers to carry that big code load seems unreasonable when existing formats do most of what we need and want for the web.
    • crote 11mo ago
      People generally expect browsers to display general-purpose image formats. It's why they support formats like classical JPEG, instead of just GIF and PNG. Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular.
      • robertoandred 11mo ago
        > Turns out people really like being able to just drag-and-drop an image from their camera into a website - being forced to re-encode first it isn't exactly popular. That’s a function of the website, not the browser.
        • jyoung8607 11mo ago
          > That’s a function of the website, not the browser. That's hand-waving away quite a lot. The task changes from serving a copy of a file on disk, as every other image format in common use, to needing a transcoding pipeline more akin to sites like YouTube. Technically possible, but lots of extra complexity in return for what gain?
• xeeeeeeeeeeenu 11mo ago
  >avif is just better for typical web image quality, What does "typical web image quality" even mean? I see lots of benchmarks with very low BPPs, like 0.5 or even lower, and that's where video-based image codecs shine. However, I just visited CNN.com and these are the BPPs of the first 10 images my browser loaded: 1.40, 2.29, 1.88, 18.03 (PNG "CNN headlines" logo), 1.19, 2.01, 2.21, 2.32, 1.14, 2.45. I believe people are underestimating the BPP values that are actually used on the web. I'm not saying that low-BPP images don't exist, but clearly it isn't hard to find examples of higher-quality images in the wild.
• deleted 11mo ago
  [deleted]
• lonjil 11mo ago
  I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported. Google on the other hand never expressed any desire to support JXL at all, regardless of the implementation. Only just now after the PDF Association announced that PDF would be using JXL, did they decide to support JXL on the web. > avif is just better for typical web image quality, it produces better looking images and its artifacts aren't as annoying (smoothing instead of blocking and ringing around sharp edges). AVIF is certainly better for the level of quality that Google wants you to use, but in reality, images on the web are much higher quality than that. And JXL is pretty good if you want smoothing, in fact libjxl's defaults have gotten so overly smooth recently that it's considered a problem which they're in the process of fixing.
  • bawolff 11mo ago
    > I don't understand what you're trying to say. Mozilla said over a year ago that they would support JXL as soon as there's a fast memory safe decoder that will be supported. Did they actually say that? All the statements i've seen them have been much more guarded and vauge. More of a, maybe we will think about it if that happens.
    • lonjil 11mo ago
      > If they successfully contribute an implementation that satisfies these properties and meets our normal production requirements, we would ship it. That's what they said a year ago. And a couple of Mozilla devs have been in regular contact with the JXL devs ever since then, helping with the integration. The patches to use jxl-rs with Firefox already exist, and will be merged as soon as a couple of prerequisite issues in Gecko are fixed.
      • magicalist 11mo ago
        Their standards position is still neutral; what switched a year ago was that they said they would be open to shipping an implementation that met their requirements. The tracking bug hasn't been updated[2] The patches you mention are still part of the intent to prototype (behind a flag), similar to the earlier implementation that was removed in Chrome. They're looking at the same signals as Chrome of a format that's actually getting use, has a memory safe implementation, and that will stick around for decades to justify adding it to the web platform, all of which seem more and more positive since 2022. [1] https://mozilla.github.io/standards-positions/#jpegxl https://mozilla.github.io/standards-positions/#jpegxl [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1539075 https://bugzilla.mozilla.org/show_bug.cgi?id=1539075
• wizee 11mo ago
  I disagree about the image quality at typical sizes - I find JPEG-XL is generally similar or better than AVIF at any reasonable compression ratios for web images. See this for example: https://tonisagrista.com/blog/2023/jpegxl-vs-avif/ https://tonisagrista.com/blog/2023/jpegxl-vs-avif/ AVIF only comes out as superior at extreme compression ratios at much lower bit rates than are typically used for web images, and the images generally look like smothered messes at those extreme ratios.
• bananalychee 11mo ago
  Even though AVIF decoding support is fairly widespread by now, it is still not ubiquitous like JPEG/PNG/GIF. So typically services will store or generate the same image in multiple formats including AVIF for bandwidth optimization and JPEG for universal client support. Browser headers help to determine compatibility, but it's still fairly complicated to implement, and users also end up having to deal with different platforms supporting different formats when they are served WebP or AVIF and want to reupload an image somewhere else that does not like those formats. As far as I can tell, JXL solves that issue for most websites since it is backwards-compatible and can be decoded into JPEG when a client does not support JXL. I would happily give up a few percent in compression efficiency to get back to a single all-purpose lossy image format.
  • hirako2000 11mo ago
    Even Google photo does not support avif. It's almost as if Google had an interest in increased storage and bandwidth. Of course they don't but as paying Driver used I'm overcharged for the same thing.
    • lonjil 11mo ago
      Some years ago, the Google Photos team asked the Chrome team to support JXL, so that they could use it for Photos. The request was ignored, of course.
      • hirako2000 11mo ago
        They could have added support themselves to the app as it doesn't use the WebView
        • ascorbic 11mo ago
          Google Photos isn't just the app
          • hirako2000 11mo ago
• deleted 11mo ago
  [deleted]
• magicalhippo 11mo ago
  > Mozilla has no desire to introduce a barely supported massive C++ decoder for marginal gains On a slightly related note, I wanted to have a HDR background image in Windows 11. Should be a breeze in 2025 right? Well, Windows 11 only supports JPEG XR[1] for HDR background images. And my commonly used tools did either not support JPEG XR (Gimp fex) or they did not work correctly (ImageMagick). So I had a look at the JPEG XR reference implementation, which was hosted on Codeplex but has been mirrored on GitHub[2]. And boy, I sure hope that isn't the code that lives in Windows 11... Ok most of the gunk is in the encoder/decoder wrapper code, but still, for something that's supposedly still in active use by Microsoft... Though not even hosting their own copy of the reference implementation is telling enough I suppose. [1]: https://en.wikipedia.org/wiki/JPEG_XR https://en.wikipedia.org/wiki/JPEG_XR [2]: https://github.com/4creators/jxrlib https://github.com/4creators/jxrlib
  • infinet 11mo ago
    Another JPEG XR user is Zeiss. It saves both grayscale and color microscope images with JPEG XR compression in a container format. Zeiss also released a C++ library (libczi) using the reference JPEG XR implementation to read/write these images. Somehow Zeiss is moving away from JPEG XR - its newer version of microscope control software saves with zstd compression by default.
• greenavocado 11mo ago
  "Marginal Gains" Generation Loss – JPEG, WebP, JPEG XL, AVIF : https://www.youtube.com/watch?v=w7UDJUCMTng https://www.youtube.com/watch?v=w7UDJUCMTng
  • edflsafoiewq 11mo ago
    Marginal gains over AVIF. (Also I am highly skeptical of the importance of these generation loss tests.)
    • jlouis 11mo ago
      Very nice in video workflows, where it's common to write out image sequences to disk.
    • greenavocado 11mo ago
      Social media exists
• danielheath 11mo ago
  The killer feature of JXL is that most websites already have a whole bunch of images in JPEG format, and converting those to JXL shrinks them by about 30% without introducing any new artifacts.