[GRASS-dev] Errors applying color rules and -g flags in r.colors

Eric_Patton · April 19, 2007, 3:28pm

I'm having trouble getting the new r.color -g flag to do anything. Or, more correctly, maybe it's working properly, but I just can't tell if it's doing anything or not.

Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset:

~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT
~ >
~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow
Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow
~ >

Am I using the flag correctly, or does it also require the use of the 'rules' parameter? r.colors -ge on the input raster also fails to produce anything on the gis.m map window. r.colors -e works nicely on its own.

I'm also getting errors applying several of the new-ish predefined color tables. I've ran a script to apply each color table in turn to the same input raster. Output pasted below (warning, it's long):

for COLOR in `r.colors -l` ; do
echo -e "\n\nApplying color rule $COLOR to input raster...\n"
r.colors map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=$COLOR
done

Applying color rule aspect to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to aspect

Applying color rule aspectcolr to input raster...

ERROR: bad rule (percentage not in range 0-100): 180 cyan

Applying color rule bcyr to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to bcyr

Applying color rule byg to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to byg

Applying color rule byr to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to byr

Applying color rule curvature to input raster...

ERROR: bad rule (percentage not in range 0-100): -0.01 blue

Applying color rule differences to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to
differences

Applying color rule elevation to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to elevation

Applying color rule etopo2 to input raster...

ERROR: bad rule (percentage not in range 0-100): -11000 0 0 0

Applying color rule evi to input raster...

ERROR: bad rule (percentage not in range 0-100): -1.0000 white

Applying color rule grey to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to grey

Applying color rule gyr to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to gyr

Applying color rule ndvi to input raster...

ERROR: bad rule (percentage not in range 0-100): -1.0000 white

Applying color rule population to input raster...

ERROR: bad rule (percentage not in range 0-100): 1000 255 218 164

Applying color rule rainbow to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow

Applying color rule ramp to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to ramp

Applying color rule ryb to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to ryb

Applying color rule ryg to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to ryg

Applying color rule slope to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to slope

Applying color rule srtm to input raster...

ERROR: bad rule (percentage not in range 0-100): -500 0 0 10

Applying color rule terrain to input raster...

ERROR: bad rule (percentage not in range 0-100): -11000 0 0 0

Applying color rule wave to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to wave

So in sum, there are problems applying the aspectcolr, curvature, etopo2, evi, ndvi, population, srtm, and terrain color tables. It seems that r.colors will only accept a percentage color range and not a standard Grass color name or RGB value.

~ Eric.

Glynn_Clements1 · April 19, 2007, 5:22pm

Patton, Eric wrote:

I'm having trouble getting the new r.color -g flag to do anything. Or,
more correctly, maybe it's working properly, but I just can't tell if
it's doing anything or not.

Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset:

~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT
~ >
~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow
Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow
~ >

Can you provide details of the map, specifically whether it is integer
or FP, and the range?

I'm also getting errors applying several of the new-ish predefined
color tables. I've ran a script to apply each color table in turn to
the same input raster. Output pasted below (warning, it's long):

for COLOR in `r.colors -l` ; do
echo -e "\n\nApplying color rule $COLOR to input raster...\n"
r.colors map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=$COLOR
done

Applying color rule aspect to input raster...

Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to aspect

Applying color rule aspectcolr to input raster...

ERROR: bad rule (percentage not in range 0-100): 180 cyan

This is a bug in the new code; I forgot that:

if (sscanf(value, "%lf%%", &x) == 1)

will be true regardless of whether or not there is a percent sign
after the value, so it's treating all values as percentages. I'll
commit the following change shortly:

Index: lib/gis/color_rules.c

RCS file: /grassrepository/grass6/lib/gis/color_rules.c,v
retrieving revision 1.3
diff -u -r1.3 color_rules.c
--- lib/gis/color_rules.c 14 Apr 2007 03:35:32 -0000 1.3
+++ lib/gis/color_rules.c 19 Apr 2007 17:15:57 -0000
@@ -46,6 +46,7 @@
{
char value[16], color[16];
double x;
+ char c;

*norm = *nval = *dflt = 0;

@@ -86,7 +87,7 @@
return CR_OK;
}

- if (sscanf(value, "%lf%%", &x) == 1)
+ if (sscanf(value, "%lf%c", &x, &c) == 2 && c == '%')
     {
   if (x < 0 || x > 100)
       return CR_ERROR_PERCENT;

So in sum, there are problems applying the aspectcolr, curvature,
etopo2, evi, ndvi, population, srtm, and terrain color tables. It
seems that r.colors will only accept a percentage color range and not
a standard Grass color name or RGB value.

Yep. Thanks for finding this.

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

Eric_Patton · April 19, 2007, 5:59pm

Thanks for looking at this, Glynn. Comments interspersed below.

Patton, Eric wrote:

I'm having trouble getting the new r.color -g flag to do anything. Or,
more correctly, maybe it's working properly, but I just can't tell if
it's doing anything or not.

Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset:

~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT
~ >
~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow
Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow
~ >

Glynn:

Can you provide details of the map, specifically whether it is integer
or FP, and the range?

Yes, the raster is floating point; r.info -r gives:

r.info -r IsaacsHarbour_HDCS_1m_grd_fill
min=-16.806999
max=-1.215008

Glynn:

This is a bug in the new code; I forgot that:

if (sscanf(value, "%lf%%", &x) == 1)

will be true regardless of whether or not there is a percent sign
after the value, so it's treating all values as percentages. I'll
commit the following change shortly

Great, thanks! I'll test it an report back.

~ Eric.

Glynn_Clements1 · April 19, 2007, 7:03pm

Patton, Eric wrote:

>> I'm having trouble getting the new r.color -g flag to do anything. Or,
>> more correctly, maybe it's working properly, but I just can't tell if
>> it's doing anything or not.
>>
>> Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset:
>>
>> ~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT
>> ~ >
>> ~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow
>> Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow
>> ~ >

Glynn:
>Can you provide details of the map, specifically whether it is integer
>or FP, and the range?

Yes, the raster is floating point; r.info -r gives:

r.info -r IsaacsHarbour_HDCS_1m_grd_fill
min=-16.806999
max=-1.215008

Ah. Logarithmic scaling doesn't work on negative values.

It wouldn't be much effort to add a check for the case where both min
and max are negative, although I'm not sure whether that should go
into the library function (G_log_colors()) or r.colors. Or even
whether it's a good idea.

In the case where the range includes zero, there's no realistic
solution.

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

Eric_Patton · April 19, 2007, 7:16pm

Logarithmic scaling isn't critical for my work, so I'll just avoid the -g flag, or rescale my z-values in the case that I do need this feature.

I've updated my cvs to include your latest fix to color_rules.c, and while I'm not receiving the error message I did before, there is still some puzzling behavior occurring.

The color tables aspectcolr, evi, ndvi, population, and slope still display an all-white raster when invoked with no flags. However, applying the -e flag to each of these color tables creates a full-color, histogram-equalized color table as requested. I'm using the same floating-point raster as I did previously. Is this expected given the types of color tables being used? I'm not familiar with what 'evi' or 'ndvi' mean and for what types of data they are best suited.

~ Eric.

-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Thu 4/19/2007 4:03 PM
To: Patton, Eric
Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it
Subject: RE: [GRASS-user] Errors applying color rules and -g flags in r.colors

Patton, Eric wrote:

>> I'm having trouble getting the new r.color -g flag to do anything. Or,
>> more correctly, maybe it's working properly, but I just can't tell if
>> it's doing anything or not.
>>
>> Running r.colors -g produces a blank display in gis.m on an ordinary raster dataset:
>>
>> ~ >g.region rast=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT
>> ~ >
>> ~ >r.colors -g map=IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT color=rainbow
>> Color table for [IsaacsHarbour_HDCS_1m_grd_fill@PERMANENT] set to rainbow
>> ~ >

Glynn:
>Can you provide details of the map, specifically whether it is integer
>or FP, and the range?

Yes, the raster is floating point; r.info -r gives:

r.info -r IsaacsHarbour_HDCS_1m_grd_fill
min=-16.806999
max=-1.215008

Ah. Logarithmic scaling doesn't work on negative values.

It wouldn't be much effort to add a check for the case where both min
and max are negative, although I'm not sure whether that should go
into the library function (G_log_colors()) or r.colors. Or even
whether it's a good idea.

In the case where the range includes zero, there's no realistic
solution.

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

Glynn_Clements1 · April 19, 2007, 7:40pm

Patton, Eric wrote:

I've updated my cvs to include your latest fix to color_rules.c, and
while I'm not receiving the error message I did before, there is still
some puzzling behavior occurring.

The color tables aspectcolr, evi, ndvi, population, and slope still
display an all-white raster when invoked with no flags. However,
applying the -e flag to each of these color tables creates a
full-color, histogram-equalized color table as requested. I'm using
the same floating-point raster as I did previously. Is this expected
given the types of color tables being used? I'm not familiar with what
'evi' or 'ndvi' mean and for what types of data they are best suited.

The aspectcolor, population and slope tables only cover positive
values, while the evi and ndvi tables cover the range -1 to 1, so it's
expected that those tables won't work with the data in question.

OTOH, -e maps the range of the data to the range of the tables; the
absolute values used in the tables don't matter.

In general, tables which associate colors with percentages (aspect,
bcyr, byg, byr, elevation, grey, gyr, rainbow, ramp, ryb, ryg and
wave) can be applied to any data, while those which use absolute
values (aspectcolr, curvature, etopo2, evi, ndvi, population, slope,
srtm, and terrain) only make sense for data with certain ranges.

You can get a rough idea of the applicability of a colour table by
reading the corresponding rules file ($GISBASE/etc/colors/<name>).
E.g. slope is defined as:

  0 255 255 255
  2 255 255 0
  5 0 255 0
  10 0 255 255
  15 0 0 255
  30 255 0 255
  50 255 0 0
  90 0 0 0

This is designed for the slope map generated by r.slope.aspect, where
the value is a slope angle between 0 and 90 degrees.

Similarly, the aspectcolr map:

  0 white
  1 yellow
  90 green
  180 cyan
  270 red
  360 yellow

is designed for the aspect maps produced by r.slope.aspect, where the
value is a heading between 0 and 360 degrees.

[The "aspect" map should probably also use 0-360 rather than 0%-100%;
I'm not sure why it doesn't.]

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

Eric_Patton · April 20, 2007, 3:53pm

Thanks, that clears up all the outstanding issues.

A while back I think I recall someone saying that they had implemented a
C structure that would allow a color-picker to be used in Grass
programs. Would it be much difficulty adding this color-picker dialog to
r.colors to assist in constructing custom color rules files? It seems to
me that this module would be the ideal place to have such a feature.

--
Eric Patton
email: epatton@nrcan.gc.ca

-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Thursday, April 19, 2007 4:40 PM
To: Patton, Eric
Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it
Subject: RE: [GRASS-user] Errors applying color rules and -g
flags in r.colors

Patton, Eric wrote:

> I've updated my cvs to include your latest fix to
color_rules.c, and
> while I'm not receiving the error message I did before,
there is still
> some puzzling behavior occurring.
>
> The color tables aspectcolr, evi, ndvi, population, and slope still
> display an all-white raster when invoked with no flags. However,
> applying the -e flag to each of these color tables creates a
> full-color, histogram-equalized color table as requested. I'm using
> the same floating-point raster as I did previously. Is this
expected
> given the types of color tables being used? I'm not
familiar with what
> 'evi' or 'ndvi' mean and for what types of data they are
best suited.

The aspectcolor, population and slope tables only cover
positive values, while the evi and ndvi tables cover the
range -1 to 1, so it's expected that those tables won't work
with the data in question.

OTOH, -e maps the range of the data to the range of the
tables; the absolute values used in the tables don't matter.

In general, tables which associate colors with percentages
(aspect, bcyr, byg, byr, elevation, grey, gyr, rainbow, ramp,
ryb, ryg and
wave) can be applied to any data, while those which use
absolute values (aspectcolr, curvature, etopo2, evi, ndvi,
population, slope, srtm, and terrain) only make sense for
data with certain ranges.

You can get a rough idea of the applicability of a colour
table by reading the corresponding rules file
($GISBASE/etc/colors/<name>).
E.g. slope is defined as:

  0 255 255 255
  2 255 255 0
  5 0 255 0
  10 0 255 255
  15 0 0 255
  30 255 0 255
  50 255 0 0
  90 0 0 0

This is designed for the slope map generated by
r.slope.aspect, where the value is a slope angle between 0
and 90 degrees.

Similarly, the aspectcolr map:

  0 white
  1 yellow
  90 green
  180 cyan
  270 red
  360 yellow

is designed for the aspect maps produced by r.slope.aspect,
where the value is a heading between 0 and 360 degrees.

[The "aspect" map should probably also use 0-360 rather than
0%-100%; I'm not sure why it doesn't.]

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

Glynn_Clements1 · April 20, 2007, 4:43pm

Patton, Eric wrote:

A while back I think I recall someone saying that they had implemented a
C structure that would allow a color-picker to be used in Grass
programs.

This is part of the Tcl/Tk GUI. Options which are marked as colours
can be set using a colour picker from within gis.m or within the
dialog generated by --ui. See the options in the Colors tab of d.vect
for an example.

Would it be much difficulty adding this color-picker dialog to
r.colors to assist in constructing custom color rules files? It seems to
me that this module would be the ideal place to have such a feature.

This would need to be part of a separate application, rather than of
r.colors itself.

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

cmbarton · April 21, 2007, 3:43am

An interactive color picker is best implemented in an interactive GUI
environment. There are some already active in the current TclTk GUI, and we
are adding quite a few more for user convenience in the new wxPython GUI
that is now under develoment.

Michael

On 4/20/07 8:53 AM, "Patton, Eric" <epatton@nrcan.gc.ca> wrote:

Thanks, that clears up all the outstanding issues.

A while back I think I recall someone saying that they had implemented a
C structure that would allow a color-picker to be used in Grass
programs. Would it be much difficulty adding this color-picker dialog to
r.colors to assist in constructing custom color rules files? It seems to
me that this module would be the ideal place to have such a feature.

--
Eric Patton
email: epatton@nrcan.gc.ca

-----Original Message-----
From: Glynn Clements [mailto:glynn@gclements.plus.com]
Sent: Thursday, April 19, 2007 4:40 PM
To: Patton, Eric
Cc: grassuser@grass.itc.it; grass-dev@grass.itc.it
Subject: RE: [GRASS-user] Errors applying color rules and -g
flags in r.colors

Patton, Eric wrote:

I've updated my cvs to include your latest fix to

color_rules.c, and

while I'm not receiving the error message I did before,

there is still

some puzzling behavior occurring.

The color tables aspectcolr, evi, ndvi, population, and slope still
display an all-white raster when invoked with no flags. However,
applying the -e flag to each of these color tables creates a
full-color, histogram-equalized color table as requested. I'm using
the same floating-point raster as I did previously. Is this

expected

given the types of color tables being used? I'm not

familiar with what

'evi' or 'ndvi' mean and for what types of data they are

best suited.

The aspectcolor, population and slope tables only cover
positive values, while the evi and ndvi tables cover the
range -1 to 1, so it's expected that those tables won't work
with the data in question.

OTOH, -e maps the range of the data to the range of the
tables; the absolute values used in the tables don't matter.

In general, tables which associate colors with percentages
(aspect, bcyr, byg, byr, elevation, grey, gyr, rainbow, ramp,
ryb, ryg and
wave) can be applied to any data, while those which use
absolute values (aspectcolr, curvature, etopo2, evi, ndvi,
population, slope, srtm, and terrain) only make sense for
data with certain ranges.

You can get a rough idea of the applicability of a colour
table by reading the corresponding rules file
($GISBASE/etc/colors/<name>).
E.g. slope is defined as:

0 255 255 255
2 255 255 0
5 0 255 0
10 0 255 255
15 0 0 255
30 255 0 255
50 255 0 0
90 0 0 0

This is designed for the slope map generated by
r.slope.aspect, where the value is a slope angle between 0
and 90 degrees.

Similarly, the aspectcolr map:

0 white
1 yellow
90 green
180 cyan
270 red
360 yellow

is designed for the aspect maps produced by r.slope.aspect,
where the value is a heading between 0 and 360 degrees.

[The "aspect" map should probably also use 0-360 rather than
0%-100%; I'm not sure why it doesn't.]

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

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton