HN Reader

Author here. Hello everyone! Feel free to ask me anything. I'll go ahead and dispel some doubts I already see here:

- It isn't really a "new format". It's an update to the existing format. - It is very backwards compatible. -- Old programs will load new PNGs to the best of their capability. A user will still know "that is a picture of a red apple".

There also seems to be some confusion about how PNGs work internally. Short and sweet: - There are chunks of data. -- Chunks have a name, which says what data it contains. A program can skip a chunk it doesn't recognize. - There is only one image stream.

A fun trick I do with my web based drawing tools is to save a JSON representation of your document as a comment field inside of a PNG. This way the doc you save is immediately usable as an image but can also be loaded back into the editor. Also means your downloads folder isn’t littered with unintelligible JSON files.

It is just a spec on something widely implemented already.

Assuming Next gen PNG will still require new decoder. They could just call it PNG2.

JPEG-XL already provides everything most people asked for a lossless codec. If there are any problems it is its encoding and decoding speed and resources.

Current champion of Lossless image codec is HALIC. https://news.ycombinator.com/item?id=38990568

> Officially supports Exif data

Probably the best news here. While you already can write custom data into a header, having Exif is good.

BTW: Does Exif have a magnetometer (rotation) and acceleration (gravity) field? I often wonder about why Google isn't saving this information in the images which the camera app saves. It could help so much with post-processing, like with leveling the horizon or creating panoramas.

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.

So animated GIFs can be replaced by Animated PNGs with alpha blending with transparent backgrounds and lossless compression! Some nostalgia from 2000s websites can be revived and relived :)

Curious if Animated SVGs are also a thing. I remember seeing some Javascript based SVG animations (it was a animated chatbot avatar) - but not sure if there is any standard framework.

A fun fact about PNG, the correct pronunciation is defined in the specification

> PNG is pronounced “ping”

See the end of Section 1 [0]

0: https://www.w3.org/TR/REC-png.pdf

I'm worried that by supporting too many encodings and color spaces this will hamper adoption and unexpected unsupported files. Perhaps this is more of an encoder/decoder library issue, which hopefully will give us rec2020 rgb32/rgb10a2 encode/decode apis so we can simply use them without having to know so many details.

Official support for animations, yes! This feels so nostalgic to me, I have written an L-system generator with support for exporting animated PNGs 11 years ago! They were working only in Firefox, and Chrome used to have an extension for them. Too bad I had to take the website down.

Back then, there were no libraries in C# for it, but it's actually quite easy to make APNG from PNGs directly by writing chunks with correct headers, no encoders needed (assuming PNGs are already encoded as input).

https://github.com/NightElfik/Malsys/blob/master/src/Malsys....

https://marekfiser.com/projects/malsys-mareks-lsystems/

It seems like this new PNG spec just cements what exists already, great! The best codecs are the ones that work on everything. PNG and JPEG work everywhere, reliably.

Try opening a HEIC or AV1 or something on a machine that doesn't natively support it down to the OS-level, and you're in for a bad time. This stuff needs to work everywhere—in every app, in the OS shell for quick-looking at files, in APIs, on Linux, etc. If a codec does not function at that level, it is not functional for wider use and should not be a default for any platform.

I'm very curious to see how this will end up stacking up vs lossless jpegxl

This is a false claim in the PR:

> Many of the programs you use already support the new PNG spec: ... Photoshop, ...

Photoshop does NOT support APNGs. The PR calls out APNg recognition as the 2nd bullet point of "What's new?"

Am I missing something? Seems like a pretty big mistake. I was excited that an art tool with some marketshare finally supported it.

> I know you all immediately wondered, better compression?. We're already working on that.

This worries me. Because presumably, changing the compression algorithm will break backwards compatibility, which means we'll start to see "png" files that aren't actually png files.

It'll be like USB-C but for images.

Not backwards compatible. We just add it to that nice cupboard "great advanced image formats we will forget about".

Society doesn't need a new image format. I'd wager to say not any new multimedia format. Big corporate entites do, and have churning them out at a steady pace.

Look at poor webp - a format pushed by the largest industry players - and the abysmal everyday use it gets, and the hate it generates.

Let's call it PPNG: Pas Portable NetWork Graphic

Somebody needs to manage human time/date approximates in a way other people in s/w will align to.

"photo scanned in 2025, is about something in easter, before 1940 and after 1920"

If you wanted better compression, it's called Lossless WEBP. Lossless WEBP is such a nice codec. Compared with Lossless JXL, it decompresses many times more quickly, and while JXL usually produces a smaller file, it doesn't always.

Lossless AVIF is not competitive.

However, lossless WEBP does not support indexed color images. If you need palettes, you're stuck with PNG for now.

Reading the linked blog post on the new cICP chunk type [0], it looks like the "proper HDR support" isn't something that you couldn't already do with an embedded ICC profile, but instead a much-abbreviated form of the colorspace information suitable for small image files.

[0] https://svgees.us/blog/cICP.html

What if we kind of fit JXL in PNG? That way it's more likely to be supported

HDR is about, well, high dynamic range images, usually expressed with at least 10 bits of precision (although it can also be float, etc), and often, but not always encoding scene-referred data instead of image-referred data (originally it was supposed to only encode scene-referred data, but then other competing formats ignored that). It has nothing to do with the gamut and with the color primaries, although in practice HDR images use a large color space.

But you can absolutely have an SDR image encoded using a large color space. So I am not sure why the author talks about color primaries when it tries to justify HDR… I still don’t know what kind of HDR images this new PNG variant can encode.

So what do we call it? PNG3? The spec is titled "Portable Network Graphics Specification (Third Edition)".

Surely they aren't releasing a new, incompatible version and expecting us to pretend it's the same format...?

> This updates the existing image/png Internet Media type

whyyyyyyy

20 years?? What took so long.

This is the first time I’ve seen HDR used to refer to wider color spaces and not extended brightness and contrast ratios.

cautiously optimistic. the thing that makes png so sought after is its status as frozen

It was gone??? Was I the only one using it this entire time?

What about implementations? libpng seems pretty dead, 1.7 has been in development forever but 1.6 is still considered the stable version. Is there a current "canonical" png C/C++ library?

Time is ripe for audio-included animated PNG files.

Can anyone explain how they maintain backwards compatibility on formats like this when adding features? I assume there are byte ranges managed in the format, but with things like compression, wouldn’t compressed images be unrenderable on clients that don’t support it? I suppose it would behoove servers to serve based on what the client would support.

Not backwards compatible I think

we need transparent (like gif)

!!!

Parallel compression/decompression is already possible via Z_SYNC_FLUSH.

Until everything new is "optional". Hopefully PNG won't be the target of "enshitification". We all know that for file formats, there is a very strong pressure from developers and vendors for that to happen since it favors, hard, vendor and developer lock-in. If not careful, even with a team of PHD devs won't be able to write alternatives encoders/decoders that "reasonbly" and the world will end-up with very few alternatives implementations, if not only one.

I did skim through the specs, it seems most of it is related to cleanup and optional blocks, so it seems PNG is still safe, am I wrong? (asking those who did dive into the new specs deeply).

>After 20 years of stagnation, PNG is back with renewed vigor!

After 20 years of success, we can't resist the temptation to mess with what works.

Doesn’t PNG already support 16 bits per color channel and an arbitrary number of color channels?

I thought this was about Papua New Guinea.

Never heard about Animated PNGs, and I am a nerd to the core.

Pleasantly surprised.

This is just rebranded MNG format that the PNG group tried to push as a ”standard” 20 years ago. Firefox removed MNG for a reason.

DaVinci Resolve also supports OpenEXR format with the added magic of LUT.

PNG is popular with some Commercial Application developers, but the exposure and color problems still look 1980's awful in some use-cases.

Even after spending a few grand on seats for a project, one still gets arrogant 3D clown-ware vendors telling people how they should run their pipeline with PNG hot garbage as input.

People should choose EXR more often, and pick a consistent color standard. PNG does not need yet another awful encoding option. =3

Oh no another HEIC!

it's more to do with the obvious economic layer underneath. you give a format new life only if there's tooling and distribution muscle behind it. adobe, apple, chrome, ffmpeg etc may not get aligned at the same time. someone somewhere wants apng/hdr/png to be a standard pipe again for creative chains; maybe because video formats are too bulky for microinteraction or maybe because svg is too unsafe in sandboxed renderers. and think onboarding of animations, embedded previews, rich avatars, system wide thumbs ; all without shipping a separate codec or runtime. every time a 'dead' format comes back, it's usually because someone needed a way around a gate

I can't believe the standard is 20yo.

this is good news, any packages who support new png standard or planning to? rust/go/python/js?

Papua New Guniea never went away!

Can someone TLDR why I should care as someone who doesn't directly get into the weeds of this type of things?

Is this written exactly for (1) people who implement/maintain this and, I say this with love, (2) nerds. Or will there be effects outside of a microscopic improvement on storage + latency.

PNG: doing very little with as much complexity as possible.