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

Re: set yrange [*<-5:5<*] causes error gnuplot.exe on windows on gnuplot 4.5 (2010-09-30)

[sfeam (E. Merritt) <eam...@gm...>]

On Thursday 30 September 2010, Tatsuro MATSUOKA wrote:
> Hello
> 
> In checking all.dem using gnuplot.exe on windows gnuplot 4.5 (2010-09-30), 
> 
> ******************** file autoscale.dem ********************
> 
> set yrange [*<-5:5<*]
>              ^
> "autoscale.dem", line 23: ':' or keyword 'to' expected
> 
> set yrange [*<-5:5<*]
> does not work only gnuplot.exe on windows.
> 
> For gnuplot on the cygwin and djgpp, wgnuplot.exe, and wgnuplot_pipes.exe,  'set yrange [*<-5:5<*]'
> gives no error.
> 
> This issue seem to be specific to gnuplot.exe on windows.

I can think of no explanation for that.  It is mystifying.
So far as I know, the only difference in compiling gnuplot.exe and wgnuplot.exe
is the environmental variable WGP_CONSOLE.  Is that correct?
But I do not see any code in either parse.c and axis.c that depends on WGP_CONSOLE.

Do any of these work?
   set yrange [*<5    : 15<*]
   set yrange [*<(-5) :  5<*]
   N = -5;  set yrange [*<N : 5<*]

> The auto scale like [*<-5:5<*]  seem to be imported recently to the cvs release, so this issue perhaps
> is not relevant to the current official release  ver. 4.4.2. Right?

That is correct.  The new range syntax is only for 4.5.
 
> If it is better to register this issue to the bug tracker, I will do it.

If it continues to be a problem then please open a tracker item.
But first let's see if anyone else has an idea what might be happening.

	Ethan

Re: palette is strange on X11 terminal on cygwin (gnuplot 4.5 ChangeLog 2010-09-30)

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

On Thursday 30 September 2010, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have found the palette looks strange on X11 terminal on cygwin (gnuplot 4.5 ChangeLog 2010-09-30) 
> 
> set pm3d;set palette
> splot x*x-y*y
> 
> White stripes appear in the palette. 
> See the snapshot the below
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0043
>  0043 palette101001.png, 26,212 bytes, 2010-10-01
> 
> On windows and wxt terminal, such phenomena did not occur.
> 
> How about the X11 terminal on other platforms ?
> Is the issue cygwin specific?

Thank you for pointing out this problem.  It is present on other platforms
as well.  I have added back a 1-pixel overlap of adjacent rectangles in the
colorbox.  This is what the code did before yesterday's change.
I thought it was a coding error, but it seems the overlap was an intentional
fix for the problem you have seen.  This time I added a comment saying it is
intentional.

	Ethan

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[Tatsuro M. <tma...@ya...>]

Hello

--- Ethan Merritt  wrote:

> On Thursday 30 September 2010 04:24:36 pm Tatsuro MATSUOKA wrote:
> > Hello
> > 
> > I have tried Ethan's modification to config.dj2.
> > It seems to work fine on gnuplot 4.4.2 and 4.5.
> > 
> > Before Patch
> > gnuplot> print NaN
> >          undefined variable: NaN
> > After patch
> > gnuplot> print NaN
> > 0.0
> 
> Unfortunately, that shows isnan() is found but the initialization of
> the user variable NaN is not working correctly.
> NaN should print as "NaN" or "nan" rather than 0.0.
> 
> Could you please try this patch to see if the initialization
> method used for Microsoft C also works for DJGPP?
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- gnuplot-cvs/src/stdfn.c 2010-07-30 12:11:40.000000000 -0700
> +++ gnuplot-djgpp/src/stdfn.c     2010-09-30 18:12:55.000000000 -0700
> @@ -458,7 +458,7 @@
>  double
>  not_a_number(void)
>  {
> -#ifdef __MSC__
> +#if defined(__MSC__) || defined(DJGPP) || defined(__DJGPP__)
>         unsigned long lnan[2]={0xffffffff, 0x7fffffff};
>      return *( double* )lnan;
>  #else
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Ooops!

On windows version built by gcc on MinGW also gives
gnuplot> pr NaN
0.0               

I will research NaN related topic using search engine for gcc on MinGW (and) DJGPP.
After that I will consider application of the patch. 

Regards

Tatsuro


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

set yrange [*<-5:5<*] causes error gnuplot.exe on windows on gnuplot 4.5 (2010-09-30)

[Tatsuro M. <tma...@ya...>]

Hello

In checking all.dem using gnuplot.exe on windows gnuplot 4.5 (2010-09-30), 

******************** file autoscale.dem ********************

set yrange [*<-5:5<*]
             ^
"autoscale.dem", line 23: ':' or keyword 'to' expected

set yrange [*<-5:5<*]
does not work only gnuplot.exe on windows.

For gnuplot on the cygwin and djgpp, wgnuplot.exe, and wgnuplot_pipes.exe,  'set yrange [*<-5:5<*]'
gives no error.

This issue seem to be specific to gnuplot.exe on windows.

The auto scale like [*<-5:5<*]  seem to be imported recently to the cvs release, so this issue perhaps
is not relevant to the current official release  ver. 4.4.2. Right?

If it is better to register this issue to the bug tracker, I will do it.

Regards

Tatsuro
 

 

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

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

On Thursday 30 September 2010 04:24:36 pm Tatsuro MATSUOKA wrote:
> Hello
> 
> I have tried Ethan's modification to config.dj2.
> It seems to work fine on gnuplot 4.4.2 and 4.5.
> 
> Before Patch
> gnuplot> print NaN
>          undefined variable: NaN
> After patch
> gnuplot> print NaN
> 0.0

Unfortunately, that shows isnan() is found but the initialization of
the user variable NaN is not working correctly.
NaN should print as "NaN" or "nan" rather than 0.0.

Could you please try this patch to see if the initialization
method used for Microsoft C also works for DJGPP?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot-cvs/src/stdfn.c 2010-07-30 12:11:40.000000000 -0700
+++ gnuplot-djgpp/src/stdfn.c     2010-09-30 18:12:55.000000000 -0700
@@ -458,7 +458,7 @@
 double
 not_a_number(void)
 {
-#ifdef __MSC__
+#if defined(__MSC__) || defined(DJGPP) || defined(__DJGPP__)
        unsigned long lnan[2]={0xffffffff, 0x7fffffff};
     return *( double* )lnan;
 #else
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

	thanks,

		Ethan



> 
> and candlesticks.dem works without error.
> 
> Thanks!!
> 
> Tatsuro
> --- Hans-Bernhard Br将モker  wrote:
> 
> > On 29.09.2010 19:32, Ethan Merritt wrote:
> > 
> > > If you change the configuration file config.dj2 does it build properly?
> > >
> > > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > > --- config.dj2.old      2010-09-29 10:21:42.000000000 -0700
> > > +++ config.dj2  2010-09-29 10:22:06.000000000 -0700
> > > @@ -142,7 +142,7 @@
> > >   #endif
> > >
> > >   /* Define to 1 if you have the `isnan' function. */
> > > -/* #undef HAVE_ISNAN */
> > > +#define HAVE_ISNAN
> > 
> > FWIW 'configure' doesn't believe DJGPP has isnan().  The autoconf test 
> > for it yields false because it looks for a function, not a macro, but 
> > it's done without -lm.  So it finds neither the macro, nor the function 
> > in libm.a.
> > 
> > I can't currently perform any real tests of my own using DJGPP --- gcc 
> > 4.4.4 consistently crashes on me in term.c with a heap fault.
> > 
> > 
> 
> 
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

palette is strange on X11 terminal on cygwin (gnuplot 4.5 ChangeLog 2010-09-30)

[Tatsuro M. <tma...@ya...>]

Hello

I have found the palette looks strange on X11 terminal on cygwin (gnuplot 4.5 ChangeLog 2010-09-30) 

set pm3d;set palette
splot x*x-y*y

White stripes appear in the palette. 
See the snapshot the below
http://www.geocities.jp/tmgpltwin/Files/Files.html#0043
 0043 palette101001.png, 26,212 bytes, 2010-10-01

On windows and wxt terminal, such phenomena did not occur.

How about the X11 terminal on other platforms ?
Is the issue cygwin specific?

Regards

Tatsuro

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[Tatsuro M. <tma...@ya...>]

Hello

I have tried Ethan's modification to config.dj2.
It seems to work fine on gnuplot 4.4.2 and 4.5.

Before Patch
gnuplot> print NaN
         undefined variable: NaN
After patch
gnuplot> print NaN
0.0

and candlesticks.dem works without error.

Thanks!!

Tatsuro
--- Hans-Bernhard Br将モker  wrote:

> On 29.09.2010 19:32, Ethan Merritt wrote:
> 
> > If you change the configuration file config.dj2 does it build properly?
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > --- config.dj2.old      2010-09-29 10:21:42.000000000 -0700
> > +++ config.dj2  2010-09-29 10:22:06.000000000 -0700
> > @@ -142,7 +142,7 @@
> >   #endif
> >
> >   /* Define to 1 if you have the `isnan' function. */
> > -/* #undef HAVE_ISNAN */
> > +#define HAVE_ISNAN
> 
> FWIW 'configure' doesn't believe DJGPP has isnan().  The autoconf test 
> for it yields false because it looks for a function, not a macro, but 
> it's done without -lm.  So it finds neither the macro, nor the function 
> in libm.a.
> 
> I can't currently perform any real tests of my own using DJGPP --- gcc 
> 4.4.4 consistently crashes on me in term.c with a heap fault.
> 
> 


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: too coarse stepping when plotting color box

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday 26 September 2010, Manfred Schwarb wrote:
> >> As Dan suggested, if there are only 5 colors in the palette then we need
> >> only draw 5 rectangles in the color box. Unlike the current code,
> >> however, they shouldn't be evenly spaced.  The endpoints of each rectangle
> >> should be taken from the palette definition so that they will indeed be
> >> placed with perfact accuracy.

I have modified the routine that draws the colorbox for non-PostScript terminals.
It now checks each little colored rectangle that makes up the colorbox to see
if it straddles a break-point in a defined color palette.  If so, that little
rectangle is split into two smaller rectangles so that their boundary lies
exactly at the point where the palette is potentially discontinuous.

This gives pixel-accuracy for defined palettes so long as the terminal itself
is using continuous (RGB) colors.  The modified code is now in CVS.

It does not, however, fix the problem that if the palette uses only a limited
number of colors (set palette maxcolors N) then these colors are assigned with
even spacing over the whole range. If you would like to have finer color
resolution in one specific part of the range, that's an issue.

	Ethan


> > 
> > After playing around with non-linear discrete palettes like the one in your
> > problem figures, I have become suspicious that the problem is more serious
> > than just the resolution of the color box.  The palette colors assigned to
> > individual points are also wrong.  That is, the bad coloring in the color box
> > is a correct representation of the coloring assigned to elements of the plot.
> > 
> 
> 
> Yes, I found that changing this colorbar code, it changes also the the
> plot itself, perhaps because of the "set_color(gray);" line inside of the loop?
> 
> 
> > Now it may be that the way I constructed a test palette is not a good way
> > to do it.  I'll show my test below.  
> > 
> > set palette defined (0 "purple", 1 "blue", \
> >                      1 "blue", 2 "dark-green", \
> >                      2 "dark-green", 4 "spring-green", \
> >                      4 "spring-green", 8 "yellow", \
> >                      8 "yellow", 16 "orange", \
> >                      16 "orange", 32 "red" \
> >                      )
> > set xrange [0:32]
> > set cbrange [0:32]
> > set ytics 2
> > set cbtics 2
> > set grid y
> > 
> > plot '+' using 1:1:1 with points lt 7 lc palette
> > 
> > pause -1
> > 
> > # Limiting the number of colors makes it much worse, and clarifies that the
> > # error comes from assigning colors to the palette in equal increments
> > # rather that looking at the requested range boundaries:
> >   set palette maxcolors 7
> >   replot
> > 
> > 
> > So apparently one cannot create a discrete palette this way.
> > Or at least you cannot create a discrete palette with unequal color ranges.
> > Using "show palette palette 7" confirms this, I think.
> > 
> > But maybe there's another way that works better.
> > Perhaps you could create a palette by hand and load it using
> >  set palette file 'mypalette.dat'
> > Unfortunately the documentation is not very helpful as to exactly how color
> > ranges are assigned to colors that are read in from a file.
> >  
> > What commands produced the palette in your problem case?
> 
> 
> 
> I did something along this (I want to change colors exactly at
> values 1,2.5,5,10,....200):
> 
> set term png truecolor small size 770,610
> set out "|cat"
> set pm3d map
> s=-1.0
> d=200-(-1.0)
> set palette defined (  0.0 "#DDDDDD", (-0.01-s)/d "#DDDDDD", \
>                (-0.01-s)/d "white",     (1.0-s)/d "white",  \
>                  (1.0-s)/d "#FFFF00",   (2.5-s)/d "#FFFF00",  \
>                  (2.5-s)/d "#C1FFB4",   (5.0-s)/d "#C1FFB4",  \
>                  (5.0-s)/d "#92E178",  (10.0-s)/d "#92E178",  \
>                 (10.0-s)/d "#6EC36E",  (20.0-s)/d "#6EC36E",  \
>                 (20.0-s)/d "#49913C",  (30.0-s)/d "#49913C",  \
>                 (30.0-s)/d "#577350",  (40.0-s)/d "#577350",  \
>                 (40.0-s)/d "#5050C8",  (50.0-s)/d "#5050C8",  \
>                 (50.0-s)/d "#6600AA", (100.0-s)/d "#6600AA",  \
>                (100.0-s)/d "#993399", (150.0-s)/d "#993399",  \
>                (150.0-s)/d "#AA3366", (199.99-s)/d "#AA3366", (200.0-s)/d "#FF66FF" )
> set cbrange [-1.0:200]
> splot [:][:][:] '/tmp/mydata' matrix notitle
> set output
> 
> 
> > 
> > 	Ethan
> > 
> > 
> >>
> >> 	Ethan
> >>
> >>>
> 
> 
> 

Map of gnuplot usage

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

SourceForge has recently added an interesting feature that tracks
where download requests come from and then produces a world map.
No, they don't use gnuplot to do the plotting :-(

  https://sourceforge.net/projects/gnuplot/files//stats/map

It probably will not come as a surprise that the largest number of
download requests come from the US, Japan, and Germany.
But it seems we have at least a couple of users in places like
Fiji and Bhutan as well.

	Ethan

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[Hans-Bernhard B. <HBB...@t-...>]

On 29.09.2010 19:32, Ethan Merritt wrote:

> If you change the configuration file config.dj2 does it build properly?
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- config.dj2.old      2010-09-29 10:21:42.000000000 -0700
> +++ config.dj2  2010-09-29 10:22:06.000000000 -0700
> @@ -142,7 +142,7 @@
>   #endif
>
>   /* Define to 1 if you have the `isnan' function. */
> -/* #undef HAVE_ISNAN */
> +#define HAVE_ISNAN

FWIW 'configure' doesn't believe DJGPP has isnan().  The autoconf test 
for it yields false because it looks for a function, not a macro, but 
it's done without -lm.  So it finds neither the macro, nor the function 
in libm.a.

I can't currently perform any real tests of my own using DJGPP --- gcc 
4.4.4 consistently crashes on me in term.c with a heap fault.

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

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

On Wednesday 29 September 2010 10:32:23 am Ethan Merritt wrote:
> If you change the configuration file config.dj2 does it build properly?
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> --- config.dj2.old      2010-09-29 10:21:42.000000000 -0700
> +++ config.dj2  2010-09-29 10:22:06.000000000 -0700
> @@ -142,7 +142,7 @@
>  #endif
> 
>  /* Define to 1 if you have the `isnan' function. */
> -/* #undef HAVE_ISNAN */
> +#define HAVE_ISNAN
> 
>  /* Define if you use have kpsexpand (TeX). */
>  /* #undef HAVE_KPSEXPAND */
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> I think this should work, because I now see that there is a call to isnan()
> in datafile.c that is not protected by #ifdef HAVE_ISNAN.  
> So if djpp can compile datafile.c, then it must support isnan().

I made a small mistake.
The unprotected call to isnan() is in graphics.c, not datafile.c.
But still I think it must be true that djpp supports isnan().

	Ethan 

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

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

On Tuesday 28 September 2010 09:58:57 pm Tatsuro MATSUOKA wrote:
> Oops! Djgpp version seems not to support NaN
> 
> The same error  occurred in gnuplot 4.5 cvs.
> But this might be the limitation djgpp environments.
> At the moment, in my opnion, it is better to ignore this issue and consider the treatment in the cvs
> release.

If you change the configuration file config.dj2 does it build properly?

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- config.dj2.old      2010-09-29 10:21:42.000000000 -0700
+++ config.dj2  2010-09-29 10:22:06.000000000 -0700
@@ -142,7 +142,7 @@
 #endif

 /* Define to 1 if you have the `isnan' function. */
-/* #undef HAVE_ISNAN */
+#define HAVE_ISNAN

 /* Define if you use have kpsexpand (TeX). */
 /* #undef HAVE_KPSEXPAND */
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

I think this should work, because I now see that there is a call to isnan()
in datafile.c that is not protected by #ifdef HAVE_ISNAN.  
So if djpp can compile datafile.c, then it must support isnan().

However, I am not certain that the variable NaN will be properly initialized.
So please check the output of "print NaN" after building.

	Ethan

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[Tatsuro M. <tma...@ya...>]

Hello

--- "sfeam (Ethan Merritt)"  wrote:

> On Monday 27 September 2010, Tatsuro MATSUOKA wrote:
> > 
> > I have uploaded new binaries for windows, cygwin and djgpp.
> > http://www.tatsuromatsuoka.com/gnuplot/Eng/gp442/
> 
> Thank you very much for your very quick preparation of these binaries.
> 
> I tried to test the binaries for gp442win32
> using wine running on linux.  
> 
> - The wgnuplot.exe binary seems to work well.
> 
> - Unforunately, the gnuplot.exe binary does not respond to <cr>.
> 
> Is this a failure of the wine emulation, or is it a problem on true Windows also?
> Although this appears like the same failure that was present in 4.5 recently,
> I do not understand how that could happen.  The change the caused the error
> in 4.5 was never applied to 4.4.

For me gnuplot.exe (4.4.2) accepts "Enter" correctly.
*********************
        G N U P L O T
        Version 4.4 patchlevel 2
        last modified Wed Sep 22 12:10:34 PDT 2010
        System: MS-Windows 32 bit

        Copyright (C) 1986-1993, 1998, 2004, 2007-2010
        Thomas Williams, Colin Kelley and many others

        gnuplot home:     http://www.gnuplot.info
        faq, bugs, etc:   type "help seeking-assistance"
        immediate help:   type "help"
        plot window:      hit 'h'

Terminal type set to 'wxt'
gnuplot>
gnuplot> plot sin(x)
gnuplot>
*************************:
And correct sin(x) graph appeared in wxt terminal. 

All demo scripts worked correct at the demo directory with some files generated in the make process. 
It was confirmed using  gnuplot.exe.

For DJGPP  I  only did simple test 

gnuplot> plot sin(x) 
It worked correctly.  
For DjGPP, the some demos does work so that I did not carried out all.dem test. 

But I will try .....

Oops! Djgpp version seems not to support NaN

******************** file candlesticks.dem ********************
Hit return to continue
Hit return to continue
Hit return to continue
         "candlesticks.dem", line 32: undefined variable: NaN

The same error  occurred in gnuplot 4.5 cvs.
But this might be the limitation djgpp environments.
At the moment, in my opnion, it is better to ignore this issue and consider the treatment in the cvs
release.

(If I replace 'NaN' by '1/0' ,"candlesticks.dem" goes well.)


> I did not test the gp442djpp binary because it can not run under linux.
> 
> Should I upload all of these to SourceForge, or do we need a fix
> for the win32 gnuplot.exe?

Before uploading them on SourceForge, wgnuplot.hlp should be modified.
As I wrote, my help workshop does not work correctly.
Therefore Petr kindly generated it. However it lacks the explanation of the cairo based terminals.

The gnuplot.rtf generated by make process includes explanation of only linked terminals.
I suppose that Petr's wgnuplot.hlp is genarated with his own environments.  
Perhaps his build environments lacks libraries for the cairo based terminals.

I have uploaded gnuplot.rtf for MS-help workshop.  If it is complied by the correct version of the
MS-help workshop, the help file will be complete.

Regards

Tatsuro  


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[sfeam (E. Merritt) <eam...@gm...>]

On Monday 27 September 2010, Tatsuro MATSUOKA wrote:
> 
> I have uploaded new binaries for windows, cygwin and djgpp.
> http://www.tatsuromatsuoka.com/gnuplot/Eng/gp442/

Thank you very much for your very quick preparation of these binaries.

I tried to test the binaries for gp442win32
using wine running on linux.  

- The wgnuplot.exe binary seems to work well.

- Unforunately, the gnuplot.exe binary does not respond to <cr>.

Is this a failure of the wine emulation, or is it a problem on true Windows also?
Although this appears like the same failure that was present in 4.5 recently,
I do not understand how that could happen.  The change the caused the error
in 4.5 was never applied to 4.4.

I did not test the gp442djpp binary because it can not run under linux.

Should I upload all of these to SourceForge, or do we need a fix
for the win32 gnuplot.exe?

    thanks,

		Ethan

> Regards
> 
> Tatsuro
> 
> 
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
> 

MacUpdate Dev: gnuplot updated

[<up...@ma...>]

Gnuplot Project,

gnuplot 4.4.1 has just been updated to version 4.4.2 on MacUpdate. Check it out at:

http://www.macupdate.com/info.php/id/16168/gnuplot

Please keep MacUpdate informed of any new Mac version releases of your products, so we can promote them for you. You can update your listing by signing up for a developer tools account:

http://www.macupdate.com/developer/

Partner in our 24-hour promotion of your software through mupromo.com:
http://www.mupromo.com/

-MacUpdate Team
www.macupdate.com

[You're being notified of this update because you're listed as the developer of gnuplot. Please email us if you are not the developer: up...@ma...].

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[Tatsuro M. <tma...@ya...>]

Hello

--- Tatsuro MATSUOKA  wrote:

> Hello
> 
> --- "sfeam (Ethan Merritt)"  wrote:
> 
> > Also my apologies to Tatsuro Matsuoka, whose Windows binaries for
> > 4.4.1 are now out of date only a few days after they were announced.
> 
> OK. 
> 
> I will close current snapshots immediately and prepare new binaries for 4.4.2.

I have uploaded new binaries for windows, cygwin and djgpp.
http://www.tatsuromatsuoka.com/gnuplot/Eng/gp442/

Regards

Tatsuro


--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Re: Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[Tatsuro M. <tma...@ya...>]

Hello

--- "sfeam (Ethan Merritt)"  wrote:

> Also my apologies to Tatsuro Matsuoka, whose Windows binaries for
> 4.4.1 are now out of date only a few days after they were announced.

OK. 

I will close current snapshots immediately and prepare new binaries for 4.4.2.

Regards

Tatsuro  

--------------------------------------
Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
http://pr.mail.yahoo.co.jp/ie8/

Gnuplot 4.4.2 (fixes some problems with 4.4.1)

[sfeam (E. Merritt) <eam...@gm...>]

I have just uploaded to SourceForge a source tarball and documentation for 
Gnuplot version 4.4.2.

Yes, this follows version 4.4.1 very quickly.  
It fixes three problems that were reported immediately after the 4.4.1
release. Two of these seemed serious enough to justify an immediate fix.

1) The color specification syntax "lc N" was broken in 4.4.1.
   This was a regression from 4.4.0

2) A "refresh" command either from the command line or implicitly from
   mousing would cause a segfault if a previous "replot" command had
   been interrupted.

3) There was an error in the clipping of filled curves when a single
   polygonal fill segment straddled one corner of the plot box.


My apologies for missing a report from Christoph Junghans that pointed
out the "lc N" regression before 4.4.1 was actually released.  
Also my apologies to Tatsuro Matsuoka, whose Windows binaries for
4.4.1 are now out of date only a few days after they were announced.

		Ethan Merritt (gnuplot development team)

Re: too coarse stepping when plotting color box

[Manfred S. <man...@gm...>]

Hi Ethan,

> 
> After playing around with non-linear discrete palettes like the one in your
> problem figures, I have become suspicious that the problem is more serious
> than just the resolution of the color box.  The palette colors assigned to
> individual points are also wrong.  That is, the bad coloring in the color box
> is a correct representation of the coloring assigned to elements of the plot.
> 


Yes, I found that changing this colorbar code, it changes also the the
plot itself, perhaps because of the "set_color(gray);" line inside of the loop?


> Now it may be that the way I constructed a test palette is not a good way
> to do it.  I'll show my test below.  
> 
> set palette defined (0 "purple", 1 "blue", \
>                      1 "blue", 2 "dark-green", \
>                      2 "dark-green", 4 "spring-green", \
>                      4 "spring-green", 8 "yellow", \
>                      8 "yellow", 16 "orange", \
>                      16 "orange", 32 "red" \
>                      )
> set xrange [0:32]
> set cbrange [0:32]
> set ytics 2
> set cbtics 2
> set grid y
> 
> plot '+' using 1:1:1 with points lt 7 lc palette
> 
> pause -1
> 
> # Limiting the number of colors makes it much worse, and clarifies that the
> # error comes from assigning colors to the palette in equal increments
> # rather that looking at the requested range boundaries:
>   set palette maxcolors 7
>   replot
> 
> 
> So apparently one cannot create a discrete palette this way.
> Or at least you cannot create a discrete palette with unequal color ranges.
> Using "show palette palette 7" confirms this, I think.
> 
> But maybe there's another way that works better.
> Perhaps you could create a palette by hand and load it using
>  set palette file 'mypalette.dat'
> Unfortunately the documentation is not very helpful as to exactly how color
> ranges are assigned to colors that are read in from a file.
>  
> What commands produced the palette in your problem case?



I did something along this (I want to change colors exactly at
values 1,2.5,5,10,....200):

set term png truecolor small size 770,610
set out "|cat"
set pm3d map
s=-1.0
d=200-(-1.0)
set palette defined (  0.0 "#DDDDDD", (-0.01-s)/d "#DDDDDD", \
               (-0.01-s)/d "white",     (1.0-s)/d "white",  \
                 (1.0-s)/d "#FFFF00",   (2.5-s)/d "#FFFF00",  \
                 (2.5-s)/d "#C1FFB4",   (5.0-s)/d "#C1FFB4",  \
                 (5.0-s)/d "#92E178",  (10.0-s)/d "#92E178",  \
                (10.0-s)/d "#6EC36E",  (20.0-s)/d "#6EC36E",  \
                (20.0-s)/d "#49913C",  (30.0-s)/d "#49913C",  \
                (30.0-s)/d "#577350",  (40.0-s)/d "#577350",  \
                (40.0-s)/d "#5050C8",  (50.0-s)/d "#5050C8",  \
                (50.0-s)/d "#6600AA", (100.0-s)/d "#6600AA",  \
               (100.0-s)/d "#993399", (150.0-s)/d "#993399",  \
               (150.0-s)/d "#AA3366", (199.99-s)/d "#AA3366", (200.0-s)/d "#FF66FF" )
set cbrange [-1.0:200]
splot [:][:][:] '/tmp/mydata' matrix notitle
set output


> 
> 	Ethan
> 
> 
>> As Dan suggested, if there are only 5 colors in the palette then we need
>> only draw 5 rectangles in the color box. Unlike the current code,
>> however, they shouldn't be evenly spaced.  The endpoints of each rectangle
>> should be taken from the palette definition so that they will indeed be
>> placed with perfact accuracy.
>>
>> 	Ethan
>>
>>>

Re: too coarse stepping when plotting color box

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

On Thursday 23 September 2010 11:12:11 am Ethan Merritt wrote:
> On Thursday 23 September 2010 10:52:33 am Manfred Schwarb wrote:
> > Am 22.09.2010 17:32, schrieb sfeam (Ethan Merritt):
> > 
> > >>
> > >> The color transition from one color to the next in discrete palettes
> > >> should be at the exact pixel location.
> > > 
> > > I do not recall seeing the original problem report.
> > > Can you give us a pointer to it?
> > 
> > 
> > http://sourceforge.net/mailarchive/forum.php?thread_name=201009220832.37418.sfeam%40users.sourceforge.net&forum_name=gnuplot-beta
> 
> 
> OK, thanks.
> 
> I think the underlying problem is that the code that draws the color box
> was written to handle continuous color palettes.  The comment "I think
> no one can distinguish more than 128 colors" refers to the minimal step
> within a continuous spectrum.
> 
> I don't have any code to offer, but I think the best solution to the
> problem is to write a different routine for drawing discrete palettes.

After playing around with non-linear discrete palettes like the one in your
problem figures, I have become suspicious that the problem is more serious
than just the resolution of the color box.  The palette colors assigned to
individual points are also wrong.  That is, the bad coloring in the color box
is a correct representation of the coloring assigned to elements of the plot.

Now it may be that the way I constructed a test palette is not a good way
to do it.  I'll show my test below.  

set palette defined (0 "purple", 1 "blue", \
                     1 "blue", 2 "dark-green", \
                     2 "dark-green", 4 "spring-green", \
                     4 "spring-green", 8 "yellow", \
                     8 "yellow", 16 "orange", \
                     16 "orange", 32 "red" \
                     )
set xrange [0:32]
set cbrange [0:32]
set ytics 2
set cbtics 2
set grid y

plot '+' using 1:1:1 with points lt 7 lc palette

pause -1

# Limiting the number of colors makes it much worse, and clarifies that the
# error comes from assigning colors to the palette in equal increments
# rather that looking at the requested range boundaries:
  set palette maxcolors 7
  replot


So apparently one cannot create a discrete palette this way.
Or at least you cannot create a discrete palette with unequal color ranges.
Using "show palette palette 7" confirms this, I think.

But maybe there's another way that works better.
Perhaps you could create a palette by hand and load it using
 set palette file 'mypalette.dat'
Unfortunately the documentation is not very helpful as to exactly how color
ranges are assigned to colors that are read in from a file.
 
What commands produced the palette in your problem case?

	Ethan


> As Dan suggested, if there are only 5 colors in the palette then we need
> only draw 5 rectangles in the color box. Unlike the current code,
> however, they shouldn't be evenly spaced.  The endpoints of each rectangle
> should be taken from the palette definition so that they will indeed be
> placed with perfact accuracy.
> 
> 	Ethan
> 
> > 
> > It is perhaps in your SPAM folder. Sorry for this, I used a wrong 
> > outgoing mail server to send the email.
> > 
> > Probably my hack is wrong indeed, but it works for my use case.
> > 
> > Thanks for looking at it, cheers,
> > 
> > Manfred
> > 
> >  
> > 
> > > 
> > >> There is some obvious cleanup possibility in this function, as
> > >>
> > >> (xy_to - xy_from) == (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot)
> > >>
> > >> so one can drop the redundant if-condition.
> > >>
> > >>
> > >> And when xy_step === 1, one can eliminate this variable completely,
> > >> which would make the loop less heavyweight.
> > > 
> > > One step in coordinate space is not the same as one pixel.
> > > Many terminals track coordinates at higher resolution.
> > > x11 axis coordinates run from [0:4096], but the pixel resolution is
> > > typically  smaller by a factor of 5-10.  The cairo terminals,
> > > including wxt, oversample by a factor of 20.  The canvas terminal
> > > by a factor of 10. And so on.
> > > 
> > > There is currently no way that I know of for the gnuplot core
> > > code to know the pixel resolution of the output device.
> > > 
> > > 	Ethan
> > > 
> > >>
> > >>
> > >> Which would lead to some thing like:
> > >> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> > >> +++ color.c     2010-09-22 09:16:05.000000000 +0200
> > >> @@ -361,9 +361,8 @@
> > >>  static void
> > >>  draw_inside_color_smooth_box_bitmap(FILE * out)
> > >>  {
> > >> -    int steps = 128; /* I think that nobody can distinguish more colours drawn in the palette */
> > >> -    int i, xy, xy2, xy_from, xy_to;
> > >> -    double xy_step, gray;
> > >> +    int i, xy, xy2, xy_from, xy_to, steps;
> > >> +    double gray;
> > >>      gpiPoint corners[4];
> > >>
> > >>      (void) out;                        /* to avoid "unused parameter" warning */
> > >> @@ -378,7 +377,7 @@
> > >>         xy_from = color_box.bounds.xleft;
> > >>         xy_to = color_box.bounds.xright;
> > >>      }
> > >> -    xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) / (double) steps;
> > >> +    steps = xy_to - xy_from;
> > >>
> > >>      for (i = 0; i < steps; i++) {
> > >>         gray = (double) i / steps;      /* colours equidistantly from [0,1] */
> > >> @@ -386,14 +385,14 @@
> > >>             gray = 1 - gray;
> > >>         /* Set the colour (also for terminals which support extended specs). */
> > >>         set_color(gray);
> > >> -       xy = xy_from + (int) (xy_step * i);
> > >> -       xy2 = xy_from + (int) (xy_step * (i + 1));
> > >> +       xy = xy_from + i;
> > >> +       xy2 = xy + 1;
> > >>         if (color_box.rotation == 'v') {
> > >>             corners[0].y = corners[1].y = xy;
> > >> -           corners[2].y = corners[3].y = (i == steps - 1) ? xy_to : xy2;
> > >> +           corners[2].y = corners[3].y = xy2;
> > >>         } else {
> > >>             corners[0].x = corners[3].x = xy;
> > >> -           corners[1].x = corners[2].x = (i == steps - 1) ? xy_to : xy2;
> > >> +           corners[1].x = corners[2].x = xy2;
> > >>         }
> > >>  #ifdef EXTENDED_COLOR_SPECS
> > >>         if (supply_extended_color_specs) {
> > >>
> > >>
> > >> Cheers, Manfred
> > >>
> > >>
> > >>
> > >>> See what the rest of the list thinks.
> > >>>
> > >>> Dan
> > >>>
> > >>>
> > >>> Manfred Schwarb wrote:
> > >>>> Am 21.09.2010 17:24, schrieb Daniel J Sebald:
> > >>>>
> > >>>>
> > >>>>> Something certainly doesn't look right with the original.  However,
> > >>> putting the resolution so high doesn't seem like the best solution.  At the
> > >>> same time, limiting to 128 steps seems restrictive.  I would think it all
> > >>> depends on how the user sets up the color axis.  For example, if only five
> > >>> colors are used, perhaps only five levels are needed, so long as the color
> > >>> ticks align with the color box representation.
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Hmm, no I think it does not depend on the number of used colors.
> > >>>> As soon as one wants a discrete palette, placing has to be accurate to
> > >>>> pixel resolution. 
> > >>>> Which means, if one does not want to calculate each color transition
> > >>>> separately somehow, one has to draw in pixel resolution, i.e.
> > >>>> each pixel line separately.
> > >>>>
> > >>>> The following gives good results for me:
> > >>>>
> > >>>> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> > >>>> +++ color.c     2010-09-21 22:42:01.000000000 +0200
> > >>>> @@ -361,7 +361,7 @@
> > >>>>  static void
> > >>>>  draw_inside_color_smooth_box_bitmap(FILE * out)
> > >>>>  {
> > >>>> -    int steps = 128; /* I think that nobody can distinguish more
> > >>> colours drawn in the palette */
> > >>>> +    int steps;
> > >>>>      int i, xy, xy2, xy_from, xy_to;
> > >>>>      double xy_step, gray;
> > >>>>      gpiPoint corners[4];
> > >>>> @@ -378,6 +378,8 @@
> > >>>>         xy_from = color_box.bounds.xleft;
> > >>>>         xy_to = color_box.bounds.xright;
> > >>>>      }
> > >>>> +    steps=xy_to-xy_from;
> > >>>> +
> > >>>>      xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright -
> > >>> color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) /
> > >>> (double) steps;
> > >>>>
> > >>>>      for (i = 0; i < steps; i++) {
> > >>>>
> > >>>>
> > >>>> In my example, steps becomes 499, which is much smaller
> > >>>> than my insane 12800.
> > >>>> What do you think?
> > >>>>
> > >>>> Cheers,
> > >>>> Manfred
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>> Dan
> > >>>>>
> > >>>>>
> > >>>>> Manfred Schwarb wrote:
> > >>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> when doing 2d plots ("splot") with discrete colors
> > >>>>>> [i.e. 'set palette defined ( 0 "yellow", 0.5 "yellow", 0.5 "red", 1
> > >>> "red" )'],
> > >>>>>> I get some distorted color distribution in the color box.
> > >>>>>>
> > >>>>>> I then discovered that the reason is the coarse stepping
> > >>>>>> in calculating the color values.
> > >>>>>> The following cures it for me:
> > >>>>>>
> > >>>>>> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> > >>>>>> +++ color.c     2010-09-21 14:09:48.000000000 +0200
> > >>>>>> @@ -361,7 +361,7 @@
> > >>>>>> static void
> > >>>>>> draw_inside_color_smooth_box_bitmap(FILE * out)
> > >>>>>> {
> > >>>>>> -    int steps = 128; /* I think that nobody can distinguish more
> > >>> colours drawn in the palette */
> > >>>>>> +    int steps = 12800; /* I think that nobody can distinguish more
> > >>> colours drawn in the palette */
> > >>>>>>     int i, xy, xy2, xy_from, xy_to;
> > >>>>>>     double xy_step, gray;
> > >>>>>>     gpiPoint corners[4];
> > >>>>>>
> > >>>>>>
> > >>>>>> I figured that "steps" has to be in the range of 10000 to get
> > >>>>>> completely accurate color value calculation.
> > >>>>>>
> > >>>>>> Good and bad examples as attachments.
> > >>>>>>
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>> Manfred
> > >>>>>>
> 
> 
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: too coarse stepping when plotting color box

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

On Thursday 23 September 2010 10:52:33 am Manfred Schwarb wrote:
> Am 22.09.2010 17:32, schrieb sfeam (Ethan Merritt):
> 
> > On Wednesday 22 September 2010, Manfred Schwarb wrote:
> >>
> >>> That's the right idea.  You're aiming for the resolution to match the
> >>> number of pixels?
> >>>
> >>
> >> The color transition from one color to the next in discrete palettes
> >> should be at the exact pixel location.
> > 
> > I do not recall seeing the original problem report.
> > Can you give us a pointer to it?
> 
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=201009220832.37418.sfeam%40users.sourceforge.net&forum_name=gnuplot-beta


OK, thanks.

I think the underlying problem is that the code that draws the color box
was written to handle continuous color palettes.  The comment "I think
no one can distinguish more than 128 colors" refers to the minimal step
within a continuous spectrum.

I don't have any code to offer, but I think the best solution to the
problem is to write a different routine for drawing discrete palettes.
As Dan suggested, if there are only 5 colors in the palette then we need
only draw 5 rectangles in the color box. Unlike the current code,
however, they shouldn't be evenly spaced.  The endpoints of each rectangle
should be taken from the palette definition so that they will indeed be
placed with perfact accuracy.

	Ethan

> 
> It is perhaps in your SPAM folder. Sorry for this, I used a wrong 
> outgoing mail server to send the email.
> 
> Probably my hack is wrong indeed, but it works for my use case.
> 
> Thanks for looking at it, cheers,
> 
> Manfred
> 
>  
> 
> > 
> >> There is some obvious cleanup possibility in this function, as
> >>
> >> (xy_to - xy_from) == (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot)
> >>
> >> so one can drop the redundant if-condition.
> >>
> >>
> >> And when xy_step === 1, one can eliminate this variable completely,
> >> which would make the loop less heavyweight.
> > 
> > One step in coordinate space is not the same as one pixel.
> > Many terminals track coordinates at higher resolution.
> > x11 axis coordinates run from [0:4096], but the pixel resolution is
> > typically  smaller by a factor of 5-10.  The cairo terminals,
> > including wxt, oversample by a factor of 20.  The canvas terminal
> > by a factor of 10. And so on.
> > 
> > There is currently no way that I know of for the gnuplot core
> > code to know the pixel resolution of the output device.
> > 
> > 	Ethan
> > 
> >>
> >>
> >> Which would lead to some thing like:
> >> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> >> +++ color.c     2010-09-22 09:16:05.000000000 +0200
> >> @@ -361,9 +361,8 @@
> >>  static void
> >>  draw_inside_color_smooth_box_bitmap(FILE * out)
> >>  {
> >> -    int steps = 128; /* I think that nobody can distinguish more colours drawn in the palette */
> >> -    int i, xy, xy2, xy_from, xy_to;
> >> -    double xy_step, gray;
> >> +    int i, xy, xy2, xy_from, xy_to, steps;
> >> +    double gray;
> >>      gpiPoint corners[4];
> >>
> >>      (void) out;                        /* to avoid "unused parameter" warning */
> >> @@ -378,7 +377,7 @@
> >>         xy_from = color_box.bounds.xleft;
> >>         xy_to = color_box.bounds.xright;
> >>      }
> >> -    xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) / (double) steps;
> >> +    steps = xy_to - xy_from;
> >>
> >>      for (i = 0; i < steps; i++) {
> >>         gray = (double) i / steps;      /* colours equidistantly from [0,1] */
> >> @@ -386,14 +385,14 @@
> >>             gray = 1 - gray;
> >>         /* Set the colour (also for terminals which support extended specs). */
> >>         set_color(gray);
> >> -       xy = xy_from + (int) (xy_step * i);
> >> -       xy2 = xy_from + (int) (xy_step * (i + 1));
> >> +       xy = xy_from + i;
> >> +       xy2 = xy + 1;
> >>         if (color_box.rotation == 'v') {
> >>             corners[0].y = corners[1].y = xy;
> >> -           corners[2].y = corners[3].y = (i == steps - 1) ? xy_to : xy2;
> >> +           corners[2].y = corners[3].y = xy2;
> >>         } else {
> >>             corners[0].x = corners[3].x = xy;
> >> -           corners[1].x = corners[2].x = (i == steps - 1) ? xy_to : xy2;
> >> +           corners[1].x = corners[2].x = xy2;
> >>         }
> >>  #ifdef EXTENDED_COLOR_SPECS
> >>         if (supply_extended_color_specs) {
> >>
> >>
> >> Cheers, Manfred
> >>
> >>
> >>
> >>> See what the rest of the list thinks.
> >>>
> >>> Dan
> >>>
> >>>
> >>> Manfred Schwarb wrote:
> >>>> Am 21.09.2010 17:24, schrieb Daniel J Sebald:
> >>>>
> >>>>
> >>>>> Something certainly doesn't look right with the original.  However,
> >>> putting the resolution so high doesn't seem like the best solution.  At the
> >>> same time, limiting to 128 steps seems restrictive.  I would think it all
> >>> depends on how the user sets up the color axis.  For example, if only five
> >>> colors are used, perhaps only five levels are needed, so long as the color
> >>> ticks align with the color box representation.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> Hmm, no I think it does not depend on the number of used colors.
> >>>> As soon as one wants a discrete palette, placing has to be accurate to
> >>>> pixel resolution. 
> >>>> Which means, if one does not want to calculate each color transition
> >>>> separately somehow, one has to draw in pixel resolution, i.e.
> >>>> each pixel line separately.
> >>>>
> >>>> The following gives good results for me:
> >>>>
> >>>> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> >>>> +++ color.c     2010-09-21 22:42:01.000000000 +0200
> >>>> @@ -361,7 +361,7 @@
> >>>>  static void
> >>>>  draw_inside_color_smooth_box_bitmap(FILE * out)
> >>>>  {
> >>>> -    int steps = 128; /* I think that nobody can distinguish more
> >>> colours drawn in the palette */
> >>>> +    int steps;
> >>>>      int i, xy, xy2, xy_from, xy_to;
> >>>>      double xy_step, gray;
> >>>>      gpiPoint corners[4];
> >>>> @@ -378,6 +378,8 @@
> >>>>         xy_from = color_box.bounds.xleft;
> >>>>         xy_to = color_box.bounds.xright;
> >>>>      }
> >>>> +    steps=xy_to-xy_from;
> >>>> +
> >>>>      xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright -
> >>> color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) /
> >>> (double) steps;
> >>>>
> >>>>      for (i = 0; i < steps; i++) {
> >>>>
> >>>>
> >>>> In my example, steps becomes 499, which is much smaller
> >>>> than my insane 12800.
> >>>> What do you think?
> >>>>
> >>>> Cheers,
> >>>> Manfred
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Dan
> >>>>>
> >>>>>
> >>>>> Manfred Schwarb wrote:
> >>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> when doing 2d plots ("splot") with discrete colors
> >>>>>> [i.e. 'set palette defined ( 0 "yellow", 0.5 "yellow", 0.5 "red", 1
> >>> "red" )'],
> >>>>>> I get some distorted color distribution in the color box.
> >>>>>>
> >>>>>> I then discovered that the reason is the coarse stepping
> >>>>>> in calculating the color values.
> >>>>>> The following cures it for me:
> >>>>>>
> >>>>>> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> >>>>>> +++ color.c     2010-09-21 14:09:48.000000000 +0200
> >>>>>> @@ -361,7 +361,7 @@
> >>>>>> static void
> >>>>>> draw_inside_color_smooth_box_bitmap(FILE * out)
> >>>>>> {
> >>>>>> -    int steps = 128; /* I think that nobody can distinguish more
> >>> colours drawn in the palette */
> >>>>>> +    int steps = 12800; /* I think that nobody can distinguish more
> >>> colours drawn in the palette */
> >>>>>>     int i, xy, xy2, xy_from, xy_to;
> >>>>>>     double xy_step, gray;
> >>>>>>     gpiPoint corners[4];
> >>>>>>
> >>>>>>
> >>>>>> I figured that "steps" has to be in the range of 10000 to get
> >>>>>> completely accurate color value calculation.
> >>>>>>
> >>>>>> Good and bad examples as attachments.
> >>>>>>
> >>>>>>
> >>>>>> Cheers,
> >>>>>> Manfred
> >>>>>>


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: too coarse stepping when plotting color box

[Manfred S. <man...@gm...>]

Am 22.09.2010 17:32, schrieb sfeam (Ethan Merritt):

> On Wednesday 22 September 2010, Manfred Schwarb wrote:
>>
>>> That's the right idea.  You're aiming for the resolution to match the
>>> number of pixels?
>>>
>>
>> The color transition from one color to the next in discrete palettes
>> should be at the exact pixel location.
> 
> I do not recall seeing the original problem report.
> Can you give us a pointer to it?


http://sourceforge.net/mailarchive/forum.php?thread_name=201009220832.37418.sfeam%40users.sourceforge.net&forum_name=gnuplot-beta

It is perhaps in your SPAM folder. Sorry for this, I used a wrong 
outgoing mail server to send the email.

Probably my hack is wrong indeed, but it works for my use case.

Thanks for looking at it, cheers,

Manfred

 

> 
>> There is some obvious cleanup possibility in this function, as
>>
>> (xy_to - xy_from) == (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot)
>>
>> so one can drop the redundant if-condition.
>>
>>
>> And when xy_step === 1, one can eliminate this variable completely,
>> which would make the loop less heavyweight.
> 
> One step in coordinate space is not the same as one pixel.
> Many terminals track coordinates at higher resolution.
> x11 axis coordinates run from [0:4096], but the pixel resolution is
> typically  smaller by a factor of 5-10.  The cairo terminals,
> including wxt, oversample by a factor of 20.  The canvas terminal
> by a factor of 10. And so on.
> 
> There is currently no way that I know of for the gnuplot core
> code to know the pixel resolution of the output device.
> 
> 	Ethan
> 
>>
>>
>> Which would lead to some thing like:
>> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
>> +++ color.c     2010-09-22 09:16:05.000000000 +0200
>> @@ -361,9 +361,8 @@
>>  static void
>>  draw_inside_color_smooth_box_bitmap(FILE * out)
>>  {
>> -    int steps = 128; /* I think that nobody can distinguish more colours drawn in the palette */
>> -    int i, xy, xy2, xy_from, xy_to;
>> -    double xy_step, gray;
>> +    int i, xy, xy2, xy_from, xy_to, steps;
>> +    double gray;
>>      gpiPoint corners[4];
>>
>>      (void) out;                        /* to avoid "unused parameter" warning */
>> @@ -378,7 +377,7 @@
>>         xy_from = color_box.bounds.xleft;
>>         xy_to = color_box.bounds.xright;
>>      }
>> -    xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) / (double) steps;
>> +    steps = xy_to - xy_from;
>>
>>      for (i = 0; i < steps; i++) {
>>         gray = (double) i / steps;      /* colours equidistantly from [0,1] */
>> @@ -386,14 +385,14 @@
>>             gray = 1 - gray;
>>         /* Set the colour (also for terminals which support extended specs). */
>>         set_color(gray);
>> -       xy = xy_from + (int) (xy_step * i);
>> -       xy2 = xy_from + (int) (xy_step * (i + 1));
>> +       xy = xy_from + i;
>> +       xy2 = xy + 1;
>>         if (color_box.rotation == 'v') {
>>             corners[0].y = corners[1].y = xy;
>> -           corners[2].y = corners[3].y = (i == steps - 1) ? xy_to : xy2;
>> +           corners[2].y = corners[3].y = xy2;
>>         } else {
>>             corners[0].x = corners[3].x = xy;
>> -           corners[1].x = corners[2].x = (i == steps - 1) ? xy_to : xy2;
>> +           corners[1].x = corners[2].x = xy2;
>>         }
>>  #ifdef EXTENDED_COLOR_SPECS
>>         if (supply_extended_color_specs) {
>>
>>
>> Cheers, Manfred
>>
>>
>>
>>> See what the rest of the list thinks.
>>>
>>> Dan
>>>
>>>
>>> Manfred Schwarb wrote:
>>>> Am 21.09.2010 17:24, schrieb Daniel J Sebald:
>>>>
>>>>
>>>>> Something certainly doesn't look right with the original.  However,
>>> putting the resolution so high doesn't seem like the best solution.  At the
>>> same time, limiting to 128 steps seems restrictive.  I would think it all
>>> depends on how the user sets up the color axis.  For example, if only five
>>> colors are used, perhaps only five levels are needed, so long as the color
>>> ticks align with the color box representation.
>>>>>
>>>>
>>>>
>>>>
>>>> Hmm, no I think it does not depend on the number of used colors.
>>>> As soon as one wants a discrete palette, placing has to be accurate to
>>>> pixel resolution. 
>>>> Which means, if one does not want to calculate each color transition
>>>> separately somehow, one has to draw in pixel resolution, i.e.
>>>> each pixel line separately.
>>>>
>>>> The following gives good results for me:
>>>>
>>>> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
>>>> +++ color.c     2010-09-21 22:42:01.000000000 +0200
>>>> @@ -361,7 +361,7 @@
>>>>  static void
>>>>  draw_inside_color_smooth_box_bitmap(FILE * out)
>>>>  {
>>>> -    int steps = 128; /* I think that nobody can distinguish more
>>> colours drawn in the palette */
>>>> +    int steps;
>>>>      int i, xy, xy2, xy_from, xy_to;
>>>>      double xy_step, gray;
>>>>      gpiPoint corners[4];
>>>> @@ -378,6 +378,8 @@
>>>>         xy_from = color_box.bounds.xleft;
>>>>         xy_to = color_box.bounds.xright;
>>>>      }
>>>> +    steps=xy_to-xy_from;
>>>> +
>>>>      xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright -
>>> color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) /
>>> (double) steps;
>>>>
>>>>      for (i = 0; i < steps; i++) {
>>>>
>>>>
>>>> In my example, steps becomes 499, which is much smaller
>>>> than my insane 12800.
>>>> What do you think?
>>>>
>>>> Cheers,
>>>> Manfred
>>>>
>>>>
>>>>
>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> Manfred Schwarb wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> when doing 2d plots ("splot") with discrete colors
>>>>>> [i.e. 'set palette defined ( 0 "yellow", 0.5 "yellow", 0.5 "red", 1
>>> "red" )'],
>>>>>> I get some distorted color distribution in the color box.
>>>>>>
>>>>>> I then discovered that the reason is the coarse stepping
>>>>>> in calculating the color values.
>>>>>> The following cures it for me:
>>>>>>
>>>>>> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
>>>>>> +++ color.c     2010-09-21 14:09:48.000000000 +0200
>>>>>> @@ -361,7 +361,7 @@
>>>>>> static void
>>>>>> draw_inside_color_smooth_box_bitmap(FILE * out)
>>>>>> {
>>>>>> -    int steps = 128; /* I think that nobody can distinguish more
>>> colours drawn in the palette */
>>>>>> +    int steps = 12800; /* I think that nobody can distinguish more
>>> colours drawn in the palette */
>>>>>>     int i, xy, xy2, xy_from, xy_to;
>>>>>>     double xy_step, gray;
>>>>>>     gpiPoint corners[4];
>>>>>>
>>>>>>
>>>>>> I figured that "steps" has to be in the range of 10000 to get
>>>>>> completely accurate color value calculation.
>>>>>>
>>>>>> Good and bad examples as attachments.
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Manfred
>>>>>>

Re: too coarse stepping when plotting color box

[sfeam (E. Merritt) <eam...@gm...>]

On Wednesday 22 September 2010, Manfred Schwarb wrote:
> 
> > That's the right idea.  You're aiming for the resolution to match the
> > number of pixels?
> > 
> 
> The color transition from one color to the next in discrete palettes
> should be at the exact pixel location.

I do not recall seeing the original problem report.
Can you give us a pointer to it?

> There is some obvious cleanup possibility in this function, as
> 
> (xy_to - xy_from) == (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot)
> 
> so one can drop the redundant if-condition.
> 
> 
> And when xy_step === 1, one can eliminate this variable completely,
> which would make the loop less heavyweight.

One step in coordinate space is not the same as one pixel.
Many terminals track coordinates at higher resolution.
x11 axis coordinates run from [0:4096], but the pixel resolution is
typically  smaller by a factor of 5-10.  The cairo terminals,
including wxt, oversample by a factor of 20.  The canvas terminal
by a factor of 10. And so on.

There is currently no way that I know of for the gnuplot core
code to know the pixel resolution of the output device.

	Ethan

> 
> 
> Which would lead to some thing like:
> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> +++ color.c     2010-09-22 09:16:05.000000000 +0200
> @@ -361,9 +361,8 @@
>  static void
>  draw_inside_color_smooth_box_bitmap(FILE * out)
>  {
> -    int steps = 128; /* I think that nobody can distinguish more colours drawn in the palette */
> -    int i, xy, xy2, xy_from, xy_to;
> -    double xy_step, gray;
> +    int i, xy, xy2, xy_from, xy_to, steps;
> +    double gray;
>      gpiPoint corners[4];
> 
>      (void) out;                        /* to avoid "unused parameter" warning */
> @@ -378,7 +377,7 @@
>         xy_from = color_box.bounds.xleft;
>         xy_to = color_box.bounds.xright;
>      }
> -    xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) / (double) steps;
> +    steps = xy_to - xy_from;
> 
>      for (i = 0; i < steps; i++) {
>         gray = (double) i / steps;      /* colours equidistantly from [0,1] */
> @@ -386,14 +385,14 @@
>             gray = 1 - gray;
>         /* Set the colour (also for terminals which support extended specs). */
>         set_color(gray);
> -       xy = xy_from + (int) (xy_step * i);
> -       xy2 = xy_from + (int) (xy_step * (i + 1));
> +       xy = xy_from + i;
> +       xy2 = xy + 1;
>         if (color_box.rotation == 'v') {
>             corners[0].y = corners[1].y = xy;
> -           corners[2].y = corners[3].y = (i == steps - 1) ? xy_to : xy2;
> +           corners[2].y = corners[3].y = xy2;
>         } else {
>             corners[0].x = corners[3].x = xy;
> -           corners[1].x = corners[2].x = (i == steps - 1) ? xy_to : xy2;
> +           corners[1].x = corners[2].x = xy2;
>         }
>  #ifdef EXTENDED_COLOR_SPECS
>         if (supply_extended_color_specs) {
> 
> 
> Cheers, Manfred
> 
> 
> 
> > See what the rest of the list thinks.
> > 
> > Dan
> > 
> > 
> > Manfred Schwarb wrote:
> > > Am 21.09.2010 17:24, schrieb Daniel J Sebald:
> > > 
> > > 
> > >>Something certainly doesn't look right with the original.  However,
> > putting the resolution so high doesn't seem like the best solution.  At the
> > same time, limiting to 128 steps seems restrictive.  I would think it all
> > depends on how the user sets up the color axis.  For example, if only five
> > colors are used, perhaps only five levels are needed, so long as the color
> > ticks align with the color box representation.
> > >>
> > > 
> > > 
> > > 
> > > Hmm, no I think it does not depend on the number of used colors.
> > > As soon as one wants a discrete palette, placing has to be accurate to
> > > pixel resolution. 
> > > Which means, if one does not want to calculate each color transition
> > > separately somehow, one has to draw in pixel resolution, i.e.
> > > each pixel line separately.
> > > 
> > > The following gives good results for me:
> > > 
> > > --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> > > +++ color.c     2010-09-21 22:42:01.000000000 +0200
> > > @@ -361,7 +361,7 @@
> > >  static void
> > >  draw_inside_color_smooth_box_bitmap(FILE * out)
> > >  {
> > > -    int steps = 128; /* I think that nobody can distinguish more
> > colours drawn in the palette */
> > > +    int steps;
> > >      int i, xy, xy2, xy_from, xy_to;
> > >      double xy_step, gray;
> > >      gpiPoint corners[4];
> > > @@ -378,6 +378,8 @@
> > >         xy_from = color_box.bounds.xleft;
> > >         xy_to = color_box.bounds.xright;
> > >      }
> > > +    steps=xy_to-xy_from;
> > > +
> > >      xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright -
> > color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) /
> > (double) steps;
> > > 
> > >      for (i = 0; i < steps; i++) {
> > > 
> > > 
> > > In my example, steps becomes 499, which is much smaller
> > > than my insane 12800.
> > > What do you think?
> > > 
> > > Cheers,
> > > Manfred
> > > 
> > > 
> > > 
> > > 
> > >>Dan
> > >>
> > >>
> > >>Manfred Schwarb wrote:
> > >>
> > >>>Hi,
> > >>>
> > >>>when doing 2d plots ("splot") with discrete colors
> > >>>[i.e. 'set palette defined ( 0 "yellow", 0.5 "yellow", 0.5 "red", 1
> > "red" )'],
> > >>>I get some distorted color distribution in the color box.
> > >>>
> > >>>I then discovered that the reason is the coarse stepping
> > >>>in calculating the color values.
> > >>>The following cures it for me:
> > >>>
> > >>>--- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> > >>>+++ color.c     2010-09-21 14:09:48.000000000 +0200
> > >>>@@ -361,7 +361,7 @@
> > >>> static void
> > >>> draw_inside_color_smooth_box_bitmap(FILE * out)
> > >>> {
> > >>>-    int steps = 128; /* I think that nobody can distinguish more
> > colours drawn in the palette */
> > >>>+    int steps = 12800; /* I think that nobody can distinguish more
> > colours drawn in the palette */
> > >>>     int i, xy, xy2, xy_from, xy_to;
> > >>>     double xy_step, gray;
> > >>>     gpiPoint corners[4];
> > >>>
> > >>>
> > >>>I figured that "steps" has to be in the range of 10000 to get
> > >>>completely accurate color value calculation.
> > >>>
> > >>>Good and bad examples as attachments.
> > >>>
> > >>>
> > >>>Cheers,
> > >>>Manfred
> > >>>
> 
> 

Re: too coarse stepping when plotting color box

[Manfred S. <man...@gm...>]

> That's the right idea.  You're aiming for the resolution to match the
> number of pixels?
> 

The color transition from one color to the next in discrete palettes
should be at the exact pixel location.

There is some obvious cleanup possibility in this function, as

(xy_to - xy_from) == (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot)

so one can drop the redundant if-condition.


And when xy_step === 1, one can eliminate this variable completely,
which would make the loop less heavyweight.


Which would lead to some thing like:
--- color.c.orig        2010-09-21 14:09:41.000000000 +0200
+++ color.c     2010-09-22 09:16:05.000000000 +0200
@@ -361,9 +361,8 @@
 static void
 draw_inside_color_smooth_box_bitmap(FILE * out)
 {
-    int steps = 128; /* I think that nobody can distinguish more colours drawn in the palette */
-    int i, xy, xy2, xy_from, xy_to;
-    double xy_step, gray;
+    int i, xy, xy2, xy_from, xy_to, steps;
+    double gray;
     gpiPoint corners[4];

     (void) out;                        /* to avoid "unused parameter" warning */
@@ -378,7 +377,7 @@
        xy_from = color_box.bounds.xleft;
        xy_to = color_box.bounds.xright;
     }
-    xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) / (double) steps;
+    steps = xy_to - xy_from;

     for (i = 0; i < steps; i++) {
        gray = (double) i / steps;      /* colours equidistantly from [0,1] */
@@ -386,14 +385,14 @@
            gray = 1 - gray;
        /* Set the colour (also for terminals which support extended specs). */
        set_color(gray);
-       xy = xy_from + (int) (xy_step * i);
-       xy2 = xy_from + (int) (xy_step * (i + 1));
+       xy = xy_from + i;
+       xy2 = xy + 1;
        if (color_box.rotation == 'v') {
            corners[0].y = corners[1].y = xy;
-           corners[2].y = corners[3].y = (i == steps - 1) ? xy_to : xy2;
+           corners[2].y = corners[3].y = xy2;
        } else {
            corners[0].x = corners[3].x = xy;
-           corners[1].x = corners[2].x = (i == steps - 1) ? xy_to : xy2;
+           corners[1].x = corners[2].x = xy2;
        }
 #ifdef EXTENDED_COLOR_SPECS
        if (supply_extended_color_specs) {


Cheers, Manfred



> See what the rest of the list thinks.
> 
> Dan
> 
> 
> Manfred Schwarb wrote:
> > Am 21.09.2010 17:24, schrieb Daniel J Sebald:
> > 
> > 
> >>Something certainly doesn't look right with the original.  However,
> putting the resolution so high doesn't seem like the best solution.  At the
> same time, limiting to 128 steps seems restrictive.  I would think it all
> depends on how the user sets up the color axis.  For example, if only five
> colors are used, perhaps only five levels are needed, so long as the color
> ticks align with the color box representation.
> >>
> > 
> > 
> > 
> > Hmm, no I think it does not depend on the number of used colors.
> > As soon as one wants a discrete palette, placing has to be accurate to
> > pixel resolution. 
> > Which means, if one does not want to calculate each color transition
> > separately somehow, one has to draw in pixel resolution, i.e.
> > each pixel line separately.
> > 
> > The following gives good results for me:
> > 
> > --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> > +++ color.c     2010-09-21 22:42:01.000000000 +0200
> > @@ -361,7 +361,7 @@
> >  static void
> >  draw_inside_color_smooth_box_bitmap(FILE * out)
> >  {
> > -    int steps = 128; /* I think that nobody can distinguish more
> colours drawn in the palette */
> > +    int steps;
> >      int i, xy, xy2, xy_from, xy_to;
> >      double xy_step, gray;
> >      gpiPoint corners[4];
> > @@ -378,6 +378,8 @@
> >         xy_from = color_box.bounds.xleft;
> >         xy_to = color_box.bounds.xright;
> >      }
> > +    steps=xy_to-xy_from;
> > +
> >      xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright -
> color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) /
> (double) steps;
> > 
> >      for (i = 0; i < steps; i++) {
> > 
> > 
> > In my example, steps becomes 499, which is much smaller
> > than my insane 12800.
> > What do you think?
> > 
> > Cheers,
> > Manfred
> > 
> > 
> > 
> > 
> >>Dan
> >>
> >>
> >>Manfred Schwarb wrote:
> >>
> >>>Hi,
> >>>
> >>>when doing 2d plots ("splot") with discrete colors
> >>>[i.e. 'set palette defined ( 0 "yellow", 0.5 "yellow", 0.5 "red", 1
> "red" )'],
> >>>I get some distorted color distribution in the color box.
> >>>
> >>>I then discovered that the reason is the coarse stepping
> >>>in calculating the color values.
> >>>The following cures it for me:
> >>>
> >>>--- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> >>>+++ color.c     2010-09-21 14:09:48.000000000 +0200
> >>>@@ -361,7 +361,7 @@
> >>> static void
> >>> draw_inside_color_smooth_box_bitmap(FILE * out)
> >>> {
> >>>-    int steps = 128; /* I think that nobody can distinguish more
> colours drawn in the palette */
> >>>+    int steps = 12800; /* I think that nobody can distinguish more
> colours drawn in the palette */
> >>>     int i, xy, xy2, xy_from, xy_to;
> >>>     double xy_step, gray;
> >>>     gpiPoint corners[4];
> >>>
> >>>
> >>>I figured that "steps" has to be in the range of 10000 to get
> >>>completely accurate color value calculation.
> >>>
> >>>Good and bad examples as attachments.
> >>>
> >>>
> >>>Cheers,
> >>>Manfred
> >>>

-- 
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl

Re: too coarse stepping when plotting color box

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

That's the right idea.  You're aiming for the resolution to match the number of pixels?

See what the rest of the list thinks.

Dan


Manfred Schwarb wrote:
> Am 21.09.2010 17:24, schrieb Daniel J Sebald:
> 
> 
>>Something certainly doesn't look right with the original.  However, putting the resolution so high doesn't seem like the best solution.  At the same time, limiting to 128 steps seems restrictive.  I would think it all depends on how the user sets up the color axis.  For example, if only five colors are used, perhaps only five levels are needed, so long as the color ticks align with the color box representation.
>>
> 
> 
> 
> Hmm, no I think it does not depend on the number of used colors.
> As soon as one wants a discrete palette, placing has to be accurate to
> pixel resolution. 
> Which means, if one does not want to calculate each color transition
> separately somehow, one has to draw in pixel resolution, i.e.
> each pixel line separately.
> 
> The following gives good results for me:
> 
> --- color.c.orig        2010-09-21 14:09:41.000000000 +0200
> +++ color.c     2010-09-21 22:42:01.000000000 +0200
> @@ -361,7 +361,7 @@
>  static void
>  draw_inside_color_smooth_box_bitmap(FILE * out)
>  {
> -    int steps = 128; /* I think that nobody can distinguish more colours drawn in the palette */
> +    int steps;
>      int i, xy, xy2, xy_from, xy_to;
>      double xy_step, gray;
>      gpiPoint corners[4];
> @@ -378,6 +378,8 @@
>         xy_from = color_box.bounds.xleft;
>         xy_to = color_box.bounds.xright;
>      }
> +    steps=xy_to-xy_from;
> +
>      xy_step = (color_box.rotation == 'h' ? color_box.bounds.xright - color_box.bounds.xleft : color_box.bounds.ytop - color_box.bounds.ybot) / (double) steps;
> 
>      for (i = 0; i < steps; i++) {
> 
> 
> In my example, steps becomes 499, which is much smaller
> than my insane 12800.
> What do you think?
> 
> Cheers,
> Manfred
> 
> 
> 
> 
>>Dan
>>
>>
>>Manfred Schwarb wrote:
>>
>>>Hi,
>>>
>>>when doing 2d plots ("splot") with discrete colors
>>>[i.e. 'set palette defined ( 0 "yellow", 0.5 "yellow", 0.5 "red", 1 "red" )'],
>>>I get some distorted color distribution in the color box.
>>>
>>>I then discovered that the reason is the coarse stepping
>>>in calculating the color values.
>>>The following cures it for me:
>>>
>>>--- color.c.orig        2010-09-21 14:09:41.000000000 +0200
>>>+++ color.c     2010-09-21 14:09:48.000000000 +0200
>>>@@ -361,7 +361,7 @@
>>> static void
>>> draw_inside_color_smooth_box_bitmap(FILE * out)
>>> {
>>>-    int steps = 128; /* I think that nobody can distinguish more colours drawn in the palette */
>>>+    int steps = 12800; /* I think that nobody can distinguish more colours drawn in the palette */
>>>     int i, xy, xy2, xy_from, xy_to;
>>>     double xy_step, gray;
>>>     gpiPoint corners[4];
>>>
>>>
>>>I figured that "steps" has to be in the range of 10000 to get
>>>completely accurate color value calculation.
>>>
>>>Good and bad examples as attachments.
>>>
>>>
>>>Cheers,
>>>Manfred
>>>
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> 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://www(DOT)dansebald(DOT)com