Updated r.colors - was: [GRASS-dev] problem with r.colors on Mac

[Michael Barton]

Thanks Glynn. This is real nice.

Two suggestions.

1) for the rules entry, can it be a browse prompt initially set to the
directory where these rules files are stored rather than a list? That way,
users could also select their own rules files stored anywhere on their
system.

2) it might be good in the long run to change the equalization and log flags
to an "enhance=" argument. That way other enhancement algorithms (e.g.,
gaussian) could be added without making a lot of flags.

This is a real nice improvement already though.

Michael


On 4/12/07 2:53 PM, "Glynn Clements" <glynn at gclements.plus.com> wrote:

> 
> Glynn Clements wrote:
> 
>> Beyond that, I'd like to propose eliminating most of the individual
>> G_make_*_colors() functions in favour of a general purpose function
>> which takes the name of a rules file as an argument.
> 
> I've done this, and would appreciate it if the changes could receive
> some testing.
> 
> The core of r.colors' color=rules and rules= options is now in
> lib/gis/color_rules.c. Apart from the lower-level functions used by
> r.colors, this provides two new functions:
> 
> int G_make_colors(struct Colors *colors, const char *name, CELL min, CELL
> max);
> int G_make_fp_colors(struct Colors *colors, const char *name, DCELL min, DCELL
> max);
> 
> These effectively supersede most of the G_make_*_[fp_]colors()
> functions, i.e.:
> 
>  G_make_aspect_colors
>  G_make_byg_colors
>  G_make_byr_colors
>  G_make_grey_scale_colors
>  G_make_gyr_colors
>  G_make_rainbow_colors
>  G_make_ramp_colors
>  G_make_ryg_colors
>  G_make_wave_colors
> 
> plus the _fp_ versions.
> 
> A call such as:
> 
> G_make_rainbow_colors(&colors, min, max);
> 
> can be replaced with:
> 
> G_make_colors(&colors, "rainbow", min, max);
> 
> The following functions don't have direct equivalents:
> 
>  G_make_histogram_eq_colors
>  G_make_histogram_log_colors
>  G_make_random_colors
> 
> The first two can be replaced with a combination of
> G_make_colors(&colors, "grey", ...) and either G_histogram_eq_colors()
> or G_log_colors(), e.g.:
> 
> G_make_colors(&colors, "grey", min, max);
> G_histogram_eq_colors(&colors_tmp, &colors, &statf);
> colors = colors_tmp;
> or:
> G_make_colors(&colors, "grey", min, max);
> G_log_colors(&colors_tmp, &colors, 100);
> colors = colors_tmp;
> 
> [I will modify G_{histogram_eq,log}_colors to allow the colour table
> to be updated in-place, to avoid the need for a temporary variable.]
> 
> G_make_random_colors() cannot be implemented by means of colour rules,
> and so will remain.
> 
> The corresponding changes to r.colors are:
> 
> 1. "r.colors color=rules" is implemented using the lower level functions
> G_read_color_rules(), G_parse_color_rule() etc, with r.colors itself
> handling terminal interaction.
> 
> 2. "r.colors rules=" just calls G_make_fp_colors() with the specified
> rule name.
> 
> Also, the rules files have been moved to the lib/gis/color directory.
> 
> The next step is to replace the various G_make_*_[fp_]colors()
> functions with wrappers around G_make_[fp_]colors(). Unless that shows
> up any problems, I'll replace the use of G_make_*_[fp_]colors() with
> direct calls to G_make_[fp_]colors(), and merge the rules= and color=
> options in r.colors.

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

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