[GRASS-user] error message coming with r.colors

Dear list,

I try to adapt the color table of a raster file using an ascii file (> rules option) with the following statement:

r.colors map=b25_daymax0.l1_neu@PERMANENT color=rules 'rules=/sonne3/.../GIS/colorscript_farben_temp'

Hence the following message comes up:

"color", "rules", and "raster" options are mutually exclusive

Any ideas what this means? Please see also the attached colorscript.

Regards

Christian

_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

(attachments)

colorscript_farben_temp (123 Bytes)

christian Brandt wrote:

I try to adapt the color table of a raster file using an ascii file
(> rules option) with the following statement:

r.colors map=b25_daymax0.l1_neu@PERMANENT color=rules 'rules=/sonne3/.../GIS/colorscript_farben_temp'

Hence the following message comes up:

"color", "rules", and "raster" options are mutually exclusive

Any ideas what this means?

What it says; you can't use both "color" and "rules". If you use
"color=rules", the rules are read from stdin (equivalent to -i). If
you use "rules=...", the rules are read from the specified file.

So, just omit the color=rules option, i.e.:

r.colors map=b25_daymax0.l1_neu@PERMANENT 'rules=/sonne3/.../GIS/colorscript_farben_temp'

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

Hi,

2008/8/5 Glynn Clements <glynn@gclements.plus.com>:

What it says; you can't use both "color" and "rules". If you use
"color=rules", the rules are read from stdin (equivalent to -i). If
you use "rules=...", the rules are read from the specified file.

So, just omit the color=rules option, i.e.:

r.colors map=b25_daymax0.l1_neu@PERMANENT 'rules=/sonne3/.../GIS/colorscript_farben_temp'

hm, maybe quite confusing (at least for me). Can we change it in GRASS 7

color=rules

* rules not given or rules=-, read from stdin
* otherwise read from the file

and eliminate interactive mode

?

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

On Tue, 2008-08-05 at 21:30 +0200, Martin Landa wrote:

Hi,

2008/8/5 Glynn Clements <glynn@gclements.plus.com>:
> What it says; you can't use both "color" and "rules". If you use
> "color=rules", the rules are read from stdin (equivalent to -i). If
> you use "rules=...", the rules are read from the specified file.
>
> So, just omit the color=rules option, i.e.:
>
> r.colors map=b25_daymax0.l1_neu@PERMANENT 'rules=/sonne3/.../GIS/colorscript_farben_temp'

hm, maybe quite confusing (at least for me). Can we change it in GRASS 7

color=rules

* rules not given or rules=-, read from stdin
* otherwise read from the file

and eliminate interactive mode

?

Martin

I remember facing this error message some time ago which sounded very
logical. Since then I never force a "color" when I want to use "rules".
Maybe an additional reference in the manual wouldn't leave any space for
doubts.

Hi,

2008/8/5 Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de>:

[...]

I remember facing this error message some time ago which sounded very
logical. Since then I never force a "color" when I want to use "rules".
Maybe an additional reference in the manual wouldn't leave any space for
doubts.

that 'color=rules rules=path_to_file' ends with the error is not so
much logical (in my eyes;-)

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa *

On Tue, 2008-08-05 at 22:47 +0200, Martin Landa wrote:

Hi,

2008/8/5 Nikos Alexandris <nikos.alexandris@felis.uni-freiburg.de>:

[...]

> I remember facing this error message some time ago which sounded very
> logical. Since then I never force a "color" when I want to use "rules".
> Maybe an additional reference in the manual wouldn't leave any space for
> doubts.

that 'color=rules rules=path_to_file' ends with the error is not so
much logical (in my eyes;-)

Martin

Martin,

you are (also) right. But in my case, I really never got tyrannised by
this module.

Martin Landa wrote:

> I try to adapt the color table of a raster file using an ascii file (> rules option) with the following statement:
>
> r.colors map=b25_daymax0.l1_neu@PERMANENT color=rules 'rules=/sonne3/.../GIS/colorscript_farben_temp'
>
> Hence the following message comes up:
>
> "color", "rules", and "raster" options are mutually exclusive
>
> Any ideas what this means? Please see also the attached colorscript.

it seems to be a bug in r.colors, the attached patch quickly fix it.

It isn't a bug. color=rules was left as an "alias" for -i solely for
backwards compatibility.

Anyway r.colors needs some more cleaning. In GRASS7 I would suggest to
remove

-i Enter rules interactively

1) then if rules file is given read from the file
2) if not given (and color=rules) switch to the interactive mode
3) or completely remove interactive mode, print error about missing
rules file <- seems to be a better solution, to avoid any interactive
mode in GRASS7

?

If reading from stdin remains, it will be via -i, although I'm
inclined to simply remove the feature altogether (it doesn't work well
the GUI).

> What it says; you can't use both "color" and "rules". If you use
> "color=rules", the rules are read from stdin (equivalent to -i). If
> you use "rules=...", the rules are read from the specified file.
>
> So, just omit the color=rules option, i.e.:
>
> r.colors map=b25_daymax0.l1_neu@PERMANENT 'rules=/sonne3/.../GIS/colorscript_farben_temp'

hm, maybe quite confusing (at least for me). Can we change it in GRASS 7

color=rules

* rules not given or rules=-, read from stdin
* otherwise read from the file

and eliminate interactive mode

The color=rules option will go. Note that the description of -i is
misleading; it reads rules from stdin, which can be redirected from a
file (you only get "interactive" behaviour if stdin is a tty).

Reading rules from stdin is a substantial deviation from normal
behaviour. If this feature remains (and I'm not sure that it should),
it should be a completely separate flag (i.e. -i), not just a
particular choice for the color= option.

Currently, there are four special cases for the color= option: random,
grey.eq, grey.log and rules. All other options just use the
corresponding rules file from $GISBASE/etc/colors.

The -g and -e switches make grey.log and grey.eq redundant, and -i
makes color=rules redundant, which leaves color=random as the only
special case (it cannot be implemented via a rules file, and only
works for integer maps). I'm considering making color=random a
separate flag.

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

On Tue, 2008-08-05 at 22:00 +0100, Glynn Clements wrote:
[...]

The -g and -e switches make grey.log and grey.eq redundant

By the way, something I don't understand (copy-paste from the manual):

The -e flag equalizes the original raster's color table. It can preclude
the need for grey.eq rule, when used as -e color=grey. Note however,
that this will not yield a color table identical to color=grey.eq,
because grey.eq scales the fraction by 256 to get a grey level, while -e
uses it to interpolate the original colour table.

Martin Landa wrote:

> I remember facing this error message some time ago which sounded very
> logical. Since then I never force a "color" when I want to use "rules".
> Maybe an additional reference in the manual wouldn't leave any space for
> doubts.

that 'color=rules rules=path_to_file' ends with the error is not so
much logical (in my eyes;-)

Well, the error message seems clear enough:

  "color", "rules", and "raster" options are mutually exclusive

The description of color=rules in the manpage is also quite clear:

       The rules color table type will cause r.colors to read color table
       specifications from standard input (stdin) and will build the color ta-
       ble accordingly.

However, it doesn't appear until around half-way through a fairly
large manpage.

For 6.3.1/6.4, it may be worth noting the mutual exclusion earlier on.
For 7.0, color=rules will disappear shortly.

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

Nikos Alexandris wrote:

> The -g and -e switches make grey.log and grey.eq redundant

By the way, something I don't understand (copy-paste from the manual):

The -e flag equalizes the original raster's color table. It can preclude
the need for grey.eq rule, when used as -e color=grey. Note however,
that this will not yield a color table identical to color=grey.eq,
because grey.eq scales the fraction by 256 to get a grey level, while -e
uses it to interpolate the original colour table.

It then goes on to say:

  If the original colour table is a 0-255 grey scale, -e is
  effectively scaling the fraction by 255. Different algorithms
  are used. -e is designed to work with any color table, both
  the floating point and the integer raster maps.

Essentially the only difference is in how a floating-point value
between 0 and 1 is converted to an integer between 0 and 255. In
practice, the difference will be invisible to the eye.

Here's a concrete example:

  $ r.colors elevation.dem -e color=grey
  Reading elevation.dem ...
  Color table for <elevation.dem> set to grey
  $ r.mapcalc 'tmp1 = r#elevation.dem'
  $ r.colors elevation.dem color=grey.eq
  Reading elevation.dem ...
  Color table for <elevation.dem> set to grey.eq
  $ r.mapcalc 'tmp2 = r#elevation.dem'
  $ r.mapcalc 'diff = tmp1 - tmp2'
  $ r.stats -c diff
  -1 155417
  0 147001
  r.stats complete.

So, roughly half the cells are identical between the two, while half
differ by one intensity level.

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

Glynn wrote:

If reading from stdin remains, it will be via -i, although
I'm inclined to simply remove the feature altogether
(it doesn't work well the GUI).

I agree that -i is confusing from the auto-gen GUI.

Please keep the ability to pipe rules from stdin. I use it all the time,
both from the command line and within scripts when it is simple enough
that using a temp file would just be a waste.
e.g. the r.colors.stddev addons script.

I would be happy with removing color=rules and the -i flag *if* 'rules=-'
remained to tell it to expect data from stdin.

Reading rules from stdin is a substantial deviation from normal
behaviour. If this feature remains (and I'm not sure that it should),
it should be a completely separate flag (i.e. -i), not just
a particular choice for the color= option.

see also v.in.ascii, r.category, r.reclass, r.what, r.what.color, r.profile, ...

we should allow input from stdin for modules which it is useful, and we should do so in a standardized way across all modules. I am happy with the "rules=-" solution; I find adding flags for "expect from stdin" to be unneeded complication and highly confusing to new GUI users.

I wish to make the distinction between removing r.colors "interactive mode" and removing the ability to pipe from stdin rather than from a file.

I'm considering making color=random a separate flag.

example usage?
  "ERROR: colors= rules= and -random flag are mutually exclusive"
???

Hamish

Hamish wrote:

> If reading from stdin remains, it will be via -i, although
> I'm inclined to simply remove the feature altogether
> (it doesn't work well the GUI).

I agree that -i is confusing from the auto-gen GUI.

Well; not just confusing. If you run a module from the GUI, and it
expects data from stdin, it's likely to wait forever for input which
will never come. The GUI should explicitly close stdin.

Please keep the ability to pipe rules from stdin. I use it all the time,
both from the command line and within scripts when it is simple enough
that using a temp file would just be a waste.
e.g. the r.colors.stddev addons script.

I would be happy with removing color=rules and the -i flag *if* 'rules=-'
remained to tell it to expect data from stdin.

Note that r.colors doesn't currently understand "rules=-" (although
you can probably use e.g. rules=/dev/stdin).

I can see some advantage to using e.g. "rules=-", as it's easy for the
GUI to prevent this (just require that the answer to any old_file
option exists).

> Reading rules from stdin is a substantial deviation from normal
> behaviour. If this feature remains (and I'm not sure that it should),
> it should be a completely separate flag (i.e. -i), not just
> a particular choice for the color= option.

see also v.in.ascii, r.category, r.reclass, r.what, r.what.color, r.profile, ...

we should allow input from stdin for modules which it is useful, and
we should do so in a standardized way across all modules. I am happy
with the "rules=-" solution; I find adding flags for "expect from
stdin" to be unneeded complication and highly confusing to new GUI
users.

Well, I've just started removing most of the explicitly interactive
stuff.

In the course of that, I've noticed at least one module (r.quant)
which only allows rules from stdin, not from a file. It wouldn't
surprise me if there are others.

We probably want a library function to fopen() an input file, which
returns stdin if "-" is given as the filename. There's still the issue
that any modules which need to seek will only work with a file, not a
pipe.

I wish to make the distinction between removing r.colors "interactive
mode" and removing the ability to pipe from stdin rather than from a
file.

> I'm considering making color=random a separate flag.

example usage?
  "ERROR: colors= rules= and -random flag are mutually exclusive"
???

The flag would be equivalent to color=random, so it would exclude with
color= and anything which color= excludes.

OTOH, maybe it should be a separate module.

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

On Wed, 2008-08-06 at 01:14 +0100, Glynn Clements wrote:

Nikos Alexandris wrote:

> > The -g and -e switches make grey.log and grey.eq redundant
>
> By the way, something I don't understand (copy-paste from the manual):
>
> The -e flag equalizes the original raster's color table. It can preclude
> the need for grey.eq rule, when used as -e color=grey. Note however,
> that this will not yield a color table identical to color=grey.eq,
> because grey.eq scales the fraction by 256 to get a grey level, while -e
> uses it to interpolate the original colour table.

It then goes on to say:

  If the original colour table is a 0-255 grey scale, -e is
  effectively scaling the fraction by 255. Different algorithms
  are used. -e is designed to work with any color table, both
  the floating point and the integer raster maps.

Essentially the only difference is in how a floating-point value
between 0 and 1 is converted to an integer between 0 and 255. In
practice, the difference will be invisible to the eye.

Here's a concrete example:

  $ r.colors elevation.dem -e color=grey
  Reading elevation.dem ...
  Color table for <elevation.dem> set to grey
  $ r.mapcalc 'tmp1 = r#elevation.dem'
  $ r.colors elevation.dem color=grey.eq
  Reading elevation.dem ...
  Color table for <elevation.dem> set to grey.eq
  $ r.mapcalc 'tmp2 = r#elevation.dem'
  $ r.mapcalc 'diff = tmp1 - tmp2'
  $ r.stats -c diff
  -1 155417
  0 147001
  r.stats complete.

So, roughly half the cells are identical between the two, while half
differ by one intensity level.

Thank you for your time and the concrete example. Nikos