[Enhancement]: Optimize static PNG assets

[lumiscosity]

Checked Existing

• I have checked the repository for duplicate issues.

What enhancement would you like to see?

The 3DS especially suffers from poor download speeds and low memory. PNG images can be compressed down losslessly using tools such as oxipng. This shouldn't be incompatible with the 3DS browser - PNG standards haven't moved much in the past 22 years (past APNGs, which we aren't using anyways).

Any other details to share? (OPTIONAL)

I already have a PR for this queued up, just gotta test it - the setup I use can be found here.

[suprstarrd]

Related - here's a pull request from @imgbot: suprstarrd#1

If this issue becomes approved, anyone can make a PR from my imgbot branch and send it upstream. (Unless your compression technique has more significant savings than theirs?)

Not a member of the team but I support. Every byte counts.

[ashquarky]

I had already put pretty significant manual effort into optimising the CTR assets specifically (which is, I suspect, why @suprstarrd 's method shows minimal gain on those CTR assets). Portal and web are pretty free I think and haven't been tuned.

Given that, I am really impressed to see significant improvement from oxipng, even on the already tuned assets. We definitely need to check compatibility with the applets, but I'm very curious what it's doing and if I can build similar improvements into Juxt's uploaded image processing.

[lumiscosity]

if you check the link with the setup i sent, you'll see there's a bunch of tools at play over just oxipng - each of these calls does something else. that being said, the second and third steps especially take a huge amount of time and processing power, so for live image processing it might be wise to skip them - on my laptop, running nothing else, it took around 6 minutes to process all the files in the repo, and the time required rises pretty fast with resolution. the last two tools do some weird wizardry to cut off ~1-2 bytes from every image. it's pretty cheap so it might as well be worth it.

that being said, all of the images in my pr are compressed better than the imgbot pr, so it's definitely worth the effort for static assets.

notably, imgbot seems to strip the colorspace information chunks (use the swipe function on bandwidthalert.png and you'll see the background is off) - i'm not sure if the 3DS supports those in the first place and it could be an ok tradeoff if we're shaving off every last byte (not that the chunks for it are that big in the first place), so i could integrate that into my setup for a bit of extra crunch, and the queueing command would look like this in that case:

function rcomp() {
    find . -name "*.png" -type f -exec oxipng -o max -a --strip all {} \;
    find . -name "*.png" -type f -exec pngout {} \;
    find . -name "*.png" -type f -exec oxipng -o max --zopfli -a --strip all {} \;
    find . -name "*.png" -type f -exec defluff-shim {} \;
    find . -name "*.png" -type f -exec deflopt {} \;
}

imgbot also supports SVG, while my PR is only for PNGs.

[ashquarky]

The 3DS hardware is pretty terrible for colour reproduction anyway, often mixing up purple and blue - this appears to be some element of the screen itself. So not too worried about colour accuracy for assets that are only displayed on 3DS.