colour lib needs reviewers

[Manu via Digitalmars-d]

On 14 September 2016 at 04:34, Marco Leise via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> Am Tue, 13 Sep 2016 12:00:44 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:
>
>> 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 mean RGBX. JavaScript's canvas works that way for
> example. I.e. the only pixel format is RGBA for simplicity's
> sake and I'm not surprised it actually draws something if I
> load it with a 24-bit graphic. ;)

Given this example, isn't it the job of the image loader to populate
the image with data?
If you ask for an RGBA image loaded from a 24bit BMP or something,
sure, it should put 0xFF in there, but I don't know if it's right that
that logic belongs here...?

>> > […] 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.
>
> I agree with that decision, and that it entails that
> arithmetics are undefined for alpha channels. :-( Yeah bummer.
> The idea that basic (saturating) arithmetics work on colors is
> a great simplification that works for the most part, but let's
> be fair, multiplying two HSV colors isn't exactly going to
> yield a well defined hue either,

You'll notice I didn't add arithmetic operators to the HSx type ;)
If you have HSx colors,  and want to do arithmetic, cast it to RGB first.


> just as multiplying two
> angles doesn't give you a new angle. I.e.:
> http://math.stackexchange.com/a/47880

I went through a brief phase where I thought about adding an angle
type (beside normint), but I felt it was overkill.
I still wonder if it's the right thing to do though... some type that
understands a circle, and making angle arithmetic work as expected.
I like my solution of not providing arithmetic operators for HSx and
LCh for now though ;)


>> > […]
>> […]
>> From which functions? Link me?
>> I'd love to see more precedents.
>
> Yep, that's better than arguing :)
> So here are all graphics APIs I know and what they do when
> they encounter colors without alpha and need a default value:
>
> SDL:
> https://wiki.libsdl.org/SDL_MapRGB
> "If the specified pixel format has an alpha component it will be returned as all 1 bits (fully opaque)."
>
> Allegro:
> https://github.com/liballeg/allegro5/blob/master/include/allegro5/internal/aintern_pixels.h#L59
> (No docs, just source code that defaults to 255 for alpha when
> converting a color from a bitmap with non-alpha pixel format
> to an ALLEGRO_COLOR.)
>
> Cairo:
> https://www.cairographics.org/manual/cairo-cairo-t.html#cairo-set-source-rgb
> "Sets the source pattern within cr to an opaque color."
>
> Microsoft GDI+:
> https://msdn.microsoft.com/de-de/library/windows/desktop/ms536255%28v=vs.85%29.aspx
> "The default value of the alpha component for this Color
> object is 255."
>
> Gnome GDK:
> https://developer.gnome.org/gdk-pixbuf/2.33/gdk-pixbuf-Utilities.html#gdk-pixbuf-add-alpha
> "[…] the alpha channel is initialized to 255 (full opacity)."
>
> Qt:
> http://doc.qt.io/qt-4.8/qcolor.html#alpha-blended-drawing
> "By default, the alpha-channel is set to 255 (opaque)."
>
> OpenGL:
> https://www.opengl.org/sdk/docs/man2/xhtml/glColor.xml
> "glColor3 variants specify new red, green, and blue values
> explicitly and set the current alpha value to 1.0 (full
> intensity) implicitly."
> (Note: The color can be queried and shows a=1.0 without
> blending operations setting it internally if needed.)
>
> Java (AWT):
> https://docs.oracle.com/javase/7/docs/api/java/awt/Color.html#Color%28int,%20boolean%29
> "If the hasalpha argument is false, alpha is defaulted to 255."
>
> Apple's Quartz does not seem to provide color space
> conversions and always requires the user to give the alpha
> value for new colors, so there is no default:
> https://developer.apple.com/library/tvos/documentation/GraphicsImaging/Reference/CGColor/index.html#//apple_ref/c/func/CGColorCreate

Touche! ;)


> One thing I noticed is that many of those strictly separate
> color spaces from alpha as concepts. For example in Quartz
> *all* color spaces have alpha. In Allegro color space
> conversions are ignorant of alpha. That begs the question
> what should happen when you convert RGBA to a HLx
> color space and back to RGBA. Can you retain the alpha value?
> CSS3 for example has HSLA colors that raise the bar a bit.

I've actually had the thought that I should remove alpha from RGB, and
instead provide an aggregate colour type where you could make RGBA by
RGB +  alpha, and each element in the aggregate would follow its own
natural arithmetic rules... again, it feels like massive overkill
though, and RGBA 8 is just way simpler for the 99% case.

That aggregate thing can appear, or be added in the future, or by
users. The library and conversions are all extensible.