KTX2 Texture Compression
Textures are ubiquitous in modern graphical applications. They give color and material information to our models.
The higher the resolution of our texture, the more detail we can get. These days, high-resolution cameras are becoming more accessible and affordable. However, this comes with a cost: memory usage.
We have compressed image formats such as JPEG and PNG that reduce memory usage of images stored on disk. These formats are also helpful for web applications, as we can reduce the amount of data we need to transfer over the network, effectively reducing page load times. However, formats such as JPEG can’t be interpreted by the graphics card (GPU); they are just designed to compress images, not for rendering. A JPEG image would need to be decompressed before sending it to the GPU for rendering.
The following is a 256×256 image.
Created with GIMP
Compressed as JPEG, with high quality, it weighs 53.5 KB.
Once we decompress the image to RGBA8 for GPU consumption, it will take 256KB. That’s about 5x more!
This is a very small image but, as an example, a 4K image (which is very common these days) would take 64MB. Large applications will have lots of resources, including textures, so this can add up quickly and eat up all the GPU memory (VRAM), especially in low-end devices such as smartphones, tablets, and VR devices.
Texture compression formats were invented to allow for compressing images in the GPU. These compression formats are designed to fit the way GPUs are architected to achieve optimal performance. This translates, not only to lower VRAM utilization, but also:
- Faster load times as the amount of data that needs to be transferred to the GPU is lower.
- Better frame rates as the internal transfer bandwidth requirements are reduced.
Different GPU manufacturers, in collaboration with the main players involved, came up with different texture compression formats. Some examples of these formats are:
- The BC family of formats (also known as S3TC) such as BC1, BC3, BC6H, BC7 (among others). These formats are exclusive to desktop platforms.
- ETC (Ericsson Texture Compression) family, composed by ETC1, ETC2, and ETC2_EAC and EAC. These formats were mainly adopted by OpenGL and are used in Android and WebGL platforms.
- PVRTC is a family of formats exclusive to PowerVR chips. It was important because it was the only supported format in iOS. It’s now becoming obsolete as Apple is now adopting ASTC for all devices.
- ASTC is the most advanced texture compression format nowadays. It’s a standard developed by the Khronos group, and it’s now the de facto format for mobile devices.
As you can imagine, having so many texture compression formats can be a big headache for application developers who care about having good performance in multiple platforms.
The Khronos group has attempted to solve this fragmentation issue with the KTX2 container format and the super compression schemes. We will explore them further in the following sections.
KTX1
Before KTX2, as you might have guessed, there was KTX1.
KTX1 was a very simple image container format — that is, it’s just a format that contains images, which can be in different formats. It could contain any of the compressed texture formats mentioned above and it could also contain raw RGBA images. It’s simple, it just works.
The problem was that, if you wanted to support many platforms, the KTX1 container would have to include the images in the specific formats for each platform. That can be hard to maintain and implies storing the same information in each format (files become bigger).
KTX2
KTX2 aims to solve the fragmentation even further with the transcodeable formats and super compression schemes.
In addition to the image formats supported by KTX1, KTX2 adds two transcodeable formats: Universal ASTC (UASTC) and ETC1S. These formats are designed to be converted to the platform-specific texture compression formats. Conversion from these so-called transcodeable formats to the texture compression formats is blazing fast, so it’s a process that can be easily performed at runtime (the process is called transcoding).
On top of that, KTX2 adds support for supercompression schemes. It’s a technique that further compresses transcodeable formats on disk. With these techniques, we can achieve KTX2 files, which are similar in size to JPEG, or even smaller sometimes.
[image from https://www.khronos.org/ktx/]
How to convert images to KTX
In order to convert your images to KTX you can use the official KTX-Software command line tools.
You can compile the command line tools from source, but the easiest option is to download the installer from the Releases section.
During the installation process make sure the “Command line tools” checkbox is ticked.
Inside the installation folder you will find the tool you need: toktx.exe.
Basic command:
| toktx.exe –encode uastc –zcmp 15 –genmipmap output.ktx input.jpg |
–zcmp: configures the compression level in disk.
–genmipmap: the whole mipmap chain will be generated and stored in the KTX file. This is recommended as generating the mipmap chain of compressed textures is expensive, so we should avoid doing it at runtime.
Another interesting option is –uastc_quality, which allows you to fine tune the quality vs compression speed.
| toktx.exe –encode uastc –zcmp 15 –genmipmap –uastc_quality 3 output.ktx input.jpg |
toktx has lots of options which you should definitely check out:
| toktx.exe –help |
Benchmarks
As a simple example, we use a simple sphere with a PBR material.
We created two identical materials, except for the fact one uses JPG images, and the other uses KTX images.
As you can see, using KTX drastically reduces VRAM usage. The whole 4 images add up to 128MB of VRAM when using JPG, vs 32MB when using KTX. The quality of the final image is similar, and you won’t notice the difference.
Additionally, it seems that for most of the images KTX occupies less disk space than JPG, although it might not always be the case.
For this test, we have converted the JPG images to KTX using the official “toktx” command line tool. Finding the best set of parameters to pass to this command line tool is an art as it involves playing with tradeoffs. You should try to find the most suitable parameters for your application’s images, taking into account quality/performance demands. For example, normal maps usually demand more accuracy than color maps.
These are the parameters we used for the previous example:
| color: & ‘C:\Program Files\KTX-Software\bin\toktx.exe’ –encode uastc –genmipmap –assign_oetf srgb –target_type RGB –uastc_quality 3 –uastc_rdo_l 4 –zcmp 20 .\Ktx\Bricks_color.ktx .\Jpg\Bricks_color.jpg
normals: & ‘C:\Program Files\KTX-Software\bin\toktx.exe’ –encode uastc –genmipmap –assign_oetf linear –target_type RGB –normalize –uastc_quality 3 –uastc_rdo_l 0.5 –zcmp 20 .\Ktx\Bricks_normals.ktx .\Jpg\Bricks_normals.jpg
pbr: & ‘C:\Program Files\KTX-Software\bin\toktx.exe’ –encode uastc –genmipmap –assign_oetf linear –target_type RG –uastc_quality 3 –uastc_rdo_l 1 –zcmp 20 .\Ktx\Bricks_pbr.ktx .\Jpg\Bricks_pbr.jpg
AO: & ‘C:\Program Files\KTX-Software\bin\toktx.exe’ –encode uastc –genmipmap –assign_oetf linear –target_type R –uastc_quality 3 –uastc_rdo_l 4 –zcmp 20 .\Ktx\Bricks_AO.ktx .\Jpg\Bricks_AO.jpg |
KTX in Evergine
We have added support for both KTX1 and KTX2 and all the platform-specific compressed texture formats in Evergine 2025.10.
This is great news for all applications, but especially for web applications, as its adoption can greatly improve load times.
You can now optimize your graphical applications with minimal investment: everything is seamlessly integrated into the engine and very user-friendly.
The user can import KTX2 files in the editor just like any other image format and use it in materials. The file extension needs to be “.ktx” or “.ktx2”.
The Evergine.ImageRuntime has been extended to allow loading KTX2 files.
If your GLTF files include KTX images (embedded or referenced), everything will work out of the box.
Related Posts
