Blender 5.0 introduces HDR support for Linux/Wayland. It is provided as an experimental option as we have tested it with limited number of systems/setup. We would like feedback how it works on other setups as well.
No official plans yet. Linux/Wayland support was easy as it fitted in what we already had laid out. We did test Windows, but it had limitations that required more work than expected. Any developer can pick it up. In the near future my own planning doesn’t have room for it.
Hello,
i will test as soon as possible with an ASUS ROG Swift OLED PG32UCDP but i need to assemble first new system components ( with a 9700 xt ) and upgrade Fedora 42 and GNOME 48 .
Are 10 bit ( not HDR ) monitors supported too ? i use also a Benq PD3200U.
Thank you !
I’ve been testing blender-5.0.0-alpha+main.53578d33aeaa-linux.x86_64-release on Arch Linux, AMD 7900xtx, AW3225qf, KDE Plasma for a couple of days now, no issues so far. HDR looks good.
Works as described on KDE Plasma with an Nvidia GPU connected to an LG C2 TV.
I did notice that bright areas in the HDR viewport tend to overwhelm low opacity overlay elements. While that makes for a nice stained glass window effect, it’s not so good for readability.
Are there plans for supporting HDR output targets with other view transforms? The extra peak brightness is nice, but I direly miss the smooth highlight roll-off and color attenuation of a good tone mapper. I have my TV set to HGIG mode, which effectively prevents double tone mapping by disabling its built-in adjustments.
I had a quick try replacing the Blender config.ocio file with one for ACES.
All the Display Devices presets of the ACES config seem to leave the High Dynamic Range option available, enabling it outputs HDR brightness as long as View Transform > Un-tone-mapped is set. Display Device > Rec.2100-HLG - Display functions well as a default look without needing to tweak Exposure and Gamma, and Look > ACES 1.3 Reference Gamut Compression seems to prevent clipping issues with vibrant colors. It still lacks some of the high brightness color bleaching that AgX does very well, but overall this a much nicer HDR look than Standard transform in the default config, I’m pretty impressed.
A little viewport quirk with the ACES config is that the colors in all presets look overly vivid in Material Preview compared to Rendered view.
The issue is that blending is happening between bright pixels and sRGB UI elements. We should check with the UI team about possibilities to make the theme more HDR compatible. I guess this is already the case on Metal.
Blender isn’t in control when supporting more view transforms. Blender only makes the UI element inactive for a fix number of known view transform names, but there isn’t any logic being executed. The OCIO configuration is fully in control to determine if HDR works. If a view transform inside the OCIO configuration does “clamping” it will not be able to display HDR content.
Just to expand on Jeroen’s comment as I helped test the Windows side.
On Windows, NVIDIA GPUs would advertise HDR support to Blender while Windows was in SDR mode. This resulted in Blender launching in HDR mode, which resulted in some content displaying incorrectly in this configuration.
Not really a Blender user but I tested it on my Alder Lake ThinkPad with an 2.8k OLED screen running Debian testing/trixie and GNOME 48. Seemed to work as expected when following the instructions. Dragged the Blender window between the internal HDR enabled screen and external monitors that only support SDR and saw the expected difference in appearance.
@Jeroen-Bakker@Alaska Btw after looking through the code, I think we don’t have wayland compositor’s HDR enablement detection mechanism?
If we enable HDR in blender but not in compositor config, this seems to be some kind of wide-gamut implementation, but this highly relies on compositor implementation. Maybe we should still disable HDR if compositor hasn’t enabled that?
I hope this isn’t too out of scope here, but thanks to Eary already working on AgX for Rec.2100 HLG and PQ, I was able to adapt it to the extended sRGB output used here for HDR.
That’s a drop-in replacement for the Blender OCIO config with all the original definitions, so it doesn’t mess up Blender’s internal color reproduction like the ACES config does.
Not sure this is a great solution, but for convenience I made presets for 1.5x, 2x, 3x, 4x, 5x, and 10x extended sRGB brightness, with 10x representing the full range from the 100 nits SDR reference to 1000 nits HDR of HLG. The low tonal range looks exactly the same between AgX SDR and HDR, and the higher range is expanded to coincide with each peak brightness target. The highlight roll-off happens at the same scene-referred brightness level in all cases, if I’m not mistaken, so no additional highlight recovery between AgX SDR and HDR.
It utilizes the existing sRGB definition for the final color space conversion, so that assumes extended sRGB wants the same compound (linear + exp 2.4) transfer curve. I checked that it does indeed output negative float values for more pure colors than sRGB could display, as long as no compositor nodes clamp negative values. Might be worth some future consideration allowing negative values to go through more types of nodes.
But yeah in short, I think AgX HDR looks amazing on a capable display.
