Texture Compression Mode ETC1S

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

2 Likes

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)
http://tinydobbins.com/test/defold/test_textures/textureTest_181_etc1s_disable_premultiply_alpha/

1 Like

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)

1 Like

@AGulev The previous WebP settings are here:

2 Likes

@Mathias_Westerdahl about the building time, @AGulev found interesting thing, if to add the path to atlases here:

building faster
before:
UASTC_HIGH: time ~6m
after:
UASTC_HIGH: time ~4m43s

for ETC1S_HIGH, 2:46 vs 01:32, dunno how that works :hushed:

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.

2 Likes

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.

3 Likes

Disclaimer:
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).
WEBP_LOSSY_NORMAL:

cwebp -q 75 test.png -o test.webp

WEBP_LOSSY_HIGH:

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.

Arhive:

webp vs basis.zip (2.5 MB)

5 Likes

png files with backgrounds like this (just example. forum convert it to jpeg, pls download archive)

with backgrounds.zip (1.6 MB)

2 Likes

UASTC:

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 )

2 Likes

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?

2 Likes

I’m wondering why Defold includes JPEG/PNG decompressor but doesn’t have an option to compress RGBA atlases into PNG, RGB atlases into PNG/JPEG?

JPEG can provide a good balance between quality and size for lossless RGB images, and there are many compression libs like Guetzli. PNG can be compressed very well, too.

It’s a good option if a developer doesn’t care about the memory size of textures.

2 Likes

I’m wondering why Defold includes JPEG/PNG decompressor but doesn’t have an option to compress RGBA atlases into PNG, RGB atlases into PNG/JPEG?

I think the primary intended use for the JPEG/PNG decompressors was to support downloading dynamic content on the fly on the web.

I can’t say for certain why we don’t used .png as the format for lossless image compression. I think the issue only came up when we wanted as small images as possible. By then WebP existed, and produced much smaller textures, for lossless images. It also supports lossy compression. So, as a source package, I think it was a better deal.

I think both time (decompression) and quality were also considered when not choosing jpeg. (I don’t think I have those design documents anymore.)

In the near future, I believe we’ll have a core functionality (Basis Universal), and have other compression strategies as pipeline extensions (WebP etc).

2 Likes

Now I’ve come across the fact that etc1s doesn’t work - it doesn’t decode on android. Is this normal?

Clearly the quality is poor, then maybe we should remove everything that doesn’t work from these lists:
image

UPD: I’ve checked on several of my projects - etc1s works on android as long as it’s applied to RGB atlases. If the atlas is RGBA, the application will crash.

2 Likes

And a rather important point - texture profiles do NOT apply to textures!
o___O
They only apply to atlases.
Therefore, 80 mb of textures in my project always remains 80 mb, whichever profile I set.
But I really wish I could pack them into etc1s… :sob:

1 Like

I found that decoding ETC1S causes an error on Windows. On Android / iOS / macOS everything works correctly (but on some Android devices there are sometimes crashes related to decoding too).
P.S.
I seem to be the most active ETC1S user here, as I use it to reduce the size of 2D-backgrounds in the build. This format helps me a lot, because it is much better to compress in ETC1S than to downsample by 4x times - still pixelization will be visible to the naked eye.