Followup re: 10-bit (30-bit) display support for GIMP

Applications
,
1

Previously in November 2020 on the old mailing list I discussed with @barefootliam the fact that GIMP as of that time (2.99/2.10) did not seem to support 10-bit per channel display color depth (displayed, not the underlying internal image color depth of GIMP) on any operating system. Liam felt that it did partially work but that was not my experience, and a mailing list user Magnus Larsson agreed that it did not work.

Subsequently last year in October I raised the question again on this forum where barefootliam again felt it did work, but @Jehan was unsure of this and suggested that matthiasc might know something about the GTK support at least.

In none of my testing on systems where the 10-bit display is working (verified with a gradient in applications that do support 10-bit) could GIMP display the gradient, Mac, Windows or Linux. I have not gone back and tested again this year because I am assuming there would be some major update or announcement if the work were done for this, which from what Jehan said sounded like it might be no inconsiderable amount of.

To quote Jehan:

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:

So I am checking back in to see if the status of this has changed before I dive into it again myself. 10-bit displays are becoming more and more common, at least ones that support 8-bit+FRC, so I imagine some people may have access to them without even realizing it at this point. I’m not sure of the suitability of FRC displays vs. true 10-bit, but on my one FRC display the results are “similar” between it and a true 10-bit display - in software that supports the 10-bit color depth.

I would definitely consider doing some coding work on this myself, although it sounds like the task may be considerably larger than I have the time or experience (e.g. with GTK internals) to undertake.

Thanks.

[as a new user I can only ping two people per post so I trimmed the ping of matthiasc, if anyone else cares to ping him please do]

1 Like
2

What happened when i tried was that image windows were displayed correctly, but the rest of the user interface was not. The reason was that the gtk toolkit thought 32-bit meant 8/8/8/8, for RGBA, where GIMP understood for its display 10/10/10/2. So, some things in the menus dialogue boxes and so on came out transparent because gtk set wrong values.

I no longer have access to a display that supports 10/10/10/2 to test it, though.

1 Like
3

As a continuation to my previous comment (in your old thread):

  • While X11 already had some support, it is still being worked on for the various Wayland compositors (also it will have to happen per compositor, so we might get it for one but not the others). The MR which should bring 10-bit support on GNOME/Wayland was already given in my previous comment and as you can see by clicking on it, it is still not merged. I can’t say for KDE or other compositors. Now you could stay on X11 (hopefully X11 will stay around, as I read some people are trying to push X11 out of some distributions already even though Wayland is clearly not ready yet for many usage, like pro graphics works!) and configure it accordingly.
  • On GTK side, not sure if the situation changed at all. To be fair, it is not necessarily a problem but that still depends on some basic color awareness between systems (i.e. when the interface is passed from 8-bit to 10-bit buffers). In worst cases, we hear these stories of software whose interface goes oversaturated, probably because the system just mapped the 8-bit to a 10-bit range which might actually represent a wider gamut without doing any real color transform. I have no idea which situation we are on. The tests made by @barefootliam seem to imply though that it might even be worse than just a wrong color space conversion as the display system even fails to understand the format (or its bit depth) it is handed (or the toolkit fails to advertize what format it hands over).
  • Finally on GIMP side, we would obviously control more closely the parts which we really care about (the canvas and possibly other parts where we show colors, thumbnails, etc.). I am unsure what level of support we have (if at all), though @barefootliam tests seem to imply that at least it’s better than bare GTK. This being said, none of the devs have worked on this specific topic since your last thread. Personally I still don’t even have 10-bit display hardware. I would not count on GIMP to do the right thing. Maybe it does (or partly), but I can’t assure it.

I would not expect there to be huge change for GIMP 3 in general. After GIMP 3, where we’ll have reviewed all the bases on color correctness so we’d have hopefully correct display everywhere (8-bit at least; see the roadmap, it’s the item we call “space invasion”; it started with GIMP 2.10 where we introduced many pieces of it; with GIMP 3, we want to make the whole thing robust and verified; after GIMP 3, we are planning to extend this, which would imply indeed things like 10-bit display, HDR or whatnot, as well as possibly more core color model supports, etc.), this would definitely be a good feature to work on.

To be continued…

1 Like
4

Color management and HDR support are in the works for Wayland, but they will only be supported with GTK4 and newer. There is a lot of work involved with these features—from the graphics drivers to the display servers, from protocols to toolkits and applications—so it cannot be retrofitted on top of GTK3.

1 Like
5

Oh actually, this MR might be superseded by a newer MR (or it’s complementary, I don’t know): backends/native: Try 10 bpc formats (!3139) · Merge requests · GNOME / mutter · GitLab

It might be merged for GNOME 46 according to this comment (which is one of the discussions where there are discussions to remove X11 in Fedora; which I hope won’t happen for at least a few years!). So there might be some evolution soon. :person_shrugging:

1 Like
6

The proposal is for removing the X11 session; X11, in the form of XWayland, will stay around for years to come.

7

Sure. For the HDR part at least, it’s likely fine by us. As said above, I don’t see us working on HDR by the time GIMP 3 is released. And since some people might want us to go for GTK4 soon after, who knows… maybe it won’t be much of a problem. For more classical color management, it’s a bit more of a problem though. We need at least this for our daily work. :confused:

Does color management work through XWayland? Also even if it does, it would mean we will need to tell people to run GIMP with GDK_BACKEND=x11 to have color management since GIMP 3 will be a native Wayland application by default.

Also what about NVidia graphics card? Last we updated our machine with such a card (Fedora 38), it still couldn’t run GNOME on Wayland (black screen then back to login screen if I recall). We hate having the proprietary drivers and all that, but we are in the professional graphics industry. It’s not like we can avoid this apart from changing jobs.

I mean, if it all works fine, I don’t care about X or Wayland. And I am one who does a lot of Wayland-related fixes in GIMP code. Yet we still have a day job which is graphics creation! :slight_smile:

8

I forgot to mention that for the tests i did, i started X manually from the command-line to tell it to use 30bpp, and checked that it offered 10/10/10/2 visuals. I don’t now know for sure but it was probably the proprietary NVidia X11 driver via a DisplayPort cable. And yes, the cable/connector you use makes a difference, some cards can do higher bit depth only on one port, or have frequency limits. It may also be necessary to change the mode in the monitor’s internal menu before starting X.

1 Like
9

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