Phobos colour module?

[Manu via Digitalmars-d]

On 6 January 2015 at 04:11, via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote:
>>
>> Yeah, in my misc repo, there used to be stand along image.d and
>> simpledisplay.d. Now, they both depend on color.d. Even just a basic
>> definition we can use elsewhere is nice to have so other libs can interop on
>> that level without annoying casts or pointless conversions just to please
>> the type system when the contents are identical.
>
>
> Yes, that too. I was more thinking about the ability to create an adapter
> that extracts colour information from an existing data structure and adds
> context information such as gamma. Then let  you build a function that say
> reads floats from 3 LAB pointers and finally returns a tuple with a 16 bit
> RGB pixel with gamma correction and the residue in a specified format
> suitable for dithering... ;-]
>
> It is quite common error to do computations on colours that are ignorant of
> gamma (or do it wrong) which results in less accurate imaging. E.g. When
> dithering you need to make sure that the residue that is left when doing bit
> truncation is added to the neighbouring pixels in a "linear addition"
> (without gamma). Making stuff like that less tedious would make it a very
> useful library.

I have thought about how to handle residue from lossy-encoding, but I
haven't thought of an API I like for that yet.
Dithering operates on neighbourhoods of pixels, so in some ways I feel
it is beyond the scope of colour.d, but residue is an important detail
to enable dithering that should probably be expressed while encoding.

Currently, I have a colour template which can be arbitrarily typed and
components defined in some user-specified order. It binds the
colourspace to colours. 'CTo to(CTo, CFrom)(CFrom colour)' is defined
and performs arbitrary conversions between colours.

I'm finding myself at a constant struggle between speed and
maximizing-precision. I feel like a lib should maximise precision, but
the trouble then is that it's not actually useful to me...
Very few applications care about colour precision beyond ubyte, so I
feel like using double for much of the processing is overkill :/
I'm not sure what the right balance would look like exactly.
I can make fast-paths for common formats, like ubyte conversions
between sRGB/Linear, etc use tables. Performing colourspace
conversions in fixed point (where both sides of conversion are integer
types) might be possible without significant loss of precision, but
it's tricky... I just pipe through double now, and that's way
overkill.

I'll make a PR tonight some time for criticism.