PDA

View Full Version : Gradient Colors Aren't Matching



Schwyhart
03-01-2018, 09:44 AM
What I mean by this, is say I have a surface that is a dark gray. I have another surface that has all the same material settings, but I added a gradient to the color channel. The gradient goes from yellow to the exact same dark gray color.
The end result is below. (Left is solid color, Right is same color but inside the Gradient node. In this example the Gradient only has one value. All color settings are 128 128 128)

140428

MonroePoteet
03-01-2018, 11:08 AM
I'm not sure what you mean when the Gradient "only has one value". A Gradient pretty much needs at least two values to be a Gradient.

It appears you're using LW 2018. The Gradient input to the Principled BSDF material seems to work for me. Sample LW2018 scene / object attached.

The Gradient uses the X Coordinate as input, ranging from -1.0 to 1.0, with gradient keys at -1, -.5, 0.0, .5 and 1.0, with all but the 0.0 being a yellow. VPR shows what I'd expect.

140429

mTp

MonroePoteet
03-01-2018, 11:22 AM
Ah, I re-read your post - you're saying that if you simply add a single-value Gradient to the Color channel input with all Color values at (128,128,128), it's a different output. I'd guess that one of the three separate colors isn't actually (128,128,128) - the BG color in the Gradient, the key in the Gradient, or the Color in the Material node.

What version are you running?

mTp

Schwyhart
03-01-2018, 12:09 PM
On my phone now.
On the Gradient node, you have color sliders (not sure if there's an official name), and you can delete all but one. Regardless, even if you had 100 color sliders that were all the same colors, it would appear as one solid color. All color rgb value inputs are set to set to 128,128, 128.

Left sphere has no gradient is actually a solid color. Right sphere has the gradient node, but all color sliders are the same rgb values - making it appear as a solid color.

My thinking is that both spheres should appear the same, but the sphere with the gradient node appears brighter. Make sense?

MonroePoteet
03-01-2018, 12:43 PM
Yes, now it makes sense, but I can't reproduce it either in LW 2015.3 or LW 2018.0.1. Adding a (128,128,128) constant Gradient into the Color Channel shows the same color for me. I think the *very* slight lightness of the right-hand sphere is caused by having more of the surface toward both the Light and the Camera.

Some other parameter is different in your case, apparently. Perhaps post the sample objects?

140437

Here, the spheres are swapped, with the gradient-input sphere on the left.

140439

mTp

P.S. these are LW 2018.0.1 renders

Schwyhart
03-01-2018, 01:53 PM
Texture Shaded Solid view and layout
140441

Surface 1 = PBSDF no nodes
Surface 2 = Gradient Panel
You can see my spheres are different shades
140442

140443

Schwyhart
03-01-2018, 01:58 PM
and yes...2018.0.1
and it's the same result in 2018.0.2...for me anyway.

It's very possible I made a mistake somewhere. I just need told where so I can fix it.

I don't know if this video clears things up or not, but here goes.
https://youtu.be/ePNuaVdRTzs

MonroePoteet
03-01-2018, 03:07 PM
Well, the problem is reproduced when I change the Color Space preferences ("o") "Convert Color Space to Linear" option "Picked Colors" to sRGB as in your sample scene. When I select that option, the Gradient picked color displayed in its sample is *not* (127,127,127), but a much brighter gray (170,170,170), even if I type (127,127,127) into the R,G,B entries in the Color Picker. The brighter gray is seen by using an eyedropper selection tool from an image editor.

140444

If you really want Convert Color Space to Linear=>Picked Colors set to sRGB, note that the Layers=>Color Layer node with Gradient type does not display this behavior.

I'll have to defer to someone MUCH more expert in Color Space conversions to know why you'd want (or not want) Picked Colors set that way.

Good luck!
mTp

P.S. So, I guess either the Color Picker in the Principled BSDF node doesn't comply with the sRGB conversion, or the Color Picker in the Gradient node shouldn't? Dunno.

Schwyhart
03-01-2018, 03:11 PM
I haven't messed with the Color Space options. That's interesting that sRGB doesn't affect both spheres the same.
I'll keep it Linear for now. Thanks for helping me out! :)

So, is this a bug or not?

MonroePoteet
03-01-2018, 03:17 PM
I haven't messed with the Color Space options. That's interesting that sRGB doesn't affect both spheres the same.
I'll keep it Linear for now. Thanks for helping me out! :)

So, is this a bug or not?

Ah, cross posted. As I said in my prior P.S., it seems to me that the Color Picker in the Principled BSDF node should comply with the sRGB conversion, but I don't know for sure.

As I said previously, I'll have to defer to someone MUCH more familiar with how Color Space options "should" affect the picked colors.

mTp

gerardstrada
03-01-2018, 06:11 PM
I haven't updated yet but it looks like a bug, since constant colors MUST comply with CS conversions. That's the way it works from LW10 to LW 2015.3. An option for not affecting Gradient output may be to additionally include a vector output in the gradient node, but color output should comply with CS conversions.

It seems also in LW 2018 that the sRGB preset has Picked and Light colors set to linear. This is wrong. For sRGB standard this value should be 2.2 gamma. The most near curve in CS panel is sRGB instead. The only scenario when linear would be correct for sRGB standard in CS panel would be if we would be correcting picked colors in the picker instead (with 2.2 power function), however LW color picker is not shipped with gamma correction options. In such case, perhaps you might want to try SG_CCPicker.



Gerardo

gar26lw
03-02-2018, 05:12 AM
It seems also in LW 2018 that the sRGB preset has Picked and Light colors set to linear. This is wrong. For sRGB standard this value should be 2.2 gamma. The most near curve in CS panel is sRGB instead. The only scenario when linear would be correct for sRGB standard in CS panel would be if we would be correcting picked colors in the picker instead (with 2.2 power function), however LW color picker is not shipped with gamma correction options. In such case, perhaps you might want to try SG_CCPicker.

Gerardo


i submitted a bug about this a while back. was hoping fixed in this latest patch.

LWB-3032

it does say in testing so i think it’s getting fixed.

MSherak
03-02-2018, 12:10 PM
Default CS has picked colors and light colors as linear. Which the gradient node is fixed at. This is also why the default material color for items is 128,128,128 in 2018. If you change it to sRGB color pick then ones middle color should be 187,187,187. (I would call this part a bug since it sticks with 128,128,128)

To get the colors the same do a Pow function of 2.2 per channel on gradients when working with sRGB in Picked and Light CS set. Course there will be a oh so slight variance since you are doing a conversion from vector->scalar->vector.

Hope this helps.

gerardstrada
03-03-2018, 05:05 PM
Gar26lw, Hope it's fixed.

MSherak, it seems the other bug you mention (haven't noticed before) is related to LW picker since other pickers specify the correct color values. Btw, the slight variance you are noticing is due to sRGB curve is slightly different than 2.2 curve, but the 2.2 linearization -for picked colors only- is the way to go for the sRGB standard case, while images should be linearized with the inverse of the sRGB curve.


I haven't explained myself well in my previous post, so just in case, color output of a Gradient should comply to CS settings because (same as a constant Color node) it has the primary purpose of setting color property in shaders or materials. In order to be correctly fixed to linear, the Gradient node might have a vector output additionally. So we would have an output fixed to linear (vector) and another output complying with CS settings (color).



Gerardo

jwiede
03-04-2018, 06:39 PM
i submitted a bug about this a while back. was hoping fixed in this latest patch.

LWB-3032

it does say in testing so i think it’s getting fixed.

You're referring to the bug where sRGB CS has "picked colors" & "light colors" as "Linear", correct?

Hopefully when they fix that, they'll realize they need to fix gradient color outputs as well. Might be worth adding a mention of that to your bug (that gradient color output generated from "picked color" keys must be treated same as "picked colors" w.r.t. CS handling).

gar26lw
03-04-2018, 08:07 PM
You're referring to the bug where sRGB CS has "picked colors" & "light colors" as "Linear", correct?

Hopefully when they fix that, they'll realize they need to fix gradient color outputs as well. Might be worth adding a mention of that to your bug (that gradient color output generated from "picked color" keys must be treated same as "picked colors" w.r.t. CS handling).

added

DuneBoy
03-07-2018, 10:50 PM
Firstly there are two bug fixes that were should be known about. They involve the Color and Gradient nodes, the attached image shows the bug manifesting in LW2015 using its sRGB preset. What happens is that during evaluation of the node the color values are linearized based on the Picked Colors space. And as you can see when piping multiple Gradient nodes together, you end up getting a progressively darker color. Thus both nodes have had the eval-time linearization removed. If there are cases where you know that a correction is needed, either to linear or from it, LW2018 includes a Convert Color Space node which can apply and/or remove a selected color space from the input color.

Now as for the change to the sRGB preset, that is by design, this same topic was addressed on Facebook here:
https://www.facebook.com/groups/lightwiki/permalink/1333923083380354/

My posts consist of:

(my first reply)

The options in the top half [of the CS tab] are for linearizing a color, going from a given space to linear. Any popup set to Linear means "don't touch these colors"

In versions before we supported color space you had an implicit sRGB curve on the picked colors (roughly sRGB based on the monitor that was used when picking colors). To compensate for that the option for Picked Colors and (Picked) Light Colors can be used to remove that implicit sRGB curve to linearize them. This only makes sense for legacy assets.

But by leaving it at sRGB it would continue the paradigm of having the color values include sRGB baked in to the values.

Given that there were already going to be adjustments needed for legacy assets in LW2018, it was decided to finally break that habit and change the preset to the way it should be. Thus the numerical values are linear (and kept that way throughout the pipeline) and it's only when displayed that a color gets corrected (not including whatever output options you've set).


(in answer to why Picked and Light Colors were sRGB in the preset in LW2015)

The preset remained as it was in LW2015 to maintain the best compatibility with existing assets. But you can customize it in LW2015 to match LW2018's and get the same benefit when starting new assets (linear color values, only corrected at display-time). However when it's left with sRGB for the Picked/Light Colors, then the color values would be no different than an asset from LW9.6 (because you'd end up with the same implicit sRGB curve on your colors).

If you have the Picked/Light Colors and Display all set to sRGB you'll notice that the colors displayed in the color picker (the good one :) ) don't look any different than if it was all set to linear (or if you were picking in 9.6, see the problem).

That's because as it's displaying the colors, the picker first linearizes based on the Picked/Light Colors' space (if not Linear) and then applies the Display space. And when those options match you end up right back where you started. And thus you haven't actually compensated for the Display space (and it looks as it would before LW10).

By having the Picked/Light Colors set to Linear and Display set to sRGB then the color picker simply applies the Display space and you're then picking a linear color value based on its corrected appearance. That's why the colors in the picker appear brighter with LW2018's preset than with LW2015's.


(in reply to the question, is it wrong to use the sRGB preset in 2015 originated assets)

I wouldn't say you were wrong, but the implications of the settings need to be known.

Picked/Light Colors set to sRGB is absolutely needed for pre-10 assets if you want to use the linear workflow. Otherwise you end up with the render too bright (implicit sRGB+the applied Display space). However the side effect is that anything you create with that setup will continue to require that setup in order to look as expected. But the side benefit is that you could continue to use those assets back in 9.6 and they would still have the expected colors.

If you were starting a new project fresh in LW2015 then you could use the LW2018-style setup or LW2015's preset and still get the benefits of linear workflow, however with the LW2018-style setup the color values that are stored in the scene/objects will be linear (that's preferred because then color-correction takes place only at display-time).

You can think of the LW2018-style setup as a "Power User" configuration for when legacy assets aren't a concern. So LW2018 now simply makes that better setup the default for the preset.

gerardstrada
03-12-2018, 02:09 AM
Firstly there are two bug fixes that were should be known about. They involve the Color and Gradient nodes, the attached image shows the bug manifesting in LW2015 using its sRGB preset. What happens is that during evaluation of the node the color values are linearized based on the Picked Colors space. And as you can see when piping multiple Gradient nodes together, you end up getting a progressively darker color. Thus both nodes have had the eval-time linearization removed. If there are cases where you know that a correction is needed, either to linear or from it, LW2018 includes a Convert Color Space node which can apply and/or remove a selected color space from the input color.
The correct behavior is to have picked colors in the Gradient complying to CS settings, and besides, having also input Key Colors unchanged. Because linearization should be done over picked colors only, not over colors plugged into Gradient color inputs. i.e. in v2015 when we connect an output Color Layer node into an input Color Layer node, there's no change in color. Same thing should happen with Gradient's KeyColor inputs. Let's notice that sacrificing a correct feature to fix a bug of another parameter is not really a bugfix.


Now as for the change to the sRGB preset, that is by design, this same topic was addressed on Facebook here:
https://www.facebook.com/groups/lightwiki/permalink/1333923083380354/
My posts consist of:
(my first reply)
The options in the top half [of the CS tab] are for linearizing a color, going from a given space to linear. Any popup set to Linear means "don't touch these colors"
In versions before we supported color space you had an implicit sRGB curve on the picked colors (roughly sRGB based on the monitor that was used when picking colors). To compensate for that the option for Picked Colors and (Picked) Light Colors can be used to remove that implicit sRGB curve to linearize them. This only makes sense for legacy assets.
In sRGB standard (which sRGB preset is for), picked colors are never sRGB curve but 2.2 gamma curve. sRGB curve is an output curve not a screen curve. This is why picked colors and light colors should be 2.2 gamma, not sRGB curve. This correction has nothing to do with "legacy assets" but with the display curve of the sRGB standard. Let's notice that sRGB curve is more near to 2.2 curve than linear curve in this case.


But by leaving it at sRGB it would continue the paradigm of having the color values include sRGB baked in to the values.
Paradigm has not changed. Display curve for sRGB standard has not changed up to date. This is, computers calibrated to sRGB standard still needs a 1/2.2 correction and therefore a pow linearization of 2.2 is still needed. Let's say inverse sRGB curve is the most near curve to 2.2 in this case. But linear definitively is not.


Given that there were already going to be adjustments needed for legacy assets in LW2018, it was decided to finally break that habit and change the preset to the way it should be. Thus the numerical values are linear (and kept that way throughout the pipeline) and it's only when displayed that a color gets corrected (not including whatever output options you've set).
The numerical values are not linear if no linearization has been performed, those are non-linear uncorrected color values for sRGB standard, so sRGB preset of v2015 is more near to "the way it should be".


(in answer to why Picked and Light Colors were sRGB in the preset in LW2015)
The preset remained as it was in LW2015 to maintain the best compatibility with existing assets. But you can customize it in LW2015 to match LW2018's and get the same benefit when starting new assets (linear color values, only corrected at display-time). However when it's left with sRGB for the Picked/Light Colors, then the color values would be no different than an asset from LW9.6 (because you'd end up with the same implicit sRGB curve on your colors).
The linearization correction in the sRGB standard has nothing to do with "existing assets", but with its screen curve, which is 2.2 gamma correction. So no matter if assets are new or old, if they are not linearized, they are not linear.


If you have the Picked/Light Colors and Display all set to sRGB you'll notice that the colors displayed in the color picker (the good one) don't look any different than if it was all set to linear (or if you were picking in 9.6, see the problem).
That's because as it's displaying the colors, the picker first linearizes based on the Picked/Light Colors' space (if not Linear) and then applies the Display space. And when those options match you end up right back where you started. And thus you haven't actually compensated for the Display space (and it looks as it would before LW10).
You think "you end up right back when you started", but you are not really looking. This is what happens behind the scenes:

You set sRGB preset (I mean the correct v2015 preset, not the incorrect v2018 preset) and let's say we need to set up a middle grey color according to sRGB standard monitor. So set a 0.5 R,G,B value in the picker. Then LW applies a linearization to this value according to sRGB curve, which is something about 0.214041. So that's the real value LW is assigning, not the 0.5 value you are seeing in the picker. Then it applies a display correction according to sRGB curve, which display the 0.214041 value back AS IF IT WAS 0.5, but this is just an illusion, because the actual value you are seeing is already linearized. You can check if this is certain by setting the display parameter to linear in CS panel. then you'll see the current color you have picked is actually darker.

Just in case, display colors are set up at display time only, they do not actually change the pixel RGB values. Only input corrections change actual pixel values.



By having the Picked/Light Colors set to Linear and Display set to sRGB then the color picker simply applies the Display space and you're then picking a linear color value based on its corrected appearance. That's why the colors in the picker appear brighter with LW2018's preset than with LW2015's.
With sRGB setup of v2018 is happening precisely the opposite. In sRGB standard, you are picking gamma corrected NON-LINEAR colors, not linear colors. Surely you have had the best intention to improve LW, but you are confusing 2 main basic color management terms:

You are confusing the concept LINEAR with the concept PERCEPTUALLY UNIFORM.

In sRGB preset of v2018 (picked/light colors set to Linear and display set to sRGB) you are picking colors perceptually uniform, not linear colors. Linear colors means they are radiometrically correct, perceptually uniform colors means their tonal values are distributed according to our NON-LINEAR visual perception. TWO DIFFERENT CONCEPTS in color management practice.


(in reply to the question, is it wrong to use the sRGB preset in 2015 originated assets)
I wouldn't say you were wrong, but the implications of the settings need to be known.
Picked/Light Colors set to sRGB is absolutely needed for pre-10 assets if you want to use the linear workflow. Otherwise you end up with the render too bright (implicit sRGB+the applied Display space). However the side effect is that anything you create with that setup will continue to require that setup in order to look as expected. But the side benefit is that you could continue to use those assets back in 9.6 and they would still have the expected colors.
If you were starting a new project fresh in LW2015 then you could use the LW2018-style setup or LW2015's preset and still get the benefits of linear workflow, however with the LW2018-style setup the color values that are stored in the scene/objects will be linear (that's preferred because then color-correction takes place only at display-time).
You can think of the LW2018-style setup as a "Power User" configuration for when legacy assets aren't a concern. So LW2018 now simply makes that better setup the default for the preset.
As explained, linearization has nothing to do with new or old assets, it has to do with linearizing non-linear values of almost perceptually uniform colors in sRGB standard. Standard which has not changed up to date. This means the sRGB preset in v2015 is the "almost" technically correct preset to work in linear light and the only reason to change it would be to set 2.2 curve correction instead of sRGB curve for picked and light colors. sRGB preset in v2018 is just plain wrong and it's a wrongly induced bug that must be corrected. Color management purpose is for color consistency and predictability and that's precisely what v2018 breaks with this bug.


https://s9.postimg.org/ksv8246n3/LW2018s_RGBpreset.png
https://s9.postimg.org/m7wsqvab3/LW2015s_RGBpreset.png

If you ask me, a better way to set up picker colors is directly in the picker, as it's possible in SG_CCPicker, or at least as it was possible in the original version of JCPicker.



Gerardo

DuneBoy
03-12-2018, 03:37 AM
I'll be excerpting quotes and replying to those. And just a few, since it's the middle of the night.


Because linearization should be done over picked colors only, not over colors plugged into Gradient color inputs.

Yeah, by the definition of that setting, sure. Except there's no way to tell one "Picked Color" from another, 3 floats are simply that, 3 floats. There's no metadata associated with a single color value, like where it came from or what profile it might have have applied to it if any. You can copy a color value from something unrelated to the render, paste it on a light and on a surface node. In the later two cases it would assume to have whatever profile is set for the (picked) Light Colors and Picked Colors settings.


Let's notice that sacrificing a correct feature to fix a bug of another parameter is not really a bugfix.
Nope, the way the Gradient node worked (removing the Picked Colors profile on eval) was not correct and there were bug reports on it. Manipulating colors because you assume they are X breaks things for all the times they aren't X (mixing Normal maps via the Gradient node would be a case of this bug screwing up the data).


You think "you end up right back when you started", but you are not really looking. This is what happens behind the scenes
Uh, you do end up back where you start.
Start with 0.5, remove sRGB (Picked Colors)
Now you have 0.214041
Now apply sRGB (Display)
And you have 0.5 again
And that is literally what happens when the color picker is displaying colors. It's the same routine for the color swatches each time they redraw, remove Picked (or Light) Colors, then apply Display.

What you've described isn't how it actually works when it comes to picking colors. The values, i.e. the numbers displayed, always show the actual untouched numbers. It's only the swatches that ever get corrected. "Then LW applies a linearization to this value according to sRGB curve" Only at certain times on-the-fly, and only if Picked (or Light) Colors is set to sRGB.


If you ask me, a better way to set up picker colors is directly in the picker, as it's possible in SG_CCPicker, or at least as it was possible in the original version of JCPicker.
Neither of those pickers use the latest API version and would therefore be treated as being unaware of color space and thus the Affect Color Picker option will potentially be manipulating the color values going into and out of the the picker. Just a heads up.


sRGB preset in v2018 is just plain wrong
That's a matter of opinion since it was already being used by some individuals before LW2018 adopted it.

I'll close by stating that there is room for improvement in the way the color picker displays the colors. But I'm trying to avoid a ton of "when is it lying to me and how" type of issues, so right now it never manipulates the numerical values, only how they are visually displayed (the same paradigm used elsewhere).

gerardstrada
03-12-2018, 06:47 PM
I'll be excerpting quotes and replying to those. And just a few, since it's the middle of the night.
Yeah, by the definition of that setting, sure. Except there's no way to tell one "Picked Color" from another, 3 floats are simply that, 3 floats. There's no metadata associated with a single color value, like where it came from or what profile it might have have applied to it if any. You can copy a color value from something unrelated to the render, paste it on a light and on a surface node. In the later two cases it would assume to have whatever profile is set for the (picked) Light Colors and Picked Colors settings.
If by definition and practical convenience should be in that way, then it should be in that way.
How developers make it possible, that's precisely their job.

Thinking loudly, if when enabling a Key Color, a new entry is created, and when disabling it this entry is deleted, there should be indeed a way to differentiate it from picked color entry and treat those 3 floats differently.


Nope, the way the Gradient node worked (removing the Picked Colors profile on eval) was not correct and there were bug reports on it. Manipulating colors because you assume they are X breaks things for all the times they aren't X (mixing Normal maps via the Gradient node would be a case of this bug screwing up the data).
As explained before, for linearization - necessary to properly work in linear light in sRGB standard - profile evaluation is the correct way for color property. For normal maps (which is vector, not color) then, LW should include a vector input instead, which wouldn't comply with CS settings. Maybe they could include a profile conversion section within Gradient node for these special cases. And if for some reason, this is not possible for them, then input Key Color should be switched altogether into input Key Vector. In that way user user will know what to expect and behavior would be correct. Otherwise it's still a bug.



Uh, you do end up back where you start.
Start with 0.5, remove sRGB (Picked Colors)
Now you have 0.214041
Now apply sRGB (Display)
And you have 0.5 again
And that is literally what happens when the color picker is displaying colors. It's the same routine for the color swatches each time they redraw, remove Picked (or Light) Colors, then apply Display.
Of course you are not really looking. Once again:
Start with 0.5 in the picker
remove sRGB
Now you have 0.214041 in the shader. Let's say it's an emission material (100%) no lights. So the rendered pixel value is 0.214041. Actual pixel value is the value that enters to render.
Now apply sRGB Display and you have 0.5 BUT AT DISPLAY TIME ONLY, because actual pixel value is now 0.214041, NOT 0.5.

So the calculated value in the render is not "0.5 again" because the color computed is now linearized.


What you've described isn't how it actually works when it comes to picking colors. The values, i.e. the numbers displayed, always show the actual untouched numbers. It's only the swatches that ever get corrected. "Then LW applies a linearization to this value according to sRGB curve" Only at certain times on-the-fly, and only if Picked (or Light) Colors is set to sRGB.
Not, linearization is applied on the actual pixel value, what's applied on the fly is the display correction. Once again (sorry for quoting myself):

"You can check if this is certain by setting the display parameter to linear in CS panel. then you'll see the current color you have picked is actually darker."

So let's do the test:

https://s10.postimg.org/ydfs52xy1/displaytest.png

Correct sRGB preset. The first render is set to sRGB display curve. Value of the pixel? 21.40% (or 0.214041 in float). Second render is set to linear display curve. Pixel value? 21.40% (or 0.214041 in float). So what's applied on the fly is the display value, NOT the linearized colors.



Neither of those pickers use the latest API version and would therefore be treated as being unaware of color space and thus the Affect Color Picker option will potentially be manipulating the color values going into and out of the the picker. Just a heads up.
Not, the usage I'm proposing is not in that way. As commented before (really sorry for quoting me again):

"The only scenario when linear would be correct for sRGB standard in CS panel would be if we would be correcting picked colors in the picker instead (with 2.2 power function), however LW color picker is not shipped with gamma correction options. In such case, perhaps you might want to try SG_CCPicker."

So in a native implementation we should be able to set the picked colors globally in CS panel and also be able to change it locally in the picker. That's more handy (i.e. to solve the Gradient issue) that having a fixed global value.


That's a matter of opinion since it was already being used by some individuals before LW2018 adopted it.
If those individuals are working in sRGB standard, then they are not working properly in linear light, they are working in perceptually uniform space. Two different things.


I'll close by stating that there is room for improvement in the way the color picker displays the colors. But I'm trying to avoid a ton of "when is it lying to me and how" type of issues, so right now it never manipulates the numerical values, only how they are visually displayed (the same paradigm used elsewhere).
The paradigm implies to display colors in a predictable way in the first place. That's the paradigm used elsewhere for sRGB. Cases when we let untouched picked colors is when we don't work in sRGB standard and we either don't have a way to properly correct for such standard in a predictable way and our only option is picking colors perceptually checking RT preview, or we are able to correct colors for wider gamut displays with better proper tools.



Gerardo

DuneBoy
03-12-2018, 07:39 PM
Of course you are not really looking. Once again:
Start with 0.5 in the picker
remove sRGB
Now you have 0.214041 in the shader. Let's say it's an emission material (100%) no lights. So the rendered pixel value is 0.214041. Actual pixel value is the value that enters to render.
Now apply sRGB Display and you have 0.5 BUT AT DISPLAY TIME ONLY, because actual pixel value is now 0.214041, NOT 0.5.


That's correct, except it isn't what I was referring to in my original and reply posts. I'm talking about the actual process of picking a color, not once that color has been picked and it's time to render it. In the actual color picker, when the Picked Colors and Display spaces match (sRGB), then the result (visual and numerical) is the same as if CS wasn't enabled at all. You end up with color values that are in sRGB space stored in the objects and scene.

DuneBoy
03-12-2018, 08:52 PM
Just for a test I grabbed the closest other 3D package I could find to see how it handles colors. Attached are the blender screen grabs, one with the Display Device set to None (no management) and another with it set to sRGB (it doesn't have anything equivalent to Picked Colors by the look of it). On the right side of each window is a color swatch set to 0.5, yet it displays brighter (188, 188, 188) in the one set to sRGB.

It's interesting to note that they don't apply the display space to the visual colors in their picker, but rather to the values sent for visualizing the color (you can see this because the handle on the right of the color wheel is higher than the mid point in the sRGB version). Whereas I do apply the display space to the visual colors and the handles have a 1:1 relationship with the underlying color values (i.e. 0.5 means the handle is at the halfway point for that axis regardless of CS settings).

gerardstrada
03-13-2018, 02:39 AM
That's correct, except it isn't what I was referring to in my original and reply posts. I'm talking about the actual process of picking a color, not once that color has been picked and it's time to render it. In the actual color picker, when the Picked Colors and Display spaces match (sRGB), then the result (visual and numerical) is the same as if CS wasn't enabled at all. You end up with color values that are in sRGB space stored in the objects and scene.
So You have been referring about the process in the screenbuffer when picking a color and I've been referring to what happens with the actual color within the whole process from picking to rendering and final display. This is good because we can see in a basic way how the picked color process fit into the whole process and which is the most proper way of displaying a picked color within the linear light process in sRGB standard. But let's talk about it in a moment...


Just for a test I grabbed the closest other 3D package I could find to see how it handles colors. Attached are the blender screen grabs, one with the Display Device set to None (no management) and another with it set to sRGB (it doesn't have anything equivalent to Picked Colors by the look of it). On the right side of each window is a color swatch set to 0.5, yet it displays brighter (188, 188, 188) in the one set to sRGB.
It's interesting to note that they don't apply the display space to the visual colors in their picker, but rather to the values sent for visualizing the color (you can see this because the handle on the right of the color wheel is higher than the mid point in the sRGB version). Whereas I do apply the display space to the visual colors and the handles have a 1:1 relationship with the underlying color values (i.e. 0.5 means the handle is at the halfway point for that axis regardless of CS settings).
Did you know that in 1923, the first guy who published the number of human chromosomes counted 24 pairs? It was not until 1956 that a young Indonesian student counted the actual number, 23 pairs. The funny thing is that for 33 years, all prestigious scientists thought that human chromosomes were 24 pairs :D Think you get the point.

I can understand we search for references when approaching unknown or uncertain topics, but the best way to learn things is by studying the nature of the things in practice first, checking and proving how things work and how things does not work in the field by using logic, and then we can develop with knowledge of cause and context, a correct, or more proper, or more convenient process, management or direction. This also allows us to identify mistakes, or less proper, or less convenient procedures from other sources when crossing information, it does not matter where this info comes from. Curiously, I've tried virtually ALL render engines available in main 3D packages and I haven't found a single one which has not a small or big mistake in color management aspect. So yes, it's a very tricky topic even for the specialists and the few color scientists I've meet.

Blender is not really a good reference in this case because, as it's stated in the color management configuration file, color spaces for color picking and texture painting is not internally supported yet. This is a serious flaw for users when picking colors in Blender for sRGB standard, which is the most common standard.

But let's don't worry, as we have seen, this topic is very simple in LW and it will not be difficult for us to find which is the most coherent way to approach it. So let's come back and check how the picked process you have described fit in the whole linearization process I've described for sRGB standard.

Linearization process is really more than just undoing a curve, but to keep things simple, let's say that's the only thing we need to do. Moreover, to keep things even simpler, let's say that undoing the sRGB curve for picked colors is the most convenient curve available in LW - we know it's gamma 2.2, but let's say it's sRGB curve. So let's see the context first (the linearization process) and then the picking color process.

We have a sRGB-corrected input color value (this is, a non-linear value) which we need with this sRGB correction in order we see an almost perceptually uniform color as it's suppose it is under sRGB viewing environment conditions. Let's pick a middle grey. In order to work in a radiometrically correct space to process this color realistically (this is, like in the actual scene) by the renderer, we need to linearize this color value. For doing so, we need to undo the sRGB curve by applying the inverse formula. This of course give us a darker value as result. In order to preview the resulting color back as perceptually uniform color, we apply back (on the fly) a sRGB gamma correction. Let's notice that the actual color value is in fact darker of what we are seeing. This is good because we can for example apply in DP Filter Node Editor a DP Bloom filter or DP DOF filter and process this image yet in linear space while previewing in almost perceptually uniform space.

In this context, if we apply the same color transformation to the screen-buffer, we get a predictable result. The displayed color appearance will be what we are expecting as a perceptually uniform result for any given value. Not darker, not brighter. plus, the result is actually linear.


https://s9.postimg.org/m7wsqvab3/LW2015s_RGBpreset.png

But if we skip the linearization part for the picked input color value, the displayed color will be brighter of what we are expecting for a given value. So we are gonna need to check and adjust it perceptually, more or less, what we think it could be a middle grey color. If our environment condition is not exactly the one specified by sRGB standard (very common), or if we have a window in front or behind of us causing flare, or we had lights ON one day and lights OFF another day, or the same scene is worked by multiple artists, or if stars are not aligned, then this middle grey will be different on every case. There's not consistency there, and predictability is lower than the first case. Moreover, if by some reason we need to pick an exact color, let's say to calibrate camera with color checker, then results will be radiometrically wrong. This is terrible for a physically based rendering approach.


https://s9.postimg.org/ksv8246n3/LW2018s_RGBpreset.png

Good thing about the first case is that the color we expect in sRGB standard is very near of the color we get. When avoiding linearization, we are getting a washed-out color and making things unnecessarily harder for the artists. They just want to pick a color and get that color, that's all. They don't want to deal with color management and set colors by trial and error if they can avoid it. We wouldn't use a rock to drive a nail if we can use a hammer. The way sRGB preset in v2015 behaves is the most invisible way they can get with current LW CM system. We can say is the more coherent way and "radiometrically correct" in all scenarios.



Gerardo

jwiede
03-13-2018, 02:57 PM
I'm with Gerardo on this, having "Picked Colors" & "Light Colors" as "Linear" leads to an inconsistent model (imbalanced corrections). Gerardo's last example very clearly demonstrates the problem, that is NOT "middle grey" in sRGB. The OP's issue is another demonstration of what happens because of the inconsistent model that results from "Picked Colors" & "Light Colors" being set to "Linear".

In a consistent model, as the settings were in 2015, such problems do not occur.

DuneBoy
03-13-2018, 06:56 PM
We have a sRGB-corrected input color value (this is, a non-linear value) which we need with this sRGB correction in order we see an almost perceptually uniform color as it's suppose it is under sRGB viewing environment conditions. Let's pick a middle grey. In order to work in a radiometrically correct space to process this color realistically (this is, like in the actual scene) by the renderer, we need to linearize this color value. For doing so, we need to undo the sRGB curve by applying the inverse formula. This of course give us a darker value as result. In order to preview the resulting color back as perceptually uniform color, we apply back (on the fly) a sRGB gamma correction. Let's notice that the actual color value is in fact darker of what we are seeing. This is good because we can for example apply in DP Filter Node Editor a DP Bloom filter or DP DOF filter and process this image yet in linear space while previewing in almost perceptually uniform space.

In this context, if we apply the same color transformation to the screen-buffer, we get a predictable result. The displayed color appearance will be what we are expecting as a perceptually uniform result for any given value. Not darker, not brighter. plus, the result is actually linear.


"plus, the result is actually linear."
We must be mixing our terms, because the result wouldn't be linear. As soon as you've applied the Display profile those values are no longer linear, they'd be whatever profile you've applied.

I've attached two images, each is a screen capture of the color picker displaying the same color. One was taken while the CS settings were set to the 2015 sRGB preset and the other was taken with the settings all set to Linear. Please tell me which one is which and the method used to make that determination. (Not trying to be an arse just trying to demonstrate something)

Next, let's pretend we've started a project using the 2015-style preset. We're halfway done when IT comes in and replaces our sRGB computer monitor with a rec.709 based display. What CS settings do you use and why? Because we need those existing assets to look good in the same scene alongside the new assets.

Roughly what color space is a color going to be in (for storage and render) if it's visually picked while using the 2018-style preset?

Lastly, our EXRs store the linear color values from the renderer. Why is storing linear values accepted for EXRs but not objects and scenes?



having "Picked Colors" & "Light Colors" as "Linear" leads to an inconsistent model (imbalanced corrections).

Not if the values stored in the objects and scene are already linear. If you're dealing with legacy assets that have sRGB baked in then by all means feel free to set Picked (and Light) Colors to sRGB and if you're loading a legacy scene it should load with those 2015-style settings.

Just in case I wasn't clear in my initial posting, the change to the preset was by design. Which means there was research and meetings held before the change was made (nearly two years ago), so it wasn't made lightly. Trust me, I was in the "Picked Colors should match Display" camp before I understood how the system worked (I'm not talking about "in theory", I'm talking about how the actual code actually works) and the full implications of Picked Colors being non-Linear.

gerardstrada
03-14-2018, 02:13 AM
having "Picked Colors" & "Light Colors" as "Linear" leads to an inconsistent model (imbalanced corrections). Gerardo's last example very clearly demonstrates the problem, that is NOT "middle grey" in sRGB. The OP's issue is another demonstration of what happens because of the inconsistent model that results from "Picked Colors" & "Light Colors" being set to "Linear".

In a consistent model, as the settings were in 2015, such problems do not occur.
Totally agree.


"plus, the result is actually linear."
We must be mixing our terms, because the result wouldn't be linear. As soon as you've applied the Display profile those values are no longer linear, they'd be whatever profile you've applied.
The terms I'm using are standardized color management terms. And the result will be INDEED linear, because the part I'm referring there is the whole linearization process of ACTUAL pixel color values for sRGB standard (the context) I'm not referring there to the picked color process yet. The picked color process comes later when I say "In this context..." So the actual color value is indeed linear as demonstrated here:


https://s10.postimg.org/ydfs52xy1/displaytest.png

The displayed color is not the actual pixel color value of the rendered image, it's just the screen-buffer color displayed on the fly. As we can see (once again) in the image above, the actual pixel color value is linear, I mean, "accurately" linear.


I've attached two images, each is a screen capture of the color picker displaying the same color. One was taken while the CS settings were set to the 2015 sRGB preset and the other was taken with the settings all set to Linear. Please tell me which one is which and the method used to make that determination. (Not trying to be an arse just trying to demonstrate something)
You are not being an "arse", all the contrary, you are demonstrating precisely the nice thing about sRGB preset in v2015: that the linearization process is invisible for the artist, but it's there, as shown in the above image.



Next, let's pretend we've started a project using the 2015-style preset. We're halfway done when IT comes in and replaces our sRGB computer monitor with a rec.709 based display. What CS settings do you use and why? Because we need those existing assets to look good in the same scene alongside the new assets.
There are several ways to solve the issue of your example. Let's notice first what I commented before (sorry for quoting me once again):

"Linearization process is really more than just undoing a curve, but to keep things simple, let's say that's the only thing we need to do."

Let's notice that LW CS system has not yet the proper tools for doing this. But if you'd have to solve such issue within LW CS system limitations, and once again, let's say sRGB is the proper curve to keep things simple, you could still use sRGB for picked colors because environment viewing conditions has not changed, so you may generate a LUT from your display standard curve -which is not Rec.709 (that's the input curve, not the display curve) - to sRGB standard, and use that as display profile.

Notice also that ideally, we would be proofing colors from standard display to device display. I have to use here an unreleased version of SG_CCTools for doing such proper color transformations in unbounded mode.


Roughly what color space is a color going to be in (for storage and render) if it's visually picked while using the 2018-style preset?
If by storage you mean the final render, that's in dependency of your image format. The render may be roughly linear (well, not so linear if you change your display standard and keep the same environment viewing conditions as in your example) but it would be a trial and error process anyway, because the display correction is being applied over an already perceptually uniform color, so that's like adding gamma correction twice over the same color, that's the reason why it looks washed-out, and you are making the simple process of picking a color much harder for the artist, who just want predictability, without mention that things would be broken if one needs to pick exact colors according to sRGB standard.


Lastly, our EXRs store the linear color values from the renderer. Why is storing linear values accepted for EXRs but not objects and scenes?
Values in objects and scenes are fp anyway and they can be stored linearly, but the way they are stored should not affect the way picked colors are displayed, which is more predictable and consistent for usage in the way v2015 sRGB preset is set up.


Not if the values stored in the objects and scene are already linear. If you're dealing with legacy assets that have sRGB baked in then by all means feel free to set Picked (and Light) Colors to sRGB and if you're loading a legacy scene it should load with those 2015-style settings.
When adjusting colors by trial and error, colors are roughly linearized, and as I commented in my previous post, it won't be consistent by depending on external factors for sRGB standard. When leaving this to CS settings, this is more predictable and consistent for sRGB standard. and if you need to pick exact values, then as John says, the v2018 model is inconsistent and not as predictable as in v2015.


Just in case I wasn't clear in my initial posting, the change to the preset was by design. Which means there was research and meetings held before the change was made (nearly two years ago), so it wasn't made lightly. Trust me, I was in the "Picked Colors should match Display" camp before I understood how the system worked (I'm not talking about "in theory", I'm talking about how the actual code actually works) and the full implications of Picked Colors being non-Linear.
Really sorry such bug made by design has taken 2 years. As commented, it's a wrongly induced bug. It doesn't matter if they have been discussing this by 2 months or 2 years. It's just a step backward in practice for sRGB standard users. If it's a matter of years, I've been working in linear light for 20 years now (since LW 5.6 days or so), and in that time, I was used to "linearize" picked/light colors perceptually - just like v2018 is set up now!!! :D when we developed SG_CCTools with Sebastian back in 2007, it was GREAT because we did not have to linearize proper color by trial and error process anymore. When LW 10 came out, it automated the process for global TRC corrections. But this is not a years competition, this is about what works better in practice, and as shown before, LW2015 sRGB preset is a more predictable way and "radiometrically correct" in all scenarios, which is key for physically based rendering.



Gerardo

jwiede
03-14-2018, 08:46 PM
There's another benefit to the way 2015 has it: It doesn't require re-converting picked colors & gradients in node flows to accommodate the local display color space. That's good from an efficiency standpoint, because it's wasteful to have every node flow using them do such conversions. Node flows are interpreted so having to stick math nodes into every such usage to convert colors to display space is inefficient.

However, there's a even better reason why 2015's approach is better, which is that it allows node flows to be color-space independent in their handling of picked colors & gradients, which isn't possible the way 2018 is set up. The way 2018 has it, the node flow has to include nodes to convert picked/light/gradient colors to display space, and that means the node flow must somehow know a priori what display space setting is being used locally (which it cannot easily determine automatically). The 2018 approach would require users to go in and alter the embedded display space conversions for whatever they're using (harming the utility of such node flows, compounds, etc.).

Again, look at the OP's cited scenario, as well as Geraldo's examples, and it's quite clear that the 2018 approach creates problems for users that do not exist in the 2015 approach. The 2018 approach is _not working "fine"_, users are being required to do manual conversions to display space of picked/light/gradient colors in node flows to retain consistency, and that clearly demonstrates the problem.

DuneBoy
03-14-2018, 08:48 PM
But this is not a years competition

Correct, it's not. I merely mentioned that the change was made nearly two years ago as a way to demonstrate that in that time (and over many, many builds, oh so many builds), the beta testers didn't cry that the sky was falling.

Sadly I can no longer devote anymore of my time to this discussion. You are more than welcome to report any issues you have. However if they concern this topic please include as much documentation as possible (e.g. "here's how it works in product X", "here's the docs from OCIO about it"), suggestions for other ways to solve the original problems (sRGB colors in objects being one) are also welcome. Suggestions for improvement to the color picker are of course welcome as well.

Laterz

gerardstrada
03-15-2018, 08:01 AM
Correct, it's not. I merely mentioned that the change was made nearly two years ago as a way to demonstrate that in that time (and over many, many builds, oh so many builds), the beta testers didn't cry that the sky was falling.
Well, the only one talking about someone crying that the sky is falling is you. We are just discussing and demonstrating with examples and proper technical terms why sRGB preset in V2018 lacks of predictability and consistency compared with V2015 preset, even the examples you have provided prove this. Idea of all people involved in this thread is helping to make things better, not worse. If no betatester noticed this was a backward step, maybe is because even the most basic aspects of color management are very uncertain topics for most of users. Guess in such cases, developers need to consult to people more informed about CM frameworks, workflows, pipelines and proper CM practices.

If for some reason picked values are in the need to be stored linearly (because let's say the plan is to make them compatible with OSL) then this should not affect to the user, because color management should be, as much as possible, invisible for artists. How developers solve this issue in the code it's up to them, as long as it doesn't affect users' work adversely like happens with v2018 sRGB preset, because they are leaving the proper linearization of all color properties to users' perception and it should be actually just like happens when we save an EXR file as in your example, we see an almost perceptually uniform image but we save a linear one. We don't need to have a wrongly displayed image for doing so. In the same way, displayed picked colors should look like they are suppose to look in sRGB standard and resulting values should be linear. Sorry but this is not happening in v2018 and that's a bug that must be corrected yet.

If you ask me, the simplest way of doing this, once again, is by performing the linearization in the picker. With a native linearization in the picker, they would solve the display problem, the gradient problem, the linear storage problem, because at least in the SG_CCPicker case, the displayed value is perceptually uniform but the stored value and the final rendered value is linear.

They could do as happens in Maya as well, where the user can display linear values in almost perpetually uniform way and non-linear values also in the same perceptually uniform way, not with a gamma correction added twice ...and if they really want to rock, they can... well, let's wait first this simple bug can be fixed.


Sadly I can no longer devote anymore of my time to this discussion. You are more than welcome to report any issues you have. However if they concern this topic please include as much documentation as possible (e.g. "here's how it works in product X", "here's the docs from OCIO about it"), suggestions for other ways to solve the original problems (sRGB colors in objects being one) are also welcome. Suggestions for improvement to the color picker are of course welcome as well.
I think that the ones who need to include documentation about this bug "by design" is the people who have suggested and approved this bug. And I'm not referring to mention what others packages are doing, I'm not referring to reference any external source because there's a lot of crap in the web coming from ANY source, I'm referring to reference reasons with knowledge of cause and context as we are doing here.

And if you want to know, this does not happen when working properly in linear light with PRenderman, Arnold, Maxwell, Vray, you name it. you can notice even by doing a quick search to their documentation:

Pixar Renderman
https://community.renderman.pixar.com/article/1206/linear-workflow-color-management.html


https://dbql2bd8kqpp.cloudfront.net/network6/storage/7/attachments/5581-16225-6412.jpg

see? color swatch is linearized. The basic flow is exactly how sRGB preset is setup from LW v10 to v2015.

"We are picking colors in the sRGB values of our monitors, so IT IS NOT LINEAR." (caplocks added my me) "TO COMPENSATE, Maya can apply a LUT to the swatch SO THAT WE ARE PICKING IN THE RIGHT COLOR SPACE." (caplocks added my me).

"Right colorspace" means we pick linear color values and preview perceptually uniform values according to sRGB standard.

Moreover, the line just after that says:

"TO AVOID DOUBLE GAMMA CORRECTION, we need to make sure we uncheck the RenderMan "Linearize Colors" checkbox, under the Render Settings > Features > Shading. This attribute was created pre-Maya 2016 and is redundant with the current workflow."

They use here the terms interchangeably (which is wrong) but what they are referring in practice is that the LUT applied to the swatch is already linearizing the colors, and idea is not doing this twice with the pre-2016 options.

In Maya we are able to switch display or rendered space for the picker values and as long Color Management checkbox is enabled, we ALWAYS will see perceptually uniform colors, this is, linear values will be gamma corrected, or non-linear values won't have gamma correction applied twice.


Arnold:
https://support.solidangle.com/display/A5AFMUG/Gamma+Correction+and+Linear+Workflow
Exactly same story because last version of Arnold uses native Maya CM setup:


https://support.solidangle.com/download/attachments/27164954/inputs-diagram.jpg

what is saying there in color swatch?? oh yes: LINEARIZE

"If you are using a solid color, set the color in the color picker: TO MATCH A SPECIFIC SRGB VALUE, set the “mixing color space” to “Display Space” and enter the sRGB value – WHAT YOU SEE IN THE SWATCH WILL BE WHAT YOU RENDER". (caplocks added my me).

When setting to the "display space" IN THE PICKER, we got gamma corrected values -BUT- the display correction is not applied twice like in v2018 preset:


https://s13.postimg.org/f07bhsqd3/Maya_CP.png

When switching to "rendering space" we got linear values and still proper display correction. So in both cases the displayed picked colors are exactly the same.


https://s13.postimg.org/i71v1gstj/Maya_CPlin.png

Maxwell:
http://support.nextlimit.com/display/maxwelldocs/Camera+panel?src=search

This is made automatically assuming 2.2 gamma by default for the input and output colors:

"Maxwell Render™ internally uses a gamma of 2.2 to convert from spectral space to RGB space. You can use this parameter to control the gamma conversion. Lower gamma values darken the image, higher values lighten the image. Note that you can control this parameter interactively while rendering incore rendering application."

And as we can see, its color picker displays the colors we are supposed to see for 2.2 gamma display
http://support.nextlimit.com/display/maxwelldocs/Color+Picker


VRay:
https://docs.chaosgroup.com/display/VRAY3MAX/Color+Mapping

The Linear Workflow checkbox is disabled by default in Vray because it worked not like v2015 sRGB preset, but as the very old GammaRight shader used to work in LW 5.5, this is, it corrected colors after shading evaluation. In Vray case, proper linear workflow can be now managed by each 3D package, then for avoiding double and improper linearizations, this old feature has been disabled and it's not used anymore.

Vray however deserves a special mention in the case of improper usage in 3Ds Max, since it has been floating around, curiously about 2 years ago, a tutorial where a guy says that picked colors are already... guess what?? linear! :D this guy, is curiously confusing also the concepts of PERCEPTUALLY UNIFORM with LINEAR. He says that picked colors don't need to be linearized because they are already linear. but that's incorrect. Displayed colors are perceptually uniform yes, which makes him think erroneously that the values should be linear then, but that's not the case in reality. OS profile is applying a gamma correction in order to compensate for the non-linearity of the monitor (same as images) so even when the displayed color looks perceptually uniform, actual VALUES are non-linear. Some inadvertent people in color management have bought such incorrect concept and they are making their picking color process harder than necessary.

If you ask me, I don't really have any issues with v2018 preset because I know it's wrong and can continue using a more proper pipeline. But the people who have no clue about color management won't be able to expect a physically based render from LW when even the process of picking a color starts to be not only artist-unfriendly but also unpredictable and inconsistent.



Gerardo

medzo
03-16-2018, 02:05 AM
arghh!!!! so which one is it?

medzo
03-16-2018, 04:24 AM
I just did a test of my own and not sure what to think of.

The scene is really basic. In photoshop I did a simple texture colored RGB 128_128_128.

I have applied texture to ground plane and a sphere and made another sphere with 128_128_128 RGB color.

Both spheres should have the same color, right? Well in 2018sRGB preset they don't look the same, but with '2015sRBG' preset they kinda do and even here is a very small difference.

Is this a simple proof that 2018sRBG preset is not correct? Are other CG packages behaving the same? Or I know just to little about color spaces? :)

gerardstrada
03-19-2018, 05:21 PM
That's a proof that with v2018 sRGB preset, colors are not displayed in a predictable way and you need to adjust it by trial and error until more or less it looks like as what you get with v2015 sRGB preset automatically. Yes, in LW linear workflow context, that's incorrect.

However, you could use v2018 sRGB preset if you would be linearizing picked colors within the picker (I use SG_CCPicker). In such way you would be able not only to linearize your picked colors but also these values would be stored in linear space within the scene, surfaces, nodes and objects. Since this feature is still not native in LW picker, then the preset is incorrect with native LW tools only.

Maybe this graph may explain better what's hapenning behind the scenes when we pick a color:


https://s10.postimg.org/4nm3n16fd/displaycolor.png

Let's say our reference is a camera linear raw. a grey card would have a value of about 0.2 and our visual perception would see this as 50% grey. This happens because our visual perception is non-linear (more sensitive to darks than brights). So like happens in reality, a linear color value will be seen as perceptually uniform IF we could keep the same input luminance values in our display.

but display response is non-linear - curiously, roughly the inverse of our visual perception (a pow function of 2.2 defines its response in sRGB standard). So now the roughly 0.2 linear value provides a color perception for us of about 21% grey, but notice the value is still linear, roughly 0.2.

in order to make it perceptually uniform again, the color swatch value is encoded with a gamma correction of 1/2.2 driving the digital to analog conversion which outputs voltages to the monitor. This more efficiently encode values for 8-bpc bottleneck of screen buffer. So we get again about 50% perceptual grey. But notice the value is not 0.2 anymore, because it has been encoded in non-linear way, so now color value is about 0.5.

in order to process this color back at linear space (as reality works), we need to linearize the value back, in our 3d/compositing software. Of course color will be darker, but that's how a linear middle grey is displayed in non-linear displays.

Finally, a gamma correction is applied back at software level with a LUT which changes -on the fly- the values in the frame buffer again. At software level, a final image is able to be displayed without changing the actual color values of the image, so in the viewer window (and color swatches and surfaces previews) the software is able to override OS color management.

I think the order you are asking these questions is the right way to go. Before asking if is there another package behaving the same (like Blender - because linearizations in the picker are not yet supported) you are asking: Which one is the correct or better behavior? that's the question. because even if you want to follow what another is doing, how would you know you are following the right behavior? If LW wants to lead again, they need to begin to ask this question and not just following what others are doing.



Gerardo

Schwyhart
03-20-2018, 09:36 PM
Well this quickly went over my head lol