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

Re: Working...

[Justace C. <pro...@co...>]

Ok,

	So this might not be a question for this list but here goes.  I have
used the set palette defined to (1 "red", 2 "white", 3 "blue") and that
shows the data greatly.  And I set cbrange to [-1:1].  Now all the -2
values are set to bright red, as they should be.  Is there a syntax
where I can say I want to interpolate the colors  between like -1 and 0
as red to white, between 0 and 1 interpolate between white and blue and
all colors from -1 and down go to black?  I am sure there is a way to do
this, without makeing a huge color xref file.  The help documentation
for the set palette is kinda confusing.  Thanks for the help.

Justace

On Fri, 2004-03-05 at 10:21, Petr Mikulik wrote:
> > region with NaN, but how do I put that in gnuplot so that it does not
> > plot it?  I was putting it in as a -2 and then telling it to only plot
> > [-1:1] on the z but that was silly since it is a 2D plot.  Maybe the
> > image style needs to have an internal variable that the user can set to
> > define NaN's.  That way I could go and set that to -2 and when image
> > converts the float to a color it goes ohhh this is a NaN, what fill
> > style should I use here or what predefined color do I have for NaN.
> 
> You generate a discrete palette (palette can be red from a file), set the
> first color to white, and then apply a filter so that the invisible range is
> mapped to white, and the rest to the remaining palette entries. I do it this
> way from Octave.
> 
> How to do it more easily (in future)? "With image", colors of all pixels
> have to be defined. So there would have to be "set palette backgroundcolor",
> and "with image" would have to accept the "set zrange" window. Or the
> background colour could be that of linetype e.g. -2?
> 
> ---
> Petr Mikulik
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Postscript and PM3D file size.

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

Roger Fearick wrote:

>On Thu, 4 Mar 2004, Daniel J Sebald wrote:
>  
>
>>Petr Mikulik wrote:
>>
>>    
>>
>>>>So anyway, why doesn't Gnuplot have a mascot?  :)
>>>>   
>>>>
>>>>        
>>>>
>>>That's why I've put on the new web page "Screenshots" section that icon with
>>>a bug (icon used on OS/2 -- what the icon on other OSes?). Isn't that a
>>>mascot? Who drew it?
>>>
>>>      
>>>
>>What?!  Gnuplot's mascot is a bug?  I don't think that is a good idea...  :)
>>
>>It does look like a bug (a black widow spider... with four legs), but I 
>>think it is supposed to be  the face of a gnu amidst a rectangle 
>>representing a plot, i.e., gnu-plot.
>>
>>Dan
>>    
>>
>
>I drew it.
>It is meant to be the face of a gnu superimposed on a plot.
>It was based on a careful study of the small herd of black
>wildebeest in a field on the lower mountain slopes about
>a kilometre from here.
>On the other hand, I don't claim to be an artist.
>Roger.
>

Oh really?  You're from Cape Town.  Fascinating...  Out of curiousity, a 
search turns up the following:  (The first picture looks surprisingly 
like the icon.  What's odd is that there seems to be quite a variation 
in the direction of the horns.)

http://www.seaworld.org/AnimalBytes/wildebeestab.html
http://www.seaworld.org/animal-info/animal-bytes/animalia/eumetazoa/coelomates/deuterostomes/chordates/craniata/mammalia/artiodactyla/eastern-white-bearded-wildebeest.htm
http://www.m-w.com/mw/art/gnu.htm
http://www.gnuworld.com/gnus
http://www.onime.com/Africa/herbivores/antilope/whitebeardedgnu.html

Re: Working...

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

Justace Clutter wrote:

>Cool,
>
>	My stuff is almost working and with the image patch much faster.  The
>new deal is this.  Since I am generating a correlation matrix with
>respect to one set of channels, i.e.  the channels correlated with
>themselves, half of the matrix is useless.  Specifically the upper left
>of the diagonal.  So, to cut back on my calculation time I fill that
>region with NaN, but how do I put that in gnuplot so that it does not
>plot it?  I was putting it in as a -2 and then telling it to only plot
>[-1:1] on the z but that was silly since it is a 2D plot.  Maybe the
>image style needs to have an internal variable that the user can set to
>define NaN's.  That way I could go and set that to -2 and when image
>converts the float to a color it goes ohhh this is a NaN, what fill
>style should I use here or what predefined color do I have for NaN. 
>Just some thoughts and questions here.
>

For your correlation matrix, you might want to simply replicate the 
other half since it is probably Hermitian symmetric, of if you are 
working with real signals, outright symmetric.  In any case, your idea 
of mapping to a certain value might work.  It may cause a problem with 
automatic scaling of the color axis.  However, you should be able to 
manually set the color axis so that your "NaN" number gets mapped to 
white.  For example, set the color map some how to [-1:1] and then make 
your "NaN" be a +2  (Or -2, whichever gets mapped to the white value.)

Dan

Re: Working...

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

> region with NaN, but how do I put that in gnuplot so that it does not
> plot it?  I was putting it in as a -2 and then telling it to only plot
> [-1:1] on the z but that was silly since it is a 2D plot.  Maybe the
> image style needs to have an internal variable that the user can set to
> define NaN's.  That way I could go and set that to -2 and when image
> converts the float to a color it goes ohhh this is a NaN, what fill
> style should I use here or what predefined color do I have for NaN.

You generate a discrete palette (palette can be red from a file), set the
first color to white, and then apply a filter so that the invisible range is
mapped to white, and the rest to the remaining palette entries. I do it this
way from Octave.

How to do it more easily (in future)? "With image", colors of all pixels
have to be defined. So there would have to be "set palette backgroundcolor",
and "with image" would have to accept the "set zrange" window. Or the
background colour could be that of linetype e.g. -2?

---
Petr Mikulik

Working...

[Justace C. <pro...@co...>]

Cool,

	My stuff is almost working and with the image patch much faster.  The
new deal is this.  Since I am generating a correlation matrix with
respect to one set of channels, i.e.  the channels correlated with
themselves, half of the matrix is useless.  Specifically the upper left
of the diagonal.  So, to cut back on my calculation time I fill that
region with NaN, but how do I put that in gnuplot so that it does not
plot it?  I was putting it in as a -2 and then telling it to only plot
[-1:1] on the z but that was silly since it is a 2D plot.  Maybe the
image style needs to have an internal variable that the user can set to
define NaN's.  That way I could go and set that to -2 and when image
converts the float to a color it goes ohhh this is a NaN, what fill
style should I use here or what predefined color do I have for NaN. 
Just some thoughts and questions here.

Justace

Re: Postscript and PM3D file size.

[Hans-Bernhard B. <br...@ph...>]

On Thu, 4 Mar 2004, Petr Mikulik wrote:

> That's why I've put on the new web page "Screenshots" section that icon with
> a bug (icon used on OS/2 -- what the icon on other OSes?). Isn't that a
> mascot? Who drew it?

Hmm... The windows version doesn't use that icon.  It has it's own pair of
icons, one for the main (text) window, another for the graph. See
gnuplot/src/win/*.ico.  I guess it might be a good idea to use the same
icon on all platforms that use icons, i.e. Windows, OS/2 and (I guess)
MacOS.  

X11 only uses icons in the contexts of KDE or Gnome, AFAIK, and I'm not
sure it's possible or easy to export an icon without making gnuplot_x11
dependant on either Gtk or Qt.  Any experts know better?

OTOH, an icon isn't quite the same as a mascot.  That'd have to be more
along the lines of the BSD daemon, Tux the Linux penguin, or Mozilla's
lizard.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

tutorial/tutorial.tex

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

I've slightly modified the $Subj. The changes are not yet in cvs, but rather
at
	http://gnuplot.sourceforge.net/help.html
saying

LaTeX and the gnuplot plotting program (in postscript; and in pdf) by David
Klotz. This tutorial, bundled with gnuplot sources, was written in 1991 for
gnuplot version 3.0. It was slightly updated by the gnuplot team for gnuplot
4.0 in March 2004.

Can you please comment on the changes -- I'd like to submit it so that this
tutorial does not look "no more maintained" -- but maybe someone would like
to add some more text in it.


Also, there is a "gpcard.tex" there, a on the web link to "gnuplot 3.4 Quick
Reference by Burkhard Kirste" -- would someone like to proof-read it and
update?

---
Petr Mikulik

Re: Postscript and PM3D file size.

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

> I drew it.
> It is meant to be the face of a gnu superimposed on a plot.
> It was based on a careful study of the small herd of black
> wildebeest in a field on the lower mountain slopes about
> a kilometre from here.

Well, your explanation is nice and I'll put it along to the icon on the web.
Don't you have a photo that could accompany this text?

However -- shouldn't wildebeest have the whole head black?

---
Petr Mikulik

Re: French links

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

> The three links to the French gnuplot pages are
> broken.

At which web page? At the new one, it is said there:

http://gnuplot.sourceforge.net/help.html

=>

Gnuplot pages in French - but no one is currently available:
N/A Traduction de la documentation de gnuplot
N/A Premiers Pas avec Gnuplot 3.5
N/A Le groupe Leonhard Euler


If you know some (more) working sites, please contribute.

---
PM

French links

[John B. <bb...@ya...>]

The three links to the French gnuplot pages are
broken.

     --jab

=====
John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.

__________________________________
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster
http://search.yahoo.com

Re: Postscript and PM3D file size.

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

Petr Mikulik wrote:

>>So anyway, why doesn't Gnuplot have a mascot?  :)
>>    
>>
>
>That's why I've put on the new web page "Screenshots" section that icon with
>a bug (icon used on OS/2 -- what the icon on other OSes?). Isn't that a
>mascot? Who drew it?
>

What?!  Gnuplot's mascot is a bug?  I don't think that is a good idea...  :)

It does look like a bug (a black widow spider... with four legs), but I 
think it is supposed to be  the face of a gnu amidst a rectangle 
representing a plot, i.e., gnu-plot.

Dan

Re: Postscript and PM3D file size.

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

> So anyway, why doesn't Gnuplot have a mascot?  :)

That's why I've put on the new web page "Screenshots" section that icon with
a bug (icon used on OS/2 -- what the icon on other OSes?). Isn't that a
mascot? Who drew it?

---
PM

Re: Postscript and PM3D file size.

[Hans-Bernhard B. <br...@ph...>]

On Thu, 4 Mar 2004, Daniel J Sebald wrote:

> Well, I guess water should actually "slosh", not "jostle".  So anyway, 
> why doesn't Gnuplot have a mascot?  :)

Simple: because no-one ever thought that we needed one badly enough to go
and make one. 

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Postscript and PM3D file size.

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

Hans-Bernhard Broeker wrote:

>On Thu, 4 Mar 2004, Daniel J Sebald wrote:
>
>[...]
>
>  
>
>>I must learn how to use this cscope.  (I've bookmarked the info page...  
>>hey, why the water jostling around in the magnifying glass guy's head?
>>Is he/she/it supposed to be half magnifying glass, half periscope, i.e.,
>>sea scope?)
>>    
>>
>
>I've no idea --- I didn't design the mascot, and the person who made it
>didn't leave an explanation of the intent.  But your guess appears quite
>likely to be true.
>

Well, I guess water should actually "slosh", not "jostle".  So anyway, 
why doesn't Gnuplot have a mascot?  :)

Dan

Re: Postscript and PM3D file size.

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

Hans-Bernhard Broeker wrote:

>On Wed, 3 Mar 2004, Daniel J Sebald wrote:
>  
>
>>Oh yeah, I forgot about "matrix".  The issue there is that "matrix" is 
>>designed for 3d data, i.e., splot.  (List members, if anything I say 
>>here is incorrect, please correct me.)  
>>    
>>
>
>I was going to about 'matrix', but you seemed to be progressing so nicely,
>I though I'ld let you you find that one yourself ;->
>
>  
>
>>There is a routine in "datafile.c" called df_3dmatrix.  I think it only
>>get's called from "plot3d.c".  
>>    
>>
>
>Don't just think, check it.  Tools like "cscope" will let you answer such
>queries almost in an instant:
>
>gnuplot/src> cscope -L0 df_3dmatrix
>datafile.h <global> 100 int df_3dmatrix __PROTO((struct surface_points *, int ));
>datafile.c df_3dmatrix 1268 df_3dmatrix(this_plot, need_palette)
>plot3d.c get_3ddata 652 xdatum = df_3dmatrix(this_plot, NEED_PALETTE(this_plot));
>
>You can even let it show you only the calls to a function:
>
>gnuplot/src> cscope -L3 df_3dmatrix
>plot3d.c get_3ddata 652 xdatum = df_3dmatrix(this_plot, NEED_PALETTE(this_plot));
>

I must learn how to use this cscope.  (I've bookmarked the info page... 
hey, why the water jostling around in the magnifying glass guy's head? 
 Is he/she/it supposed to be half magnifying glass, half periscope, 
i.e., sea scope?)

>>not the mode is "splot" or "plot".  In other words, if I'm not mistaken,
>>Gnuplot should not allow "matrix" to be used in "plot" mode.  
>>    
>>
>
>The current official version probably shouldn't, right.  So let's try...
>
>gnuplot> p 'using.dat' matrix u ($0):2:3 w e
>
>No error, no warning, and a rather stupid plot. How's that for a rather
>surprising undocumented feature?
>

Yes...  As a temporary fix for 4.0, the following placed near the start 
of the eval_plots() routine inside plot2d.c will rule out using 'matrix' 
option with 'splot'.  (Patch attached.)

    /* Temporary hack to rule out 'matrix' for 2d plots.  'matrix' is 
currently
       tested for inside df_open() which doesn't know the option currently
       can't be used with 'plot'.  This should be cleaned up post 4.0 
and this
       chunk of code tossed out. */
    while (!END_OF_COMMAND) {
    if (almost_equals(c_token, "mat$rix"))
        int_error(c_token, "option 'matrix' not supported for 2d plots");
    c_token++;
    }
    c_token = begin_token;

    /* ** First Pass: Read through data files ***

>>Actually, in the image patch, I modified things so that a mode variable 
>>is passed into that routine so it is possible to identify whether 
>>"splot" or "plot" was issued.  I probably needed that information for 
>>something else, but it could be used to rule out "matrix" when issued 
>>with "plot".  
>>    
>>
>
>But it should only be ruled out if that was not a 'plot with pixels',
>right?
>

Correct.

>>in previous discussions, that 2d and 3d formats have diverged in some 
>>ways.  
>>    
>>
>
>I suspect they have never started off a common ground in the first place.
>After looking at all the code for prolonged times, you get the impression
>3D must have been grafted onto an existing 2D-only plotting program as an
>afterthought.
>

Yes, that is my impression as well.

>>I think the "datafile.c" and related routines could be cleaned up 
>>a great deal, focusing more on just getting data from a file into 
>>Gnuplot and not so much on what the eventually plotting mode will look like.
>>    
>>
>
>Agreed.  After 4.0 is out, we could split datafile.c into two: datafile.c
>and "using.c".  The latter would be in charge of all the translation from
>data records into gnuplot "points", i.e. treat options 'using', 'every',
>'index' and 'smooth' (which really should be renamed to 'filter' some
>time).
>

That should be good.

>>Do developers here agree that, for large files, binary data in "plot" 
>>mode is preferable to ascii matrix?
>>    
>>
>
>Preferrable: yes.  But not so much so that it would be a strong argument
>against allowing 'matrix' at least in those 2D plots that really are 3D
>(i.e. "plot with image").
>
>I think we actually should allow 'matrix' for such plots.  It's about
>equally sensible as allowing binary files for 2D plots.'
>

Sure.  I think 'matrix' should be valid whenever appropriate.  If 
someone has a small set of data, fine.  And if they have a large set of 
data, fine too.  But I think it is just a better habit to work with 
compact data and not 20 M ASCII files.

Dan

Re: default tic label format

[Hans-Bernhard B. <br...@ph...>]

On Wed, 3 Mar 2004, Pieter-Tjerk de Boer wrote:

> Hello,
> 
> While trying the 3.8k.1 version of gnuplot, I noticed that the default
> format for the labels on the axis is "% g".
> This has two (minor) disadvantages, compared to simple "%g" as it was
> in version 3.7:

Note: it's '% g' there, too, as of 3.7 patchlevel 3.0.

> - labels on horizontal axes are not centered nicely (the invisible
>   leading space is included in the centering calculation).
> - labels on the y2 axis (if used) start farther away from the axis
>   than the y1 axis labels do.

But note that both of these affect only *positive* ticks.  To stick
with the y2 axis as the most visibly affected one, the choice we have,
for a symmetric axis range, is one of:

%g:
5
0
-5

% g:
 5
 0
-5

%+g:
+5
+0
-5

Looking at these, I think "% g" indeed looks better than %g or %+g would.

In the end, this really is one of the personal preference issue that
can't be solved by the program itself.  Such personal default adjustments 
is what you have ~/.gnuplot or gnuplot.ini for (depending on your 
platform).

> Obviously, I would suggest changing to "%g" before the release of 4.0.

For the record: I suggest we keep '% g'.


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Postscript and PM3D file size.

[Hans-Bernhard B. <br...@ph...>]

On Wed, 3 Mar 2004, Daniel J Sebald wrote:
> 
> Oh yeah, I forgot about "matrix".  The issue there is that "matrix" is 
> designed for 3d data, i.e., splot.  (List members, if anything I say 
> here is incorrect, please correct me.)  

I was going to about 'matrix', but you seemed to be progressing so nicely,
I though I'ld let you you find that one yourself ;->

> There is a routine in "datafile.c" called df_3dmatrix.  I think it only
> get's called from "plot3d.c".  

Don't just think, check it.  Tools like "cscope" will let you answer such
queries almost in an instant:

gnuplot/src> cscope -L0 df_3dmatrix
datafile.h <global> 100 int df_3dmatrix __PROTO((struct surface_points *, int ));
datafile.c df_3dmatrix 1268 df_3dmatrix(this_plot, need_palette)
plot3d.c get_3ddata 652 xdatum = df_3dmatrix(this_plot, NEED_PALETTE(this_plot));

You can even let it show you only the calls to a function:

gnuplot/src> cscope -L3 df_3dmatrix
plot3d.c get_3ddata 652 xdatum = df_3dmatrix(this_plot, NEED_PALETTE(this_plot));

> not the mode is "splot" or "plot".  In other words, if I'm not mistaken,
> Gnuplot should not allow "matrix" to be used in "plot" mode.  

The current official version probably shouldn't, right.  So let's try...

gnuplot> p 'using.dat' matrix u ($0):2:3 w e

No error, no warning, and a rather stupid plot. How's that for a rather
surprising undocumented feature?

> Actually, in the image patch, I modified things so that a mode variable 
> is passed into that routine so it is possible to identify whether 
> "splot" or "plot" was issued.  I probably needed that information for 
> something else, but it could be used to rule out "matrix" when issued 
> with "plot".  

But it should only be ruled out if that was not a 'plot with pixels',
right?

> in previous discussions, that 2d and 3d formats have diverged in some 
> ways.  

I suspect they have never started off a common ground in the first place.
After looking at all the code for prolonged times, you get the impression
3D must have been grafted onto an existing 2D-only plotting program as an
afterthought.

> I think the "datafile.c" and related routines could be cleaned up 
> a great deal, focusing more on just getting data from a file into 
> Gnuplot and not so much on what the eventually plotting mode will look like.

Agreed.  After 4.0 is out, we could split datafile.c into two: datafile.c
and "using.c".  The latter would be in charge of all the translation from
data records into gnuplot "points", i.e. treat options 'using', 'every',
'index' and 'smooth' (which really should be renamed to 'filter' some
time).

> Do developers here agree that, for large files, binary data in "plot" 
> mode is preferable to ascii matrix?

Preferrable: yes.  But not so much so that it would be a strong argument
against allowing 'matrix' at least in those 2D plots that really are 3D
(i.e. "plot with image").

I think we actually should allow 'matrix' for such plots.  It's about
equally sensible as allowing binary files for 2D plots.

But this really had better be delayed until after the 4.0 release. We
might want to put this into the "TODO" file, though.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Postscript and PM3D file size.

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

Justace Clutter wrote:

>I have been using this ASCII grid format for quite a while now.  That is
>the definition from the help pages for the matrix datafile format.  Am I
>wrong with this?
>

Oh yeah, I forgot about "matrix".  The issue there is that "matrix" is 
designed for 3d data, i.e., splot.  (List members, if anything I say 
here is incorrect, please correct me.)  There is a routine in 
"datafile.c" called df_3dmatrix.  I think it only get's called from 
"plot3d.c".  There is no way to call it from "plot2d.c".  Inside 
"datafile.c" where the word "matrix" is tested for there seems to be no 
test for whether or not the mode is "splot" or "plot".  In other words, 
if I'm not mistaken, Gnuplot should not allow "matrix" to be used in 
"plot" mode.  In the documentation for "matrix" there is reference to a 
mesh, so I assume there is an "splot" restriction.

Actually, in the image patch, I modified things so that a mode variable 
is passed into that routine so it is possible to identify whether 
"splot" or "plot" was issued.  I probably needed that information for 
something else, but it could be used to rule out "matrix" when issued 
with "plot".  Or, for that matter plot2d.c could be modified to allow 
data files in "matrix" format.  To you Justace, this is all probably 
neither here nor there.  But it gets back to a point I've tried to make 
in previous discussions, that 2d and 3d formats have diverged in some 
ways.  I think the "datafile.c" and related routines could be cleaned up 
a great deal, focusing more on just getting data from a file into 
Gnuplot and not so much on what the eventually plotting mode will look like.

Suffice it to say that "matrix" is currently being ignored in "plot" 
mode.  Sorry.  I suppose it would be possible to hack a quick fix 
together in the image patch (I'm not sure how much work it would take), 
but I'd prefer to not do that.  Instead, I think it would be better for 
the group to discuss how best to clean up the datafile routines post 
4.0, then make the change.  I say that because there is the alternative 
of binary data, and I think it is a better habit to work with binary 
data for large files.

Do developers here agree that, for large files, binary data in "plot" 
mode is preferable to ascii matrix?

Dan




>Justace
>
>On Wed, 2004-03-03 at 10:46, Daniel J Sebald wrote:
>  
>
>>Justace Clutter wrote:
>>
>>    
>>
>>>I like the idea of this pixels based image.  The fact that the image
>>>could be 10 megs does not bother me.
>>>
>>>      
>>>
>>Well, in my case my web space is only 10 M.
>>
>>    
>>
>>> It is the idea that an image could
>>>be 120 megs bothers me.  So I got the patch and applyed.  It did not go
>>>clean as one hunk did not make it.  But I fixed it by hand.  I was
>>>patching against 3.8k.1.  So, I guess that I do not understand the
>>>syntax.  Here is the datafile that I have, or really a sample:
>>>
>>>0.999849 0.652204 0.678995 0.658985 0.585981 0.566624 0.547193 0.615902
>>>0.539023 0.556559 0.547578 0.53746 0.522146 0.535582 0.530735 0.531924
>>>0.554801 0.518362 0.479106 0.527362 0.534836 0.546124 0.522834 0.508155
>>>0.54706 0.469279 0.581292 0.468283 0.535739 0.557979 0.490128 0.536971
>>>0.530735 0.506848 0.523189 0.531732 0.550917 0.484002 0.57789 0.460027
>>>0.556111 0.535427 0.508878 0.558746 0.459494 0.578337 0.45805 0.595234 
>>>
>>>So I have a grid here, 8x6, that I would like displayed.  Each of these
>>>floats would need to be mapped onto a color.  PM3D did this great.  So
>>>when I try to use the matrix modifier with just plot it is not happy,
>>>then I tried to use splot, still not happy.  Here is what I was trying..
>>>
>>>gnuplot> plot 'tmp.data' matrix with image
>>>
>>>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>>>
>>>Warning: empty x range [0.999849:0.999849], adjusting to
>>>[0.989851:1.00985]
>>>
>>>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>>>
>>>gnuplot> splot 'tmp.data' matrix with image
>>>
>>>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>>>
>>>gnuplot> set view map
>>>gnuplot> splot 'tmp.data' matrix with image
>>>
>>>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>>>
>>>gnuplot>
>>>
>>>Can you give me some ideas on how I can use the image style with this
>>>setup?  I looked at the information on the image but it seems pretty
>>>biased toward images like the tux and not array'd data.  Thanks in
>>>advance.
>>>
>>>      
>>>
>>Well, here is the issue.  You are putting the data in ASCII format in 
>>what looks to you like a grid.  However, Gnuplot hasn't been set up to 
>>read ASCII data in such a way.  It is set up to read ordered tuples of 
>>data, such as
>>
>>x1  y1  z1
>>x2  y2  z2
>>...
>>
>>where the position is part of the data specification.
>>
>>Telling Gnuplot what the underlying grid is without specifying it is the 
>>problem.  That is why the "binary" file specifications have extra 
>>qualifiers to indicate grid dimensions, grid spacing, etc.
>>
>>Another alternative for binary is "Gnuplot binary" where the first line 
>>and row of the matrix give the x and y spacing information.  I've 
>>generally not used that for images, but I think it should work.  (Type 
>>"help splot binary" at Gnuplot's command line for more info on that format.)
>>
>>The reason you may want to avoid putting your image in ASCII format is 
>>that you are playing the numbers game again.  Your example above has 9 
>>characters for each pixel element.  1800 x 1800 x 9 or roughly 27 M at a 
>>minimum, and if when you add the (x,y) coordinates it goes to 81 M. 
>> That's too big.  If in the program or software you are using to 
>>generate the data you could multiply by 2^16 and then save the values in 
>>binary as unsigned 16 bit ints you would be better off.  Can you do that?
>>
>>Dan
>>
>>    
>>
>>>Justace
>>>
>>>On Wed, 2004-03-03 at 01:00, Daniel J Sebald wrote:
>>> 
>>>
>>>      
>>>
>>>>Justace Clutter wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>So,
>>>>>
>>>>>	I have this project where I have computed a bunch of channel
>>>>>correlations.  The entire matrix is like 1800x1800 with one side of the
>>>>>diaganal set to NaN since it is symetric.  Now to the root of the
>>>>>problem.  I use the pm3d portion of gnuplot to create a 2D map of the
>>>>>matrix.  Here is the snipplit of code that I use...
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>><snip>
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>I used the first set size command to try to bring the file size down, of
>>>>>course it did not work.  The resultant file is 120Meg.  This is crazy.
>>>>>Am I doing somehting wrong?
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Justace,
>>>>
>>>>Am I understanding correctly that you are essentially attempting to 
>>>>display an 1800x1800 matrix as an image?  Ethan's comment is correct 
>>>>that each element, i.e., pixel, will be drawn as a rectangle, i.e., 
>>>>polygon.  There is a lot of ASCII text associated with each rectangle. 
>>>>You might try the image patch on SourceForge (something originally 
>>>>titled "with pixels").  That will put the image into a PostScript file 
>>>>in a compact form.
>>>>
>>>>Realize though that 1800x1800 is a lot of data.  Saved as bytes, that 
>>>>alone would be roughly 3M.  I've tried 1000x1000 images with no 
>>>>problems, but things really do slow down.  So, unless it is necessary to 
>>>>keep such high resolution for the image, your first step might be to 
>>>>down sample the data appropriately.  Keep in mind what your eventual 
>>>>display will be.  (For example, people often put high res photos on 
>>>>their web pages which take close to a minute to download.  However, the 
>>>>display is usually low resolution so a condensed image would have served 
>>>>equally well and, in fact, would save space on their server.)  Ethan's 
>>>>suggestion of PNG is a good idea because that inherently brings down the 
>>>>resolution.
>>>>
>>>>Dan
>>>>   
>>>>
>>>>        
>>>>
>>
>>
>>-------------------------------------------------------
>>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
>>_______________________________________________
>>gnuplot-beta mailing list
>>gnu...@li...
>>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>    
>>
>
>
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

default tic label format

[Pieter-Tjerk de B. <ptd...@cs...>]

Hello,

While trying the 3.8k.1 version of gnuplot, I noticed that the default
format for the labels on the axis is "% g".
This has two (minor) disadvantages, compared to simple "%g" as it was
in version 3.7:
- labels on horizontal axes are not centered nicely (the invisible
  leading space is included in the centering calculation).
- labels on the y2 axis (if used) start farther away from the axis
  than the y1 axis labels do.

Actually, I remember already briefly discussing this with Lars a few
years ago; he then wrote:

>  I remember that change, and that there was a reason for it ...
> 
> Yep, it was suggested to me by Lucas Hart:
> 
> |  BTW, I find DEF_FORMAT "% g" more legible for tables than "%g"; any 
> |  effect on labels that would preclude a change?  Also, since you are 
> 
>  I suppose your observation qualifies for Lucas' condition ...

Obviously, I would suggest changing to "%g" before the release of 4.0.

Best regards,
  Pieter-Tjerk

Re: Postscript and PM3D file size.

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

Daniel J Sebald wrote:

>   My experience with angiography images and the sort is that maybe 50% 
> lossless compression is the best on average.

(That's not RLE encoding, but something else.)

Dan

Re: Postscript and PM3D file size.

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

Justace Clutter wrote:

>I like the idea of this pixels based image.  The fact that the image
>could be 10 megs does not bother me.
>

Well, in my case my web space is only 10 M.

>  It is the idea that an image could
>be 120 megs bothers me.  So I got the patch and applyed.  It did not go
>clean as one hunk did not make it.  But I fixed it by hand.  I was
>patching against 3.8k.1.  So, I guess that I do not understand the
>syntax.  Here is the datafile that I have, or really a sample:
>
>0.999849 0.652204 0.678995 0.658985 0.585981 0.566624 0.547193 0.615902
>0.539023 0.556559 0.547578 0.53746 0.522146 0.535582 0.530735 0.531924
>0.554801 0.518362 0.479106 0.527362 0.534836 0.546124 0.522834 0.508155
>0.54706 0.469279 0.581292 0.468283 0.535739 0.557979 0.490128 0.536971
>0.530735 0.506848 0.523189 0.531732 0.550917 0.484002 0.57789 0.460027
>0.556111 0.535427 0.508878 0.558746 0.459494 0.578337 0.45805 0.595234 
>
>So I have a grid here, 8x6, that I would like displayed.  Each of these
>floats would need to be mapped onto a color.  PM3D did this great.  So
>when I try to use the matrix modifier with just plot it is not happy,
>then I tried to use splot, still not happy.  Here is what I was trying..
>
>gnuplot> plot 'tmp.data' matrix with image
>
>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>
>Warning: empty x range [0.999849:0.999849], adjusting to
>[0.989851:1.00985]
>
>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>
>gnuplot> splot 'tmp.data' matrix with image
>
>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>
>gnuplot> set view map
>gnuplot> splot 'tmp.data' matrix with image
>
>GNUPLOT (plot_image):  Image grid must be at least 2 x 2.
>
>gnuplot>
>
>Can you give me some ideas on how I can use the image style with this
>setup?  I looked at the information on the image but it seems pretty
>biased toward images like the tux and not array'd data.  Thanks in
>advance.
>

Well, here is the issue.  You are putting the data in ASCII format in 
what looks to you like a grid.  However, Gnuplot hasn't been set up to 
read ASCII data in such a way.  It is set up to read ordered tuples of 
data, such as

x1  y1  z1
x2  y2  z2
...

where the position is part of the data specification.

Telling Gnuplot what the underlying grid is without specifying it is the 
problem.  That is why the "binary" file specifications have extra 
qualifiers to indicate grid dimensions, grid spacing, etc.

Another alternative for binary is "Gnuplot binary" where the first line 
and row of the matrix give the x and y spacing information.  I've 
generally not used that for images, but I think it should work.  (Type 
"help splot binary" at Gnuplot's command line for more info on that format.)

The reason you may want to avoid putting your image in ASCII format is 
that you are playing the numbers game again.  Your example above has 9 
characters for each pixel element.  1800 x 1800 x 9 or roughly 27 M at a 
minimum, and if when you add the (x,y) coordinates it goes to 81 M. 
 That's too big.  If in the program or software you are using to 
generate the data you could multiply by 2^16 and then save the values in 
binary as unsigned 16 bit ints you would be better off.  Can you do that?

Dan

>Justace
>
>On Wed, 2004-03-03 at 01:00, Daniel J Sebald wrote:
>  
>
>>Justace Clutter wrote:
>>
>>    
>>
>>>So,
>>>
>>>	I have this project where I have computed a bunch of channel
>>>correlations.  The entire matrix is like 1800x1800 with one side of the
>>>diaganal set to NaN since it is symetric.  Now to the root of the
>>>problem.  I use the pm3d portion of gnuplot to create a 2D map of the
>>>matrix.  Here is the snipplit of code that I use...
>>>
>>>      
>>>
>><snip>
>>
>>    
>>
>>>I used the first set size command to try to bring the file size down, of
>>>course it did not work.  The resultant file is 120Meg.  This is crazy.
>>>Am I doing somehting wrong?
>>>
>>>      
>>>
>>Justace,
>>
>>Am I understanding correctly that you are essentially attempting to 
>>display an 1800x1800 matrix as an image?  Ethan's comment is correct 
>>that each element, i.e., pixel, will be drawn as a rectangle, i.e., 
>>polygon.  There is a lot of ASCII text associated with each rectangle. 
>> You might try the image patch on SourceForge (something originally 
>>titled "with pixels").  That will put the image into a PostScript file 
>>in a compact form.
>>
>>Realize though that 1800x1800 is a lot of data.  Saved as bytes, that 
>>alone would be roughly 3M.  I've tried 1000x1000 images with no 
>>problems, but things really do slow down.  So, unless it is necessary to 
>>keep such high resolution for the image, your first step might be to 
>>down sample the data appropriately.  Keep in mind what your eventual 
>>display will be.  (For example, people often put high res photos on 
>>their web pages which take close to a minute to download.  However, the 
>>display is usually low resolution so a condensed image would have served 
>>equally well and, in fact, would save space on their server.)  Ethan's 
>>suggestion of PNG is a good idea because that inherently brings down the 
>>resolution.
>>
>>Dan
>>    
>>

Re: Postscript and PM3D file size.

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

Arnd Baecker wrote:

>On Wed, 3 Mar 2004, Petr Mikulik wrote:
>
>[...]
>
>  
>
>>2. Use "with pixels style" patch by Daniel at the "Patches" section on
>>sourceforge.
>>    
>>
>
>And in that case I think using RLE instead of the present scheme
>should reduce the file size by another relevant factor.
>(However, though this seems pretty straight forward,
>someone has to code this and at the moment I am completely
>busy with other stuff ;-)
>

Well, run length encoding is great for applications like fax data and 
the sort, i.e., a single bit image depth.  That's because there are 
typically long stretches of white space where the run length really 
achieves compression.  However, I'm not sure what RLE will get you in 
color or gray scale images.  My experience with angiography images and 
the sort is that maybe 50% lossless compression is the best on average. 
 There are forms of lossy compression, but this takes consideration.  If 
someone on the list has experience with compact representation of 
various image types, that would be helpful...

I feel that coding is half the problem.  The other half is simply making 
a decision what to do, i.e., agreeing on what the format or syntax 
should be.  It can in fact be a fun little project to implement some of 
these things.  I just went to the library and looked at the Adobe 
PostScript Standard book and picked the most flexible beginning format, 
which to me seemed to be ASCII85.  The reason is that it would be 
lossless compression (keeping everyone fairly happy from the start), 
various PostScript viewers would likely be able to read it, and there 
would be no question of whether we should use, say, and MPEG compression 
library routine.  That is, I didn't see any sense in going full tilt 
into writing, say, an MPEG routine if it wasn't certain it would get 
used or if the developers may decided using some existing library would 
be the smartest maintenance alternative.

Dan

Re: Postscript and PM3D file size.

[Arnd B. <arn...@we...>]

On Wed, 3 Mar 2004, Petr Mikulik wrote:

[...]

> 2. Use "with pixels style" patch by Daniel at the "Patches" section on
> sourceforge.

And in that case I think using RLE instead of the present scheme
should reduce the file size by another relevant factor.
(However, though this seems pretty straight forward,
someone has to code this and at the moment I am completely
busy with other stuff ;-)

Best,

Arnd

Re: Postscript and PM3D file size.

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

> 	I have this project where I have computed a bunch of channel
> correlations.  The entire matrix is like 1800x1800 with one side of the
> diaganal set to NaN since it is symetric.  Now to the root of the
> problem.  I use the pm3d portion of gnuplot to create a 2D map of the
> matrix.  Here is the snipplit of code that I use...
>
> I used the first set size command to try to bring the file size down, of
> course it did not work.  The resultant file is 120Meg.  This is crazy.

Ethan has explained why the ps file does not depend on "set size".

Decrease size of pm3d map in ps file can be done by:

1. Postprocessing your ps file -- see scripts pm3dCompress.awk and
pm3dConvertToImage.awk in gnuplot sources or in
http://gnuplot.sourceforge.net/scripts/

2. Use "with pixels style" patch by Daniel at the "Patches" section on
sourceforge.

---
Petr Mikulik

Re: Postscript and PM3D file size.

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

On Tuesday 02 March 2004 08:20 pm, Justace Clutter wrote:
>
> 	I have this project where I have computed a bunch of channel
> correlations.  The entire matrix is like 1800x1800 with one side of the
> diaganal set to NaN since it is symetric.  Now to the root of the
> problem.  I use the pm3d portion of gnuplot to create a 2D map of the
> matrix.  Here is the snipplit of code that I use...
>       set terminal postscript eps color palfuncparam 500

This is a case where PostScript is probably the wrong format to choose
for output.   The PostScript output file will contain a separate command
for every point (or box or line or...) plotted, even if they all fall on top
of each other.  For very large datasets, where there are more data
points than the resolution of your output device, you are better off
using a pixel-based output format like PNG.   That way the output
size is fixed in advance.  No matter how many data points map to
a single pixel, it's still only one pixel.


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle