How to properly encode normalmap as compressed texture

[Makio64]

left before compression ( png normal map with srgb metadata ) / right after compression as basislz

The command im using :
ktx2 create --format R8G8B8_UNORM --assign-oetf srgb --encode basis-lz --clevel 5 --qlevel 255 input output

For this test im using a model from sketchfab : https://sketchfab.com/3d-models/cut-fish-c9bcb782e5ef4d37bd8671f1f82a0fbc
I then render it in threejs viewer like : https://gltf-viewer.donmccurdy.com/ so if i use --normal-map it will not work correctly as it expecting rgb normalmap.

I try different setting but cant get a correct normal map without the square, any idea of what im missing ? thanks !

[MarkCallow]

First of all I don't know what you mean "without the square". What square? I see some compression artifacts but nothing extraordinary.

You should not use sRGB for normal maps as normals are not color data. sRGB encoding will completely mess up the normals. Also
never use --assign-oetf unless you know that the input file has incorrect colorspace metadata. If the input file is linear, as it should be, specify only --format R8G8B8_UNORM. If the input file is sRGB then use --convert-oetf linear so it is properly converted.

I presume by --normal-map you mean --normal-mode. --normal-mode creates a 2 component normal map and expects the normals to be normalized. A 2 component map allows the uncorrelated XY components to be separated with one in the RGB channels of the compressed texture, the other in the alpha channel. Compression of these, unlike the RGB channels is also uncorrelated. Therefore there will be fewer compression artifacts.

If the renderer does not support 2 channel normal maps then do not use --normal-mode.

[Makio64]

Thanks for your answer @MarkCallow !

Yes i was talking about the compression artifacts & the --normal-mode option which i shoudn't use as not supported by threejs.

For my use case im not the author of the 3d models and i will have to deal with .srgb normal sometime.
Changing the format to R8G8B8_SRGB and using --convert-oetf linear give the same rendering.

I will try to compress the normal with another compression than basislz, any suggestions for higher quality ?

Thanks !

[Makio64]

made it works with toktx --encode uastc --normal_mode --input_swizzle rgb1 --assign_oetf linear --assign_primaries none outputPath inputPath but got a bug using the equivalent with ktx create #836

Also I dont understand whats the goal of --input_swizzle rgb1 ?

[MarkCallow]

See #836 for my response on that.

Never use --assign-oetf unless you know for a fact that the input file has the OETF you are specifying and it differs from what the file's metadata claims. If you have to deal with an sRGB-encoded file as input for your normals you should do --format R8G8B8_UNORM --convert-oetf linear. It is safe to always use this combination because if the input file is already linear --convert-oetf becomes a no-op. For toktx use --convert_oetf linear.

The difference between what you had before and now is the UASTC encoding. That is what caused the improvement.

--input-swizzle rgb1 says replace the input file's alpha channel with 1. If your input file has only 3 channels it is not necessary but it does no harm. Even if the input file has 4 channels the option is probably not necessary as, if it contains properly prepared normals it is unlikely to have any non-one alpha values.

You can interactively experiment with the various compression options using the glTF-Compressor Tool especially, but not only, if your target is glTF.

[Makio64]

My use case is similar to the one in gltf-transform : taking the texture as a buffer directly from the .glb and the colorspace on normal map metadata is often null so we assign it in this case ( similar approach than https://github.com/donmccurdy/glTF-Transform/blob/main/packages/cli/src/transforms/toktx.ts ) .

The result works in most cases but I will use convert as much as possible in the futur. Thanks 🙏

[MarkCallow]

If there is no colorspace metadata then you have to use --assign-oetf. Hopefully you know what the colorspace is.

I looked more closely at the ktx create code. It turns out that implicitly converts the input to the nominal OETF of the specified format, if necessary. E.g, in the case of R8G8B8_UNORM it would convert to linear OETF. If the input has colorspace metadata then you only need to specify --format R8G8B8_UNORM there is no need for --convert-oetf linear. If no colorspace metadata assign it to whatever you know it to be and ktx create will convert from that to linear, if necessary.

[arpu]

there are some examples of usage for ktx create from @donmccurdy https://github.com/donmccurdy/KTX2-Samples/blob/main/encode.sh