To the frustration of many developers and end-users, back in 2022 Google deprecated JPEG-XL support in Chrome/Chromium and proceeded to remove the support. That decision was widely slammed and ultimately Google said they may end up reconsidering it. In November there was renewed activity and interest in restoring JPEG-XL within Google's image web browser and as of yesterday the code was merged.

all 11 comments

sorted by: hot top controversial new old
[–] 4 points 9 months ago* (8 children)

What is JPEG-XL and why wouldn't one continue to use PNG instead?

Edit: Sounds like it shrinks file sizes a bit extra?

  • source
  • hideshow 8 child comments
  • [–] [S] 10 points 9 months ago* (last edited 9 months ago) (6 children)

    Up to 46% compared to PNG is more than a bit extra. It's also supports both loseless and lossy compression and supports backwards compatability between legacy JPEG. Among many other modern features.

    And PNG is so old that it lacks basic modern features like HDR support.

    The only competition to JPEG-XL is AVIF. Though both likely to coexist as they have different strenghts.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 3 points 9 months ago (2 children)

    And PNG is so old that it lacks basic modern features like HDR support.

    You can actually store HDR images in PNG (Even BMP, but that's cursed), you just need to include the right metadata, and have a client that supports said metadata. Without it, the image looks a bit funky, but still legible.

    Now WebP on the other hand, is incapable of storing HDR images. The lossless mode is limited to 8bpc images, and Google killed off WebP2 in favour of AVIF (Which doesn't have a dedicated lossless mode), which could have fixed those limitations.

  • source
  • parent
  • hideshow 2 child comments
  • [–] [S] 4 points 9 months ago (1 child)

    Technically true, but the standard was only recently updated to reflect that. https://www.w3.org/TR/png-3/

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 9 months ago*

    Yep, that's the proper way (Since you can specify the metadata correctly)

    But there's also an older rather cursed way, a specially crafted colour profile that a compatible viewer would see and then act as if the image data was in a specific HDR format. It worked too, a few viewers support it, but it's a pretty terrible way to handle it so it's been deprecated.

    I actually used it as part of a pipeline to turn Xbox HDR screenshots into HDR JXL images, the JXL encoder at the time would recognise it and apply the right metadata itself.

  • source
  • parent
  • [+] -1 points 9 months ago* (last edited 2 weeks ago) (3 children)
  • [–] [S] 4 points 9 months ago (2 children)

    Moreover, JPEG XL includes several features that help transition from the legacy JPEG coding format. Existing JPEG files can be losslessly transcoded to JPEG XL files, significantly reducing their size (Fig. 1). These can be reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications. Both transcoding and reconstruction are computationally efficient. Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients. This provides a smooth transition path from legacy JPEG platforms to the modern JPEG XL.

    https://ds.jpeg.org/whitepapers/jpeg-xl-whitepaper.pdf

  • source
  • parent
  • hideshow 2 child comments
  • [+] 0 points 9 months ago* (last edited 3 weeks ago) (2 children)
  • [–] [S] 2 points 9 months ago (1 child)

    Creating two different copies of a file isn’t backward compatibility.

    Well if you bothered to actually read you would know that is precisely not the case here. The JPEG XL file can be reconstructed to the exact same JPEG file, ensuring backward compatibility with legacy applications.

    Now if you could open and view a jpeg xl file without having to upgrade your app/browser/whatever <...>

    That would be forward compatability.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 3 points 9 months ago

    Þird party here.

    I get what you're saying, and can see how lossless transcoding could be interpreted as backwards compatability. Backwards compatability would mean any JPEG image is also a valid JPEG XL image, and þat's not þe case. You may as well claim PNG is backwards compatible wiþ GIF, because you can losslessly transcoded between þe two formats.

    Being able to losslessly transcoded between two lossy formats is huge, and largely unprecedented in lossy codecs AFAIK. Not even JPEG can losslessly transcoded between itself, and it is backwards compatible wiþ itself.

  • source
  • parent
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • 18 comments in c/technology@lemmy.world view that post
    [–] 12 points 9 months ago

    It is pretty great for shrinking the filesize of my photos. It's a part of the PDF standard now. It'll get great support across the board eventually. Still pretty early in adoption

  • source
  • [–] 45 points 9 months ago (11 children)

    Google tried to sabotage it in favour of its own WebP standard.

    Nobody gives a shit about WebP.

  • source
  • hideshow 11 child comments
  • [–] 3 points 9 months ago

    Their dumb counter argument was AVIF, for the same reason as webp which is reduced total size since they're a massive cloud provider and want to penny pinch costs wherever possible.

    JPEG-XL also has a progressive loading algorithm that increases the quality as you download instead of classic vertical scan loading, which is sick but I don't think any browser actually bothered to implement it yet after the Google hit job.

    Hopefully will see it in action soon.

  • source
  • parent
  • [+] 10 points 9 months ago* (last edited 2 weeks ago) (10 children)
  • [–] 41 points 9 months ago (9 children)

    They don't have to. It's backwards compatible. You can ignore it and we can keep on happily using it.

    Fuck Google, fuck WebP.

  • source
  • parent
  • hideshow 9 child comments
  • [–] 8 points 9 months ago (6 children)

    How is JPEG XL backwards compatible?

  • source
  • parent
  • hideshow 6 child comments
  • [–] 35 points 9 months ago (5 children)

    It's "compatible" in that it can represent old JPEG/JFIF data more efficiently and in less space, and the transformation to JPEG XL and back to JPEG/JFIF is lossless (in that you don't lose any /more/ quality, you can get the same bits back out) and quick enough to be doable on-demand. You could, for example, re-encode all your old photos on your CDN as JPEG XL without loss of quality but save a bunch of disc space and bandwidth when serving to modern browsers, and translate dynamically back to the old format for older browers, all with no loss of quality.

  • source
  • parent
  • hideshow 5 child comments
  • [+] -19 points 9 months ago (4 children)

    So what you're saying is: both formats can encode image data

  • source
  • parent
  • hideshow 4 child comments
  • [+] 8 points 9 months ago* (last edited 3 weeks ago) (3 children)
  • [–] 3 points 9 months ago

    The difference (claimed by the comment above) is in the words

    without loss of quality

    So you can convert back and forth without the photo copy of a photo copy problem.

    And you don't have to store the second copy of the file except for caching of frequently fetched files which I'm sure will just be an nginx rule.

  • source
  • parent
  • [–] 2 points 9 months ago

    What they’re saying is that a web server can create a traditional jpeg file from a jpeg xl to send to a client as needed.

    Other way around, you can convert a "web safe" JPEG file into a JXL one (and back again), but you can't turn any random JXL file into a JPEG file.

    But yeah, something like Lemmy could recompress uploaded JPEG images as JXL on the server, serving them at JXL to updated clients, and converting back to JPEG as needed, saving server storage and bandwidth with no quality loss.

  • source
  • parent
  • [–] 2 points 9 months ago

    No, I'm saying that JPEG XL can perfectly represent old JPEG/JFIF data, so on the server side you can store all your image data once and more efficiently, and still support old clients without any lossy cascade or the CPU load of having to re-encode. That is what is meant about it offering backwards compatibility.

  • source
  • parent
  • load more comments (-1 replies)
  • load more comments (-1 replies)
  • load more comments (-1 replies)
    [–] 8 points 9 months ago

    Good, Chrome has allowed them to be in a position to dictate the future of internet standards for too long. Fuck em

  • source
  • [–] 8 points 9 months ago

    Fuck Chrome.

  • source
  • [–] 4 points 9 months ago

    This is good but no matter what I don't think Google should have such a monopoly over the web.

  • source
  • [–] 1 point 9 months ago (1 child)

    Can someone ELI5? I read the article. 🙃

  • source
  • hideshow 1 child comment