colour lib needs reviewers

[Manu via Digitalmars-d]

On 13 September 2016 at 00:37, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 09/12/2016 12:14 AM, Manu via Digitalmars-d wrote:
>>
>> I think I'm about as happy with my colour lib as I'm going to be.
>> It really needs reviews.
>
>
> Upon a quick look it seems to have the right amount of "notes", as Emperor
> Joseph II would say. Well balanced, nothing jumping at you. Nice work.

Thanks. It has taken a lot more work than I actually expected to make
this not suck!

> Regarding Phobos suitability: One thing I'd like to hear from the community
> is the applicability of this work. I know very little about colors (only the
> RGB was familiar from HTML etc, but then there was no YUL), but that doesn't
> mean much. The library is quite isolated from the rest of Phobos, e.g. a
> stronger case would be made if there were some std.experimental.canvas
> package which uses the color package. Or at least a
> std.experimental.terminal package or something. A good case for inclusion
> would motivate the presence of the library as a catalyst for many user-level
> abstractions. -- Andrei

So, the main reason I wanted to push for this in phobos is because
it's an enabler.
There is no multimedia in phobos at all. I think that's a shame, and
this is a starting point. Any conceivable image based work depends on
this as foundation. If pixel format types are phobos-supplied, then D
image libraries will naturally be compatible, as opposed to naturally
incompatible since every image library will otherwise re-implement
their own colour types (and almost always incorrectly).
The thing about colours is, they're HARD to get right, but more
importantly, most programmers have no idea that it's actually a hard
problem and won't tend to go looking for a lib for a colour type (Ie,
struct { ubyte r, g, b;}... simple! *cough*). They probably will use
it if it's in phobos though for compatibility reasons.
Image processing is super easy by contrast.

One of my first port-of-calls after this work would be a graph/plot
library... I'd use the hell out of that. I constantly want to output
data visualisations!

It also enables seamless interaction with realtime rendering api's.
Ie, if OpenGL/D3D/Vulkan bindings support phobos supplied colour
types, then image decoding libraries, and other sources of image data
become easy to render without any requirement for adaptation.
Rendering libs and image/video data source libs are almost always
separate, independent libraries. We need to maximise probability that
they are compatible out of the gate.

I didn't want to touch 'images' in this work, because there are
countless subjective designs to present those API's, but I don't think
there's many competing designs for a colour library, so it felt it was
the best and most bang-for-buck starting place overall.

Also, I think this has very high synergy with ndslice. I think ndslice
+  color is the foundation for image processing, or at least image
data transport.