colour lib

[Andrea Fontana via Digitalmars-d]

On Wednesday, 31 August 2016 at 09:33:24 UTC, Manu wrote:
> 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.

So maybe I miss (more than) something reading source code. You 
should write a readme to explain how it works :)