Phobos colour module?

[via Digitalmars-d]

On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d 
wrote:
> 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...

If you create a "pixel" converter that aims for speed, the 
programmer might also want it to generate a shader (as text 
string) with exactly the same properties.  It makes less and less 
sense to create a performant imaging library that is CPU only.

I suggest reducing the scope to:

1. Provide generic accurate conversion and iterators for colours 
(or more general; for arrays of spectral values). Useful for 
doing batch like stuff or initialization.

2. Provide fast colour support for transforms that are simple 
enough to not warrant GPU processing, but where you accept the 
cost of building lookup tables before processing. (Build tables 
using (1).)

> 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 think a precise reference implementation using double is a good 
start. People creating PDFs, SVGs or some other app that does not 
have real time requirements probably want that. It is also useful 
for building LUTs.

One thing to consider is that you also might want to handle 
colour compontents that have negative values or values larger 
than 1.0:

-  it is useful in non-realistic rendering as "darklights" ( 
http://www.glassner.com/wp-content/uploads/2014/04/Darklights.pdf 
)

- with negative values you can then have a unique representation 
of a single colour in CIE (the theoretical base for RGB that was 
developed in the 1930s).

- it allows the programmer to do his own gamut compression after 
conversion