Re: [GRASS-dev] Color tables/rules now use standardized color parsing

[Markus Neteler]

On Thu, Oct 20, 2016 at 12:20 AM, Vaclav Petras  wrote:
> Dear all,
>
> in r69708, I've changed the implementation of parsing color rules to use the
> G_str_to_color() function instead of a custom mechanism. This, in connection
> with r69683, adds the possibility to use HTML (CSS) style of hexadecimal
> colors with leading hash.
>
> So, now you can do:
>
> r.colors elevation rules=- < 0% #D24926
> 100% #FCE36D
> EOF
>
> Where it gets little tricky is that hash is used to comment a line in color
> rules/color table format. A comment is now implemented as a line where first
> character is hash, so there is no interference. We just need to keep it that
> way.
>
> The comments (# ...) are actually not documented in r.colors manual.

I just tested it with a soil map, great job!

> Same goes also for the syntax with space as a separator instead of colon. Now 
> we
> also support ; and , as separators (because that's what G_str_to_color()
> supports). The hash syntax keeps tradition and it is undocumented as well
> for now (but there is a test!).

Perhaps worthwhile to mention it in the manual?

thanks
Markus

> Best,
> Vaclav
>
>
> r69708 https://trac.osgeo.org/grass/changeset/69708
> r69683 https://trac.osgeo.org/grass/changeset/69683
> Specify color as #RRGGBB
> https://lists.osgeo.org/pipermail/grass-dev/2016-October/082662.html
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Color tables issues

[Markus Neteler]

On Fri, Apr 4, 2014 at 4:29 AM, Vaclav Petras wenzesl...@gmail.com wrote:
 Hi,

 I just had three issues with color table.

 1) First, I did not see anything when I showed the output of r.stats.zonal
 in map display:

 r.stats.zonal base=basin_10K cover=aspect method=sum output=test
 d.rast test

 But the values were ok, so I realized I that the preset color table is wrong
 and I need to set my own.

The current behaviour seems to be

if (Rast_read_colors(covermap, , colors)  0)
Rast_write_colors(output, G_mapset(), colors);


 2) It worked, however, the color table pictures were not in the r.colors
 dialog. Note: I had freshly compiled trunk after make distclean (outside
 GRASS session).

 So, I went to raster/r.colors and run make inside GRASS session. I got the
 color tables.

Hopefully solved by Martin the other day:

http://trac.osgeo.org/grass/changeset/59820
http://trac.osgeo.org/grass/changeset/59821

 3) In the meantime, I noticed that color tables thumbnails are in docs which
 is bad when some Linux distribution has the separate package for docs
 (recently noted on mailing list).

Perhaps we need them twice:
- in docs/html/colortables/ (as now)
- in GISBASE/etc/colortables/

(it is 160kb only)

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables for vector

[Martin Landa]

Hi,

2011/8/22 Glynn Clements gl...@gclements.plus.com:
 There is one open issue. How to write color tables for vector maps
 which are not located in the current mapset. I was thinking about
 'vector/name/colr2`, but it would require quite lot changes in
 gislib (at least in G__ls()) etc, the second option which came to my
 mind is 'vector2/name/colr2' as destination file for color table.
 What do you think?

 I'd suggest using the same mechanism as for rasters, but with a
 different top-level directory name, e.g. vcolr2/mapset/name.

done in r47867.

Martin

-- 
Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables question

[Hamish]

Michael wrote:
 Is there a way when you 1) reproject or 2) georectify a map
 to bring its color table with it into the target
 location/mapset?

I was under the impression that that happened already for both
scenarios.
 
 Or do you have to manually copy the color table from the
 original mapet to the new one?

I'm pretty sure that's not needed, both from memory and from
a quick grep of the code:

grass65/raster/r.proj$ grep color *
main.c:  orows, ocols, have_colors, /* Input map has a colour table */
main.c:have_colors = G_read_colors(inmap-answer, setname, colr);
main.c:if (have_colors  0) {
main.c: G_write_colors(mapname, G_mapset(), colr);
main.c: G_free_colors(colr);


grass65/imagery/i.rectify$ grep color *
exec.c: colr_ok = G_read_colors(name, mapset, colr)  0;
exec.c: G_write_colors(result, G_mapset(), colr);
exec.c: G_free_colors(colr);



 If the latter, perhaps a nice enhancement to r.color would be
 the ability to copy a color table from ANY other map and not
 just those in the current location.

if you like, Glynn's new r.colors.out + 'r.colors rules=' will
do that outside of the automation.



Hamish



  
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Glynn Clements]

Hamish wrote:

  I am just going through some old emails and I am wondering whether there 
  was a reason why the images illustrating the pre-defined color tables 
  generated by Hamish and available on wiki 
  
  http://grass.osgeo.org/wiki/Raster_color_tables
  
  could not be included directly into the man page
  http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
  or is this just an unfinished thread.
 
 done by Glynn for GRASS 7:
   http://grass.osgeo.org/grass70/manuals/html70_user/r.colors.html
 
 (I notice dynamic ones are broken [random, grey.log, grey.eq])

Fixed in r41464.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables (legal aspects)

[Jarosław Jasiewicz]

Hi

I created for my personal use some color tables almost identical to that 
of ESRI


I wonder about legal aspect of publish it as add-on. It is possible that 
these color schemes are not restricted, but there are lots of doubt.

what you think about?

regards
Jarek




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables (legal aspects)

[Hamish]

Jarosław wrote:
 I created for my personal use some color tables almost
 identical to that of ESRI
 
 I wonder about legal aspect of publish it as add-on. It is
 possible that these color schemes are not restricted, but
 there are lots of doubt.
 what you think about?

If it is a derivative of a creative work under copyright, then you are
bound by the terms of that copyright.

... which raises the question of is a color table a creative work?

For something simply like byr I find it hard to imagine that it is.
For something more complex like rainbow or wave it could start to be.
For something which is derived from a simple linear path through color-
space it would be hard to argue that the math is either a creative work
or original. (as long as you just followed the mathematical eqn.)

I would look at it likes notes of music. Three notes strung together
can hardly be called an original creative work. Once you have added
enough complexity to pull out a discernible melody though, it becomes a
different situation.


hope it helps,
Hamish




___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Helena Mitasova]

I am just going through some old emails and I am wondering whether there 
was a reason why the images illustrating the pre-defined color tables 
generated by Hamish and available on wiki 

http://grass.osgeo.org/wiki/Raster_color_tables

could not be included directly into the man page
http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
or is this just an unfinished thread.

I don't get complaints about it any more but it may be useful for newcomers.

Also, when using histogram equalized color table the legend is 
generated with equal intervals which often ends up being just one color 
for most of the legend - would it be difficult to generate the legend 
with histogram equalized values? Maybe a task to add to GSoC GRASS cartographic
output project?

Helena



On Aug 26, 2009, at 9:22 PM, Helena Mitasova wrote:

 
 On Aug 26, 2009, at 2:22 AM, Hamish wrote:
 
 Helena wrote:
 I often get a question why there aren't images of color tables
 in GRASS GUI along with their names. Is this technically feasible?
 Or it is already there and I just don't see it?
 
 I don't think it's there.
 
 I am thinking about adding them to the r.colors man page, but first I
 
 IMhO these sorts of things should go in the wiki, not the man page.
 Anything but simple PNG figures add a huge amount to the bulk of the
 SVN and .tar.gz release sizes.
 
 I had in mind something that is on hand directly from the GUI -
 best would be in the drop-down menu which currently lists the color tables by 
 name,
 but if that is not supported by the wxpython, man page would do as well 
 because it
 is accessible from the command's gui.
 The images are tiny, they take very little space - I had in mind something 
 like this
 (I should have put it into the Description section, but you get the idea)
 http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
 this just uses your rescaled png images.
 
 Same would be handy for the point symbols - they are pretty difficult to find 
 on wiki
 if you don't know where they are. If this cannot go into the man page, adding
 a link to the wiki page on man page would certainly help.
 
 would like to ask whether somebody has done this already (or has a
 script to do it).
 I was thinking about running something like this through all color
 tables
 
 set GRASS_WIDTH=50 and GRASS_HEIGHT=100
 r.colors elev co=ryg
 d.colortable elev
 d.out.file ryg_col
 d.erase
 convert -rotate 90 ryg_col
 
 I have made a little script which does the trick, I'll post it to
 the wiki shortly at  http://grass.osgeo.org/wiki/Raster_color_tables
 
 that was ultrafast! Thanks a lot - even that helps,
 
 Helena
 
 
 Hamish
 
 
 
 
 
 
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Hamish]

Helena wrote:
 I am just going through some old emails and I am wondering whether there 
 was a reason why the images illustrating the pre-defined color tables 
 generated by Hamish and available on wiki 
 
 http://grass.osgeo.org/wiki/Raster_color_tables
 
 could not be included directly into the man page
 http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
 or is this just an unfinished thread.

done by Glynn for GRASS 7:
  http://grass.osgeo.org/grass70/manuals/html70_user/r.colors.html

(I notice dynamic ones are broken [random, grey.log, grey.eq])


 Also, when using histogram equalized color table the legend is 
 generated with equal intervals which often ends up being just
 one color  for most of the legend - would it be difficult to generate
 the legend with histogram equalized values? 

Yes and no. Suggested method using current tools is to figure
out the breaks with r.quantile/r.univar and then run d.legend
with the use= option. e.g.:


g.region rast=slope
r.colors -e slope col=bcyr

TICKS=`r.quantile slope perc=$(seq -s, 0 10 100) --quiet | \
   cut -f3 -d: | tr '\n' ',' | sed -e 's/,$//'`

d.legend slope -f use=$TICKS


which works quite nicely.
(beware if working with 0.01.0 values that use= might cast to int(??))


Probably we could add that to d.rast.leg as a new -e flag without much
trouble; a new flag to G_spawn(r.quantile) from within d.legend is
possible, but more work. (I've been putting off un-monolithing d.legend
as it is working well, but I'll have to sit down and do that at some
point as I've been meaning to for years)


for ps.map output use the colortable's discrete Yes option
to force a categorical legend, after using r.category to assign
labels to FP tick values you want displayed. (just guessing; untested)


 Maybe a task to add to GSoC GRASS cartographic output project?

My plan for a possible SoC GRASS cartographic output project is simply
a wxGUI frontend for ps.map which creates ps.map instruction files and
runs ps.map at ~10 dpi for previews. IMO ps.map and d.legend are near-
feature complete mature code and I don't really want to throw students
into them. I do plan however to work with Jorge to merge some of the
nice stuff from ps.output back into ps.map. (starting with fancy borders)

I'm not sure what future work needs to be done for the PS display driver
beyond lots of testing, otherwise it is mostly general improvements to
the main wxGUI display window (which also benefits the day-to-day GUI).


The OSGeo cartographic library is something else entirely, from my POV
probably svg + gdal/ogr centered  I'd lobby strongly to try and get
the GMT people involved as early as possible. (our [ie grass] code bases
are already quite compatible already actually, some long ago common
history I guess.)


finally, I'll mention that in the last 6 months I've been using GMT a bit
more and now that I am more familiar with it the gulf between it and
ps.map seems a lot smaller than I once thought it was.
(depends on your usage of course- GMT can do a lot of things!)


Hamish



  
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Hamish]

Hamish wrote:
 (beware if working with 0.01.0 values that use= might cast to int(??))

never mind, that's incorrect. it's fine.  (tested with slope*0.01 but not
extreme log data [which in raw form probably suffers from FP precision
storage issues of its own])


there does seem to be a minor precision issue with the range check though.


Hamish



  
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Glynn Clements]

Hamish wrote:

  These should be generated as part of the build process.
  Otherwise, there's no guarantee that they actually match the colour
  tables in lib/gis/colors 
 
 great, looks good.
 
 One thing I notice is that in grass7 the D_move_abs(), D_cont_rel()
 line widths are heavier than they were in 6.x. (2px vs 1px wide)
 Is it possible to make 1px again? An explicit D_line_width(0) just
 makes it grey,

At present, the output will be affected by $GRASS_RENDER_IMMEDIATE,
$GRASS_LINE_WIDTH, and $GRASS_ANTIALIAS (that's an oversight; I'll
modify the script to unset those).

 I guess it has to be moved 1/2 a pixel from centered
 on grid lines to centered mid-cell?? It seems to work ok in d.legend
 which is pretty much the same code.

You shouldn't assume that the display library will allow that kind of
low-level control. At some point, it may support scaling of unscaled
coordinates, so that modules with hard-coded sizes produce usable
results on 200dpi monitors.

Even at present, you don't actually have that degree of control, given
the existence of the PS driver and PS/PDF/SVG output via the cairo
driver.

 Also I notice that for d.colortable and d.legend that with D_end()
 to close the polygon there is a pixel missing from the start/end
 position here. see attached.

Use D_close() if you want a closed path (i.e. a join rather than
caps).

 (hmmm, D_end() is a no-op?)

At present, yes.

  (shouldn't those have been moved to lib/raster?).
 
 fwiw they are used by v.colors too. (which will eventually be free
 of r.* hacks)

How are the files going to be read? Is someone planning on duplicating
the contents of lib/raster/color_rules.c for the sake of not using the
raster library? If so, that code should be moved back into lib/gis.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Hamish]

Glynn wrote:
 These should be generated as part of the build process.
 Otherwise, there's no guarantee that they actually match the colour
 tables in lib/gis/colors 

great, looks good.

One thing I notice is that in grass7 the D_move_abs(), D_cont_rel()
line widths are heavier than they were in 6.x. (2px vs 1px wide)
Is it possible to make 1px again? An explicit D_line_width(0) just
makes it grey, I guess it has to be moved 1/2 a pixel from centered
on grid lines to centered mid-cell?? It seems to work ok in d.legend
which is pretty much the same code.

Also I notice that for d.colortable and d.legend that with D_end()
to close the polygon there is a pixel missing from the start/end
position here. see attached.  (hmmm, D_end() is a no-op?)


 (shouldn't those have been moved to lib/raster?).

fwiw they are used by v.colors too. (which will eventually be free
of r.* hacks)


Hamish



  attachment: gr7_D_line_end_knick.png___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Glynn Clements]

Hamish wrote:

  I often get a question why there aren't images of color tables
  in GRASS GUI along with their names. Is this technically feasible?
 ...
  I am thinking about adding them to the r.colors man page,
 
 thumbnail images of the colortables now added in 6.5 and 7 svn
 in the raster/r.colors/ dir.

These should be generated as part of the build process. Otherwise,
there's no guarantee that they actually match the colour tables in
lib/gis/colors (shouldn't those have been moved to lib/raster?).

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Hamish]

Helena wrote:
 I often get a question why there aren't images of color tables
 in GRASS GUI along with their names. Is this technically feasible?
...
 I am thinking about adding them to the r.colors man page,

thumbnail images of the colortables now added in 6.5 and 7 svn
in the raster/r.colors/ dir.

I put Glynn's html insertion magic trick in the Makefile, but for now
it's commented out. Someone who knows those things better than I can
enable it.

script to (re)generate the images can be found on the Talk page of:
  http://grass.osgeo.org/wiki/Color_tables


Hamish

ps- I cleaned up the d.colortable rendering to make this easier.



  
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[paolo]

On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
hmit...@unity.ncsu.edu
wrote:

 http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
 this just uses your rescaled png images.

Quite useful - +1 for me.
pc
-- 
http://faunalia.it/pc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Dylan Beaudette]

On Thursday 27 August 2009, paolo wrote:
 On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
 hmit...@unity.ncsu.edu

 wrote:
  http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
  this just uses your rescaled png images.

 Quite useful - +1 for me.
 pc

+1 from me as well. I really like the mini-images next to the color scheme 
name. 

Dylan

-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Markus Neteler]

On Thu, Aug 27, 2009 at 6:19 PM, Dylan Beaudettedebeaude...@ucdavis.edu wrote:
 On Thursday 27 August 2009, paolo wrote:
 On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
 hmit...@unity.ncsu.edu

 wrote:
  http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
  this just uses your rescaled png images.

 Quite useful - +1 for me.
 pc

 +1 from me as well. I really like the mini-images next to the color scheme
 name.

An option might be to make a local Makefile hack to substitute part
of the generated HTML file with a replacement including these images.

Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Glynn Clements]

Markus Neteler wrote:

 On Thu, Aug 27, 2009 at 6:19 PM, Dylan Beaudettedebeaude...@ucdavis.edu 
 wrote:
  On Thursday 27 August 2009, paolo wrote:
  On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
  hmit...@unity.ncsu.edu
 
  wrote:
   http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
   this just uses your rescaled png images.
 
  Quite useful - +1 for me.
  pc
 
  +1 from me as well. I really like the mini-images next to the color scheme
  name.
 
 An option might be to make a local Makefile hack to substitute part
 of the generated HTML file with a replacement including these images.

Try overriding the default rule with:

r.colors.tmp.html: $(HTMLSRC)
$(call htmldesc,$,$@)
sed 's!^DDb\([a-z0-9.]*\)/b:!DDimg width=80 height=12 
src=Colortable_\1_i.pngb\1/b:!' $@  $...@.tmp
mv -f $...@.tmp $@

Or you could just put the images into the static part of the file.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Hamish]

Helena wrote:
 http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
 this just uses your rescaled png images.

Markus:
 An option might be to make a local Makefile hack to substitute
 part of the generated HTML file with a replacement including
 these images.


I don't think that's needed; just put the images in the main
body of description.html, as the color options get repeated there.

the script on the discussion side of the wiki page could be
modified to use Helena's idea of d.colortable + rotate 90 for
the mini images; no point including the d.legend frame around them. If you want 
a 1px frame use border=1 in the img src.

..png please.


Hamish



  

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Hamish]

 Markus:
  An option might be to make a local Makefile hack to substitute
  part of the generated HTML file with a replacement including
  these images.
 
 Hamish wrote:
 I don't think that's needed; just put the images in the main
 body of description.html, as the color options get repeated there.

sorry, I just noticed that that is only true for 6.4, in 6.5/7 the
duplicated list has been removed.

I suggest to make the thumbnails the equivalent of 8-10pt tall and an
inch wide, about what Helena already demonstrated, maybe a little bigger.


Hamish



  

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Hamish]

Helena wrote:
 I often get a question why there aren't images of color tables
 in GRASS GUI along with their names. Is this technically feasible?
 Or it is already there and I just don't see it?

I don't think it's there.
 
 I am thinking about adding them to the r.colors man page, but first I

IMhO these sorts of things should go in the wiki, not the man page.
Anything but simple PNG figures add a huge amount to the bulk of the
SVN and .tar.gz release sizes.

 would like to ask whether somebody has done this already (or has a 
 script to do it).
 I was thinking about running something like this through all color
 tables
 
 set GRASS_WIDTH=50 and GRASS_HEIGHT=100
 r.colors elev co=ryg
 d.colortable elev
 d.out.file ryg_col
 d.erase
 convert -rotate 90 ryg_col

I have made a little script which does the trick, I'll post it to
the wiki shortly at  http://grass.osgeo.org/wiki/Raster_color_tables


Hamish



  

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] color tables

[Helena Mitasova]

On Aug 26, 2009, at 2:22 AM, Hamish wrote:


Helena wrote:

I often get a question why there aren't images of color tables
in GRASS GUI along with their names. Is this technically feasible?
Or it is already there and I just don't see it?


I don't think it's there.


I am thinking about adding them to the r.colors man page, but first I


IMhO these sorts of things should go in the wiki, not the man page.
Anything but simple PNG figures add a huge amount to the bulk of the
SVN and .tar.gz release sizes.


I had in mind something that is on hand directly from the GUI -
best would be in the drop-down menu which currently lists the color  
tables by name,
but if that is not supported by the wxpython, man page would do as  
well because it

is accessible from the command's gui.
The images are tiny, they take very little space - I had in mind  
something like this
(I should have put it into the Description section, but you get the  
idea)

http://skagit.meas.ncsu.edu/~helena/grasswork/grasscontrib/r.colors.html
this just uses your rescaled png images.

Same would be handy for the point symbols - they are pretty difficult  
to find on wiki
if you don't know where they are. If this cannot go into the man  
page, adding

a link to the wiki page on man page would certainly help.



would like to ask whether somebody has done this already (or has a
script to do it).
I was thinking about running something like this through all color
tables

set GRASS_WIDTH=50 and GRASS_HEIGHT=100
r.colors elev co=ryg
d.colortable elev
d.out.file ryg_col
d.erase
convert -rotate 90 ryg_col


I have made a little script which does the trick, I'll post it to
the wiki shortly at  http://grass.osgeo.org/wiki/Raster_color_tables


that was ultrafast! Thanks a lot - even that helps,

Helena



Hamish







___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev