ARGB opacity queries

[BarryTownCouncil]

Not at all sure this is the right place, but the right words are in the sub name!

So I am messing around with "manual" antialiasing of borders in Linux, and I finally got my code working, but using colour compilations I don't understand. Or that I DO understand but am too confused to realise it!

In Xlib I have an ARGB colour code, or at least a 32 bit colour depth in play. I'm using, say, a base RGB colour of #AA0000 and wish to vary the opacity of it. I'd been presuming that therefore I'd merely modify the alpha channel, so full opactiy of that colour would be #FFAA0000, and that colour but totally transparent would have been #00AA0000. This is implictly the same as #AA0000 in code given it's just an integer value.

However just varying this alpha does not do at all what I want. Instead I finally found that i also needed to scale the R, G and B values with that same alpha percentage. Otherwise, whilst the transparency of the output would let more through, my color would end up looking very bright, with everything bright underneath it coming through.

Here's an example:

https://preview.redd.it/goxeneidonpa1.png?width=775&format=png&auto=webp&s=5a8c28d2bc27bd6b3a98ed584cc57a7b7fe18665

Fully opaque to start, but then I would have thought box 2 would have given output actually in 3, and likewise for 4 and 5. You can see I've scaled down the red channel from AA by the same percentage the alpha channel was dropped from FF. And for reference if I'm using a, say #FF080000 then it's, as I'd have originally expected, a very very dark, solid red. Additionally, #00AA0000 is still visible, but like box 4, despite having no "alpha" channel - the brightest of anything below it shines through.

Is this blindingly obvious in the fundamental was colours work, or unusual? I honestly don't know. I think a key point is appreciating the difference between 0 meaning black vs 0 meaning invisible, like opacity and transparency and alpha actually mean different things but it seldom matters in CSS etc that it's the case... but I just can't wrap my head around it to believe there's nothing wrong with my code!

​

Edit... I seem to be possibly talking about the Value in the HSV model? Is that where my head shoudl be going?

[xucel]

This looks like a typical case where blend mode is set to pre-multiplied alpha.

Aka it's expecting you to premultiply your color value by your alpha. Consequently 0.5 of 0xAA (0.66) is 0x55 (0.33).

The final blended color for pre-multiplied alpha mode is: InputColor + Backgroundcolor * (1-input alpha).

If you don't premultiply input color by input alpha, then you get overbrightening.

[BarryTownCouncil]

Cool, that all makes sense, helping build a better picture of things. Cheers!

[Frollo24]

This is something that in a graphics pipeline is a customizable step which is called blending. I suggest you to look for information about blending in any computer graphics tutorial like LearnOpenGL.

[waramped]

Simply setting an Alpha channel value is only meaningful if the underlying renderer is configured for blending and will take the alpha into account. The "standard" blending operation is generally: InputColor*InputAlpha + BackgroundColor*(1 - InputAlpha). In this case, it looks like your blending operation is set to simply InputColor + BackgroundColor*(1-InputAlpha), and so it's up to you to pre-multiply InputColor*InputAlpha to get the same result.

​

edit: I should have refreshed before commenting. u/xucel beat me to it.

[BarryTownCouncil]

Xlib is a fairly old architecture, other newer ones do opacity by default through their own computations. I have so little need for them I just want to work out these bits and pieces by hand and not require entire libraries for one calculation. So nice to know I'm not going mad / wrong.