Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.graphics.apps.gnuplot > #549 > unrolled thread

Plotting into table with multiple columns

Back to article view | Back to comp.graphics.apps.gnuplot

Contents

  Plotting into table with multiple columns Ingo Thies <ingo.thies@gmx.de> - 2011-08-27 11:24 +0200
    Re: Plotting into table with multiple columns Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2011-08-27 13:41 +0200
      Re: Plotting into table with multiple columns Ingo Thies <ingo.thies@gmx.de> - 2011-08-27 17:04 +0200
    Re: Plotting into table with multiple columns sfeam <sfeam@users.sourceforge.net> - 2011-08-27 22:56 -0700
      Re: Plotting into table with multiple columns Ingo Thies <ingo.thies@gmx.de> - 2011-08-28 12:59 +0200
        Re: Plotting into table with multiple columns Christoph Bersch <usenet@bersch.net> - 2011-09-02 10:23 +0200
        Re: Plotting into table with multiple columns "EAMerritt@gmail.com" <eamerritt@gmail.com> - 2011-09-21 16:43 -0700
          Re: Plotting into table with multiple columns Ingo Thies <ingo.thies@gmx.de> - 2011-10-08 13:16 +0200
          set palette cubehelix Ingo Thies <ingo.thies@gmx.de> - 2011-10-08 13:55 +0200
            Re: set palette cubehelix sfeam <sfeam@users.sourceforge.net> - 2011-10-08 10:48 -0700
              Re: set palette cubehelix sfeam <sfeam@users.sourceforge.net> - 2011-10-08 14:30 -0700

#549 — Plotting into table with multiple columns

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

[toc] | [next] | [standalone]

#550

On 27.08.2011 11:24, Ingo Thies wrote:

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

[toc] | [prev] | [next] | [standalone]

#551

Am 2011-08-27 13:41, schrieb Hans-Bernhard Bröker:

> 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

[toc] | [prev] | [next] | [standalone]

#552

Ingo Thies wrote:

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



> 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

[toc] | [prev] | [next] | [standalone]

#553

Hi,

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

[toc] | [prev] | [next] | [standalone]

#564

On 28.08.2011 12:59, Ingo Thies wrote:
>
> 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

[toc] | [prev] | [next] | [standalone]

#591

On Aug 28, 3:59 am, Ingo Thies <ingo.th...@gmx.de> wrote:
> 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 ingnuplot: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).

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

[toc] | [prev] | [next] | [standalone]

#638

Hi Ethan,

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, EAMerritt@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

[toc] | [prev] | [next] | [standalone]

#639 — set palette cubehelix

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

[toc] | [prev] | [next] | [standalone]

#640 — Re: set palette cubehelix

Ingo Thies wrote:

> 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

[toc] | [prev] | [next] | [standalone]

#641 — Re: set palette cubehelix

sfeam wrote:
> 
>> 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


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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.graphics.apps.gnuplot

csiph-web