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
> > >>>
> 
>