std.experimental.color, request reviews

[Manu via Digitalmars-d]

On 24 June 2015 at 20:11, Guillaume Chatelet via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Tuesday, 23 June 2015 at 14:58:35 UTC, Manu wrote:
>>
>> https://github.com/D-Programming-Language/phobos/pull/2845
>>
>> I'm getting quite happy with it.
>> I think it's a good and fairly minimal but useful starting point.
>>
>> It'd be great to get some reviews from here.
>
>
> My experience (my previous job involved designing a GPU based color grading
> machine) is that the more you study colors, the more you realize how rich
> this domain is.

Indeed, it's a very deep hole ;)
This is a library that could easily suffer literally endless feature
creep, I just want to keep it reasonable and practical to start with.

I've done CG for a decade or so, and some research related colour
activity (satelite,medical,thermal imagery; my current job)


> To me there are different features corresponding to different domains :
> - spectral/multispectral colors (Satellite imagery, Medical imagery,
> Spectrometry), also useful for monitor calibration.
> - vfx industry will want
>  - sRGB, Adobe RGB with non linear gradation law (piecewise linear+gamma for
> sRGB)

Check, done.

>  - camera colorspaces (Alexa, PanaLog, Gamma)

I don't think this will come up in the near term.

>  - film colorspaces (density encoded, cineon / kodak log)

Likewise.

>  - broadcast colorspaces YUV, YCbCr, YPbPr, DCI P3

On the short-list.

>  - physical color space XYZ (CGI rendering)

Done.

> - print industry will want CMYK

This requires ICC interaction. There's OS involvement there.
It's a fair way down the list.

> - game industry will want alpha support with or without premultiplication,

I don't think pre-multiplied alpha is a detail that the colour itself
really needs to know about.
I thought about this, but I think it's a niche and unnecessary
complexity. Read; over-engineering.

> HSL

Easy, on the short list.

> - academic will want perceptual colorspace (Lab, L*a*b*), distance expresses
> how different colors are perceived.

On the short-ish list. This requires quite a lot of care, and it takes
time to get it just right.

> ...

I'm aware of all the points on your list. They aren't being overlooked.


> So to me there are several things to consider :
> - the number of channels, their semantics, the type they use (8/10/16/32/64
> bits, int, unsigned, float...)
> - some format packs channels, most common form of DPX is RGB10A2 bits packed
> in a 32 bit word (10bits red, 10bits green, 10 bits blue, 2 bits alpha) the
> word might be little/bigendian

Check. My background is realtime rendering ;)
I know what I'm doing here.

> - the gradation law for those channels (linear, sRGB, log, semilog, lookup
> table, ...)

All present or planned.

> - alpha is a special beast when composing colors

The colour type itself can't reasonably make any useful decision for
the user here, this is related to the functions that combine colours.

> - when the signal is captured/displayed the gamut comes into play (space of
> colors the device can handle) the color value can be correlated with the
> characteristics of the light : white balance, signal quantification, white
> point, black point, channel characteristics (spectrum)

On the mid-range-list. Chromatic adaptation is necessary for Lab at least.
This is mostly ancillary functionality though, it lives beside the
present offering.

> - moving between colorspaces is not necessary reversible (HSL <-> RGB). It
> involves non trivial logic (1D LUT, 3D LUT, matrix, piecewise functions,
> log/pow) that also makes the transformation lossy.

Yup. Can only do the best possible for each conversion. People making
use of those colour spaces and performing such conversions understand
these details.


> Manu, I understand that you don't want this library to handle very possible
> cases what is your rationale for what's useful / not necessary ? I suppose
> most users will simply manipulate sRGB jpeg/png.

Nothing is off the table. I start with RGB, since it's the 99% case.
That leads to XYZ for RGB conversions, and HSV is also very easy from
there. I had planned for that to be the initial offering.
I have made a start on Y'UV, Lab, and the compressed colour formats
typical in realtime gfx.
Advanced features are best driven by demand. There's no point
supporting scientific colour analysis if there's nobody to use it,
while a video professional sits waiting for broadcast related stuff...

I think the overwhelming use will be for loading+displaying images,
and rendering using opengl/dx/whatever.
Therefore, sRGB with all gamma conventions supported. Other RGB colour
spaces are easy from there; just definitions in a table (done, but
need tests).
PackedRGB is next (numerous requests already), then probably HSV.
After that, it's open to request. I'd like to work on some HDR related tools.

I can see a pretty clear distinction between what's *necessary* in a
standard colour library (ie, to facilitate other libraries), and
'would be nice' for niche or expert use :)
Don't worry, I'm an optics nerd!