Hue Shift

Ok. The HSV formula for transferring RGB triplet into the HSV form is widely published. But I've failed to find any hints to how one arrives at it, so I could try to optimize it for my game's blitter routine. Therefore I tried to infer h,s,v formula myself, using basic vector math.

v = (r+g+b)/3 //value
hs = v-r,v-g,v-b //hue*saturation vector
s = hs.length //saturation
h = angle(hs/s) //hue is the angle of the vector

Guess when one needs to just change the saturation, there is no reason compute the angle or even vector length in full, but the common requirement to change the hue requires nasty computation. Can anyone hint at any efficient way of shifting hue?

Update to: http://lj.rossia.org/users/sadkov/467130.html

Checked my sqrt against the log2 based sqrt, using clang's __builtin_clz (which should expand to single assembly opcode), and the library's sqrtf, called using (int)sqrtf((float)i):
#define CLZ(x) __builtin_clz(x)
uint32_t clz_sqrt(uint32_t value) {
if (!value) return 0;
uint32_t xn = 1 << ((32 - CLZ(value))/2);
xn = (xn + value/xn)/2;
xn = (xn + value/xn)/2;
xn = (xn + value/xn)/2;
return xn;
}


got rather strange results:
$ gcc -O3 test.c -o test && ./test
isqrt16: 6.498955
sqrtf: 6.981861
log2_sqrt: 61.755873


Clang provided CPU based sqrtss, which is nearly as fast as my one. Lesson learned: on x86 compiler can provide fast enough sqrt, which is less than %10 slower than what you can come with up yourself, wasting a lot of time, or can be 10 times faster, if you use some ugly bitwise hacks. And still sqrtss is a bit slower than custom function, so if you really need these 5%, you can get them. Yet ARM for example has no sqrtss, so log2_sqrt shouldn't lag that bad.