In article <3a06b03e@news.povray.org>, "Wlodzimierz ABX Skiba" 
<abx### [at] abxartpl> wrote:

> but this could be useful - color curves like color_map
> 
> #declare Curve=curve{red Spline1 green Spline2 filter Spline3}
> #declare Pigment=pigment{pattern color_map{curve Curve}}

I have been thinking the possibility of something like this...I think it 
might be useful. But I don't think it applies to the curves patch...


> this also allow extension to other color spaces I think

No, it won't. See explanation below.


> but you put sign "=" between meaning of "all" and "gray"
> is it true in other color spaces ?

The "=" operator isn't used in this patch...I don't know what you mean.


> >Your
> >syntax will cause confusion("I can modify red and green at the same
> >time, but not blue and saturation?").
> it depends of implementation in your planned patch :-)

No, it doesn't. For example, you can't manipulate red and hue 
simultaneously, you can only manipulate one color space at a time. This 
is because saturation and hue affect red, green, and blue, and the same 
goes for the reverse. My syntax will allow the addition of hsl, hue and 
saturation modes, yours won't, at least not in a way that makes sense. 
However, those shouldn't be necessary anyway, since you can just use 
other conversion filters before and after the curves filter to get the 
same result. So we are back to whether or not to use the color syntax 
for splines.

What exactly is deficient in the syntax I chose? Why do you think 
specifying splines representing color channel curves with a color-like 
syntax is a better idea than specifying a channel and a spline to go 
with it?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message