Two questions about colors: 1- Regardless of the color space used for the sources, and regardless of the operations we perform on the timeline, do we always see only an sRGB signal on the monitor? Even if the monitor is set to a different color space? I mentioned this in the manual where I had gathered various comments from GG and others, but I can no longer find the sources. Can we see from the code how the signal sent to the monitor works? 2- In the rendering window, is it possible to use any options to set a color space (e.g., BT.709 or DCI-P3) of our choice? For example, can we use the zscale or libplacebo parameters?
On Tue, Apr 28, 2026 at 10:37 AM Andrea paz via Cin <cin@lists.cinelerra-gg.org> wrote:
Two questions about colors: 1- Regardless of the color space used for the sources, and regardless of the operations we perform on the timeline, do we always see only an sRGB signal on the monitor? Even if the monitor is set to a different color space? I mentioned this in the manual where I had gathered various comments from GG and others, but I can no longer find the sources. Can we see from the code how the signal sent to the monitor works?
I think no? My understanding is that in modern terminology "gamma" is Electro-optical-transfer-function, and it describes (separately for each primary rgb color) how much light each sub-pixel must emit. What *really* happens depend on emitting material, and firmware inside monitor ... and well, gamma curve loaded into GPU's Digital Analog Converters in VGA case (I have VGA monitor). 8/10 bpc differs, but we do not do 10bpc rendering to monitor so this is not yet our space. Do you have any photo-target for calibration? I think (but I can be wrong) ideally colors as seen on your screen in some std. viewing environment should closely match what you see IRL with your eyes. Multiple cameras and monitors used in production and re-production lately complicate this greatly ...
2- In the rendering window, is it possible to use any options to set a color space (e.g., BT.709 or DCI-P3) of our choice? For example, can we use the zscale or libplacebo parameters?
I think zscale/libplacebo works if you set them as video_filter in .opts file, and zscale should work as draggable ffmpeg filter (libplacebo fails due to misconfigured complex input?) Ideally, like DaVinci Resolve there must be specialized hdmi/dp output module, just directly blasting pixels and some infoframes over hdmi/dp wire, so monitor can correct itself or just bypass signal without any additional processing. This only will work over separate, two-monitor setup I think (or maaay be via isolated display output in X) We sadly lack someone who both can code AND does have monitor hardware AND understand theory behind those transforms ... I only have qute shallow understanding on all 3 topics ....
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
On Tue, 28 Apr 2026, Andrea paz via Cin wrote:
1- Regardless of the color space used for the sources, and regardless of the operations we perform on the timeline, do we always see only an sRGB signal on the monitor? Even if the monitor is set to a different color space? I mentioned this in the manual where I had gathered various comments from GG and others, but I can no longer find the sources. Can we see from the code how the signal sent to the monitor works?
I approximately know two cases, they are very different from each others. 1) Conventional (non-HDR) mode. On an uncalibrated monitor you can see anything, although good IPS monitors usually look rather close to sRGB. Generally, to be sure what you see, you must calibrate your monitor with a calorimether device and some calibration software like ArgyllCMS to create the monitor profile. If you have several non-HDR monitors, each one has ist own profile. CMS software knows, which profile is assigned to which monitor, and knows how not to intermix them. The reality is yet more complicated. Usually monitors have various adjustments (brightness, contrast, gamma, color temperature, etc.), laptop panels have backlight power. The computer knows nothing about such adjustments. Should you change anything on the monitor, you must recalibrate it with the new settings. Calibration profiles can be actualized in different ways. Operating system can do it system-wide (via, for example, colord daemon in KDE, or ArgyllCMS can load its profile via KDE's autostart shotrcuts, etc.). Or some programs can take into account LCMS profiles in their private windows (most photo processing programs like Darktable or Rawtherapee can do that). If, for example, colord has loaded the profile system-wide, and then Gimp corrects colors once again, you can get bad colors corrected twice. CinGG has no interface to CMS and cannot apply any monitor profiles. If the profile has been loaded by other software, for example, colord has loaded it system-wide, colors from CinGG will be displayed correctly (as sRGB). 2) HDR-mode. It is claimed that monitors supporting this mode and switched to this mode are factory-calibrated, profile is saved in firmware, they require no calibration at all, and, moreover, no calibration can be applied to them. Instead, it is claimed that light intensity from pixels be proportional to the pixel values, starting from zero (no light), up to some maximum depending on the actual max brightness of the particular monitor. In this mode, you have that what you have, and can only rely on it. CinGG cannot use this mode at all (at least not yet). _______________________________________________________________________________ Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3305504 Email sge@nmr.nioch.nsc.ru _______________________________________________________________________________
On Tue, Apr 28, 2026 at 12:42 PM Georgy Salnikov via Cin <cin@lists.cinelerra-gg.org> wrote:
On Tue, 28 Apr 2026, Andrea paz via Cin wrote:
1- Regardless of the color space used for the sources, and regardless of the operations we perform on the timeline, do we always see only an sRGB signal on the monitor? Even if the monitor is set to a different color space? I mentioned this in the manual where I had gathered various comments from GG and others, but I can no longer find the sources. Can we see from the code how the signal sent to the monitor works?
I approximately know two cases, they are very different from each others.
1) Conventional (non-HDR) mode. On an uncalibrated monitor you can see anything, although good IPS monitors usually look rather close to sRGB. Generally, to be sure what you see, you must calibrate your monitor with a calorimether device and some calibration software like ArgyllCMS to create the monitor profile.
If you have several non-HDR monitors, each one has ist own profile. CMS software knows, which profile is assigned to which monitor, and knows how not to intermix them.
The reality is yet more complicated.
Usually monitors have various adjustments (brightness, contrast, gamma, color temperature, etc.), laptop panels have backlight power. The computer knows nothing about such adjustments. Should you change anything on the monitor, you must recalibrate it with the new settings.
Calibration profiles can be actualized in different ways. Operating system can do it system-wide (via, for example, colord daemon in KDE, or ArgyllCMS can load its profile via KDE's autostart shotrcuts, etc.). Or some programs can take into account LCMS profiles in their private windows (most photo processing programs like Darktable or Rawtherapee can do that). If, for example, colord has loaded the profile system-wide, and then Gimp corrects colors once again, you can get bad colors corrected twice.
CinGG has no interface to CMS and cannot apply any monitor profiles. If the profile has been loaded by other software, for example, colord has loaded it system-wide, colors from CinGG will be displayed correctly (as sRGB).
I wonder what will happen if you try to view wide-gamut photo on wide-gamut capable monitor *via cingg* ? :)
2) HDR-mode. It is claimed that monitors supporting this mode and switched to this mode are factory-calibrated, profile is saved in firmware, they require no calibration at all, and, moreover, no calibration can be applied to them. Instead, it is claimed that light intensity from pixels be proportional to the pixel values, starting from zero (no light), up to some maximum depending on the actual max brightness of the particular monitor. In this mode, you have that what you have, and can only rely on it.
Ya, HDR10, HDR10+, HLG, Dolby Vision .... xkcd "Standards" https://www.avsforum.com/threads/checking-for-bt-2020-color-gamut-usage-beyo... and https://www.rtings.com/tv/tests/picture-quality/sdr-color-volume might be relevant (keyword seems to be BT.2020) Second link does not contain test file, but first one might? I wonder if something can be rigged via mpv, cingg, ffmpeg + x265 encoding "fake' HDR? I.e. low *dynamic* range, yet still wide color gamut? Just hack for consumer mons apparently having no way to display BT2020 SDR video signal ....
CinGG cannot use this mode at all (at least not yet).
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3305504 Email sge@nmr.nioch.nsc.ru _______________________________________________________________________________
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
On Tue, Apr 28, 2026 at 1:02 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
On Tue, Apr 28, 2026 at 12:42 PM Georgy Salnikov via Cin <cin@lists.cinelerra-gg.org> wrote:
On Tue, 28 Apr 2026, Andrea paz via Cin wrote:
1- Regardless of the color space used for the sources, and regardless of the operations we perform on the timeline, do we always see only an sRGB signal on the monitor? Even if the monitor is set to a different color space? I mentioned this in the manual where I had gathered various comments from GG and others, but I can no longer find the sources. Can we see from the code how the signal sent to the monitor works?
I approximately know two cases, they are very different from each others.
1) Conventional (non-HDR) mode. On an uncalibrated monitor you can see anything, although good IPS monitors usually look rather close to sRGB. Generally, to be sure what you see, you must calibrate your monitor with a calorimether device and some calibration software like ArgyllCMS to create the monitor profile.
If you have several non-HDR monitors, each one has ist own profile. CMS software knows, which profile is assigned to which monitor, and knows how not to intermix them.
The reality is yet more complicated.
Usually monitors have various adjustments (brightness, contrast, gamma, color temperature, etc.), laptop panels have backlight power. The computer knows nothing about such adjustments. Should you change anything on the monitor, you must recalibrate it with the new settings.
Calibration profiles can be actualized in different ways. Operating system can do it system-wide (via, for example, colord daemon in KDE, or ArgyllCMS can load its profile via KDE's autostart shotrcuts, etc.). Or some programs can take into account LCMS profiles in their private windows (most photo processing programs like Darktable or Rawtherapee can do that). If, for example, colord has loaded the profile system-wide, and then Gimp corrects colors once again, you can get bad colors corrected twice.
CinGG has no interface to CMS and cannot apply any monitor profiles. If the profile has been loaded by other software, for example, colord has loaded it system-wide, colors from CinGG will be displayed correctly (as sRGB).
I wonder what will happen if you try to view wide-gamut photo on wide-gamut capable monitor *via cingg* ? :)
2) HDR-mode. It is claimed that monitors supporting this mode and switched to this mode are factory-calibrated, profile is saved in firmware, they require no calibration at all, and, moreover, no calibration can be applied to them. Instead, it is claimed that light intensity from pixels be proportional to the pixel values, starting from zero (no light), up to some maximum depending on the actual max brightness of the particular monitor. In this mode, you have that what you have, and can only rely on it.
Ya, HDR10, HDR10+, HLG, Dolby Vision .... xkcd "Standards"
https://www.avsforum.com/threads/checking-for-bt-2020-color-gamut-usage-beyo...
and
https://www.rtings.com/tv/tests/picture-quality/sdr-color-volume
might be relevant (keyword seems to be BT.2020)
Second link does not contain test file, but first one might?
I wonder if something can be rigged via mpv, cingg, ffmpeg + x265 encoding "fake' HDR? I.e. low *dynamic* range, yet still wide color gamut?
https://x265.readthedocs.io/en/2.5/cli.html --master-display <string> SMPTE ST 2086 mastering display color volume SEI info, specified as a string which is parsed when the stream header SEI are emitted. The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and %u are unsigned 32bit integers. The SEI includes X,Y display primaries for RGB channels and white point (WP) in units of 0.00002 and max,min luminance (L) values in units of 0.0001 candela per meter square. Applicable for HDR content. Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001): G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default. ==== I wonder what will happen if you push 1000 nit here down to 100 or something? Will equation/algo/signalling break?
Just hack for consumer mons apparently having no way to display BT2020 SDR video signal ....
CinGG cannot use this mode at all (at least not yet).
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3305504 Email sge@nmr.nioch.nsc.ru _______________________________________________________________________________
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
On Tue, Apr 28, 2026 at 2:07 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
On Tue, Apr 28, 2026 at 1:02 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
On Tue, Apr 28, 2026 at 12:42 PM Georgy Salnikov via Cin <cin@lists.cinelerra-gg.org> wrote:
On Tue, 28 Apr 2026, Andrea paz via Cin wrote:
1- Regardless of the color space used for the sources, and regardless of the operations we perform on the timeline, do we always see only an sRGB signal on the monitor? Even if the monitor is set to a different color space? I mentioned this in the manual where I had gathered various comments from GG and others, but I can no longer find the sources. Can we see from the code how the signal sent to the monitor works?
I approximately know two cases, they are very different from each others.
1) Conventional (non-HDR) mode. On an uncalibrated monitor you can see anything, although good IPS monitors usually look rather close to sRGB. Generally, to be sure what you see, you must calibrate your monitor with a calorimether device and some calibration software like ArgyllCMS to create the monitor profile.
If you have several non-HDR monitors, each one has ist own profile. CMS software knows, which profile is assigned to which monitor, and knows how not to intermix them.
The reality is yet more complicated.
Usually monitors have various adjustments (brightness, contrast, gamma, color temperature, etc.), laptop panels have backlight power. The computer knows nothing about such adjustments. Should you change anything on the monitor, you must recalibrate it with the new settings.
Calibration profiles can be actualized in different ways. Operating system can do it system-wide (via, for example, colord daemon in KDE, or ArgyllCMS can load its profile via KDE's autostart shotrcuts, etc.). Or some programs can take into account LCMS profiles in their private windows (most photo processing programs like Darktable or Rawtherapee can do that). If, for example, colord has loaded the profile system-wide, and then Gimp corrects colors once again, you can get bad colors corrected twice.
CinGG has no interface to CMS and cannot apply any monitor profiles. If the profile has been loaded by other software, for example, colord has loaded it system-wide, colors from CinGG will be displayed correctly (as sRGB).
I wonder what will happen if you try to view wide-gamut photo on wide-gamut capable monitor *via cingg* ? :)
2) HDR-mode. It is claimed that monitors supporting this mode and switched to this mode are factory-calibrated, profile is saved in firmware, they require no calibration at all, and, moreover, no calibration can be applied to them. Instead, it is claimed that light intensity from pixels be proportional to the pixel values, starting from zero (no light), up to some maximum depending on the actual max brightness of the particular monitor. In this mode, you have that what you have, and can only rely on it.
Ya, HDR10, HDR10+, HLG, Dolby Vision .... xkcd "Standards"
https://www.avsforum.com/threads/checking-for-bt-2020-color-gamut-usage-beyo...
and
https://www.rtings.com/tv/tests/picture-quality/sdr-color-volume
might be relevant (keyword seems to be BT.2020)
Second link does not contain test file, but first one might?
I wonder if something can be rigged via mpv, cingg, ffmpeg + x265 encoding "fake' HDR? I.e. low *dynamic* range, yet still wide color gamut?
https://x265.readthedocs.io/en/2.5/cli.html
--master-display <string>
SMPTE ST 2086 mastering display color volume SEI info, specified as a string which is parsed when the stream header SEI are emitted. The string format is “G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)” where %hu are unsigned 16bit integers and %u are unsigned 32bit integers. The SEI includes X,Y display primaries for RGB channels and white point (WP) in units of 0.00002 and max,min luminance (L) values in units of 0.0001 candela per meter square. Applicable for HDR content.
Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):
G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)
Note that this string value will need to be escaped or quoted to protect against shell expansion on many platforms. No default.
====
I wonder what will happen if you push 1000 nit here down to 100 or something? Will equation/algo/signalling break?
For my hdmi->vga converter dongle libdisplayinfo test program prints: bash-5.1$ build/test/di-edid-print /sys/class/drm/card0-HDMI-A-1/edid make: PNP(HJW) model: MACROSILICON serial: 0x0002E842 HDR static metadata: luminance 0.000000-0.000000, maxFALL 0.000000 metadata type1=no EOTF tSDR=yes, tHDR=no, PQ=no, HLG=no default color primaries: red: 0.640, 0.330 green: 0.300, 0.600 blue: 0.150, 0.060 default white: 0.312, 0.329 default gamma: 2.20 signal colorimetry: https://gitlab.freedesktop.org/emersion/libdisplay-info requires meson for building I wonder what Andrea's display shows when set to non-sRGB mode ?
Just hack for consumer mons apparently having no way to display BT2020 SDR video signal ....
CinGG cannot use this mode at all (at least not yet).
_______________________________________________________________________________
Georgy Salnikov NMR Group Novosibirsk Institute of Organic Chemistry Lavrentjeva, 9, 630090 Novosibirsk, Russia Phone +7-383-3305504 Email sge@nmr.nioch.nsc.ru _______________________________________________________________________________
_______________________________________________ Cin mailing list -- cin@lists.cinelerra-gg.org To unsubscribe send an email to cin-leave@lists.cinelerra-gg.org
I only use non-sRGB mode, since I use a wide-gamut ICC profile created with the Spider 5. Right now, it doesn't work in any color manager—neither in colord (X11, KDE) nor in “Settings → Display” (Wayland, KDE). My ICC profile displays incorrect colors: AdobeRGB; sRGB; Rec.709; DCI-P3. The monitor displays very dark, almost black screens. I don’t know why; the only combination that works for me is using the custom profile but without my ICC—it automatically uses the monitor’s default profile (Dell UP2716D). In short, nothing works on the graphics side, and I think it’s time to format and reinstall Arch from scratch. I’ve already tried comparing GIMP and CinGG using test images. There are small differences (mainly in brightness or gamma, I’m not sure) but I don’t know how to evaluate them. I've already installed libdisplay-info on my system as a dependency for other programs, but I can't find any di-edid-print. When I run: $ /usr/bin/di-edid-decode /sys/class/drm/card1-DP-3/edid I get the result I've attached, but it doesn't include the same information you posted. In short, I’m not particularly concerned about my own specific situation, which I can’t seem to resolve. I just wanted to change or remove the section on colors in the manual; if I’ve understood your responses correctly, you should only use an sRGB monitor (preferably calibrated); any other color space is counterproductive. PS: - zscale applies to the track, but when I try to edit the primaries or primariesin, the Compositor goes black. I'm getting the following errors in the terminal: PluginFVClient::process_buffer() F_zscale err: Generic error in an external library - I apply Libplacebo to the track, but everything immediately turns black, even without adjusting any parameters. I'm getting the following errors in the terminal: PluginFVClient::activate() F_libplacebo err: Invalid argument PluginFVClient::process_buffer() F_libplacebo err: Operation not permitted
On Wed, Apr 29, 2026 at 2:50 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:
I only use non-sRGB mode, since I use a wide-gamut ICC profile created with the Spider 5. Right now, it doesn't work in any color manager—neither in colord (X11, KDE) nor in “Settings → Display” (Wayland, KDE). My ICC profile displays incorrect colors: AdobeRGB; sRGB; Rec.709; DCI-P3. The monitor displays very dark, almost black screens. I don’t know why; the only combination that works for me is using the custom profile but without my ICC—it automatically uses the monitor’s default profile (Dell UP2716D). In short, nothing works on the graphics side, and I think it’s time to format and reinstall Arch from scratch.
I’ve already tried comparing GIMP and CinGG using test images. There are small differences (mainly in brightness or gamma, I’m not sure) but I don’t know how to evaluate them.
I've already installed libdisplay-info on my system as a dependency for other programs, but I can't find any di-edid-print. When I run:
$ /usr/bin/di-edid-decode /sys/class/drm/card1-DP-3/edid
I get the result I've attached, but it doesn't include the same information you posted.
In short, I’m not particularly concerned about my own specific situation, which I can’t seem to resolve. I just wanted to change or remove the section on colors in the manual; if I’ve understood your responses correctly, you should only use an sRGB monitor (preferably calibrated); any other color space is counterproductive.
PS:
- zscale applies to the track, but when I try to edit the primaries or primariesin, the Compositor goes black. I'm getting the following errors in the terminal:
I think you need to change some parameters in synchro, probably primaries/trc/gamut (?) cat ~/.bcast5/F_zscale.xml 384 370 <F_ZSCALE w=3840 width=3840 h=2160 height=2160 size="" s="" dither=0 d=0 filter=5 f=5 out_range=0 range=0 r=0 primaries=9 p=9 transfer=15 t=15 matrix=1 m=1 in_range=1 rangein=1 rin=1 primariesin=9 pin=9 transferin=14 tin=14 matrixin=1 min=1 chromal=1 c=1 chromalin=0 cin=0 npl=0.000000 agamma=true param_a=0.000000 param_b=0.000000 threads=0>
PluginFVClient::process_buffer() F_zscale err: Generic error in an external library
- I apply Libplacebo to the track, but everything immediately turns black, even without adjusting any parameters. I'm getting the following errors in the terminal:
PluginFVClient::activate() F_libplacebo err: Invalid argument PluginFVClient::process_buffer() F_libplacebo err: Operation not permitted
cat ~/.bcast5/F_zscale.xml 384 370 <F_ZSCALE w=3840 width=3840 h=2160 height=2160 size="" s="" dither=0 d=0 filter=5 f=5 out_range=0 range=0 r=0 primaries=9 p=9 transfer=15 t=15 matrix=1 m=1 in_range=1 rangein=1 rin=1 primariesin=9 pin=9 transferin=14 tin=14 matrixin=1 min=1 chromal=1 c=1 chromalin=0 cin=0 npl=0.000000 agamma=true param_a=0.000000 param_b=0.000000 threads=0>
Even if I copy your settings, the result doesn't change. The Compositor view turns black no matter what I do. Do you think this is one of “my” problems, or is it related to CinGG's setting? Anyway, zscale isn't really important because there are native plugins that do the same thing. I was just wondering if you could use zscale's color space conversion in the rendering window so you could choose the color space for the final file. Do you think there's any other way to do this? Let me explain why I've been bothering you so much with these silly questions: I thought I could apply Display-Referred color management to the CinGG workflow (which doesn’t have color management). To do this, you need to match the color spaces of the sources (which must be done beforehand and outside of CinGG) with the color space of the Timeline/Compositor (and this can’t be done because, if I understand correctly, only sRGB is visible) and finally with the color space of the rendering file (and I don’t think this is possible either, unless there’s a way to force the color space onto the temporary before starting encoding *). If these three color spaces matched, then we’d be fully in Display-Referred mode, and during color correction, internal conversions and color data loss would be minimized, yielding the best possible result. However, two out of three steps prevent this. Too bad! * One possible approach is to place the native “colorspace” plugin at the end of the plugin chain used for color correction—that is, as the last plugin before rendering.
On Wed, 29 Apr 2026 11:49:53 +0000 Andrea paz via Cin <cin@lists.cinelerra-gg.org> wrote:
I only use non-sRGB mode, since I use a wide-gamut ICC profile created with the Spider 5. Right now, it doesn't work in any color manager—neither in colord (X11, KDE) nor in “Settings → Display” (Wayland, KDE). My ICC profile displays incorrect colors: AdobeRGB; sRGB; Rec.709; DCI-P3. The monitor displays very dark, almost black screens. I don’t know why; the only combination that works for me is using the custom profile but without my ICC—it automatically uses the monitor’s default profile (Dell UP2716D).
Hi Andrea, FWIW, the measurements for a new display profile must be made in the exact same video mode (including possible gamut and HDR metadata in the signal) as the display will be driven while using the profile. If anything changes in the signalling or calibration (e.g. changing settings in the monitor itself), a new profile must be made. Because of this, a profile made under one system (Xorg, Plasma Wayland, GNOME Wayland, ...) may not be right under another system for the very same monitor. Color management on X11 vs. Wayland works fundamentally differently: https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/winsys_color... On X11, every app needs to use the monitor profile itself. They may fetch that profile automatically from colord, but colord itself does no color management. On Wayland, the display system (the compositor) implements color management and uses the monitor profile. App windows are assumed to be sRGB unless the app explicitly says otherwise through the Wayland protocol. X11 apps through Xwayland are a good question - there is no way that an X11 app could say it is producing something other than sRGB. If you configure the monitor profile to X11 apps, the result will likely be wrong, because the Wayland compositor still assumes that the X11 app produces sRGB and does the color conversion again. There could be desktop environment specific overrides to work around this so that X11 apps could employ larger than sRGB color gamut for display, but I'm not aware of any. I have hopes to improve the situation. On a Wayland compositor, doing the measurements is tricky if the compositor or desktop environment does not explicitly support profiling. Here is an old post about Plasma Wayland: https://zamundaaa.github.io/wayland/2024/07/16/how-to-profile.html I don't know if things have changed in Plasma since. My plan for supporting profiling is at: https://gitlab.freedesktop.org/pq/color-and-hdr/-/work_items/27 I hope this explains the messy situation at least a little bit. Thanks, pq
participants (4)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov -
Pekka Paalanen