JPEGXL info...

[frostknight]

https://devclass.com/2025/11/24/googles ... claration/

Seems google has finally accepted jpegxl as the future.

Moonchild if your watching, I cannot wait to see what you think about this.

I wonder if you will get a kick out of it, since you have had jpegxl for so long built into your web browser.

I imagine mozilla will do the same if google is serious.

[andyprough]

Sounds like Google made another big bet that most of the world would just roll over and adopt whatever technology Google selected, in this case AVIF.

Sometimes they win these big bets, sometimes they lose. It appears they may be on the way to losing this one. But, when you've got a few trillion dollars of other-people's-money to burn (and you can always get more), you can lose a few of those bets and survive just fine.

[jobbautista9]

Still feels weird to see Apple and Adobe of all things being champions of the open web in this front... Really shows how disappointing Mozilla has been in doing the bare minimum of defending and upholding the open web. In retrospect I think they are more to blame than Google (which I must note is a very large corporation with many factions in it, and one of those factions which is the PIK team from Zurich is involved in JPEG-XL's development) for ignoring the patches that completes JPEG-XL support (animations, progressive decoding, color profiles, alpha transparency, HDR) listed in their metabug (they're still not merged to this day btw!), and therefore not letting JPEG-XL support be shipped (because it's currently so incomplete in Nightly). This inaction by Mozilla gave the Chrome team an excuse to ax its own JPEG-XL support leading to this unnecessary situation where we all had to evangelize so hard to prevent another JPEG XR situation (XR was a collaboration between JPEG and Microsoft for an image format replacing JPEG, PNG and GIF; killed by WebP).

[back2themoon]

Meanwhile though, I am noticing a slight increase in websites only offering AVIF with no fallback. Nothing dramatic, but it is annoying. We've survived far worse.

[Moonchild]

If you notice it, report it to the webmasters (politely!). Each voice adding to the choir disfavouring the absolutely awful AVIF format helps!

[SouthernComputerGeek]

The Pale Moon developers made the right call by sticking with JPEG-XL.

[jez9999]

Am I the only one that doesn't really like a format that can be lossy or lossless? When I see a file extension I want to be able to know whether I might lose some image data on export. If I'm exporting to a file I want to know I can't accidentally select the "lossy" mode. With PNG I know that. Kinda wish they'd done a totally different name for the lossless format.

[Falna]

Am I the only one that doesn't really like a format that can be lossy or lossless? When I see a file extension I want to be able to know whether I might lose some image data on export.

I'll add a +1 to that!

[RealityRipple]

.jpgx and .jpgl would have been great for that, too.

[Moonchild]

Am I the only one that doesn't really like a format that can be lossy or lossless? When I see a file extension I want to be able to know whether I might lose some image data on export. If I'm exporting to a file I want to know I can't accidentally select the "lossy" mode. With PNG I know that. Kinda wish they'd done a totally different name for the lossless format.

Funny thing is... png can be lossy (depending on which compressor you use), and jpeg can be lossless... So this is nothing new with jpeg-xl.

[jez9999]

As far as I can tell PNG itself is never lossy. A compressor losing information is doing that before encoding to the PNG format.

[back2themoon]

But if you take a crappy jpg and save it as png, it won't make it lossless. I get what you mean, but you can't rely on the extension alone. You need to know the source.

If you are creating the files, this is just an organization issue.

[jez9999]

It's more of a peace of mind issue. I've never lost a bit of precision saving to PNG and they're so reliably lossless that Spore could use their precise pixel RGB values for steganographic encoding of creature XML data.

[Moonchild]

Regardless of it being possible to have lossless encoding, as pointed out by back2themoon, the file format isn't a guarantee that it is actually lossless compared to the image source.
It is ultimately always up to the person encoding the images to decide the intended use of the image for publication. As a consumer of it, you rely on the publisher making those decisions. Whether the image format chosen is commonly used for either lossless or lossy becomes irrelevant in that context. So, why would a single format filling both roles by default become a negative? Those decisions for "intent" are made for other formats as well, e.g. PDF; you can create a PDF with intent for the web, for printable, for editable content, for archival purposes, etc. each will their own internal structures catering to the specific intent (e.g. bitmaps being lossy or not; fonts embedded completely, or only the glyphs actually used, or converted to vector; markup hints retained or dropped, etc.). That's not considered a problem, so I'm struggling to understand why it would be a considerable problem in the case of jpeg-xl.

[jez9999]

Because it's about what happens in practice. In practice, PNG images are clean and JPEG images have horrible artefacts unless they're photographs. In practice always trumps in theory.

[Gemmaugr]

Only thing bothering me is the name. Is it JPEGXL, JPEG XL, JEPG-XL, JPGXL, JPG XL, or JPG-XL. I've seen it all used.

[Moonchild]

Because it's about what happens in practice. In practice, PNG images are clean and JPEG images have horrible artefacts unless they're photographs. In practice always trumps in theory.

Feel free to show me the horrible artefacts that are "inherent to jpeg".

[jez9999]

Capture.PNG

Dunno about you but the pixel artefacts jump out all over the place to me...

[RealityRipple]

That's not artifacting, that's anti-aliasing.

[jez9999]

Nope, it's artifacting. Almost every pixels is a slightly different colour.