KHR_texture_float_bc6h: Compressed float format for material textures

[rsahlin]

The purpose of this extension is to enable use of HDR material textures by means of compressed texture float format VK_FORMAT_BC6H_UFLOAT_BLOCK.
KTX v2 shall be used as a container, the extension is defined in a way that follows the paradigm of KHR_texture_basisu.
To decode textures this package can help:
https://github.com/KhronosGroup/BC6H-Decoder-WASM

The intended usecase for this extension is any usecase where HDR image resources needs to be specified, for instance in an environment map (IBL) but it could be relevant for any material texture where increased range is wanted.

The format VK_FORMAT_BC6H_UFLOAT_BLOCK is chosen based on previous discussions with input from, Alexey, Don, Norbert and others.

[lexaknyazev]

For material textures, there's virtually no benefit in using high-precision textures with the standard (aka bt.709) gamut. Bringing WCG material texture support to glTF would require much more infrastructure updates than adding a new pixel format.

[rsahlin]

AFAIK the BT709 standard supports a bitdepth of 8 or 10 - could you please explain why this would not be beneficial in our usecase?

[lexaknyazev]

Because to get that benefit in rendering context, all these specific conditions should be met:

• Original texture source data is authored with precision greater than 8-bit sRGB, so there is actual data in those extra bits.
  • Note that 8-bit sRGB has roughly 12 bits of linear precision for values near zero and about 7 bits of linear precision for values near one.
• That extra precision is amplified enough during shading so that it makes a difference on a standard screen after the tone mapping.
  • A good example would be a simple linear gradient that is stretched over a very long object so that a single 1/255 step takes lots of screen space thus making that gradient look quantized.

[lexaknyazev]

Higher-fidelity material textures and non-prefiltered IBLs have different input data requirements and unlikely to be served by a single extension.

[rsahlin]

So what is your suggestion?

[lexaknyazev]

There were couple attempts at defining an IBL extension within the current ecosystem. My suggestion is to converge there. In parallel, we could work on WCG support in glTF. This is a big topic with major ecosystem implications, so it should start with a high-level discussion.

[rsahlin]

Sure - I agree with that.
However, in the meantime I think we could make progress with either BC6H or RGB9E5 which are needed in order for us to define enviroment light extension.

[lexaknyazev]

If the immediate goal of these extensions is to provide storage support for IBL, that's fine. Still, I wouldn't expect the finalized IBL extension to support more than one storage option.

[rsahlin]

If the immediate goal of these extensions is to provide storage support for IBL, that's fine. Still, I wouldn't expect the finalized IBL extension to support more than one storage option.

Well, the goal is to provide support for float source images (textures) - one immediate usage of this would be the IBL.
Written the way it is it shall also be possible to use as a texture source for materials, ie the same way that KHR_texture_basisu is used.

[lexaknyazev]

glTF does not prescribe runtime behaviour so this statement cannot be included. If there's an application-specific use-case, this should be a vendor extension.

[rsahlin]

Removed wording and added conformance section.

[fire]

Is there are corresponding uncompressed float format? Something like tinyexr compiled to wasm? Feel free to direct me to another location.