some MaterialUI icons have no alpha anymore

[ghost]

I heard there was some optimization done lately on the assets, not sure if this was by @Alcaro or someone else, but things aren't quite right now:

[RobLoach]

Before:
https://github.com/libretro/retroarch-assets-old1/blob/627d8f39a44810bb7e0923bf6dfdc5512c44b4b6/glui/help.png

After:
https://github.com/libretro/retroarch-assets-old1/blob/master/glui/help.png

Now:
https://github.com/libretro/retroarch-assets/blob/master/glui/help.png

Looks like all have transparency?

[Alcaro]

Wouldn't surprise me too much if RetroArch is somehow not implementing the complete PNG specification. (That premultiplication script creeps me out, standard PNGs don't do that.)

It would surprise me slightly more, but not too much, if my recompression script doesn't implement the complete PNG specification and somehow glitched the pics (I saw some of them use 16 bits per channel, rather than the usual 8). But on the other hand, that would've glitched the GitHub previews too.

[inactive123]

This is a serious issue though especially in light of the 1.7.0 release that we intend to launch within a few days. If it is not realistic to have RPNG patched so that it can handle these images within the next few days, I would recommend we revert the optimizations.

[Alcaro]

Reverting that commit would inflate the repo a fair bit, and I'm not sure how to revert across the flattening without losing whatever happened since then. Selectively restoring only those images would be mostly harmless, but that requires identifying them.

But more importantly, if we don't fix it in rpng, nothing's stopping this issue from reappearing a dozen times.

Poking the images with ImageMagick reveals that it changed from Indexed to Grayscale color type, and that it has a tRNS chunk. Which is conveniently marked as TODO in rpng.

tRNS on non-indexed color looks fairly simple, just 'every time you see this color, replace with transparent', but obviously someone would have to do it. I'm currently not available.

[anyputer]

Can I also mention that when the window scale is set to 2x, the XMB icons look blurry too? This wasn't always the case.

[inactive123]

I tested this out now - not only are the images lower in quality, but they also have that unfortunate alpha issue now.

Since we don't have time right now to add that missing code support, I'm simply going to revert the icons for MaterialUI as is. We don't have the luxury or the time to inconvenience nightly users with this right now. We can return to these icon optimizations at a later date once you have this TnS support in RPNG and either you or somebody else finds the time to add it. This was a bit of a jumping of the gun, and while it's nobody's fault and it's simply negligence of testing, we cannot leave it like this either, it's not a non-trivial issue. So I'm making the veto decision to revert the files back that were affected, fortunately it's not all of them.

[inactive123]

Updated the problematic images -

9a446eb

@bparker06 and/or other contributors - please let me know if there are still tray icons that exhibit this issue or whether this takes care of them all now.

[anyputer]

Oh and it looks like the XMB Pixel theme is blurry and not pixel perfect too.
Even with the Dot-Art. All of the themes look blurrier when scaled down now :(

[RobLoach]

and it looks like the XMB Pixel theme is blurry and not pixel perfect too.

Would be good to suppose HighDPI for the assets. While the approach is questionable, I made a different issue for it: #189

[alfrix]

@Alcaro i could re-export all the images with the original optimization of optipng -o 7 that didn't cause issues...

[alfrix]

or maybe just grab them from the last commit before the optimizations

from retroarch-assets-old1:
https://codeload.github.com/libretro/retroarch-assets-old1/zip/c81efec323a8e743909519ee892a4031c88d4d13

Should i do a pull reverting them?