[GRASS-dev] Re: [GRASS GIS] #72: PNG driver: boundary rendering is off by one pixel

[Glynn Clements]

GRASS GIS wrote:

> #72: PNG driver: boundary rendering is off by one pixel
> ----------------------+-----------------------------------------------------
>   Reporter:  hamish   |       Owner:  grass-dev at lists.osgeo.org   
>       Type:  defect   |      Status:  new                         
>   Priority:  blocker  |   Milestone:  6.4.0                       
>  Component:  Tcl      |     Version:  svn-develbranch6            
> Resolution:           |    Keywords:  gis.m, rendering, PNG_DRIVER
> ----------------------+-----------------------------------------------------
> Changes (by hamish):
> 
>   * version:  svn-trunk => svn-develbranch6
> 
> Comment:
> 
>  Michael:
>  > It's easy enough to put in the rendering mode for d.* commands.
> 
>  There is no need for the GUI to expose the render mode to the user, it's a
>  debug switch to aid development.
> 
>  > 1) Is it ONLY d.vect that has a problem?
> 
>  no, it's a problem with the rendering library functions. the different
>  render= switches choose which lib fns to render with.

It's only d.vect that has that option.

>  > 2) I've seen discussion go back and forth over which of these
>  > switches to use. Has that been settled in this case?
> 
>  For d.vect it has been changed to "c" as the best compromise for GRASS 6.
>  (where "best" means it was the last man standing; IIRC some of the
>  otherwise more favoured candidates had the possibility of writing outside
>  of the X buffer etc. and so were disqualified)

That's about right. r, d and l can result in coordinates which exceed
the 16-bit limit of the X11 protocol, so don't work with XDRIVER (they
might be useful if you will only be using the PNG/PS/cairo drivers),
while g uses client-side rasterisation, which is far from ideal when
used with non-raster drivers (PS, HTMLMAP, PS/PDF/SVG output from the
cairo driver).

>  I had thought to post new screenshot tests responding to that post
>  exploring my observation that the current problem is with near vertical
>  lines. Spearfish's fields vector layer is a good example as it has many
>  near horiz + vertical boundaries and is the basis of the first 2 of 3
>  screenshots attached to this report. The third is varied coastline data,
>  but demonstrates what happens with a diversity of line angles. In light of
>  those 3 I don't think any more screenshots would provide any more info.
> 
> 
>  Glynn wrote in the above post:
>  "It wouldn't be particularly hard to make the closer-to-vertical case
>  match, by using the same algorithm in both cases. Making the
>  closer-to-horizontal case match is harder (and messy)."
> 
>  I'm cautiously optimistic that the problem is with the closer-to-vertical
>  case. If so, and thus it isn't a major developer drain to fix it, then I'd
>  really hope we could do that for 6.4 as for GRASS 6 the PNG driver is our
>  primary d.* hardcopy output method.

In that case, the fix is to make draw_line() in
lib/pngdriver/Draw_line.c match line() in lib/driver/Polygon.c.

Currently, the former uses Bressenham's algorithm[1] while the latter
uses floating-point linear interpolation.

[1] http://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm

OTOH, the real issue may be that one of the primitives is rounding the
coordinates while the other is truncating them. If so, this is a
consequence of the fundamental API flaw, namely the use of integer
coordinates.

-- 
Glynn Clements <glynn at gclements.plus.com>