#388 pm3d map plot gives a figure that is smaller than a normal 2d plot

[leoking]

Currently the pm3d map plot gives a figure that is smaller than a normal 2d plot.

This the default pm3d output:

This the 2d plot output (a trick has been used here to produce this density map using plot, see the attached code):

This is because pm3d map still assumes it is doing a 3d plot. In a 3D plot, we have to have some space for the z axis, and even if we drop it in the map view, the space-holder for the z axis is still there, therefore, gnuplot makes the whole plot a bit smaller.

The problem is that pm3d map is not a 3d plot, it actually a 2d plot. If pm3d map is smaller than normal 2d plot, it will make it impossible to have it together with other 2d figures in a multiplot.

There are ways to dodge this by writing pm3d results to a temporary file and replot it using "plot with image". But it is very inefficient.

I attached a file to illustrate the different size between a default pm3d map plot and a 2d plot:

f(x,y)=sin(1.3*x)*cos(.9*y)+cos(.8*x)*sin(1.9*y)+cos(y*.2*x)
set size square
set xrange [-5:5]
set yrange [-5:5]
set contour base
set cntrparam level incremental -3, 0.5, 3
set palette rgbformulae 33,13,10
set pm3d map
set isosample 250, 250
unset key
splot f(x,y) with pm3d

pause 2
reset
f(x,y)=sin(1.3*x)*cos(.9*y)+cos(.8*x)*sin(1.9*y)+cos(y*.2*x)
set xrange [-5:5]
set yrange [-5:5]
set isosample 250, 250
set table 'test.dat'
splot f(x,y)
unset table

set contour base
set cntrparam level incremental -3, 0.5, 3
unset surface
set table 'cont.dat'
splot f(x,y)
unset table

reset
#set lmargin 0
#set rmargin 0
#set bmargin 0
#set tmargin 0
set size square
set xrange [-5:5]
set yrange [-5:5]
unset key
set palette rgbformulae 33,13,10
p 'test.dat' with image, 'cont.dat' w l lt -1 lw 1.5

[Ethan Merritt]

I am reclassifying this as a Feature Request, since the problem is not so much a bug in any particular command but rather an unfortunate interaction between default settings, "set margin", and multiplot autolayout.

Some thoughts:

Both "plot" and "splot" allow you to fully specify the plot size and position using

   set lmargin at screen ...
   set rmargin at screen ...
   set bmargin at screen ...
   set tmargin at screen ...

This will produce identical layout with both "plot" and "splot".

However you have a good point about multiplot. Setting the margins explicitly as above will override the multiplot settings.

One approach would be to add a new class of coordinates. Right now we have axis coordinates ("first", "second"), "graph" coordinates, and "screen" coordinates. The "set margin" commands only work with screen coordinates. Your issue would be solved if there were an equivalent to "screen" that operated relative to the current multiplot panel rather than relative to the full canvas. So something like
set lmargin at panel 0.1
set rmargin at panel 0.9
...

If multiplot mode is not active then "screen" and "panel" coordinates would be identical.

[Christoph Bersch]

I don't see any multiplot settings involved. I think, the request is, that set view map; splot ... and plot default to the same margin settings.

[Ethan Merritt]

I may have misunderstood, but I thought the request was for a way to make all plots in different panels of a multiplot to have the same physical dimensions. But what would those dimensions be?

Leaving aside for the moment any difference in handling 2D/3D plots, there is no single "default" set of boundaries even for 2D plots. The automated choice of plot layout changes depending on the current setting of axis tics, margins, titles, colorbox, and probably more stuff I'm not thinking of at the moment. Given this, even if you limit your mulitplot panels to being all 2D plots the automatically chosen plot boundaries are not going to be the same in all panels unless the plot commands are very nearly identical.

If you are making individual plots you can currently enforce uniformity across all these different plot styles and label options by using "set [lrbt]margin at screen foo". That handles both 2D and 3D styles. But it doesn't work in multiplot mode because the "at screen foo" places the boundaries relative to the screen (just as it says) rather than relative to the multiplot panel.

[Ethan Merritt]

Ticket moved from /p/gnuplot/bugs/1382/

[Ethan Merritt]

Alternatively, if the request is basically for a way to rescale a plot in "set view map" mode - that's a lot easier. I don't know how the current fixed size was chosen (command.c:2359 surface_scale = 1.3) but it would be trivial to add an explicit scale multiplier to the "set view map" command.

[leoking]

Thanks. Ethan, The following code is able to produce a larger density plot. As you said, it can not be used in a multiplot mode though. I think your suggestion of adding another "panel" coordinates is very useful. And I also think it would nice if "set pm3d map" can by default set margins at "panels" similar to a normal 2d plot.

The changes to default setting might be trivial from a developer's point of view. But from a user's perspective, they might be critical. This remind me a general conception in people's mind that figures produced by matplotlib are nicer than gnuplot. I now know it is only that the default style setting of matplotlib is better.

However, for a user without any experiences of gnuplot and matplotlib. He/she would be likely to choose matplotlib because of its better default style.

So that I am trying to create a set of better default style for gnuplot. Here is a comparison of figures produced using the default setting I created and the current default setting of gnuplot: https://en.wikipedia.org/wiki/JavaGnuplotHybrid :

I feel my default setting enables the figures produced by gnuplot to be more attractive, on par with matplotlib. As least, people can not say the figures produce by gnuplot are 80s like.

I have attached the default settings I created for 2d and 3d figures. It would be my honor if you can incorporate it into gnuplot. It would also be great if you can add a link to my project JavaGnuplotHybrid http://github.com/mleoking/JavaGnuplotHybrid in this page: http://www.gnuplot.info/links.html .

Thanks.

f(x,y)=sin(1.3*x)*cos(.9*y)+cos(.8*x)*sin(1.9*y)+cos(y*.2*x)
set size square
set xrange [-5:5]
set yrange [-5:5]
set contour base
set cntrparam level incremental -3, 0.5, 3
set palette rgbformulae 33,13,10
set pm3d map
set isosample 250, 250
unset key
set lmargin at screen 0.05
set rmargin at screen 0.95
set bmargin at screen 0.05
set tmargin at screen 0.95
splot f(x,y) with pm3d

[Ethan Merritt]

The figures you show for the "default style of gnuplot" do not match what I would expect from current cvs (or indeed from 4.6).

1) the color sequence you show is the very old r/g/b/m/c/y cycle rather than the default as shown in the online demos. E.g.
http://gnuplot.sourceforge.net/demo_5.0/iterate.html

2) I don't think 3D surface plots have ever defaulted to individual points. You get a line surface either with or without hidden line removal:
http://gnuplot.sourceforge.net/demo_5.0/surface1.html
pm3d mode is something else, but I don't think it should be the default.

I may have missed it, but do you have a gnuplot script showing exactly what you prefer as defaults? The scripts I see contain plot commands as well as graphics state settings, so it is not clear which commands you consider "default" and which are specific to that example.

[leoking]

Hi Ethan,

I am feeling exited if my default setting could be accepted. Tell me I am not dreaming. :)

I am using 4.6.5 on windows.
1) 5.0's color appears to be better. :) But as a Java programmer who can only depend on binary releases of Gnuplot. I feel 5.0 is still far away from me. :/
2) I did not set "with lines" for splot and I plotted from a datafile, so that the default output turned to be points.

I went over the styles and recommend the following default styles:

For lines:

#default common line styles:
set style line 1 lc rgb 'dark-blue' lt 1 lw 2 ps 1 pt 5;
set style line 2 lc rgb 'dark-red' lt 2 lw 2 ps 1 pt 7;
set style line 3 lc rgb 'dark-green' lt 3 lw 2 ps 1 pt 9;
set style line 4 lc rgb 'orange' lt 4 lw 2 ps 1 pt 11;
set style line 5 lc rgb 'dark-pink' lt 5 lw 2 ps 1 pt 13;
set style line 6 lc rgb 'purple' lt 6 lw 2 ps 1 pt 15;
set style line 7 lc rgb 'olive' lt 7 lw 2 ps 1 pt 17;
set style line 8 lc rgb 'slategray' lt 8 lw 2 ps 1 pt 19;
set style line 9 lc rgb 'steelblue' lt 9 lw 2 ps 1 pt 21;
set style line 10 lc rgb 'black' lt 10 lw 2 ps 1 pt 23;
set style line 100 lc rgb 'gray30' lt 1 lw 1;
set style line 101 lc rgb 'gray30' lt 0 lw 1;
set style increment user;
set termoption dashed;

1)The point type 5, 7, 9, 11, 13 are nicer than 1, 2, 3, 4,... They should appear first. So that when user plot a small number of series, they will always be used.
2) Dark colors appear to be nicer than those pure colors.

BTW, why let "set style increment" deprecated? If you use "set linetype" instead, a typical line setting would be:

set linetype 1 linetype 2 lc....

There are two "linetype"s in a line representing different meaning. It is a bit confusing, isn't?

For axes of 2d plot:

set border 3 back ls 100;# remove border on top and right and set color to gray
set tics nomirror;
set grid back ls 101;

For axes of 3d plot:

set border 1+2+4+8+16+32+128+256+512 back ls 100;
set xtics border out nomirror
set ytics border out nomirror
set ztics border out nomirror
set grid x y z back ls 101;
set xyplane 0;

For the default color palette:

set cbtics scale 0;
set palette negative rgb 21,22,23 #Reversed hot color palette; This color palette is highly recommended. It allows color printed in gray while stil preserving the information.

Here are the figures produced using the new default style setting (their code are attached including those new default styles):

While working out the styles, I found another bug, 3d figure's four vertical border can either be shown or hid together. I wanted to delete the red border, but was not successful. I will post another separate bug report for this issue.

[leoking]

I am not sure whether Gnuplot can have different default axis styles for 2d and 3d plots. If that is not possible. You can just use the default axis style of 3d figures.

[Ethan Merritt]

===

From my perspective line styles (as opposed to linetypes) are only needed for nonce uses; that is, they are "use once and forget". It makes no sense to call a line style a "default" because it does not persist across a reset command.

We have gradually moved to making the linetypes themselves customizable. This is already possible (and recommended) in version 4.6 and is done by default in version 5. In both versions 4.6 and 5 you can place the desired linetype definitions in a system configuration file or in your personal ~/.gnuplot configuration file. Either way this establishes a new set of default linetypes.

So if you like that set of colors, I suggest to wrap it up as a configuration file for the linetypes. There are example implementations in the .../share directory of the gnuplot distribution.
Note, however, that the version 5 default colors take into account the ability for a viewer to distinguish the colors even if they have a color vision defect.

===

set linetype LT linetype LT lc LC
There are two "linetype"s in a line representing different meaning. >> It is a bit confusing, isn't?

Yes it definitely was confusing. So version 5 does aways with it in favor of a new property "dashtype". This is the change that has been the major item holding up release, but I think it's now almost ready to roll out. The intent is to disallow potentially recursive commands like the one above and instead use

set linetype N dashtype <dash spec=""> linecolor <rgb spec="">
As of today the code still accepts a potentially recursive numerical linetype, but my thought is to either deprecate that or remove it entirely for the version 5 release.

===

As to the grid/border/palette settings, to me those are just personal preferences. Unless you have a compelling argument why one choice is better than another, I don't see a reason to change the current defaults. I might even agree with you that it's "nicer" to have the grid on by default in 3D plots, but again that's just personal preference.

===

The one setting I see there that maybe really does make sense to change as a default is "set xyplane at 0". That option was introduced somewhere around version 4.2 or 4.4 and to me it makes more sense as a default that the original default (which I can't even describe properly :-)

===

I will go ahead and add a scaling option for "set view map". I think it was just an oversight that the generalized "set view" command accepts scale parameters but "set view map" does not. Hmm, does it need separate x and y scales or would a single scale factor suffice?

===

Please have a good look at the changes already in for version 5. It may be that some of your concerns are already addressed, but even if not then at least any proposed changes should be relative to the current status and not relative to something in 4.6 that has already been reworked.

For instance, have a look at the documentation for "set colorsequence" and "set palette cubehelix". Also have a look at the new command "reset session", which is relevant to persistent/nonpersistent settings.

[Ethan Merritt]

Version 5 will have a scale parameter for "set view map" and the default size will be larger than the version 4 default. It is not guaranteed to match any particular 2D setting however, as I don't think that's a well-defined target.