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

I just have been having problems with r.colors on the Mac. This is from cvs source code I downloaded and compiled today.

r.colors will crash the GUI when I run it with either grey.eq or grey.log as the color map. It seems to calculate the equalization stretch OK with grey.eq, though, in spite of crashing.

r.colors gives me a blank (i.e. white) image if I use grey.log. I list the color table below. As you can see, it’s just white.

color table from grey.log

% 43844 43964
nv:255
43844:254 43963:254
43964:255 43964:255

Any thoughts?

Michael


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

Michael Barton wrote:

I just have been having problems with r.colors on the Mac. This is from cvs
source code I downloaded and compiled today.

r.colors will crash the GUI when I run it with either grey.eq or grey.log as
the color map. It seems to calculate the equalization stretch OK with
grey.eq, though, in spite of crashing.

My guess is the gronsole code. Running r.colors from the command line
with GRASS_MESSAGE_FORMAT=gui doesn't show anything unusual.

As I've mentioned before, the use of "read" with non-blocking I/O is
likely to be problematic if the program generates output quickly. If
there's a problem here, r.colors is a good candidate to trigger it as
it will generate percentage output relatively fast.

r.colors gives me a blank (i.e. white) image if I use grey.log. I list the
color table below. As you can see, it¹s just white.

color table from grey.log

% 43844 43964
nv:255
43844:254 43963:254
43964:255 43964:255

This is expected behaviour; grey.log maps a value of x to
255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't*
map the minimum value to black, it maps 1 to black (log(1) == 0).

I don't know whether this is a good idea, but it is how grey.log has
always behaved.

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

On 4/10/07 7:04 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

I just have been having problems with r.colors on the Mac. This is from cvs
source code I downloaded and compiled today.

r.colors will crash the GUI when I run it with either grey.eq or grey.log as
the color map. It seems to calculate the equalization stretch OK with
grey.eq, though, in spite of crashing.

My guess is the gronsole code. Running r.colors from the command line
with GRASS_MESSAGE_FORMAT=gui doesn't show anything unusual.

As I've mentioned before, the use of "read" with non-blocking I/O is
likely to be problematic if the program generates output quickly. If
there's a problem here, r.colors is a good candidate to trigger it as
it will generate percentage output relatively fast.

This hasn't happened before for me with r.colors. Other things that run
faster haven't given me problems before, though this has happened with
v.to.rast. Your explanation may well be the correct one. But I wonder why it
is a problem now and not previously (i.e., a month ago).

If read is a problem, what is an alternative? I don't understand the
gronsole code very well (didn't write it), but I might be able to fix a
specific issue like this.

r.colors gives me a blank (i.e. white) image if I use grey.log. I list the
color table below. As you can see, it¹s just white.

color table from grey.log

% 43844 43964
nv:255
43844:254 43963:254
43964:255 43964:255

This is expected behaviour; grey.log maps a value of x to
255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't*
map the minimum value to black, it maps 1 to black (log(1) == 0).

I don't know whether this is a good idea, but it is how grey.log has
always behaved.

I had thought that grey.log was a histogram stretch like grey.eq. In the
docs, it is called "histogram logarithmic transformed grey scale". In that
sense, it seems like it should set the minimum value to black rather than 1.
Thanks for the explanation. Would it be difficult to change this to stretch
the image histogram rather than values of 1 to n?

Michael

__________________________________________
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

Michael Barton wrote:

>> I just have been having problems with r.colors on the Mac. This is from cvs
>> source code I downloaded and compiled today.
>>
>> r.colors will crash the GUI when I run it with either grey.eq or grey.log as
>> the color map. It seems to calculate the equalization stretch OK with
>> grey.eq, though, in spite of crashing.
>
> My guess is the gronsole code. Running r.colors from the command line
> with GRASS_MESSAGE_FORMAT=gui doesn't show anything unusual.
>
> As I've mentioned before, the use of "read" with non-blocking I/O is
> likely to be problematic if the program generates output quickly. If
> there's a problem here, r.colors is a good candidate to trigger it as
> it will generate percentage output relatively fast.

This hasn't happened before for me with r.colors. Other things that run
faster haven't given me problems before, though this has happened with
v.to.rast. Your explanation may well be the correct one. But I wonder why it
is a problem now and not previously (i.e., a month ago).

If read is a problem, what is an alternative?

gets.

Gronsole::output_to_gronsole is written on the assumption that it will
get complete lines. Gronsole::readout tries to do this, but fails to
allow for the fact that "read" may return arbitrary chunks of data
(i.e. partial lines).

If the stream is in non-blocking mode, gets will return an empty
string if a complete line isn't available. The fblocked function can
be used to distinguish this from the case where the process wrote a
blank line. Also, after this case occurs, another readable event won't
be generated for the stream until a complete line is available.

I don't understand the
gronsole code very well (didn't write it), but I might be able to fix a
specific issue like this.

Gronsole::readout is the relevant function.

>> r.colors gives me a blank (i.e. white) image if I use grey.log. I list the
>> color table below. As you can see, it¹s just white.
>>
>> color table from grey.log
>>
>> % 43844 43964
>> nv:255
>> 43844:254 43963:254
>> 43964:255 43964:255
>
> This is expected behaviour; grey.log maps a value of x to
> 255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't*
> map the minimum value to black, it maps 1 to black (log(1) == 0).
>
> I don't know whether this is a good idea, but it is how grey.log has
> always behaved.

I had thought that grey.log was a histogram stretch like grey.eq. In the
docs, it is called "histogram logarithmic transformed grey scale". In that
sense, it seems like it should set the minimum value to black rather than 1.
Thanks for the explanation. Would it be difficult to change this to stretch
the image histogram rather than values of 1 to n?

It wouldn't be hard to change it to map log(min) to black. I'm not so
sure about the histogram equalisation part.

The main issue is whether someone might be relying upon the existing
behaviour.

Beyond that, it would be nice to be able to apply histogram
equalisation and/or logarithmic scaling to any colour table, rather
than just grey.

The existence of grey.log and grey.eq is the main reason that r.colors
still has separate color= and rules= options, as those two cannot be
implemented using rules files.

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

On Wed, Apr 11, 2007 at 11:42:57AM +0100, Glynn Clements wrote:

Michael Barton wrote:
> >> r.colors gives me a blank (i.e. white) image if I use grey.log. I list the
> >> color table below. As you can see, it?s just white.
> >>
> >> color table from grey.log
> >>
> >> % 43844 43964
> >> nv:255
> >> 43844:254 43963:254
> >> 43964:255 43964:255
> >
> > This is expected behaviour; grey.log maps a value of x to
> > 255*log(x)/log(max); the minimum value is ignored. IOW, it *doesn't*
> > map the minimum value to black, it maps 1 to black (log(1) == 0).
> >
> > I don't know whether this is a good idea, but it is how grey.log has
> > always behaved.
>
> I had thought that grey.log was a histogram stretch like grey.eq. In the
> docs, it is called "histogram logarithmic transformed grey scale". In that
> sense, it seems like it should set the minimum value to black rather than 1.
> Thanks for the explanation. Would it be difficult to change this to stretch
> the image histogram rather than values of 1 to n?

It wouldn't be hard to change it to map log(min) to black. I'm not so
sure about the histogram equalisation part.

The main issue is whether someone might be relying upon the existing
behaviour.

Maybe not too much since it is "only" a color table.

Beyond that, it would be nice to be able to apply histogram
equalisation and/or logarithmic scaling to any colour table, rather
than just grey.

Absolutely. A long standing wish...

The existence of grey.log and grey.eq is the main reason that r.colors
still has separate color= and rules= options, as those two cannot be
implemented using rules files.

A simplification would be appreciated, but moreover support for FP map
histogram equalisation etc.

Markus

Markus Neteler wrote:

> It wouldn't be hard to change it to map log(min) to black. I'm not so
> sure about the histogram equalisation part.
>
> The main issue is whether someone might be relying upon the existing
> behaviour.

Maybe not too much since it is "only" a color table.

I've fixed this.

> Beyond that, it would be nice to be able to apply histogram
> equalisation and/or logarithmic scaling to any colour table, rather
> than just grey.

Absolutely. A long standing wish...

I've added two new functions to libgis:

  int G_histogram_eq_colors(struct Colors *, struct Colors *, struct Cell_stats *);
  int G_log_colors(struct Colors *, struct Colors *, int);

Eac function creates a new colour table from an existing colour table.
In both cases, the new table covers the same range as the old table,
but the mapping across the range is either equalised or
logarithmically scaled.

The next step is to add corresponding options to r.colors.

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.

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

Glynn Clements wrote:

> > Beyond that, it would be nice to be able to apply histogram
> > equalisation and/or logarithmic scaling to any colour table, rather
> > than just grey.
>
> Absolutely. A long standing wish...

I've added two new functions to libgis:

  int G_histogram_eq_colors(struct Colors *, struct Colors *, struct Cell_stats *);
  int G_log_colors(struct Colors *, struct Colors *, int);

Eac function creates a new colour table from an existing colour table.
In both cases, the new table covers the same range as the old table,
but the mapping across the range is either equalised or
logarithmically scaled.

The next step is to add corresponding options to r.colors.

Done; r.colors now has -e (hist. eq.) and -g (log. scale) options.

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

On Wed, Apr 11, 2007 at 06:37:48PM +0100, Glynn Clements wrote:

Glynn Clements wrote:

> > > Beyond that, it would be nice to be able to apply histogram
> > > equalisation and/or logarithmic scaling to any colour table, rather
> > > than just grey.
> >
> > Absolutely. A long standing wish...
>
> I've added two new functions to libgis:
>
> int G_histogram_eq_colors(struct Colors *, struct Colors *, struct Cell_stats *);
> int G_log_colors(struct Colors *, struct Colors *, int);
>
> Eac function creates a new colour table from an existing colour table.
> In both cases, the new table covers the same range as the old table,
> but the mapping across the range is either equalised or
> logarithmically scaled.
>
> The next step is to add corresponding options to r.colors.

Done; r.colors now has -e (hist. eq.) and -g (log. scale) options.

Wow - thanks a bunch!

Markus

On Apr 11, 2007, at 2:12 PM, Markus Neteler wrote:

On Wed, Apr 11, 2007 at 06:37:48PM +0100, Glynn Clements wrote:

Glynn Clements wrote:

Beyond that, it would be nice to be able to apply histogram
equalisation and/or logarithmic scaling to any colour table, rather
than just grey.

Absolutely. A long standing wish...

I've added two new functions to libgis:

  int G_histogram_eq_colors(struct Colors *, struct Colors *, struct Cell_stats *);
  int G_log_colors(struct Colors *, struct Colors *, int);

Eac function creates a new colour table from an existing colour table.
In both cases, the new table covers the same range as the old table,
but the mapping across the range is either equalised or
logarithmically scaled.

The next step is to add corresponding options to r.colors.

Done; r.colors now has -e (hist. eq.) and -g (log. scale) options.

Wow - thanks a bunch!

Markus

Glynn, big thanks from me too, I need it all the time, Helena

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Glynn Clements wrote:

Done; r.colors now has -e (hist. eq.) and -g (log. scale) options.

Glynn,

Wow! Now GRASS is able to equalize any color table, superb. Thank you.

Messing around with the new feature I found there is a difference
between -e/-g color=grey and the old color=grey.eq/grey.log; in spearfish:

$ r.colors landcover.30m col=grey.eq
$ r.mapcalc 'tryit_old_eq=#landcover.30m'

$ r.colors -e landcover.30m col=grey
$ r.mapcalc 'tryit_new_eq=#landcover.30m'

There is a difference between the 2 colortables it seems:

$ r.mapcalc 'dif_eq=tryit_new_eq-tryit_old_eq'
$ r.info -r dif_eq
min=-1
max=0

In case of logarithmic scaling there is a difference too:

$ r.colors landcover.30m col=grey.log
$ r.mapcalc 'tryit_old_log=#landcover.30m'

$ r.colors -g landcover.30m col=grey
$ r.mapcalc 'tryit_new_log=#landcover.30m'

$ r.mapcalc 'dif_log=tryit_new_log-tryit_old_log'
$ r.info -r dif_log
min=0
max=10

Is that as expected?

Maciek

On 4/11/07 4:43 AM, "Markus Neteler" <neteler@itc.it> wrote:

On Wed, Apr 11, 2007 at 11:42:57AM +0100, Glynn Clements wrote:

Michael Barton wrote:

I had thought that grey.log was a histogram stretch like grey.eq. In the
docs, it is called "histogram logarithmic transformed grey scale". In that
sense, it seems like it should set the minimum value to black rather than 1.
Thanks for the explanation. Would it be difficult to change this to stretch
the image histogram rather than values of 1 to n?

It wouldn't be hard to change it to map log(min) to black. I'm not so
sure about the histogram equalisation part.

The main issue is whether someone might be relying upon the existing
behaviour.

Maybe not too much since it is "only" a color table.

Beyond that, it would be nice to be able to apply histogram
equalisation and/or logarithmic scaling to any colour table, rather
than just grey.

Absolutely. A long standing wish...

The existence of grey.log and grey.eq is the main reason that r.colors
still has separate color= and rules= options, as those two cannot be
implemented using rules files.

A simplification would be appreciated, but moreover support for FP map
histogram equalisation etc.

I agree with Markus. For r.colors behavior, I suggest ultimately:

map= [name of raster to set color table]

colors= [name of predefined color tables] (merge current rules and colors)

stretch= [grey.eq,color.eq, grey.log, color.log, other?] (put grey.eq and
grey.log here)

rast= [import color table of this raster]

rules= [import user defined color table] (add a gui "prompt" for browse
button)

For backward compatibility in the 6.x series, we'd have to leave grey.eq and
grey.log as valid settings for the colors argument. I suppose we'd have to
leave in the current list of predefined rules files as valid for the rules
argument.

Michael

__________________________________________
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

Maciej Sieczka wrote:

Messing around with the new feature I found there is a difference
between -e/-g color=grey and the old color=grey.eq/grey.log; in spearfish:

$ r.colors landcover.30m col=grey.eq
$ r.mapcalc 'tryit_old_eq=#landcover.30m'

$ r.colors -e landcover.30m col=grey
$ r.mapcalc 'tryit_new_eq=#landcover.30m'

There is a difference between the 2 colortables it seems:

$ r.mapcalc 'dif_eq=tryit_new_eq-tryit_old_eq'
$ r.info -r dif_eq
min=-1
max=0

grey.eq scales the fraction by 256 to get a grey level, while -e uses
it to interpolate the original colour table. If the original colour
table is a 0-255 grey scale, -e is effectively scaling the fraction by
255.

This comes down to how color_look.c (G_get_d_raster_color() etc)
interpolates colour rules. E.g. if you have a single grey-scale rule
with 0% = 0/0/0 and 100% = 255/255/255, 99.9999% gets you 254/254/254.

I don't think there's anything that I can do about this for -e.
grey.eq creates its own grey scale, but -e has to work with any colour
table, so it's reliant upon the existing colour lookup functions.

In case of logarithmic scaling there is a difference too:

$ r.colors landcover.30m col=grey.log
$ r.mapcalc 'tryit_old_log=#landcover.30m'

$ r.colors -g landcover.30m col=grey
$ r.mapcalc 'tryit_new_log=#landcover.30m'

$ r.mapcalc 'dif_log=tryit_new_log-tryit_old_log'
$ r.info -r dif_log
min=0
max=10

Is that as expected?

The algorithm used by grey.log is quite different to that used by -g.

The former takes a "struct Cell_stats", and generates a "step" (a rule
with the same grey level for the start and end points) for each
category which occurs.

The latter simply divides the range into 100[*] logarithmically equal
steps. This eliminates the need to compute statistics, so there are no
issues with FP data or performance issues with large maps.

[*] I can easily change the number of steps, or make it an option.

BTW: -e and -g aren't mutually exclusive.

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

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.

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

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@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

Here is a screenshot of Cesium Magnetometry of a Spanish Neolithic site
(early farming ca. 4200 BC). I used Glynn's new histogram equalized gyr
color table for the magnetometry values and show them in NVIZ.

Michael

<http://www.public.asu.edu/~cmbarton/files/grass_screenshots/punxo_1_coloren
hanced.jpg>

On 4/12/07 2:53 PM, "Glynn Clements" <glynn@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

Michael Barton wrote:

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.

As I've mentioned before, that isn't the purpose of the rules= option.

Once I've merged the rules= and color= options, I can re-use the
rules= option to read rules from a file (but I don't think that you
can specify a default directory for a file option).

Beyond that, it may be worth replacing colour=rules with a flag. Or
even a completely separate r.colors.rules module (I think I've already
expressed my opinions on having an interactive mode in a module which
is otherwise non-interactive).

For now, I'm going to wait to see if any issues arise from the most
recent round of changes.

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.

I'll look into it either when I eventually deal with the rules=/color=
issue (probably 7.x) or when another "modifier" actually gets added.

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

Glynn Clements wrote:

The next step is to replace the various G_make_*_[fp_]colors()
functions with wrappers around G_make_[fp_]colors().

Done.

I'm going to leave it alone for now, to see if any issues arise.

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

Hi Glynn,

I guess I wasn't very clear on this.

On 4/13/07 11:10 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Once I've merged the rules= and color= options, I can re-use the
rules= option to read rules from a file (but I don't think that you
can specify a default directory for a file option).

Beyond that, it may be worth replacing colour=rules with a flag. Or
even a completely separate r.colors.rules module (I think I've already
expressed my opinions on having an interactive mode in a module which
is otherwise non-interactive).

Heavens NO! No interactive mode. I just meant that currently the rules
option only allows you to specify the names of color table files located in
$GISBASE/etc/colors. My suggestion is to allow you to specify color table
files located anywhere. For example

...as we have now

r.colors map=elevation rules=byr

...as I suggest, the following would be permitted

r.colors map=elevation rules=/Users/cmbarton/colors/byr

When I was talking about a prompt, I meant the gui-prompt in the
interface-description xml file. Currently, it calls a list of values that
are the names of text files in the $GISBASE/etc/colors directory. As I
suggest, this would be replaced by a file browsing prompt (#prompt
file,file,file for scripts).

Michael

__________________________________________
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

Glynn Clements wrote:

Once I've merged the rules= and color= options, I can re-use the
rules= option to read rules from a file (but I don't think that you
can specify a default directory for a file option).

I've done that. The colors= option now uses the rules files (except
for the grey.eq, grey.log, random and rules choices). The rules=
option is now a file option.

Beyond that, it may be worth replacing colour=rules with a flag. Or
even a completely separate r.colors.rules module (I think I've already
expressed my opinions on having an interactive mode in a module which
is otherwise non-interactive).

For now, I've added a flag (-i), and retained color=rules.

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

Many thanks. This can open up r.colors to user submitted color tables. I'm
looking forward to trying this out.

Michael

On 4/13/07 9:15 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Glynn Clements wrote:

Once I've merged the rules= and color= options, I can re-use the
rules= option to read rules from a file (but I don't think that you
can specify a default directory for a file option).

I've done that. The colors= option now uses the rules files (except
for the grey.eq, grey.log, random and rules choices). The rules=
option is now a file option.

Beyond that, it may be worth replacing colour=rules with a flag. Or
even a completely separate r.colors.rules module (I think I've already
expressed my opinions on having an interactive mode in a module which
is otherwise non-interactive).

For now, I've added a flag (-i), and retained color=rules.

__________________________________________
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