In article <chrishuff-AE6B1C.09490803112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> I will send you the code as soon as it is tested.

I've found a couple more bugs, for example, Insert_Spline_Entry() took a 
vector and tried to pass 5 float values through it. I changed that to an 
expression... However, it might be a good idea to have separate 
Insert_Spline_Vector_Entry() and maybe Insert_Spline_Float_Entry() 
functions for ease of use in other code.
I also cleaned up a lot of the code, mostly just reformatting it, but 
partly rewriting some functions. And I fixed some typos in the 
comments...:-)
I plan on doing more, but I thought you would like to have what I have 
done so far. I hope this is helpful in the work you are doing.
The spline code changes are here:
http://homepage.mac.com/chrishuff/mpovplus/splines.zip

I will upload the curves post_process patch soon.

-- 
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

Mark Wagner wrote:
> 
> Chris Huff wrote in message ...
> >In article <3a03ab54$1@news.povray.org>, "Mark Wagner"
> ><mar### [at] gtenet> wrote:
> >
> >(got a better name for the last one? "all"?)
> 
> "all" makes more sense than "grey".
> 
	I think it depends on what the spline does exactly: is it the same as:
rgb SPLINE, SPLINE, SPLINE

	Or does it only change the brightness? A good thing to add too:
spline-based manipulations on hue and saturation...


-- 

* Abandon the search for truth, * mailto:ber### [at] inamecom
* Settle for a good fantasy.    * http://www.enst.fr/~jberger
*********************************

Post a reply to this message

<Jer### [at] enstfr> wrote:

> > "all" makes more sense than "grey".
> 	I think it depends on what the spline does exactly: is it the same as:
> rgb SPLINE, SPLINE, SPLINE
> 	Or does it only change the brightness?

It uses the same spline to adjust each channel. The current value of the 
channel is taken as the "t" value of the spline, and the result of the 
spline is used as the new value for the channel.


> A good thing to add too: spline-based manipulations on hue and 
> saturation...

Not as a special feature of the spline patch...just use a rgb_to_hsl 
filter, then use the ordinary curves filter to adjust hue or saturation, 
then use hsl_to_rgb to get the corrected image back. More flexible, less 
complicated, and you can combine it with other things to get special 
effects. And I *am* planning to write these conversion filters...as soon 
as I figure out the math. I've found lots of information about 
converting between color spaces, but little or nothing about the actual 
equations used to convert between rgb and hsl. That, or I'm just not 
recognizing it when I see 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

In article <chrishuff-2DD880.12353405112000@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> ...as soon as I figure out the math. I've found lots of information 
> about converting between color spaces, but little or nothing about 
> the actual equations used to convert between rgb and hsl. That, or 
> I'm just not recognizing it when I see it...

Never mind, I just came across a couple files Nathan sent me which 
should do everything that I need. I had set them aside and completely 
forgotten about them...

-- 
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

Chris Huff wrote in message ...
>In article <3a04ed21@news.povray.org>, "Mark Wagner"
><mar### [at] gtenet> wrote:
>> The limit is 256 points -- enough for most uses, but why have a limit
>> when there doesn't need to be one?
>
>It looks to me like that was just a stopgap measure...it looks like you
>could implement it mostly by adding code to the Insert_Spline_Entry()
>function.
>I don't have any experience with growing dynamically allocated
>arrays...I tend to use linked lists for everything.


I've already got the code for this written -- it's just a matter of copying
it from my personal version to SkyPOV.

>> >Also, it would be useful if you could access the control points, with
>> >functions that behave similar to the array functions and an array-like
>> >syntax.
>> This might be very difficult to implement -- there are enough
>> problems with the spline syntax as it is.
>
>I think could get it working with functions, but I have no idea how to
>do the array like syntax...
>INT spline_points(SPLINE_IDENT) Retrieves the number of points in the
>spline.
>EXPRESS get_spline_point(INT_INDEX) Returns the corresponding point on
>the spline.


I think that, usage-wise, it would be better to use the array syntax.  This
would allow points to be changed and read using a single syntax.

>BTW, I implemented the SPLINE_IDENT(T, TYPE) syntax. You can now do
>something like this:
>#declare Spl = spline {linear_spline ...}
>
>#declare Val1 = Spl(T);
>#declare Val2 = Spl(T, cubic_spline);
>#declare Val3 = Spl(T, quadratic_spline);
>
>I will send you the code soon.


Thanks!

Post a reply to this message

Chris Huff wrote in message ...
> Anyway, this is the syntax I am planning to use(I am currently working
> on the first form):

don't you like pov schema for color definition ?

> curves {rgb RED_SPLINE, GREEN_SPLINE, BLUE_SPLINE}

curves {red RED_SPLINE green GREEN_SPLINE blue BLUE_SPLINE}

> curves {red RED_SPLINE}
> curves {green GREEN_SPLINE}
> curves {blue BLUE_SPLINE}

ok.

> curves {gray GRAY_SPLINE}
> (got a better name for the last one? "all"?)


curves {rgb GRAY_SPLINE}

ABX

Post a reply to this message

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

> Chris Huff wrote in message ...
> > Anyway, this is the syntax I am planning to use(I am currently working
> > on the first form):
> 
> don't you like pov schema for color definition ?

Uh, POV doesn't let you specify colors with splines. And you don't 
specify colors in the curves patch, it simply reuses the keywords as 
names for color channels.

Some of those would be pretty easy to do, but they would just be 
confusing...since you are not specifying a color. Would you like it 
better if it required the "type" keyword before the type?
And anyway, the syntax I use is better suited for expansion to other 
color spaces. I plan to allow other color spaces to be manipulated by 
adding a filter to convert to those spaces, but a future version of the 
curves patch may allow a shortcut for modifying those spaces. Your 
syntax will cause confusion("I can modify red and green at the same 
time, but not blue and saturation?").

-- 
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

Chris Huff wrote in message ...
>Uh, POV doesn't let you specify colors with splines.

yes, I know
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}}

therefore I thought about similiar syntax
this also allow extension to other color spaces I think

>And anyway, the syntax I use is better suited for expansion to other
>color spaces.

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

>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 :-)

ABX

Post a reply to this message

In article <3a06459f$1@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> >I don't have any experience with growing dynamically allocated
> >arrays...I tend to use linked lists for everything.
> I've already got the code for this written -- it's just a matter of 
> copying it from my personal version to SkyPOV.

:-)


> I think that, usage-wise, it would be better to use the array syntax. 
>  This would allow points to be changed and read using a single 
> syntax.

Arrays don't have any special syntax for insertion...and I don't think 
reading the points with [] brackets will be very easy. As for changing 
existing points...what would this do?
#declare Spl[2] = 0.4;

Would this set the t value of the third point to 0.4, or would it set 
the x value? Also, this syntax would be a problem for using arrays of 
splines.

I would suggest using functions for most of these:

Getting number of control points:
INT spline_points(SPLINE_IDENT)

Reading a point:
FLOAT get_spline_t(SPLINE_IDENT, INDEX)
Returns the "distance" of the point at INDEX.

EXPRESS get_spline_value(SPLINE_IDENT, INDEX)
Returns the value of the spline at INDEX. I'm not sure how to handle 
floats, vectors, and colors...maybe this function will work for all of 
them.

Modifying a point:
set_spline_t(SPLINE_IDENT, INT_INDEX, FLOAT_NEW_T)
Changes the "distance" of the point at INDEX.

set_spline_value(SPLINE_IDENT, INT_INDEX, EXPRESS_VALUE)
Changes the value of the spline at INDEX. You can specify a float, 
vector, color...

Adding a point should be possible already, it should work fine with the 
modifications I made(mainly the fix to Copy_Spline()). Just do something 
like this:
#declare Spline = spline {Spline NEW_POINTS}

And one other thing that should probably be taken care of: multiple 
points with the same t value should probably not be allowed. New points 
with the same t value of an existing point should replace that point. I 
don't remember seeing anything about this in the source code...

-- 
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

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