A new PNG spec

Papua New Guniea never went away!

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

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

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.

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.

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

> 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

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

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

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

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?

That's what OptiPNG already does.

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"

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.

Overshadowed by CSS animations for almost all use cases.

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.

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

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.

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

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

But animated gradient outlines on text is the only use-case I care about.

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

Pleasantly surprised.

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

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

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

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

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

Oh TIL - Thanks!

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

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

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?

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.

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

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.

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

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.

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

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.

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/

That is not backward compatible problem. If a cable that does 100w charging when using pd2.0, but only 60w when using with pd3.1 device, then i would agree with you.

because those usb-c ports do not follow the spec. If they had followed the spec from 1st day there would be no problem even now.

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

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

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

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.

The problem is not backward compatibility but labeling. A USB-C cable looks universal but isn’t. Some of them just charge, some do data, some do PD, some give you access to high speed. But there is no way to know.

I believe the problem here is that you will have PNG images that “look” like you can open them but can’t.

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.

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.

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

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

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

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

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/

the parent said "changing the compression algorithm will break backwards compatibility", which i assume is something works now won't work in the future. The usb-c spec is intentionally trying to avoid that.

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

Cable labeling could fix 99% of the issues with USB-C compat. The solution should never be blaming consumer for buying the wrong cable. Crappy two-wire charge-only cables are perfectly fine for something like a night desk lamp. Keep the poor cables, they are okay, just tell me if that's the case.

Some aren't even USB. Thunderbolt and DisplayPort both use USB-C too.

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?

Today, I can save a PNG file off a random website and then open it.

If PNG gets extended, it's entirely plausible that someone will view a PNG in their browser, save it, and then not be able to open the file they just saved.

There are those who claim "backwards compatibility" doesn't cover "how you use it" - but roughly none of the people who now have to deal with broken software care about such semantic arguments. It used to work, and now it doesn't.

it's vendors just changing the physical port but not updating the electronics. specifically, a 5.1kΩ pull-up resistors on the CC1 and/or CC pins is needed on the host (was usb-a) side in order for the c to c cable to work.

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

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

That's not just an issue with usb-c. normal usb a and b cables can have data or no data depending on how stingy the company wants to be, and you can't know until you test it

JPEG is no different. Only the decoder is specified. As long as the decoder decodes what you give it to the image you wanted to see, you can implement anything. This is how imgoptim/squash/aerate/dietJPG works. By (ab)using this flexibility.

Same is also true for the most advanced codecs. MPEG-* family and MP3 comes to my mind.

Nothing stops PNG from defining a "set of decoders", and let implementers loose on that spec to develop encoders which generate valid files. Then developers can go to town with their creativity.

This is what I fear, too.

Do they mention which C libraries use this spec?

Let's call it PPNG: Pas Portable NetWork Graphic

What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)? I know its not so much about PNG but some future format.

That's what I would call really extensible, but then there may be no limits and hacking/viruses could have easily a field day.

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

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

It's poor, only because Google is using their stranglehold on browsers, to push their own WebP trash. That company can't get broken up soon enough.

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.

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.

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

Oh no another HEIC!

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.

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

> What about an extensible format that would have as part of header an algorithm (in some recognized DSL) of how to decompress it (or any other step required for image manipulation)?

Will sooner or later be used to implement RCEs. Even if you could do a restriction as is done for eBPF, that code still has to execute.

Best would be not to extend it.

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.

> Can animated PNG beat av1 or whatever?

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

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.

Same thing with PNG. Just call the format with new additions it PNGX, so the user can clearly see that the reason their software can’t display the image is not a file corruption.

This is just pretending that if you have a cat and a dog in two bags and you call it “a bag”, it’s one and the same thing…

I honestly don't see an issue with the mpeg-4 example.

Regarding the potential for fragmentation of the png ecosystem the alternative is a new file format which has all the same support issues. Every time you author something you make a choice between legacy support and using new features.

From a developer perspective, adding support for a new compression type is likely to be much easier than implementing logic for an entirely new format. It's also less surface area for bugs. In terms of libraries, support added to a dependency propagates to all consumers with zero additional effort. Meanwhile adding a new library for a new format is linear effort with respect to the number of programs.

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.

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

For animations with lots of regions of solid color it could do very well.

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.

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

> plenty of more advanced competing lossless formats

Other than JXL which still has somewhat spotty support in older software? TIFF comes to mind but AFAIK its size tends to be worse than PNG. Edit: Oh right OpenEXR as well. How widespread is support for that in common end user image viewer software though?

>Display hardware has progressed

It has, but WWW is still de facto sRGB, and will be for a long time still. But again, I'm not strictly opposed to evolving PNG, I just hope they don't ruin it in the process, because that's usually what happens when something gets update for a modern audience. I'll be watching with mixed optimism and concern.

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.

which is what usb-c spec has been avoiding so far. Even in USB4 spec, there are a lot of mentioning the new spec should be compatible with TB3 devices.

USB-C spec is anything but breaking backward compatible.

> Cable labeling could fix 99% of the issues with USB-C compat.

Labelling is a poor band-aid on the root problem - consumer cables which look identical and fit identically should work wherever they fit.

There should never have been a power-only spec for USB-C socket dimensions.

If a cable supports both power and data, it must fit in all sockets. If a cable supports only power it must not fit into a power and data socket. If a cable supports only data, it should not fit into a power and data socket.

It is possible to have designed the sockets under these constraints, with the caveat that they only go in one way. I feel that that would have been a better trade-off. Making them reversible means that you cannot have a design which enforces cable type.

The alternative is the website operator who wants to save on bandwidth instead adopts JXL or WEBP or what have you and ... the end user with old software still can't open it.

It's a dichotomy. Either the provider accommodates users with older software or not. The file extension or internal headers don't change that reality.

Another example, new versions of PDF can adopt all the bells and whistles in the world but I will still be saving anything intended to be long lived as 1/a which means I don't get to use any of those features.

Firefox also doesn’t support JPEG XL out of the box, and Chrome does support the new PNG, so ¯\_(ツ)_/¯.

All valid points, however AV1 also supports lossless compression and is almost certainly going to win the file size competition against APNG every time.

https://trac.ffmpeg.org/wiki/Encode/AV1#Losslessencoding

I never once in 25 years encountered an issue with an mp4 Container that could Not be solved by installing either the divx or xvid codec. And I extensively used mp4's metatdat for music, even with esoteric Tags.

Not Sure what youre talking abouz.

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

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

Plenty of JPGs on the web are already in HDR and you wouldn't notice it if you don't have a HDR capable display. The same is true for PNGs.

> Display hardware has progressed

The continued popularity of non-HDR 1080p screens on laptops is a bleak reminder that most people would rather save a couple hundred bucks than buy HDR capable hardware.

HDR is great for TVs and a nice-to-have on phones (who mostly get it for free because OLEDs are the norm these days), but display technology only advances as much as its availability in low-cost devices.

PNG already supports color profiles, but probably not HDR. I would say that the gamut argument in the article is misleading, you can already encode a wider gamut.

Not sure how HDR encoding works, but my impression is that you can set a nominal white point other than (1, 1, 1) in your specified colorspace. This is an extension, but orthogonal to specifying the colorspace itself and the gamut.

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

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

Once you add more than 256 different colours in total, GIF explodes in terms of file size. It's great for small, compact images with limited colour information, but it can't compete with APNG when the image becomes more detailed than what you'd find on Geocities.

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.

Because your non-smartphone camera doesn't have enough ram/speed to do that I assume (when in burst mode)

If a smartphone camera is doing it, then bad camera app!

There is nothing in display hardware today that TIFF couldn't handle already.

For example 16bit (integer) TIFF files 'with headroom', i.e. where some bits were used to represent data over 1.0 (HDR) was a common approach for VFX work in the 90's.

16bit float TIFF is also thing since 33 years. Adobe DNG is modeled after TIFF. High end offline renderers have traditionally been using TIFF (with mip-maps) to store textures.

TIFF supports tags so primaries and white point or a known color space name can be stored in the file.

The format is so versatile, it is used everywhere.

And of course it also supports indexed color, i.e. a non-negotiable feature at the time PNG was introduced.

PNG was meant to replace GIF. Instead of looking what was already there some group of "experts" and "enthusiasts" (quote Wikipedia) succumbed to their NIH complexes. If licensing/patent woes over compression algorithms had been a motivator, why not just add a new one to TIFF?

The fact that PNG stores straight/unpremultiplied alpha says everything if you know anything about imaging in computer graphics.

And the fact that the updated format spec just released didn't address this tells you everything you need to know about the group in charge of that, today.

PNG is the VHS of image formats. It should have never seen the light day of in the first place nor the adoption it did.

He's saying that in 25 years, you used only the LC and HE profiles, and didn't encounter TwinVQ even once. I looked at my thousand-odd MPEG-4 files. They're overwhelmingly AAC LC, a little bit of AAC LC SBR, no TwinVQ at all.

If you want to check yours: mediainfo **/*.mp4 | grep -A 2 '^Audio' | grep Format | sort | uniq -c

https://en.wikipedia.org/wiki/TwinVQ#TwinVQ_in_MPEG-4 tells the story of TwinVQ in MPEG-4.

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.

That makes sense to me for any image you want to share publicly, but for private images having the location and capture time embedded in the image is incredibly useful.

You can get pretty good guesses just by feel and length. Tiny with a super thin cable? Probably charge only.

Thunderbolt meets usbc specs (and exceeds them afaik), so it is still usb...

Most modern camera modules have built in hardware codecs like mjpeg, region of interest selection, and frame mirror/flip options.

This is particularly important on smartphones and battery operated devices. However, most smartphone devices simply save the photo the same way regardless of orientation, and simply add a display-rotated flag to the metadata.

It can be super annoying sometimes, as one can't really disable the feature on many devices. =3

So since my vape (example, i dont vape) has a power and data slot for charging and firmware updates, i should be limited to only using dual purpose cables day to day rather than a power only cable?

But where the analogy with USB-C is very good is that just like USB-C, there is no way for a user to tell from the look of the port or the file extension what the capabilities are. Which even for a fairly tech savvy user like me is frustrating. I have a bunch of cables, some purchased years ago, how do I know what is fit for what?

And now think of the younger generation that has grown up with smartphones and have been trained to not even know what a file is. I remember this story about senior high school students failing their school tests during covid because the school software didn't support heif files and they were changing the file extension to jpg to attempt to convert them.

I have no trust the software ecosystem will adapt. For instance the standard libraries of the .net framework are fossilised in the world of multimedia as of 2008-ish. Don't believe heif is even supported to this day. So that's a whole bunch of code which, unless the developers create workarounds, will never support a newer png format.

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.

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

Not entirely true, it depends on what's being displayed, see a few simple tests specifically constructed to show how much better APNG can be vs GIF and {,lossy} webp: http://littlesvr.ca/apng/gif_apng_webp.html

Of course I don't think it generalizes all that well…

> [not] Officially supports Exif data

How can you call this basic fail a success?

Parallel compression/decompression is already possible via Z_SYNC_FLUSH.

Video files aren't a good analogy. Before God placed VLC and ffmpeg on earth, you had to install a galaxy of codecs on your computer to get a chance to read a video file and you could never tell exactly what codec was stored in a container, nor if you had the right codec version. Unfortunately there is no vlc and ffmpeg for images (I mean there is, the likes of imagemagick, but the vast majority of software doesn't use them).

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

> If a cable supports only power it must not fit into a power and data socket

That's even more confusing than the current state of affairs. If my phone has power and data socket, then I cannot use power only cable to only charge it? Presumably with the charger that has power only socket. So I need a cable with two different ends anyway. Just go micro-USB at this point :)

Funnily enough, there is a 100% overkill way to solve such issues. Just use super expensive certified TB cables. Well... plus a A-to-C adapter for noncompliant devices, I guess.

If by private you mean "never shared", I agree.

I don't see why? If your video output is plain old RGB (like the Amiga hardware), then an unmodified decoder will handle new files without a problem. You only need a new decoder if your video output can handle more vivid colours than RGB can express.

It's a new and compatible spin. https://svgees.us/blog/img/revoy-cICP-bt.2020.png uses the important new feature and your old software can display it.

More generally, PNG has a simple feature to specify what's needed. A file consists of a number of chunks, and one bit in the chunk specifies whether that chunk is required for display. All of the extensions I've seen in the past decades set that bit to "optional".

For example, this update includes a chunk containing EXIF data. As you'd expect, the exif chunk sets that bit to "optional".

False, or misleading.

The AV1 spec [1] does not allow RGB color spaces, therefore AV1 cannot preserve RGB animations in a bit-identical fashion.

[1] https://aomediacodec.github.io/av1-spec/av1-spec.pdf

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

Rotation for speed/efficiency/compression reasons (indeed with PNG's horizontal line filters it can have a compression reason too) should have been a flag part of the compressed image data format and for use by the encoder/decoder only (which does have caveats for renderers to handle partial decoding though... but the point is to have the behavior rigorously specified and encoded in the image format itself and handled by exactly one known place namely the decoder), not part of metadata

It's basically a shame that the exif metadata contains things that affect the rendering

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.

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

> So since my vape (example, i dont vape) has a power and data slot for charging and firmware updates, i should be limited to only using dual purpose cables day to day rather than a power only cable?

Well, yes.

Why can't you use a power+data cable for the vape (or whichever appliance takes both)? What's the deal-breaker here?

The alternative is labeling, or plugging cables in to see if they do what you want them to do.

Both are a poor user interface.

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

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

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.

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.

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

>The format is so versatile, it is used everywhere.

Yeah, I love the fact that you can embed a PDF file inside a TIFF.

You said that's not really true and the described exactly how it's true, what did you mean?

Doesn't OptiPNG just brute force various settings and pick the best result?

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.

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

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

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.

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.

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

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?

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.

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

I thought this was about Papua New Guinea.

Not all businesses are attempting to reach a market of "every internet user globally".

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

I tried these examples on ezgif, and indeed apng manages to be smaller than webp every single time. Weird, I was under the impression that webp was almost always smaller? Is this because GIF images are already special, or apng uses better compression than png?

edit: using the same ezgif webp and apng on a H.264 source, apng is suddenly 10x the size than webp. It seems apng is only better if the source is gif

Can the 5% view images at all? The number of web crawlers have exploded recently.

One interesting thing about JPEG is that you can rotate an image with no quality loss. You don't need to convert each 8x8 square to pixels, rotate and convert back, instead you can transform them in the encoded form. So, rotating each 8x8 square is easy, and then rotating the image is just re-ordering the rotated squares.

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

That's not how it works.

The server declares what versions of media it has, and the client requests a supported media format. The same trick have been used for audio and video for ages too.

Example:

    <picture>
        <source srcset="a.webp" type="image/webp">
        <img src="fallback.jpg">
    </picture>

Maybe they offer alternatives to webp for those 5% ?

See CSS image-set : https://developer.mozilla.org/en-US/docs/Web/CSS/image/image...

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

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.

the main reason is probably that the chip is already outputting the image in a lossy format, and if you reorder the pixels you must reencode the image which means degrading the image, so it's much better to just change the exif orientation.

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

I can tell you, I have personally worked with a global corporation and we estimated that for one of their websites, supporting the 3% that we exclude by using “modern standards” would be more costly than the amount of revenue they get from them. So in that case, it was a rational decision. And up to the 10% cut, management just didn’t want to do the extra investment. So if something falls below that 10% threshold, they just don’t care to get it fixed.

This problem was solved by HTTP since forever. Client sends `Accept` header with supported formats and server selects the necessary content with corresponding `Content-Type` header. You don't need any HTML tags for it.

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

Not backwards compatible I think

What about file extensions?

"Use case" is written without hyphen https://en.m.wikipedia.org/wiki/Use_case

> there is no way for a user to tell from the look of the port or the file extension what the capabilities are

But that's typical for file extensions. Consider EXE – it is probably an executable, but an executable for what? Most commonly Windows – but which Windows version will this EXE run on? Maybe this EXE only works on Windows 11, and you are still running Windows 10. Or maybe you are running x86-64 Windows, but this EXE is actually for ARM or MIPS or Alpha. Or maybe it is for some other platform which uses that extension for executable files – such as DOS, OS/2, 16-bit Windows, Windows CE, OpenVMS, TOPS-10, TOPS-20, RSX-11...

.html, .js, .css – suggest to use a web browser, but don't tell you whether they'll work with any particular one. Maybe they use the latest features but you use an old web browser which doesn't support them. Maybe they require deprecated proprietary extensions and so only work on some really old browser. Maybe this HTML page only works on Internet Explorer. Maybe instead of UTF-8 it is in some obscure legacy character set which your browser doesn't support.

.zip – supports extensible compression and encryption methods, your unzip utility might not support the methods used to compress/encrypt this particular zip file. This is actually normal for very old ZIP files (from the 1980s) – early versions of PKZIP used various deprecated compression mechanisms, which few contemporary unzip utilities support. The format was extended to 64-bit without changing the extension, there's still a lot of 32-bit only implementations out there. ZIP also supports platform-specific file attributes–e.g. PKZIP for z/OS creates ZIP files which contain metadata about mainframe data storage formats, unzip on another platform is going to have no idea what it means, but the metadata is actually essential to interpreting the data correctly (e.g. if RECFM=V you need to parse the RDWs, if RECFM=F there won't be any)

.xml - okay, it is XML – but that tells you nothing about the actual schema. Maybe you were expecting this xml file to contain historical stock prices, but instead it is DocBook XML containing product documentation, and your market data viewer app chokes on it. Or maybe it really is historical stock prices, but you are using an old version of the app which doesn't support the new schema, so you can't view it. Or maybe someone generated it on a mainframe, but due to a misconfiguration the file came out in EBCDIC instead of ASCII, and your app doesn't know how to read EBCDIC, yet the mainframe version of the same app reads it fine...

.doc - people assume it is legacy (pre-XML) Microsoft Word: every version of which changed the file format, old versions can't read files created with newer versions correctly or at all, conversely recent versions have dropped support for files created in older versions, e.g. current Office versions can't read DOC files created with Word for DOS any more... but back in the 1980s a lot of people used that extension for plain text files which contained documentation. And it was also used by incompatible proprietary word processors (e.g. IBM DisplayWrite) and also desktop publishing packages (e.g. FrameMaker, Interleaf)

.xmi – I've seen this extension used for both XML Model Interchange (XML-based standard for exchanging UML diagrams) and XMIT (IBM mainframe file archive format). Because extensions aren't guaranteed to be unique, many incompatible file formats share the same extension

.com - is it an MS-DOS program, or is it DCL (Digital Command Language)?

.pic - probably some obscure image format, but there are dozens of possibilities

.img – could be either a disk image or a visual image, either way dozens of incompatible formats which use that extension

.db – nowadays most likely SQLite, but a number of completely incompatible database engines have also used this extension. And even if it is SQLite, maybe your version of SQLite is too old to read this file because it uses some features only found in newer versions. And even if SQLite can read it, maybe it has the wrong schema for your app, or maybe a newer version of the same schema which your old version that app doesn't support, or an old version of the schema which the current version of the app has dropped support for...

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

Maybe the issue is with your operating system then?

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

You can't even upload webp to instagram.

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

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

Which makes sense for an app made for photos: why would you capture a photograph to disk in a format made for distributing on the web?

I have no idea! I actually hoped someone would show a much more comprehensive and serious benchmark in response, but that has failed to materialize.

App support has very little to do with the operating system. OSes by and large will preview it just fine.

Indeed, why might one upload a photo to the web in a format made for distributing images on the web?

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?

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

Sometimes respected, largely ignored. URLs very often don't map directly to files served.

File extensions are just a hint about what the file might be and have nothing to do with what the file actually is. If the server sets the MIME type, the browser will use that as the hint.

But even beyond that, most file formats have a bit of a header at the start of the file that declares the actual format of the file. Browsers already can understand that and use the correct render for a file without an extension.

Not even Google supports webp uploads in many of their web apps, and it's their format.

Yes, but it's 2% that are still using browsers without full support for WebP according to caniuse, which takes its numbers from StatCounter.

https://caniuse.com/webp

Note that I'm looking at "all tracked," which excludes 2% "other" browsers in the data whose featureset is not known.

Just last week I had again some PDFs Okular could not open because of some more uncommon form features.

TIL, and hard agree (on face value). I’ve been struck by this with arbitrary rotation of images depending on application, very annoying.

What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.

Any industry.

e.g. cars - not everyone is physically able to drive books - blind people can't read music - deaf people can't hear

It is a form of 80/20 or 90/10 rule the last small percentage costs as much as the majority.

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

on the contrary. on macOS apps don't have to support image (or movie) formats. it is done by the system and transparently handled by the APIs. apps automatically gain new formats when the system adds it.

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

The unfortunate side effect of this convenience is that apps automatically lose image support when macOS chases to no longer support them, too.

One example is Sony's SRF camera raw format.

Programs like Photoshop and Affinity have to bring their own decoders where previously none were required.

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

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

If you are using an image optimization service like Imgix / Cloudflare Image Resizing then it doesn't really matter, image can be uploaded as any supported format and will be sent to the end user according to their "Accept" header

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.

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.

And having to bring in support for formats that are deprecated by the OS, if they decide to keep supporting that format as there is sufficient demand from their users, is worse than having to bring in support for all formats rather than getting support from the OS?

Having ask that in a slightly confrontational way, one of the reasons I started using VLC all those years ago, and still use it to this day, was having trouble with other media players that relied on OS support fail to work well (or at all) with some codecs, while VLC brought support for them, and their dog, built-in and reliable. Dragging your own format support libraries with you can be beneficial.

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

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?

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!

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

An image decoded in the wrong colour space for the output will look wrong. It is not using extra bits to express the increased dynamic range: the existing numeric range is stretched and warped.

Could it be a lack of resources? Or some missing expertise? Maybe they could find some interns who are familiar with it? Maybe the entire world is so obsessed w AI, we don't even care about image formats anymore.

You can't use webp on Reddit, Instagram, and hundreds of other websites. Which is ironic because some of them serve images as webp.

Instagram hasn't even been primarily or even secondarily about photos for a long time. Indeed trying to "just" upload a photo is made super inconvenient these days.

I meant Windows, as macOS and Linux are usually good with modern things. It’s trivial to add the support if you don’t have it. I have no idea about Windows, but I got this vibe of someone using Win7 in 2025 and complaining the world moved on and keeps moving on.

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

That doesn’t mean it’s dead, it rather shows sheer incompetence of the web dev departments of these wonderful companies for whom webp or avif aren’t images, I guess.

I can't believe the standard is 20yo.

> it was a rational decision. And up to the 10% cut, management just didn’t want to do the extra investment

Rational, or economical? I find it rational to help someone in need since I'd want others to do the same to me, even if it's not financially profitable for me. Imo more factors flow into what's rational, but I understand what you mean by corporate greed working this way (less than 10% of people are blind, neither male nor female, run a free operating system or can't afford a new computer, etc., so yep they're not profitable groups and for-profits don't optimise for that)

Or convert before you upload because the image host has delusions about fighting the Google monoculture by refusing WebP support. Even more of a head scratcher when WebM is their only video format.

No, cause thats just one of the features.

Images are often at different resolutions too, that way, depending on the pixel density of the device, and the physical size, the browser can select the photo that has high enough resolution, but not one that is needlessly large, while also selecting the preferred image format.

> 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

People crammed exif data into PNGs anyway, and now they can continue to do that but in conformance with the spec.

Blame Adobe. For what they charge for Creative Suite it ought to have supported it a long time ago.

My webcrawler sucks down a lot of WebP images, at least it did before it got the smackdown from Cloudflare.

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

Instagram's image uploading interface is klunky compared to Mastodon which is entirely unfunded.

Just tested reddit. It works fine with .webp I don't have an instagram account

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

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.

Adobe Photoshop has support for WebP (through "Save as", not "Export") but I don't think WebP is important.

> What are the arguments for this? It would seem easier for everyone to rotate and then store exif for the original rotation if necessary.

Performance. Rotation during rendering is often free, whereas the camera would need an intermediate buffer + copy if it's unable to change the way it samples from the sensor itself.

Honestly this kind of stuff happens all the time in large companies.

Interns won't want to work on a dead end like this. Moreso they need to be supervised by someone that doesn't want to get removed by being the lowest X% usefulness in a company. So all these existing tools that aren't primary revenue generators just sit on coast mode.

Try https://www.reddit.com/settings/profile

There are so many uneven areas of Reddit where WebP doesn't work. Old reddit, profile support, mod tools, etc.

I lived through that era (first K-Lite Codec Pack, then CCCP came along), but still it holds.

Proprietary or open, any visual codec is a battleground. Even in commercial settings, I vaguely remember people saying they prefer the end result of one encoder over another, for the same video/image format, not unlike how photographers judge cameras by their colors.

So maybe, this flexibility to PNG will enable or encourage people to write better or at least unorthodox encoders which can be decoded by standard compliant ones.

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

This shows the unfortunate power of distribution.

It doesn't matter if the alternative is technically superior once the majority use the mainstream thing.

But it can’t open them

Because PNGs won't answer back when I call them by some "correct" name.

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

How is rotation during rendering free?

Not sure if that's version specific, but my one can (version 26.7.0) without any issues or warnings. Tried with this sample file: https://www.gstatic.com/webp/gallery/1.webp

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.

Depends...

You'll commonly call someone by their pronounced name out of respect, forced or given.

In a situation where someone does something really stupid or annoying and the forced respect isn't there, most people don't.

You are using the notion of rationality wrong. Rational reasoning can only help you find how to achieve goals that align with your values. It is strictly worthless in choosing your values.

If a corporation has determined that profit maximization is their core tenet, excluding the needs of a minority of users can likely be deduced in a rational manner from that tenet. That is precisely why values need to be forced onto corporate actors through regulation, e.g. in this case through mandatory accessibility guidelines like EU directive 2019/882 that enters into force this very week.

How do you pronounce PNG?

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

Yes JPEG-XL has an alpha channel.

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.

The 50 4E 47 spells "PNG"

Those are indeed the "magic" bytes of PNG. It's a very clever choice meant to ensure the transport layer didn't mess with it.

To start, there's a byte with the upper bit set which ensures an "8-bit clean" transport. If it's stripped, it becomes a harmless tab. Then the literal "PNG" text so you can see it in a text editor. Then a CR-LF pair to check for CR-LF to LF translations. Then, a CTRL-Z to stop display on DOS-like systems. And finally, another LF to check for LF to CR-LF translations.

It's a clever "magic" that basically ensures a binary transport layer. Things that mattered back in 1996.

https://www.libpng.org/pub/png/spec/1.2/PNG-Rationale.html#R...

Looks Photoshop has since v23.2 in 2022.

> People that create things get to name them.

And if they pick something dumb enough other people get to ignore them.

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?

Doesn't pico-8 store the data in the least significant bits of colour? Maybe it got updated to use chunks.

> Consider EXE – it is probably an executable, but an executable for what? Most commonly Windows

Has anyone ever used .exe for anything other than Windows?

I have to differentiate myself from LLMs by using words wrong though

> 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

Pee En Gee

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.

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?

P&G, stands for Pee & Gloat.

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

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.

Seems that logic does not apply to jpeg though.

I was about to write that Slack doesn't support webp but I just tested it and it does. For years I have been typing "convert file.webp file.jpg" and then posting that in slack but it looks like they have added support.

if you’d like to go and implement that in all the millions of existing web apps, go ahead?

Let’s also not forget the dependency mess that leaves in applications before we do though..

Pretty much every pixel rendered these days was generated by a shader so gpu side you probably already have way more translation options than just a 90° rotation (likely already being used for a rotation of 0°). You'd likely have to write more code cpu side to handle the case of tell the gpu to rotate this please and handle the UI layout diffrence. Honestly not a lot of code.

Portable & Graphical

The biggest driver of adoption are features.

"WebP is used by 16.7% of all websites. This means that while it's a popular image format, it's not yet the dominant format, with JPEG still holding the majority share at 73.0%, according to W3Techs. However, WebP offers significant advantages in terms of compression and file size, making it a preferred choice for many web developers. "

That doesn't seem to apply to images that aren't multiples of 8 in size, does it?

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 )

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.

Linguistic prescriptivism is wrong, and people who promote it are showing they have zero respect for others when they don't have to.

Is this a bit?

I agree that language is fluid. However, when it comes to names, I think people should have enough respect to pronounce things how the creator (or owner, depending on the situation) of the name says it should be pronounced. Too often people will mispronounce someone's name as a sign of intentional disrespect (see Kamala Harris for a fairly recent prominent example) and I cannot get behind that. You see a similar disrespect in the hard-soft discourse around the pronunciation of GIF. A lot of people use the hard g and mock the creator for thinking that soft g should ever have been right.

Naming is probably one of the few language areas that I think should be prescriptive, even while language at large is descriptive.

20 years?? What took so long.

I agree with the point you're trying to make, but your examples are terrible. Music industry doesn't have too much to do to help deaf people. It's not like they're deliberately making deaf-inaccessible music instead of relying on the old good deaf-accessible music formats.

(Also, the parent comment's example is also not so good because as someone else pointed just because the top 25% websites are serving webp it does mean they're not serving alternative formats for those who does not support it, as this is quite trivial to setup)

Absolutely not. See my response to your sibling comment. Choosy nerds choose "GIF".

Maybe using VLC Media Player from an early age has left me with too high expectations. But if I have a program designed to view or edit a certain class of file, and it doesn't support a certain file format, I will blame that program.

Unless you're uploading memes you've downloaded from elsewhere, this strictly isn't true. I'd consider myself an Instagram power user and the only thing that I and all the people I interact with is photos and videos. None of those are webp, or would have been worthwhile to save as webp as an intermediate format.

Way back when, my prof was using his Linux machine to demonstrate how to use GCC. He called the end result .exe but that might have been for the benefit of the Windows users in the room. (Though Linux users being considerate to Windows users, or vice versa, is admittedly a rarity)

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

are there any cameras that take pictures that are not a multiple of 8 in width and height?

A parent may name their baby Elizabeth. Then even the parent might call them Liz or Beth or Betsy or Bit or Bee.

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

I don’t think technical standards merit the same level of “deference to the creator” as personal names. People are wrong about standards they created all the time (ask me what I think about John Gruber’s “stewardship” of Markdown) and should be corrected, a standard is meant for all. Obviously the pronunciation of an acronym isn’t anywhere near as important as technical details, but I think the principle holds.

How about renaming JPEG XL to PNG or just merging the complete spec into PNG 3.0?

I could save my photos as BMPs like early digital cameras did but that doesn't make it practical or reasonable. My camera takes pictures as RAW or HEIF files. Why would I save my photos to a primarily lossy codec that's optimized and designed for distribution rather than preserving fidelity?

We used to do this with JPEG, in fact. And that's why many pictures on Facebook from pre-2018 or so all have a distinctive grainy look. It's artifacts on top of artifacts. Storage on phones isn't tight anymore, we don't need to store photos in a format meant to minimize bytes at the expense of quality.

"Pong". Hate me, I don't care.

If the creator insists on a weird pronunciation, because of an inside joke most won't ever get, then I feel no responsibility in humoring them.

The G in gif is for graphics. Not 'giraffics'. And most people in the world have no idea what Jif even is, much less a particular catchphrase from an old ad campaign that barely even connects.

As much as I hate jif, thinking about it, "GPU" works the same - we say gee-pee-you and not gh-pee-you. Garbage Collection is also gee-cee. So it's only logical that jif is the correct one - even if it's not the widely accepted one.

Wrt/ communication, aside from personal preference, one can either respect the creator, or the audience. If I stand in front of 10 colleagues, 10 out of them would not understand jif, or would only get it because this issue has some history now. gif on the other hand has no friction.

Ghengis Khan for example sounds very different from its original Mongolian pronunciation. And there is a myriad others as well.

pronounce the jraphics interchange format any way you want, everyone knows what you're talking about anyway -- try not to get so worked up. It's not the shopping cart problem, because no-one is measurably harmed by not choosing the same pronunciation as you.

But there is no standardization of sidecar files, no? Whereas EXIF is pretty standard.

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

I used to call them Nogs claiming the P was silent.

People believed me. Still funny.

why not? that's up to the program displaying the animation, not the animation itself -- i'm sure a pausable gif or apng display program is possible

I'm convinced that this is because of the prevalent MVP culture in modern software engineering. Instead of holistically looking at a new feature request such as "support webp images" we break it down into parts (e.g. "serve webp" "accept webp upload here" "accept webp upload there") and then we call it a MVP when only the highest priority items are done.

EXIF inside of PNGs is new. You can make it work by embedding structured chunks into the file, but it's not official in any way (well, not until the new spec, at least). Sidecar files have some kind of interoperable format that at least don't break buggy PNG parsers when you open the image file. The sidecar files themselves differ in format, but at least they're usually formatted according to their extension.

The usual sidecar files, XMP files, are standardised (in that they follow a certain extensible XML structure) and can (and often do) include EXIF file information.

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.

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

Prior to Windows 95, the vast majority of PC games were MS-DOS exe files – so anyone who played any of those games (whether back in their heyday, or more recently through DOSBox) has run an MS-DOS exe. Most people who ever used Lotus 1-2-3 or WordPerfect were running an MS-DOS exe. Both products were eventually ported to Windows, but were far less popular under Windows than under DOS.

Under Windows 95/98/Me, most command line tools were MS-DOS executables. Their support for 32-bit Windows console apps was very poor, to the extent that the input and output of such apps was proxied through a 16-bit MS-DOS executable, conagent.exe

First time in my life I ever used GNU Emacs, it was an OS/2 exe. That's also true for bash, ls, cat, gcc, man, less, etc... EMX was my gateway drug to Slackware

For anything GPU-rendered, applying a rotation matrix to a texture sample and/or frame-buffer write is trivially cheap (see also why Vulkan prerotation exists on Android). Even ignoring GPU-rendering, you always are doing a copy as part of rendering and often have some sort of matrix operation anyway at which point concatenating a rotation matrix often doesn't change much of anything.

Everything I've tried supports WebPs. It took Adobe a while but even Photoshop supports the format these days.

Hell, for some software features (like stickers in some chat apps), WebP is mandatory.

HEIFF files, on the other hand...

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.

I was referring to the new PNG, not to JPEG XL.

the stored image is always a multiple of 8, with padding that is ignored (and heavily compressed).

AV1 supports YCoCg, which encodes RGB losslessly.

It is a bit-reversible rotation of the RGB cube. It makes the channels look more like luma and chroma that the codec expects.

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

I would agree we will see less improvements that when comparing modern jpeg implementation and the reference one.

When it comes to hardware encoding/decoding, I am not following your point I think. The fact that some are already looking at hardware implementation for JPEG XL means that….?

I just know JPEG hardware acceleration is quite common, hence I am trying to understand how that makes JPEG XL different/better/worse?

we need transparent (like gif)

!!!

It's absolutely possible. Browsers even routinely pause playback when images aren't visible on screen.

They just don't have a proper UI and JS APIs exposed, and there's nothing stopping them from adding that.

IMO browsers are just stuck with tech debt, and maintainin a no-longer-relevant distinction between "animations" and "videos". Every supported codec should work wherever GIF/APNG work and vice versa.

It's not even a performance or complexity issue, e.g. browsers support AVIF "animations" as images, even though they're literally fully-featured AV1 videos, only wrapped in a "pretend I'm an image" metadata.

Is there any risk that if I open a JPEG-XL in something that knows what a JPEG is but not what a JPEG-XL is and then save it, it'll get lossy compressed? Backwards compatibility is awesome, but I know that if I save/upload/share/copy a PNG, it shouldn't change without explicit edits, right?

No, APNG explodes in size in that case.

In APNG it's either the same 256 colors for the whole animation, or you have to use 24-bit color. That makes the pixel data 3 times larger, which makes zlib's compression window effectively 3 times smaller, hurting compression.

OTOH GIF can add 256 new colors with each frame, so it can exceed 256 colors without the cost of switching all the way to 16.7 million colors.

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

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

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.

Looking at TFA, it's placing in the spec a few things that are already widely stacked onto the format (such as animation). This is a very sensible update, and backwards compatible with existing PNG.

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.

Society wholeheartedly thanks Google for saving costs for Google

Slight nitpicking, but you can rotate in 90° increments without loss.

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