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

[GRASS GIS]

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

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


 see Glynn's reply of 2008-04-16 which covers the guts of this bug,
   http://article.gmane.org/gmane.comp.gis.grass.devel/26529

 (I can't get on any high-horse about using the trac system right now as
 the trac server is currently unresponsive, while email continues to flow
 through)


 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.

 My current workaround is to do:
 {{{
 alias xwdtopng='xwd | xwdtopnm | pnmtopng > '
 xwdtopng image.png
 }}}


 GRASS 7 is expected to use floating point coordinates for rendering, so
 the problem goes away (or is replaced by another).


 Hamish

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/72#comment:6>
GRASS GIS <http://grass.osgeo.org>