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