Colors with depths > 8bpc are not displayed correctly (except maybe in GNOME image viewer?)

My system specifications are at the bottom.

Hi all,

I have a display that ostensibly supports 10 bits per channel (bpc) color. However, almost any attempt to view gradients/dim images with a color depth greater than 8 bits per channel results in notable color banding. As I understand it, greater color depth than 8 bpc should mean less color banding, not the same amount or more. To download the images I tested with, see my Blender Artists post.

Also, Firefox, Chromium & Chrome all return a value of 24 when I enter screen.colorDepth in their respective consoles, even though Chrome is not required to always output 24. 10 bits per channel should result in a total color depth of 30.

A little over a week ago, after a brief discussion on GNOME Discourse, I opened bug #3512 for GNOME mutter, then closed it after a contributor suggested the issue was at the application level rather than in the compositor. This made sense to me at the time, but given how little success I’ve had across various applications, I figured I’d document my findings here.

Every test I’ve done has left me more confused than the last. I would greatly appreciate any insight & troubleshooting ideas. Thanks!

Applications/software tested:

Note: None of the below applications were installed via Flatpak.

GNOME image Viewer:

  • This is the only piece of software that displays all test images the way I expected.
  • jursonovicst’s gradient displays correctly, with less noticable color banding in the 10-bit gradients.
  • Sphere render displays correctly, with less noticable color banding in the 16 bpc version.

GNOME desktop background:

  • jursonovicst’s gradient displays equivalent color banding between 8-bit and 10-bit gradients.
  • Banding is worse in 16 bpc sphere render vs. the 8 bpc version.

Krita:

  • jursonovicst’s gradient displays correctly, with less noticable color banding in the 10-bit gradients. Color space used: “High Dynamic Range UHDTV Wide Color Gamut Display (Rec. 2020) - SMPTE ST 2084 PQ EOTF”
  • Banding is more noticable in the 16 bpc version when it is loaded in any of several color spaces I tried. When loading the 8 bpc option, I was not given the option to select a color space (maybe I’m just bad at Krita, but I couldn’t find a setting that corrected this).

Blender:

  • jursonovicst’s gradient displays equivalent color banding between 8-bit and 10-bit gradients when imported as a reference image.
  • Setting the viewport sampling to be equal to the final render results in almost no color banding on the sphere.
  • Importing the 16 bpc sphere render as a reference image results in very noticable color banding.

GIMP:

  • jursonovicst’s gradient displays equivalent color banding between 8-bit and 10-bit gradients.
  • Comparable, but not identical color banding is shown for the different versions of the sphere render.

Firefox & Chrome:

  • jursonovicst’s gradient displays equivalent color banding between 8-bit and 10-bit gradients.
  • Banding is worse in 16 bpc sphere render vs. the 8 bpc version.
  • Entering screen.colorSpace in the console returns a value of 24.

Hollow Knight (launched via Steam):

  • Substantial color banding exists in dark scenes. Launching with -force-opengl doesn’t affect this.

Minecraft with Iris shaders:

  • Substantial color banding exists in dark scenes.

Specifications

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

Edits

Clarified Blender test results.
Corrected spelling.
Added Minecraft to the list.

Wayland or X11?

I’m using Wayland.

What happens when you try with X11? I don’t think all the color management workflows are complete in Wayland.

When I try X11:

  • GNOME Image Viewer now displays the 16 bpc sphere render with more pronounced banding. (worse behavior than before)
  • GNOME desktop background displays equivalent color banding between 8- & 10- bit gradients. (same behavior as before)

I didn’t try to recreate the other tests, as this behavior seemed immediately worse than on Wayland. If you think it’s worth retesting the other applications, I can try, but it’ll be a couple weeks before I can get to that.

I would try with Krita.

Krita behaves the same way on X.org as it did on Wayland.

1 Like

https://docs.gimp.org/2.10/en/gimp-image-precision.html

GIMP correctly detects the precision of the images I open in it, but it only displays them with up to 8 bits per channel (based on the color banding I see). Unfortunately, I don’t think that thread addresses this issue.

1 Like

Regarding the desktop background, I’ve been informed that mutter depends on the library GdkPixbuf to load images. Since GdkPixbuf only supports colors with up to 8 bits per channel, it follows that desktop backgrounds are limited to that color depth.

Regarding Blender, the current state of displaying colors is described in the Blender Projects thread Supporting HDR workflows in Blender.

1 Like