Current status of 30-bit (10 bits per channel) color depth framebuffer support in GIMP?

Previously in November 2020 on the mailing list I discussed with @barefootliam (I believe this is his username here) the fact that GIMP as of that time (2.99/2.10) did not seem to support 10-bit per channel color depth on any operating system. Tested were Windows 10, Linux and macOS. A mailing list user Magnus Larsson confirmed this issue. This still seems to be the case as of 2.10.32.

Is there some way to enable support which I am unaware of? If not, are there any plans to implement this? How difficult would it be? Thanks.

I’ve used GIMP since on a system with 10-bit colour + 2 bit alpha.

The problem on Linux back then was that the underlying gtk+ toolkit
didn’t understand 2-bit alpha, so the dialogue boxes tended to have
transparent backgrounds or be invisible. The actual image windows were

Unfortunately i don’t have a monitor right now to test on, but i’d
suggest trying gimp 2.99 and letting us know what you find.

liam / ankh / barefootliam / demib0y :slight_smile:

1 Like

Was this on Linux? 2.99.12 on macOS and Windows are still not detecting/using 30-bit depth. Linux is less convenient for me to test but I will do so at some point if it would be helpful…

I don’t think macOS or Windows use 10-10-10-2 depth for the desktop, it would break too much (both use transparency all over the place). I’m not positive but I imagine that it is 10-10-10-10 and they just waste the extra bits up to 48-bit or something like that. That may not be the only solution but 2-bit alpha does not match with what I’m seeing.

Yes, Linux, using X11, which was able to use 10+10+10+2 visuals.

Did you verify that it was truly displaying 10 bit color rather than the desktop merely being in 10 bit mode? Because GIMP does work with the desktop in 10/30 bit on macOS and Windows, it just doesn’t display 10 bit color.

Yes. The canvas itself was 10-bit. The UI controls were… very confused. But i haven’t tried it for a long time as i had to borrow the monitor.

Thanks. I’ll go back and try it again at some point, but last time I tried on Linux GIMP did the same thing there as on Windows and macOS - not display 10 bit color.

As I understand, you are talking about display support, not image storage support, right?

I have no idea if GIMP supports this and I don’t think we have any specific code for 30-bit display. In any case, it likely requires the whole software stack to support this. It means:

  1. GTK support; I have no idea what’s the current situation. I could find this 1±year-old comment which seems to imply there was no support early 2021 at least. It may have evolved since then. @matthiasc could give more input on this.
  2. Also display backend support (on Linux, it would be X11 or Wayland compositors). For GNOME/Wayland in particular, it looks like this MR would be relevant: Use the first framebuffer config instead of always XRGB8888 (!1756) · Merge requests · GNOME / mutter · GitLab (not merged yet at this point in time).
  3. And lastly of course, specific application support may be needed (in particular for custom widgets, i.e. canvas — which is after all the most important part where we’d want to show correct colors —, etc. I could imagine, as all common widgets would be handled by the toolkit?). Personally I don’t even have 30-bit hardware to test this. But eventually if I get confirmation the whole stack has support, I’d love GIMP to get proper support.

This being said, it looks like @barefootliam was saying it could already work in some cases? Seriously I have no idea. :person_shrugging:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.