[GRASS-dev] color tables

GRASS GRASS developer
1

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 am thinking about adding them to the r.colors man page, but first I 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

Helena

2

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

3

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

4

On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
<hmitaso@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

5

On Thursday 27 August 2009, paolo wrote:

On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
<hmitaso@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

6

On Thu, Aug 27, 2009 at 6:19 PM, Dylan Beaudette<debeaudette@ucdavis.edu> wrote:

On Thursday 27 August 2009, paolo wrote:

On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
<hmitaso@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

7

Markus Neteler wrote:

On Thu, Aug 27, 2009 at 6:19 PM, Dylan Beaudette<debeaudette@ucdavis.edu> wrote:
> On Thursday 27 August 2009, paolo wrote:
>> On Wed, 26 Aug 2009 21:22:16 -0400, Helena Mitasova
>> <hmitaso@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!^<DD><b>\([a-z0-9.]*\)</b>:!<DD><img width="80" height="12" src="Colortable_\1_i.png"><b>\1</b>:!' $@ > $@.tmp
  mv -f $@.tmp $@

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

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

8

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

9

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

10

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.

11

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 <glynn@gclements.plus.com>

12

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

13

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.0<1.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

14

Hamish wrote:

(beware if working with 0.0<1.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

15

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 <glynn@gclements.plus.com>

16

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

17

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