1 00:00:00,017 --> 00:00:03,597 And Zawar, the stage is yours. Okay. 2 00:00:04,177 --> 00:00:09,457 Hi, everyone. I'm Zawar. And he's right. I will be talking about color management. 3 00:00:10,037 --> 00:00:16,217 I've been working on Quinn's color management support for quite a while now. 4 00:00:16,517 --> 00:00:20,017 So I am qualified to talk about it a little bit. 5 00:00:20,817 --> 00:00:24,377 Color is a very big and complicated topic. 6 00:00:24,417 --> 00:00:31,417 So I will be skipping a lot. I will not be talking about like biological or 7 00:00:31,417 --> 00:00:38,157 psychological bits about color but mostly with a focus on practical matters 8 00:00:38,157 --> 00:00:41,937 on what we should do in our software, 9 00:00:44,437 --> 00:00:52,137 so let's start with a question what even this color and let's dumb it down a 10 00:00:52,137 --> 00:00:55,177 bit and start at the kindergarten level. 11 00:00:56,397 --> 00:00:58,477 What's this color? Red. 12 00:00:59,717 --> 00:01:04,297 But if that's red, then what's that color? 13 00:01:08,177 --> 00:01:11,117 It's also red, but just a bit darker. 14 00:01:13,697 --> 00:01:18,317 But if these are both red, what's What's that third color? 15 00:01:22,337 --> 00:01:30,697 Yes, it's all kind of red, so using these names to talk about colors is maybe acceptable, 16 00:01:31,397 --> 00:01:34,717 if you're an artist and you mix your colors to paint on a canvas, 17 00:01:34,877 --> 00:01:39,937 but in computers we can't work with just a bunch of random names. 18 00:01:40,797 --> 00:01:42,777 We need cold hard numbers. 19 00:01:44,852 --> 00:01:51,172 You might already be familiar with the rgb system if you've used cue color in your application, 20 00:01:51,812 --> 00:01:58,952 you probably already input some of these in your app and these are the values 21 00:01:58,952 --> 00:02:05,112 that i chose with the color picker the first one is a hundred percent red second 22 00:02:05,112 --> 00:02:10,052 one is fifty percent red and the third is a hundred percent red with a bit of 23 00:02:10,052 --> 00:02:11,512 green and blue mixed in in. 24 00:02:12,312 --> 00:02:15,932 But then we're still at the same original question. 25 00:02:16,132 --> 00:02:20,492 Well, which red are we talking about? Which green? Which blue? 26 00:02:21,692 --> 00:02:25,252 These are nice, but they're not objective. 27 00:02:27,072 --> 00:02:30,312 Luckily, around a hundred years ago, 28 00:02:30,472 --> 00:02:35,632 some scientists already solved this problem for us before it even became relevant 29 00:02:35,632 --> 00:02:42,372 for computers and they did a bunch of experiments with lasers. 30 00:02:43,732 --> 00:02:46,672 Lasers are awesome like just in general 31 00:02:46,672 --> 00:03:00,812 but also for colors for colors they're especially great because you have a single 32 00:03:00,812 --> 00:03:05,992 wavelength of light it's one pure color and it's objective. 33 00:03:08,892 --> 00:03:15,012 What they came up with is the XYZ color space. So no red, green, or blue. 34 00:03:16,792 --> 00:03:20,452 This image is not the XYZ color space. It only has two axes. 35 00:03:22,032 --> 00:03:25,772 It is derived from XYZ and it's called XYY. 36 00:03:27,832 --> 00:03:32,412 And the second Y is just brightness and we're ignoring that for now. 37 00:03:34,392 --> 00:03:39,912 You can see that we have a coordinate grid here where we can just specify an 38 00:03:39,912 --> 00:03:45,312 X and a Y and then we get an objectively defined color. 39 00:03:46,672 --> 00:03:55,772 In this coordinate system, you can pick two points and in the middle is the 40 00:03:55,772 --> 00:04:00,432 color that you get out if you mix these two other colors 50-50. 41 00:04:01,452 --> 00:04:08,172 If you mix them as light, that is, paint is very different, and we're not talking about that at all. 42 00:04:10,292 --> 00:04:17,632 The round shape around the color, those numbers are the wavelengths of light. 43 00:04:20,699 --> 00:04:26,119 So, this is great, we now have actual numbers to work with. 44 00:04:28,939 --> 00:04:36,619 And the color space that we actually use in programs most of the time is called sRGB. 45 00:04:38,199 --> 00:04:45,059 In this triangle, we have the actual real definitions for what red, green and blue mean. 46 00:04:45,259 --> 00:04:49,139 It's just that red corner, that green corner and that blue corner. 47 00:04:51,139 --> 00:04:57,979 Now, there's a fourth point in here that is relevant in the middle of the triangle. 48 00:04:58,179 --> 00:05:04,299 We see the D65 point and that's called the white point. 49 00:05:04,779 --> 00:05:09,059 It is quite literally the point that you consider to be white. 50 00:05:11,139 --> 00:05:15,479 I have an example here for why we need to care about it. 51 00:05:16,559 --> 00:05:21,479 I originally wanted to use some paper and some LEDs to show it, 52 00:05:21,599 --> 00:05:25,559 but then my cat jumped on my lap and didn't allow me to do any work. 53 00:05:25,999 --> 00:05:29,059 So I used her as the example. 54 00:05:31,059 --> 00:05:36,899 On the left, you can see an image that I took with my phone set to automatic 55 00:05:36,899 --> 00:05:44,099 settings with a light that's pretty like cold color temperature, 56 00:05:44,099 --> 00:05:46,559 So similar to what these lights in here are. 57 00:05:48,199 --> 00:05:52,179 And then I took the second photo with the same camera settings, 58 00:05:52,459 --> 00:05:59,119 but I turned on the light that I use in the evening, which has more of an orange tone. 59 00:06:00,779 --> 00:06:03,819 And the result isn't very surprising, right? 60 00:06:03,919 --> 00:06:11,079 You shine an orange light on a white fur and it looks orange. 61 00:06:11,979 --> 00:06:15,879 What this picture doesn't tell you is that for me in the room, 62 00:06:15,959 --> 00:06:18,279 she didn't look orange at all. 63 00:06:19,699 --> 00:06:25,039 Because our brains adjust to the light that we are surrounded by. 64 00:06:25,779 --> 00:06:29,479 The brain goes, oh, I know this is supposed to be white. 65 00:06:30,019 --> 00:06:36,219 And it shifts your whole color vision around until white actually looks roughly white again. 66 00:06:38,039 --> 00:06:46,259 So that's where we need to specify what the white point is, otherwise it's pretty... 67 00:06:46,259 --> 00:06:48,159 All the other colors are meaningless. 68 00:06:49,319 --> 00:06:56,339 Now this is again like a wishy-washy explanation that doesn't really translate to numbers. 69 00:06:57,179 --> 00:07:02,659 In our RGB system this just means that red, 70 00:07:02,839 --> 00:07:09,379 green and blue all at a hundred percent doesn't actually make all the three 71 00:07:09,379 --> 00:07:15,279 primary colors the same brightness they have a different maximum brightness. 72 00:07:18,764 --> 00:07:24,644 And if with sRGB, if you emit red, green and blue with these intensities at 73 00:07:24,644 --> 00:07:28,804 100 percent, then you get that D65 white point. 74 00:07:31,324 --> 00:07:35,984 So now we've defined red, green, blue and even white. 75 00:07:36,364 --> 00:07:41,624 So we're done, right? We have our RGB numbers and the talk is over. 76 00:07:43,264 --> 00:07:50,444 Well, it's of course not that simple in practice. In practice, sRGB is a lie. 77 00:07:53,224 --> 00:07:59,124 So sRGB is what all the content you generally find on the internet uses. 78 00:08:00,024 --> 00:08:05,744 And it's meant for computer displays, but it's relatively old by now. 79 00:08:06,664 --> 00:08:13,644 And we can both not always perfectly make displays that have exactly the sRGB 80 00:08:13,644 --> 00:08:18,064 colors. colors and we don't necessarily want to. 81 00:08:21,804 --> 00:08:30,504 I have measured my old laptop display and my gaming monitor's colors and you can see, 82 00:08:31,724 --> 00:08:37,964 that on the left side the laptop display pretty much exactly follows sRGB. 83 00:08:37,964 --> 00:08:41,184 Like this dotted line that's sRGB 84 00:08:41,184 --> 00:08:44,424 and like red's a bit off greens a 85 00:08:44,424 --> 00:08:51,244 bit off but it's very close you don't notice the difference if you would look 86 00:08:51,244 --> 00:08:57,684 at it side by side but then there's the gaming monitor and red's just completely 87 00:08:57,684 --> 00:09:03,044 off and green is way out there blue is still pretty much correct. 88 00:09:07,322 --> 00:09:07,542 What? 89 00:09:11,642 --> 00:09:18,142 Not quite. It's just an HDR gaming monitor that does whatever. 90 00:09:20,682 --> 00:09:25,422 No, like this is the measurement from. Is this a mode or something? 91 00:09:27,242 --> 00:09:30,862 No, not in this case. Like this is some other image mode. 92 00:09:33,322 --> 00:09:36,622 And if you watch 93 00:09:36,622 --> 00:09:39,862 if you show an 94 00:09:39,862 --> 00:09:43,742 sRGB image on that second monitor it will 95 00:09:43,742 --> 00:09:47,622 happily show you colors but green 96 00:09:47,622 --> 00:09:50,822 will be that green and not the one 97 00:09:50,822 --> 00:09:54,382 we defined before so green 98 00:09:54,382 --> 00:09:59,682 and red look more intense on that screen which in 99 00:09:59,682 --> 00:10:07,122 many cases if you like that that's fine but if you then need to create content 100 00:10:07,122 --> 00:10:13,442 for displays that are actually sRGB then you have a problem because what you 101 00:10:13,442 --> 00:10:17,942 see will not be what someone else sees when they watch it on their screen. 102 00:10:19,982 --> 00:10:25,642 The second reason that sRGB isn't great is that it's it only covers a small 103 00:10:25,642 --> 00:10:29,322 part of the entire range of human vision. 104 00:10:31,042 --> 00:10:37,602 Displays still can't reproduce all of the right side here, which is the Rec. 105 00:10:37,762 --> 00:10:44,502 2020 color space that's used for HDR content, but they can do a significant fraction of it. 106 00:10:45,602 --> 00:10:50,762 And we want to use that color. If you watch a movie, you don't want to be limited 107 00:10:50,762 --> 00:10:59,402 to a small subset of colors, But if you can actually show what the real colors in the real world do, 108 00:10:59,642 --> 00:11:03,842 then you can make the movie look a lot more lifelike. 109 00:11:06,350 --> 00:11:13,850 To deal with all these differences in colors we need to use color management. 110 00:11:15,790 --> 00:11:21,650 I left out the actual math you don't need to be scared about it if you want 111 00:11:21,650 --> 00:11:27,910 to know about it you can look it up it is not that complicated but basically, 112 00:11:29,550 --> 00:11:38,610 we use linear rgb values in our source color space I will talk a bit more about the linear part later. 113 00:11:40,190 --> 00:11:46,130 And we multiply that with a matrix that converts from sRGB to that objective 114 00:11:46,130 --> 00:11:48,490 independent x, y, z color space. 115 00:11:49,710 --> 00:11:55,290 Then we have x, y, z values and we multiply those by a matrix that goes from 116 00:11:55,290 --> 00:11:57,610 x, y, z to our target color space. 117 00:11:59,170 --> 00:12:05,410 And then you're done. then you have RGB values that on the display show the 118 00:12:05,410 --> 00:12:12,950 same color as the sRGB content actually wanted to show and of course this also 119 00:12:12,950 --> 00:12:18,710 works in the opposite direction if we have some HDR content we just, 120 00:12:19,470 --> 00:12:26,630 calculate a matrix that goes from the rec 2020 color space to XYZ and then another 121 00:12:26,630 --> 00:12:29,590 that goes from XYZ back to sRGB. 122 00:12:30,970 --> 00:12:39,210 That second case is a little bit more complicated though, because Rec.2020 has 123 00:12:39,210 --> 00:12:42,890 a lot of colors that an sRGB display just cannot show. 124 00:12:45,627 --> 00:12:47,907 To deal with that, we need to use gamut mapping. 125 00:12:50,167 --> 00:12:56,727 This, I will not go into the details of how you do it, because the current implementation 126 00:12:56,727 --> 00:13:01,687 in QWIN isn't that great, and I don't know that much about it, like how to... 127 00:13:01,687 --> 00:13:07,047 There's a lot of different approaches, and it would take a long time to go through 128 00:13:07,047 --> 00:13:09,307 all of that, and it involves a lot of math. 129 00:13:11,167 --> 00:13:16,127 But basically, we need to do some mapping of all the colors us that we can't 130 00:13:16,127 --> 00:13:24,487 show on our target display and move them inside of that triangle that we can actually show. 131 00:13:27,227 --> 00:13:36,007 So now we kind of covered all the very basics about color, at least in practical terms. 132 00:13:36,127 --> 00:13:40,167 Like this, like I said, there's a lot of biological and 133 00:13:40,167 --> 00:13:47,867 psychological things and a lot of other are not RGB color spaces that we generally 134 00:13:47,867 --> 00:13:56,327 don't care about that much on the compositor side at least and that I don't know that much about, 135 00:13:58,007 --> 00:14:05,707 but we left something out before in the X Y Y color space that segment Y it's 136 00:14:05,707 --> 00:14:13,287 about brightness and we can't have color without brightness I mean it would just be black. 137 00:14:15,307 --> 00:14:17,327 So let's talk about it. 138 00:14:21,087 --> 00:14:27,707 SRGB uses the sRGB EOTF, the electro-optical transfer function. 139 00:14:28,987 --> 00:14:34,347 That's a very fancy word for saying it's a function where you put in the RGB 140 00:14:34,347 --> 00:14:38,167 value and you get out an actual brightness value. 141 00:14:41,090 --> 00:14:48,890 Srgb displays just take your value and take it to the power of 2.2 and then 142 00:14:48,890 --> 00:14:52,030 you have a resulting value from 0 to 1. 143 00:14:52,790 --> 00:14:58,130 So that's relative to the maximum brightness of your display it's a pretty simple 144 00:14:58,130 --> 00:15:04,990 situation the reason that we use this instead of of just the value directly 145 00:15:04,990 --> 00:15:11,430 corresponding to the brightness we want to show is that we humans, 146 00:15:11,590 --> 00:15:15,050 we don't see brightness in a linear way. 147 00:15:16,330 --> 00:15:21,210 We can see a lot more shades in the darkness than we can see in the bright areas of an image. 148 00:15:22,630 --> 00:15:30,310 So this basically compresses the image data and we can use fewer bits to represent 149 00:15:30,310 --> 00:15:35,350 the data in a way that we can't see steps in the brightness. 150 00:15:38,250 --> 00:15:42,530 There is, however, a second transfer function that is pretty widely used, 151 00:15:43,450 --> 00:15:45,350 and it's the perceptual quantizer. 152 00:15:47,070 --> 00:15:51,570 I didn't put the equation in here because I was too lazy to type it all out. 153 00:15:51,610 --> 00:15:54,290 It's a lot bigger than sRGB, 154 00:15:56,430 --> 00:16:03,370 but it basically just allocates even more of the range to darker values and 155 00:16:03,370 --> 00:16:07,390 that follows our brightness perception a lot more closely. 156 00:16:07,570 --> 00:16:10,990 So we can compress the data better. 157 00:16:13,010 --> 00:16:18,430 But it also does something else very differently. If you look at the Scala, 158 00:16:18,630 --> 00:16:27,270 this doesn't go from 0 to 1 to an output of 0 to 1, but it outputs 0 to 10,000. 159 00:16:28,510 --> 00:16:36,690 Now this is in nits or candela per square meter it's just a unit for brightness 160 00:16:36,690 --> 00:16:39,190 you might know that from some displays, 161 00:16:41,510 --> 00:16:42,230 and. 162 00:16:45,115 --> 00:16:48,375 What you can do with that is HDR. 163 00:16:49,715 --> 00:16:54,715 Now, HDR is pretty much a marketing term that doesn't mean that much. 164 00:16:55,915 --> 00:16:59,475 Applications like to slap the label on every display they can find. 165 00:17:00,175 --> 00:17:06,255 Like, this is HDR, so we can charge you more money for it, even though it doesn't 166 00:17:06,255 --> 00:17:07,495 really do a good job at it. 167 00:17:09,335 --> 00:17:13,975 But basically, the perceptual quantizer defines, 168 00:17:15,115 --> 00:17:18,155 an sdr brightness that black line there 169 00:17:18,155 --> 00:17:21,895 of 203 nits so 170 00:17:21,895 --> 00:17:25,275 that's a very small part of the whole output range 171 00:17:25,275 --> 00:17:35,935 and that sdr white is basically the normal brightness the if you go outside 172 00:17:35,935 --> 00:17:43,935 and you see the street and a tree like those would be roughly sdr brightness and then you have, 173 00:17:45,115 --> 00:17:49,375 the sky with clouds that are a lot brighter and you have the sun that's just 174 00:17:49,375 --> 00:17:57,535 insanely bright and you can use that rest of the value range to represent that in your image. 175 00:17:59,515 --> 00:18:05,695 In practice this means that some displays need to be able to go brighter than, 176 00:18:06,495 --> 00:18:10,395 their normal brightness in some areas of the screen. 177 00:18:12,675 --> 00:18:17,115 Now, here we have the same problem as with color. 178 00:18:17,595 --> 00:18:20,735 Most displays can't actually do HDR. 179 00:18:21,855 --> 00:18:27,995 So if an image has this transfer function, we have a lot of data that we just 180 00:18:27,995 --> 00:18:30,535 cannot represent on our screen. 181 00:18:32,795 --> 00:18:38,495 To do that, we again need to do some color management. In this case, we do tone mapping. 182 00:18:39,735 --> 00:18:46,815 All the brightness values that are above the level that is the SCR white need 183 00:18:46,815 --> 00:18:52,215 to be mapped down, so you don't just see a white blob like in the first image. 184 00:18:55,155 --> 00:19:02,435 This is an example of Quinn's tone mapping algorithm. It is not quite perfect 185 00:19:02,435 --> 00:19:05,175 yet, but I would say it does a decent job. 186 00:19:06,175 --> 00:19:12,155 Instead of the clouds that are just limited to the maximum brightness that we 187 00:19:12,155 --> 00:19:20,055 can see, being just a giant white blob, you can actually see some details in the lower image. 188 00:19:23,113 --> 00:19:31,473 So all of this is very nice you now have a very rough idea hopefully of, 189 00:19:32,273 --> 00:19:41,793 what all the color and brightness things means but what does it actually matter for your applications. 190 00:19:44,533 --> 00:19:51,333 What do you do in practice because so far most of you will have probably just 191 00:19:51,333 --> 00:19:57,233 used srgb numbers in your applications, and that mostly works out fine, right? 192 00:19:58,993 --> 00:20:05,893 And the simple answer is, if your app only needs sRGB, you don't do anything. 193 00:20:06,973 --> 00:20:14,193 On Wayland. On X11, things are complicated and messy, and you're on your own 194 00:20:14,193 --> 00:20:17,213 if you want to do color management on X11. 195 00:20:18,393 --> 00:20:24,233 But on Wayland, Quinn assumes, if your application doesn't tell the compositor 196 00:20:24,233 --> 00:20:30,573 that it's doing anything fancy with colors, then it's just using sRGB like most applications are. 197 00:20:32,173 --> 00:20:35,793 So Quinn takes that image from your application, 198 00:20:38,153 --> 00:20:42,413 looks at the display, looks at the display settings that the user has configured, 199 00:20:42,673 --> 00:20:47,373 if they have a color profile or if we're using just the data from the display, 200 00:20:48,733 --> 00:20:52,713 and it applies that color profile profile, it does all the color and brightness 201 00:20:52,713 --> 00:20:58,033 transformations and the resulting colors should be mostly correct. 202 00:20:59,413 --> 00:21:04,493 Not all displays do an amazing job at this, but if you calibrate it with a color 203 00:21:04,493 --> 00:21:06,873 profile, the result should be good. 204 00:21:10,222 --> 00:21:17,582 If your app needs more than just the basic srgb though you need to use the wayland 205 00:21:17,582 --> 00:21:27,502 color management protocol with this you can tell quinn you are using the rec 2020 color space, 206 00:21:28,462 --> 00:21:34,322 you are using the perceptual quantizer transfer function instead of just srgb 207 00:21:34,322 --> 00:21:40,382 be you can tell it that you're using like exactly what the display already does 208 00:21:40,382 --> 00:21:44,882 and Quinn will use that information in, 209 00:21:45,542 --> 00:21:53,482 its transformation to the display and it will ensure that the resulting colors 210 00:21:53,482 --> 00:22:00,142 will be correct again now you can also query the compositor for what the display 211 00:22:00,142 --> 00:22:04,842 can actually do I give your application needs to do some more fancy things. 212 00:22:05,782 --> 00:22:10,042 You can get information about what color space it does, how bright it goes, 213 00:22:10,282 --> 00:22:15,542 how much HDR range you have, what the brightness setting is, a lot of good stuff. 214 00:22:17,922 --> 00:22:24,042 Now I also need to say that technically speaking, the color management protocol is still not done yet. 215 00:22:24,902 --> 00:22:31,082 In Plasma 6.1, you need to set this environment variable to make Quinn actually 216 00:22:31,082 --> 00:22:39,202 support the protocol otherwise you just can't use it in git master it is enabled 217 00:22:39,202 --> 00:22:43,142 by default so you can just directly start using it, 218 00:22:44,882 --> 00:22:47,962 of course dealing with Wayland might 219 00:22:47,962 --> 00:22:51,142 not be very simple especially if 220 00:22:51,142 --> 00:22:58,422 you don't know anything about it but I have a small test app that you can just 221 00:22:58,422 --> 00:23:07,242 copy paste code from if you like or you can use it on your computer to see what 222 00:23:07,242 --> 00:23:10,702 kind of color space your display can actually do. 223 00:23:14,482 --> 00:23:17,582 If you just want to look at 224 00:23:17,582 --> 00:23:20,742 some pretty HDR videos or play HDR games 225 00:23:20,742 --> 00:23:27,182 there's some earlier work that you can just use right now without needing to 226 00:23:27,182 --> 00:23:34,082 do a lot of additional work you can start games in game scope with dash dash 227 00:23:34,082 --> 00:23:38,022 hdr dash enabled and it will just work, 228 00:23:39,702 --> 00:23:44,042 and for videos you need to do a bit more you need to install this vulkan layer 229 00:23:44,042 --> 00:23:50,422 and run mpv with this long command all of that will be sorted out in time so 230 00:23:50,422 --> 00:23:59,222 that it just works you double click a video file and you get HDR or SDR or whatever the video does. 231 00:24:02,274 --> 00:24:08,134 Now, last but not least, I want to promote this repository. 232 00:24:08,874 --> 00:24:15,974 It has a lot of deeper explanations, a lot of links and discussions to color 233 00:24:15,974 --> 00:24:19,374 management, HDR, and Wayland color management things. 234 00:24:20,614 --> 00:24:24,654 And it helped me a lot to understand a bunch of these things. 235 00:24:24,654 --> 00:24:27,694 So if you are 236 00:24:27,694 --> 00:24:30,494 interested in knowing more about color 237 00:24:30,494 --> 00:24:35,194 management than this very superficial overview you 238 00:24:35,194 --> 00:24:38,834 can use that to get that information and go 239 00:24:38,834 --> 00:24:43,574 through it at your own pace yeah and 240 00:24:43,574 --> 00:25:01,854 that's really it and now we have a lot of time for questions Thank you for your questions. 241 00:25:01,894 --> 00:25:04,654 Yeah, thank you. And Paul Ketchans? 242 00:25:09,754 --> 00:25:16,054 Is there a reason why the Rack 2020 color space excludes so much on the left 243 00:25:16,054 --> 00:25:18,514 side of the coordinate space? space. 244 00:25:18,834 --> 00:25:25,154 Like it looks like it tries to fill the entire space except at the left. 245 00:25:27,474 --> 00:25:27,634 So. 246 00:25:31,594 --> 00:25:37,794 So I don't know the details of how this color space was developed, 247 00:25:38,014 --> 00:25:45,134 but I assume it's just a lot easier to get that actually into a display. 248 00:25:46,134 --> 00:25:53,694 A color space isn't very useful if most of the colors in it can't actually be shown on a display. 249 00:25:59,456 --> 00:26:02,596 Color, because of our nature, it has more of this green. 250 00:26:04,596 --> 00:26:10,256 So it's just theory, but I believe it's because we're more sensitive to the green color. 251 00:26:12,296 --> 00:26:19,816 Pretty likely. I have a question about how the HDR color is represented in images. 252 00:26:19,996 --> 00:26:25,756 So, for example, in a mobile phone, we can make a photo with HDR and without 253 00:26:25,756 --> 00:26:30,336 HDR, but actually we have the same RGB numbers, right? 254 00:26:30,476 --> 00:26:37,016 Or HDR images contain additional numbers on top of RGB? 255 00:26:39,196 --> 00:26:45,756 Could you repeat that question? So when we make a photo, for example, 256 00:26:45,756 --> 00:26:51,576 on a mobile phone, we can enable HDR, but it produces the same image, 257 00:26:51,736 --> 00:26:53,056 but with different colors. 258 00:26:53,156 --> 00:27:01,656 And the colors are represented it as RGB from 0 to 255 or HDR use additional 259 00:27:01,656 --> 00:27:03,936 numbers to store the colors? 260 00:27:04,616 --> 00:27:14,096 So in general, HDR doesn't need to use a different amount of bits, like you can... 261 00:27:14,096 --> 00:27:20,296 My HDR monitor at home only does 8 bits, so 0 to 255. 262 00:27:21,416 --> 00:27:27,956 But it is usually recommended that you use at least 10 bits of resolution because 263 00:27:27,956 --> 00:27:34,336 while the PQ transfer function is a lot more efficient, 264 00:27:35,136 --> 00:27:43,416 you still have a very steep curve on the bottom and on 8 bits you may be able 265 00:27:43,416 --> 00:27:46,456 to see some banding, some brightness steps in it, 266 00:27:47,276 --> 00:27:49,336 but it's not strictly necessary. 267 00:27:53,497 --> 00:27:56,777 So it's less of a question i just 268 00:27:56,777 --> 00:27:59,557 want to say thank you for putting work into 269 00:27:59,557 --> 00:28:02,477 this and also for bearing with me in 270 00:28:02,477 --> 00:28:08,197 all these cultures i know it's not been it has not been fun thank you for putting 271 00:28:08,197 --> 00:28:21,257 in all that time so if i understood you right you focused in this talk mainly on what, 272 00:28:22,077 --> 00:28:26,557 Quinn currently does with HDR content and mapping it then to sRGB. 273 00:28:26,797 --> 00:28:31,737 You talked about the transfer function and I guess sort of a static tone mapping implementation. 274 00:28:32,277 --> 00:28:37,657 But there's also systems and content that define their own transfer functions 275 00:28:37,657 --> 00:28:39,637 and tone mapping functions that are. 276 00:28:40,577 --> 00:28:45,117 Parameterized by metadata in the content like per scene or per frame like Dolby 277 00:28:45,117 --> 00:28:47,817 Vision or HDR 10 plus and stuff like that. 278 00:28:47,977 --> 00:28:51,197 How far are we from supporting that or maybe 279 00:28:51,197 --> 00:28:54,917 we already do and how does it click together so on 280 00:28:54,917 --> 00:28:58,457 Wayland you can change your HDR metadata 281 00:28:58,457 --> 00:29:01,437 per frame so you can tell Quinn 282 00:29:01,437 --> 00:29:04,957 this frame has a lower maximum 283 00:29:04,957 --> 00:29:08,677 brightness so it can adjust its tone mapping function if you 284 00:29:08,677 --> 00:29:12,157 have a special format like HDR gain 285 00:29:12,157 --> 00:29:17,017 maps where you have two images and you need to compute them together there's 286 00:29:17,017 --> 00:29:22,037 currently at least no support for that in the Wayland protocol you have to do 287 00:29:22,037 --> 00:29:26,377 that computation on the application side but it could be added at some later 288 00:29:26,377 --> 00:29:30,077 point if it brings us benefits thank you. 289 00:29:35,897 --> 00:29:38,537 Test test test test so it's probably 290 00:29:38,537 --> 00:29:41,777 a little bit too technical to put inside your talk but if I Right. 291 00:29:42,077 --> 00:29:47,777 Remember correctly, if I have a color managed GUI application, 292 00:29:48,097 --> 00:29:53,737 doesn't the surface that has to be color managed be like a literally different 293 00:29:53,737 --> 00:29:58,157 surface or else it messes up the UI, which is all encoded in sRGB, right? 294 00:29:59,217 --> 00:30:05,877 It depends. If you do some color management yourself, you can transform the 295 00:30:05,877 --> 00:30:10,957 colors of that UI to the color space that you put the whole window in. 296 00:30:11,697 --> 00:30:16,177 So you can make it work in the application. Of course, it is more convenient, 297 00:30:16,357 --> 00:30:21,057 especially with HDR content, if you can just put it on a separate surface and 298 00:30:21,057 --> 00:30:22,817 let the compositor just deal with it. 299 00:30:25,597 --> 00:30:27,077 Have enough time for any other questions? 300 00:30:33,008 --> 00:30:40,048 So for the future, as far as I understand, this is for content like images and videos. 301 00:30:40,888 --> 00:30:49,008 Would that evolve into the Plasma UI itself being capable of better colors in 302 00:30:49,008 --> 00:30:51,588 capable displays or something like that? 303 00:30:52,728 --> 00:30:59,088 So it is possible. We could make that happen with some changes in Qt so that 304 00:30:59,088 --> 00:31:02,448 it supports all the color management bits itself. 305 00:31:03,768 --> 00:31:11,288 Right now, I don't see a huge need for it because sRGB works fine for normal UI stuff. 306 00:31:11,948 --> 00:31:20,108 But if we want to have like a plasmoid on your desktop that shows an HDR image, 307 00:31:20,348 --> 00:31:23,388 it would of course be nice to actually make that happen. 308 00:31:24,348 --> 00:31:27,388 Yeah my question kind of follows up 309 00:31:27,388 --> 00:31:30,908 on that one because you you skipped 310 00:31:30,908 --> 00:31:34,088 the parts about like psychological effects 311 00:31:34,088 --> 00:31:37,068 of colors and then i'm assuming you 312 00:31:37,068 --> 00:31:39,828 have maybe read a bit about it and i was 313 00:31:39,828 --> 00:31:43,148 wondering if you heard anything that maybe we 314 00:31:43,148 --> 00:31:49,988 should try to to use for normal applications colors which no other applications 315 00:31:49,988 --> 00:31:58,288 are using like we should try to go beyond srgb and maybe then all the KDE apps 316 00:31:58,288 --> 00:32:00,548 look more colorful than anyone else. 317 00:32:04,399 --> 00:32:07,119 Has a slider in the 318 00:32:07,119 --> 00:32:10,039 display settings if your monitor is 319 00:32:10,039 --> 00:32:13,119 in HDR mode but I intend to expand that 320 00:32:13,119 --> 00:32:16,139 to SDR mode as well where you can say 321 00:32:16,139 --> 00:32:21,899 that you want just all SDR applications to be more intense because not everyone 322 00:32:21,899 --> 00:32:26,659 cares about correctness and maybe you want your colors to look just a lot more 323 00:32:26,659 --> 00:32:33,559 intense right but you could make that happen like it's a few lines of code to, 324 00:32:34,399 --> 00:32:41,679 make all KDE applications like a few lines of code in each app to make the colors 325 00:32:41,679 --> 00:32:45,179 more intense by just scaling all the colors, 326 00:32:46,039 --> 00:32:52,799 yeah so the question was also if you know if we should do this if you have seen 327 00:32:52,799 --> 00:32:58,599 anything about psychological whatever so I know that many people just. 328 00:32:59,519 --> 00:33:03,199 Assume brighter more intense colors looks 329 00:33:03,199 --> 00:33:07,139 better and that's a 330 00:33:07,139 --> 00:33:10,079 matter of like personal preference I think 331 00:33:10,079 --> 00:33:17,879 in many cases it is good to have like this normal background of sRGB colors 332 00:33:17,879 --> 00:33:27,639 so that when you watch an HDR video you actually notice the difference but in terms of marketing, 333 00:33:27,939 --> 00:33:33,379 using HDR capabilities of the display certainly can have an appeal. 334 00:33:34,939 --> 00:33:39,579 So yeah, that's something that we should maybe discuss further. 335 00:33:40,779 --> 00:33:42,539 I think I don't, uh, okay. 336 00:33:46,759 --> 00:33:53,299 Sometime ago I was, um, calibrating a monitor for Pentium Colors and, uh, 337 00:33:53,519 --> 00:34:00,179 I I noticed that it required the brightness to be at maximum in order for the calibration to work, 338 00:34:00,319 --> 00:34:06,059 which led me to realize that apparently for certain calibrations, 339 00:34:06,079 --> 00:34:11,939 they rely on certain specific brightness and they might not work if the brightness 340 00:34:11,939 --> 00:34:13,399 is lower than a certain threshold. 341 00:34:13,399 --> 00:34:16,139 Hold my question will then 342 00:34:16,139 --> 00:34:19,179 be will it be possible to 343 00:34:19,179 --> 00:34:22,799 have something like a a calibration 344 00:34:22,799 --> 00:34:25,919 that works for multiple brightnesses maybe 345 00:34:25,919 --> 00:34:29,579 a function based on that yes so icc 346 00:34:29,579 --> 00:34:36,399 profiles as far as i know don't have any standardized or even experimental functionality 347 00:34:36,399 --> 00:34:44,099 for that but we can add non-standard tags and i want to make that happen yes 348 00:34:44,099 --> 00:34:46,399 because it's very useful to know, 349 00:34:47,339 --> 00:34:51,899 what exactly the backlight of your display does when you set it to 50.