Wayland Color Management Protocol Posted For Weston

[oiaohm]

Windows does handle it properly when using a color managed pipeline.

https://www.intel.com/content/www/us/en/support/articles/000035037/graphics.html

Being off is true under Windows as well because of the miss alignment between HDR and SDR. The color managed pipeline does not in fact get sRGB right on HDR monitors under windows.

Yes being washed out is right. Then you mess with brightness between HDR and SDR that still has SDR on HDR being wrong. You attempt do a icc correction and SDR is still wrong on most HDR monitors in HDR mode.

Somethings are just impossible. Lot of HDR monitors are simple unable to show SDR and HDR correct at the same time. Yes they can have perfect sRGB support in SDR mode and perfect P3 color in HDR mode.

Washed out SDR on HDR is normal. Over saturated HDR on SDR monitor is also normal. This is just how the color models line up unfortunately. Yes most monitors are not REC2020 or REC2100.

Color standards are a stack of problems.

[Quackdoc]

https://www.intel.com/content/www/us/en/support/articles/000035037/graphics.html

Being off is true under Windows as well because of the miss alignment between HDR and SDR. The color managed pipeline does not in fact get sRGB right on HDR monitors under windows.

Yes being washed out is right. Then you mess with brightness between HDR and SDR that still has SDR on HDR being wrong. You attempt do a icc correction and SDR is still wrong on most HDR monitors in HDR mode.

Somethings are just impossible. Lot of HDR monitors are simple unable to show SDR and HDR correct at the same time. Yes they can have perfect sRGB support in SDR mode and perfect P3 color in HDR mode.

Washed out SDR on HDR is normal. Over saturated HDR on SDR monitor is also normal. This is just how the color models line up unfortunately. Yes most monitors are not REC2020 or REC2100.

Color standards are a stack of problems.

firstly, you are conflating many things as one thing, first things first, "Color spaces" are composed of 3 parts, Color transfer, primaries/gamut, and whitepoint. when doing comparing DCI-p3 <--> sRGB, you are talking about converting all 3 of these into the proper format, Gamut, Transfer, AND whitepoint. this is NOT converting to and from HDR! Let us pretend that by HDR we are talking explictly and only about transfer function as many people do.

This means you can have srgb gamut with PQ transfer, giving you a small gamut bright picture (similar to googles ultra HDR afaik).

Working with HDR10, it is actually specified that you use the BT.2020 primaries, with PQ transfer etc.

With this being said, when converting DCI-p3 to sRGB COLORSPACE (gamut, transfer, whitepoint) the colors will look fine, since windows can handle these conversions ASSUMING the applications are properly colormanaged.

NOW we talk about HDR, Technically speaking, you can do a dumb conversion between sRGB and a sRGB like colorspace that uses a PQ transfer. (you can actually simulate this using mpv and some shaders invert transfers with a shader if you wish) and it looks, not great, but usable. this alone means that windows is simply not preforming any proper management here (im not sure if this works when the apps are colormanaged).

this is not a faliure of SDR+HDR itself. this is just windows being bad whenever HDR is involved, windows can't even handle playing different types of HDR properly when you let windows handle HDR.

the major issue here is how to, if at all, handle tonemapping. tonemapping is necessary because the intent of display is not the same when you are using a very high nit transfer like pq or HLG

[oiaohm]

NOW we talk about HDR, Technically speaking, you can do a dumb conversion between sRGB and a sRGB like colorspace that uses a PQ transfer. (you can actually simulate this using mpv and some shaders invert transfers with a shader if you wish) and it looks, not great, but usable. this alone means that windows is simply not preforming any proper management here (im not sure if this works when the apps are colormanaged).

This is some of the problem. To save on compute cost the simplest conversion possible is used.

Another part of the problem is that most monitor is not REC2020 output yes HDR10 says you must use the REC2020 color space but what happens when the Monitor cannot in fact output that. Remember when monitor is in sRGB/SDR mode it always using single backlight. If your monitor has zoned backlight I am sorry you are screwed.

The reality there is only so much you can do in software. You convert sRGB correctly to REC2020 it does not help if the HDR mode of the monitor cannot display REC2020 correctly.

Like most of us are not using microled or equal displays were each pixel is it own thing. Instead using the cheap zoned led that does approximation of REC2020 in HDR and its a horrible approximation where you can set two pixels on screen that should be the same and due to them being in different brightness zones they are now different.

This is not just a case of applications being colormanaged this is a case you need a monitor that is capable. Lots of screens while they are in sdr mode they have a stable error that you can make a icc correction profile for but when they are in HDR mode all bets are off because the error is not stable. Yes this is one of the key reasons causing sRGB to appear washed out in HDR mode comes back to this. Think your application in a lot of cases is full of white so that equals run backlight high right see the washed out problem. So lower the brightness of the SDR applications is working around the defect in the hack that allows somewhat HDR using cheaper LCD technology.

HDR with sRGB issues 90% is the poor quality of the monitors we use not the software side.

[Quackdoc]

This is some of the problem. To save on compute cost the simplest conversion possible is used.

Another part of the problem is that most monitor is not REC2020 output yes HDR10 says you must use the REC2020 color space but what happens when the Monitor cannot in fact output that. Remember when monitor is in sRGB/SDR mode it always using single backlight. If your monitor has zoned backlight I am sorry you are screwed.

The reality there is only so much you can do in software. You convert sRGB correctly to REC2020 it does not help if the HDR mode of the monitor cannot display REC2020 correctly.

Like most of us are not using microled or equal displays were each pixel is it own thing. Instead using the cheap zoned led that does approximation of REC2020 in HDR and its a horrible approximation where you can set two pixels on screen that should be the same and due to them being in different brightness zones they are now different.

thats not an issue at all for us, since we care about uniformity whether display renders or not is irrelevant. what matters is proper uniformity across applications, let the display handle display issues.

This is not just a case of applications being colormanaged this is a case you need a monitor that is capable. Lots of screens while they are in sdr mode they have a stable error that you can make a icc correction profile for but when they are in HDR mode all bets are off because the error is not stable. Yes this is one of the key reasons causing sRGB to appear washed out in HDR mode comes back to this. Think your application in a lot of cases is full of white so that equals run backlight high right see the washed out problem. So lower the brightness of the SDR applications is working around the defect in the hack that allows somewhat HDR using cheaper LCD technology.

HDR with sRGB issues 90% is the poor quality of the monitors we use not the software side.

We literally don't care AT ALL about the capabilities of the display itself, as I said above let the display handle display issues. my point is that when it comes to rendering multiple apps with different colorspaces, as long as you aren't being an idiot, the OS can handle getting proper uniformity across apps, srgb, dci-p3, hdr and sdr, etc. Windows gets most of the way there, pooping itself for non colormanaged apps, and when HDR, OSX is nearly all of the way there since it handles colormanagement globally, but doesnt handle tonemapping and normalization well.

if you want a good display, asus has some pretty affordable proarts models now that are pretty impressive

[oiaohm]

We literally don't care AT ALL about the capabilities of the display itself, as I said above let the display handle display issues.

Problem is you will still have users complaining about SDR on HDR output being washed out because people are not aware that their monitors are not REC2020 or REC2100 so when in HDR is going to do it wrong. This is what leads to the Windows let user adjust SDR brightness on HDR on the hope of getting into user acceptable level of screwed..

Windows gets most of the way there, pooping itself for non colormanaged apps.

This is not correct. Windows also runs into the problem of color managed SDR applications not rendering correctly when Monitor is in HDR output because of the poor quality of color presentation by many common HDR monitors.

thats not an issue at all for us, since we care about uniformity whether display renders or not is irrelevant. what matters is proper uniformity across applications, let the display handle display issues.

Do note you said uniformity. Zoned backlight screens don't in fact have uniformity in color presentation when each zone is running with different backlight level. This is kind of a killer.

There is a fundamental hardware problem. Yes Windows and other have include hacks to work around some of these issues.

srgb, dci-p3, hdr and sdr

SDR that common REC709 and SRGB the gamma is different between them this can come very important for color matching but those are close enough that you mostly don't care. This is not where the problem starts.

HDR monitor/tv can be REC2020 or REC2100 or DCI-P3 or REC709 or SRGB certified to a percentage of accuracy in HDR mode.

Lets say your monitor is certified to DCI-P3 lets presume its 100 percent.(they never are) That means any color outside that can now be horrible wrong. Yes only the DCI-P3 section of REC2020 was checked in this case.

On a DCI-P3 certified screen SRGB correctly covered to REC2020 rendering washed(too bright) out is normal because the monitor was not certified to do the darker blues.

Yes certified REC709 or SRGB runs you into the same problem. This is something people have failed to notice Zoned HDR monitors are not certified to output REC2020 or REC2100 correctly but then certified for one of the other 3 instead this now leaves you with a screen that can only in fact do one of those somewhat right even with calibration.

The quality of your monitor is a serous limiting factor. Yes its not straight to have a monitor that is certified for SRGB in SDR mode but only certified for DCI-P3 in HDR then have all kinds of problems because you cannot calibrated it to show SRGB and DCI-P3 correctly at the same time.

Color managed is working on the idea that you can apply like a icc profile of the monitor to fix the problems. The issue is what do you do when the Monitor itself due to design you cannot in fact make a correction profile that works. This is what happens on DCI-P3 certified HDR attempting to display SRGB.

Also the percentage of error is another thing +-10% when displaying the same color in HDR mode on monitors out there.

If this problem was just software it would be one thing. But when the problem is cost cutting in monitors and short cutting on monitor calibration this is a different problem.
Yes the logic of might as well save the GPU/CPU processing time of doing conversion perfectly right because users not going to see it right anyhow because their monitor is garbage comes into play.

Fundamental hardware problems effects are annoying as hell as it normally spreads into the software stack.

[Quackdoc]

...

I'm not going to bother replying to anything but this, try reading what I said and responding to it instead of making some shit up. you clearly have no idea what I wrote, nor what you are even talking about, stop talking about hardware, there is absolutely nothing to do with hardware AT ALL when it comes to displaying SDR apps on HDR mode or vice versa, it has no bearing on DCI-P3 on sRGB and vice versa

hardware has literally NOTHING to do with any of this

it has NOTHING to do with monitors being bt.2020 capable or not, I already explained that windows breaks colormanagement on HDR toggled

Literally nothing you said here is accurate in any way at all.

it's all software issues. I have a shitty HDR400 display, when HDR mode is enabled, tonemapped SDR apps look perfectly fine

[Daktyl198]

KDE developers don't accept just suggestions from Nvidia either.

Yes, but the KDE developers were willing to work with Nvidia to write test cases to see whether Nvidia's proposal had any merit, and to do the work to show NVidia why their proposal wasn't going to work out. Gnome developers don't even go that far. They have a singular goal, and any outside input is entirely ignored. That's either a good thing or a bad thing, depending on the person looking at it.

[Daktyl198]

...

Again, as a user please explain to me how it's totally possible for a monitor to display a color in one color space, but be physically, via hardware, limited when it comes to displaying that same color in a color space that (almost) entirely encapsulates the first? You keep talking about lighting zones, but I have all of my lighting zones turned off on my monitor. Please explain to me why sRGB content looks so wrong on my display, and why it cannot simply be flagged as sRGB and converted using a fairly simple transformation to the "HDR" color space? Surely there are comparable values within the HDR color space that equate to almost every single sRGB color. Surely somebody, somewhere, has figured out at least a workable quick transformation. I'm not asking for sRGB to be represented perfectly, just for it to not look ENTIRELY wrong.

[oiaohm]

Again, as a user please explain to me how it's totally possible for a monitor to display a color in one color space, but be physically, via hardware, limited when it comes to displaying that same color in a color space that (almost) entirely encapsulates the first? You keep talking about lighting zones, but I have all of my lighting zones turned off on my monitor. Please explain to me why sRGB content looks so wrong on my display, and why it cannot simply be flagged as sRGB and converted using a fairly simple transformation to the "HDR" color space? Surely there are comparable values within the HDR color space that equate to almost every single sRGB color. Surely somebody, somewhere, has figured out at least a workable quick transformation. I'm not asking for sRGB to be represented perfectly, just for it to not look ENTIRELY wrong.

HDR monitor in SDR mode is basically lets lock to a single backlight value in the zoned monitors. If you look at the LCD panel without the backlight in most HDR monitor zones you find that the pixels are only 8 bit at best. Some are only 6(these are the real garbage monitors). Using backlight variation to expand from 6/8 to 10 bits per pixel.

So yes most HDR monitors with zoned blacklight can do a good sRGB because the core LCD is really a sRGB lcd and when you stop using zoned you can get back there.. But some zoned HDR monitors don't have sRGB lcd but instead have a P3 lcd these you don't really get back to sRGB disabling individual zoned backlight .

Zoned backlighting is means to use sRGB and P3 lcd panel to provide a very roughly highly color incorrect REC2020 and that the problem.

Yes zoned HDR monitors really cannot generate REC2020 or REC2100 you only get in HDR mode a form of very rough approximation. This is why when you try to display sRGB and P3 at the same time you end up screwed.

Now lets say you look at a microled display they have 10-16 bits per pixel real. These have close to correct REC2020/REC2100 coverage these you can in fact display something correctly in REC2020 with over 95% accuracy. This also means when you map sRGB to REC2020 it looks correct screen always because the monitor really does have REC2020 color space.

You don't have zoned monitor REC2020 approximation is what equals sRGB looking to washed out/too bright most of the time.

Yes if you with a zoned monitor start displaying some of the REC2020 test images you notice points that should be the same color are not in fact the same color the adjusting the backlight to expand range leads to this problem. Its the problem that every in this area is bright and this is a dark pixel so the backlight is set at the kind of adverage or the reverse happens where everything should be dull and there is few bright pixels. Both cases it rock and hard place where the zoned stuff you over.

Basically the means to map a color space into another correctly depend on two things.
1 the color space being mapped into can in fact display the colors
2 that the color space is in fact being rendered correctly.

Zoned LCD monitors don't render REC2020 correctly so what ever you map into REC2020 is going to also be wrong when displayed on those monitors. So yes hardware limit is a curse. There is a reason why full REC2020 monitors cost so much.

[mSparks]

HDR monitor in SDR mode is basically lets lock to a single backlight value in the zoned monitors.

ahahahaahaaa,

Quality

HDR/SDR is a backlighting issue.