Our support for the KTX image format was greatly improved, to make it the best format for images (in some cases — when you don’t care about image size on disk, but care about loading time).

Note that the post below discusses various details, but you don’t really to do anything special to benefit from these improvements. Just use KTX, as any other image, for your textures / images. The snapshot Castle Image Viewer can be also used to view KTX files.

Improvements:

1. KTX loading has been optimized for (very often) cases when the entire image contents can be loaded from disk to memory in one Stream.ReadBuffer call. This makes reading KTX lighting-fast in many cases.
   • To get some logs about it, you can use CastleInternalCompositeImage and set global LogVerboseKtx to true. We will then send to log additional messages when the optimal loading / saving path was used. As the name implies, this is internal functionality, if you use it: be prepared we may break it in the future (but then, this is just additional logging).
2. The support for 16-bit KTX images, which previously resulted in 8-bit data (we lost precision) and only worked for grayscale data, has been extended: they now result in float-based (32-bit) data, and support all channel variants (G, GA, RGB, RGBA).
   • Note that I didn’t have testcases for all possibilities. You’re welcome to test the code on your KTX files, and report a bug if it fails!

   • Note that we also support KTX images with 32-bit float data, which load/save fast to our float-based image classes like TGrayscaleFloatImage. This didn’t change. We just changed 16-bit support now to also result in TGrayscaleFloatImage, not in TGrayscaleImage.

3. We can now save KTX files (without any extra libraries necessary, just pure Pascal code).

   • This also means we can auto-generate trivial/downscaled KTX files from your files, which is great to speedup loading time (at the cost of extra disk space), see description here.

Having fun with KTX? Please support us on Patreon.