I hate that you can’t right click copy images, it always wants to share as a link. Plus some other issues when sharing, but it’s just such a pain in the ass.

2029 Headline: Worlds largest data breach caused by zero day exploit in popular PNG 3.0 renderer

the payload was reportedly embedded in an animated image of the attacker repeatedly flicking his left testicle

Right, and it depends on what "quite off target" means. Are we talking about greens becoming purples? Or dark greens becoming bright greens? If the image is still mostly recognizable, just with poor saturation or contrast or whatever, I think it's acceptable for older software.

JXL can do lossy images (like JPEG) and lossless ones (like PNG), and on average it'll produce smaller file sizes than both (While beating JPEG quality wise). The killer feature is that it can do lossless recompression of existing JPEG files and shave off about 20% of the file size, and it's reversible so you can turn those JXL files back into JPEG images for existing software.

The downside is that it was created by Google Research (among others), but the Chrome team made AVIF instead and decided that's what they'd support and nothing else.

At least Safari supports it.

lossless recompression of existing JPEG
Uh… how does it make a JPEG lossless? Or is it lossless in that it makes a JXL out of a JPEG without affecting the original JPEG quality (i.e. no further loss beyond JPEG's)?

Being able to turn JPEGs into JXLs and JXLs back to JPEGs is cool, though

What's with the AVIF thing? Yet another I am unfamiliar with (all I know about image formats is JPG = worse quality, PNG = better quality, GIF = animated (and something WebP. Idk much about that one either))

Also, in my research, I've found something about the distinction between lossless JXL vs lossy JXL. Seems like you wouldn't be able to tell if the image is lossy or lossless just from it being a JXL

I hate that you can’t right click copy images, it always wants to share as a link. Plus some other issues when sharing, but it’s just such a pain in the ass.

WebP is the same, it's got a lossy mode (VP8) and a lossless mode (Which is more limited than PNG, but beats it where it overlaps). But to make it more complicated the lossless mode also has lossy processing modes, where it alters the image first to achieve smaller output sizes.

And PNG is no different.

People have a long habit of turning JPEG files into PNG files, the file extension won't help you there. They also could have reduced the colour depth or resized it, all lossy operations. All it really tells you is that it can have an alpha channel.

As for AVIF, personally I don't like the format, it feels like an "open media" (But still patented) version of HEIF to oppose Apple. Like WebP it makes the (baseless IMO) assumption that a format designed to encode motion data is better at encoding still data than a format designed to encode still data. It's got all the limitations of a video format (It's got a max resolution, only supports 12bit images, and no progressive decoding), and they left out all the enhancements from WebP (The dedicated lossless mode, "lossless AVIF" files are huge and the last I checked badly supported, so nobody actually used them, and they just called very high quality settings "lossless")

A team inside of Google was working on WebP2 around the same time, that used AV1 but actually added the useful stuff like efficient lossless encoding, it got killed too in favour of AVIF.

Ooh, Alpha channel. Forgot of that. That is a nice one. Love me some alpha channel.

So, what would you say is best? If someone wanted to save an image, which format would you recommend? I usually go with PNG. JPG if I want bad quality on purpose (drag quality slider to minimum for extra compression)

I'm probably gonna be massively downvoted for saying the forbidden word but I asked AI to do a summary with references of the forward and backward compatibility of PNG's new version:

!

Based on recent search results, the new PNG specification (Third Edition) and its reference library (libpng) maintain strong backward compatibility while introducing modern features. Here's a detailed compatibility analysis:

1. Backward Compatibility (Viewing Old PNGs with New Lib)

• Full Support: The new libpng (1.6.49+) and PNG Third Edition fully support legacy PNG files. Existing PNGs (conforming to the 2003/2004 spec) will render correctly without changes .
• Implementation Stability: Libpng's API evolution (e.g., hiding png_struct/png_info internals since 1.5.0) ensures older apps using png_get_*/png_set_* functions remain compatible. Direct struct access, deprecated since 1.4.x, may break in libpng 2.0.x (C99-only) .
• Security Enhancements: Critical vulnerabilities (e.g., CVE-2019-7317 in png_image_free()) were patched in libpng 1.6.37+, making the new lib safer for decoding old files .

️ 2. Forward Compatibility (Viewing New PNGs with Old Lib)

• Basic Support: Older libpng versions (pre-1.6.37) can decode new PNGs if they avoid new features. Core chunks like IHDR or IDAT remain unchanged .
• New Feature Limitations:
  • HDR Imagery: Requires libpng 1.6.45+ and apps supporting the mDCv chunk. Older libs ignore HDR data, falling back to SDR, which may cause color inaccuracies .
  • APNG Animation: Officially standardized in PNG Third Edition. Older libs (e.g., <1.6) treat APNG as static images, showing only the first frame .
  • EXIF Metadata: New eXIf chunks are ignored by legacy decoders, losing metadata like GPS or copyright info .
• Security Risks: Older libs (e.g., ≤1.6.36) contain unpatched vulnerabilities (e.g., CVE-2015-8126). Parsing malicious new PNGs could exploit these flaws .

Compatibility Summary

Scenario	Compatibility	Key Considerations
Old PNG → New Lib	Excellent	Legacy files work flawlessly; security improved.
New PNG → Old Lib	️ Partial	Basic rendering works, but HDR/APNG/EXIF ignored. Security risks in unpatched versions.
New Features	Conditional	Requires updated apps (e.g., Photoshop, browsers) and OS support .

3. Implementation and Industry Adoption

• Broad Support: Major browsers (Chrome, Safari, Firefox), OSs (iOS, macOS), and tools (Photoshop, DaVinci Resolve) already support the new spec .
• Progressive Enhancement: New features like HDR use optional chunks, ensuring graceful degradation in older software .
• Future-Proofing: Work on PNG Fourth Edition (HDR/SDR interoperability) and Fifth Edition (better compression) is underway .

Conclusion

• Upgrade Recommended: New libpng (1.6.49+) ensures security and full compatibility with legacy files.
• Test Workflows: Verify critical tools handle new features (e.g., APNG animation in browsers).
• Fallbacks for Old Systems: For environments stuck with outdated libs, convert new PNGs to legacy format (e.g., strip HDR/APNG) .

For developers: Use png_get_valid(png_ptr, info_ptr, PNG_INFO_mDCv) to check HDR support and provide fallbacks .

!<