What about optimizing images?

[K0-RR]

Hello, my plan was to fork Compliance assets repositories and after lossless compression submit PRs but I figured I would ask first what do You think about it.

There is no downside to this and the resource pack size will just get smaller. The easiest way to achieve this would be to just use GitHub Imgbot as it doesn't require any actions from You other than adding it to the repo with one or two clicks. Imgbot however doesn't do the job as good (still better than nothing) as the tools I use: Leanify and Oxipng.

Can I proceed or do You prefer to do it by yourself / not interested at all?

[RobertRR11]

I have tried using Oxipng myself once, but I couldn't find a way to compress images in all folders at once. So if you could show me that I would really appreciate it for future use.

[K0-RR]

The command for enabling recursive mode is -r (--recursive), similarly to other command-line programs
The full command I use is oxipng -arZ -o max --strip all --fix /path/to/the/dir (well I also use -v for verbose mode)

For Leanify (compiled from the source because the dev refuses to release a new version for no reason) I just use leanify -p /path/to/directory and the results will be the same or better. Leanify can break other files than image ones, like xml.

[Cyphall]

That might be a great idea.

I developped a small tool a few years ago that basically runs all the png files in a folder through google's ZopfliPNG.

When running this tool on Faithful-Java-32x, the size went from 5.67 MB to 1.94 MB(!)
With Faithful-Java-64x, the size went from 7.58 MB to 5.33 MB.

Also, it seems that some of the textures (acacia_door_bottom.png for example) have fully transparent pixels that have different values in their rgb channels, taking unnecessary space.

[RobertRR11]

Alright, since we're preparing for releases I'll keep this open and when we're ready upload the compressed textures.

[Cyphall]

There are still some questions to be answered before going further:

1. Do we need to keep metadata?
   Most of it is pointless information, but some metadata like sRGB profile (if used) may change the final result.
2. Do we discard rgb data for pixels that have an alpha value of 0?
   This is supposedly useless data for color textures but might break non-color data such as normal maps and specular maps.

[Pomi108]

The rgb data for alpha 0 pixels breaks some textures (fast leaves is the only example i can think of, but still), so I'd keep it to be safe

[Pomi108]

Oh also, not sure if we're gonna be compressing TGAs, but the majority of those relies on RGB data on alpha 0 pixels. So yeah.

[RobertRR11]

Oh also, not sure if we're gonna be compressing TGAs, but the majority of those relies on RGB data on alpha 0 pixels. So yeah.

I don't know if tools that compress TGAs even exist, I planned only doing PNGs

[Cyphall]

The rgb data for alpha 0 pixels breaks some textures (fast leaves is the only example i can think of, but still), so I'd keep it to be safe

Well, it seems fast leaves are already broken in Minecraft Vanilla (see MC-57918), but nice catch nonetheless.

[Pomi108]

We just tried this out and found that it absolutely breaks Bedrock and Java 1.12 and below. So yeah, I don't think this is feasible

[Cyphall]

Alright, so we keep all pixel data.

1. Do we need to keep metadata?
   Most of it is pointless information, but some metadata like sRGB profile (if used) may change the final result.

For this point, what do we do?

[Pomi108]

I think the colour profile was the main issue. We could try compressing the pack while keeping that the same

[Cyphall]

I set up my tool to keep all the chunks that might change the final render :

• cHRM
• gAMA
• pHYs
• iCCP
• sRGB
• oFFs
• sTER

(this list is from google/zopfli#113 (comment)).

How do you want to proceed for the compression?
I can put the sources of my tool on github if you want to build it and compress the textures yourself.