Plotting into table with multiple columns
Ingo Thies
maybe this has been discussed earlier, but I coulnd not find a thread
about this.
I want to redirect a plot into a table but such that all data are
plotted as separate columns. I.e. consider, let's say, a number of
functions f1 to fn, and the table should look like this
col1 col2 col3 ... coln+1
x f1(x) f2(x) ... fn(x)
(replace in mind these labels with the corresponding values)
Currently, gnuplot writes them in blocks one after the other. I know
that one can plot up to three columns using parametric mode and splot to
table (this has been discussed here already, AFAIR), but unfortunately,
I need four columns...
Is it possible to use a print statement inside a for-loop? This would
solve the problem. I could, of course, do this in an external program,
but it would be nice and elegant to do this in the same gp script
without invoking external self-written software.
Thanks in advance!
Ingo
Hans-Bernhard Bröker
> I want to redirect a plot into a table but such that all data are
> plotted as separate columns. I.e. consider, let's say, a number of
> functions f1 to fn, and the table should look like this
>
> col1 col2 col3 ... coln+1
> x f1(x) f2(x) ... fn(x)
>
> (replace in mind these labels with the corresponding values)
There's a huge problem with that idea. There's no particular reason
every dataset should have the same number of samples, much less the same
x positions. Please keep in mind that functions in gnuplot are,
effectively, just internal datafile generators.
> Is it possible to use a print statement inside a for-loop?
As soon as gnuplot actually gets for loops around commands: sure. So
far that hasn't been done, though. What you get know are loop
constructions _inside_ the plot command, which are an entirely different
thing.
In the end, you're making the opposite of a very common mistake. Many
people out there abuse spreadsheets as plotting programs. You appear to
be trying to abuse gnuplot as a spreadsheet.
Ingo Thies
> There's a huge problem with that idea. There's no particular reason
> every dataset should have the same number of samples, much less the same
> x positions. Please keep in mind that functions in gnuplot are,
> effectively, just internal datafile generators.
Well, I don't see the problem, rather I do indeed see a huge particular
reason why the datasets should have equal dimensions and x positions in
almost all relevant cases: Using a single plot/splot command in the
table mode already implies equal samples number for all plotted
functions since it is defined by a single "set samples" command before.
Furthermore, a single plot/splot command is usually preceded by a single
xrange definition.
In contrast, I currently do not see any possibility (nor the necessity)
to change the number of samples during a plot. For subsequent plot
commands (e.g. with replot) the sequential block structure is, of
course, useful (although I would prefer to use separate table files
instead).
Unequal xranges may occur of one lets gnuplot autoscale the x range for
all functions individually (I've not tested whether this is possible),
but in that case sequential blocks as fall-back option are OK.
We are talking here about tabulated data from functions, not from
reading existing data files.
> As soon as gnuplot actually gets for loops around commands: sure. So far
A have found a workaround, although this introduces a separate gnuplot
file: The data are plotted in a iteratetly reread file using print
sprintf(...).
> In the end, you're making the opposite of a very common mistake. Many
> people out there abuse spreadsheets as plotting programs. You appear to
> be trying to abuse gnuplot as a spreadsheet.
Here, the reason is to have an easy way to write out data from gnuplot
to give the user the possibility to use them by another software. Of
course, the same could also be done by a separate program, but doing it
"on the fly" while printing is, in my opionion, more elegant.
--
Gruß,
Ingo
sfeam
> Hi all,
>
> maybe this has been discussed earlier, but I coulnd not find a thread
> about this.
>
> I want to redirect a plot into a table but such that all data are
> plotted as separate columns. I.e. consider, let's say, a number of
> functions f1 to fn, and the table should look like this
>
> col1 col2 col3 ... coln+1
> x f1(x) f2(x) ... fn(x)
>
> (replace in mind these labels with the corresponding values)
>
> Currently, gnuplot writes them in blocks one after the other. I know
> that one can plot up to three columns using parametric mode and splot
> to table (this has been discussed here already, AFAIR), but
> unfortunately, I need four columns...
>
> Is it possible to use a print statement inside a for-loop? This would
> solve the problem.
Not in version 4.4.
Yes in version 4.5:
increment = whatever
x = start
do for [i=1:N] {
print f1(x), f2(x), f3(x), f4(x), ...
x = x + increment
Ingo Thies
>> Is it possible to use a print statement inside a for-loop? This would
>> solve the problem.
>
> Not in version 4.4.
> Yes in version 4.5:
[...]
Thanks, I didn't yet notice this option (seems to a very recent
addition; I should update my gnuplot.pdf).
However, for compatibility reasons (colleagues should be able to make
use of it without the need of a local CVS build) I have decided in
favour of the reread command, although this requires a separate script
file.
Actually, it is an implementation of the cube helix colour scheme
described by David A. Green recently: http://arxiv.org/abs/1108.5083
Instead of using Green's FORTRAN77 code I am doing everything in
gnuplot: http://www.astro.uni-bonn.de/~ithies/gnuplot/colortools/
(cubehelix.gp and related scripts). One of these scripts exports the
generated RGB palette for independent use (however, not required for
everyday use).
--
Gruß,
Ingo
Christoph Bersch
>
> Actually, it is an implementation of the cube helix colour scheme
> described by David A. Green recently: http://arxiv.org/abs/1108.5083
>
> Instead of using Green's FORTRAN77 code I am doing everything in
> gnuplot: http://www.astro.uni-bonn.de/~ithies/gnuplot/colortools/
> (cubehelix.gp and related scripts). One of these scripts exports the
> generated RGB palette for independent use (however, not required for
> everyday use).
Thank you for sharing this, I've been looking for quiet some time for a
similar colormap.
Christoph
eame...@gmail.com
> Actually, it is an implementation of the cube helix colour scheme
> described by David A. Green recently:http://arxiv.org/abs/1108.5083
>
> (cubehelix.gp and related scripts). One of these scripts exports the
> generated RGB palette for independent use (however, not required for
> everyday use).
Ingo:
Since that looks so nice, I've created a patchset that adds the
specific color scheme
used in the Green document to the list of rgbformulae. That is, you
can select it using
set palette rgbformula 37,38,39
This doesn't approach the flexibility of your general case code, since
it uses fixed
values for zero-point, saturation, gamma, etc. But it does allow easy
selection and
this mechanism benefits PostScript output by pushing the grey->rgb
conversion into
the PostScript code itself, reducing file size. The patchset is here:
https://sourceforge.net/tracker/?func=detail&aid=3412688&group_id=2055&atid=302055
However, the example you posted earlier used different coefficients
than the
ones used in Green's example. From your experience, do you recommend
making
this or some other change? Would it be worth taking a step back and
making
"cubehelix" a separate palette option with its own set of defining
parameters?
The general case would be easy enough to implement, but it would not
produce
size-optimized PostScript output like the rgbformulae option. On the
other hand,
so far as I know PostScript is the only output mode for which
providing an
rgbformulae yields a size advantage.
Ethan
Ingo Thies
sorry for the late reply. I had been too busy recently for having a
frequent look into the group (and thus, unfortunately, did not yet check
the patch or the recent addition to CVS, but I will :-)).
But thank you so far for implementing this (and thank's to Dave Green
for inventing this method)!
On 2011-09-22 01:43, EAMe...@gmail.com wrote:
> However, the example you posted earlier used different coefficients
> than the
> ones used in Green's example. From your experience, do you recommend
> making
> this or some other change? Would it be worth taking a step back and
> making
> "cubehelix" a separate palette option with its own set of defining
> parameters?
I can give more specific answers after having tested the recent addition
to the CVS version. In general, I have understood Dave Green's paper and
web page so that "cubehelix" refers to the whole method, while he
repeatedly used the specific color scheme as an example.
In my case, I have used others more frequently (also a modification that
uses the L*a*b* space (CIE 1976) rather than RGB directly (formulae are
taken from Wikipedia; I haven't made a Gnuplot script yet, only a
Fortran program that outputs ready-for-use palette files; "colorhelix"
on my gnuplot colortools page). However, both methods have their pro's
and con's.
> The general case would be easy enough to implement, but it would not
> produce
> size-optimized PostScript output like the rgbformulae option. On the
> other hand,
> so far as I know PostScript is the only output mode for which
> providing an
> rgbformulae yields a size advantage.
Another issue I will test asap is the speed of calculating the color
scheme. For example, I have dropped using my cubehelix gnuplot script
directly in favor of using the RGB output palettes for SPH
visualisation, because their the usage of function-defined palettes (in
particular, set palette function; i didn't check with rgbformulae yet)
makes the rendering process take several times longer. But that might be
a consequence of the user-defined function parsing and might be faster
with built-in formulae.
Greetings,
Ingo
Ingo Thies
I have made a first test - looks good, well done!
I am only wondering why the gamma correction seems to have the opposite
effect: gamma>1 makes dark regions appear brighter while the same
happens for gamma<1 in mine/Davids code. So in gnuplot gamma=1.5
corresponds to gamma=0.6666.... in the original cubehelix.
According to http://en.wikipedia.org/wiki/Gamma_correction I would say
that mine interpretation is correct (see the example photograph of the
lady in the water). But the Wikipedia article might be wrong as well.
Greetings,
Ingo
sfeam
> Hi Ethan,
>
> I have made a first test - looks good, well done!
>
> I am only wondering why the gamma correction seems to have the
> opposite effect: gamma>1 makes dark regions appear brighter
This is indeed the convention used by every program I know of.
Here, for instance, is the relevant section from the ImageMagick
documentation:
"The same color image displayed on two different workstations may
look different due to differences in the display monitor. Use gamma
correction to adjust for this color difference. Reasonable values
extend from 0.8 to 2.3. Gamma less than 1.0 darkens the image and
gamma greater than 1.0 lightens it."
And here is what Photoshop says:
"Increase the gamma value or drag the gray slider to the left to
lighten the medium grays [...] Lower the gamma value to darken the
medium grays."
If you have ImageMagick (or Gimp, Photoshop, etc) installed, you can see
this very easily:
display image.png
display -gamma 2 image.png
display -gamma 0.5 image.png
For that matter, you can see it in gnuplot itself using
set palette gray gamma 1.0
test palette
set palette gray gamma 2.0
test palette
etc
> while the same happens for gamma<1 in mine/Davids code.
That is backwards from what everyone else does :-)
> According to http://en.wikipedia.org/wiki/Gamma_correction I would say
> that mine interpretation is correct (see the example photograph of the
> lady in the water). But the Wikipedia article might be wrong as well.
The Wikipedia article is very confusing as it does not, that I can see,
define the basic quantity V used in the fundamental equation given
at the top of the article:
Vout = Vin ** gamma
For any quantity V that increases with brightness (e.g. amplitude,
intensity, brightness) it is clear that gamma > 1 increases brightness.
And yes, it seems to me that the images on the Wikipedia page are
mis-described.
I am not certain, but I suspect the source of confusion is that CRT
performance is also described using a gamma term, and this description
is in some sense the inverse of what you do to the image. I.e., a
CRT with gamma = 2.0 looks dark. To make the displayed image look
"correct" you have to brighten it with a gamma correction of 2.0
The Wikipedia article calls this an "inverse gamma correction",
which may well be the correct jargon in some fields. But that
correction is what all programs I am familiar with apply as a
"gamma correction". Certainly it is what gnuplot has always done.
cheers,
Ethan
> Greetings,
>
> Ingo
sfeam
>
>> According to http://en.wikipedia.org/wiki/Gamma_correction I would
>> say that mine interpretation is correct (see the example photograph
>> of the lady in the water). But the Wikipedia article might be wrong
>> as well.
>
> The Wikipedia article is very confusing as it does not, that I can
> see, define the basic quantity V used in the fundamental equation
> given at the top of the article:
>
> Vout = Vin ** gamma
>
> For any quantity V that increases with brightness (e.g. amplitude,
> intensity, brightness) it is clear that gamma > 1 increases
> brightness. And yes, it seems to me that the images on the Wikipedia
> page are mis-described.
Upon re-reading, I now see that the Wikipedia article has lifted
that equation from the section on CRT voltage response. So in that
context V is a normalized voltage that runs from 0->1, and indeed
gamma>1 means that the image displayed by the CRT is darker than
would be the case for linear response. So the article is consistent
with itself, but still it conflates the gamma of the CRT with that
of the algorithm used in image processing to correct for it.
A CRT with gamma > 1 is dark, so in order to correct for this you
must brighten the image sent to it.
I believe that the caption for the images on that page should read
something like "This is the way the original image would appear if
displayed on various CRT monitors with gamma = XXX".
Ethan