Is the texture a normal map?

[Leadwerks]

Is there some way to detect whether a supercompressed texture is meant to be decompressed to a normal map format (BC5 on PCs). This was an issue in Basis and I was hoping KTX would add this data to the file. I notice if I used the --normal_map setting the blue channel is removed, but how to detect this in the file format?

[lexaknyazev]

That data is available in the KTX file, please see Section 3.10.2.

[Leadwerks]

This color model provides channel Ids, e.g. KHR_DF_CHANNEL_UASTC_RGB that must be used to indicate the effective number of components in the data. Consumers use this information to help select a transcode target. The following ids are valid and must be used for the type of data indicated.

How does the color model provide channel IDs?

I'm also looking in the output of toktx and it says all supercompression parameters will be stored in the file metadata:
Any specified ETC1S / BasisLZ and supercompression options are recorded in
the metadata item @c KTXwriterScParams in the output file.

However, the resulting KTX files, when loaded with libktx, report a kvDataLen value of 0, and the kvData pointer is NULL.

[lexaknyazev]

Channel IDs are a part of DFD. The spec has an example of BasisLZ/ETC1S R+G texture.

[Leadwerks]

Thank you but I don't understand that diagram.

[Leadwerks]

It looks like ktxTexture2_GetNumComponents() can return this information, but on closer inspection, the two-channel color formats are treated as luminance / alpha:
https://github.khronos.org/KTX-Software/ktxtools/toktx.html

So relying on the number of channels may not be a good idea.

[lexaknyazev]

The number of channels may be the same but the channel IDs would be different for RG and LA, assuming that the KTX file was created with correct options.

[Leadwerks]

Okay, here is how to detect that the --normal_map setting was used by the generator:

				bool isnormalmap = false;
				unsigned int len;
				std::string key = "KTXwriterScParams";
				void* val;
				ktxHashList_FindValue(&ktx->kvDataHead, key.c_str(), &len, &val);
				String s = String((const char*)val);
				if (s.Find("--normal_map") > -1) isnormalmap = true;

However, I would still like to be able to retrieve the channel IDs and use that as well. This setting only works with the ECTS compression method.

[MarkCallow]

For anything but transcodable textures, ktxTexture2_GetNumComponents() returns the actual number of components in the texture. For transcodable textures it returns a result based on the DFD channel ids. It will report luminance-alpha textures as having 4 components (channel id RGBA for UASTC, RGB + AAA for ETC1S) because you typically don't want to use the 2 component compressed formats for LA. Normal maps will be reported as having 2 components (channel ids RRRG for UASTC and RRR + GGG for ETC1S). However there may be other uses for 2-component textures so the component count is not a guarantee.

I am thinking about adding a new metadata item KTXnormalMap which, if present, will definitively state the texture is a normal map. This metadata item could be used with uncompressed 3-component normal maps as well as compressed and transcodable 2-component maps. I'd like to know your opinions about this.

@Leadwerks kvDataLen will only be non-zero if KTX_TEXTURE_CREATE_RAW_KVDATA_BIT is specified in createFlags when a Create* function is called. The default behavior is to build a hash list on which you can use ktxHashList_FindValue. Please note that --normal_mode will only be set for ASTC, UASTC and ETC1S compressed textures so this is not a general solution.

[lexaknyazev]

@MarkCallow
Maybe a lower-hanging fruit is to add a public API to get DFD fields. Currently it seems that apps need to deserialize DFD themselves.

[Leadwerks]

I am thinking about adding a new metadata item KTXnormalMap which, if present, will definitively state the texture is a normal map. This metadata item could be used with uncompressed 3-component normal maps as well as compressed and transcodable 2-component maps. I'd like to know your opinions about this.

This seems more versatile than guessing based on component counts and channel IDs. Some files may store a normal map in an uncompressed format, for example. The application could make more intelligent decisions about how to treat the file.

I don't have a very strong preference as long as a method is chosen, but it does seem like something is needed for practical usage, at least when a transcodable format is in use.

[Leadwerks]

However there may be other uses for 2-component textures so the component count is not a guarantee

You know, the question might not really be whether it's a normal map, but whether it should be transcoded into an RG format. This is only applicable to supercompressed textures, and those are always going to be transcoded into some memory-compressed format. No one is going to use lossy compression for an image and then decompress it to RGBA.

If a supercompressed texture is stored with two channels, and those channels are red and green, I can't think of any reason those would not always be transcoded into BC5 format, at least on PC.

[MarkCallow]

You know, the question might not really be whether it's a normal map, but whether it should be transcoded into an RG format.

Exactly. And for this purpose ktxTexture2_GetNumComponents() provides the information you need.

[Leadwerks]

Well, except for the channel IDs. I'll start with this approach but in the future I think a new command or some example code to detect the channels in use will be needed.

[MarkCallow]

For transcodable textures ktxTexture2_GetNumComponents() uses the channel ids to determine the value it returns. You don't need any more information to determine an appropriate transcode target.