chore: lossless png compression

[ckerr]

I used this script to run lossless compression utils [zopflipng, optipng, advpng, pngcrush] dialed to maximum (e.g. advpng --shrink-insane) on all the png files in the repo.

The ugly: this is very slow, which is why I'm PR'ing the changed files instead of adding the process to a workflow.

The good: this PR reduces the total size of png files in the repo from 14,328,881 bytes to 6,536,247 bytes, a lossless savings of about 55%.

See also https://github.com/electron/website/pull/583#issuecomment-2183389109. CC @dsanders11, @BlackHole1, @erickzhao who were all active in that PR.

[dsanders11]

It would be nice if we had a way to verify the changes were actually lossless (not just for this PR, but any future ones), so we don't risk committing lossy changes that then get further lossy changes on top of them in the future.

This comment suggests that ffmpeg -loglevel error -i <name>.png -f md5 - would get you the hash of the decoded raw output as a way to confirm two PNGs are the same, but I'm getting different hashes between main and the content in this PR, so not sure it's a proper method.

If we can verify that the output is lossless, we could rig that script up as a GitHub Actions workflow to run after every push to main and commit back the compressed PNGs. I think that would satisfy our issue of not wanting it to be part of the build pipeline but still get the benefit of smaller file sizes.

[ckerr]

but I'm getting different hashes between main and the content in this PR, so not sure it's a proper method.

Interesting!

I believe these compressors are lossless but I haven't done anything to confirm it. It's possible that I'm holding one of them wrong. I'll do a little digging to see if there's a good way to check and will mark this PR as a draft in the interim.

Agree on docs/, I'll revert those changes too.

[ckerr]

but I'm getting different hashes between main and the content in this PR, so not sure it's a proper method.

I still have some work to do on this, but just to check in: I've found two reasons that a lossless compression could still fail checksum tests:

1. This thread says some PNGs contain creation timestamps in their data, so checksum tests would fail unless those timestamps are identical

2. Some PNGs (including some of the ones in this repo) contain a nonstandard data chunk "iDOT" which is an interesting sidestory but the tldr is it's a nonstandard Apple extension that's unused by non-Apple png readers. So if the compressors discarded these, that would also affect the checksum

The closest thing I could find to a clean off-the-shelf test for equality was using ImageMagick's compare -metric AE a.png b.png null. That sounds good but I still need to test it out.