Optimize Image and Add to Additional Location (Ref: #596)

[Zallb]

This pull request optimizes the image initially included in PR #596 with Zopflipng. Additionally, replacing the old image that was previously missed in the ip2c.

Please review the changes and inform me of any other locations where the old flag might still be in use.

[Fernando-A-Rocha]

This is not your fault, but ideally we shouldn't have duplicated flag images in the official resources. If we're keeping them, they should be centralized in 1 res.

[AlexTMjugador]

This PR is nice, although I wonder why you specifically chose Zopflipng for the optimization, because as far as I am aware it's a mostly unchanging piece of software that isn't getting improvements these days.

Did you try out other optimizers, like Oxipng? (Disclaimer: I'm a Oxipng contributor.)

[Zallb]

This PR is nice, although I wonder why you specifically chose Zopflipng for the optimization, because as far as I am aware it's a mostly unchanging piece of software that isn't getting improvements these days.

Did you try out other optimizers, like Oxipng? (Disclaimer: I'm a Oxipng contributor.)

Because most MTA assets (this repo included) use the same tool to optimize images (https://forum.multitheftauto.com/topic/119032-tool-png-optimizer)

Maybe if Oxipng well outperforms this tool, it might be worth to have everything re-optimized.. Last time I downloaded the installer I was shocked by the 100+ MB size

[AlexTMjugador]

I see, I was not aware of that forum post. It's fair enough to try to keep things simple by standardizing on a single PNG optimizer.

On the topic of Oxipng's install size, it'd be interesting to note where you're getting it from, because the upstream CLI binaries for the v9.1.3 release are only around ~600 KiB big. So any significant size difference ought to be caused due to additional features or bundled software.

[Dutchman101]

ZopfliPNG preserves every pixel, so there's not even a microscopic visual difference, yet it hugely reduces size and therefore the texture it loads into memory (client performance). Other PNG 'optimizers' like the one you mentioned don't do this.

That a project isn't very active doesn't mean much, if it's feature complete. It is, because that use is its goal and it works perfectly.

I see, I was not aware of that forum post. It's fair enough to try to keep things simple by standardizing on a single PNG optimizer.

FYI, we standardized on ZopfliPNG, for the aforementioned reasons. It was also applied across the mtasa-blue project.

[AlexTMjugador]

ZopfliPNG preserves every pixel, so there's not even a microscopic visual difference, yet it hugely reduces size and therefore the texture it loads into memory (client performance). Other PNG 'optimizers' like the one you mentioned don't do this.

Oxipng can also preserve the exact same pixel color and transparency (alpha) values, in addition to using Zopfli as a compression backend for pixel data. But those behaviors depend on how you set it up. The documentation for it is available on the manual file on its repository and other places. Interestingly, Oxipng natively supports multithreading, which can come in handy when optimizing lots of PNGs at once.

That a project isn't very active doesn't mean much, if it's feature complete. It is, because that use is its goal and it works perfectly.

Well, one thing I learned when writing my own compression code is that no such thing as a practical, general-purpose perfect compression encoder for arbitrary inputs exists 🙂. People come up with different ways to encode data all the time; even ML autoencoder models (yes, AI) have applications in data compression. Oxipng could be (or could not be) a better way. It definitely does some things differently to ZopfliPNG.

Of course, as I stated before, if sticking to ZopfliPNG is still desired then so be it. I just wanted to make clear what Oxipng can do and how it could (or could not) be an improvement.

[Nico8340]

Merge