Oolite on HDR Displays

[Cholmondely]

I guess both the readme distributed with the game and the wiki are good places to have this information available.

How would you suggest adding it to the wiki?

A "HDR" page. Or a displays page?

[another_commander]

A page entitled HDR would be fine I guess

[Cholmondely]

A page entitled HDR would be fine I guess

Here's a feeble atttempt at something I'm ignorant of. I'm presuming that a screenshot is pointless. Please edit it to death!

[another_commander]

 HDR wiki page is now up.

[another_commander]

I have implemented support for saving HDR snapshots in EXR format. This is much better than Radiance HDR; it supports expanded gamut colors, for starters. It is also more widespread in the graphics industry, meaning that there are more apps available that can open it out of the box. Although slower to encode than Radiance, in practice I did not see a measurable difference when saving an HDR screenshot. The only drawback compared to Radiance that I can see is size, as EXRs are massive (11.8MB for a 1920x1080 screen vs 4.5MB with Radiance). But at the very least, we now have the option to choose our format.

Right now choosing EXR or Radiance happens at compile time, but probably this could be turned into a .GNUstepDefaults option in the future. We have test binaries available on github ( https://github.com/OoliteProject/oolite ... 0592041935 ) if you want to have a go at it. The code is at the EXRSnapshots branch.

The implementation uses the tinyexr (written in C++) and miniz libraries and has been designed to accommodate Linux in the future. If/when we have HDR support on Linux, adding the same feature there should be just a trivial manipulation of the GNUmakefile. As it stands right now, Linux binaries should see no change other than an info message in stderr that the feature is pending implementation, in case anyone tries to call the SaveEXRSnapshot function in the code.

[another_commander]

HDR snapshot file format is now a user preference in the EXRSnapshots branch. Default is EXR, but you can set the .GNUstepDefaults key "hdr-snapshot-format" to make it save Radiance .hdr snapshots like this:

Code: Select all

"hdr-snapshot-format" = .hdr;

The leading dot is optional, Oolite will understand the extension with or without it. If the key is missing we default to .exr. If the user tries to be clever and enters any random string rather than the allowed "[.]hdr" and "[.]exr", a warning will be posted in the log and .exr will be selected by default anyway.

We are very close to pull request with this, I believe.

[another_commander]

As it turns out, the escessive size of EXRs I was complaining about earlier was due to me not having activated image compression during my tests, With just one little line of code, added in commit 181c4f3, EXR sizes are now very reasonable and directly comparable to Radiance .hdr ones. Depending on the image content, sizes of a 1920x1080 snapshot can range from about 3MB to 6.5MB instead of 12MB.

So defaulting to EXR as our snapshot format for HDR is definitely the way forward.

[Simba]

I would like to report a few bugs:

1) I tried to set the maximum brightness value to less than 400 nits (in my example it is 310 nits), having previously edited "descriptions.plist". But when I select my value, nothing happens, and after exiting the settings menu and returning back, it turns out that the value is set to 400 nits. In the end, I was able to set the desired value only by editing ".GNUstepDefaults".

2) For some reason, changing the paper white brightness distorts the colors of the original SDR content. An example with XenonUI in the screenshots (see the gradients near the block headers). The value without distortion is 200 nits.
SDR
200
170
120
100
80

If you increase the brightness, for some reason the background grid appears:
210
220
280

[another_commander]

Thanks for the post, much appreciate the time taken to test and provide feedback.

Regarding point 1, I have been able to reproduce the issue and there is indeed a small problem when the user tries to manually add a max brightness value which is less than the minimum expected by the game, which is 400 nits. There are two ways to resolve this:

• Let the player apply any value they set in descriptions.plist. This would be the more transparent way and probably what most players would expect to see. If you set your value at 310 nits, you expect to see that appearing in the max brightness slider.
• Respect the limits set by the game. Currently, for the maximum brightness setting those are 400 nits for low and 1000 nits for high. Settng any max brightness to a higher or lower value should be rejected by the game and ignored.

I am leaning towards the second one. The problem with the first is that it would allow any value and that could lead to a completely messed up image, because there would be nothing stopping the player from e.g. setting a paper white value higher than the manually defined maximum brightness. Error checking these edge cases can be messy. So I think that I will change it so that your 310 nits value will be ignored and the game will stick to 400 even if you add 310 in descriptions.plist.

For anyone interested, by leaving the max brightness at 400 nits you actually get the game to tone map to around 320 nits. I know, it doesn't make sense, but 400 nits is the minimum VESA standard for HDR and my own laptop can output a max of around 350 nits, so I had to test with what I actually have. That's why currently it is set so that the 400 selection will actually tone map to whatever my laptop can achieve (which, coincidentally, is what you want Simba). In the future I can probably adjust it a bit so that max brightness 400 actually outputs 400 nits and maybe add 350 nits as an extra selection.


Regarding point 2, maybe I am missing what you mean, but what you describe is expected behavior. Paper white is just a setting that tells Oolite how many nits an object with rgb color (1.0, 1.0, 1.0) emits. So if you set paper white to 140 nits, rgb (1,1,1) will emit 140 nits and if you set it to 280 nits, it will emit 280 (leaving less space until 310 or 400 or whatever for highlights. If you set paper white to be equal to your maximum brightness, then all you are achieving is a very bright SDR image). So you can consider it more or less as a generic overall brightness slider. Changing its value will dim or make on-screen colors brighter (without exceeding max brightness). The background grid you mention is expected to appear at high paper white values; it is information already present in the background image and brightening said image up just makes the grid more easily visible. I don't think there is any problem there. If I am missing something, please get back to me with some more details.