Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-24 06:27:23
|
I have just uploaded to SourceForge a new patchset #1072284 that allows all
plot elements, 2D or 3D, to use PM3D palette coloring options.
Please have a look at it.
Output from a demo script is here:
http://www.bmsc.washington.edu/people/merritt/gnuplot/demo/palette_2D.html
The code is very simple. The generic linetype structure now contains a
t_colorspec substructure. This is parsed inside lp_parse() and applied
inside term_apply_lp_properties(). These two chunks of code thus handle all
plot elements that have an associated linetype.
Benefits:
1) plot elements can be assigned to have arbitrary colors (a frequent request)
2) these colors are terminal-independent (another frequent request)
What's still missing:
1) Pattern fill behavior is terminal-dependent. This is fixable, but probably
not a high priority.
2) The "save" and "show" commands do not funnel printout of linetype
properties through a shared routine. This means that there is no single place
I can change to correctly report the palette properties of all plot elements.
This is only a problem if you want to save your session for later reloading.
For now the work-around is to define and use explicit linestyles.
3) ??? Tell me if you find something else I missed.
|
|
From: Petr M. <mi...@ph...> - 2004-11-25 08:30:39
|
> I have just uploaded to SourceForge a new patchset #1072284 that allows all > plot elements, 2D or 3D, to use PM3D palette coloring options. > Please have a look at it. > > Output from a demo script is here: > http://www.bmsc.washington.edu/people/merritt/gnuplot/demo/palette_2D.html That's nice! Isn't there white and black missing in the color wheel? However, it is not flexible for using "red", "white", etc colors in splots. I would prefer an approach that would itself be able to extract a color matching to e.g. "red". If you look to show.c:show_palette_fit2rgbformulae(), there is a method to calculate distance between given (rgb) color and any other color. File tables.c contains color names and their RGBs. Thus user's plot sin(x) with line Red lw 2 where Red would be Red = getcolor("red") or, for any rgb, MyLightRed = getcolor(0.9,0.01,0.01) would search through the current palette and find the corresponding "pal frac". Thus this could would work on all color tables, giving more or less same results. I have no clear idea what from the above should be constant, macro, function. Those palette having infinite number of colors would be sampled to e.g. 256 discrete colors during the search. > 2) The "save" and "show" commands do not funnel printout of linetype > properties through a shared routine. This means that there is no single place save would work with the above method > PM3D palette I would rather call it "palette of smooth continuous colors" or like that, as in 'help palette' --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-25 20:24:35
|
On Thursday 25 November 2004 12:30 am, Petr Mikulik wrote:
> > I have just uploaded to SourceForge a new patchset #1072284 that allows
> > all plot elements, 2D or 3D, to use PM3D palette coloring options.
>
> Isn't there white and black missing in the color wheel?
The color wheel in the demo is a standard HSV colorwheel with
Saturation and Value both set to 1. That is, it maps the fractional
gray value onto a fully saturated Hue. White would correspond to
S=0; Black would correspond to V=0. These are not in the wheel,
but you don't need a color wheel to specify black or white
(actually foreground/background) since these are already available
as lt -1 and lt -2.
> However, it is not flexible for using "red", "white", etc colors in splots.
> I would prefer an approach that would itself be able to extract a
> color matching to e.g. "red".
The colorwheel demo shows one possible use of this feature for
2D plots. I agree that the use of a specific color wheel is not compatible
with 3D plots that require a different palette function.
> If you look to show.c:show_palette_fit2rgbformulae(), there is a method to
> calculate distance between given (rgb) color and any other color.
> MyLightRed = getcolor(0.9,0.01,0.01)
>
That's a good idea. It would still be a problem that if you change
the palette, any existing *constant* color assignments would become
invalid. In order to make such definitions independent of the
current palette, they would have to themselves be functions that
are evaluated at plot time. So I think it would have to be:
MyLightRed() = sprintf("%3.1f",getcolor(0.9,0.01,0.01))
plot sin(x) lt palette frac MyLightRed()
(yes, I know it is not currently possible to define a function with
no arguments)
or maybe
MyLightRed = 'lt palette frac sprintf("%3.1f",getcolor(.9,.1,.1))'
plot sin(x) @MyLightRed
We could leave this choice up to the user, however. Both become
possible if we introduce a user-callable function getcolor(r,g,b).
> > PM3D palette
>
> I would rather call it "palette of smooth continuous colors" or like that,
OK.
The required configuration option is ./configure --enable-pm3d,
and the documentation uses this term in many places. I agree that it
would be better to distinguish between the palette to choose specific
colors and the use of a palette to map colors onto 3D surfaces (=pm3d).
|
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-28 22:59:06
|
On Thursday 25 November 2004 12:30 am, Petr Mikulik wrote: > > However, it is not flexible for using "red", "white", etc colors in splots. > I would prefer an approach that would itself be able to extract a > color matching to e.g. "red". Done. Revised patchset on SourceForge. I have added a suboption keyword "rgbcolor" (shorthand "rgb") to the linetype specifier. It accepts a string parameter which is either a hexadecimal RGB triple in the form "#RRGGBB" or one of the color names in gnuplot's internal table. See "show palette colornames". plot "foo" with lines lt rgb "#DDFF00" plot "bar" with lines lt rgb "goldenrod" It is up to the individual drivers how to provide these colors, and of course it only works for terminal types that support RGB color. > If you look to show.c:show_palette_fit2rgbformulae(), there is a method to > calculate distance between given (rgb) color and any other color. I tried that first, but it turns out not to work very well. The problem is that it only knows about colors in the current palette, and most "pure" colors do not appear in the palette at all. So for example, the default palette has no greens. Requesting anything green or greenish by this mechanism returns black. It is of course possible to define a palette that contains a comprehensive sampling of colors, but then you are right back to the problem that the color selection method only works with certain specific palettes. Anyway, the direct RGB request method works much better. Have a look. |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-29 23:26:53
|
On Monday 29 November 2004 09:38 am, Mike wrote: > > You might wish to consider making the leading character in the colorspec > and 'x' to be consistent with your work on the GD-related drivers, or to > make the GD-drivers consistent with this work and allow either a leading > 'x' or the leading '#'. The color specs in the gd driver pre-date my involvement. I had forgotten about them, although coincidentally I looked them up yesterday because Dan Sebald was asking how to set the background color. Anyhow, I chose the #rrggbb syntax because that is how the colors are given to 'set palette defined', and the discussion of color names and hexadecimal representations applies perfectly to this new case also. So if I were to change anything, I think it would be gd.trm. thanks for the feedback. Ethan -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Petr M. <mi...@ph...> - 2004-11-30 08:33:04
|
> > You might wish to consider making the leading character in the colorspec > > and 'x' to be consistent with your work on the GD-related drivers, or to > > make the GD-drivers consistent with this work and allow either a leading > > 'x' or the leading '#'. > > The color specs in the gd driver pre-date my involvement. > I had forgotten about them, although coincidentally I looked them up > yesterday because Dan Sebald was asking how to set the background > color. That syntax in for gif/png is because # denotes a comment. An idea would be to use the strings, allowing for colornames as well: set terminal png "red" "green" "blue" "#123456" or maybe with a new keyword set terminal png colors "red" "green" "blue" "#123456" -- PM |
|
From: Petr M. <mi...@ph...> - 2004-11-30 08:33:03
|
> > However, it is not flexible for using "red", "white", etc colors in splots.
> > I would prefer an approach that would itself be able to extract a
> > color matching to e.g. "red".
>
> Done. Revised patchset on SourceForge.
>
> names in gnuplot's internal table. See "show palette colornames".
>
> plot "foo" with lines lt rgb "#DDFF00"
> plot "bar" with lines lt rgb "goldenrod"
>
> Anyway, the direct RGB request method works much better.
That's a great solution!
(*)
gnuplot> plot x w l lt pal
2D plots cannot color by Z value; please use splot instead
It should say sth like "plot: argument for palette is always required" or
"the syntax is 'lt pal' for splot (z-coloring), or 'lt pal <color>' for
plot"
(*)
'help linestyle': please add help for the rgb
Otherwise, the patch is fine.
---
PM
|
|
From: Petr M. <mi...@ph...> - 2004-11-30 08:42:13
|
> plot "foo" with lines lt rgb "#DDFF00" > plot "bar" with lines lt rgb "goldenrod" There could be a new built-in routine hsv2rgb(h,s,v) that would do the RGB string by the given h,s,v by means of getcolor.c:HSV_2_RGB(). Similarly, cmy2rgb(c,m,y) ciexyz2rgb() yiq2rgb() Additionally, these routines could be used for testing the conversion employed via various 'set palette' models. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2004-11-29 04:01:28
|
Petr Mikulik wrote: >>I have just uploaded to SourceForge a new patchset #1072284 that allows all >>plot elements, 2D or 3D, to use PM3D palette coloring options. >>Please have a look at it. >> >>Output from a demo script is here: >> http://www.bmsc.washington.edu/people/merritt/gnuplot/demo/palette_2D.html >> >> > >That's nice! > > That does look rather slick. I've been wondering about plot background colors, too. I often see plots with slightly off-white backgrounds. There is the X11 background color, but nothing for controlling background color for, say, png or PostScript. I know it has little to do with the "scientific" leanings of gnuplot. It would require something like "set background" (whole area including axes and labels), "set plotground" (area only inside the axes). This might then require some color such as "none" or "clear", which have obvious meanings in terminals like PostScript. Just a thought. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-29 04:25:47
|
On Sunday 28 November 2004 08:02 pm, Daniel Sebald wrote:
> I've been wondering about plot background colors, too. I often see
> plots with slightly off-white backgrounds. There is the X11 background
> color, but nothing for controlling background color for, say, png
You have not been looking very hard. Here is part of the output
from 'help set term png'
set term png ... {<color0> <color1> <color2> ...}
...
The background color is set first, then the border colors, then
the X & Y axis colors, then the plotting colors.
> or PostScript.
The PostScript output has no background color. It is intended to print on
whatever piece of paper you like, including a colored piece of paper.
Same thing if you import it into an electronic document - it gets the
background of whatever style sheet you import it into.
If you really need a solid background in a stand-along PostScript file
for some reason, it's a 1 or 2 line edit:
1) Find the line at the top of the file that says something like
%%BoundingBox: 50 50 554 770
2) Find the line that says
%%EndProlog
3) Just before the EndProlog line, add a command to fill the bounding box
with a color of your choice:
1 .4 1 setrgbcolor newpath
50 50 moveto 50 770 lineto 554 770 lineto 554 50 lineto closepath fill
Now your plot has a nice purple background.
> Just a thought.
I don't think it makes much sense, except maybe for bitmap output modes
that do not support transparency. For all other output formats, the
background is controlled by the document/webpage/paper/etc that the
plot is imported into.
|
|
From: Daniel J S. <dan...@ie...> - 2004-11-29 05:02:32
|
Ethan Merritt wrote:
>On Sunday 28 November 2004 08:02 pm, Daniel Sebald wrote:
>
>
>>I've been wondering about plot background colors, too. I often see
>>plots with slightly off-white backgrounds. There is the X11 background
>>color, but nothing for controlling background color for, say, png
>>
>>
>
>You have not been looking very hard. Here is part of the output
>from 'help set term png'
>
> set term png ... {<color0> <color1> <color2> ...}
> ...
> The background color is set first, then the border colors, then
> the X & Y axis colors, then the plotting colors.
>
>
OK. This works, thanks. I experimented with the first couple colors.
A keyword level solution with demo would be nicer to work with, I
think. However, that might be a bit too much work given lack of
consistency across terminals... and the fact that 2D/3D plotting and
layout are slightly different. (I still think combining 2D/3D as much
as possible would be a worthwhile step sooner than later... In
January/February I will propose removing the BINARY_DATA_FILE switch to
make plot.c and plot3d.c more similar.)
Dan
|
|
From: Petr M. <mi...@ph...> - 2004-11-30 08:35:03
|
> I've been wondering about plot background colors, too. I often see
> plots with slightly off-white backgrounds. There is the X11 background
> color, but nothing for controlling background color for, say, png or
> PostScript. I know it has little to do with the "scientific" leanings
> of gnuplot. It would require something like "set background" (whole
> area including axes and labels), "set plotground" (area only inside the
> axes). This might then require some color such as "none" or "clear",
> which have obvious meanings in terminals like PostScript.
Yet another background is that of the graph (easy for 2D and 'view map',
more intriguing for 3D), and for the key.
What about some new syntax for that?
set key ... background rgb "gray10"
set border ... background rgb "gray10"
set size ... background rgb "cyan"
or
set style background {key | border | graph | paper} .... ?
---
PM
|
|
From: Daniel J S. <dan...@ie...> - 2004-12-06 03:59:00
|
Petr Mikulik wrote:
>>I've been wondering about plot background colors, too. I often see
>>plots with slightly off-white backgrounds. There is the X11 background
>>color, but nothing for controlling background color for, say, png or
>>PostScript. I know it has little to do with the "scientific" leanings
>>of gnuplot. It would require something like "set background" (whole
>>area including axes and labels), "set plotground" (area only inside the
>>axes). This might then require some color such as "none" or "clear",
>>which have obvious meanings in terminals like PostScript.
>>
>>
>
>Yet another background is that of the graph (easy for 2D and 'view map',
>more intriguing for 3D), and for the key.
>
>What about some new syntax for that?
>
>set key ... background rgb "gray10"
>set border ... background rgb "gray10"
>set size ... background rgb "cyan"
>
>or
>
>set style background {key | border | graph | paper} .... ?
>
>
>
(I was out of town for a bit...) Either of these would be fine. Or
does your "or" mean both methods should be implemented?
This doesn't seem like a difficult thing to add. It wouldn't be
something I could get around to for a while. Rather than letting this
proposed syntax get lost in the discussion list, maybe it would be a
good idea to put this under a patch or something in SourceForge. There
wouldn't be an actual patch there just yet, unfortunately, but it would
be a reminder for later? Should we do that?
For the 3D interpretation, how about just coloring the x-y plane
portion? Another alternative might be the back three sides of a 3-space
cube, but I don't know if that would have an appealing look.
Individually controlling plane colors?... that's over doing it in my
opinion.
...
With the rgb color format. Those are fine. Also, I added a tuple
format for the binary data options, to represent points in 2-space or
3-space. For example, (1.5,3.5) or (4.5, 3.3, 2.2). Could those be
used in other places? E.g.,
set key ... background rgb (0.3, 0.2, 0.57)
[Writing this just now makes it seem better in my mind than in type.]
If so, maybe the tuple code could be made part of the parser. I'm not
strongly advocating it, just tossing it out to the list.
Dan
|
|
From: Daniel J S. <dan...@ie...> - 2004-12-06 04:16:20
|
Daniel J Sebald wrote: > set key ... background rgb (0.3, 0.2, 0.57) Does this "rgb (0.3, 0.2, 0.57)" run the risk of being confused as a user-defined function? Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-12-06 04:47:17
|
Daniel J Sebald wrote: > Daniel J Sebald wrote: > >> set key ... background rgb (0.3, 0.2, 0.57) > > > > Does this "rgb (0.3, 0.2, 0.57)" run the risk of being confused as a > user-defined function? Hans' may have just answered this: > gnuplot> splot using (x):(y):f(x,y):color(x,y) > > <> Good thinging, in principle. Except may not be 100% correct. Some daring young fella *might* have gone ahead and defined himself a function named 'using' ;-) |
