Material Color - Storing Colors changes values slightly

[Antonis_Schley]

Hi,

so i don't know, what excactly is going on here:

I am a big fan of the "store color" function with Materials in VRED.

When I used it to transfer a color value between two Materials, i noticed the slider slightly jumps when comparing.

So i checked it and the values differed by a tiny fraction. When i repeated the process it did not change again.

Today i wanted to recreate it, and the values changed 4 times repeating the process, then stayed.

Would love to know if this is something I have to worry about, or if this is related to "output color" or so?

Cheers,

Antonis

[michael_nikelsky]

Only the RGB values you see under output color are actually stored in the material, everything else is recalculated, so there might be indeed situations where the values shift slightly due to floating point inaccuracies from converting between the different color spaces because when you initially change the sliders you calculate a rgb color depending on which color slider you changed. When you you copy it to another material however the rgb color is copied and the rest is calculated from there. 

So nothing to worry about, the color is still the same, just the slider values might be slightly different.

[Antonis.Schley]

Hi @michael_nikelsky ,

thanks for your answer.

So i tested it again.
The RGB values visible to the user are changing too.
With this specific color, i could change it 4 times. After that it stayed.
You can see the difference on the material preview too.

It's not that this is a huge issue, but it seems to be an Inaccuracy.
Am I wrong?

Thanks for your time anyways.

[michael_nikelsky]

That is indeed weird and I can´t reproduce it on my system, even when using the exact same color values you used. I will need to check the code to figure out what might be the cause. An initial guess would be that it has something to do with the display profile in windows messing up the color storage, not sure how that was implemented.

[Antonis_Schley]

I tested if version and/or machine is the cause.

But I was able to reproduce it on my laptop with version 2022.3, while i originally had the issue with 2022.2 on my workstation. I used a different color too...

[michael_nikelsky]

I am still not able to reproduce this. Can you give me a step by step instruction of what you are clicking in which order? Also, which color field are you changing?

There is one thing where you need to pay attention and the is light colors or incandescence colors when photometric parameters are turned on. Since the intensity of the emission is controlled by the separate intensity slider the colors are recalculated based on this. In this case the values might indeed change since they exceeding what the color slider can show. But I don´t assume this is the case here.

[Antonis_Schley]

Hi @michael_nikelsky 

and thanks for not giving up on me!

So while going through my steps creating this issue, i found this out:

If i store the color pressing on the button "store color" there is no issue.

Instead of doing this though I always drag&drop the color from "current" into the store-fields.

Only by doing this, i am getting these deviations. So it seems i should not do that?

[michael_nikelsky · Accepted solution]

Ok, I can reproduce this. I haven´t verified it yet but I think what happens there it will take the color that is rendered on you monitor, which most likely is just 8 bit, and convert that back to our internal color representation. So this is different to just using store Color which directly stores the color you have set.

I am not sure why it degrades even more if you continue with the process, it doesn´t do that for me. But I am working on an sRGB calibrated monitor, my guess is if you are using a wider gamut display the windows color profile might cause some further degradation because the colors get converted multiple times instead of just getting converted once.

So yes, you should avoid doing the drag&drop and use the store color function instead, even if it is less convenient. I will open a ticket for this nonetheless, maybe there is a way for us to fix this.

Kind regards

Michael