astc-encoder VS j40

A1: The optimization suggestion in the original text is to remove the meaningless Alpha channel (defined in the original text that the Alpha channel has the value of 1). This is indeed helpful for memory optimization. In your test case, whether it is in png or tga format, after entering the engine, it will be converted to the internal format (RGBA, ETC, ASTC, etc.) by the engine. Imagine taking ETC2 as an example. If there is no Alpha channel and the compression quality is acceptable, RGB_Compressed_ETC2_4bits can be used. If this meaningless Alpha channel is added, then we will automatically select RGBA_Compressed_ETC2_8bits when importing the settings in batches. In this way, the memory is doubled. Regarding the ASTC in the question, the definition of the Texture import format (https://github.com/Unity-Technologies/UnityCsReference/blob/master/Editor/Mono/AssetPipeline/TextureImporterEnums.cs) in the Unity editor source code has this comment: // ASTC uses 128bit block of varying sizes (we use only square blocks). It does not distinguish RGB/RGBA. That is, it has nothing to do with whether the Alpha channel is included. For an introduction to the ASTC format, I recommend you to read the ASTC Format Overview on Github: https://github.com/ARM-software/astc-encoder/blob/main/Docs/FormatOverview.md Regarding the issue of the new version of Unity mentioned in your previous reply, you can look at this issue on the Unity forum: https://forum.unity.com/threads/is-astc-rgb-encode-gone.660622 Some people may think that if the format of all textures in the project is ASTC, the meaning of removing Alpha is not very significant. In fact, it cannot be generalized. Although the size is the same, according to the test in (https://zhuanlan.zhihu.com/p/158740249), Whether there is an Alpha channel will affect the compression quality to a certain extent. Therefore, it must be used reasonably in the project.

You can also force it by using extensions like `[[gnu::always_inline]]` or `__forceinline`. I've actually used this technique to generate an auto-vectorizable function whenever it's possible [1].

[1] https://github.com/lifthrasiir/j40/blob/252e7987d36d50f617f2...

There's already an independent implementation, though it doesn't cover animations, progressive, or some other features yet.

If you are interested in making a J40 binding in Rust, please also take a look at the future Rust version itself. I've made an initial issue [1] about this effort.

[1] https://github.com/lifthrasiir/j40/issues/10

J40: Independent, self-contained JPEG XL decoder\ (27 comments)