Relax DFD transfer function restrictions

[lexaknyazev]

The spec says:

If vkFormat is one of the *_SRGB{,_*} formats then transferFunction must be KHR_DF_TRANSFER_SRGB and vice-versa. For all other vkFormat values, except VK_FORMAT_UNDEFINED, transfer_function must be KHR_DF_TRANSFER_LINEAR.

The second rule is impractical for the following reasons:

• 10- and 12-bit data in formats like A2R10G10B10_UNORM_PACK32 may be legitimately encoded with PQ, HLG, or even sRGB transfer function. The lack of dedicated GPU API formats to achieve correct hardware filtering is a much smaller issue than the KTX 2.0 inability to store the data.
• Legacy packed formats like R5G6B5_UNORM_PACK16 are almost never used to store true linear values because of the reduced precision. So again, KTX 2.0 cannot be used to store that data correctly.

Proposal Replace the second normative rule with an implementation note explaining common use cases and pitfalls.

[MarkCallow]

The whole situation is unfortunate. Are you aware of any efforts to provide hardware support for other transfer functions or for programmable blend stages?

The 4K HDR broadcasts here are 10-bit with HLG. I can't think off hand of any case where my TV blends any UI elements with the broadcast image. Everything is overlaid. I wonder if it is because they can't do proper blending.

I agree that we need to be able to store such formats in KTX 2.0. I expect hardware will eventually provide support. Please propose a PR along the lines you suggest. I will have to revise ktx2check. Please include actionable statements or recommendations in the implementation note that can be used by it and by toktx, if support for any of these formats is added to it or its descendants in future.

We should get the proposal reviewed initially by the PBR and 3D Commerce TSGs to get the benefit of their expertise.

Regarding R5G6B5_UNORM_PACK16, historically in both OpenGL ES and M3G they were treated as linear. Neither supported sRGB textures. The fact that the stored values may be non-linear is accidental* due to all the screens they were used with having sRGB transfer functions.

* Except for those very few people who truly understood what was going on.

[lexaknyazev]

Are you aware of any efforts to provide hardware support for other transfer functions or for programmable blend stages?

Somewhat.

• MTLPixelFormatBGRA10_XR_sRGB. 10-bit surface format with hardware sRGB transfer function. Clearly, it was added for display-p3 mobile screens.
• Programmable blending is supported via various techniques (framebuffer fetch, image load/store with barriers, etc.) on all modern platforms.

Regarding R5G6B5_UNORM_PACK16, historically in both OpenGL ES and M3G they were treated as linear. Neither supported sRGB textures. The fact that the stored values may be non-linear is accidental* due to all the screens they were used with having sRGB transfer functions.

To the best of my knowledge, developers and users simply ignored mathematical inaccuracies caused by doing linear filtering and lighting on non-linear values. So to properly describe the rendering intent, old data should be stored in KTX 2.0 as R5G6B5_UNORM_PACK16 + KHR_DF_TRANSFER_SRGB. Treating old content as having linear transfer function in modern EOTF-aware pipelines would be incorrect.

I'll open a PR.