image optimizer for web

After running Pingo on this image, its size decreased dramatically which made me very suspicious. I then ran ImageMagick with this command to check for differences between the original and Pingo optimized files.

"magick.exe" compare -channel all -metric ae "Original.png" "Optimized.png" "Difference.png"

ImageMagick returned the value "3.25729e+06" which confirms Pingo did lossy optimizations. If ImageMagick returned the value 0, that would mean there are no visual differences between the two files.

Hello Alex,

This PNG:
* https://konachan.net/image/ac4750c35ec23b8b2535533feee36687/Konachan.com%20-%20346859%20armor%20breasts%20cropped%20demon%20gloves%20gray_hair%20horns%20japanese_clothes%20mask%20original%20red_eyes%20short_hair%20sideboob%20snow%20yohan1754.png
is 16-bit per sample.

4 links for you:
* https://www.w3.org/TR/2003/REC-PNG-20031110/#13Sample-depth-rescaling
* http://www.libpng.org/pub/png/libpng-1.2.5-manual.html#section-3.7
* https://source.chromium.org/chromium/chromium/src/+/main:ui/gfx/codec/png_codec.cc;l=156
* https://chromium.googlesource.com/webm/libwebp/+/0.2.0/examples/cwebp.c#429
Your web browser scales down the PNG to 8-bit for display, using "png_set_strip_16".
The "-lossless" from cwebp (WEBP) = scales to 8-bit as well.

* https://web.archive.org/web/20210420093845/https://css-ig.net/submit/bugs/
Cedric stated here that Pingo supports only 8-bit ("PNG-48 procceesed to PNG-24" topic, not available).
It decodes and encodes to 8-bit. It's lossy regarding bytes if you drop 16-bit per sample PNG.

Cheers!

Hello Damien,

Thank you for your reply. I'm aware of bit depth reduction and believed that this was what Pingo was doing to this file. I'm disappointed that Pingo does bit depth reduction when using its lossless mode. If Pingo doesn't support 16-bit PNG files, then it should just skip them altogether. I believe there should be a separate setting if a user wants Pingo to reduce the bit depth of their PNG files. Unsuspecting users would believe that using Pingo's lossless mode on PNG files would always yield lossless results, but that would not be true for 16-bit files.

Pingo "lossless" isn't really lossless actually:
- It drops data if alpha=null
- It removes interlacing
- It scales down 16-bit to 8-bit
- It drops all meta
- It changes the order of palette indices
- ...
Those have critical hits:
- alpha=null on height maps, ...
- interlacing for display
- 16-8 = minor color banding
- meta loss
- shared palette = mess

I guess all of us have definition of lossless :)

Cheers!

Thanks again for the reply, Damien. I agree, people have varying definitions of the word lossless. Common online dictionaries generally define the term as "free from loss" and "not losing information." I define the term lossless as "not losing valuable information." The definition of valuable information in a PNG file varies depending on who you're talking to. I've left my personal thoughts to your bullet points below.

Pingo drops data if alpha=null: I've had no issues with Pingo, along with other optimizers, dropping the alpha channel on PNG files that don't have transparent pixels. You're technically losing data, but it isn't meaningful data for these files, as there's no visual difference. Nullifying height maps hasn't caused any issues for me.

Pingo removes interlacing: I recognize the benefits of interlacing, but I don't use it. I prefer the better compression of non-interlaced PNG files. As long as removing interlacing doesn't affect visual quality, I have no problems with this.

Pingo scales down 16-bit to 8-bit: I don't believe this is lossless. You're reducing the bit depth from more precise 16-bit to less precise 8-bit, while introducing color banding. Most people won't be able to perceive a visual difference, but the fact that there is one in general doesn't sit well with me.

Pingo drops all metadata: From my understanding, Pingo will remove non-critical metadata during lossless optimization without the -strip setting. Adding the -strip setting will remove all metadata. I have no issues with metadata removal, as I never utilize it.

Pingo changes the order of palette indices: As long as this doesn't degrade visual quality, I'm unaffected by this.

I believe the general takeaway from this discussion is that PNG optimizers need to give users choices. Choices to keep or remove the alpha channel, preserve or remove interlacing, enable or disable bit depth reduction, preserve or remove metadata, handle palette indices in a less messy way, etc. The more choices we have, the more control we have in optimizing PNG files the way we want them to be optimized.

Hello Alex,

Yes, removing alpha channel if all are 255 (=no transparency at all) is 1 use case. My point was actually that Pingo sets the Red/Green/Blue to 0 if the alpha is 0 (=totally transparent). You lose data without any possible recovery. Sometimes it sets some weird data instead of 0. I guess it's about improving the deflate.

Shared/Ordered palettes is more specific use case on some apps, not regular viewers/web. Interlacing is worst for filters so for compression. 

Cheers!

Greetings Damien,

Pingo most likely changes/removes color information (RGB) on fully transparent pixels to improve deflate compression. This wouldn't be considered lossless by the dictionary definition, though as long as no visual changes occur after running Pingo (lossless mode) on an image with transparency, this doesn't affect me.

What applications rely on the order of palette indices? I'm intrigued and would like to learn more.

I understand that interlacing alters PNG filtering, which correlates to worse compression. That's why I don't use it.

@Alex,

Back in the old days & IIRC, it's a 2D-art game maker (I fail to remember the name). The initial resource was a Png while related animations were only mapped sequences.
If it doesn't make sense, you can compare this to animated png: if you change the order on a color-mapped one, then you've to remap everything (IDAT+FDAT) or it'll break your file.

Cheers!

Hey Damien,

Thanks for the insight. I'll keep this in mind while optimizing PNG files in the future.

Thanks for adding the -no-16bit option, Cedric. Exactly what I was wanting. As always, your work is highly appreciated.

Hi

Just wanted to point out a false premise here: Browsers do support wide gamut color, including 16-bit PNGs. Chrome has had support for a few years now, and Safari has for many more. They all support ICC profiles and support is gradually tricking out for cICP too.

See here, for instance: https://bugs.chromium.org/p/chromium/issues/detail?id=839034
One line in the source that appears to unconditionally reduce to 8-bit does not actually reflect reality.