Menu
▾
▴
gnuplot-beta
|
From: Aapo L. <aap...@gm...> - 2005-03-22 19:16:17
|
Hi! I noticed something strange using Gnuplot 4.1 CVS (and Gnuplot 4.0, too): the following commands ---- clip ---- unset surface set contour set logscale z set palette model HSV functions gray, gray, 1.0-0.5*gray set log cb unset colorbox set cntrparam levels 30 set view 0,0 splot x**2+y**2+1.0 palette ---- clap ---- draw nice coloured contours as you would expect, but the the contour labels in the legend are of wrong colour - all the contour label lines in the legend have the same colour as the maximum intensity contour line. However, the contour label numerical values seem to be correct in the legend. This happens with at least x11 and postscript terminals. I'm using Debian i386 GNU/Linux (Sarge). Can someone confirm? Aapo -- Aapo Lankinen <aap...@gm...> |
|
From: Aapo L. <aap...@gm...> - 2005-03-22 21:02:05
Attachments:
contour.patch
|
On Tue, 2005-03-22 at 21:15 +0200, Aapo Lankinen wrote:
> Hi!
>
> I noticed something strange using Gnuplot 4.1 CVS (and Gnuplot 4.0,
> too): the following commands
>
> ---- clip ----
> unset surface
> set contour
> set logscale z
> set palette model HSV functions gray, gray, 1.0-0.5*gray
> set log cb
> unset colorbox
> set cntrparam levels 30
> set view 0,0
> splot x**2+y**2+1.0 palette
> ---- clap ----
>
> draw nice coloured contours as you would expect, but the the contour
> labels in the legend are of wrong colour - all the contour label lines
> in the legend have the same colour as the maximum intensity contour
> line. However, the contour label numerical values seem to be correct in
> the legend. This happens with at least x11 and postscript terminals.
> I'm using Debian i386 GNU/Linux (Sarge). Can someone confirm?
Nevermind, I figured it out myself. In the logarithmic mode of the
contour PM3D-plot there is two subsequent log10():s of the z-coordinate
of the legend, which effectively renders the legend line samples to the
same colour. I removed the other de-log, and following patch fixes the
problem at least for me. :-) I hope it does not cause any other
unexpected problems. Can someone check if it's safe? I don't know
anything about Gnuplot except reading the source for an hour :-)
Maybe someone could perhaps apply it to the CVS, if it indeed does work
for others? (diff for contour.c below and attached)
Aapo
--- contour.c 2005-03-22 22:07:26.589004130 +0200
+++ contour.c 2005-03-22 22:08:12.726777705 +0200
@@ -247,7 +247,7 @@
contour_list->isNewLevel = 1;
sprintf(contour_list->label, contour_format,
AXIS_DE_LOG_VALUE(FIRST_Z_AXIS,z));
#ifdef PM3D
- contour_list->z = AXIS_DE_LOG_VALUE(FIRST_Z_AXIS, z);
+ contour_list->z = z;
#endif
}
}
--
Aapo Lankinen <aap...@gm...>
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-03-23 19:02:12
|
On Tuesday 22 March 2005 01:01 pm, Aapo Lankinen wrote: > > Nevermind, I figured it out myself. In the logarithmic mode of the > contour PM3D-plot there is two subsequent log10():s of the z-coordinate > of the legend, which effectively renders the legend line samples to the > same colour. I removed the other de-log, and following patch fixes the > problem at least for me. :-) Thanks. Applied in cvs. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Aapo L. <aap...@gm...> - 2005-06-07 15:10:16
Attachments:
logcontourfix.patch
|
On Wed, 2005-03-23 at 11:01 -0800, Ethan Merritt wrote: > On Tuesday 22 March 2005 01:01 pm, Aapo Lankinen wrote: > > same colour. I removed the other de-log, and following patch fixes the > > problem at least for me. :-) > > Thanks. Applied in cvs. You're welcome. However, I found a new bug in the Gnuplot 4.1 CVS logarithmic contours code. The following script doesn't work as expected: ---- clip ---- unset surface set contour set log z set palette model HSV functions gray, gray, 0.8-0.5*gray set log cb unset colorbox set view map set cntrparam level incremental 5,2,200 splot x**2+y**2+1.0 palette ---- clap ---- Nothing is plotted. The problem is in the "cntrparam level incremental" definition; Gnuplot recognizes the values as linear increments in logarithmic axis, which leads in HUGE steps in the actual z-value. The steps go like (10^5, 10^7, 10^9, ... , 10^200), which is obviously very wrong. By replacing the "set cntrparam" command with "set cntrparam level incremental 1,0.1,2" one gets a nice plot with z range [10:100] (10^1 and 10^2) with ten contours (1/0.1). This works, but is very confusing for the end user. One thing to note is that it's not generally quite clear what is meant by "cntrparam level incremental" in logarithmic space. I assume that the user means constant increments in logarithmic space. However, because addition in logarithmic space means multiplication in linear space, there will be a problem: What is the multiplicator (i.e. the logarithmic addition)? The incrementation parameter is not usable, as it should mean an incrementation in linear space, not multiplication. I wrote a small patch based on the interpretation of constant increments in logarithmic space. In the patch, the incrementation in logarithmic space is calculated so that the first incremental step (in linear space) is exactly as large as the incrementation the user selected. I chose that implementation, because a) it's intuitive b) it's simple to program c) it doesn't seem to break the existing, correct implementation for linear z axis. So, the new patch should give contours in z positions (5, 7, 9.8, 13.7, 19.2, ...) for "set cntrparam level incremental 5,2,200". The idea is that 5 + 2 = 7, so that the first two steps are the same as for the linear case, and the next steps are calculated logarithmically based on the first two. I hope that is intuitive enough; at least it's lot better than the current behaviour. The main problem is that it doesn't draw anything with negative values (which do not have real logarithms anyway). Well, at least it doesn't dump core either. :-) The very very small patch to implement this is attached, please try it for the example above to see what I mean. I've tried it with simple linear and logarithmic scripts (like the sample above), but who knows? It may break something; works for me, but YMMV. :-) Best Regards, Aapo Lankinen -- Aapo Lankinen <aap...@gm...> |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-03-23 06:20:36
|
On Tuesday 22 March 2005 11:15 am, Aapo Lankinen wrote: > > ---- clip ---- > unset surface > set contour > set logscale z > set palette model HSV functions gray, gray, 1.0-0.5*gray > set log cb > unset colorbox > set cntrparam levels 30 > set view 0,0 > splot x**2+y**2+1.0 palette > ---- clap ---- > > all the contour label lines in the legend have the same colour > as the maximum intensity contour line. > Can someone confirm? I confirm there's a bug. When cb is in logscale, the axis limits CB_AXIS.min and CB_AXIS.max are stored as the log of the limit value. But the function cb2gray(val) checks val itself against the limits, rather than checking log(val). Unfortunately, changing it to log(val) inside cb2gray does not produce the correct contour coloring either. So there must be additional problems. There's ongoing discussion of revising the contouring code anyhow, so maybe someone will spot the correct fix while revising it for other reasons. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From:
<br...@ph...> - 2005-06-07 17:50:50
|
` Lankinen wrote: > You're welcome. However, I found a new bug in the Gnuplot 4.1 CVS > logarithmic contours code. The following script doesn't work as > expected: As so often, that depends on the background of the person doing the expecting... The right way of handling this would have been to do it like the other "tick series" things in gnuplot do it, i.e. like 'set xtics'. Which means the endpoints are numbers in the input format, but the increment is a *factor*, not an addition to the logarithm. So '5,2,200' should have delivered tics at (5,10,20,40,80,160) > One thing to note is that it's not generally quite clear what is meant > by "cntrparam level incremental" in logarithmic space. Taking into account prior art, it is. It just fails to be implemented that way ;-( |
|
From: Aapo L. <aap...@gm...> - 2005-06-08 10:52:34
Attachments:
contourlog.patch
|
On Tue, 2005-06-07 at 19:52 +0200, Hans-Bernhard Bröker wrote: > As so often, that depends on the background of the person doing the > expecting... > > The right way of handling this would have been to do it like the other > "tick series" things in gnuplot do it, i.e. like 'set xtics'. Which > means the endpoints are numbers in the input format, but the increment > is a *factor*, not an addition to the logarithm. That's cool. I made a new patch that implements it that way. > So '5,2,200' should have delivered tics at (5,10,20,40,80,160) Now the z ticks are exactly like that. And the patch is even simpler. :-) > Taking into account prior art, it is. It just fails to be implemented > that way ;-( Ok, thank you. I don't have very deep knowledge of Gnuplot, so I didn't realise that. But now it's fixed, see the attached patch. Best Regards, Aapo Lankinen -- Aapo Lankinen <aap...@gm...> |
