On Thursday 13 October 2005 02:58 pm, Andrea Gavana wrote: > # that is the old colour --> GREY > rgb_old = (0.7, 0.7, 0.7) > > So, no matter what colour I choose as a "new" colour, the Hue part of the new colour doesn't change in RGB. In other words, leaving the old value for "Saturation" and "Value" makes the presence of the "Hue" part useless. But why in the world does this happen? If a colour is defined by 3 values, changes in every single value should change the colour too...
Turns out this is a bad example for the HSV transformation. The saturation of pure grey is 0, and the hue is undefined (which means it probably takes a default value, or is left wherever you set it -- it has no effect). So what happens is that an HSV hue change leaves pure grays untouched. The RGB to HSV coordinate transform is going from a 3D cartesian system to a *cylindrical* coordinate system, where the long axis of the cylinder is "value", the radius is "saturation", and the angle is "hue". your neutral gray is going to be about 0.7 up the "value" axis, but with no saturation, the hue makes no difference in the outcome. The transformation I suggested was rotating the HSV system about the axis, by substituting the hue. So, if you had, for example, a bright red, you'd get a bright blue, instead (because we got the hue from "process blue" / rgb=(0,0,1)). But gray stays gray. > Ah, thanks God for the existence of RGB ;-) Well, it may be that the hue transform just isn't what you're looking for. We could also preserve only the value, forcing saturation to 1 and hue to the specified hue: >>> hsv_new = (hue_tgt, 1.0, hsv_old[2]) >>> rgb_new = hsv_to_rgb(*hsv_new) >>> rgb_new (0.0, 0.0, 0.69999999999999996) (You might get a more aesthetically pleasing outcome with a less pure color, by setting the saturation lower). Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com -- http://mail.python.org/mailman/listinfo/python-list
