I would like to play a bit more with that, but I’m not sure what parameterы for webp encoder correspond to WEBP_LOSSY_NORMAL, WEBP_LOSSY_FAST, WEBP_LOSSY_HIGH and WEBP_LOSSY_BEST
thanks for experiments @AGulev! indeed, in your pictures without “premultiply alpha” it looks better,
but this is the result: (built in Defold version sha1: aa82e11a5e6619fb8634d90df3d42e494678685b)
This is example with ETC1S -comp_level 5 (prev. one was 6)
I use just
./basisu -comp_level 5 test-keep-transperent-pixels.png
ETC1S -comp_level 5.zip (1.0 MB)
UASTC_HIGH: time ~6m
UASTC_HIGH: time ~4m43s
for ETC1S_HIGH, 2:46 vs 01:32, dunno how that works
Bob.jar builds “too many” files. E.g. separate .png files.
E.g if you specify the
test.atlas to use the
A.png, bob will build both as textures, and if the texture profile matches, it compresses both.
I recommend specifying “*.atlas” in the pattern.
Much better now!
It is interesting if LZ4 takes a lot of time and if Defold applies it to ETC1S. Because as I understood it’s useless for ETC1S
LZ4 shouldn’t take much time no.
It’s generally the texture compression algorithm that takes time.
You can compare with turning off the texture compression (or use the debug property “project.compress_archive = false”).
Sure, it’s unnecessary to compress the ETC1s, since it’s already compressed, but we currently have no way of distinguish between UASTC/ETC1S compressed textures.
Please, pay attention this is comparison of sizes and quality and nothing more. I don’t take into account all aspects.
BasisU and WebP are totally different. Both have it’s pros and cons. I did these tests just because some html5 games have higher priority in disk space (download size) but not memory or decoding speed. It is important for some but not for all the games.
I use the newest version (latest master 427ebe62ebd6c7fed40994b1f963e66aa3993fce) basisu at the moment.
So, it seems like UASTC has too good quality for the goal we want to achieve, but ETC1s has too low quality for our goal =)
I tested everything for texture without premultiplied alpha (not sure what the reason of quality issue in case we use it, it’s separate thing for the other investigation)
It seems like for the best quality of ETC1s we should use:
./basisu -comp_level 6 test.png -q 255 -linear -max_endpoints 16128 -max_selectors 16128
Also, I played a bit with RDO for UASTC, but even with extreme values result was far away from the goal.
So, I kept only one with the smallest size + norm quality:
./basisu -uastc -uastc_rdo_m test.png -uastc_rdo_l 5 -uastc_rdo_d 8192 -uastc_level 0
I tested two WebP versions. The newest WebP(1.2) and WebP we previously used in Defold (0.5).
cwebp -q 75 test.png -o test.webp
cwebp -q 90 test.png -o test.webp
I didn’t measure decompression and compression speed and the other metrics, but I noticed that webp 1.2 decoder twice as bigger that webp 0.5 decoder JFYI.
webp vs basis.zip (2.5 MB)
png files with backgrounds like this (just example. forum convert it to jpeg, pls download archive)
with backgrounds.zip (1.6 MB)
compressed and uncompressed size are the same… see attached images.
ETC1S: doesn’t work for me at all, build just stops (180 displayed a message, something like “encoding error”, 181 is silent )
This seems strange.
2048 x 2048 x 1 = 4 mb which is the expected size of the .basis file it produces. However, for the LZ4 compression to not compress the .basis file, that’s very unexpected.
Could you share that image with me?