#1603 hidden3d offset 1 and inconsistent contour color

[Peter Gasparovic]

When using splot with contours, 'set hidden3d' (with default offset 1) makes colors of contours inconsistent with colours in key legend. They are shifted by one. I can't imagine situation, when offseting contour color on back side is desired.

When tested in gnuplot 4.6.0 on win32 the colors were OK.
When tested in gnuplot 4.6.5 on win32 and 5.0.0 on win64 the colors are inconsistent.

Example attached

[Ethan Merritt]

Thank you for the bug report and test files.
As you note, this seems to be a bug introduced in version 4.6.5
Fixed now (I think) in CVS for 4.6, 5.0, and 5.1

[Dan Sebald]

In doing a diff in cvs I noticed this small change. I'm wondering if subtracting 1 is the general solution, but I haven't investigated this one much. What I do notice in the example attached PNG files that the erroneous plot "shifted offset1default" is that the mesh itself has a non-black color.

What's more, in that erroneous plot PNG file the first entry in the key corresponds to the function and although the line next to function in the key is dashed to match the plot mesh the dashed line in the key is black and not magenta. (One has to magnify the plot to get a good judge of color.) That is still the case in the current CVS version, more noticeable when looking at the PostScript output from the contours_hidden.plt example.

So, there could be something new in 5.0, hidden3d where the function itself is considered a line color, in which case perhaps the number of mesh plots should be subtracted, not 1. Or perhaps "black" should be considered the first color, beginning with the function mesh. Again, I haven't looked too closely.

[Peter Gasparovic]

I used "splot ... with lines linetype 0" and that's the reason why the mesh lines are dashed.

I didn't care about dashed line. I only wanted thin line for mesh and thick line for contours and "linetype 0" is the only way how to achieve it. Gnuplot then uses linetype 0 only first time (for mesh lines) and then cycles linetypes 1-8 for remaining lines (i.e. contours). If I try "splot ... with lw 0.5" both mesh lines and contour lines are thin an that's not what I want. I think, there is the need for another splot command option for linestyle of contours (separate from linestyle of mesh).

Regarding erroneous color of mesh lines with "linetype 0", the change appeared between versions 4.6.0 and 4.6.5.

[Dan Sebald]

OK, you should be able to achieve this with the current capabilities of the code. But, there may be some bugs here as I'm having a few problems getting just what you describe.

First, I'm working with the Qt terminal or X11 terminal rather than PostScript terminal, but behavior seems the same.

One should be able to control the surface plot characteristics without having to use a linetype. Try something like the following:

set grid layerdefault linewidth 0.5 linecolor rgb "black", linewidth 0.5 linecolor rgb "black"

[snip]

splot "a.txt" nonuniform matrix using 2:1:3 with lines linecolor rgb "black" linewidth 0.5

And it should be possible to control the thickness of the contour lines with something like the following:

set for [i=1:8] linetype i linewidth 4;

At least that seems logical, but unfortunately that doesn't work for me. However, the line color works in this fashion, i.e.,:

set for [i=1:8] linetype i linecolor rgb "blue";

Maybe there is a bug there. In any case, experiment a bit to see if you get what you want, and if anything seems confusing or contrary to documentation, or you can't fine tune the plot in the way you like, then report back.

[Peter Gasparovic]

Dan, "set grid ..." doesn't solve my problem with mesh lines. My grid was OK.

Regarding your advice
"... should be possible to control the thickness of the contour lines with something like the following: set for [i=1:8] linetype i linewidth 4;"
it doesn't work for me either (in Postscript terminal). So with the current capabilities (or bugs) I am not able to set surface mesh lines and contours to different line thickness.

Specifically, your change of color:
set for [i=1:8] linetype i linecolor rgb "blue"; # works OK

Your change of linewidth:
set for [i=1:8] linetype i linewidth 4;
works, but there must not be command "splot ... linewidth 0.5", because linewidth in "splot" takes precedence over linewidth in "set". Maybe it is a feature and not a bug, but then my problem is unsolvable.

However, I have found evident bug. If you issue command:
set linetype 1 linewidth 4;
, all linetypes in surface plot have linewidth 4. (If splot doesn't contain linewidth.)

There is one positive effect of your definition of mesh line:
splot "a.txt" nonuniform matrix using 2:1:3 with lines linecolor rgb "black"
- the problem with color offset of contour lines disappeared. However, behavior of "splot ... with linetype ..." is inconsistent with behavior of "splot ... with lines linecolor ..." and so I consider it a bug.

[Ethan Merritt]

By "all linetypes in surface plot" are you referring to conour lines or something else?

It is intended that all contours for a particular plot share line properties except for color. So far as I recall it has always been that way, but maybe I misremember. Could you clarify exactly how you want the plot to come out?

[Dan Sebald]

"
Your change of linewidth:
set for [i=1:8] linetype i linewidth 4;
works, but there must not be command "splot ... linewidth 0.5", because linewidth in "splot" takes precedence over linewidth in "set".
"

Oh, guess so. I wouldn't have thought that to be the case. Why shouldn't the surface mesh and the contours be controlled individually?

For that matter, using the same line characteristics for contours other than pen color seems restricting as well. It seems conceivable that a user might want to vary that. E.g., every contour the same color while the contour associated with, say, an optimum might be a different color or dashed line instead of solid line.

FWIW, I would have preferred {base | surface | all} over {base | surface | both}. "both" implies two. It probably will never be a problem, but if another location is added, making three, then "both" is ambiguous.

[Peter Gasparovic]

Ethan, by "all linetypes in surface plot" I meant surface mesh lines and surface contour lines.
If it is intended that all contours share line properties (other than color), why also mesh shares these properties?
I agree with Dan, that shared line properties other than color is too restricting. It also damages predictability and transparency of user interface. It brings intricate dependency between "set linetype" an "set countour" (contour invalidates linetype changes). I had also difficulty to find information about this dependency in gnuplot help.

[Peter Gasparovic]

I want surface plot with contours, where:
1. mesh lines are thin black or gray
2. contour lines are thick and colored by different colors
3. some contour lines are dashed

[Ethan Merritt]

I want surface plot with contours, where:

(1) mesh lines are thin black or gray

Easy

(2) contour lines are thick and colored by different colors

Also easy

Here you go:

set contour; set cntrparam levels 10
splot x*y lc "gray" lw 0.5 nocontour, \
      x*y lw 3 nosurface

This is solution becomes a bit more tricky if you also want hidden3d because for some reason "nosurface" gets ignored in that case. As a workaround we set the color of lt 1 and lt 2 to background and reverse the order of plotting:

set linetype 1 lc bgnd
set linetype 2 lc bgnd
splot x*y lt 1 lw 3 nosurface, \
      x*y lc "gray" lw 0.5 nocontour

(3) some contour lines are dashed

Handling of dashed lines changed radically in version 5, and I think no special attention was paid to contours. How would you like it to work? I can think of several approaches. It could be drawn from the linetype (in parallel with the colors). Or it could be a new property in "set cntrparam" (i.e. set cntrparam dashpattern "..." every 5). Or something else entirely.

[Peter Gasparovic]

Yes, I forgot that I need also hidden3d.
I have tried your workaround, but the result in postscript terminal looks strange - the mesh lines are only partly visible (see attachment). An the offset color bug is back (because you let the splot to draw mesh lines by linetype). (In gnuplot 5.0.0.)

(3) I would let cntrparam reserved for geometric and logical properties of contours, and draw presentation style of the contours (color, width, dashpattern) from the linetype.

[Ethan Merritt]

I obviously cannot fix the off-by-one coloring retroactively in 5.0.0, but I believe it is working in the current CVS version. Here's what I get. I can see a couple of artifacts in the *.ps version but only if I look closely.

It would be easy (I think) to honor the dash pattern of the corresponding linetype for contour lines in normal plots. But the hidden3d code is totally separate from the normal drawing code and does not currently know anything about dash types. Changing that would not be trivial, because the additional property would have to be tracked and passed down through multiple layers of processing.

[Dan Sebald]

I like the control of linetype as well. Seems the most natural and logical way of going about it. The

set for [i=1:8] linetype i ...

syntax makes it easy to customize as well. Could make the colors index a heat map or other color-bar quantity.

Ask the discussion list for general opinion.

[Ethan Merritt]

Z-value, palette colors, etc are already available, so that by itself doesn't constrain the choice much.

[Dan Sebald]

I verified that two surfaces correctly orders the colors by reducing the number of contour lines to 1 in demo (8) of contours.dem. However, I ran into what looks like a bug:

https://sourceforge.net/p/gnuplot/bugs/1610/

Perhaps that bug is related to the color offset by one in some way.

[Dan Sebald]

OK, Hans pointed out that

https://sourceforge.net/p/gnuplot/bugs/1610/

isn't a bug. The default contour line behavior is to match the 1,2,5 behavior of axis tics. That is contours behave almost like tic marks.

However, I think looking at this may have reveal where the source of this off-by-one color bug originated. It appears the real issue may be that one of the contour lines is missing. In the following example, shouldn't the number of contours match the number of ticks?

set term qt
set contour
splot x

The ticks/labels are at -10, -5, 0, 5, 10. But the contour lines are only four: -5, 0, 5, 10. Has the first contour line been lost some time ago so that the color is now starting at the second line and is one greater than in the past?

[Dan Sebald]

What about the missing contour line?

https://sourceforge.net/p/gnuplot/bugs/1603/#e770

[David Kastrup]

I think this fix is wrong. The reason is that the example graphics are not representative: they don't show the surface from below. Currently the surface from below is colored with linetype 2 and cannot be configured separately from the first contour line type.

[Ethan Merritt]

Yes it can. If you are in hidden3d mode then contour lines start at +2 rather than +1. Here's a png

[David Kastrup]

Uh, I loaded your image in Gimp and double-checked with the color picker. The underside of the surface has the identical color as the first labelled contour line. Of course, the consequences for colored lines aren't as bad as for dashed contours. Still annoying though.

Now presumably one can fudge around this using set hidden3d offset in order to get a different linetype for the underside. So at least there should be a usable workaround (assuming that the documentation is not lying). But your own PNG does not support your statement.

[Ethan Merritt]

You are correct. My bad.
Gnuplot development is in the middle of a transition of the project that moves the source and development to git. When the dust settles on that I'll have another look at contour lines.

[Dan Sebald]

I'm recalling this one. It seemed a really peculiar bug that came out of nowhere when there didn't appear to be previous issues. I'm guessing that contour levels utilize the tick-spacing code in some way, and I wonder if something was changed with tick marks in the past that influences the color selection. Note the missing contour level in example https://sourceforge.net/p/gnuplot/bugs/1603/#e770 Ethan's example showing the underneath surface has the same property, contours start at -80 when perhaps they should start at -100.