Phobos colour module?

[Manu via Digitalmars-d]

On 7 January 2015 at 00:28, Manu <turkeyman at gmail.com> wrote:
> On 6 January 2015 at 19:31, via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote:
>>>
>>> What's wrong with old-fashioned `Fast` postfixes on entry points where a
>>> faster but less precise method is available? Or template arguments like
>>> std.algorithm.SortStrategy?
>>
>>
>> If this is for phobos it should follow a common model. But since a fast
>> implementation might involve an object which builds a table before
>> processing....
>>
>> Another problem is that "precise" is a very loose term if the conversion is
>> for display or for composition in a shader. What you want depends on the
>> kind of post processing that happens after this and how it affects the
>> nonlinearities of human perception.
>
> I think an important facet of 'fast' image processing is in the loop
> that processes batches of pixels, rather than in the api that
> processes a single pixel.
> I've gone with accurate; that's the strategy throughout phobos.
>
> I can't create look-up-tables at the moment, since '^^' doesn't work
> in CTFE! >_<
>
> Here's a PR to see where I'm at:
> https://github.com/D-Programming-Language/phobos/pull/2845

I'd like to get some ideas from people what basic colour operations
people would like/expect to see.

I'm also pondering which operators should be supported.
Do people think it makes any sense to support unary -? They're only
really useful in cases like normal maps, and don't make sense on
unsigned+normalised colour types.
What about unary ~? Bitwise not doesn't really have any meaning in
terms of colour, but it might make sense for the operator to calculate
the negative colour... although that kinda feels like operator abuse
to me.

What should happen when operators are applied to colours of differing
colour space? I kinda feel like denying operators on colour space
mismatch. It's not clear which format (left/right hand side) should be
the preferred format for the operation/result...

I'm also questioning whether implicit assignment colour conversion
should be allowed (and this kinda relates to restricting operators to
like-types. Alternatively I can limit conversion to explicit cast
operator or to!.

What about scalar operators, ie, to scale a colour? should the scalar
argument be expected to match the datatype, or support float against
all types for scaling? (slow! int->float->int conversion for a basic
mul!)

What details have I missed?