Consider using WebP instead of PNG for image assets

[pepoluan]

Problem Description

Currently, all the PNG files inside the images directory takes more than 100 MiB, 178'830'063 bytes, to be exact:

$ { find . -type f -name "*.png" -printf "%s+"; echo 0; } | bc
178830063

Before the advent of more modern image formats, it is understandable that the image format chosen was PNG, because JPEG does not support the necessary alpha channel.

However, with WebP maturing and JPEG XL increasing in popularity, we should revisit this decision.

For example, after a quick-n-dirty conversion from PNG to WebP using the following command:

$ while read src; do cwebp -q 80 "$src" -o "${src%.*}.webp"; done < <(find . -type f -name "*.png")

I ended up with only one-sixth the original size; 29'504'104 bytes, to be exact:

$ { find . -type f -name "*.webp" -printf "%s+"; echo 0; } | bc
29504104

I believe a saving of nearly 150 MB is quite significant.

Related Issue Links

• Somewhat related to Support image formats dedicated to frame sequences #4980 , though that one is more about animation frames.
• Strongly related: optimized sprites #9880

Desired Solution

• Convert all PNG images to WebP images
• Use libwebp to decode the new image format into in-memory bitmap for use

Alternative Approaches

There is one drawback of using lossy compression for storage: Generational Loss

Successive editing and saving will slowly degrade the images.

To prevent this, we can use this strategy:

1. Move the PNG-format images to a different repo.
2. Changes to the images should be done only in this repo.
3. Regularly (on change) generate a whole set of WebP images from these files as "release"
4. Grab the "release" images and use them in the images directory

Additional Context

No response

[danaris]

I don't know offhand the differences between the formats, but HEIC is another modern image codec designed to be more space-efficient. I would suggest it also be considered, and compared, before deciding on a format.

[eebop]

Heic is proprietary to apple and requires a paid subscription on non-mac machines

[danaris]

So far as I can tell, it is not proprietary—it is an ISO standard, and can be implemented by anyone. According to https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format it is fully supported by Windows 11 and Android—it requires a paid purchase for Windows 10 to support specifically the ones that Apple creates by default (HEVC encoding), but not the format as a whole. It's not clear from this whether it's a one-time purchase or a subscription.

Do you have a source that contradicts this information?

[Zitchas]

To be honest, I detest dealing with webp stuff. Not everything opens it, and everytime I get an image in WebP it just means extra work. I convert everything out of WebP at first opportunity.

So aside from windows 10 needing a paid subscription (which I'm not paying, thank you very much.), how about those on variations of Linux and older Windows? Currently, our only graphical requirement is "Runs OpenGL 3.0 or greater". I don't think the gains are worth changing that to "Runs OpenGL 3.0 and has WebP support".

edit: I'm not against ES having WebP support, and if someone wants to use it to make a "extra-compact" version with it, great! I know there are some players for whom every Mb counts. But I really don't think it should be the standard.

[RisingLeaf]

This is just premature optimisation, as Zitchas said webp is not as widespread as png and jpeg.

If we really wanted to save space and time we could think about saving precompiled pictures. But that's for later down the road.

I am also against adding webp support as that would be another dependency of the project (we already have a lot).

[SomeTroglodyte]

I feel the discussion slightly beside the point: User or developer platform is irrelevant. You're ultimately preparing some storage into textures ready for the render pipeline - so it depends entirely on the library used to load those textures, including licensing.

another dependency of the project

To the point, but maybe whatever you currently use already has more options?

If at all, I'd consider going for one of the formats meant for 3D textures, as only those can give you the best mipmaps, as those will improve scaling on 2D markedly too. Venerable dds (even foss games used that iirc) or ktx/zktx or maybe I'm way out of date...

[43897689431805741092]

There is one drawback of using lossy compression for storage: Generational Loss

WEBP supports lossless compression though, doesn't it? Since you say this, I wonder, are lossless WEBP images not actually meaningfully smaller than PNGs? Using lossy compression for game graphics is an absolute no-go out of principle IMO.

Something that definitely can and should be done (literally right now, whoever has the knowledge to PR it neatly – I'll probably mess it up) is re-saving all the PNG images currently in the game with the maximum compression setting of 9. I always run downloads of new game versions through FileOptimizer (except the Shuttle's top-down graphics, which it corrupts) and found that some of the newer graphics added (e.g. the Fusion Cannon projectile) are practically uncompressed.

[SomeTroglodyte]

meaningfully smaller

At best 30%, expected (my guess for ES assets) nearer 15%: https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study#results
A meaningless difference if the code loading them into textures needs new libraries. Also, supporting a FOSS-hostile Kraken.

[Zitchas]

I feel the discussion slightly beside the point: User or developer platform is irrelevant. You're ultimately preparing some storage into textures ready for the render pipeline - so it depends entirely on the library used to load those textures, including licensing.

A couple things here.

a) As a project with no formal organization, there's no entity to sign or pay for a licensing agreement.

b) One of the core tenets of the project has been that end-users can add their own graphics and data as easily as pasting a random image from their picture folder into the correct location, along with <5 mins of editing with their preferred text editor. I am aware of a number of contributors, myself included, who have contributed both code and content with this level of software.

c) As an aspect of B, we've made something of an effort to ensure that all the content (visual and otherwise) remains easily accessible to everyone in order to encourage community participation and contribution.

d) Low appetite for putting work into adopting things that are hostile to FOSS.

In summary, if something makes things harder for the general userbase to view, edit, and work with the files, it's not a good fit for Endless Sky.