colour lib needs reviewers

[Guillaume Chatelet via Digitalmars-d]

On Monday, 12 September 2016 at 15:06:29 UTC, Manu wrote:
> On 13 September 2016 at 00:37, Andrei Alexandrescu via
>> 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.

+1

It's simply amazing how the concept of color is well understood 
by everyone and yet utterly hard to understand in the details.

Color is a Universe in itself! Just have a look at Metamerism(1) 
(colors that look the same but aren't), Human Tetrachromacy(2) 
(some people - mostly women - perceive more colors than others). 
I'm not even scratching the surface: it connects with everything: 
Physics, Physiology, Art, Entertainement, Evolution(3)...

Having a high quality Color API in Phobos is a differentiator and 
an enabler: think Raytracer, image batch processing, scientific 
analysis, interactions with GUI or rendering APIs.
I think it's an important addition to Phobos - I might be biased 
though :-P

1. https://en.wikipedia.org/wiki/Metamerism_(color)
2. https://en.wikipedia.org/wiki/Tetrachromacy#Humans
3. https://www.youtube.com/watch?v=qrKZBh8BL_U