thumbnails.py failure

[neteler]

thumbnails.py has two problems:

make thumbnails
make[1]: Entering directory `/home/neteler/grass70/vector/v.colors'
GISRC=/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70 GISBASE=/home/neteler/grass70/dist.x86_64-unknown-linux-gnu PATH="/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin:$PATH" PYTHONPATH="/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/python:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/etc/python:$PYTHONPATH" LD_LIBRARY_PATH="/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib:/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib:" LC_ALL=C  ./thumbnails.py
Traceback (most recent call last):
  File "./thumbnails.py", line 188, in <module>
    main()
  File "./thumbnails.py", line 179, in main
    grad = make_gradient(path)
  File "./thumbnails.py", line 121, in make_gradient
    maxval = float(records[-1][0])
ValueError: could not convert string to float: default
make[1]: [thumbnails] Error 1 (ignored)
make[1]: Leaving directory `/home/neteler/grass70/vector/v.colors'
VERSION_NUMBER=7.0.svn VERSION_DATE=2013 \
        python /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/tools/mkhtml.py v.colors > /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/docs/html/v.colors.html
VERSION_NUMBER=7.0.svn /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/tools/g.html2man.py /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/docs/html/v.colors.html /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/docs/man/man1/v.colors.1
rm v.colors.tmp.html
[neteler@oboe v.colors]$

The problem is the (valid) "default" here:

grep default lib/gis/colors/*
lib/gis/colors/srtm_plus:default 255:255:255

which needs to be blacklisted (or whatever, since "nv" is accepted) in these Python scripts:

raster/r.colors/thumbnails.py
vector/v.colors/thumbnails.py

---

Second issue: even if deleting the offending line locally, nothing is really produced. How should it work? I expected to see an enriched HTML manual.

[hamish]

untested patch for problem #1:

Index: raster/r.colors/thumbnails.py
===================================================================
--- raster/r.colors/thumbnails.py	(revision 56728)
+++ raster/r.colors/thumbnails.py	(working copy)
@@ -102,7 +102,7 @@
             # skip comments
             continue
         records.append(line.split())
-    records = [record for record in records if record[0] != 'nv']
+    records = [record for record in records if record[0] != 'nv' and record[0] != 'default']
     relative = False
     absolute = False
     for record in records:

H

[neteler]

Replying to hamish:

untested patch for problem #1:

Works. It appears to solved problem 2 as well. Please submit.

Markus

[neteler]

Replying to neteler:

It appears to solved problem 2 as well.

To be precise: the png files are generating, yet lacking the integration in the HTML file.

[hamish]

Anna - the new r.colors module GUI dropdown list looks brilliant. thanks! The information is right where/when you need it.

Thumbnails in the help page fixed in trunk with r56787.

some observations of further buglettes:

I note in trunk there is some rendering error in the top-left corners of all the image boxes, manifested as a missing pixel. (in GRASS 6 there was/is a similar bug in d.barscale + Xdriver)

Another rendering issue to be fixed: the absolute-value limited/libgis color tables (grey.eq, grey.log, and random) are too big by a few pixels on the right and bottom sides.

We should do something better with the population palettes, maybe put them on a log-scale. Maybe the same with the precipitation palette. See the special rule for population in the old shell script version of the thumbnail generation script:

​http://grasswiki.osgeo.org/wiki/Talk:Color_tables

Finally, this is a clear case where the Xdriver does a better job than the Cairo driver, compare the thumbnails in trunk with the crispness of the devbr6 versions:

source:grass/branches/develbranch_6/raster/r.colors/thumbnails

... sometimes you want 1px lines to be exactly 1px wide, and no anti-aliasing.

Hamish

[glynn]

Replying to hamish:

I note in trunk there is some rendering error in the top-left corners of all the image boxes, manifested as a missing pixel. (in GRASS 6 there was/is a similar bug in d.barscale + Xdriver)

Finally, this is a clear case where the Xdriver does a better job than the Cairo driver, compare the thumbnails in trunk with the crispness of the devbr6 versions:

source:grass/branches/develbranch_6/raster/r.colors/thumbnails

... sometimes you want 1px lines to be exactly 1px wide, and no anti-aliasing.

Both of these are a result of the d.* modules having been "minimally ported" from the 6.x display API.

Closed paths should be closed with D_close() rather than by D_cont_{abs,rel} back to the starting point. The latter will result in the path being treated as open and thus having end caps.

Single-pixel lines should be drawn along the centre-line of a pixel row or column, not along the boundary between rows/columns. IOW, the vertices should have coordinates which are offset from an integer value by 0.5, rather than being integers.

The display API can't realistically do this automatically because it can't easily and reliably determine when it needs to "fix" the coordinates and when it should use them verbatim. E.g. d.vect shouldn't fix boundaries which happen to be axis-aligned rectangles because they'll be misaligned with the rest of the data.

OTOH, if you have a 200-dpi display, single-pixel lines may as well just not be drawn, because you probably won't be able to see them. For a quick fix, setting the line width to 2 pixels is probably simpler than changing the coordinates.

[hamish]

Replying to glynn:

Single-pixel lines should be drawn along the centre-line of a pixel row or column, not along the boundary between rows/columns.

it is enough for me to know that single-pixel lines are still possible, the rest, as they say, is just details & can tuned up along the way.

fwiw I'm mostly concerned about things like d.legend and d.barscale which like to be crisp rectangles and not anti-aliased.

thanks, Hamish

ps- curved lines in symbol rendering are a lot less wiggly now, see r56778. but it's still not perfect: I believe that add_coor()'s x,y in stroke.c can go all-floating point now.

[martinl]

No activity for a long time. Closing. Feel free to reopen if needed.