|
![](/i/fill.gif) |
In article <390### [at] aetec ee>, Vahur Krouverk <vah### [at] aetec ee>
wrote:
> I'm currently implementing color space conversion for my shader patch.
> It includes conversion between rgb, xyz, xyY, hsv, hsl and yiq spaces.
> It seemed to be good idea to put this conversion function to color.c
> file (err, coloUr.c). Now I'm wondering, whether it is good idea to
> make those conversion functions available from POV-Ray as well? Is there
> any use for them? One thing, that comes to my mind, is post-processing:
> with conversion from rgb to hsl (or hsv) it would be easy to add or
> reduce saturation, or change hue.
I have been wondering about making these conversion functions for a long
time, the only thing stopping me is a complete lack of knowledge of
these color spaces and converting between them. I have also been
thinking a post_process filter which does this would be useful.
> If this is good idea, then how should it be implemented? As functions?
> Which form would be preferable:
> rgb2hsv(COLOUR) or
> COLOUR rgb2hsv(COLOUR)?
I would definitely choose the second syntax, the first would only cause
trouble. The function should take and return a color.(I used a vector
function for eval_pigment(), so it doesn't return an actual color. That
means it loses filter and transmit, but I didn't know how to add a new
class of functions which returns a color.)
The post_process versions wouldn't require any parameters.
A somewhat similar set of functions would be functions for conversion
between cartesian, cylinderical, and spherical coordinates.
--
Christopher James Huff - Personal e-mail: chr### [at] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |