Stride and Skia clear color not the same as ImGUI window

seltzdesign · November 26, 2024, 5:34pm

When using ImGUI (Stride), I noticed that the clear color and window color of a ImGUI Window are not the same. Normally you don’t notice it, but when using very dark greys, you can tell.

Is the Stride window and ImGUI using different color spaces?

If I set the same color on an ImGUI window and as clear color for a stride and skia renderer, you can see they are not the same colors:

Skia:

For Skia it is very close, only off by 1 in RGB.

Stride:

For Stride it is much further apart by 5 in RGB.

Any ideas how to convert the colors so they match? (especially in ImGui [Stride]). I am using theming in my application with very dark greys and you can just tell when the windows have a different color to the renderer background

SkiaStrideImGUIColors.vl (33.0 KB)

bjoern · November 26, 2024, 5:44pm

Pobably related to:

github.com/vvvv/VL.StandardLibs

Alternative blending for Stride ImGui region

opened 12:32AM - 08 Mar 24 UTC

gregsn

**Is your feature request related to a problem? Please describe.** Colors typ…ically are too bright. **Describe the solution you'd like** My understanding is that this can't be fixed for the linear color space. Blending just works differently here. That's why I would propose the user be able to choose between different techniques. Sometimes one solution looks better than the other. **Describe alternatives you've considered** An additional in-between render target. But I think the alpha of that render target again will make a problem when applying it to the final output. Also, I tried reasoning with some math, but to my understanding, it's not solvable. **Additional context** current: ![grafik](https://github.com/vvvv/VL.StandardLibs/assets/575557/31b2b872-5355-4f2c-b452-080a3ed02f65) new technique: ![grafik](https://github.com/vvvv/VL.StandardLibs/assets/575557/39b1d7c7-13a7-4d71-add3-a2468585bc14) While the above example makes the new technique look good, there are counterexamples. current: ![grafik](https://github.com/vvvv/VL.StandardLibs/assets/575557/80547df3-a4e2-4e65-8a35-e53ae07521ca) new technique: ![grafik](https://github.com/vvvv/VL.StandardLibs/assets/575557/2162440b-9acc-4868-ab5b-1384e9d52c3f) **The new technique in the shader** ``` if (TSRgb) { streams.Color = float4(ColorUtility.ToLinear(streams.Color.rgb), ColorUtility.ToLinear(streams.Color.a)); } ``` **My math and my reasoning as to why this is not solvable. I might be wrong** This is how I understand the graphics pipeline. Again, it's so *##$&ing complicated, I might be wrong. So that's just my opinion how it works ;) drawing two triangles on top in linear color space: ``` destc1 = srcA.c * srcA.a + destc0.c * (1 - srcA.a) destc2 = srcB.c * srcB.a + destc1.c * (1 - srcB.a) finalcL = togamma(destc2) ``` `destc0`, `destc1` & `destc2` are different states of a pixel in the target surface. `srcA` and `srcB` is what the pixel shader outputs for those two calls. `finalcL` is what I get to see. My understanding is that displaying a linear target surface to the gamma-based screen involves some final `togamma()` call somewhere at the very end of the pipeline. this is how things have been with gamma colors all over the place: drawing two triangles on top in gamma color space: ``` destGammac1 = srcGammaA.c * srcGammaA.a + destGammac0.c * (1 - srcGammaA.a) destGammac2 = srcGammaB.c * srcGammaB.a + destGammac1.c * (1 - srcGammaB.a) finalcG = destGammac2 ``` it's a bit unfair. The names are longer. But it's simpler as the final `togamma()` call isn't performed by the pipeline. task: make the final colors that hit your eye be equal `finalcL =? finalcG` ok. let's only focus on the second triangle been drawn. We need to somehow make them equal. ` togamma(srcB.c * srcB.a + destc1.c * (1 - srcB.a)) =? srcGammaB.c * srcGammaB.a + destGammac1.c * (1 - srcGammaB.a) ` It already seems unlikely that this will work out. Reasoning: `(a*b)^c = a^c*b^c ` but surely `(a+b)^c != a^c+b^c` `togamma(.. + ..)` already gives me no hope to break this up in a way that I'll end up with something that looks exactly like on the right side of the equation. Well, to be honest, I tried for fun. This is what I ended up with when trying to solve for srcB.a `srcB.a = [toLin(togamma(srcB.c) * srcGammaB.a + destGammac1.c * (1 - srcGammaB.a)) - destc1.c] / (srcB.c - destc1.c) ` let's try again. let's try to make them match somehow while keeping an eye on both sides without solving for one variable: `togamma(destc1.c + srcB.a * (srcB.c - destc1.c)) = destGammac1.c + srcGammaB.a * (srcGammaB.c - destGammac1.c) ` not a valid transformation: `destGammac1.c + togamma(srcB.a * (srcB.c - destc1.c)) = destGammac1.c + srcGammaB.a * (srcGammaB.c - destGammac1.c) ` valid: `destGammac1.c + togamma(srcB.a) * togamma(srcB.c - destc1.c) = destGammac1.c + srcGammaB.a * (srcGammaB.c - destGammac1.c) ` not a valid transformation: `destGammac1.c + togamma(srcB.a) * (togamma(srcB.c) - destGammac1.c) = destGammac1.c + srcGammaB.a * (srcGammaB.c - destGammac1.c) ` Ok, I have two invalid transformations in here, but funnily I see this guy here: `togamma(srcB.a)`, which is basically what I propose to do: to tweak the alpha... At least in some cases, it looks better. **Design Options** So what do you think? Can we have a boolean input pin or enum pin on the region where we choose between techniques? Or should we playful and offer a float where you can lerp between the two solutions? Thanks for your great work! @kopffarben

seltzdesign · November 26, 2024, 7:18pm

Thanks, @bjoern. Okay, it seems that defining both colours separately and matching them by eye is the only solution for now.

tonfilm · November 26, 2024, 8:49pm

Could additionally be related to quantization when somewhere in the color conversion chain 8-bit colors are used where each channel can only have 256 different values.

gregsn · November 27, 2024, 2:19pm

up to now:
grafik
upcoming - 6.7. preview >=250:
grafik