[GEM-dev] Why is [hsv2rgb] implemented as an abstraction?

[Mathieu Bouchard]

On Tue, 11 Dec 2007, Chris McCormick wrote:

> As the resident abstractions-over-externals obsessive, I feel I should 
> put forward an argument to the contrary, just for good measure. 
> Basically it goes like this: CPU is getting cheaper, but programmer time 
> is getting more expensive (or put a different way; i'd rather make the 
> computer do work than myself do work).

The code for this is many years old and is small. The task to do does not 
change and the exact formulas are set. This is not the context in which 
one thinks about "programmer time getting more expensive".

> My implication is that editing an abstraction is easier than editing & 
> compiling an external, which could well be wrong, but there it is.

But why would you need to edit it?

But back to a more basic question: why do you want to use HSV ? it's that 
kind of weird hexagonal-pyramidal colourspace and that's one of the 
reasons why it's slower to process: you need to compute several "if" to 
get any value converted, and on modern processors, "if" is harder to 
optimise than anything else. But those same "if"s have other consequences: 
it makes the conversion formula bigger and somewhat harder to combine with 
other formulas. It's definitely not linear and not super close to any 
linear system.

if you do a polar transform on YUV, you have something easier, faster and 
more correct all at once. I usually just skip the polar transform: if you 
apply rotations directly on YUV values, you can make very believable hue 
shifts.

HSV is dubious in part because the apparent brightness at maximum 
so-called value is very variable and seems to peak high or low at 
secondaries or primaries: compare yellow (brightness 89%) and blue 
(brightness 11%). this really makes HSV suck sometimes. YUV does not have 
this problem.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada