PNG Image Format Gets Native Animation and HDR in Version 3.0

[lexluthermiester]

PNG is equal to BMP quality without just literally wasting diskspace for no reason though.

Is it? I can't remember where, but there was an article I read discussing the techspecs of the format and it stated that PNG, though close, was inferior to BMP. It gave the technical reasons why and they seemed reasonable.

 

[R-T-B]

Is it? I can't remember where, but there was an article I read discussing the techspecs of the format and it stated that PNG, though close, was inferior to BMP. It gave the technical reasons why and they seemed reasonable.

It's a lossless RGB stream, I really don't see how it couldn't be equal in quality. It's a little slower to decode but that was relevant in the 486 era, not at all with todays cpus.

 

[lexluthermiester]

It's a lossless RGB stream, I really don't see how it couldn't be equal in quality. It's a little slower to decode but that was relevant in the 486 era, not at all with todays cpus.

Fair enough. Still prefer progressive coded JPGs..

 

[Mine18]

Why should we continue to expand on dead-end formats?
PNG uses the generic and obsolete Deflate algorithm.

It's time to move on to AVIF (or if there are better alternatives?).

IMO websites should only use 3 (or 4) formats:

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

 

[R-T-B]

Fair enough. Still prefer progressive coded JPGs..

Hey man thats part of what makes the PC great, choice, so as long as people don't start posting litetal .bmp spam not going to judge anyones format beyond "great, enjoy."

 

[efikkan]

Had some example comparisons, but apparently AVIF uploads don't work on forums atm. On the AV1 and codec yeah hopefully, but for now it still needs to gain a better footing as a standard like even MS Paint doesn't allow AVIF export yet though it can import AVIF images fine and pretty common issue with software atm non existent or partially supported for the time being.

Sure, if it's for comparing quality of lossy compression.
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.

IMO websites should only use 3 (or 4) formats:
- 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).

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.

 

[efikkan]

@InVasMani
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;

Spoiler

This test only focuses on lossless compression.

First test case:
Firstly, I wanted to check some images of medium-to-hard compression difficulty, so I figured game screenshots was a good source. The screenshots I found online already had compression artifacts in them (even PNGs), so I ended up making some myself just to give the algorithms a chance to shine. (And it turns out I haven't gotten many games the past few years , so AoE II and C&C remastered it is, along with some Unigine benchmarks.)
All very large images; 3480x2160, 24bpp.

Compression comparison:

	PNG	OptiPNG	WebP	AVIF	JPEG XL
Image1 - AoE II Rem.	17078937	15124685	13798112	16122545	16114673
Image2 - C&C Rem.	13867871	13777863	10791384	10307663	10001043
Image3 - Unigine Sup.	11205027	11134088	9541984	8356204	7839086
Image4 - Unigine Valley	7586407	7235039	5951946	5407012	5243487
Image5 - Unigine Valley	10314065	10111339	8069364	7709303	6860860
		4.44%	19.82%	20.23%	23.30%

Then I compared compression speed (converting from PNG):

	OptiPNG	WebP	AVIF	JPEG XL
Image1	165.083 s	6.21 s	5.405 s	21.335 s
Image2	180.848 s	4.543 s	5.153 s	15.701 s
Image3	237.349 s	4.85 s	5.612 s	14.588 s
Image4	426.164 s	4.706 s	12.871 s	8.996 s
Image5	294.696 s	4.797 s	5.101 s	13.095 s

Tested on a Ryzen 9 5900X 12C/24T 3.7/4.8 GHz stock. All using CLI tools: cwebp, avifenc, cjxl and optipng. Most tools seemed to spawn threads, but didn't manage to saturate the CPU more than ~4-4.3x a single core.

Then when validating my results I discovered to my big disappointment that quality level 100 (which is claimed to be lossless) is just very close to lossless, but only the parameter --lossless truly is, so rerunning avifenc with that results in images as big as PNG. So that's a complete failure on AVIF in my opinion. I validated the results using image-magick to give me the pixel differences.

Second test case:
I also did a second test case, where I just picked a bunch of assets from my old projects; backgrounds, sprites and GUI elements, mostly simpler stuff, things we should expect PNG to compress very well already. The intention here is to emulate a use case for anyone hosting a website, making an app or a desktop application/game, where there typically are some assets that needs to be lossless. I'm not going to show individual files here, this is just to give an indication.

Aggregated results:

OptiPNG:	WebP:	AVIF:	JPEG XL:
8.33%	37.31%	-2.46%	33.95%

Keeping in mind once again the results for AVIF here are invalid, but I included it to showcase how surprisingly bad it performs in simpler images. Looking at individual images, it actually performed worse the "simpler" the image is.

Most impressive here is WebP, which managed to compress already heavily compressed PNGs much further. I observed up to 93% reduction in size vs. PNG. Also worth noting is that especially for the simplest images (typically GUI elements), where is typically where we see OptiPNG help a lot, you'll get around 30-40% compression on top of what OptiPNG can achieve, so depending on the types of assets you have, this can make a difference.

Conclusions:
- JPEG XL and WebP will achieve ~20% reduction for detailed pictures and significantly more for "simpler" pictures over PNG.
- Both JPEG XL and WebP achieve similar results overall, but results will favor one or the other depending on the picture type.
- Both JPEG XL and WebP are much faster and yield better results than using OptiPNG. (I have also seen OptiPNG yield corrupted results in the past, so you need to verify the results.)
- There may be further parameters to yield even better results under specific conditions for these formats.
- AVIF is a disappointment for lossless compression, thanks to it's normal "lossless" setting not being lossless.
- Differences can be quite significant for hosts of websites and distributers of software.
- Lossy compression isn't tested, and may paint a very different picture. (and I don't even know yet how to do a fair comparison).

Further exploration is encouraged.

 

[lexluthermiester]

@InVasMani
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;

Spoiler

This test only focuses on lossless compression.

First test case:
Firstly, I wanted to check some images of medium-to-hard compression difficulty, so I figured game screenshots was a good source. The screenshots I found online already had compression artifacts in them (even PNGs), so I ended up making some myself just to give the algorithms a chance to shine. (And it turns out I haven't gotten many games the past few years , so AoE II and C&C remastered it is, along with some Unigine benchmarks.)
All very large images; 3480x2160, 24bpp.

Compression comparison:

	PNG	OptiPNG	WebP	AVIF	JPEG XL
Image1 - AoE II Rem.	17078937	15124685	13798112	16122545	16114673
Image2 - C&C Rem.	13867871	13777863	10791384	10307663	10001043
Image3 - Unigine Sup.	11205027	11134088	9541984	8356204	7839086
Image4 - Unigine Valley	7586407	7235039	5951946	5407012	5243487
Image5 - Unigine Valley	10314065	10111339	8069364	7709303	6860860
		4.44%	19.82%	20.23%	23.30%

Then I compared compression speed (converting from PNG):

	OptiPNG	WebP	AVIF	JPEG XL
Image1	165.083 s	6.21 s	5.405 s	21.335 s
Image2	180.848 s	4.543 s	5.153 s	15.701 s
Image3	237.349 s	4.85 s	5.612 s	14.588 s
Image4	426.164 s	4.706 s	12.871 s	8.996 s
Image5	294.696 s	4.797 s	5.101 s	13.095 s

Tested on a Ryzen 9 5900X 12C/24T 3.7/4.8 GHz stock. All using CLI tools: cwebp, avifenc, cjxl and optipng. Most tools seemed to spawn threads, but didn't manage to saturate the CPU more than ~4-4.3x a single core.

Then when validating my results I discovered to my big disappointment that quality level 100 (which is claimed to be lossless) is just very close to lossless, but only the parameter --lossless truly is, so rerunning avifenc with that results in images as big as PNG. So that's a complete failure on AVIF in my opinion. I validated the results using image-magick to give me the pixel differences.

Second test case:
I also did a second test case, where I just picked a bunch of assets from my old projects; backgrounds, sprites and GUI elements, mostly simpler stuff, things we should expect PNG to compress very well already. The intention here is to emulate a use case for anyone hosting a website, making an app or a desktop application/game, where there typically are some assets that needs to be lossless. I'm not going to show individual files here, this is just to give an indication.

Aggregated results:

OptiPNG:	WebP:	AVIF:	JPEG XL:
8.33%	37.31%	-2.46%	33.95%

Keeping in mind once again the results for AVIF here are invalid, but I included it to showcase how surprisingly bad it performs in simpler images. Looking at individual images, it actually performed worse the "simpler" the image is.

Most impressive here is WebP, which managed to compress already heavily compressed PNGs much further. I observed up to 93% reduction in size vs. PNG. Also worth noting is that especially for the simplest images (typically GUI elements), where is typically where we see OptiPNG help a lot, you'll get around 30-40% compression on top of what OptiPNG can achieve, so depending on the types of assets you have, this can make a difference.

Conclusions:
- JPEG XL and WebP will achieve ~20% reduction for detailed pictures and significantly more for "simpler" pictures over PNG.
- Both JPEG XL and WebP achieve similar results overall, but results will favor one or the other depending on the picture type.
- Both JPEG XL and WebP are much faster and yield better results than using OptiPNG. (I have also seen OptiPNG yield corrupted results in the past, so you need to verify the results.)
- There may be further parameters to yield even better results under specific conditions for these formats.
- AVIF is a disappointment for lossless compression, thanks to it's normal "lossless" setting not being lossless.
- Differences can be quite significant for hosts of websites and distributers of software.
- Lossy compression isn't tested, and may paint a very different picture. (and I don't even know yet how to do a fair comparison).

Further exploration is encouraged.

That was really in depth! Impressive. Because of what RTB stated earlier I took a closer look at each of the major formats. I've changed my mind about PNG and will be using it as a replacement for BMP going forward. Not changing anything where JPG's are concerned. AVIF does not offer enough benefit to be a compelling replacement, and the same with WebP. JPG is a universally supported format, AVIF/WebP are not.

 

[InVasMani]

That's a pretty intricate comparison across various options. The AVIF/WebP did pretty nicely on speed/compression comparatively speaking and were mostly neck and neck to some degree. Not sure what happened on Image 4 on speed kind of looks like a possible system hiccup, but depends on how you went about testing if you used averaging or just did a quick test at different settings. AVIF Lossless setting you mentioned is disappointing to hear.

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.

 

[efikkan]

Not sure what happened on Image 4 on speed kind of looks like a possible system hiccup, but depends on how you went about testing if you used averaging or just did a quick test at different settings.

I did most of them multiple times, including that one. (And I redid it now with a similar result.) The results were so consistent I didn't even bother to average them. I tested on Ubuntu with no major background processes or applications, just a text editor, spreadsheet etc.

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.

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.

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.

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.

I'm actually very curious to see how they stack up at lossy.

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.

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.

In terms of threading I used a script setup to leverage the cores and threads on my 14700K.

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

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.

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?

 

[InVasMani]

Yeah looks like that's pretty much all one thread fully loaded. It's been a bit since I ran my script don't think that was the case with what I was doing though I did batch test of like 50 images to gauge the encode/decode performance at different quality settings. It's not high up on my priority list atm of things to pick at though. I have a lot of script things I'd rather work on overall.

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.