gnuplot-beta — Developers and beta testers of new gnuplot code

None

[Petr M. <mi...@ph...>]

I propose to change the message

	Notice: cannot contour non grid data!

into

	Notice: Cannot contour non grid data. Please use "set dgrid3d".

Any objections?

---
PM

Re: ConTeXt terminal - any volunteers for testing?

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday 07 February 2007 23:36, Mojca Miklavec wrote:
> 
> Instructions for trying it out can be found on the site with a patch itself:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1654807&group_id=2055&atid=302055
> 
> One needs a reasonably recent TeX distribution. Now that TeXLive is
> available (for Debian as well), it should be more straightforward to
> try it out (half a year ago it wouldn't work on most TeX
> distributions, as it doesn't work with teTeX either).

My current distribution installs both teTeX and ConTeXt:
    tetex-context-3.0-18mdv2007.0

Are you saying that this won't work for testing?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

ConTeXt terminal - any volunteers for testing?

[Mojca M. <moj...@gm...>]

Hello,

I have uploaded a new version of ConTeXt terminal.

Here are some sample demos created with it:
    http://dl.contextgarden.net/misc/gnuplot-context.zip
and some real-world usage:
    http://www.nibua-r.org/ConTeXt/PhD/

Just for comparison, you can also take a look at this example:
    http://dl.contextgarden.net/misc/enhancedtext.pdf
    http://gnuplot.sourceforge.net/demo_4.3/enhancedtext.html

The terminal supports all the 4.2 features except images, palettes
(partially finished, but not yet complete) and enchanced text (the
latter is not going to be supported - see example above - since TeX
offers better rendering quality for free; images and palettes will be
completed in a later stage - TeX has problems passing huge portions of
code to metapost anyway).

Instructions for trying it out can be found on the site with a patch itself:
http://sourceforge.net/tracker/index.php?func=detail&aid=1654807&group_id=2055&atid=302055

One needs a reasonably recent TeX distribution. Now that TeXLive is
available (for Debian as well), it should be more straightforward to
try it out (half a year ago it wouldn't work on most TeX
distributions, as it doesn't work with teTeX either).

The terminal doesn't require any external libraries or special
configuration, so compiling it with the rest should be
straightforward.

Mojca

Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

On 2/7/07, Pierre <pie...@gm...> wrote:
> On 2/7/07, Ethan Merritt <merritt@u.washington.edu> wrote:
> > On Wednesday 07 February 2007 11:44, Hans-Bernhard Br=F6ker wrote:
> > > Pierre wrote:
> > >
> > > > I'm not sure to understand why it is biased. Each vertex color is
> > > > known. The first vertex is the top left one, after they have been
> > > > sorted.
> > >
> > > The bias lies in picking the top left vertex as "the first".
> > > This can cause nasty effects like: the same triangle comes out subtly
> > > different if the scene is rendered upside down or rotated by 90 degre=
ss,
> > > even though the result should be exactly the same.
> >
> > That is true, but the failure mode is usually harmless. If you rotate t=
he
> > triangle in 3D its coloring may change very slightly, but if it is a
> > single facet of a larger surface this will probably not be noticed sinc=
e
> > the adjacent triangles are similarly affected.
>
> I will add a custom version to test these cases using numerical
> results (output the edges values to a file and compare them). We can
> then see if the error is acceptable. As you say, I do not expect any
> noticeable differences.

By the way, any help is welcome. If someone volunteers to write these
tests, he will be more than welcome :)

--Pierre

Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

On 2/7/07, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Wednesday 07 February 2007 11:44, Hans-Bernhard Br=F6ker wrote:
> > Pierre wrote:
> >
> > > I'm not sure to understand why it is biased. Each vertex color is
> > > known. The first vertex is the top left one, after they have been
> > > sorted.
> >
> > The bias lies in picking the top left vertex as "the first".
> > This can cause nasty effects like: the same triangle comes out subtly
> > different if the scene is rendered upside down or rotated by 90 degress=
,
> > even though the result should be exactly the same.
>
> That is true, but the failure mode is usually harmless. If you rotate the
> triangle in 3D its coloring may change very slightly, but if it is a
> single facet of a larger surface this will probably not be noticed since
> the adjacent triangles are similarly affected.

I will add a custom version to test these cases using numerical
results (output the edges values to a file and compare them). We can
then see if the error is acceptable. As you say, I do not expect any
noticeable differences.

> > the same issue can cause edges to be drawn differently if you switch th=
e
> > order of their vertices in the drawline() function call.
>
> This is the more important issue, as I tried to point out before.
> In rendering a tesselated surface, it is common that the same edge
> will be traversed in different directions in the course of rendering
> the two facets that it separates.  In order to assure smooth coloring
> across the break, it is crucial that the direction of traversal not
> affect the color assignment.

The "psychedelic example shows a case where the same edge is shared
between different triangles. I did not see any artifacts.

It was expected as the slopes and delta are not affected by the
position of the vertex, it is alway V(n) - V(n-1), where n is the
first or not should not change the constant slopes and delta. If yes,
we will see it with the numerical tests (hopefully :).

--Pierre

Re: [RFC] Gradient fill options

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 07 February 2007 11:44, Hans-Bernhard Br=F6ker wrote:
> Pierre wrote:
>=20
> > I'm not sure to understand why it is biased. Each vertex color is
> > known. The first vertex is the top left one, after they have been
> > sorted.
>=20
> The bias lies in picking the top left vertex as "the first".=20
> This can cause nasty effects like: the same triangle comes out subtly=20
> different if the scene is rendered upside down or rotated by 90 degress,=
=20
> even though the result should be exactly the same.   =20

That is true, but the failure mode is usually harmless. If you rotate the
triangle in 3D its coloring may change very slightly, but if it is a
single facet of a larger surface this will probably not be noticed since
the adjacent triangles are similarly affected.

> the same issue can cause edges to be drawn differently if you switch the=
=20
> order of their vertices in the drawline() function call.

This is the more important issue, as I tried to point out before.
In rendering a tesselated surface, it is common that the same edge
will be traversed in different directions in the course of rendering
the two facets that it separates.  In order to assure smooth coloring
across the break, it is crucial that the direction of traversal not
affect the color assignment.


=2D-=20
Ethan A Merritt

Re: [RFC] Gradient fill options

[<HBB...@t-...>]

Pierre wrote:
>> > And, more importantly, it's a bit biased, which tends to turn into a
>> > robustness problem.  The bias lies in the arbitrary choice of one 
>> > vertex to be shared by the two first interpolations.

> I'm not sure to understand why it is biased. Each vertex color is
> known. The first vertex is the top left one, after they have been
> sorted.

The bias lies in picking the top left vertex as "the first".  Why should 
this be treated different from the other two?  It doesn't necessarily 
have to cause visible rounding/precision effects, but it can.

This can cause nasty effects like: the same triangle comes out subtly 
different if the scene is rendered upside down or rotated by 90 degress, 
even though the result should be exactly the same.    Other cases of the 
same issue can cause edges to be drawn differently if you switch the 
order of their vertices in the drawline() function call.

Re: save does not save key bindings

[Petr M. <mi...@ph...>]

> > I discovered that key bindings are not saved by a "save"
> > command.  Intentional? Oversight?
> > 
> > Should we add these as a normal part of "save"?
> > Should there instead be a separate "save bindings" command?
> 
> I'd vote for adding `bindings` to the list.  I'm guessing there is someone 
> who'd like to set up their bindings and save just the bindings.  Then 
> perhaps add a load command to their initialization file.  So, "yes" on 
> both those questions.

I agree.

---
PM

Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

Hi,

The code has added in the new playground module in libgd CVS:

http://cvs.php.net/viewvc.cgi/gd/playground/gdimageshadedtriangle/

This version contains the last patch from Daniel.

By the way, if you like to have CVS access, please let me know. I
think it may improve the testing process.

On 2/7/07, Daniel J Sebald <dan...@ie...> wrote:
> Hans-Bernhard Br=F6ker wrote:
> > Daniel J Sebald wrote:
> >
> >>I've looked through the code a bit and your examples.  (What command
> >>does one need to compile this program?)  I'd have to think about your
> >>approach to be certain about the result.  You've broken the thing down
> >>into a series of one dimensional linearities, first along the sides of
> >>the triangle to get a color, and then across the x dimension to further
> >>interpolate between those two.  Seems logical, but it may be open for
> >>rounding problems.
> >
> >
> > And, more importantly, it's a bit biased, which tends to turn into a
> > robustness problem.  The bias lies in the arbitrary choice of one verte=
x
> > to be shared by the two first interpolations.
> >
> > It can be better to go via barycentric coordinates.  It's effectively a
> > method to find three numbers s, t, and u such that:
> >
> >       s+t+u=3D1
> >       s*A + t*B + u*C =3D X  for the point, and its colour.
> >
> > I.e. you solve the equation for s,t,u given a point X, then substitute
> > them into the equation to find the target colour.
>
> Interesting.  This results in matrix equations similar to what I sent pre=
viously:

I'm not sure to understand why it is biased. Each vertex color is
known. The first vertex is the top left one, after they have been
sorted.

Or is it something you will do outside the function to define the
color at each vertex?

Is it about having a higher precision for the interpolation (instead
of the linear interpolation)?

Maybe an example result may help to see the differences and their
impacts in a real case. Maybe using an existing surface (one in your
test cases), we can then compare all results.

Pardon me if my questions are too obvious but I never looked so deeply
the rounding/precision problems. it is really a good thing as it
minimizes the risk of errors (no bad surprise after the releases).

--Pierre

Re: Copy to clipboard for Linux

[Daniel J S. <dan...@ie...>]

On the topic of key bindings, I've updated clipboard patch #1523316.

Dan

Re: [RFC] Gradient fill options

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Bröker wrote:
> Daniel J Sebald wrote:
> 
>>I've looked through the code a bit and your examples.  (What command 
>>does one need to compile this program?)  I'd have to think about your 
>>approach to be certain about the result.  You've broken the thing down 
>>into a series of one dimensional linearities, first along the sides of 
>>the triangle to get a color, and then across the x dimension to further 
>>interpolate between those two.  Seems logical, but it may be open for 
>>rounding problems.
> 
> 
> And, more importantly, it's a bit biased, which tends to turn into a 
> robustness problem.  The bias lies in the arbitrary choice of one vertex 
> to be shared by the two first interpolations.
> 
> It can be better to go via barycentric coordinates.  It's effectively a 
> method to find three numbers s, t, and u such that:
> 
> 	s+t+u=1
> 	s*A + t*B + u*C = X  for the point, and its colour.
> 
> I.e. you solve the equation for s,t,u given a point X, then substitute 
> them into the equation to find the target colour.

Interesting.  This results in matrix equations similar to what I sent previously:

s * x_1 + t * x_2 + u * x_3 = x
s * y_1 + t * y_2 + u * x_3 = y
s * 1   + t * 1   + u * 1   = 1

or

| x_1 x_2 x_3 |
| y_1 y_2 y_3 |
| 1   1   1   |

(call it Z) product with

[s t u]'

equals

[x y 1]'

so

[s t u]' = inv(Z) [x y 1]'

Since I doubt you'd want to compute the intermediate values s t u for each pixel inside the triangle

c = [c_1 c_2 c_3] * [s t u]'

 = [c_1 c_2 c_3] * inv(Z) * [x y 1]'

 = [w_1 w_2 b] * [x y 1]'

 = w' * [x y]' + b

Dan

libgd-2.0.34 released

[Pierre <pie...@gm...>]

Hi,

A small note about the immediate release of gd-2.0.34. I would like to
thank you for all the feedbacks and bug reports.

See the release announcement here:

http://www.libgd.org/ReleaseNote020034

Downloads:
http://www.libgd.org/releases/

Have fun with gnuplot and gd!

Regards,
--Pierre

Re: save does not save key bindings

[Daniel J S. <dan...@ie...>]

Ethan A Merritt wrote:
> While creating a gnuplot script for use as a class demo,
> I discovered that key bindings are not saved by a "save"
> command.  Intentional? Oversight?
> 
> Should we add these as a normal part of "save"?
> Should there instead be a separate "save bindings" command?
> 

>From the documentation:

 where <option> is `functions`, `variables`, `terminal` or `set`. If
 no option is used, `gnuplot` saves functions, variables, `set`
 options and the last `plot` (`splot`) command.

I'd vote for adding `bindings` to the list.  I'm guessing there is someone who'd like to set up their bindings and save just the bindings.  Then perhaps add a load command to their initialization file.  So, "yes" on both those questions.

Dan

save does not save key bindings

[Ethan A M. <merritt@u.washington.edu>]

While creating a gnuplot script for use as a class demo,
I discovered that key bindings are not saved by a "save"
command.  Intentional? Oversight?

Should we add these as a normal part of "save"?
Should there instead be a separate "save bindings" command?

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Redirecting "print" output?

[Daniel J S. <dan...@ie...>]

> That does work for a long time...:

OK, thanks everyone.

Re: Redirecting "print" output?

[Petr M. <mi...@ph...>]

> Is it possible, or does it seem like a good feature, to have the output of 
> a "print" command redirected? Of course, that info is now in the many 
> GPVAL_ variables, and what is nice is that "print GPVAL_X_MAX" prints out 
> a single value that requires little processing than a simple formatted 
> variable read (no weeding out other stuff).  Perhaps everything there is 
> needed already (I'm not as proficient in redirection as others on the 
> list).  Otherwise, would the ability to redirect "print" to a file 
> (Windows?... any word on Vista?) or pipe be of any benefit?

That does work for a long time...:

gnuplot> set print "a.dat"
gnuplot> plot x
gnuplot> print 1,2
gnuplot> print GPVAL_X_MIN, GPVAL_X_MAX
gnuplot> set print
gnuplot> !cat a.dat
1 2
-10.0 10.0
!

Or do you mean sth completely different?


> Octave has interest in getting back the range values from gnuplot's 
> autoranging result after a plot.

Piping is used in ginput.m, for example, to get MOUSE_ variables. For 
GPVAL_, it would be the same. The current gpinput.m is on gnuplot's web 
page.

---
PM

Re: Redirecting "print" output?

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 06 February 2007 15:25, Daniel J Sebald wrote:
> Is it possible, or does it seem like a good feature, 
> to have the output of a "print" command redirected?

Already there.

  set print "/my/output/file"
  print "foo"













> Octave has interest in getting back the range values from gnuplot's autoranging result after a plot.  Of course, that info is now in the many GPVAL_ variables, and what is nice is that "print GPVAL_X_MAX" prints out a single value that requires little processing than a simple formatted variable read (no weeding out other stuff).  Perhaps everything there is needed already (I'm not as proficient in redirection as others on the list).  Otherwise, would the ability to redirect "print" to a file (Windows?... any word on Vista?) or pipe be of any benefit?  
> 
> Dan
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

-- 
Ethan A Merritt                                 Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

Re: Redirecting "print" output?

[<HBB...@t-...>]

Daniel J Sebald wrote:

> Is it possible, or does it seem like a good feature, to have the
> output of a "print" command redirected?

It's possible since version 4.0 already.  See 'help set print'

Redirecting "print" output?

[Daniel J S. <dan...@ie...>]

Is it possible, or does it seem like a good feature, to have the output of a "print" command redirected?  Octave has interest in getting back the range values from gnuplot's autoranging result after a plot.  Of course, that info is now in the many GPVAL_ variables, and what is nice is that "print GPVAL_X_MAX" prints out a single value that requires little processing than a simple formatted variable read (no weeding out other stuff).  Perhaps everything there is needed already (I'm not as proficient in redirection as others on the list).  Otherwise, would the ability to redirect "print" to a file (Windows?... any word on Vista?) or pipe be of any benefit?

Dan

Re: [RFC] Gradient fill options

[<HBB...@t-...>]

Daniel J Sebald wrote:
> I've looked through the code a bit and your examples.  (What command 
> does one need to compile this program?)  I'd have to think about your 
> approach to be certain about the result.  You've broken the thing down 
> into a series of one dimensional linearities, first along the sides of 
> the triangle to get a color, and then across the x dimension to further 
> interpolate between those two.  Seems logical, but it may be open for 
> rounding problems.

And, more importantly, it's a bit biased, which tends to turn into a 
robustness problem.  The bias lies in the arbitrary choice of one vertex 
to be shared by the two first interpolations.

It can be better to go via barycentric coordinates.  It's effectively a 
method to find three numbers s, t, and u such that:

	s+t+u=1
	s*A + t*B + u*C = X  for the point, and its colour.

I.e. you solve the equation for s,t,u given a point X, then substitute 
them into the equation to find the target colour.

Re: [RFC] Gradient fill options

[Daniel J S. <dan...@ie...>]

Pierre wrote:

>> Anyway, I'd be interested in the equilateral "color triangle".
> 
> 
> Please find it here (Example 2): http://blog.thepimp.net/misc/gdshading/

That looks good.  All portions have a blended, semicircular appearance.  The previous examples choice of points resulted in something slightly different.

Yes, fixed-point is good so long as resolution is kept high.  Stay with that approach.

Dan

Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

On 2/4/07, Daniel J Sebald <dan...@ie...> wrote:
> Pierre wrote:
>
> > I put a meaningless example here: http://blog.thepimp.net/misc/gdshading/
> >
> > The color stop points are in the comments, it is something like a
> > range -0.25..1.0 used "black blue red yellow".
> >
> > The results has no special value (besides being a nice shading effect
> > ;),
>
> psychedelic
>
> > but it may help to see how gdShadedTriangle works and what should
> > be done to match your needs.
>
> I've looked through the code a bit and your examples.  (What command does one need to compile this program?)

gcc colormap.c -o colormap -I/path/to/usr/include -L/path/to/usr/lib -lgd

or if you use 2.0.34RC2 or  CVS version of libgd you can simply add
something like (CMake must installed, see README.TESTING):

add_executable(colormap "colormap.c")
target_link_libraries(colormap  ${GD_LIB})

at the end of the CMakeLists.txt.

> I'd have to think about your approach to be certain about the result.  You've broken the thing down into a series of one dimensional linearities, first along the sides of the triangle to get a color, and then across the x dimension to further interpolate between those two.  Seems logical, but it may be open for rounding problems.

yes, it is a linear interpolation between the two edges of each scan
line. I use the following doc to implement it:

http://tfpsly.free.fr/Docs/3dIca/3dica3.htm

> Another thing that makes me wonder a bit (and this may be a visual effect), is that I look at your gouraud3.png example:
>
> http://bugs.libgd.org/?getfile=25
>
> and imagine looking at just one of the triangles, with blue in one corner, red in another, green in the third.  Somehow it appears that they aren't blending together the way I would think.  Would it be possible to generate a fairly big equilateral triangle, say,
>
>         x0 = 10; y0 = 10;
>         x1 = 310; y1 = 10;
>         x2 = 160; y2 = 270;
>
> so that we'd expect a nice symmetrical blending of the components?

Yes, there is maybe a rounding problem as the precision is limited by
the fixed point arithmetic), but it is relatively easy to solve by
increasing the precision. I like fixed point arithmetic because it is
fast (in embedded systems too).

> I'll offer up an alternative construction, not that I'm suggesting a change,

There is absolutely no problem to suggest changes. My current
implementation is only a proposal as I used it for some basic 3D
rendering and I was happy with the quality and speed.

> but just for the sake of brainstorming.  If one thinks in terms of a single color component, it can be imagined as a two dimensional plane in three dimensional space (x and y are two dimensions, c the color a third dimension).  Generalizing the z = m x + b idea for a line, we have three points for which we want a plane to pass through.  Let w be a two dimensional vector, b a constant.  Color is then
>
> c = w' * [x y]' + b
>
> i.e., if we know w and b, we can find any color value on that plane from the above formula.  Given triplets (x_1, y_1, c_1), (x_2, y_2, c_2), (x_3, y_3, c_3), define matrix:
>
> A =
>
> | x_1  y_1  1 |
> | x_2  y_2  1 |
> | x_3  y_3  1 |
>
> and vector c = [c_1 c_2 c_3]' and vector d = [w b]'.  Then
>
> A d = c
>
> and solving for d gives
>
> d = inv(A) c
>
> I wrote a 3D inverse routine the other day.  Ultimately, this approach wouldn't mean much less code because of the inversion, but its advantage might be a little more precision, not sure.

I'm not sure either. However this solution is elegant, if you have an
implementation already (even without the gd part), I can try to
provide it as a separate patch/example. It will help to run tests
against a serie of cases.

> Anyway, I'd be interested in the equilateral "color triangle".

Please find it here (Example 2): http://blog.thepimp.net/misc/gdshading/

--Pierre

Re: [RFC] Gradient fill options

[Daniel J S. <dan...@ie...>]

Pierre wrote:

> I put a meaningless example here: http://blog.thepimp.net/misc/gdshading/
> 
> The color stop points are in the comments, it is something like a
> range -0.25..1.0 used "black blue red yellow".
> 
> The results has no special value (besides being a nice shading effect
> ;),

psychedelic

> but it may help to see how gdShadedTriangle works and what should
> be done to match your needs.

I've looked through the code a bit and your examples.  (What command does one need to compile this program?)  I'd have to think about your approach to be certain about the result.  You've broken the thing down into a series of one dimensional linearities, first along the sides of the triangle to get a color, and then across the x dimension to further interpolate between those two.  Seems logical, but it may be open for rounding problems.

Another thing that makes me wonder a bit (and this may be a visual effect), is that I look at your gouraud3.png example:

http://bugs.libgd.org/?getfile=25

and imagine looking at just one of the triangles, with blue in one corner, red in another, green in the third.  Somehow it appears that they aren't blending together the way I would think.  Would it be possible to generate a fairly big equilateral triangle, say,

	x0 = 10; y0 = 10;
	x1 = 310; y1 = 10;
	x2 = 160; y2 = 270;

so that we'd expect a nice symmetrical blending of the components?

I'll offer up an alternative construction, not that I'm suggesting a change, but just for the sake of brainstorming.  If one thinks in terms of a single color component, it can be imagined as a two dimensional plane in three dimensional space (x and y are two dimensions, c the color a third dimension).  Generalizing the z = m x + b idea for a line, we have three points for which we want a plane to pass through.  Let w be a two dimensional vector, b a constant.  Color is then

c = w' * [x y]' + b

i.e., if we know w and b, we can find any color value on that plane from the above formula.  Given triplets (x_1, y_1, c_1), (x_2, y_2, c_2), (x_3, y_3, c_3), define matrix:

A =

| x_1  y_1  1 |  
| x_2  y_2  1 |  
| x_3  y_3  1 |  

and vector c = [c_1 c_2 c_3]' and vector d = [w b]'.  Then

A d = c

and solving for d gives

d = inv(A) c

I wrote a 3D inverse routine the other day.  Ultimately, this approach wouldn't mean much less code because of the inversion, but its advantage might be a little more precision, not sure.

Anyway, I'd be interested in the equilateral "color triangle".

Dan

Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

On 2/3/07, Hans-Bernhard Br=F6ker <HBB...@t-...> wrote:
> Pierre wrote:
> > On 2/2/07, Hans-Bernhard Br=F6ker <HBB...@t-...> wrote:
> >> To give an example, from an RGB palette defined like this:
> >>
> >> 0.0: blue
> >> 0.5: white
> >> 1.0: red
>
> > I'm not sure to understand the notion of palette in your example.
>
> It's a (principally) continuous mapping from a numeric value (the number
> being displayed) to a colour.  In the case above, it consists of two
> linear paths, one from blue to white, the second from white to red.  The
> idea is to turn a data parameter into a colour, a.k.a. "false-colour
> diagram".  It's how altitude is often displayed on geographical maps
> (green lowlands, brown hills, white peaks, blue ocean).

Thanks for the explanation.

I think the shaded triangle in #39
(http://bugs.libgd.org/?do=3Ddetails&task_id=3D39) should work.

You can keep your mapping and pass the color value of each vertex.
Within a triangle the colors will be inside your range (linear
interpolation from c1 to c2 between two edges).

I put a meaningless example here: http://blog.thepimp.net/misc/gdshading/

The color stop points are in the comments, it is something like a
range -0.25..1.0 used "black blue red yellow".

The results has no special value (besides being a nice shading effect
;), but it may help to see how gdShadedTriangle works and what should
be done to match your needs.

--Pierre

Re: Key improperly placed for splot maps

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

> zoom to have the same behavior, the plot access should remain the

plot "axes" should remain the same