A new PNG spec

https://www.programmax.net/articles/png-is-back/

by bluedel • 1 year ago

672 598 1 year ago

programmax.net

bravesoul2• 1 year ago

Papua New Guniea never went away!

LeoPanthera2• 1 year ago

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.

skywal_l• 1 year ago

Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility.

That being said, they also can do dumb things however, right at the end of the sentence you quote they say:

we want to make sure we do it right.

So there's hope.

masklinn• 1 year ago

Can't you improve a compression algorithm and still produce a still valid decompression input? PNG is based on zip, there's certainly ways to improve zip without breaking backwards compatibility.

That's just changing an implementation detail of the encoder, and you don't need spec changes for that e.g. there are PNG compressors which support zopfli for extra gains on the DEFLATE (at a non-insignificant cost). This is transparent to the client as the output is still just a DEFLATE stream.

vhcr• 1 year ago

That's what OptiPNG already does.

lifthrasiir• 1 year ago

Better compression can also mean a new set of filter methods or a new interlacing algorithm. But yeah, any of them would cause an instant incompatibility. As noted in the relevant issue [1], we will need a new media type at the very least.

[1] https://github.com/w3c/png/issues/39#issuecomment-2674690324

snvzz• 1 year ago

I am hopeful whatever better compression doesn't end up multiplying memory requirements, or increase burden on cpu, especially on decompression.

Now, PNG datatype for AmigaOS will need upgrading.

Arnt5• 1 year ago

We would need a new media type. But the actual new features don't need one, because the news don't break compatibility.

https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the new colour space. If your software and monitor can handle it, you see better colour than I, otherwise, you see what I see.

Lerc2• 1 year ago

It has fields to say what compression is used. Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress.

The PNG format is specifically designed to allow software to read the parts they can understand and to leave the parts they cannot. Having an extensible format and electing never to extend it seems pointless.

mort962• 1 year ago

Adding another compression form should be handled by existing software as recognizing it as a valid PNG that they can't decompress.

Yeah, we know. That's terrible.

koito17• 1 year ago

Having an extensible format and electing never to extend it seems pointless.

This proves OP analogy regarding USB-C. Having PNG as some generic container for lossless bitmap compression means fragmentation in libraries, hardware support, etc. The reason being that if the container starts to support too many formats, implementations will start restricting to only the subsets the implementers care about.

For instance, almost nobody fully implements MPEG-4 Part 3; the standard includes dozens of distinct codecs. Most software only targets a few profiles of AAC (specifically, the LC and HE profiles), and MPEG-1 Layer 3 audio. Next to no software bothers with e.g. ALS, TwinVQ, or anything else in the specification. Even libavcodec, if I recall correctly, does not implement encoders for MPEG-4 Part 3 formats like TwinVQ. GP's fear is exactly this -- that PNG ends up as a standard too large to fully implement and people have to manually check which subsets are implemented (or used at all).

pvorb• 1 year ago

Extending the format just because you can – and breaking backwards compatibility along the way – is even more pointless.

If you've created an extensible file format, but you never need to extend it, you've done everything right, I'd say.

dooglius2• 1 year ago

Having an extensible format and electing never to extend it seems pointless.

So then it was pointless for PNG to be extensible? Not sure what your argument is.

chithanh4• 1 year ago

Adding another compression form should be handled by existing software

In an ideal world, yes. In practice however, if some field doesn't change often, then software will start to assume that it never changes, and break when it does.

TLS has learned this the hard way when they discovered that huge numbers of existing web servers have TLS version intolerance. So now TLS 1.2 is forever enshrined in the ClientHello.

shiomiru• 1 year ago

The difference between valid PNG you can't decompress and invalid PNG is fairly irrelevant when your aim is to get an image onto the screen.

And considering we already have plenty of more advanced competing lossless formats, I really don't see why "feed a BMP to deflate" needs a new, incompatible spin in 2025.

HelloNurse3• 1 year ago

Extensibility of PNG has been amply used, as intended, for proprietary chunks that hold application specific data (e.g. PICO-8 games) without bothering other software.

colanderman• 1 year ago

One could imagine a PNG file which contains a low-resolution version of the image with a traditional compression algorithm, and encodes additional higher-resolution detail using a new compression algorithm.

mrheosuper6• 1 year ago

Does usb-c spec break backward compatibility ?, a 2018 macbook work perfectly fine with 2025 usb c charger

techpression• 1 year ago

I don’t know if it’s the spec or just a plethora of vendors that ignores it, but I have many things with a USB-C port that requires USB-A as source. USB-C to A to C works, yay dongles, but not just C to C. So maybe it’s not really breaking backwards compatibility, just a weird mix of a port and the communication being separate standards.

danielheath2• 1 year ago

Some things don't work unless you use the right kind of USB-C cable.

EG your GPU and monitor both have a USB-C port. Plug them together with the right USB cable and you'll get images displayed. Plug them together with the wrong USB cable and you won't.

USB 3 didn't have this issue - every cable worked with every port.

mystifyingpoi3• 1 year ago

Yeah, I also don't think they've broken backwards compat ever. Super high end charger from 2024 can charge old equipment from 2014 just fine with regular 5V.

What was broken was the promise of a "single cable to rule them all", partly due to manufacturers ignoring the requirements of USB-C (missing resistors or PD chips to negotiate voltages, requiring workarounds with A-to-C adapters), and a myriad of optional stuff, that might be supported or not, without a clear way to indicate it.

zirgs2• 1 year ago

Yeah - it's a mess. Some devices only charge with a charger that supports PD. Some other devices need a charger WITHOUT PD support.

bmacho3• 1 year ago

+1 why not name it png4 or something. It's better if compatibility is obvious upfront

josephg3• 1 year ago

I think if they did that, nobody would use it. And anyway, from the article:

Many of the programs you use already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...

It might be too late to rename png to .png4 or something. It sounds like we're using the new png standard already in a lot of our software.

jillesvangurp• 1 year ago

Old PNGs will work just fine. And forward compatibility is much less important.

The main use case for PNG is web browsers and all of them seem to be on board. Using old web browsers is a bad idea. You do get these relics showing up using some old version of internet explorer. But some images not rendering is the least of their problems. The main challenge is actually going to be updating graphics tools to export the new files. And teaching people that sRGB maybe isn't good enough any more. That's going to be hard since most people have no clue about color spaces.

Anyway, that gives everybody plenty of time to upgrade. By the time this stuff is widely used, it will be widely supported. So, you kind of get forward compatibility that way. Your browser already supports the new format. Your image editor probably doesn't.

hnlmorg• 1 year ago

Browsers aren't the only software that work with PNGs. Far from it in fact.

AlienRobot2• 1 year ago

The main use case for PNG is web browsers

This is news to me. I'm pretty sure the main use case for PNG is lossless transparent graphics.

whywhywhywhy3• 1 year ago

The main use case for PNG is web browsers

It's not, most images you encounter on the web need better compression.

The main PNG use case is to store lossless images locally as master copies that are then compressed or in workflows where you intend to edit and change them where compressed formats would degrade the more they were edited.

ajnin• 1 year ago

What backward compatibility are we talking about here? Backwards compatibility of images will be fine, backwards compatibility of decoders might be impacted, but the article says the major image viewers (browsers) and image editors already support the 3rd version. Better compression is only planned for the 5th version of the spec.

Also if you forbid evolving existing formats, the only alternative to improve is to introduce a new format, and I argue that it would be causing even more fragmentation and be more difficult to adopt to. Look at all the drama surrounding JPEG XL.

altairprime2• 1 year ago

They could, for example, use lossy compression for the compatibility layer and then fill it in the rest of the way to lossless using incompatible new compression objects. Legacy uses will see some fidelity degradation, but they are already being stuck with sRGB downmixes, so that’s fine — and those who are bothered by it can just emit a lossless-pixels (but lossy-color and lossy-range) compatibility layer and reserve the compression benefits for the color and dynamic range.

I’m not saying this is what will happen — but if I was able to construct a plausible approach to compression in ten minutes, then perhaps it’s a bit early to predict the doom of compatibility.

bawolff6• 1 year ago

I don't think that will super be an issue. How often has "progressive jpeg" ever caused problems? That's the same thing.

ProgramMax28• 1 year ago

Worry not! (Well, worry a little.)

The first bit of our research is "What can we already make use of which requires no spec update? There are plenty of PNG optimizers. How much of that should go into the typical PNG libraries?"

Same with parallel encoding & decoding. An older image viewer will be able to decode it on one thread without ever knowing parallel decoding was an option.

Here's the worry-a-little part: Everybody immediately jumps to file size as to what image compression is better or worse. That isn't the best take, but it is what it is. So there is pressure to adopt newer technologies.

We often do have a way to maintain some degree of backwards compatibility even when we do this. For example, we can store a downsampled image for old viewers. Then extra, new chunks will know "Mix that with this full scale data, using a different compression".

As you can imagine, this mixing complicates things. It might not be the best option. Sooooo we're researching it :)

ori_b• 1 year ago

My strong vote is to just not touch it. Stability is a feature.

HexDecOctBin• 1 year ago

Downsampling will make PNG not be a lossless format. Just leave it alone, and work on a separate PNG2 or PNGX or whatever.

LegionMammal9784• 1 year ago

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

cormorant• 1 year ago

"common but not representable RGB spaces like Adobe 1998 RGB or ProPhoto RGB cannot use CICP and have to be identified with ICC profiles instead."

cICP is 16 bytes for identifying one out of a "list of known spaces" but they chose not to include a couple of the most common ones. Off to a great start...

I wonder if it's some kind of legal issue with Adobe. That would also explain why EXIF / DCF refer to Adobe RGB only by the euphemism "optional color space" or "option file". [1]

[1] https://en.wikipedia.org/wiki/Design_rule_for_Camera_File_sy...

spider-mario7• 1 year ago

CICP (H.273) originates from the video world, where Adobe RGB and ProPhoto RGB really aren’t common.

ProgramMax28• 1 year ago

PNG previously supported ICC v2. That was updated to ICC v4. However, neither of these are capable of HDR.

Maybe iccMAX supports HDR. I'm not sure. In either case, that isn't what PNG supported.

So something new was required for HDR.

LegionMammal9784• 1 year ago

However, neither of these are capable of HDR.

How so? As far as I can tell, the ICCv2 spec is very agnostic as to the gamut and dynamic range of the output medium. It doesn't say anything to the extent of "thou shalt not produce any colors outside the sRGB gamut, nor make the white point too bright".

Unless HDR support is supposed to be something other than just the primaries, white point, and transfer function. All the breathless blogspam about HDR doesn't make it very clear what it means in terms of colorspaces.

account4250• 1 year ago

Unfortunately that seems to mean that the backwards compatibility here is washed out preview instead of limited-to-sRGB.

albert_e2• 1 year ago

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.

andsoitis2• 1 year ago

Curious if Animated SVGs are also a thing.

Yes. Relevant animation elements:

• <set>

• <animate>

• <animateTransform>

• <animateMotion>

See https://www.w3schools.com/graphics/svg_animation.asp

mattigames2• 1 year ago

Overshadowed by CSS animations for almost all use cases.

albert_e2• 1 year ago

Oh TIL - Thanks!

This could possibly be used to build full fledged games like pong and breakout :)

shakna• 1 year ago

Slightly related, I recently hit on this SVG animation bug in Chrome (that someone else found):

https://shkspr.mobi/blog/2025/06/an-annoying-svg-animation-b...

riffraff• 1 year ago

I was under the impression many gifs these days are actually served as soundless videos, as those basically compress better.

Can animated PNG beat av1 or whatever?

josephg3• 1 year ago

I doubt it, given png is a lossless compression format. For video thats almost never what you want.

layer83• 1 year ago

APNG would be for lossless compression, and probably especially for animations without a constant frame rate. Similar to the original GIF format, with APNG you explicitly specify the duration of each individual frame, and you can also explicitly specify looping. This isn’t for video, it’s more for Flash-style animations, animated logos/icons [0], or UI screen recordings.

[0] like for example these old Windows animations: https://www.randomnoun.com/wp/2013/10/27/windows-shell32-ani...

armada6512• 1 year ago

Can animated PNG beat av1 or whatever?

Animated PNGs can't beat GIF nevermind video compression algorithms.

fc417fc8029• 1 year ago

many gifs these days are actually served as soundless videos

That's not really true. Some websites lie to you by putting .gif in the address bar but then serving a file of a different type. File extensions are merely a convention and an address isn't a file name to begin with so the browser doesn't care about this attempt at end user deception one way or the other.

bawolff6• 1 year ago

Its also because people like to "pause" animations, and that is not really an option with apng & gif.

account4250• 1 year ago

Soundless videos cannot be used in environments that expect an image like embeds in forums and similar.

It's a shame that browser vendors didn't add silent looping video support to the img tag over (imo) baseless concerns.

jonhohle• 1 year ago

It seems crazy to think about, but I interviewed with a power company in 2003 that was building a web app with animated SVGs.

bmacho3• 1 year ago

Curious if Animated SVGs are also a thing.

SVG is just html5, it has full support for CSS, javascript with buttons, web workers, arbitrary fetch requests, and so on (obviously not supported by image viewers or allowed by browsers).

bawolff6• 1 year ago

Browsers support all that sort of thing, as long as you use an iframe. (Technically there are sone subtle differences between that and html5, but you are right its mostly the same)

If you use an <img> tag, svgs are loaded in "restricted" mode. This disables scripting and external resources. However animation via either SMIL or CSS is still supported.

vorgol• 1 year ago

It nearly got raw socket support back in the day: https://news.ycombinator.com/item?id=35381755

chithanh4• 1 year ago

When it comes to converting small video snippets to animated graphics, I think WEBP was much better than APNG from the beginning. Only if you use GIF as intermediate format then APNG was competitive.

Nowadays, AVIF serves that purpose best I think.

account4250• 1 year ago

webm or any other non-gimped video codec would be a much better format for that use case. Unfortunately browsers don't allow those in image contexts so we are stuck with an inferior "state of the art" literally-webm-with-deliberately-worse-compression webp standard.

AVIF is only starting to become widespread so can't be used without fallback if you care about your users. Not sure how it compares to AV1 quality/compression wise but hopefully its not as gimped as webp and there will encoders that aren't as crap as libwebp that almost everyone uses.

jokoon• 1 year ago

both GIF and PNG use zipping for compressing data, so APNG are not much better than GIF

bawolff6• 1 year ago

PNG uses deflate (same as zip) but GIF uses LZW. These are different algorithms. You should expect different compression results i would assume.

0points2• 1 year ago

Remember when we unwillingly trained the generative AI:s of our time with an endless torrent of factoids?

Calzifer2• 1 year ago

(A)PNG supports semi-transparency. In GIF a pixel is either full transparent or full opaque.

Also while true color gifs seem to be possible it is usually limited to 256 colors per image.

For those reasons alone APNG is much better than GIF.

theqwxas• 1 year ago

Some years ago I've used the Lottie (Bodymovin?) library. It worked great and had a nice integration: you compose your animation in Adobe After Effects, export it to an svg plus some json, and the lottie JS script would handle the animation for you. Anything else with (vector, web) animations I've tried is missing the tools or the DX for me to adopt. Curious to hear if there are more things like this.

I'm not sure about the tools and DX around animated PNGs. Is that a thing?

qingcharles2• 1 year ago

Almost nowhere that supports uploading GIFs supports APNG or animated WEBP. The back end support is so low it's close to zero. Which is really frustrating.

extraduder_ire2• 1 year ago

Do you mean services that reencode gif files to webm/mp4? apng just works everywhere that png works, and will remain animated as long as it's not re-encoded.

You can even have one frame that gets shown if and only if animation is not supported.

account4250• 1 year ago

So animated GIFs can be replaced by Animated PNGs with alpha blending with transparent backgrounds and lossless compression!

Not progressively though unless browsers add a new mime type for it which they did not bother to do with animated webp.

adgjlsfhk12• 1 year ago

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

Simran-B• 1 year ago

I doubt it can get anywhere near. What is even the point of a new PNG version if there's something as advanced as JXL that is also royalty-free?

layer83• 1 year ago

Browser support for JPEG XL is poor (basically only Safari I think), while the new PNG spec is already supported by all mainstream browsers.

LoganDark• 1 year ago

For starters, you're actually able to use PNG.

qwertox• 1 year ago

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.

Aardwolf2• 1 year ago

Exif can also cause confusion for how to render the image: should its rotation be applied or not?

Old decoders and new decoders now could render an image with exif rotation differently since it's an optional chunk that can be ignored, and even for new decoders, the spec lists no decoder recommendations for how to use the exif rotation

It does say "It is recommended that unless a decoder has independent knowledge of the validity of the Exif data, the data should be considered to be of historical value only.", so hopefully the rotation will not be used by renderers, but it's only a vague recommendation, there's no strict "don't rotate the image" which would be the only backwards compatible way

With jpeg's exif, there have also been bugs with the rotation being applied twice, e.g. desktop environment and underlying library both doing it independently

DidYaWipe8• 1 year ago

The stupid thing is that any device with an orientation sensor is still writing images the wrong way and then setting a flag, expecting every viewing application to rotate the image.

The camera knows which way it's oriented, so it should just write the pixels out in the correct order. Write the upper-left pixel first. Then the next one. And so on. WTF.

jandrese2• 1 year ago

Yes, but websites frequently strip all or almost all Exif data from uploaded images because some fields are used by stalkers to track people down to their real address.

johnisgood4• 1 year ago

And I strip Exif data, too, intentionally, for similar reasons.

sunaookami2• 1 year ago

That reminds me when I first uploaded a picture to some forum and it showed my full home address together with a map as a "feature"

andsoitis2• 1 year ago

There is no standard field to record readouts of a camera's accelerometers or inertial navigation system.

Exif fields: https://exiv2.org/tags.html

bawolff6• 1 year ago

Personally i wish people just used XMP. Exif is such a bizarre fotmat. Its essentially embedding a tiff image inside a png.

Findecanor2• 1 year ago

Does the meta-data have support for opting in/out of "AI training"?

And is being able to read an image without an opt-in tag something that has to be explicitly enabled in the reference implementation's API?

joshvm• 1 year ago

There is an acceleration field (Exif.Photo.Acceleration) and (Exif.Photo.CameraElevationAngle) for elevation but oddly not 3 axes. Similarly there are fields for ambient environmental conditions, but only whatever specific things the spec-writers considered.

You could store this in Exif.Photo.MakerNote: "A tag for manufacturers of Exif writers to record any desired information. The contents are up to the manufacturer." I think it can be pretty big, certainly more than enough for 9 DoF position data.

pezezin2• 1 year ago

Ages ago I worked on photogrammetry software, and the lack of such information was indeed painful for us. One of the most important parts of the processing pipeline is calculation the position and orientation of each camera; having at least the orientation would have made our life much easier.

ggm3• 1 year ago

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"

SchemaLoad2• 1 year ago

The issue that gets me is that Google Photos and Apple photos will let you manually pick a date, but they won't actually set it in the photo EXIF, so when you move platforms. All of the images that came from scans/sent without EXIF lose their dates.

ggm3• 1 year ago

It's in sidecar files. Takeout gets them, some tools read them.

mbirth• 1 year ago

IIRC osxphotos has an option to merge external metadata into the exported file.

luguenth• 1 year ago

In EXIF, you have DateTimeDigitized [0]

For ambiguous dates there is the EDTF Spec[1] which would be nice to see more widely adopted.

[0] https://www.media.mit.edu/pia/Research/deepview/exif.html

[1] https://www.loc.gov/standards/datetime/

ggm3• 1 year ago

I remember reading about this in a web forum mainly for dublin core fanatics. Metadata is fascinating.

Different software reacts in different ways to partial specifications of yyyy/mm/dd such that you can try some of the cute tricks but probably only one s.w. package honours it.

And the majors ignore almost all fields other than a core set of one or two, disagree about their semantics, and also do wierd stuff with file name and atime/mtime.

kumarvvr• 1 year ago

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

Pleasantly surprised.

spauldo3• 1 year ago

Animation was an early feature, actually. It was called "MNG" and was developed alongside PNG. I don't know the details of why but it never really saw adoption outside of Firefox and was eventually removed even from there. APNG is different from MNG and came much later.

Joel_Mckay5• 1 year ago

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

morjom• 1 year ago

What are some "consistent color standards" you'd recommend? Honest question.

Joel_Mckay5• 1 year ago

Like all complex questions, the answer is it depends on the target project and or Display.

A very basic rec.709 workflow tutorial:

https://www.youtube.com/watch?v=lf8COHAgHJs

The Andreas Dürr LUT pack:

https://www.youtube.com/watch?v=dDKK54CeXgM

https://cinematiccookie.gumroad.com/l/bseftb?layout=profile

The calibration workflows also depend heavily on what is being rendered, source application(s), and the desired content look. There were some common free packs on github for popular programs at one time. Should still be around someplace... good luck. =3

DidYaWipe8• 1 year ago

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

What are you talking about? It's a bitmap. It has nothing to do with "exposure and color problems."

Joel_Mckay5• 1 year ago

In general, with some applications people hit the limits pretty quickly with PNG and JPG. In our use-case, the EXR format essentially meant a rendered part of the source image wouldn't be "overexposed" by the render pipeline, and layers could be later adjusted to better match in Resolve. Example: your scenes fireball simulation won't look like a fried egg photo from 1980 due to hitting 0xFF.

If you've never encountered the use-case, than don't worry about the aesthetics. Seriously, many vendors also just don't care... especially after they already were paid. Best of luck =3

nektro• 1 year ago

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

tonyedgecombe3• 1 year ago

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.

encom3• 1 year ago

Yea I'm mildly concerned about this as well. PNG's age is a feature, in a time where software development has gone to hell.

HelloNurse3• 1 year ago

Without the new HDR and color profile handling, PNG was still useful but significantly obsolete. Display hardware has progressed over a few decades, raising the bar for image files.

eviks5• 1 year ago

[not] Officially supports Exif data

How can you call this basic fail a success?

tonyedgecombe3• 1 year ago

Exif data might be important to you but it clearly hasn't stopped the adoption of png.

account4250• 1 year ago

Embedded (and thus often invisible) metadata is a mistake.

jbverschoor• 1 year ago

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

iliketrains• 1 year ago

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/

chithanh4• 1 year ago

Official support for animations, yes!

While I welcome that there is now PNG with animations, I am less impressed about how Mozilla chose to push for it.

Using PNG's magic numbers and pretend to existing software that it is just normal PNG? That is the same mindset that lead to HTML becoming tag soup. After all, HTML with a <blink> tag is still HTML, no?

I think they could have achieved animated PNG standardization much faster with a more humble and careful approach.

hrydgard• 1 year ago

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?

vanderZwan• 1 year ago

I mean, if the spec has been stable for two decades then maybe there just hasn't been much to fix? Especially since PNG is a relatively simple image format.

illiac78611• 1 year ago

Seems that logic does not apply to jpeg though.

ethan_smith• 1 year ago

For modern C/C++ PNG implementations, consider lodepng (header-only), stb_image/stb_image_write (single-file), or libspng (active fork focused on performance and security) as more actively maintained alternatives to libpng.

ProgramMax28• 1 year ago

libpng updates are either already landed or nearly landed.

defraudbah• 1 year ago

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

guilbep• 1 year ago

Let's call it PPNG: Pas Portable NetWork Graphic

b0a04gl• 1 year ago

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

ProgramMax28• 1 year ago

In general, I support the "follow the money" idea. But I don't think it applies here.

I'm retired and making zero money here. (I'm actually losing money on it. Wish I had a company sponsoring me for the flights and hotels for meetups.)

All participants are required to not patent any piece of it. We work hard to make sure we only reference open standards. (This one is quite tricky. We have to convince other standard orgs to make their stuff free.)

I could see the argument for getting around a gate. But fwiw I don't think that's the case :)

neepi• 1 year ago

Oh no another HEIC!

Dwedit3• 1 year ago

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.

altairprime2• 1 year ago

I look forward to seeing what PNG v5 does in the future with compression, especially relative to existing formats.

ansgri• 1 year ago

How's HDR and high bit depth support? One of the things I liked about JXL is wide range of bit depths and arbitrary number of channels.

rurban• 1 year ago

And the JXL api is a nightmare, compared to WEBP.

Dwedit3• 1 year ago

Yeah, the whole "subscribe to events then check a status result" thing is pretty bad. This is compounded by "Box" behaving differently than everything else. When I made JxlSharp (C# JXL library wrapper), I had to add a workaround in there to force Box to behave like all the other event subscriptions.

And buffer sizes aren't handled in a good way. You have to provide pre-allocated memory, guessing how big it is supposed to be. Then you get a "not big enough" error. This is a guessing game, not a good design. You're forced to overshoot, then shrink the buffer afterwards.

---

In different APIs, there tends to be a function you call to get the required buffer size. For example, many Win32 API functions make you call them with a buffer size of 0, then you get the actual required size back. Another possibility is having the library allocate the memory, and return the allocated buffer to you. Since cross-module memory management is hairy (different `malloc` implementations can't interoperate), some APIs let you provide the `malloc`, `realloc`, and `free` functions.

account4250• 1 year ago

Webp is a joke. The reference encoder can't even get color spaces right.

snickerbockers• 1 year ago

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

meindnoch7• 1 year ago

Parallel compression/decompression is already possible via Z_SYNC_FLUSH.

Retr0id8• 1 year ago

Parallel decompression of Z_SYNC_FLUSH'd data is not possible without additional metadata to tell you where the sync points are.

meindnoch7• 1 year ago

True. Although this can be mitigated in a backwards compatible manner, by adding a new PNG chunk that points to the locations of the sync points.

sylware2• 1 year ago

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).

ProgramMax28• 1 year ago

Everything new is optional. This is not a breaking change. Old PNGs and software continue to work just fine. And these new changes are backwards-compatible as much as they can be. So old software can display a new PNG and be mostly correct. By that I mean, the user will still say "it is a picture of a red apple". But if the software isn't HDR, they might not get the bright highlights and inky blacks of the HDR PNG.

sylware2• 1 year ago

What is the remaining pertinent value of HDR since we are moving towards xrgb16161616 pixel format?

antirez• 1 year ago

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

LeoPanthera2• 1 year ago

You’re going to be shocked when you find out how webp works.

qwertfisch2• 1 year ago

Because that’s a video compression format, from where only a single intra-frame is used.

poisonborz2• 1 year ago

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.

michaelmior• 1 year ago

and the abysmal everyday use it gets

Estimates are that 95% of Internet users have a browser that supports WebP and that ~25% of the top million websites serve WebP images. I wouldn't call that abysmal.

hsbauauvhabzb3• 1 year ago

My file manager can’t handle them but my browser can.

Edit: and good luck uploading the format to the majority of webforms that aren’t faang.

dotancohen2• 1 year ago

5% of people can't view them, yet 25% of top websites use them?

In what other industry would it be considered acceptable to exclude 5% of visitors/users/clients?

Geezus_42• 1 year ago

Great, so I can download it, but then I have to convert it to a different format before half my apps will be able to use it.

AlienRobot2• 1 year ago

You can't even upload webp to instagram.

whywhywhywhy3• 1 year ago

completely fails the second you want to do anything more than load it on a webpage

Photoshop still won’t open it, MacOS preview opens it but then demands to convert it to tiff when you try to edit it

Etheryte• 1 year ago

I don't really think this is the case here. All major browsers already support the new spec for example. This isn't a case of oh we'll have support for it eventually, it's already there.

Hendrikto• 1 year ago

Momentum built, and additional parties became interested. […] we had representation from […] Adobe, Apple, BBC, Comcast / NBCUniversal, Google, MovieLabs, and […] W3C
Many […] programs […] already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...
Plus, you saw some broadcast companies in that list above. Behind the scenes, hardware and tooling are being updated to support the new PNG spec.

127• 1 year ago

There's a big issue that all old popular image formats are 8-bits. 10-bits or even 12-bits would help a lot with storing more information and maintaining editability.

londons_explore• 1 year ago

If adding more bits to an image format, please make it 'n bit'. Ie. the file could be 8 bit, it could be 10, it could be 12, it could be 60 bit!

Whilst we're at it, please get rid of RGB and make it N channels too.

Libraries can choose to render that into a 3 channel, 8 bit buffer for legacy applications - but the data will be there for CMYK or HDR, or depth maps, or transparency, or focus stacking, or any other future feature!

Retr0id8• 1 year ago

PNG has supported 16-bits per channel since version 1.0 in 1998 (at least)

lioeters2• 1 year ago

Not backwards compatible

They say it's technically compatible since older image decoders should recognize the PNG file is using a different compression algorithm than the default.

Many programs already support the new PNG spec: Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer...

This is intentionally ignoring the fact that there are countless PNG decoders out in the wild, many using libpng the standard decoder last updated 6 years ago; and they will not be able to read the new PNG v2 files.

They should have used a different file extension, PNG2, to distinguish this incompatible format. Otherwise, users will be confused why their newly saved PNG file cannot be read by certain existing programs.

arp242• 1 year ago

libng seems to get regular updates? A release just a few days ago.

There's a PR for APNG: https://github.com/pnggroup/libpng/pull/706 – it seems there was some work for HDR in e.g. https://github.com/pnggroup/libpng/pull/635 as well. Related: https://github.com/pnggroup/libpng/issues/507

Retr0id8• 1 year ago

Which aspects are not backwards compatible?

You'll never be able to faithfully represent an HDR image on a non-HDR system, but you'll still see an image.

account4250• 1 year ago

The problem is when "HDR" images that would perfectly fit into the sRGB color space are not rendered correctly on non-HDR systems. This PNGv2 fails that which means it isn't really any more useful and one of the existing (and much better) HDR-supporting formats like JPEG-XL or the video codec based ones pushed by the big guys.

LocalH7• 1 year ago

I miss the days of old Amiga OS 3.x, where you had installable "DataTypes" that any program could make use of. If we had that, then all such programs could at least be updated to basic compatibility by simply updating the datatype.

account4250• 1 year ago

All operating systems support some kind of shared libraries and plugin architecture.

dev_l1x_be3• 1 year ago

Look at poor webp

What about it?

"Lossless WebP is typically 26% smaller than PNG, while lossy WebP can be 25-34% smaller than JPEG at equivalent quality levels"

This literally saves houndred of thousand of cost, bandwith, electricity every month on the internet. In fact, I strongly belive that this is one of the greatest contributions from Google to society just like ZSTD from Facebook.

https://developers.google.com/speed/webp/docs/webp_study

Timwi• 1 year ago

I don't think the commenter you replied to disagrees with any of that. They were talking about poor rates of adoption, not its feature set.

poisonborz2• 1 year ago

Society wholeheartedly thanks Google for saving costs for Google

Mr_Minderbinder4• 1 year ago

Those numbers are from Google. Third parties have not found WebP to be as good as Google claims.

account4250• 1 year ago

equivalent quality levels

Therein lies the lie.

Image and video compression comparisons are like statistics with the right corpus and evaluation criteria you can should whatever narrative you want to push.

GuB-42• 1 year ago

There are some applications for a new image format, but I agree that what we have is generally good enough.

We need good video formats however. Video makes up most of the global internet traffic, probably accounts for a good part of global storage capacity too. Even slightly better compression will have a massive impact.

ProgramMax28• 1 year ago

It is very backwards compatible. I'm not sure why you thought that.

We jumped through quite a lot of hoops to make sure old software will be able to display new images. They simply won't display them optimally. But for the most part, that would be because the old software wouldn't display images optimally anyway. So the limit was the software, not the format.

What I mean by this is old software that treats everything as sRGB wouldn't correctly show a Display P3 image anyway. But we made sure it will still display the image as correctly as it could.

account4250• 1 year ago

The sample HDR images don't show correctly in image viewers even though the colors used fit into the sRGB gamut (or at least have good approximations in there). That's not really backwards compatibility.

Padriac• 1 year ago

I thought this was about Papua New Guinea.

ksec4• 1 year ago

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

klabb32• 1 year ago

What about transparency? That’s the main benefit of PNG imo.

cmiller13• 1 year ago

Yes JPEG-XL has an alpha channel.

illiac78611• 1 year ago

If there are any problems it is its encoding and decoding speed and resources.

And this will improve over time, like jpg encoders and decoders did.

ksec4• 1 year ago

I hope I am very wrong but this isn't given. In the past reference encoder and decoder do not concern about speed and resources, but last 10 years have shown most reference encoder and decoder has already put considerable effort into speed optimisation. And it seems people are already looking to hardware JPEG XL implementation. ( I hope and guess this is for Lossless only )

account4250• 1 year ago

Or it won't like JPEG 2000 encoders didn't.

thesz• 1 year ago

HALIC discussion page [1] says otherwise.

[1] https://encode.su/threads/4025-HALIC-(High-Availability-Loss...

It looks like LEA 0.5 is the champion.

And HALIC is not even close to ten in this [2] lossless image compression benchmark.

[2] https://github.com/WangXuan95/Image-Compression-Benchmark

poly2it• 1 year ago

It looks like HALIC offers very impressive decode speeds within its compression range.

Nanopolygon5• 1 year ago

Champion! I wish you hadn't commented so ignorantly. Please also try to look at the processing speeds! Or you can also try not to comment at all...

voxleone• 1 year ago

I'm using png in a computer vision image annotation tool[0]. The idea is to store the class labels directly in the image [dispensing with the side car text files], taking advantage of the beautiful png metadata capabilities. The next step is to build a specialized extension of the format for this kind of task.

[0]https://github.com/VoxleOne/XLabel

yyyk• 1 year ago

When it comes to metadata, an implementation not being widely implemented (yet) is not that big a problem. Select tools will do for meta, so this is an advancement for PNG.

bla3• 1 year ago

WebP lossless is close to state of the art and widely available. It's also not widely used. The takeaway seems to be that absolute best performance for lossless compression isn't that important, or at least it won't get you widely adopted.

adzm• 1 year ago

Only downside is that webp lossless requires RGB colorspace so you can't, for example, save direct YUV frames from a video losslessly. AVIF lossless does support this though.

mchusma• 1 year ago

I don't know that i have ever used jpg or png lossless in practical usage (e.g. I don't think 99.9% of mobile app or web usecases are for lossless). WebP lossy performance is just not worth it in practice, which is why WebP never took off IMO.

Are there usecases for lossless other than archival?

ProgramMax28• 1 year ago

WebP maxes at 8-bit per channel. For HDR, you really need 10- or 12-bit.

WebP is amazing. But if I were going to label something "state of the art" I would go with JPEGXL :)

account4250• 1 year ago

Last I checked cwebp does not preserve PNG color space information properly so the result isn't actually visually lossless.

Aloisius• 1 year ago

I'll be honest, I ignored JPEG XL for a couple years because I assumed that it was merely for extra large images.

ChrisMarshallNY• 1 year ago

Looks like it's basically reaffirming what a lot of folks have been doing, unofficially.

For myself, I use PNG only for computer-generated still images. I tend to use good ol' JPEG for photos.

HakanAbbas3• 1 year ago

I don't really understand what the new PNG does better. Elements such as speed or compression ratio are not mentioned. Thanks also for your kind thoughts ksec.

Apart from the widespread support in codecs, there are 3 important elements: processing speed, compression ratio and memory usage. These are taken into account when making a decision (pareto limit). In other words, the fastest or the best compression maker alone does not matter. Otherwise, the situation can be interpreted as insufficient knowledge and experience about the subject.

HALIC is very good in lossless image compression in terms of speed/compression ratio. It also uses a comic amount of memory. No one mentioned whether this was necessary or not. However, low memory usage negatively affects both the processing speed and the compression ratio. You can see the real performance of HALIC only on large-sized(20 MPixel+) images(single and multi-thread). An example current test is below. During operations, HALIC uses only about 20 MB of memory, while JXL uses more than 1 GB of memory.

https://www.dpreview.com/sample-galleries/6970112006/fujifil...

June 2025, i7 3770k, Single Thread Results

----------------------------------------------------

First 4 JPG Images to PPM, Total 1,100,337,479 bytes

HALIC NORMAL: 5.143s 6.398s 369,448,062 bytes

HALIC FAST : 3.481s 5.468s 381,993,631 bytes

JXL 0.11.1 -e1: 17.809s 28.893s 414,659,797 bytes

JXL 0.11.1 -e2: 39.732s 26.195s 369,642,206 bytes

JXL 0.11.1 -e3: 81.869s 72.354s 371,984,220 bytes

JXL 0.11.1 -e4: 261.237s 80.128s 357,693,875 bytes

----------------------------------------------------

First 4 RAW Images to PPM, Total 1.224.789.960 bytes

HALIC NORMAL: 5.872s 7.304s 400,942,108 bytes

HALIC FAST : 3.842s 6.149s 414,113,254 bytes

JXL 0.11.1 -e1: 19.736s 32.411s 457,193,750 bytes

JXL 0.11.1 -e2: 42.845s 29.807s 413,731,858 bytes

JXL 0.11.1 -e3: 87.759s 81.152s 402,224,531 bytes

JXL 0.11.1 -e4: 259.400s 83.041s 396,079,448 bytes

----------------------------------------------------

I had a very busy time with HALAC. Now I've given him a break, too. Maybe I can go back to HALIC, which I left unfinished, and do better. That is, more intense and/or faster. Or I can make it work much better in synthetic images. I can also add a mode that is near-lossless. But I don't know if it's worth the time I'm going to spend on it.

account4250• 1 year ago

In other words, the fastest or the best compression maker alone does not matter.

Strictly true, but e.g. for archival or content delivered to many users compression speed and memory needed for compression is an afterthought compared to compressed size.

leviathan1• 1 year ago

Not backwards compatible I think

ProgramMax28• 1 year ago

It is very backwards compatible. :) We worked hard to make sure it would be.

369548684892826• 1 year ago

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

gred4• 1 year ago

That makes two image format names which I will refuse to pronounce correctly (the other being GIF [1]).

[1] https://edition.cnn.com/2013/05/22/tech/web/pronounce-gif

cmiller13• 1 year ago

How do you pronounce PNG?

ziml772• 1 year ago

The only logic I ever hear for using a hard G is because that's how Graphics is said. Yet I never hear people saying jay-feg.

dspillett4• 1 year ago

Because the creator of gifs telling the world how he pronounced it made such a huge difference :)

Not sure I'll bother to reprogram myself from “png”, “pung”, or “pee-enn-gee”.

naikrovek3• 1 year ago

When someone makes a baby, you call that person by their real name with the correct pronunciation, don’t you?

So why can’t you do that with GIF or PNG? People that create things get to name them.

LocalH7• 1 year ago

I've said "jif" for almost 40 years, and I'm not stopping anytime soon.

Hard-g is wrong, and those who use it are showing they have zero respect for others when they don't have to.

It's the tech equivalent to the shopping cart problem. What do you do when there is no incentive one way or the other? Do you do the right thing, or do you disrespect others?

yuters• 1 year ago

Pronouncing it like that would invite confusion as the word ping is often used in messaging.

nashashmi2• 1 year ago

let's propose PENJ to avoid the confusion.

eviks5• 1 year ago

Ha, been doing it "wrong" my whole life!

ProgramMax28• 1 year ago

Even though I know about this, I still pronounce it as letters. :)

account4250• 1 year ago

That's the correct pronunciation the same way the correct pronunciation for GIF is jiff. Human language is not something you can prescribe.

qwertfisch2• 1 year ago

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.

Aachen3• 1 year ago

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

Retr0id8• 1 year ago

zlib/deflate already has the same issue. It is mitigated somewhat by PNG row filters.

adgjlsfhk12• 1 year ago

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.

wongarsu• 1 year ago

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

spider-mario7• 1 year ago

JPEG XL is not “apply zstd to the pixel data”. What the parent comment meant is that JPEG XL, like zstd, happens to use ANS among its set of techniques. It handles gradients just fine.

illiac78611• 1 year ago

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?

pmarreck2• 1 year ago

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.

bmn__• 1 year ago

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.

Dylan16807• 1 year ago

Adopt it anyway. Add a decoder. Don't let google bully you out of such a good format.

mikae1• 1 year ago

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

rhet0rica3• 1 year ago

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.

pezezin2• 1 year ago

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.

Dwedit3• 1 year ago

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.

stgn• 1 year ago

and it's too bad that JPEG-XL lacks such a filter

JPEG XL has an edge-preserving filter ("EPF") for the purpose of reducing ringing.

ccarnino• 1 year ago

I can't believe the standard is 20yo.

naikrovek3• 1 year ago

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

ProgramMax28• 1 year ago

16-bit, yes. Arbitrary channel count, no. However, HDR is more than just bitcount.

aizk• 1 year ago

20 years?? What took so long.

eabeezxjc• 1 year ago

we need transparent (like gif)

!!!

ProgramMax28• 1 year ago

PNGs have supported transparency since day 1 :)

cptcobalt• 1 year ago

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.

lazide2• 1 year ago

This new spec will make PNG even worse than HEIC or AV1 - you won’t know what codec is actually inside the PNG until you open it.

hulitu• 1 year ago

you won’t know what codec is actually inside the PNG until you open it.

But this is a feature. Think about all those exploits made possible by this feature. Sincerely, the CIA, the MI-6, the FSB, the Mossad, etc.

ecshafer• 1 year ago

I work with a LOT of images in a lot of image formats, many including extremely niche formats used in specific fields. There is a massive challenge in really supporting all of these, especially when you get down to the fact that some specs are a little looser than others. Even libraries can be very rough, since sure it says on the tin it supports JPG and TIF and HEIC... but does it support a 30GB Jpeg? Does it support all possibly meta data in the file?

remram• 1 year ago

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

ProgramMax28• 1 year ago

New? Yes. Incompatible? No.

We went to pretty extreme lengths to make sure old software worked with the new changes. Effectively, the limit will be the software, not the image.

For example, you can imagine some old software that is unaware of color spaces and treats everything as sRGB. There is nothing we can do to make that software show a Display P3 correctly. However, we can still show the image well enough that a user understands "that is a red apple".

account4250• 1 year ago

Having images show up in washed up colors without any indication is not what I'd consider "working". This mistake has been made many times, please let's not make it again.

joshmarinacci2• 1 year ago

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.

tomtom1337• 1 year ago

Could you expand on this? It sounds a bit preposterous to save a text, as json, inside an image - and then expect it to be immediately usable… as an image?

behnamoh• 1 year ago

no, GP meant they add the JSON text to the meta data of the image as comment.

bitpush• 1 year ago

Not OP, but PNG (and most image/video formats) allows metadata and most allows arbitrary fields. Good parsers know to ignore/safely skip over fields that they are not familiar with.

https://dev.exiv2.org/projects/exiv2/wiki/The_Metadata_in_PN...

This is similar to HTTP request headers, if you're familiar with that. There are a set of standard headers (User-Agent, ETag etc) but nobody is stopping you from inventing x-tomtom and sending that along with HTTP request. And on the receiving end, you can parse and make use of it. Same thing with PNG here.

chown• 1 year ago

Save text as JSON as comments but the file itself is a PNG so that you can use it as an image (like previewing it) as they would ignore the comments. However, the OP’s editor can load the file back, parse the comments, and get the original data and continue to edit. Just one file to maintain. Quite clever actually.

woodrowbarlow• 1 year ago

this is useful for code that renders images (e.g. data-visualization tools). the image is the primary artifact of interest, but maybe it was generated from data represented in JSON format. by embedding the source data (invisibly) in the image, you can extract it later to modify and re-generate.

LeifCarrotson• 1 year ago

They're not saving text, they're saving an idea - a "map" or a "CAD model" or a "video game skin" or whatever.

Yes, a hypothetical user's sprinker layout "map" or whatever they're working on is actually composed of a few rectangles that represent their house, and a spline representing the garden border, and a circle representing the tree in the front yard, and a bunch of line segments that draw the pipes between the sprinkler heads. Yes, each of those geometric elements can be concisely defined by JSON text that defines the X and Y location, the length/width/diameter/spline coordinates or whatever, the color, etc. of the objects on the map. And yes, OP has a rendering engine that can turn that JSON back into an image.

But when the user thinks about the map, they want to think about the image. If a landscaping customer is viewing a dashboard of all their open projects, OP doesn't want to have to run the rendering engine a dozen times to re-draw the projects each time the page loads just to show a bunch of icons on the screen. They just want to load a bunch of PNGs. You could store two objects on disk/in the database, one being the icon and another being the JSON, but why store two things when you could store one?

meindnoch7• 1 year ago

Check what draw.io does when you download a PNG.

dtech• 1 year ago

A fun trick, but I wouldn't want to explain to users why their things are saved as a .png, not why their things is lost after they opened and saved the PNG in Paint.

KetoManx64• 1 year ago

If a user is using paint to edit their photos, they're 100% not going to be interested in having the source document to play around with.

account4250• 1 year ago

It can also become a security issue when users inadvertendly share layers/history/whatever that isn't visible anymore in the final image but still in the editable part.

geekifier• 1 year ago

This is also how Valetudo delivers robot map data to Home Assistant https://hass.valetudo.cloud.

neuronexmachina• 1 year ago

This would be great for things like exported Mermaid diagrams.

paisawalla• 1 year ago

Are you the developer of draw.io?

shiryel• 1 year ago

That is also how Krita stores brushes. Unfortunately, that can cause some unexpected issues when there's too much data [1][2].

[1] https://github.com/Draneria/Metallics-by-Draneria_Krita-Brus...

[2] https://krita-artists.org/t/memileo-impasto-brushes/92952/11...

oakwhiz• 1 year ago

If a patch is needed for libpng to get around the issue, maybe Krita should vendor libpng for usability. It's not unreasonable for people to want to create gigantic files like this.

speps2• 1 year ago

Macromedia Fireworks did it 20 years ago, the PNG was the default save format. Of course, it wasn’t JSON stored in there…

usef-• 1 year ago

I was going to say the same thing. It was nice as their native save format could still be opened anywhere.

But you did need to remember to export if you didn't want the extra fields increasing the file size. I remember finding fireworks pngs on web pages many times back then.

IvanK_net2• 1 year ago

Macromedia did this when saving Fireworks files into PNG.

Also, Adobe saves AI files into a PDF (every AI file is a PDF file), and Photoshop can save PSD files into TIFF files (people wonder why these TIFFs have several layers in Photoshop, but just one layer in all other software).

giancarlostoro• 1 year ago

Macromedia did this when saving Fireworks files into PNG. I forgot about this..

Fireworks was my favorite image editor, I don't know that I've ever found one I love as much as I loved Fireworks. I'm not a graphics guy, but Fireworks was just fantastic.

osetnik• 1 year ago

save a JSON representation of your document as a comment field inside of a PNG

Can you compress it? I mean, theoretically there is this 'zTXt' chunk, but it never worked for me, therefore I'm asking.

dragonwriter• 1 year ago

This is also what many AI image gen frontends do, saving the generation specs as comments so you can open the image and get prompt and settings (or, for, e.g., ComfyUI, full workflows) loaded to tweak.

Really, I think its pretty common for tools that work with images generally.

akx• 1 year ago

This is what stable-diffusion-webui does too (though the format is unfortunately plaintext); ComfyUI stores the node graph as JSON, etc.

japanuspus• 1 year ago

This is such a great use. Excalidraw does this too [0], and uses a two-level extension, `.excalidraw.png`.

[0] https://excalidraw.com/

razorfen• 1 year ago

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.

jdhsddh• 1 year ago

PNG is specifically designed to support this. Clients will simply skip chunks they do not understand.

In this case there could be an embedded reduced colour space image next to an extended color space one

joshmarinacci2• 1 year ago

The PNG format has chunks with types. So you can add an additional chunk with a new type and existing decoders will ignore it.

There is also some leeway for how encoding is done as long as you end up with a valid stream of bits at the end (called the bit stream format), so encoders can improve over time. This is common in video formats. I don’t know if a lossless image format would benefit much from that.

gmueckl2• 1 year ago

PNG is a bit unusual in that it allows a couple of alternate compressed encodings for the data that are all lossless. It is up to the encoder to choose between them (scanline by scanline, IIRC). So.this encoding algorithm leeway is implicit in a way.

gmueckl2• 1 year ago

In mynunderstanding, the actual image data encoding isn't altered in this update. It only introduces an extended color space definition for the encoded data.

PNG is a highly structured file format internally. It borrows design ideas from formats like EA's Interchange File Format in that it contains lists of chunks with fixed headers encoding chunk type amd length. Decoders are expected to parse them and ignore chunk types they do not support.

joquarky3• 1 year ago

The Amiga was quite a platform. Glad to know that it had some long term influence.

kfkdjajgjic• 1 year ago

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.

creatonez• 1 year ago

I'm confused what aspect of this you're mad about. MNG is an animated format? Well, Firefox has supported APNG (Animated PNG) for the past 17 years without it ever being standardized and it has become extremely widely adopted. And... this new spec attempts to standardize it.

dveditz_3• 1 year ago

Removed MNG and started work on APNG 20 years ago! https://bugzilla.mozilla.org/show_bug.cgi?id=257197

rynop• 1 year ago

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.

ProgramMax28• 1 year ago

Phoptoshop supports the HDR part. But you are right, it does not support the APNG part.

ProgramMax28• 1 year ago

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.

fwip2• 1 year ago

Do you have any examples on hand of PNGs that use the new features of the spec? It would be cool to see a little demo page with animated or HDR images, especially to download to test if our programs support them yet.

ProgramMax28• 1 year ago

Sure!

Chris Lilley--one of the original PNG co-authors--has a post with an example HDR image: https://svgees.us/blog/cICP.html It is about half way down, with the birthday cake. Generally, us tech nerds have phones that are capable of displaying it well. So perhaps view the page on your phone.

What you should look for is the cake, the pink tips in her hair, and the background being more vivid. For me, the pink in the cake was the big give-away.

There is also the Web Platform Tests (WPT) which we use to validate browser support: https://wpt.fyi/results/png/cicp-chunk.html?label=master&lab...

Although, that image is just a boring teal. See it live in your browser here: https://wpt.live/png/cicp-chunk.html

For an example of APNG, you can use Wikipedia's images: https://en.wikipedia.org/wiki/APNG

But you have a bigger point: I should have live demonstrations of those things to help people understand.

derefr3• 1 year ago

So, I'm a big fan of metaformats with generalized tooling support. Think of e.g. Office Open XML or ePub — you don't need "an OOXML parser" / "an ePub parser" to parse these; they're both just zipped XML, so you just need a zipfile library and libxml.

For the lifetime of PNG so far, a PNG file has almost, but just barely not, been a valid Interchange File Format (IFF) file.

IFF is a great (simple to understand, simple to implement support for, easy to generate, easy to decode, memory-efficient, IO-efficient, relatively compact, highly compressible) metaformat, that more people should be aware of.

However, up to this point, the usage of IFF has consisted of:

• some old proprietary game-data and image formats from the 1980s that no modern person has heard of

• some popular-yet-proprietary AV formats [AIFF, RIFF] that nobody would write a decoder for by hand anyway (because they would need a DSP library to handle the resulting sample-stream data anyway, and that library may as well offer container-format support too)

• The object files of an open but uncommon language runtime (Erlang .beam files), where that runtime exposes only high-level domain-specific parsing tooling (`beam_lib`) rather than IFF-general decoding tooling

• An "open-source but corporate-steered" image format that people are wary of allowing to gain ecosystem traction (WebP — which is more-specifically a document in a RIFF container)

• And PNG... but non-conformantly, such that any generic IFF decoder that could decode the other things above, would choke on a PNG file.

IMHO, this is a major reason that there is no such thing as "generalized IFF tooling" today, despite the IFF metaformat having all the attributes required to make it the "JSON of the binary world". (Don't tell me about CBOR; ain't nobody hand-rolling a CBOR encoder out of template strings.)

If you can't guess by now, my wishlist item for PNGv3, is for PNG files to somehow become valid/conformant IFF files — such that the popularity of PNG could then serve as the bootstrap for a real IFF tooling ecosystem, and encourage awareness/use of IFF in new greenfield format-definition use-cases.

---

Now, I've written PNG parsers, and generic IFF parsers too. I've even tried this exact unification trick before (I wanted an Erlang library that could parse both .beam files and PNG files. $10 if you can guess the use-case for that!)

Because of this, I know that "making PNG valid per IFF" isn't really possible by modifying the PNG format, while ensuring that the resulting format is decodable by existing PNG decoders. If you want all the old [esp. hardware] PNG parsers to be compatible with PNGv3s, then y'all can't exactly do anything in PNGv3 like "move the 4-byte CRC inside the chunk as measured by the 4-byte chunk length" or "make the CRCs into their own chunks that reference the preceding record".

But I'm not proposing that. I'm actually proposing the opposite.

Much of what PNGv2 did in contravention of the IFF spec, is honestly a pretty good idea in general. It's all stuff that could be "upstreamed" — from the PNG level, to the IFF level.

I propose: formalizing "the variant of IFF used in PNG" as its own separate metaformat specification — breaking this metaformat out from the PNG spec itself into its own standards document.

This would then be the "Interchange File Format specification, version 2.0" (not that there was ever a formal IFFv1 spec; we all just kind of looked at what EA/Commodore had done, and copied it in our own code since it was so braindead-easy to implement.)

This IFF 2.0 spec would formalize, at least, a version or "profile" of IFF for which PNGv2 images are conformant files. It would have chunk CRCs; chunk attribute bits encoded for purposes of decoders + editors via meaningful chunk-name letter-casing; and an allowance for some number of garbage bytes before the first valid chunk begins (for PNG's leading file signature that is not itself a valid IFF chunk.)

This could be as far as the IFF 2.0 spec goes — leaving IFFv1 files non-decodable in IFFv2 parsers. But that'd be a shame.

I would suggest going further — formalizing a second IFFv2 "profile" against which IFFv1 documents (like AIFF or RIFF files) are conformant; and then specifying that "generic" IFFv2-conformant decoders (i.e. a hypothetical "libiff", not a format-specific libpng) MUST implement support for decoding both the IFFv1-conforming and the PNGv2-conforming profiles of IFF.

It could then be up to the IFF-decoding-tooling user (CLI command user, library caller) to determine which IFFv2 "profile" to apply to a given document... or the IFFv2 spec could also specify some heuristic algorithm for input-document "profile" detection. (I think it'd be pretty easy; find a single chunk, and if what follows its chunk-length is a CRC that validates that chunk, then you have the PNGv2-like profile. Whereas if it's not that, but is instead four bytes of chunk-name-valid character ranges, then you've got the IFFv1-like profile. [And if it's neither, then you've got a file with a corrupted first chunk.])

---

And, if you want to go really far, you could then specify a third entirely-novel "profile", for use in greenfield IFF applications:

• A few bytes of space aren't so precious; we can hash things much faster these days, with hardware-accelerated hashing instructions; and those instructions are also for hashes that do much better than CRC to ensure integriaty. So either replace the inline CRCs with CRC chunks, or with nested FORM-like container records (WCRC [len] [CRC4] [interior chunk]). Or just skip per-chunk CRCs and formalize a fHsh chunk for document-level integrity, embedding the output of an arbitrary hash algorithm specified by its registered https://github.com/multiformats/multihash "hash function code".

• Re-widen the chunk-name-valid character set to those valid in IFFv1 documents, to ensure those can be losslessly re-encoded into this profile. To allow chunks with non-letter characters to have a valid attribute decoding, specify a document-level per-chunk-name "attributes of all chunks of this type" chunk, that can either be included into a given concrete format's header-chunk specification, or allowed at various points in the chunk stream per a concrete format's encoding rules (where it would then be expected to apply to any successor + successor-descendant chunks within its containing chunk's "scope.") Note that the goal here is to keep the attribute bits in some way or another — they're very useful IMHO, and I would expect an IFF decoder lib to always be emitting these boolean chunk-attribute fields as part of each decoded chunk.

• Formalize the magic signature at the beginning into a valid chunk, that somehow encodes 1. that this is an IFF 2.0 "greenfield profile" document (bytes 0-3); 2. what the concrete format in use is (bytes 4-7). (You could just copy/generalize what RIFF does here [where a RIFF chunk has the semantics of a LIST chunk but with a leading 4-byte chunk-name type], such that the whole document is enclosed by a root chunk — though this is painful in that you need to buffer the entire document if you're going to calculate the root-chunk length.)

I'm just spitballing; the concrete details of such a greenfield profile don't matter here, just the design goal — having a profile into which both IFFv1 and PNGv2 documents could be losslessly transcoded. Ideally with as minimal change to the "wider and weirder/more brittle ecosystem" side [in this case that's IFFv1] as possible. (Compare/contrast: how HTML5 documents are a profile of HTML that supersedes both HTML4 and XHTML1.1 — supporting both unclosed tags and XML-namespaced element names — allowing HTML4 documents to parse "as" HTML5 without rewrites, and XHTML1.1 documents to be transcoded to HTML5 by just stripping some root-level xmlns declarations and changing the doctype.)

ProgramMax28• 1 year ago

Strangely, I was familiar with AIFF and RIFF files but never made the connection that they're both IFF. I hadn't known about IFF before your post. Thank you :)

W3C requires that we do not break old, conformant specs. Meaning if the next PNG spec would invalidate prior specs, they won't approve it. By extension, an old, conformant program will not suddenly become non-conformant.

I could see a group of people formalizing IFFv2, and adapting PNG to it. But that would effectively be PNGIFF, not PNG. It would be a new spec. Because we cannot break the old one.

That might be fine. But it comes with a new set of problems, like adoption.

Soooo I like the idea but it would probably be a separate thing. FWIW, it would actually be nice to make a formal IFF spec. If there was no governing body that owns it, we can find an org and gather interest.

I doubt W3C would be the right org for it. ISO subgroup??

account4250• 1 year ago

We really shouldn't be making new standards with big endian byte order.

It's also questionable how much you actually benefit from common container formats like this since you need to know the application specific format contained anyway in order to do anything useful with it. It also causes problems where "smart" programs treat files in ways that make no sense, e.g. by offering to extract a .docx file just because it looks like a .zip

80x86• 1 year ago

It would be nice if PNG supported no compression. That is handy in many situations.

dave80882• 1 year ago

You’re awesome. Thanks for making things better.

account4250• 1 year ago

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".

This is great but also has the issue that users might not notice that their setup is giving them a less than optimal result. Of course that is probably still better than not having backwards compatibility.

Edit: Seems the backwards compatibility isn't as great as it could be. Old programs show a washed out image instead which sucks. This should have been avoidable in the same way JPG gain maps work so that you only need updated programs to take advantage of the increased gamut on more-than-sRGB screens and not to correctly show colors that fit into sRGB.

ProgramMax28• 1 year ago

PNG Fourth Edition, which we are working on now, is likely to add gain maps.

However, gain maps are extra data. So there is a trade off.

The reason gain maps didn't make it into Third Edition is it isn't yet a formal standard. We have a bunch of the work ready to go once their standard launches.

nabla9• 1 year ago

Does it have any advantage over Lossless encoding in JPEG XL?

ProgramMax28• 1 year ago

Yes, lots.

The big one is adoption. I love JPEG XL and hope it becomes more widely adopted. It is very scary to add a format to a browser because you can never remove it. Photoshop and MSPaint no longer support ICO files, but browsers do. So it makes sense for browsers to add support last, after it is clearly universal. I think JPEG XL is well on their way using this approach. But they aren't there yet and PNG is.

There is also longevity and staying power. I can grab an ancient version of Photoshop off eBay and it'll support PNG. This also benefits archivists.

As a quick side note on that: I want people to think about their storage and bandwidth. Have they ever hit storage/bandwidth limits? If so, were PNGs the cause? Was their site slow to load because of PNGs? I think we battle on file size as an old habit from the '90s image compression wars. Back then, we wanted pixels on the screen quickly. The slow image loads were noticeable on dial-up. So file size was actually important then. But today?? We're being penny-wise and pound-foolish.

LinAGKar• 1 year ago

we'll be researching compression updates for PNG Fifth Edition.

What sort of improvements might we expect? Is there a chance of it rivalling lossless WebP and JPEG XL?

ProgramMax28• 1 year ago

Our first goal is to see what we can get for "free" right now. Most of the time, people save a PNG which is pretty far from optimally compressed. Then they compare that to another format which is closer to optimal and draw a poor comparison.

You can see this with PNG optimizers like OptiPNG and pngcrush.

So step 1 is to improve libpng. This requires no spec change.

Step 2 is to enable parallel encoding and decoding. We expect this to increase the file size, but aren't sure how much. It might be surprisingly small (a few hundred bytes?). It will be optional.

Step 3 is the major changes like zstd. This would prevent a new PNG from being viewable in old software, so there is a considerably higher bar for adoption. If we find step 1 got us within 1% of zstd, it might not be worth such a major change.

I don't yet know what results we'll find or if all the work will be done in time. So please don't take this as promises or something to expect. I'm just being open and honest about our intentions and goals.

Nanopolygon5• 1 year ago

If you are really going to do something new, I recommend that you proceed through a work that is very good at this. For example, HALIC(High Availability Lossless Image Compression). It is both extremely fast and has a very good compression ratio, and memory usage is very very low. There is also very strong Multithread support already. I think something like this would be great for the new PNG. Of course, we don't know what the author of HALIC thinks about this.

NotAnOtter• 1 year ago

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.

spauldo3• 1 year ago

If you don't do much with images it's probably not anything you need to worry about. If you care about things like HDR, it means you can now use PNGs for that. If you work with graphics for a living, it's probably a good idea to learn what's changed in the standard.

PNG was a huge deal when it was new, mostly because of all the headaches Unisys was giving everyone over GIF compression patents. This new standard is mostly of interest to people that have reason to care about what format their image data is in.

jug• 1 year ago

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

ProgramMax28• 1 year ago

Yeah. I mentioned this elsewhere but repeating here:

I designed the article to be accessible and understandable for the average person. So I took some liberties like showing only HDR primaries and not deep diving into HDR transfer functions. People understand the primaries intuitively.

But you are right that a wide color image could also use those same primaries without being HDR.

My goal was to be as truthful as possible while still being digestible at a glance.

In the article, I linked to Chris Lilley's post which explains it more thoroughly for the technical people.

account4250• 1 year ago

Don't forget increased bit depths. You need all of these for a full HDR experience.

nashashmi2• 1 year ago

Time is ripe for audio-included animated PNG files.

bartwe• 1 year ago

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.

4ad• 1 year ago

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.

A new PNG spec

Related Stories