KHR_gaussian_splatting_wide_gamut_color #2539
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,86 @@ | ||
| <!-- | ||
| Copyright 2015-2025 The Khronos Group Inc. | ||
| SPDX-License-Identifier: CC-BY-4.0 | ||
| --> | ||
|
|
||
| # KHR_gaussian_splatting_wide_gamut_color | ||
|
|
||
| ## Contributors | ||
|
|
||
| - Alexey Knyazev, Khronos | ||
| - Adam Morris, Cesium | ||
| - Zehui Lin, Huawei | ||
| - Michael Nikelsky, Autodesk | ||
|
|
||
| ## Status | ||
|
|
||
| Draft | ||
|
|
||
| ## Dependencies | ||
|
|
||
| Written against the glTF 2.0 spec. Extends KHR_gaussian_splatting. | ||
|
|
||
| ## Overview | ||
|
|
||
| This extension adds wide-gamut color support to the KHR_gaussian_splatting extension. It introduces several additional wide-gamut color space options for the `colorSpace` property. These additional color spaces enable more accurate color representation for high dynamic range (HDR) content and wide-gamut displays when using Gaussian splatting in glTF assets. | ||
|
Member
There was a problem hiding this comment. WCG does not imply HDR. Could we be more specific about the intended use cases here? There was a problem hiding this comment. It would be helpful to add informative language somewhere explaining that the splats are intended for alpha blending in the specified linear or non-linear color space. This behavior differs from traditional meshes where people should first convert colors to linear color space before performing any other color operations. |
||
|
|
||
| ## Additional Color Spaces | ||
|
|
||
| | Color Space | Description | | ||
| | --- | --- | | ||
| | BT.2020-ITU | BT.2020-ITU color space. | | ||
| | BT.2020-linear | BT.2020 linear color space. | | ||
| | BT.2100-PQ | BT.2100 PQ (Perceptual Quantizer) color space. | | ||
| | BT.2100-HLG | BT.2100 HLG (Hybrid Log-Gamma) color space. | | ||
| | Display-P3 | Display P3 color space. | | ||
|
Comment on lines
+31
to
+35
Member
There was a problem hiding this comment. glTF strings are case-sensitive. Could we align lower/upper case usage here? Not a very strong opinion but I'd prefer making these enums all-lowercase (or at least capitalizing Linear).
Comment on lines
+29
to
+35
There was a problem hiding this comment. It would be clearer if we explicitly state what color primiaries and transfer characteristics are being used for each color space. For example, describing BT.2020-PQ as "BT.2020 color primaires and SMPTE ST2084 Perceptual Quantizer (PQ) transfer function". PQ is defined for HDR, while BT.2020 defines SDR and WCG. BT.2100 extends BT.2020 to HDR, but using the same color primaires. |
||
|
|
||
| ## Extending the base KHR_gaussian_splatting extension | ||
|
|
||
| The base `KHR_gaussian_splatting` extension is required for this extension to be used. The new `colorSpace` values can be used in place of the existing ones defined in the base extension. | ||
|
|
||
| To extend the base extension, include both extensions in the glTF asset's `extensionsUsed` array: | ||
|
|
||
| ```json | ||
| { | ||
| "extensionsUsed": [ | ||
| "KHR_gaussian_splatting", | ||
| "KHR_gaussian_splatting_wide_gamut_color" | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| Then add the `KHR_gaussian_splatting_wide_gamut_color` extension to the `extensions` property of the `KHR_gaussian_splatting` object: | ||
|
|
||
| ```json | ||
| { | ||
| "meshes": [ | ||
| { | ||
| "primitives": [ | ||
| { | ||
| // snip... | ||
| "extensions": { | ||
| "KHR_gaussian_splatting": { | ||
| "colorSpace": "Display-P3", | ||
| "extensions": { | ||
| "KHR_gaussian_splatting_wide_gamut_color": {} | ||
| } | ||
|
Comment on lines
+56
to
+66
There was a problem hiding this comment. While gaussian splatting extension is in There was a problem hiding this comment. It has to be on inside the primitive, as e.g. another primitive in the same mesh is e.g. common, triangle based glTF asset. There was a problem hiding this comment. Okay. If we are going to add color space for other kinds of primitives, then in |
||
| } | ||
| } | ||
| } | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| There are no additional properties introduced by this extension; it solely extends the `colorSpace` options of the base extension. | ||
|
|
||
| ## Known Implementations | ||
|
|
||
| - TODO: List of known implementations, with links to each if available. | ||
|
|
||
| ## Resources | ||
|
|
||
| - BT.2020: https://www.itu.int/rec/R-REC-BT.2020 | ||
| - BT.2100: https://www.itu.int/rec/r-rec-bt.2100 | ||
| - Display P3: https://www.color.org/chardata/rgb/DisplayP3.xalter | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Saying "wide color gamut" (here and throughout) would be more standard than "wide-gamut color", which is often used as an adjective.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To include HDR and WCG in this extension, naming as color_space should be better.