PNG driver and Cairo driver mangle large symbols, XDRIVER doesn't

[hamish]

Hi,

in GRASS 6.x the PNG driver and Cairo driver badly mangle large ring symbols, while the XDRIVER doesn't. This makes the creation of automated PNG plots on a headless server somewhat problematic, unless the more tortuous ps.map + pstoimg method is used.

(note even though it's headless it still needs X.org installed, as a dependency of the Cairo driver's X11-output option)

The PNG driver has an uneven inner/outer radius and gouges out of it; the Cairo driver does not path the line segments together at all.

examples images attached.

cat << EOF > test.grf
width 30
symbol basic/circle 500 50 50 red none
EOF

d.mon x4
d.resize w=825 h=650
d.graph test.grf

xwd | xwdtopnm | pnmtopng > xdriver_ring.png
d.out.file png_driver_ring
d.out.file -c cairo_driver_ring

In GRASS 7 the situation is a bit better, the PS and one of the PNG|cairo* drivers(?) makes nice looking output, only complaint is that the closed ring has a sliver where it isn't closed. could a special beginning==end test be added to have it code the path?

Also, is it possible to double or quadruple the number of vertices in the ring? At the current number it is very obviously a polygon and not a circle.

cat << EOF > test.grf
width 30
symbol basic/circle 500 50 50 red none
EOF

export GRASS_WIDTH=825
export GRASS_HEIGHT=650

export GRASS_RENDER_IMMEDIATE=PNG
export GRASS_PNGFILE=png_driver7_ring.png
d.graph test.grf


export GRASS_RENDER_IMMEDIATE=CAIRO
export GRASS_PNGFILE=cairo_driver7_ring.png
d.graph test.grf

export GRASS_RENDER_IMMEDIATE=PS
export GRASS_PNGFILE=cairo_driver7_ring.ps
d.graph test.grf

[*] I'm not sure which driver it's using actually, I get an identical output file for both. -- that is when setting 7's GRASS_RENDER_IMMEDIATE=PNG doesn't make d.graph SegFault, while the cairo driver doesn't. then I can tell.

[] should "GRASS_RENDER_IMMEDIATE=cairo" be uppercase or not? the man page shows both ways.

thanks, Hamish

[hamish]

g6 xdriver

[hamish]

g6 png driver

[hamish]

g6 cairo driver

[hamish]

grass 7, not sure if PNG or Cairo driver was used

[hamish]

(note even though it's headless it still needs X.org installed, as a dependency of the Cairo driver's X11-output option)

make that: as a dependency of the OS's Cairo package; not our Cairo driver.

[glynn]

Replying to hamish:

(note even though it's headless it still needs X.org installed, as a dependency of the Cairo driver's X11-output option)

This depends upon whether GRASS was built --with-x. If USE_X11 is defined in the Makefiles, libcairodriver will end up with Xlib as a dependency.

In GRASS 7 the situation is a bit better, the PS and one of the PNG|cairo* drivers(?) makes nice looking output, only complaint is that the closed ring has a sliver where it isn't closed. could a special beginning==end test be added to have it code the path?

This might be an artifact of an attempt at simplifying paths. One of the complaints with making d.vect use the driver's polygon filling (instead of pre-rasterising paths with G_plot_polygon()) was that rasterising complex areas was slow. Some code was added to lib/display in 7.0 (reduce_path(), in draw2.c) to merge small, adjacent segments (effectively filtering the path), but it can cause problems if you create complex paths (with islands/cut-outs) using "cont" instead of "move".

Or it might be something else entirely. 7.0's lib/display has a specific D_close() function for closing paths; writing coincident vertices won't cause a path to be closed.

[] should "GRASS_RENDER_IMMEDIATE=cairo" be uppercase or not? the man page shows both ways.

It doesn't matter; the value is compared using G_strcasecmp(). To the extent that it matters, the canonical form should be "cairo".

[hamish]

Hi,

in an effort to relieve the symptoms I've modified lib/symbol/stroke.c in trunk (r45639) and devbr65 to draw every 1 degree around the arc instead of every 10 degrees when the symbol size is larger than 50. This in no way fixes the underlying problem though, and other stuttering artifacts are now seen in the gr6.5 PNG driver where before there were missing notches.

Hamish

[hamish]

new grass65 png driver stuttering ring from web/screenshots/web/earthquakes demo

[neteler]

On the real-time earthquake mapper it looks ok (is that GRASS 7 based?):

​http://adhoc.osgeo.osuosl.org/grass/alternate_projections/earthquakes_wintri.png

[hamish]

Replying to neteler:

On the real-time earthquake mapper it looks ok (is that GRASS 7 based?):

​http://adhoc.osgeo.osuosl.org/grass/alternate_projections/earthquakes_wintri.png

it looks a little better there because I manually patched the build, but it's still an issue. (wait for a M7.5+ to see it, last week it was visible there)

for the record, the cron job is currently running 6.4.2rc2.

Hamish

[hamish]

PNG driver line width rendering now working in trunk r59549, which shows that this bug exists in GRASS 7 too.

cairo driver seems to be working ok in trunk now, but not in 6.x.

I'll attach some more screenshots, made with the following command: (d.mark from addons, same script works in both G6 and G7)

   export GRASS_WIDTH=800
   export GRASS_HEIGHT=606
   d.mon start=PNG
   d.mark symbol=ring at=50,50 size=500 width=30
   d.mon stop=PNG

Hamish

[hamish]

GRASS 6 XDRIVER: working (d.mark symbol=ring at=50,50 size=500 width=30)

[hamish]

PNG driver in G6 and G7: rendering trouble

[hamish]

G6 XDRIVER (ok, grey); G6/G7 png driver (bad, black)

[hamish]

G6 cairo driver: interestingly wrong

[hamish]

note that between this lot and the last lot of screenshots I upped the number of vertices used when rendering large circles. that solved (masks) the missing sliver dur to the unjoined line beginning/end stroke, and by comparing the before and after PNG driver images you can visualize the now much shorter but same width lines that it draws.

summary for fat line width rendering:

working: G6 XDRIVER, G7 cairo

no good: all pngdriver, G6 cairo

Hamish

[neteler]

I have backported fix r59547 in r61752.

But there are still differences between trunk and relbr7 in the PNG driver in Draw_line.c. Backport, too?

[hamish]

Replying to neteler:

I have backported fix r59547 in r61752.

Thanks, I don't remember the exact details of that change, but from the look of it and comment:6 it's good & I should have backported it at the time.

But there are still differences between trunk and relbr7 in the PNG driver in Draw_line.c. Backport, too?

I that's r59549? It is a bugfix and I believe that it should be backported to relbr70.

AFAIK the fixme mentioned there still remains todo, although the png driver situation is better than it is in G6 thanks to Glynn's rewrite.

(this ticket is mostly specific to the png driver rendering issues which exist in G6, which I still hope to fix one day)

thanks, Hamish

[neteler]

Replying to hamish:

I that's r59549? It is a bugfix and I believe that it should be backported to relbr70.

Done so in relbr7.

[hamish]

thanks!

[martinl]

Ticket retargeted after milestone closed