Re: [GRASS-user] error message coming with r.colors
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
Hi,
2008/8/5 christian Brandt [EMAIL PROTECTED]:
I try to adapt the color table of a raster file using an ascii file ( rules
option) with the following statement:
r.colors [EMAIL PROTECTED] 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.
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
?
Martin
[cc: grass-dev, sorry for cross-posting)
--
Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa *
Index: raster/r.colors/main.c
===
--- raster/r.colors/main.c (revision 32534)
+++ raster/r.colors/main.c (working copy)
@@ -109,6 +109,7 @@
char *style, *cmap, *cmapset;
char *rules;
int fp;
+FILE *rules_file;
struct GModule *module;
struct
{
@@ -237,6 +238,7 @@
cmap = opt.rast-answer;
rules = opt.rules-answer;
+rules_file = NULL;
if (!name)
G_fatal_error(_(No map specified));
@@ -244,11 +246,11 @@
G_fatal_error(_
(One of \-i\ or \-r\ or options \color\, \rast\ or \rules\ must be specified!));
-if (interactive (style || rules || cmap))
+if (interactive ((strcmp(style, rules) rules) || cmap))
G_fatal_error(_
(Interactive mode is incompatible with \color\, \rules\, and \raster\ options));
-if ((style (cmap || rules)) || (cmap rules))
+if ((strcmp(style, rules) (cmap || rules)) || (cmap rules))
G_fatal_error(_
(\color\, \rules\, and \raster\ options are mutually exclusive));
@@ -313,7 +315,11 @@
(CELL) max);
}
else if (strcmp(style, rules) == 0) {
- if (!read_color_rules(stdin, colors, min, max, fp))
+ rules_file = fopen(rules, r);
+ if (rules_file == NULL) {
+ G_fatal_error(_(Unable to open rules file %s), rules);
+ }
+ if (!read_color_rules(rules_file, colors, min, max, fp))
exit(EXIT_FAILURE);
}
else if (find_rule(style))
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 'rules=/sonne3/.../GIS/colorscript_farben_temp' -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
Hi, 2008/8/5 Glynn Clements [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] '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 * ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
On Tue, 2008-08-05 at 21:30 +0200, Martin Landa wrote: Hi, 2008/8/5 Glynn Clements [EMAIL PROTECTED]: 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 [EMAIL PROTECTED] '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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
On Tue, 2008-08-05 at 22:47 +0200, Martin Landa wrote: Hi, 2008/8/5 Nikos Alexandris [EMAIL PROTECTED]: [...] 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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] '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 [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
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 [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
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 [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error message coming with r.colors
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 [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
