Reference images (empties) with >8 bpc color depth show unexpected banding

[flavonol]

Hi all,

I’m not sure if this is really an issue with Blender (I’m leaning toward no; here’s a relevant AskFedora thread), but at the very least, perhaps the scene
I’m using to troubleshoot this issue will be useful for someone else.

Since I’m using a display that is supposed to support color depth of 10 bits per channel, I decided to see if it was working by loading in a gradient image by jursonovicst on GitHub as a reference image. However, the 8-bit and 10-bit gradients looked exactly the same.

I decided to further investigate this by rendering a scene in blender that I hoped would show substantial color banding on a display with only 8 bits per channel color depth and a lot less on a display with higher color depth support. Supposedly, dark, foggy scenes show color banding, so I decided to render a dimly lit sphere with a volume scatter shader. I used the Rec.2020 color space here, but past testing with sRGB produced similar color banding results for me. The real-time Cycles viewport rendering of the sphere looks much better in that regard.

sphere_volume.blend (1.0 MB)

Render with color depth set to 16-bit:

Render with color depth set to 8-bit:

Importing the 16-bit render as a reference image resulted in some pretty bad color banding. The only application I’ve found to display that 16 bpc render with less color banding compared to an 8 bpc version was GNOME Image viewer.

Any insights or troubleshooting ideas would be appreciated. Thanks.

System Specifications

Distribution: Fedora LInux 40 (Workstation Edition)
GNOME Version: 46
Monitor: Acer ET322QK wmiipx (connected via DisplayPort)
Graphics card: Radeon RX 5700 XT

Edits

• Linked AskFedora thread
• Noted the better viewport rendering

[Okidoki]

Using gmic’s histogram feature with only showing 256 levels for both for comparision 16bit first/ 8bit second):
for d in 8 16 ; do gmic $d-bpc_volume.png +histogram 256 display_graph 400,300,3 -o histo$d.png; done

The overall distribution seems the same…

But this is for a very narrow area (peak) on the left side:

…so IDK what you expected.

[flavonol]

Would you be willing to explain what you’re demonstrating here and how it relates to importing images as references/empties?

[Okidoki]

Oh yes… i forgot to mention that displays are general “very bad” in darker areas… so the 10-bit of yours alone may not be enough to see soem difference but the display itself has to be of very good “dark area contrast something” IDK the actual term…

But anyway:
There was/is also:

Supporting HDR workflows in Blender

So it depends largely on the supporting drivers and settings, workflows…