Color bug in EX9 renderer with alpha below 1%

Just came across a strange bug when using colors with alpha values of less than 0.01 (i.e. 1%).

In an EX9 renderer with clear set to 0 colors with less than 1% alpha will not eventually reach the full color. Black with alpha set to 0.005 will only reach about 50% black (i.e. grey).

Please see the attached sample patch.

Also in that patch the color IOBoxes don’t show the correct values either.

Very strange indeed. Anyone have any explanation?

I am running 30.2 x64.

colour_alpha_bug.v4p (14.6 kB)

Even stranger, when i just connect a HSL (Color Join) to a color IOBox, then adjusting for example Saturation in the HSL Node will change Saturation and to a certain extend also Lightness and sometimes Hue. Almost like it is turning it into RGBA and then back to HSL (badly).

Here is another example of the color IOBox not showing correct values and HSL(Color Split) also not showing correct values. There seems to be no immediately obvious pattern to the bug. :/

Tested and is the same in 30.2 x64, 30.2 x86 and 29.2 x86.

HSL_bug.v4p (20.8 kB)

hei selz,

regarding your second concern, please note there is a difference between HSL and HSV color models, see: colors

you’re using HSL nodes with the IOBox that displays HSV. and in your last example (from the patch) the hue does not turn out correctly after the split because a color with 0 saturation has no hue defined. therefore in this example you cannot expect to get any specific hue out of the split.

@joreg

doh! Thanks for pointing that out. Silly of me to miss that…

Any idea what could cause the first bug though? Do you know how i can use the output of a EX9 renderer that has clear set to 0 in a texture? It always comes out black!

the explanation is quite technical and boring:

alpha blending is a multiplication of the color channels with the quadalpha value, in theory with infinite high resolution numbers this will never reach 0 but will get as close to 0 as you want, its an asymptotic behavior which has a high slope at the beginning but gets slower and slower when it comes near 0.
but of course we do not have infinite resolution, the normal texture format is RGBA with 8 bit per channel. that is a super low resolution, only 256 steps for each channel. there is 0 and the next step is about 0.004 then 0.008 and so on. so the value just gets stuck after a short while and the calculation is the same in very frame.

a simple solution is to render into a DX9Texture and set the color format to 16 bit per channel. this will get so close to 0 that your (low res) monitor will display it as 0 as it is below 0.004, see patch:

colour_alpha_no_bug.v4p (18.5 kB)

@tonfilm

Thanks for your explanation! That totally makes sense now. Ill go with 16bit color and solve it that way. :)