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 <[email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
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 [email protected] _______________________________________________________________________________
On Tue, Apr 28, 2026 at 12:42 PM Georgy Salnikov via Cin <[email protected]> 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 [email protected] _______________________________________________________________________________
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On Tue, Apr 28, 2026 at 1:02 PM Andrew Randrianasulu <[email protected]> wrote:
On Tue, Apr 28, 2026 at 12:42 PM Georgy Salnikov via Cin <[email protected]> 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 [email protected] _______________________________________________________________________________
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
On Tue, Apr 28, 2026 at 2:07 PM Andrew Randrianasulu <[email protected]> wrote:
On Tue, Apr 28, 2026 at 1:02 PM Andrew Randrianasulu <[email protected]> wrote:
On Tue, Apr 28, 2026 at 12:42 PM Georgy Salnikov via Cin <[email protected]> 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 [email protected] _______________________________________________________________________________
_______________________________________________ Cin mailing list -- [email protected] To unsubscribe send an email to [email protected]
participants (3)
-
Andrea paz -
Andrew Randrianasulu -
Georgy Salnikov