Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.graphics.apps.gnuplot > #2168

Re: Bug on palette

Show all headers | View raw

Vasilis wrote:

> Dear Ethan,
> 
> thank you for your reply, but i think it is a problem that could be
> fixed. In any case it was working back in 4.2.

Your particular case was working in 4.2, but there are many other
cases that were not.  In particular the code in 4.2 assumed that the
width of each color interval was identical, and produced poor
results when they were not.

I should clarify that the problem you encountered arises specifically
from mixing the "maxcolors" option with a palette containing multiple
interpolation ranges.  The data z value is mapped onto a range [0:1]
and then truncated to the nearest interval (1./maxcolors).  But if the
palette is defined by several distinct interpolation ranges, as in 
your case, this truncation can cause the value to shift from one
interpolation range to the next.  If this happens, the color is 
chosen from the "wrong" sub-palette.  This won't happen if the 
palette is defined as a single continuous interval.  It also should
not happen (or happen only rarely due to precision errors)
if maxcolors is evenly divisible by the number of palette intervals.
In your case there are 4 equally spaced palette intervals, so setting
maxcolors to 28 or 30 or any multiple of 4 would avoid the problem.

As I said, this problem case is detectable. But I am not convinced
there is a unique resolution that is correct in the general case.

> Setting a low number of maxcolor is extremely important when we make
> colorplots with dose (output of monte carlo physics programs). Setting
> a low number of maxcolors allows you to perfectly distinguish visually
> various regions of interest in your plot. If you use a smooth palette,
> you get a pleasing result for the eye but it is very hard to read it
> (e.g get the value-range of a pixel). We wonder is this color or the
> next one? Almost all scientific programs that I know (monte carlo,
> molecular dynamics, finite elements etc) they use the same approach
> they define a limited number of colors (16-30). Further more since we
> plot always in 'log cb' we try to align the colors with the decades
> e.g. 4-5 colors per decade.
> 
> Maybe as you proposed using "N separate linetype colors and plot with
> linecolor variable"  could be a solution for us. Could you please give
> me an example.

Sounds like an interesting assignment :-)  I'll look into it.

By the way, the "test palette" command is useful for checking your
palette definition without doing an actual plot.

	Ethan

Back to comp.graphics.apps.gnuplot | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Bug on palette Vasilis <vvlachoudis@gmail.com> - 2013-10-18 03:32 -0700
  Re: Bug on palette Ethan A Merritt <merritt@u.washington.edu> - 2013-10-18 17:18 -0700
    Re: Bug on palette Vasilis <vvlachoudis@gmail.com> - 2013-10-19 01:28 -0700
      Re: Bug on palette Olaf Schultz <o.schultz@enhydralutris.de> - 2013-10-19 13:28 +0200
      Re: Bug on palette Olaf Schultz <o.schultz@enhydralutris.de> - 2013-10-19 13:37 +0200
      Re: Bug on palette Ethan A Merritt <EAMerritt@gmail.com> - 2013-10-19 10:34 -0700
        Re: Bug on palette Ethan A Merritt <EAMerritt@gmail.com> - 2013-10-19 11:28 -0700
          Re: Bug on palette Vasilis <vvlachoudis@gmail.com> - 2013-10-20 05:27 -0700
          Re: Bug on palette Vasilis <vvlachoudis@gmail.com> - 2013-10-20 08:59 -0700
          Re: Bug on palette Vasilis <vvlachoudis@gmail.com> - 2013-10-20 09:37 -0700
            Re: Bug on palette sfeam <sfeam@users.sourceforge.net> - 2013-10-20 12:05 -0700
              Re: Bug on palette Vasilis <vvlachoudis@gmail.com> - 2013-10-21 00:28 -0700
                Re: Bug on palette sfeam <sfeam@users.sourceforge.net> - 2013-10-22 14:20 -0700
                Re: Bug on palette Vasilis <vvlachoudis@gmail.com> - 2013-10-23 00:42 -0700

csiph-web