Am Tue, 13 Sep 2016 12:00:44 +1000 schrieb Manu via Digitalmars-d <[email protected]>:
> 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. ;) > > […] 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, just as multiplying two angles doesn't give you a new angle. I.e.: http://math.stackexchange.com/a/47880 > > […] > […] > 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 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. -- Marco
