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
