Loading ...
Sorry, an error occurred while loading the content.

1643Re: corrupted symbols: analysis and solution

Expand Messages
  • dagoldman
    Oct 10, 2005
    • 0 Attachment
      If you want me to fiddle further, let me know.

      By the way, Andrew was right that rounding errors
      were involved. There were tiny errors in the internal
      representation of floating point numbers such as 0.5,
      totally independent of gd or ploticus. For example:

      0.49999999 x 3 rounds to 1
      0.50000001 x 3 rounds to 2

      The result was the irregularities we noticed.

      I wrote some separate rounding functions to take care
      of this. Both of the above get rounded to 0.5 exactly.
      Maybe these kind of rounding problems might crop up
      elsewhere in ploticus, in case useful.

      Daniel

      --- In ploticus@yahoogroups.com, "Stephen C. Grubb" <scg@j...> wrote:
      >
      >
      > Daniel,
      > thanks, this should be enough to get started with
      >
      > Steve
      >
      > On Sun, 9 Oct 2005, dagoldman wrote:
      >
      > > I took the code snippets and expanded them into a
      > > program for making the templates Steve mentioned.
      > >
      > > It makes a whole bunch of templates. Don't worry about
      > > the ones with gaps. The program loops multiple times with
      > > a varying stringency factor (segDelta) for when to make
      > > a segment point. The ones at the end don't have gaps
      > > (segDelta = 0.51). I erred on the side of including
      > > too many templates, to give more choices.
      > >
      > > code - http://www.ehdp.com/out/pl/pl-temps.c
      > > output - http://www.ehdp.com/out/pl/10-8-05.txt
      > >
      > > I think the templates hard-coded into a header file,
      > > as Steve suggested. The irregular ones might need
      > > some hand editing, to take out some of the border
      > > points to make look cleaner, or add some border
      > > points to the ones with gaps.
      > >
      > > Let me know if need something different.
      > >
      > > Daniel
      > >
      > > --- In ploticus@yahoogroups.com, Andrew Schulman <andrex@a...>
      wrote:
      > > >
      > > > > here's a tentative plan for a solution for the lop-sided data
      > > point
      > > > > symbols problem.
      > > > >
      > > > > grgd.c and x11.c (the two raster-type devices that ploticus
      > > supports)
      > > > > would each have a new function for rendering a pixel-based
      data
      > > point
      > > > > symbol at a specific location.. they would share a low level
      > > function that
      > > > > would render the data point symbol by using templates to color
      > > specific
      > > > > pixels centered around a data point.
      > > >
      > > > Sounds good.
      > > >
      > > > > what I'll need to come up with are the templates. There will
      > > need to be a
      > > > > template for the various data point shapes, each in several
      > > sizes. These
      > > > > would be defined in a .h file as program data. For instance,
      for
      > > a small
      > > > > square:
      > > > >
      > > > > <pre>
      > > > >
      > > > > ooooooo
      > > > > o*****o
      > > > > o*****o
      > > > > o**x**o
      > > > > o*****o
      > > > > o*****o
      > > > > ooooooo
      > > > >
      > > > > </pre>
      > > > >
      > > > > Each character will control one pixel. x indicates the exact
      > > center. Two
      > > > > different characters (o and * in this case) are used in case
      we
      > > want a
      > > > > solid colored symbol or an outlined symbol.
      > > > >
      > > > > I can come up with the templates for squares, diamonds, and
      > > triangles
      > > > > easily enough. Circles would take a little more effort.. not
      > > that big a
      > > > > deal but if anyone can come up with good looking circle
      templates
      > > in
      > > > > various sizes up to ~20 characters in diameter that would be a
      > > help.
      > > > > Maybe there's some ascii art on the web somewhere that could
      be
      > > used...
      > > >
      > > > It seems to me that the algorithm in mark.c is already pretty
      good
      > > for this:
      > > >
      > > > /* (1=up-tri 2=down-tri 3=diam 4=square 5=pent 6=circ 7=right-
      tri
      > > 8=left-tri
      > > > 9=nice-circle) */
      > > > static int nc[] = { 3, 3, 4, 4, 5, 12, 3, 3, 20 };
      /*
      > > number of
      > > > corners (constant) */
      > > > static int nt[] = { 90,270, 0, 45, 90, 90, 0, 180,
      90 }; /*
      > > location
      > > > (in degrees) of first corner (constant) */
      > > > static double h[24][2]; /* the offsets */
      > > >
      > > > [...]
      > > >
      > > > theta = 360.0 / (double)nc[inc];
      > > > /* get offsets */
      > > > g = nt[inc];
      > > > for( i = 0; i < nc[inc]; i++ ) {
      > > > h[i][0] = r * cos( g * TORAD );
      > > > h[i][1] = r * sin( g * TORAD );
      > > > g += theta;
      > > > }
      > > >
      > > > [...]
      > > >
      > > > /* draw perimeter */
      > > > else {
      > > > Emov( x+h[0][0], y+h[0][1] );
      > > > for( i = 1; i < nc[inc]; i++ ) Elin( x+h[i][0], y+h[i][1] );
      > > > Elin( x+h[0][0], y+h[0][1] ); /* close to starting point.. */
      > > > Elin( x+h[1][0], y+h[1][1] ); /* and do one more so last
      > > corner is
      > > > done right.. */
      > > > }
      > > >
      > > > If this is implemented with x, y, and r expressed in pixel
      units,
      > > the result
      > > > should be quite good. Rounding errors in h[][] will be
      symmetric
      > > around the
      > > > origin, so at least the shapes will be regular. There might
      still
      > > be some
      > > > jaggedness, for example in the circle, which could then be a
      good
      > > candidate
      > > > for antialiasing. That algorithm could be used to develop
      static
      > > symbol
      > > > templates as you suggest, or to create them on the fly as is
      done
      > > now.
      > > >
      > > > > should be able to get this into the next release. Exactly how
      > > this option
      > > > > will be invoked by the user is still to be decided.. probably
      the
      > > more
      > > > > automatic the better.
      > > >
      > > > Excellent! It seems to me that this option should just be the
      > > default for all
      > > > raster devices, or at least for GD to start. I can't think of
      any
      > > reason that
      > > > a user wouldn't want to use the method that plots regular
      symbols.
      > > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      > >
      >
      >
      > Stephen C. Grubb x-6633
      > Scientific Software Engineer, The Jackson Laboratory
      > 600 Main Street Bar Harbor, Maine 04609 USA
      >
    • Show all 12 messages in this topic