Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2005-08-12 08:55:41
|
Patch "History file for gnuplot readline" has been just committed. So both
readlines can use it.
I'm bit surprised what "unset historysize" is doing. It sets historysize to
unlimited, not suppressing writing the history file.
I propose the following changes:
1. The code for history file is always compiled in (thus no need to
--enable-history-file nor to modify dozen of files in config/).
2. By default, the history file is not read. It can be switched on in
.gnuplot by "set historysize"
3. Switching off writing/reading history file: "unset historysize"
4. "set historysize -1" would set historysize to unlimited.
Ideas?
---
PM
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-08-13 22:33:22
|
On Friday 12 August 2005 01:55 am, Petr Mikulik wrote: > I'm bit surprised what "unset historysize" is doing. It sets historysize > to unlimited, not suppressing writing the history file. > > I propose the following changes: > 1. The code for history file is always compiled in (thus no need to > --enable-history-file nor to modify dozen of files in config/). > 2. By default, the history file is not read. It can be switched on in > .gnuplot by "set historysize" > 3. Switching off writing/reading history file: "unset historysize" > 4. "set historysize -1" would set historysize to unlimited. That all sounds reasonable. > Ideas? What does "set historysize 0" do? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2005-08-16 05:26:41
|
Ethan A Merritt wrote: > On Friday 12 August 2005 01:55 am, Petr Mikulik wrote: > >>4. "set historysize -1" would set historysize to unlimited. I've no strong opinions on historysize other than using "-1" as special meaning. It probably is easy from the parser's standpoint, but I don't like when negative numbers have special meaning. The data file "using" format is like this; 0 means point, -1 means line number, -2 means index number. I find that not user friendly. How do others feel? I'd suggest "unlimited", "infinity", "infinite" rather than -1. Dan |
|
From: V. <gae...@no...> - 2005-08-16 11:23:30
|
On Tue, Aug 16, 2005 at 12:31:18AM -0500, Daniel J Sebald wrote:
> The data file "using"=20
> format is like this; 0 means point, -1 means line number, -2 means inde=
x=20
> number. I find that not user friendly.
Agreed. I prefer words. And I have often heard users of gnuplot
complain about such numbers that they cannot remember.
--
Ga=EBl
|
|
From: Theo H. <th...@ph...> - 2005-08-16 13:23:32
|
Ga=EBl Varoquaux wrote: > On Tue, Aug 16, 2005 at 12:31:18AM -0500, Daniel J Sebald wrote: >=20 >> The data file "using"=20 >>format is like this; 0 means point, -1 means line number, -2 means inde= x=20 >>number. I find that not user friendly. >=20 > Agreed. I prefer words. And I have often heard users of gnuplot > complain about such numbers that they cannot remember. I've no opinion on the merits of a keyword or number in setting the=20 history size, since it seems to me that this is something that's set=20 once (in .gnuplot or equivalent) and then forgotten. For more frequently=20 used options (especially `using`) numbers are a good thing IMO, for the=20 following reasons: - I personally forget keywords more easily than numbers - numbers are generally shorter than keywords =3D less typing - variables can be used in place of numbers - numbers are the same across all languages THeo |
|
From: Daniel J S. <dan...@ie...> - 2005-08-16 16:36:45
|
Theo Hopman wrote: > Ga=EBl Varoquaux wrote: >=20 >> On Tue, Aug 16, 2005 at 12:31:18AM -0500, Daniel J Sebald wrote: >> >>> The data file "using" format is like this; 0 means point, -1 means=20 >>> line number, -2 means index number. I find that not user friendly. >> >> >> Agreed. I prefer words. And I have often heard users of gnuplot >> complain about such numbers that they cannot remember. >=20 >=20 > I've no opinion on the merits of a keyword or number in setting the=20 > history size, since it seems to me that this is something that's set=20 > once (in .gnuplot or equivalent) and then forgotten. But isn't that an argument for having a sensical keyword? Once in a blue= moon the user has to set this and thinks "Hmm, I want this to be unlimit= ed, what do I have to enter to make the history size _unlimited_?" My po= int is that a natural keyword is easier to understand. > For more frequently=20 > used options (especially `using`) numbers are a good thing IMO, for the= =20 > following reasons: > - I personally forget keywords more easily than numbers > - numbers are generally shorter than keywords =3D less typing In the case of 'using': 0 or p$oint -1 or l$ine -2 or i$ndex 'l' and 'i' are less typing than '-1' and '-2'. AND, I'd bet on average = that people's skill at type 'p', 'l', and 'i' are much better than type 0= , -1, -2. > - variables can be used in place of numbers [Hans' point] > Now imagine somebody who just happens to have an old gnuplot script > that defines all of the above variables equals to 5. Or to 1/0, for th= at > matter, or 1.0e300. My first question is Why are you defining "unlimited" to mean 5? Second = question is how popular is the redefining of keywords? I've not made muc= h use of defining stuff in gnuplot... By that thinking, gnuplot is forev= er stuck with the current syntax and cannot add any more keywords, hence = no new features, because someone may have defined any given keyword in th= e past equal to 1234567. > - numbers are the same across all languages So people should learn just a subset of the keywords like 'using', 'with'= , 'format' but not be expected to know 'point', 'line', 'index', 'unlimit= ed', 'infinity'? Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-08-16 20:37:50
|
Daniel J Sebald wrote: > [Hans' point] >> Now imagine somebody who just happens to have an old gnuplot script >> that defines all of the above variables equals to 5. Or to 1/0, for that >> matter, or 1.0e300. > My first question is Why are you defining "unlimited" to mean 5? I'm not. But some user very well might have a perfectly valid reason for doing so. He might even have decided to use it as an expression in some place where the current code expects a number, just because he could. This would be even worse with the single-letter alternatives I've seen mentioned elsewhere in this thread. > Second question is how popular is the redefining of keywords? It's not --- because it's impossible. But OTOH, "unlimited" has never been a keyword in gnuplot before, so if you introduce it now, you always run the risk of colliding with existing user-defined variables or functions. The point is that any syntax that allows either a keyword or a number in a given position of the command introduces a parsing ambiguity, because we generally allow numeric variables to be used in *every* place where a numeric constant could be, and such variables are essentially indistinguishable from keywords. User-defined variables and functions have been in gnuplot effectively forever. Which means that in case of a parsing conflict, they must take precedence, or we risk breaking users' scripts for no valid reasons. |
|
From: Bastian M. <bma...@we...> - 2005-08-14 05:43:40
|
Ethan A Merritt wrote: > On Friday 12 August 2005 01:55 am, Petr Mikulik wrote: > >>I'm bit surprised what "unset historysize" is doing. It sets historysize >>to unlimited, not suppressing writing the history file. >> >>I propose the following changes: >>1. The code for history file is always compiled in (thus no need to >> --enable-history-file nor to modify dozen of files in config/). I am working on a patch to have gnuplot compiled with libedit from NETBSD. So could the #ifdef GNUPLOT_HISTORY statements be left in there? This would save us some very long #ifdefs ... >>2. By default, the history file is not read. It can be switched on in >> .gnuplot by "set historysize" How would the environment variable 'GNUPLOT_HISTORY_SIZE' fit in there? Could this be treated like "set historysize" in .gnuplot? >>3. Switching off writing/reading history file: "unset historysize" >>4. "set historysize -1" would set historysize to unlimited. > > > That all sounds reasonable. > > >>Ideas? > > > What does "set historysize 0" do? > Wouldn't is make sense to limit the size of 'in-memory' history to historysize as well? But that wouldn't work with your approach. So how about seperate commands for enabling/disabling saving of history? E.g. sth. like "set history on/off". Btw. the gnuplot readline code already does use historysize to limit the size of history in memory, whereas (as far is can tell) the GNU readline version does not. There it's only used for saving. Bastian |
|
From: Petr M. <mi...@ph...> - 2005-08-14 15:31:53
|
> I am working on a patch to have gnuplot compiled with libedit from > NETBSD. So could the #ifdef GNUPLOT_HISTORY statements be left in > there? This would save us some very long #ifdefs ... If you manage to make a patch for removing that #ifdef first, then there is no need for them. >>> 2. By default, the history file is not read. It can be switched on in >>> .gnuplot by "set historysize" > > How would the environment variable 'GNUPLOT_HISTORY_SIZE' fit in > there? Could this be treated like "set historysize" in .gnuplot? Should it be set before or after reading .gnuplot? > Wouldn't is make sense to limit the size of 'in-memory' history > to historysize as well? But that wouldn't work with your is this necessary? > approach. So how about seperate commands for enabling/disabling > saving of history? E.g. sth. like "set history on/off". Good idea. That GNUPLOT_HISTORY could contain "no" in this case. --- PM |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-08-16 14:29:44
|
Daniel J Sebald wrote: > like when negative numbers have special meaning. The data file "using" > format is like this; 0 means point, -1 means line number, -2 means index > number. I find that not user friendly. How do others feel? While it may appear more user-friendly to use names instead of numbers, at least in the case of existing syntax, that's a risky change to make. > I'd suggest "unlimited", "infinity", "infinite" rather than -1. Now imagine somebody who just happens to have an old gnuplot script that defines all of the above variables equals to 5. Or to 1/0, for that matter, or 1.0e300. |
|
From: Robert H. <en...@no...> - 2005-08-16 15:57:40
|
On Tue, 2005-08-16 at 16:31 +0200, Hans-Bernhard Broeker wrote: > Daniel J Sebald wrote: > > like when negative numbers have special meaning. The data file "using" > > format is like this; 0 means point, -1 means line number, -2 means index > > number. I find that not user friendly. How do others feel? > > While it may appear more user-friendly to use names instead of numbers, > at least in the case of existing syntax, that's a risky change to make. > > > I'd suggest "unlimited", "infinity", "infinite" rather than -1. > > Now imagine somebody who just happens to have an old gnuplot script > that defines all of the above variables equals to 5. Or to 1/0, for > that matter, or 1.0e300. Well, ignoring for a second the shear unlikelihood of somebody loading an old gnuplot script that used a variable name at a position that would be ambiguous in the new version, I think the problem is more a case of how clearly we define the syntax. Option 1. Variables take precedence over keywords. This would seem to make sense for the "backward compatibility" point of view you discuss above. Once a variable with the same name has been defined, it is used in preference. Option 2. Keywords take precedence over variables. Option 3. Precedence is irrelevant because: Option 3a. All keywords are reserved. Attempts to assign to a keyword variable would fail. This would break existing scripts in some cases, but make it very obvious how to fix them. Would require the parser to have a definite list of keywords, which is a long way off how it works at present. Option 3b. Variables made syntactically obvious (e.g. $x instead of x (like perl or bash). One thing I'd like to see is better support for using plot variables in other places of the plot command. e.g. I was trying to do something like this: splot "data.txt" lc rgb(x,y,z) or splot "data.txt" using 1:2:3:rgb($1,$2,$3) lc variable The current syntax seems to support whatever the needs were of the person who wrote each plot type. In general however, I'm against the introduction of new "language features" into gnuplot. I think in many cases the better approach is to generate gnuplot scripts programmatically. Rob -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Juergen W. <wie...@fr...> - 2005-08-16 17:20:10
|
On Tuesday 16 August 2005 17:57 Robert Hart wrote: > [...], I think the problem is more a case of > how clearly we define the syntax. > > Option 1. Variables take precedence over keywords. > This would seem to make sense for the "backward compatibility" point of > view you discuss above. Once a variable with the same name has been > defined, it is used in preference. > > Option 2. Keywords take precedence over variables. > > Option 3. Precedence is irrelevant because: > > Option 3a. All keywords are reserved. > Attempts to assign to a keyword variable would fail. This would break > existing scripts in some cases, but make it very obvious how to fix > them. Would require the parser to have a definite list of keywords, > which is a long way off how it works at present. > > Option 3b. Variables made syntactically obvious (e.g. $x instead of x > (like perl or bash). Nice overview. You might want to have a look at RFE #1249742 "[syntax] optional expressions". It's my trial to implement Option 2. It turns out to be quite a lot of work. Option 1 could probably be implemented by little hacks into equals() and almost_equals(). Option 3a is simply impossible because of all the short cuts which form valid key words. Consider gnuplot> p "file" u 1:2 w l And option 3b (as option 1) would break backward compatibility at least once. If such a step would be done, I'd strongly suggest to think about a complete redesign of the syntax and the parser. I don't feel comfortable with gnuplot syntax. A simple example: What does an empty "set" statement do? Consider e.g. "set output", "set pm3d" and "set label". Juergen |
|
From: V. <gae...@no...> - 2005-08-16 17:32:21
|
On Tue, Aug 16, 2005 at 07:17:28PM +0200, Juergen Wieferink wrote:
> I don't feel comfortable with gnuplot syntax.
I don't mind it, but I know many skilled computer users who don't
like gnuplot because they claim that they cannot understand its syntax,
and therefore forget it. I couldn't pin point what was wrong with it,
though.
--
Ga=EBl
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-16 16:27:11
|
On Tuesday 16 August 2005 08:57 am, Robert Hart wrote:
>
> One thing I'd like to see is better support for using plot variables in
> other places of the plot command. e.g. I was trying to do something like
> this:
> splot "data.txt" lc rgb(x,y,z)
> or
> splot "data.txt" using 1:2:3:rgb($1,$2,$3) lc variable
That works, or would if you put parens around the expression:
set pm3d
splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Robert H. <en...@no...> - 2005-08-16 16:58:41
|
On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote: > That works, or would if you put parens around the expression: > set pm3d > splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines > Are you sure? This just gives: undefined function rgb. I even resorted to scanning through the source, but AFAICT the colour for a data series is defined only once, when the plot command is parsed, but before the data file is read. e.g. I have the data below, where the columns are r,g,b,frequency, and colorname I would like to plot "rgb space" such that preferably each point is located at (r,g,b), sized according to the frequency, and coloured to match the original colour. splot "data" using 1:2:3:4 with points pointsize variable gets me most of the way there, but the colour remains elusive. I would be willing to sacrifice the sizing of points to get the colours right (or overlay coloured blobs on scaled points for example) 36, 33, 26, 47, #24211A 44, 32, 27, 7, #2C201B 53, 35, 29, 18, #35231D 89, 39, 27, 9, #59271B 80, 44, 38, 12, #502C26 108, 54, 42, 10, #6C362A 95, 58, 68, 5, #5F3A44 118, 68, 54, 9, #764436 115, 78, 76, 6, #734E4C 138, 54, 32, 13, #8A3620 144, 78, 50, 8, #904E32 163, 86, 42, 9, #A3562A 181, 110, 52, 17, #B56E34 153, 103, 87, 12, #996757 175, 116, 79, 7, #AF744F 194, 122, 83, 12, #C27A53 155, 124, 131, 4, #9B7C83 157, 132, 122, 5, #9D847A 187, 133, 84, 11, #BB8554 185, 139, 109, 11, #B98B6D 196, 134, 62, 14, #C4863E 201, 143, 79, 17, #C98F4F 203, 151, 88, 20, #CB9758 202, 154, 103, 16, #CA9A67 201, 150, 113, 13, #C99671 211, 162, 92, 53, #D3A25C 207, 163, 114, 51, #CFA372 213, 166, 104, 49, #D5A668 214, 170, 119, 45, #D6AA77 221, 178, 123, 64, #DDB27B 227, 183, 124, 40, #E3B77C 177, 156, 154, 13, #B19C9A 205, 152, 137, 14, #CD9889 213, 158, 161, 7, #D59EA1 207, 168, 142, 20, #CFA88E 214, 172, 133, 34, #D6AC85 220, 180, 135, 65, #DCB487 220, 182, 150, 49, #DCB696 216, 184, 168, 21, #D8B8A8 225, 174, 147, 16, #E1AE93 227, 186, 136, 43, #E3BA88 227, 188, 150, 50, #E3BC96 227, 189, 164, 46, #E3BDA4 201, 188, 194, 4, #C9BCC2 233, 194, 139, 56, #E9C28B 234, 198, 153, 73, #EAC699 241, 204, 156, 48, #F1CC9C 235, 201, 167, 52, #EBC9A7 240, 208, 175, 42, #F0D0AF 234, 203, 181, 28, #EACBB5 238, 210, 181, 15, #EED2B5 239, 215, 185, 25, #EFD7B9 241, 206, 167, 19, #F1CEA7 243, 211, 171, 84, #F3D3AB 245, 215, 184, 104, #F5D7B8 214, 202, 201, 6, #D6CAC9 235, 213, 202, 23, #EBD5CA 247, 220, 195, 51, #F7DCC3 250, 229, 201, 108, #FAE5C9 252, 235, 214, 36, #FCEBD6 253, 241, 220, 25, #FDF1DC 249, 235, 229, 19, #F9EBE5 254, 244, 229, 25, #FEF4E5 255, 255, 255, 1204, #FFFFFF -- Robert Hart <en...@no...> University of Nottingham This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-16 17:06:31
|
On Tuesday 16 August 2005 09:58 am, Robert Hart wrote: > On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote: > > > That works, or would if you put parens around the expression: > > set pm3d > > splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines > > > > Are you sure? This just gives: undefined function rgb. I assumed that "rgb" was a user-defined function that assigned an rgb color on the basis of 3D coords x, y, and z. If you meant something else entirely, then please explain. > I even resorted to scanning through the source, but AFAICT the colour > for a data series is defined only once, when the plot command is parsed, > but before the data file is read. > > e.g. I have the data below, where the columns are r,g,b,frequency, and > colorname > > I would like to plot "rgb space" such that preferably each point is > located at (r,g,b), sized according to the frequency, and coloured to > match the original colour. > > splot "data" using 1:2:3:4 with points pointsize variable > > gets me most of the way there, but the colour remains elusive. I still don't understand what the function rgb() is expected to do, but if you provide the function then the following command will plot with color generated by the rgb() function and pointsize taken from column 4 (tested; works here): set pm3d splot "data" using 1:2:3:(rgb($1,$2,$3)):4 with points lt palette ps variable > I would > be willing to sacrifice the sizing of points to get the colours right > (or overlay coloured blobs on scaled points for example) > > 36, 33, 26, 47, #24211A > 44, 32, 27, 7, #2C201B > 53, 35, 29, 18, #35231D > 89, 39, 27, 9, #59271B > 80, 44, 38, 12, #502C26 > 108, 54, 42, 10, #6C362A > 95, 58, 68, 5, #5F3A44 > 118, 68, 54, 9, #764436 > 115, 78, 76, 6, #734E4C > 138, 54, 32, 13, #8A3620 > 144, 78, 50, 8, #904E32 > 163, 86, 42, 9, #A3562A > 181, 110, 52, 17, #B56E34 > 153, 103, 87, 12, #996757 > 175, 116, 79, 7, #AF744F > 194, 122, 83, 12, #C27A53 > 155, 124, 131, 4, #9B7C83 > 157, 132, 122, 5, #9D847A > 187, 133, 84, 11, #BB8554 > 185, 139, 109, 11, #B98B6D > 196, 134, 62, 14, #C4863E > 201, 143, 79, 17, #C98F4F > 203, 151, 88, 20, #CB9758 > 202, 154, 103, 16, #CA9A67 > 201, 150, 113, 13, #C99671 > 211, 162, 92, 53, #D3A25C > 207, 163, 114, 51, #CFA372 > 213, 166, 104, 49, #D5A668 > 214, 170, 119, 45, #D6AA77 > 221, 178, 123, 64, #DDB27B > 227, 183, 124, 40, #E3B77C > 177, 156, 154, 13, #B19C9A > 205, 152, 137, 14, #CD9889 > 213, 158, 161, 7, #D59EA1 > 207, 168, 142, 20, #CFA88E > 214, 172, 133, 34, #D6AC85 > 220, 180, 135, 65, #DCB487 > 220, 182, 150, 49, #DCB696 > 216, 184, 168, 21, #D8B8A8 > 225, 174, 147, 16, #E1AE93 > 227, 186, 136, 43, #E3BA88 > 227, 188, 150, 50, #E3BC96 > 227, 189, 164, 46, #E3BDA4 > 201, 188, 194, 4, #C9BCC2 > 233, 194, 139, 56, #E9C28B > 234, 198, 153, 73, #EAC699 > 241, 204, 156, 48, #F1CC9C > 235, 201, 167, 52, #EBC9A7 > 240, 208, 175, 42, #F0D0AF > 234, 203, 181, 28, #EACBB5 > 238, 210, 181, 15, #EED2B5 > 239, 215, 185, 25, #EFD7B9 > 241, 206, 167, 19, #F1CEA7 > 243, 211, 171, 84, #F3D3AB > 245, 215, 184, 104, #F5D7B8 > 214, 202, 201, 6, #D6CAC9 > 235, 213, 202, 23, #EBD5CA > 247, 220, 195, 51, #F7DCC3 > 250, 229, 201, 108, #FAE5C9 > 252, 235, 214, 36, #FCEBD6 > 253, 241, 220, 25, #FDF1DC > 249, 235, 229, 19, #F9EBE5 > 254, 244, 229, 25, #FEF4E5 > 255, 255, 255, 1204, #FFFFFF > > -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Robert H. <en...@no...> - 2005-08-16 17:46:28
|
On Tue, 2005-08-16 at 10:06 -0700, Ethan Merritt wrote:
> On Tuesday 16 August 2005 09:58 am, Robert Hart wrote:
> > On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote:
> >
> > > That works, or would if you put parens around the expression:
> > > set pm3d
> > > splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines
> > >
> >
> > Are you sure? This just gives: undefined function rgb.
>
> I assumed that "rgb" was a user-defined function that assigned
> an rgb color on the basis of 3D coords x, y, and z.
Maybe I'm missing something really obvious here? I don't understand what
you mean by "assigned an rgb color". How could I make a function return
an rgb colour?
I want to plot my data such that the colour of each point is defined by:
r=x
g=y
b=z
Now as I understand it, rgb(some colour specifier) is the gnuplot way of
specifying an arbitrary colour as in:
plot sin(x) lc rgb("salmon")
or
plot sin(x) lc rgb("#123456")
now clearly the colorspec should support colours specified as three
colour components, as in:
plot sin(x) lc rgb(0.1, 0.2, 0.3)
although I realise it doesn't.
So to me, one of:
splot "data" using 1:2:3 lc rgb(x,y,z)
or
splot "data" using 1:2:3:(rgb($1,$2,$3)) lc variable
or some other variant should work.
To make it easy, I have calculated the hex colour value in my data file
(column 5), and am willing to accept that there maybe some way to write
a function which does some kind of string concatenation magic to acheive
the same. Whatever.
Specifically what I'm trying to do is visualise the gamut of colours
used in an image file, such as a photo. I used Imagemagick to quantise
the number of discrete colours down to a more manageable level, and then
for each unique colour count how many pixels are of each colour.
I then want to visualise this in 3D by plotting a point at
(x,y,z)=(r,g,b) with pointsize log(count) and colour (r,g,b)=(r,g,b)
err... I'm not sure how else to explain.
Rob
--
Robert Hart <en...@no...>
University of Nottingham
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-16 18:15:45
|
On Tuesday 16 August 2005 10:46 am, Robert Hart wrote:
> On Tue, 2005-08-16 at 10:06 -0700, Ethan Merritt wrote:
> > On Tuesday 16 August 2005 09:58 am, Robert Hart wrote:
> > > On Tue, 2005-08-16 at 09:26 -0700, Ethan Merritt wrote:
> > >
> > > > That works, or would if you put parens around the expression:
> > > > set pm3d
> > > > splot "data" using 1:2:3:(rgb($1,$2,$3)) with lines
> > > >
> > >
> > > Are you sure? This just gives: undefined function rgb.
> >
> > I assumed that "rgb" was a user-defined function that assigned
> > an rgb color on the basis of 3D coords x, y, and z.
>
> Maybe I'm missing something really obvious here? I don't understand what
> you mean by "assigned an rgb color". How could I make a function return
> an rgb colour?
One way is to define a palette that maps [0:1] onto the "hue" parameter
of a color wheel. See the demo "colorwheel.dem".
> I want to plot my data such that the colour of each point is defined by:
> r=x
> g=y
> b=z
>
> Now as I understand it, rgb(some colour specifier) is the gnuplot way of
> specifying an arbitrary colour as in:
>
> plot sin(x) lc rgb("salmon")
No, there is no such function currently.
Instead there is a keyword "rgb" that controls the parsing of the
next token on the line.
I'd have to think about whether there is a straight-forward way
to implement the notion "rgb triplet generated by function and
then assigned to linecolor". It may be possible, but I don't
off the top of my head see how it would fit into the current
scheme. Which is to say, it may be a nightmare to implement
even if it's a good idea from the perspective of user interface.
> Specifically what I'm trying to do is visualise the gamut of colours
> used in an image file, such as a photo. I used Imagemagick to quantise
> the number of discrete colours down to a more manageable level, and then
> for each unique colour count how many pixels are of each colour.
>
> I then want to visualise this in 3D by plotting a point at
> (x,y,z)=(r,g,b) with pointsize log(count) and colour (r,g,b)=(r,g,b)
>
> err... I'm not sure how else to explain.
If you have a specific set of discrete colors, then I think what you
need to do for perfect accuracty is to define a discrete palette that
consists of exactly these colors. Let's say you discretize to 128
colors, and define a palette of size 128. Then you can specify your
point colors by choosing directly from this palette:
rgb(x,y,z) = some-function-that-generates-the-palette-index
plot <foo> using 1:2:3:(rgb($1,$2,$3)) lt palette
I don't claim that this is particularly convenient, but it may be
the best you can do using the current code.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Theo H. <th...@ph...> - 2005-08-16 19:04:03
|
Ethan Merritt wrote:
> I'd have to think about whether there is a straight-forward way
> to implement the notion "rgb triplet generated by function and
> then assigned to linecolor". It may be possible, but I don't
> off the top of my head see how it would fit into the current
> scheme. Which is to say, it may be a nightmare to implement
> even if it's a good idea from the perspective of user interface.
It seems to me Rob wants something like the `rgbimage` plotting style,
where x,y,z and r,g,b are specified independently, but not limited to a
rectangular sampling grid.
> If you have a specific set of discrete colors, then I think what you
> need to do for perfect accuracty is to define a discrete palette that
> consists of exactly these colors. Let's say you discretize to 128
> colors, and define a palette of size 128. Then you can specify your
> point colors by choosing directly from this palette:
>
> rgb(x,y,z) = some-function-that-generates-the-palette-index
>
> plot <foo> using 1:2:3:(rgb($1,$2,$3)) lt palette
`set palette functions` would work well here. The following assumes 8
bits for each component, but can be modified to handle more. It also
assumes that the r,g,b components are specified in the data file as
integers from 0--255.
rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
r(gray)=int(2.**24*gray)/65536/256.
g(gray)=int(2.**24*gray)%65536/256/256.
b(gray)=int(2.**24*gray)%256/256.
set palette color model RGB functions r(gray),g(gray),b(gray)
set cbrange [0:2.**24-1]
unset colorbox
splot 'colour-data.txt' using 1:2:3:(log($4)) \
with points pointtype 6 pointsize variable lc("black"), \
'' using 1:2:3:(rgb($1,$2,$3)) \
with points pointtype 7 palette
The point types are chosen to give hollow and filled circles
respectively on the x11 terminal. Unfortunately it does not seem to be
possible to have varying point sizes _and_ colours set independently of
the z value.
THeo
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-16 19:30:06
|
On Tuesday 16 August 2005 12:04 pm, Theo Hopman wrote: > Unfortunately it does not seem to be > possible to have varying point sizes _and_ colours set independently of > the z value. It is possible. That was the example I posted earlier. The colour is taken from the 4th 'using' spec; the size is taken from the 5th spec. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Robert H. <en...@no...> - 2005-08-17 13:33:22
|
> rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
> r(gray)=int(2.**24*gray)/65536/256.
> g(gray)=int(2.**24*gray)%65536/256/256.
> b(gray)=int(2.**24*gray)%256/256.
> set palette color model RGB functions r(gray),g(gray),b(gray)
> set cbrange [0:2.**24-1]
> unset colorbox
> splot 'colour-data.txt' using 1:2:3:(log($4)) \
> with points pointtype 6 pointsize variable lc("black"), \
> '' using 1:2:3:(rgb($1,$2,$3)) \
> with points pointtype 7 palette
Wow, that's pretty neat. I'm impressed.
> The point types are chosen to give hollow and filled circles
> respectively on the x11 terminal. Unfortunately it does not seem to be
> possible to have varying point sizes _and_ colours set independently of
> the z value.
No, Ethan is right on this one. Something like:
splot 'tmp.txt' using 1:2:3:(log($4)):(rgb($1,$2,$3)) \
with points pointtype 7 pointsize variable palette
works a treat.
If only gnuplot did a depth sort on the data before plotting it....
Rob
--
Robert Hart <en...@no...>
University of Nottingham
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.
|
|
From: Theo H. <th...@ph...> - 2005-08-17 14:04:19
|
Theo Hopman wrote:
> `set palette functions` would work well here. The following assumes 8
> bits for each component, but can be modified to handle more. It also
> assumes that the r,g,b components are specified in the data file as
> integers from 0--255.
>
> rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
> r(gray)=int(2.**24*gray)/65536/256.
> g(gray)=int(2.**24*gray)%65536/256/256.
> b(gray)=int(2.**24*gray)%256/256.
> set palette color model RGB functions r(gray),g(gray),b(gray)
> set cbrange [0:2.**24-1]
> unset colorbox
> splot 'colour-data.txt' using 1:2:3:(log($4)) \
> with points pointtype 6 pointsize variable lc("black"), \
> '' using 1:2:3:(rgb($1,$2,$3)) \
> with points pointtype 7 palette
Grr. This works in theory, but not in practise, and the (wrong) results
are different on different terminals. I suspect that the rapidly varying
rgb() function is being sampled at a relatively low frequency to get a
limited set of grey values. The binning of the rgb() values causes wrong
(encoded) gravy values to be given to the r(), g() and b() functions,
resulting in incorrect colours -- red is almost right, but green is
wrong, and is useless.
THeo
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-08-17 16:28:38
|
On Wednesday 17 August 2005 07:04 am, Theo Hopman wrote:
> >
> > rgb(r,g,b)=int(r*65536)+int(g*256)+int(b)
> > r(gray)=int(2.**24*gray)/65536/256.
> > g(gray)=int(2.**24*gray)%65536/256/256.
> > b(gray)=int(2.**24*gray)%256/256.
> > set palette color model RGB functions r(gray),g(gray),b(gray)
> > set cbrange [0:2.**24-1]
> > unset colorbox
> > splot 'colour-data.txt' using 1:2:3:(log($4)) \
> > with points pointtype 6 pointsize variable lc("black"), \
> > '' using 1:2:3:(rgb($1,$2,$3)) \
> > with points pointtype 7 palette
>
> Grr. This works in theory, but not in practise, and the (wrong) results
> are different on different terminals. I suspect that the rapidly varying
> rgb() function is being sampled at a relatively low frequency to get a
> limited set of grey values. The binning of the rgb() values causes wrong
> (encoded) gravy values to be given to the r(), g() and b() functions,
> resulting in incorrect colours -- red is almost right, but green is
> wrong, and is useless.
I would need to see what you tried in more detail, but I would guess
another issue may arise here - that of "nearest color" approximations
done by the output devices or libraries themselves, and hence not really
under our control.
Could you try your test case for these two output settings:
set term png
set term png truecolor
and see if it makes a difference?
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Theo H. <th...@ph...> - 2005-08-17 17:09:35
|
Ethan Merritt wrote: > I would need to see what you tried in more detail, but I would guess > another issue may arise here - that of "nearest color" approximations > done by the output devices or libraries themselves, and hence not really > under our control. > > Could you try your test case for these two output settings: > > set term png > set term png truecolor > > and see if it makes a difference? Done. See the attached files. Notice the truecolor option gives almost correct results, except for the glaringly obvious red dot which should be white. The non-truecolor option gives erroneous results, which I don't think are related to "nearest colour" approximations: for small values of (x,y,z) = (r,g,b) we should be getting dark dots, not relatively bright green and blue ones, even if a nearest colour was being used. As `set term png` says, it's only using 157 palette positions for the colourbox. The green channel goes through 256 oscillations over the cbrange, so the palette sampling is almost certain not to give the desired results. Blue doesn't even bear thinking about. Other paletted terminals (postscript, x11) give similar undesirable results. I can conceive of a possible workaround: rather than encoding colours as rrrrrrrrggggggggbbbbbbbb, they could be encoded as something like grbgrbgrbgrbgrbgrbgrbgrb, so that the MSBs of the green and blue channels are not lost in palette sampling. I'll give this a shot sometime. THeo |
|
From: Theo H. <th...@ph...> - 2005-08-18 19:28:51
|
Theo Hopman wrote:
> I can conceive of a possible workaround: rather than encoding colours as
> rrrrrrrrggggggggbbbbbbbb, they could be encoded as something like
> grbgrbgrbgrbgrbgrbgrbgrb, so that the MSBs of the green and blue
> channels are not lost in palette sampling. I'll give this a shot sometime.
Meh...this doesn't work as well as I think it should. The various
paletted terminals agree better now, but the colours are still wrong,
though not as disastrously as before. Oddly, the truecolour png terminal
no longer gives results as good as before. Perhaps there's some flaw in
my encoding/decoding logic, but I can't see it, as is usually the case
with logic flaws. Also, some of the dots are drawn as open circles,
rather than filled. What the deal with that?
encode(c,n)=(n==1 ? (int(c)&1) : ((int(c)&1) + 8*encode(int(c)/2,n-1)) )
decode(c,n)=(n==1 ? (int(c)&1) : ((int(c)&1) + 2*decode(int(c)/8,n-1)) )
# The encode() and decode() functions use recursion to iterate over n
# bits. encode() replaces each bit with either 000 or 001; decode() does
# the reverse.
# e.g. encode(7,8) == 73 == 001 001 001
# encode(4,8) == 64 == 001 000 000
# encode(128,8) == 2097152
# encode(255,8) == 2396745 == 2^21 + 2^18 + 2^15 + ... + 2^0
# encode(256,8) == 0
rgb(r,g,b)=4*encode(g,8)+2*encode(r,8)+encode(b,8)
red(gray)=decode(int(gray*2**24)/2,8)/256.
green(gray)=decode(int(gray*2**24)/4,8)/256.
blue(gray)=decode(int(gray*2**24),8)/256.
set palette color model RGB functions red(gray), green(gray), blue(gray)
set cbrange [0:2**24-1]
unset colorbox
set ticslevel 0
splot 'colour-data.txt' using 1:2:3:(log($4)):(rgb($1,$2,$3)) \
with points pointtype 7 pointsize variable palette
THeo
|
