colour lib needs reviewers

[Manu via Digitalmars-d]

On 13 September 2016 at 07:00, Marco Leise via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Am Tue, 13 Sep 2016 00:37:22 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:
>> I flip-flopped on this multiple times.
>> It's not so simple.
>> 1. Alpha doesn't necessarily mean transparently, that's just one
>> (extremely common) use
>> 2. 1 is the multiplication identity, but 0 is the additive identity. I
>> cant find either addition or multiplication to take precedence over
>> eachother.
>> 3. With those 2 points above already making me feel a bit worried
>> about it, I think that appearing numbers out of nowhere is just
>> generally bad, so I went with a=0.
>
>> If alpha defaults to 1, then a*b works as expected (object does not
>> become transparent by this operation).
>> If alpha defaults to 0, then b-a works as expected (object does not
>> become transparent by this operation).
>
> Additive color components can work like that, but the alpha
> component just doesn't represent an amount of light. Don't try
> too hard to make the arithmetics make sense, when the
> practical use lies in 100% alpha by default.

I understand the argument, I have stressed over this to no end.
I still think it's just not 'right'. :/


> Converting every
> color to full transparent is not helpful when you want to save
> a 24-bit BMP as 32-bit PNG or get an RGBA color from an RGB
> texture.

What is the worth of storing alpha data if it's uniform 0xFF anyway?
It sounds like you mean rgbx, not rgba (ie, 32bit, but no alpha).
There should only be an alpha channel if there's actually alpha data... right?


> I don't know who declared that 100% alpha means opaque. For
> what it's worth it could have been the other way around and
> all the (1-a) and (a) in blending functions swapped.
> And a blending function is what is needed here to give any
> meaning at all to arithmetics on alpha. An additive one may be:
>
>   color = color_dst + color_src * alpha_src
>   alpha = alpha_dst

I thought about adding blend's, but I stopped short on that. I think
that's firmly entering image processing territory, and I felt that was
one step beyond the MO of this particular lib... no?
Blending opens up a whole world.


>> With that in mind, you realise alpha will *always* require explicit
>> handling... so I think 0 is a better default at that stage. It may be
>> possible to convince me otherwise ;)
>
> I fully agree with the first line, I just think that for
> practical uses alpha is considered to be 100% in pixel formats
> without alpha channel.

'rgbx' is for image formats without alpha channels...


> Otherwise the most popular blending
> functions would do nothing on RGB colors.

'rgbx' colors fed through a blend function would always properly imply alpha=1.


> SDL for example also uses 100% alpha by default: "If the
> specified pixel format has an alpha component it will be
> returned as all 1 bits (fully opaque)."

>From which functions? Link me?
I'd love to see more precedents.


>> > It seems inconsistent that you can specify all kinds of
>> > exponents when the exponent is shared but are forced to 5 bit
>> > exponents when mixed into each component, while the mantissa
>> > can still be adjusted. Would m7e3 have worked? (With f* being
>> > the IEEE standard formats.)
>>
>> I was thinking that, and mentioned as such in the comments near those lines ;)
>> Thing is, there are no realtime small floats with exponent != 5bits
>> except the unique 7e3 format on xbox 360.
>> I can extend this in an unbreaking way.
>> I might: f## =  ieee-like, s##e# = signed float, (u)##e# = unsgned float.
>> It's just pretty verbose is all: "rgb_11e5_11e5_10e5". I mean, it's
>> fine... but maybe people wouldn't find this intuitive? Many
>> programmers don't know what an 'exponent' or 'mantissa' is... :/
>
> Yeah I thought that the common formats would be the IEEE
> ones, especially f16 and that anything less are very niche
> custom formats that come and go and need verbose descriptions.
> Well, either way works.

The verbose idea I said above is my best idea. I'll roll with that if
enough people agree.
There was the other fellow who posted before who feels like it's
already too complicated for him though.

I've been very carefully trying to put the complicated bits just one
level back from arms reach, so a casual user isn't confronted with
those details.
Putting that complexity in the format string makes it very
user-facing. That's the part I'm not wild about.


>> > The final package should contain a fair amount of
>> > documentation, in my opinion also on the topics of sRGB vs.
>> > linear and what "hybrid gamma" is.
>>
>> Yeah, but is it really my job to teach someone about colour space?
>> Wikipedia can do that much better than I can... :/
>> I agree, but I don't really know where to draw the line, or how to organise it.
>>
>> Perhaps people with strong opinions on how this should be presented
>> can create a PR?
>
> Alright, but hybrid gamma is really not something that can be
> googled. Or rather I end up at Toyota's Gamma Hybrid product
> page. :D

True. I'm not even sure what the technical term for this sort of gamma
function is... I just made that up! :/
As Walter and others have asked, I'll have to start adding links to
reference material I guess, although that still feels really weird to
me for some reason.