On Thu, Apr 30, 2026 at 10:32 PM Andrew Randrianasulu <randrianasulu@gmail.com> wrote:
On Thu, Apr 30, 2026 at 10:17 PM Andrea paz <gamberucci.andrea@gmail.com> wrote:In my opinion, the behavior you've noticed indicates that CinGG is sending only sRGB signals to the monitor. It's not a matter of whether or not color management is enabled. I have wide-gamut ICC profiles set system-wide, so CinGG (or any other program) should display a wide-gamut signal if it passed the signal through unaltered, but CinGG limits it to sRGB. I’m attaching an image taken from the website https://www.wide-gamut.com/test, similar to the ChromaChecker you posted.
Interestingly THIS specific webpage does not claim my monitor support anything higher than sRGB, I see now "W" and no differently-colored squares.
So may be it implemented differently, or demand much better monitor than I have.
Previous page I found probably just highlighted than my monitor a bit better than sRGB. But not as wide as yours.
I wonder if Adobe P3 and DCI P3 makes big difference ?
I think your monitor more likely set for Adobe P3 photo, as opposed to P3 DCI (theatre)
The top color strip is wide-gamut (ProPhotoRGB); the bottom strip is sRGB. On the linked webpage, since I have a wide-gamut monitor, I can clearly see the difference between the two images: the top one is much more saturated and vibrant.May be icc profile embedded in image only works in color-managed apps like browsers, image viewers ...Does it look better (than in cingg) with mpv? in other video editors based on ffmpeg ?I think we not just do not apply display part of icc (monitor profile) but also file part ...I think video terms like full/limited range does not interact directly with terms like sRGB.In the CinGG Compositor, I don't see any difference.
This fact does not limit color accuracy only when the source files are sRGB. Any other color space is reduced to sRGB, so we end up performing color correction based on an inaccurate monitor display; consequently, the corrections made would lead to an even greater discrepancy (metamerism). With BT.709, the difference may be acceptable since the gamut is the same and only the brightness (gamma) changes. With wide-gamut color spaces, the difference becomes unacceptable.
What I still need to figure out is: why does changing the “YUV color space” affect the view in the Compositor? If we only ever see sRGB on the monitor, it should always look the same, and this setting would be useless (unlike “YUV color range,” which I understand does make a difference).
Now I’ll try compiling with lcms2, using P3 and OCIO images, and the new parameters for zscale, to see if anything changes. I’ll let you know tomorrow.