On Sat, Jul 4, 2009 at 9:18 PM, Andrew
Coppin
2. It's mind-blowingly complex.
Colour *is* complex. Which is why I'm so glad Russell O'Connor did all the hard work for me :)
Well, no, because now I'm going to have to spend a few hours trying to find out what CIE is before I can even use that library.
The sRGB function makes a Colour from RGB (actually sRGB, which is a "standardised" RGB -- basically RGB where the exact frequency and power of each channel is specified -- but you can pretend your monitor's RGB is sRGB.
So mappend gives you colour addition [with the perplexing comments about "gamut", presumably some kind of small mammal?]
The gamut of a device is the range of representable colours (a monitor's gamut looks something like a parabola with a flat base in XYZ space, whereas a printer's is much more complex and variable). This makes sense. If you double a monitor's brightest white, you don't get a colour twice as bright: you get the same colour.
but there's no subtraction? No multiplication? No linear blending?
affineCombo can do subtraction, again with the gamut warning. darken does scalar multiplication; it probably doesn't do componentwise multiplication, which doesn't make much sense if you're trying to work in a coordinate-independent setting, though I admit RGB-multiplication can be handy.
Heh, my colour library includes a custom floor implementation that talks to the GHC primops directly because calling floor is too slow...
[In case that sounds like idle talk, I had a program go from 10 seconds to less than 1 second just by using this function. There's a few tickets about it on the GHC Trac.]
Fair enough. Can your implementation not be turned into a patch? BTW, I'm also working on Haskell fractals. You might be interested in looking at my fractal package (though it's currently undocumented, and has no GUI). --Max