Tuesday, July 1st 2025
PNG Image Format Gets Native Animation and HDR in Version 3.0
Like most of us, you are probably taking your image file format for granted, without much thought about the technology behind it. However, one of the oldest image formats, Portable Network Graphics, aka PNG, has just received its version 3.0 update. After more than two decades of PNG v2.0, image file standards have evolved to meet the diverse needs of internet users who began sharing content such as GIFs online. Back in 2003, PNG 2.0 was insufficient for this purpose, and GIF took over the world of animated raster images. Today, 22 years later, PNG is making a comeback with the introduction of PNG version 3.0, released by the World Wide Web Consortium. Alongside animated raster images, PNG 3.0 is bringing HDR functionality to the image format, using only four (yes, four) additional bytes of overhead.
The PNG format is incredibly adaptable, capable of handling everything from simple graphics with a limited color palette to vibrant, full-color photographs. It's also a top choice for web design because it supports an alpha channel, which enables true transparency in images. PNG was specifically designed for the internet, as it can be streamed, allowing you to see a low-quality version of the picture that sharpens as it finishes loading. It's also a very reliable format, with built-in integrity checks that protect against glitches and corruption during transfer. Additionally, to ensure colors appear the same on your phone as they do on a designer's monitor, a PNG file can include its own color space data. This is why it's so widely used for both standard static images (image/png) and, as of today, even animated ones (image/apng). With HDR now supported, it will allow image sharing in the way it was meant to be seen.
Sources:
W3 Consortium, via Programmax.net
The PNG format is incredibly adaptable, capable of handling everything from simple graphics with a limited color palette to vibrant, full-color photographs. It's also a top choice for web design because it supports an alpha channel, which enables true transparency in images. PNG was specifically designed for the internet, as it can be streamed, allowing you to see a low-quality version of the picture that sharpens as it finishes loading. It's also a very reliable format, with built-in integrity checks that protect against glitches and corruption during transfer. Additionally, to ensure colors appear the same on your phone as they do on a designer's monitor, a PNG file can include its own color space data. This is why it's so widely used for both standard static images (image/png) and, as of today, even animated ones (image/apng). With HDR now supported, it will allow image sharing in the way it was meant to be seen.
35 Comments on PNG Image Format Gets Native Animation and HDR in Version 3.0
- For legacy support use Jpegli encoded JPEGs and Gifsickle encoded Gifs.
- Widest support (for now) and good low quality (low BPP) is avif (both static and animated) ideally encoded using the IQ Tune option in libavif.
- Highest quality and features is JXL for transparency, progressive decoding and animation, although browser support is hampering it big time (doesn't help that low BPP is more desireable by most websites so that's the appealing choice).
If it's for comparing size of lossless files, you can just tell us the results.
Paint supports saving HEIC, but not AVIF or JPEG XL.
But considering how long it took MS to add PNG support in the first place, I wouldn't expect them to support the updated PNG spec anytime soon, perhaps in Windows 15 in 2038?
Not that I think that's a problem though, as anyone can still read AVIF files, and if you're making them, you're not working with MS Paint. Pretty much "anything" support AVIF at this point, incl. Photoshop, Lightroom, GIMP, Darktable, Krita, Paint.NET, ImageMagick, etc.I don't know how old browsers you would recommend people use, but anything except Edge has supported AVIF for years. So I would say anything that's probably is used online supports AVIF.
Gif is a horrible format I wish was abandoned back in 1995.
Lossless compression with transparency is very relevant for anything GUI related (incl. applications and games).
For photos, those who don't need any kind of raw format or do any future heavy editing, will probably do fine with lossy compression like JPEG. But it is worth noting that compression size isn't everything, as different format results in different kinds of compression artifacts;
Some years ago I looked into using JPEG vs. WEBP (and probably others) for textures. It turns out that for ground textures, the compression artifacts of JPEG kind of works in its favor, as it blends in with the graininess of the texture up to a point (as long as you can't see the blockyness). I don't remember now the quality level I considered the sweet-spot (but I probably have it somewhere in my projects). When it comes to smoother surfaces, and probably normal maps etc., blurry artifacts are usually more desirable than grainy/blocky artifacts.
I did some quick tests with AVIF, JPEG XL etc., and the initial findings were interesting, but I finally had time to finish a deeper dive now, and it's a bit of a roller-coaster, so here it comes;
Overall interesting results in the comparison breakdowns and usage cases. I tested AVIF with lossy, but also did preprocess stuff before converting them to a AVIF quality setting to help offset a bit that. I'm not inherently against a bit of lossy compression provided results are acceptable enough when looked at objectively taking into account the other considerations. JPEG XL's compression is surprising. I'll have to maybe look at that at some point and compare the two with the same testing methodologies. It might even be worth looking at compressing first with a JPEG XL pass then doing AVIF on that result if using AVIF to see what happens especially if using lossy AVIF it might stage it for better looking results versus doing so without. Could also like blend the original with JPEG XL in a clever way then compress it with AVIF.
I don't care too much about the details of methodologies if the end result is generally a better looking more compressed image and don't mind some lossy behavior. Lossless is better of course, but I'm certainly not against lossy behavior considerations it's not beneath me to look at the balance trade-offs it can offer.
JPEG XL is pretty impressive outside of it's speed being a little disappointing though much better than OptiPNG which is a train wreck on speed. WebP looks really balanced overall very good general purpose lossy technique. I think if I were aiming for a lossy method to use for various purposes and fairly hands off one to choose I'd settle on JPEG XL or WebP which both are good and it's more a matter of file size and a little bit of compression speed which is less of a consideration overall if you ask so I'd lean towards JPEG XL.
In terms of threading I used a script setup to leverage the cores and threads on my 14700K. My testing was more PNG against AVIF lossy at various quality settings and with a mixture of preprocess tossed in to compare relative output quality of given quality settings. So I was really just comparing file size reduction and also what preprocessing can help nudge relative lossy output quality settings that become more noticeable at the extreme ends of that scale like 1 quality. It was deliberately experimental in nature as far as preprocessing methods and how they work alongside AVIF lossy behavior. The file reduction is great the lossy aspect at the lower quality extremes on the other hand reaches a tipping point in what you can expect from it. I felt like a 50 quality though AVIF holds up shockingly well as a whole though for a lossy image and obviously much more compressed in size. I think it was even at the cusp of reasonable down to around 30% with some of that preprocessing at least and obviously a bit lossy in nature, but felt akin to comparing game screenshots at different resolution settings in essence a bit less detailed as whole in essence.
If you wanted a analogy to what I did with AVIF lossy it's kind of like taking a file image and putting it into a blackhole and testing how much the image details got chewed up the closer to the point of singularity it went with 0 being the point of singularity and 100 the event horizon.
The images were hand-selected to pose different challenges for the encoders. That one in particular is a landscape view, with the upper half basically blurry/sun glare. Image 5 was also a bit blurry from motion blur. The other ones had more grainy details.I tested lossless because the article was about PNG, and I was arguing it was pointless to continue "improving" an obsolete format. I hope you understand I'm not arguing about when to do lossless vs. lossy. The vast majority of photos in private collection are probably lossy, and unless people want to do heavy editing, I don't think lossless photo archives are relevant for most. I mentioned websites and software as use cases where I think lossless is most relevant.I'm actually very curious to see how they stack up at lossy.I find it fascinating that the one picture which was slow with AVIF was fast with JPEG XL.
I haven't looked at lossy JPEG XL, but I want to stress that WebP gets blurry with lower details, and supposedly AVIF is dealing with this better. Old JPEG becomes grainy and blocky as you know, perhaps JPEG XL does too? So it depends on the type of picture you're dealing with.
For me, I would probably lean towards whichever is overall better at both lossy and lossless, even if it's slower at encoding. (Keep in mind I haven't measured decoding speed) My reasoning is for use in software, I rather would like to have one library, not 2 or 3.It may seem like my load numbers are a bit off, I was basing it off gnome-system-monitor. Now repeating it and looking at htop, it clearly illustrates the thread count and load;
avifenc - 1 thread with 100% load
cjxl - 24 threads, 1 with 100% load, the rest idle (!)
cwebp - 1 thread with 100% load
Take a look at this screenshot, I may be using the tool sub-optimally:
BTW, I see cjxl have a setting for "effort", so there may be even better than I've done. (I may have to re-test!)I don't know how to do it yet, but I probably would like both an objective measurement and a subjective evaluation.
But which approach makes the most sense; set a "quality level" and find out where the different file formats gets the closest while keeping as small as possible (so finding a sweet-spot), or setting a desired file size and finding out which is better at that size?
As far as what I did with the lossy AVIF I tested encode/decode speed I ran a batch test of like 50 images, but it was to gauge performance and see if the threading looked like it was working which it seemed to be from what I recall. I then started tested individual outputs at various quality settings to get a idea of the overall lossy behavior and trade offs and feel for acceptable cutoffs points to consider around it.
I then pivoted slightly to adding in some preprocess before the AVIF conversion to see if I could coax the AVIF algorithm into nice results at lower quality settings and seemed to go decently. Overall I think down to maybe 30 quality is around the cutoff area of where it's boarder line though a bit dubious while down to around 50 is reasonable I'd say, but depends how much of a critic you are at the overall detail difference. I feel like down to 50 is similar to looking at a 8 bit display vs a 10 bit display you can tell, but it' a nuanced qualitative difference.
For me I just eye balled the original image against the AVIF and look at that to gauge what to try next on quality settings and compared a bunch and after that started to dabble with preprocess to get better results from lower lossy qualities so that they didn't subjectively degrade as heavily. If you stay above about 50 quality you're unlikely to be too disappointed with the quality difference. It's really once you get down below around 30 quality it starts to nose dive in terms of detail it retains.
Easiest way to compare is just run a sweep test to compare in intervals of like 5 from like 95 to 5 quality.