partial loading

[AnonN10]

ktxTexture2_CreateFromMemory has KTX_TEXTURE_CREATE_LOAD_IMAGE_DATA_BIT flag, but how do I also skip reading the data from disk? Is there a way to calculate the KTX file size without including the image data so that I don't read more than needed from disk?

[MarkCallow]

If you use ktxTexture2_CreateFromNamedFile or ktxTexture2_CreateFromStdioStream and KTX_TEXTURE_CREATE_LOAD_IMAGE_DATA_BIT is not set, then only the header, levelIndex, etc. will be read from disk, modulo whatever buffering stdio may be doing. The data size is determined using fstat to get the file size. If you are reading a file yourself before calling ktxTexture2_CreateFromMemory you can also use fstat or stat.

[MarkCallow]

if the texture is packed into an asset archive I can't load it as a standalone file, ...

I see. Why do want to avoid reading the whole texture into memory from the asset file?

The intent behind being able to not load the data, via having KTX_TEXTURE_CREATE_LOAD_IMAGE_DATA_BIT unset, is to save memory while uploading textures to a GPU. Instead of reading the entire texture into a memory buffer, then calling an upload functions, you just call an upload function and it will read one level at a time into a buffer and upload it. If you call an encode or transcode function in this state they will load the entire texture before proceeding so it doesn't save any memory there.

[AnonN10]

Why do want to avoid reading the whole texture into memory from the asset file?

Because I only need to know the resolution and KV data. As a concrete example, in the editor I have a listing of all textures in the project which is being loaded in all entirety to be worked with, also I store sampler names in KV data. So loading all textures together with image data, only to read what sampler it uses and what resolution it has, is very wasteful, not to mention that it might be impossible to fit all images in RAM for a reasonably big projects. All in all, I don't need to load image data if I'm not going to be immediately using it, nor is it good to do any meaningless reads from the disk and wear it out for nothing.

[MarkCallow]

Because I only need to know the resolution and KV data.

For that you can read the fixed size KTX v2 header, 80 bytes. In there is the size of the texture and fields giving the offset and byteCount of the KV data. Using that info you can read the KV data. See lib/ktxint.h which has a struct matching the header layout. This low-level stuff is not exposed in libktx because its API is based around texture objects. But if there is some addition to the library that can help you with this. I'll be happy to look at a PR.

[AnonN10]

It's already good to know that there is at least a manual way to deal with it, thanks. One last question, would ktxTexture2_CreateFromMemory with KTX_TEXTURE_CREATE_LOAD_IMAGE_DATA_BIT unset be able to parse a buffer of size 80+KV bytes?

[MarkCallow]

... be able to parse a buffer of size 80+KV bytes?

No. After reading the 80 bytes, it calculates the size of the level index and reads that then it reads the dfd and kvdata and, if present, the supercompression global data. If not all that is there, you will get something like an unexpected EOF error.

After you've read the initial 80 bytes you can use the levelCount field, replacing with 1 if it is zero, to calculate the size of the level index and add that size to the dfd, kvd and sgd byte counts to tell you how much more to read to have the complete header info. You can then pass all of that to ktxTexture2_CreateFromMemory.