colour lib

[Manu via Digitalmars-d]

On 31 August 2016 at 17:58, Andrea Fontana via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Wednesday, 31 August 2016 at 06:17:15 UTC, Manu wrote:
>>
>> On 31 August 2016 at 16:01, Chris Wright via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> The color models I'm aware of are HSV, HSL, RGB[A], CMYK, Lab, Pantone,
>>> and the Open Colour Standard.
>>
>>
>> I'll initially support, XYZ/xyY, RGB (which is a gigantic set), HSx, Lab,
>> Yuv.
>>
>>
>>> I'm not sure what common operations they have.
>>
>>
>> All colours can add, subtract, scale luminance.
>>
>>
>>> Perhaps you could provide a link to your existing library?
>>
>>
>> https://github.com/TurkeyMan/color
>
>
> I always think the perfect colour library should work using a superset of
> all colour spaces, for example cie xyz (is it a superset, isn't it?).
> isColour(T) then IMO should check if x,y,z properties exists (or toXYZ()
> method).

Yeah... that would be wickedly slow.


> In this way every algorithm like "blend" or anything else could be
> implemented just for xyz (and eventually specialized for other colours if we
> want to avoid conversion overhead).

Basically the whole point of colour spaces is to do blends in
different colour spaces. XYZ is not a great space for blending, xyY is
functionally identical for blending as RGB, except that you need to do
conversions on either side of the blend. RGB tend to be integer colour
spaces, whereas XYZ/xyY are necessarily float colour spaces, which
implies a lot of int<->float conversion, etc. RGB is not at all
perceptually uniform, which is why colour spaces like Lab were
invented; if you use Lab, then your intent is to blend in Lab. Same
story for HSx spaces, you use them when you want to blend with a
linear hue axis.


> In this way it become easy to do
> cross-colour operations (for example: apply a rgb mask over another color
> space) and to implement new or strange color spaces (that automagically will
> work with all "blend" & co.). To implement a new color spaces you just need
> to map it to xyz (that should represent all - and more - visible colours:
> rgb is a subset of visibile colours)

The meat of your idea is already implemented in my code there. The way
it works is that you define your own custom colour type, and then add
a 'sign post' member, ie, `alias ParentColour = XYZ!float;`, then you
need to implement convertColor() for MyCustomColour -> XYZ and
vice-versa. With that, your custom colour will be convertible to any
other colour format; using a basic path-finding search (using the sign
posts) it will find a path from any colour type to any other colour
type, and perform the series of conversions required to get there. XYZ
is a valid superset, so you can always rely on it as a centerpoint for
colour conversions... but this is for conversion, not blending, which
is the whole point of defining your own colour space.