On 14 September 2016 at 04:34, Marco Leise via Digitalmars-d <[email protected]> wrote: > 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. ;)
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.
