Expected KTX2 file sizes

[gjcope]

Hey @donmccurdy ,

I was experimenting with KTX2 and using the gltf-Transform CLI to convert some existing models. I know file sizes can increase, but I'm seeing really significant growth, like 5x to 10x with uastc. Is this expected? I doesn't seem in line with other stats I have seen from others usage. I know it can vary texture to texture as well, but this seems to happen across the board for me.

Some test output:

D:\models\armstrong>gltf-transform etc1s suit-p1-web-high.glb output1\suit-p1-web-high.glb --slots "baseColorTexture" -v
warn: Decoded KHR_draco_mesh_compression. Further compression will be lossy.
debug: Found KTX-Software v4.0.0.
debug: Texture 1/3 (baseColorTexture)
debug: • toktx --genmipmap --bcmp C:\Users\copeg\AppData\Local\Temp\tmp-18612-vsF3XKouW3Ss-.ktx2 C:\Users\copeg\AppData\Local\Temp\tmp-18612-d8cnflxk64d6-.jpg
debug: • 1.51 MB → 1.98 MB bytes.
debug: Texture 2/3 (occlusionTexture)
debug: • Skipping, excluded by pattern "baseColorTexture".
debug: Texture 3/3 (normalTexture)
debug: • Skipping, excluded by pattern "baseColorTexture".
info: suit-p1-web-high.glb (6.55 MB) → suit-p1-web-high.glb (11.3 MB)

D:\models\armstrong>gltf-transform uastc output1\suit-p1-web-high.glb output2\suit-p1-web-high.glb --zstd 22 --slots "!baseColorTexture" -v
debug: Found KTX-Software v4.0.0.
debug: Texture 1/3 (baseColorTexture)
debug: • Skipping, already KTX.
debug: Texture 2/3 (occlusionTexture)
debug: • toktx --genmipmap --uastc 2 --zcmp 22 --assign_oetf linear --assign_primaries none --target_type R C:\Users\copeg\AppData\Local\Temp\tmp-8236-30RNvq5vxja6-.ktx2 C:\Users\copeg\AppData\Local\Temp\tmp-8236-G85TwOsVBIAY-.jpg
debug: • 1.41 MB → 11.19 MB bytes.
debug: Texture 3/3 (normalTexture)
debug: • toktx --genmipmap --uastc 2 --zcmp 22 --assign_oetf linear --assign_primaries none C:\Users\copeg\AppData\Local\Temp\tmp-8236-5938MQm14AFG-.ktx2 C:\Users\copeg\AppData\Local\Temp\tmp-8236-HyNVvWVgCYvU-.jpg
debug: • 3.2 MB → 18.63 MB bytes.
info: suit-p1-web-high.glb (11.3 MB) → suit-p1-web-high.glb (36.51 MB)

[donmccurdy]

I do expect UASTC to be larger than JPEG in most cases, and possibly lossier, so if transmission size is a big concern then keeping those textures in other formats like JPEG, PNG, or WebP might be preferable at the cost of memory footprint. To my understanding the size of a UASTC texture (before ZSTD compression) is a function of its resolution, whereas JPEG or PNG textures could become arbitrarily small. And then with ZSTD applied, compression ratio is pretty sensitive to the amount of entropy in the image, so the final ratio between JPEG and UASTC can vary a lot.

I'm not sure whether the numbers you're seeing are general or not though. What's the resolution on these textures? It could be worth extracting the textures and running similar toktx commands on them individually to see if there are better parameters to use. I would guess that ETC1S might be enough for an occlusionTexture too, since it only has one channel.

[gjcope]

Thanks! The resolution is 4k. I will give the manual toktx a try and see if it's comparable. But if I ignore the transmission impact, I assume a final file size of ~20MB from jpg->ktx2 is still going to be a performance gain as it's bound to be < the normal 50MB in memory? Is there a good way to confirm this? Trying to find a temporary solution to this issue (https://discourse.threejs.org/t/textures-in-gltf-sometimes-display-black-but-only-on-ios/30520/29) that you were also super helpful with! Thanks again.

[lexaknyazev]

• Decoded 4096x4096 JPEG texture with all mipmaps takes 89'478'484 bytes of VRAM regardless of the image contents or transmission size.
• Same texture encoded as UASTC and transcoded to BC7 or ASTC (the runtime choice depends on the platform) takes only 22'369'648 bytes of VRAM.