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