FIX: issue #2812 (image: alpha channel not correctly displayed)

[qtxie]

This PR changes the meaning of the alpha channel in color tuple.
R.G.B.A where A = 255 indicates full opacity and A = 0 full transparency.

Note: This change breaks the compatibility with Rebol.

[hiiamboris]

This is what I'm thinking.
If we make 255.255.255 equal to 255.255.255.255, that would break tuple arithmetic rules. So all 3-tuples after this PR will become transparent colors (255.0.0 = 255.0.0.0 = transparent). Which is not useful.
All opaque colors will have to become 4-tuples. And we'll have to add extra .255 to all colors we manually define in the code, and all predefined colors will have to be updated as well. Which is boring.

Perhaps this PR will do more harm than good, and it answers the design question: why Rebol has chosen a RGBT convention instead of RGBO.

[qtxie]

So all 3-tuples after this PR will become transparent colors.

Nope. How to interpret the tuple value is controlled by the applications. In view, view [base 255.0.0] is still opaque red color. In image!, when you use 3-tuples, you only set R.G.B channels, nothing to do with alpha channel.

why Rebol has chosen a RGBT convention instead of RGBO

I think just because the image library which Rebol used use this format.

[hiiamboris]

Okay but this problem still remains:

>> 255.255.255 = 255.255.255.0
== true
>> 255.255.255 = 255.255.255.255
== false

So when testing for a color equality one would have to trim the tuple length accordingly, e.g.

>> 255.255.255 = (255.255.255.255 * 1.1.1)
== true

Something we should note somewhere then.

[greggirwin]

Absolutely something to note in tuple docs, as they ignore trailing zeros when comparing.

>> 255.255.255 = 255.255.255.0.0.0.0
== true

In the context of colors, we have to think (and I haven't yet) about whether opacity is a component of a "color". It isn't, intuitively to me, but a related value for pixels in images.

[hiiamboris]

Related #2684