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

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

Re: Bug on palette

Show all headers | View raw

Vasilis wrote:

> Firefox decided to die before my last post, so here it comes again.
> 
> After looking this function I have the feeling that it makes no-sense
> to alter inside the if() the quantized gray value, to the mid-value of
> the matching interpolation range. Why? The two things are not related
> to my mind.

I agree that the current code works badly for your case and should
be fixed.  But I don't know of a perfect fix.  Everything I have come
up with fails for some class of reasonable palette definitions.
I welcome your suggestions.

As to why it switches to the midpoint of an adjacent range, that was
added to handle the case where 
1) The palette contains multiple segments (each treated as a gradient)
2) One or more segments are small compared to the others.

An example is a log scale palette with intervals
   0 1 2 4 8 16 32 64 ...
You might think maxcolors=8 would be reasonable, but without the
extra check all ranges below 4 would be treated as equal to 0.

> However I am sure you have a good reason for that, so in this case a
> more correct way would be: if (degray < sm_palette.gradient[j].pos)
> degray = sm_palette.gradient[j].pos;
> else if (degray > sm_palette.gradient[j+1].pos)
> degray = sm_palette.gradient[j+1].pos;

That code still has the effect of skipping small color ranges entirely.
 
> Last thing, doing the check linear for every plotted pixel is a real
> CPU-waste. Why not doing it with bisect as in the
> interpolate_color_from_gray()

It is linear in the number of palette segments, which is usually small.

... 

After thinking about this some more, I am trying out a variant that
works as follows:

1) If the range of the smallest palette segment is still larger than
   (total_range/maxcolors) then we don't have to worry about missing
   that segment due to truncation.  This returns to the version 4.2
   behavior for palettes with equal-width gradient segments and 
   maxcolors >= number of segments.  This condition need only be checked
   once at the time the palette is defined.

2) If condition (1) is not satisfied, then we check to see if the
   current gray value lies in one of the too-small gradient intervals.
   If so, set it to the segment midpoint; 
   if not, let the truncated value stand.

This certainly handles your current problem case "perfectly", because
it is covered by condition (1).  It also does a good but not perfect
job with the binary log scale example abouve. But it is not hard to come
up with examples where it behaves badly. In particular it produces odd
results if the truncated gray value happens to lie inside one of the
small palette segments, but the true gray value does not.
Here is an extreme case example:

   set palette defined (0 "white", 0.49 "blue", \
                        0.49 "black", 0.51 "black", \
                        0.51 "white", 1.0 "red")
   set palette maxcolors 9
   test palette

The intent is clearly to have several low-range segments distinguished
by blue saturation and several high-range segments distinguished by
red saturation, with black indicating some mid-point condition.
And that's exactly what you get for even-valued of maxcolors.
But for odd-valued maxcolor the supposedly narrow range of black
values becomes disproportionately wide.

This example case is also handled poorly by the current code, so
the revised algorithm is clearly an improvement.  But I'd like to do
even better if possible.

	Ethan

> Cheers
> Vasilis

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