Most active commenters
  • illiac786(5)

←back to thread

A new PNG spec

(www.programmax.net)
614 points bluedel | 28 comments | 24 Jun 25 13:01 UTC | HN request time: 1.571s | source | bottom
1. qwertfisch ◴[25 Jun 25 12:22 UTC] No.44376468[source]▶
Seems a bit too late? And also, JPEG XL supports all the features and uses already advanced compression (finite-state entropy, like ZStandard). It offers lossy and lossless compression, animated pictures, HDR, EXIF etc.

There is just no need for a PNG update, just adopt JPEG XL.

replies(5): >>44376756 #>>44377176 #>>44378892 #>>44379025 #>>44384951 #
2. Aachen ◴[25 Jun 25 12:55 UTC] No.44376756[source]▶
> advanced compression (finite-state entropy, like ZStandard)

I've not tried it on images, but wouldn't zstandard be exceedingly bad at gradients? It completely fails to compress numbers that change at a fixed rate

Bzip2 does that fine, not sure why https://chaos.social/@luc/114531687791022934 The two variables (inner and outer loop) could be two color channels that change at different rates. Real-world data will never be a clean i++ like it is here, but more noise surely isn't going to help the algorithm compared to this clean example

replies(3): >>44376987 #>>44377519 #>>44380331 #
3. Retr0id ◴[25 Jun 25 13:17 UTC] No.44376987[source]▶
zlib/deflate already has the same issue. It is mitigated somewhat by PNG row filters.
4. illiac786 ◴[25 Jun 25 13:35 UTC] No.44377176[source]▶
I really don’t get it. Why, but why? It’s already confusing as hell, why create yet another standard (variant) with no unique selling point?
replies(1): >>44378143 #
5. adgjlsfhk1 ◴[25 Jun 25 14:06 UTC] No.44377519[source]▶
the FSE layer isn't responsible for finding these sorts of patterns in an image codec. The domain modeling turns that sort of pattern into repeated data and then the FSE goes to town on the output.
6. pmarreck ◴[25 Jun 25 15:00 UTC] No.44378143[source]▶
JPEG XL is not a "variant", it is a completely new algorithm that is also fully backwards-compatible with every single JPEG already out there, of which there are probably billions at this point.

It also has pretty much every feature desired in an image standard. It is future-proofed.

You can losslessly re-compress a JPEG into a JPEG-XL file and gain space.

It is a worthy successor (while also being vastly superior to) JPEG.

replies(3): >>44378163 #>>44378359 #>>44378429 #
7. illiac786 ◴[25 Jun 25 15:02 UTC] No.44378163{3}[source]▶
I was referring to the new PNG, not to JPEG XL.
replies(1): >>44378454 #
8. BobaFloutist ◴[25 Jun 25 15:22 UTC] No.44378359{3}[source]▶
Is there any risk that if I open a JPEG-XL in something that knows what a JPEG is but not what a JPEG-XL is and then save it, it'll get lossy compressed? Backwards compatibility is awesome, but I know that if I save/upload/share/copy a PNG, it shouldn't change without explicit edits, right?
replies(1): >>44378533 #
9. dylan604 ◴[25 Jun 25 15:28 UTC] No.44378429{3}[source]▶
> You can losslessly re-compress a JPEG into a JPEG-XL file and gain space.

Is that gained space enough to account for the fact you now have 2 files? Sure, you can delete the original jpg on the local system, but are you going to purge your entire set of backups?

replies(2): >>44378510 #>>44385844 #
10. sdenton4 ◴[25 Jun 25 15:30 UTC] No.44378454{4}[source]▶
Looking at TFA, it's placing in the spec a few things that are already widely stacked onto the format (such as animation). This is a very sensible update, and backwards compatible with existing PNG.
replies(1): >>44378545 #
11. illiac786 ◴[25 Jun 25 15:35 UTC] No.44378510{4}[source]▶
if you do not want to delete the original jpeg, there is no point in converting them to jpeg xl I would say.

Unless serving jxl and saving bandwidth, while increasing your total storage, is worth it to you.

12. illiac786 ◴[25 Jun 25 15:38 UTC] No.44378533{4}[source]▶
a sw that does not know what jpeg xl is, will not be able to open jxl files. How would it?

Not sure what the previous poster meant with “backward compatible” here. jxl is a different format. It can include every information a jpeg includes, which then maybe qualifies as “backward compatible” but it still is a different format.

replies(2): >>44379111 #>>44379945 #
13. illiac786 ◴[25 Jun 25 15:39 UTC] No.44378545{5}[source]▶
Not sure expanding PNG capabilities is sensible, looking at the overall landscape of image formats.
replies(1): >>44381140 #
14. bmn__ ◴[25 Jun 25 16:09 UTC] No.44378892[source]▶
> just

https://caniuse.com/jpegxl

No one can afford to "just". Five years later and it's only one browser! Crazy.

Browser vendors must deliver, only then it's okay to admonish an end user or Web developer to adopt the format.

replies(1): >>44381279 #
15. mikae1 ◴[25 Jun 25 16:21 UTC] No.44379025[source]▶
> There is just no need for a PNG update, just adopt JPEG XL.

Tell that to Google. They gave up on XL in Chrome[1] and essentially killed its adoption.

[1] https://issues.chromium.org/issues/40168998#comment85

replies(2): >>44382114 #>>44384817 #
16. liuliu ◴[25 Jun 25 16:28 UTC] No.44379111{5}[source]▶
JPEG XL has the mode that in layman's word, allow bit-by-bit round-trip with JPEG.

Original JPEG -> JPEG XL -> Recreated JPEG.

Sha256(Original JPEG) == Sha256(Recreated JPEG).

That's what people meant by "backward compatible".

replies(1): >>44379451 #
17. colejohnson66 ◴[25 Jun 25 16:56 UTC] No.44379451{6}[source]▶
That’s not “backwards compatible”, but “round tripable” or “lossless reencode”
18. BobaFloutist ◴[25 Jun 25 17:44 UTC] No.44379945{5}[source]▶
Ah, got it. I assumed it was a losselessly compressed JPEG with metadata telling modern software not to compress differently but that older software would open as a normal JPEG, but I guess they meant something else with "backward compatible".
19. wongarsu ◴[25 Jun 25 18:19 UTC] No.44380331[source]▶
PNG's basic idea is to store the difference between the current pixel and the pixel above it, left of it or to the top-left (chosen once per row), then apply standard deflate compression to that. The first step basically turns gradients into repeating patterns of small numbers, which compress great. You can get decent improvements by just switching deflate for zstd
20. dveditz_ ◴[25 Jun 25 19:39 UTC] No.44381140{6}[source]▶
The capabilities are already expanded in most common implementations. This update is largely blessing those features as officially "standard".
21. Dylan16807 ◴[25 Jun 25 19:58 UTC] No.44381279[source]▶
Adopt it anyway. Add a decoder. Don't let google bully you out of such a good format.
22. rhet0rica ◴[25 Jun 25 21:48 UTC] No.44382114[source]▶
From reading that, "gave up" seems to mean "deliberately killed it so their own WebP2 wouldn't have competition." Behold the monopoly at the apex of its power.
replies(2): >>44385856 #>>44389120 #
23. pezezin ◴[26 Jun 25 06:46 UTC] No.44384817[source]▶
On the other hand, more and more software are adding support for JPEG XL. Photoshop just added it in the latest patch (https://helpx.adobe.com/photoshop/using/whats-new/2025-6.htm...), Apple has included it in the iPhone 16, it is easily available on Windows (https://apps.microsoft.com/detail/9mzprth5c0tb?hl=en-US&gl=U...), most major Linux distros already support it...

It is only a matter of time until the Chrome team has to reverse their decision.

24. Dwedit ◴[26 Jun 25 07:07 UTC] No.44384951[source]▶
If JPEG-XL decompressed faster, I'd use it more. For now, I'm sticking with WEBP for lossless, and AVIF for lossy. AVIF's CDEF filter (directional deringing) works wonders, and it's too bad that JPEG-XL lacks such a filter.

JPEG-XL's lossy modular mode is a very unique feature which needs a lot more exposure than it has. It is well-suited to non-photographic drawings or images that aren't continuous, and have never touched any JPEG-like codecs. It has different kinds of artifacts than what you typically see in a DCT image codec. Rather than ringing, you get slight pixellation.

25. account42 ◴[26 Jun 25 10:02 UTC] No.44385844{4}[source]▶
Yes the whole point of lossless re-compression is that you do not need to keep the original JPEGs. Of course you don't need to "purge" backups, just let them rotate out normally.

Also backup storage is usually cheaper than something that needs to have fast access speeds.

replies(1): >>44388781 #
26. account42 ◴[26 Jun 25 10:05 UTC] No.44385856{3}[source]▶
The really weird part is that both webp and jxl developments were largely funded by Google so its not Google killing a competitors format over their own but someone in one part of Google killing the format someone elsewhere in Google developed over their pet favorite.
27. dylan604 ◴[26 Jun 25 16:13 UTC] No.44388781{5}[source]▶
For people that shoot digital cameras saving as JPEG, it will a very cocky suggestion to tell them to toss out their camera original files!

You'll know JPEG-XL if real when camera manufactures allow for XL acquisition instead of legacy JPEG only.

28. spauldo ◴[26 Jun 25 16:53 UTC] No.44389120{3}[source]▶
PNG went through that when Microsoft kept throwing incomplete and buggy support for it in IE. Hopefully something will come along to buck Chrome's monopoly and JPEG-XL will have its chance.