Oolite on HDR Displays

[Simba]

I think the approach to implementing HDR is wrong. For a visual demonstration, I have attached a visualization of color spaces on the RGB color model. It shows that, as a rule, narrower spaces are part of wider ones. That is, when honestly converting, for example, a bitmap image from sRGB to DCI-P3, the colors should not become more saturated. On the contrary, they should remain in the same positions inside the sRGB triangle, but taking into account the output on the DCI-P3 display, you should not see any difference. In the context of a game, this means that by default, any object with sRGB textures should look the same in wider color spaces.
Then why do we need a wider color space? First, you can use textures originally made for DCI-P3. Secondly, certain visual effects can strongly distort colors (for example, a different spectrum of a Star, effects from shields, when hit by lasers, etc.).
I don't know exactly how the renderer works, but I think it first calculates the colors in the coordinates of the color model, and only before output converts it to an 8\10\12 bit format for the monitor in accordance with the target color space, or even focusing on the coverage information from EDID.

[another_commander]

.
Then why do we need a wider color space? First, you can use textures originally made for DCI-P3. Secondly, certain visual effects can strongly distort colors (for example, a different spectrum of a Star, effects from shields, when hit by lasers, etc.).

What you are describing is what happens with Oolite. We don't use dci-p3 textures of course - games that use such textures can be counted with one hand, but under default color saturation conditions, colors in Oolite are in the srgb color space and only effects such as lasers or hyperspace jumps etc. will cause some of them to go into dci-p3 or bt2020 territory. These extended color spaces are normally entered in Oolite only as a result of lighting shader maths. The game, as far as I can tell on my computer, looks the same between sdr and hdr saturation-wise and I have comparison shots between sdr and hdr to show for it. Now, if you go ahead and raise the in-game color saturation using the SetColorSaturation(0.0 .. 2.0) console command, then more colors will start becoming so saturated that srgb cannot contain them anymore and they start spilling into dci-p3 and bt-2020. You can test that by running Lilium's Reshade hdr analysis shaders on the game or by screenshooting and viewing the results in SKIV. If you want I can show you my results because I have already tested this.

I don't know exactly how the renderer works, but I think it first calculates the colors in the coordinates of the color model, and only before output converts it to an 8\10\12 bit format for the monitor in accordance with the target color space, or even focusing on the coverage information from EDID.

Actually it delivers an RGBA16F scRGB linear image to the graphics driver, which internally performs the conversion to 10-bit BT-2020 color space for display output on an hdr screen. No color model coordinates calculations occur anywhere, because scRGB and sRGB use the same color coordinates (color primaries, to be more precise), with scRGB just being bigger and accepting negative colors (which, btw, are the colors that correspond to dci-p3 and bt-2020). Most games do either this or render PQ 10-bit RGB10A2 output directly, with color-space conversions as required, the latter being the most common case.

Also, Oolite deliberately avoids referencing the EDID. Experience shows that a lot of times times it is completely off and contains bogus info, so best not use it until we start seeing accurate information becoming the rule.