Am Tue, 13 Sep 2016 12:00:44 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@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. ;)

> > […] 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

On Tuesday, 13 September 2016 at 02:00:44 UTC, Manu wrote:
> What is the worth of storing alpha data if it's uniform 0xFF anyway?

He he, that's the big problem with classic image formats. When a graphic is described in term of vector, fill, stroke, gradient, layer, etc (not to name SVG) there's no more waste.

On 14 September 2016 at 00:56, John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 13 September 2016 at 09:31:53 UTC, Manu wrote:
>>
>> On 13 September 2016 at 17:47, John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> On Tuesday, 13 September 2016 at 01:05:56 UTC, Manu wrote:
>>>>>
>>>>>
>>>>> Also can I swizzle channels directly?
>>>>
>>>>
>>>>
>>>> I could add something like:
>>>>   auto brg =  c.swizzle!"brg";
>>>>
>>>> The result would be strongly typed to the new arrangement.
>>>
>>>
>>>
>>> Perfect use-case for opDispatch like in gl3n.
>>
>>
>> One trouble with arbitrary swizzling is that people often want to
>> write expressions like "c.xyzy", or whatever, but repeating
>> components... and that's not something my colours can do. It's useful
>> in realtime code, but it doesn't mean anything, and you can't
>> interpret that value as a colour anymore after you do that.
>> This sort of thing is used when you're not actually storing colours in
>> textures, but instead just some arbitrary data. Don't use a colour
>> type for that, use a vector type instead.
>> What that sort of swizzling really is, are vector operations, not
>> colour operations. Maybe I could add an API to populate a vector from
>> the components of colours, in-order... but then we don't actually have
>> linear algebra functions in phobos either! So colour->vectors and
>> arbitrary swizzling is probably not something we need immediately.
>>
>> In my lib, colours are colours. If you have `BGR8 x` and `RGB8 y`, and add them, you don't get x.b+y.r, x.g+y.g, x.r+y.b... that's not a colour operation, that's an element-wise vector operation.
>
>
> Fair enough, you know much better than me how useful it would be. I was just suggesting that if you do support some sorts of swizzling then opDispatch would allow you to avoid users having to use strings. It would be as simple to implement as `alias opDispatch = swizzle;` given the swizzle function you were using before.

Oh, it would be super-useful! Just that it's not a colour operation, its liner algebra... I think it's a job for another lib. Getting a colour as a vector is all that's needed.

On 14 September 2016 at 04:34, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Tue, 13 Sep 2016 12:00:44 +1000
> schrieb Manu via Digitalmars-d <digitalmars-d@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.

On 14 September 2016 at 04:25, Random D user via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tuesday, 13 September 2016 at 02:00:44 UTC, Manu wrote:
>>
>> On 13 September 2016 at 07:00, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>>
>>> Am Tue, 13 Sep 2016 00:37:22 +1000
>>> schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:
>>> 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.
>
>
> FWIW I stumbled into this while double-checking HDR standards for my previous post. (I'm not a HDR expert, only somewhat interested because it's the future of displays/graphics)
>
> https://en.wikipedia.org/wiki/Hybrid_Log-Gamma

Perfect, thanks!

On 14 September 2016 at 04:10, Random D user via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
> In general, I think basics should be dead simple (even over simplified for
> the very basic case)

I think they are:

  import std.experimental.color;
  RGB8 color("red");

I don't think i's possible to make it simpler than that?


> but the API and the docs should provide me layers of
> increasing detail and sophistication, which I can study if (or when) I
> really need control and care about the details.

I'll work on the docs some more.


> Deprecated by who? Shouldn't phobos grade lib include all reasonable platforms?

They're all comprehensively supported, I just didn't pre-instantiate every possible format imaginable. That would be devastating to compile times, and have absolutely no value.

BGR really just exists because WINAPI. Microsoft haven't recommended
people write GDI based software for decades.
Look at DX10(,11,12), BGR isn't even supported in modern DirectX.
Microsoft left BGR to die years ago (and good riddance).
That said, there is an instantiation for BGR in package.d... the
reversed versions (ie, alpha first) are completely unusual; just some
big-endian games consoles.

Modern formats have the channels in order; RGB, this is true for all data types, ubyte, short, float, etc.


> I agree that you probably don't see too much variation within windows APIs, images (BMP etc.) or with D3D GPU textures (they're compressed anyway and asset pipelines to do the conversions beforehand), but I was more of thinking image libraries and the numerous, sometimes old and quirky, image formats. Or perhaps someone wants to implement a software blitter for their favorite toy device/embedded project.

"favorite toy device/embedded project" <- this is the definition of specialist task. I don't mind if that person has to type 'alias' at the top of their app.


>>> For 16 bits fairly common are:
>>> RGB565 and RGBA5551, also sometimes you see one of RGBA4444 permutations
>>> (like RGBA8 above).
>>
>>
>> Nobody uses 16bit textures anymore. Compressed textures are both MUCH smaller, and generally higher quality.
>
>
> Sure, agreed. These are not too useful as GPU textures these days (even on mobile), but if you do software 2d, load older image formats (image viewer etc.) or something even more specialized, these are pretty useful.
>
> I guess I was going for comprehensive (within reason), where as you were going for "90% of 2016 colors/image data", which is fine.

There is comprehensive support for all these formats... I just didn't
pre-instantiate the templates.
It's not hard to do at the top of your program:
  alias MyRGBType = RGB!(...details...);


> Anyways, it would be nice to see color (and hopefully image + simple
> blitter) in phobos.

I think that'll come. This is a pre-requisite.


> There's no need to write the same convert/copy/stretch/blend loop over and over again. And cpu-side code is nice to have for quick prototyping and small-scale work.

Sure.


>>> Just as a completely random idea - How about aliases for HDR formats like HDR10 and Dolby Vision? Kind of looks like they're just combinations what you already have.
>>
>>
>> This is very specialist. Instantiations are expensive. If they're not used, it's a waste of compiler effort.
>
>
> HDR TVs and displays are coming fast and with that I'm sure HDR editing and photography will be common, which of course means HDR color formats and apps. But these can be added later.

There is already support for HDR.
Use a floating point RGB with UHDTV colour space: alias HDR =
RGB!("rgb", float, linear(?), RGBColorSpace.UHDTV);
CompressedRGB also has comprehensive support for all the HDR formats
I've ever encountered.

My point was, I don't want to provide instantiations for these types... most people don't need it. People writing HDR rendering software will instantiate the types they need themselves. It's very specialist work.

Am Wed, 14 Sep 2016 11:36:12 +1000
schrieb Manu via Digitalmars-d <digitalmars-d@puremagic.com>:

> On 14 September 2016 at 04:34, Marco Leise via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> > 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?2
> […]

I admit is was a constructed example. You can't load an image directly into a HTML5 canvas. Shame on me.

> 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.

Now that you say it, yes I was wondering how the arithmetics
work since I couldn't find any opBinary.

> 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 see. I'm also wondering what equality means for a color with floating point hue 10° and another with hue 730°. I guess it is ok the way it is now, because wrapping the values doesn't guarantee they map to the same value either. Floating point equality is flawed either way.

-- 
Marco

On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote:
> I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews.
>
> I added packed-RGB support, including weird micro-float and
> shared-exponent formats.
> They're important for interacting with any real-time rendering libraries.
> There is only one texture format I'm aware of that isn't supported,
> and that is u7e3 floats, only available on Xbox360 ;)
>
> Chromatic adaptation functions are in.
> I've done a tidy/reorg pass.
>
> I'm not sure what else should be in the scope of this lib.
>
> PR: https://github.com/dlang/phobos/pull/2845
> dub: https://code.dlang.org/packages/color
> docs: http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html
>
> - Manu

Looks like a nice and simple module. My only complaint is that DDOC sections such as Returns, Args, etc. don't seem to be used at all. Also maybe a bit more detailed of an overview in package.d, which I assume is the entry point for the documentation.

On 14 September 2016 at 22:47, Meta via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote:
>>
>> I think I'm about as happy with my colour lib as I'm going to be. It really needs reviews.
>>
>> I added packed-RGB support, including weird micro-float and
>> shared-exponent formats.
>> They're important for interacting with any real-time rendering libraries.
>> There is only one texture format I'm aware of that isn't supported,
>> and that is u7e3 floats, only available on Xbox360 ;)
>>
>> Chromatic adaptation functions are in.
>> I've done a tidy/reorg pass.
>>
>> I'm not sure what else should be in the scope of this lib.
>>
>> PR: https://github.com/dlang/phobos/pull/2845
>> dub: https://code.dlang.org/packages/color
>> docs:
>> http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html
>>
>> - Manu
>
>
> Looks like a nice and simple module. My only complaint is that DDOC sections such as Returns, Args, etc. don't seem to be used at all. Also maybe a bit more detailed of an overview in package.d, which I assume is the entry point for the documentation.

Cheers.
Yeah, I need to do better with ddoc.

... I'm just gonna go on the record and say that I am really, really not enjoying ddoc ;)

If I could get people starting to review the code, I'll polish up the docs over the next few days.

On Wednesday, 14 September 2016 at 13:28:23 UTC, Manu wrote:
> Cheers.
> Yeah, I need to do better with ddoc.
>
> ... I'm just gonna go on the record and say that I am really, really not enjoying ddoc ;)

I can't say I'm a fan either.