[GRASS5] Re: [GRASSLIST:3252] r.colors color= proposal

GRASS GRASS developer
1

Michael Barton wrote:

> Actually, maybe we should just change the semantics of the "color=..."
> option so that anything other than "rules", "grey.eq", "grey.log" and
> "random" is treated as the name of a rules file.

This is a great idea.

For now, rather than changing the behaviour of color=, I've added a
rules= option and rule files for the existing options (minus those
cases noted above).

I considered adding the (dynamically generated) list of rule files to
opt4->options. However, given that adding new rule files is trivial, I
suspect that the list could easily grow to the point where the option
would need to be removed to avoid making a mess of "r.colors help".

Regarding grey.eq and grey.log: it's arguable that histogram
equalisation (linear and logarithmic) could be applied to any colour
scheme, not just grey-scale. In which case, maybe they should be a
separate option rather than a specific colour scheme.

--
Glynn Clements <glynn.clements@virgin.net>

2

> > Actually, maybe we should just change the semantics of the
> > "color=..." option so that anything other than "rules", "grey.eq",
> > "grey.log" and"random" is treated as the name of a rules file.
>
> This is a great idea.

For now, rather than changing the behaviour of color=, I've added a
rules= option and rule files for the existing options (minus those
cases noted above).

Folks should note that files loaded with the rules= option must be
located in the $GISBASE/etc/colors/ directory.

I considered adding the (dynamically generated) list of rule files to
opt4->options. However, given that adding new rule files is trivial, I
suspect that the list could easily grow to the point where the option
would need to be removed to avoid making a mess of "r.colors help".

see 'g.mapsets -l'

Regarding grey.eq and grey.log: it's arguable that histogram
equalisation (linear and logarithmic) could be applied to any colour
scheme, not just grey-scale. In which case, maybe they should be a
separate option rather than a specific colour scheme.

Interesting.. figuring out a log-color map by hand is a pain and doing
something simple like 'r.mapcalc logmap=log(map)' is wasteful.

I've also found being able to flip a colormap is often useful & doubles
your possibilities without very much overhead. I guess that only works
with all-percentage based rules however. All the predefined ones are
percentage based though, with the exception of byg, byr, gyr, and ryg
which all contain "0 white". Perhaps those 0 rules should be removed now
that GRASS has NULL support?

In other r.colors news, I've just added support for colon separated
R:G:B triplets, to be consistent with the d.* modules[*]. Backwards
compatibility with space separated triplets is maintained, although
should be left unadvertised IMO.

e.g.

1 0:120:255

seems less confusing than

1 0 120 255

to me.

[*] I'm pretty much finished with TrueColor support for core modules
now; let me know if there are any others you want done.

I commented out the code for non-referenced color-only rules, as a) they
don't work, and b) I can't figure out what they are supposed to be doing
in the first place.

e.g.

blue
green
200:40:120

73s,
Hamish

3

Hamish wrote:

> Regarding grey.eq and grey.log: it's arguable that histogram
> equalisation (linear and logarithmic) could be applied to any colour
> scheme, not just grey-scale. In which case, maybe they should be a
> separate option rather than a specific colour scheme.

Interesting.. figuring out a log-color map by hand is a pain and doing
something simple like 'r.mapcalc logmap=log(map)' is wasteful.

I've also found being able to flip a colormap is often useful & doubles
your possibilities without very much overhead. I guess that only works
with all-percentage based rules however.

For absolute values, presumably you would use:

  max - x' = x - min
=> x' = max - (x - min)

In which case, the obvious implementation would be to flip the colour
table after it has been created (and the percentages converted to
absolute values).

Histogram equalisation and log scales are a bit more involved. You
can't just transform the colours which form the endpoints of each
range. The obvious implementation is to create the base colour table
fromt the rules, then create a new colour table by looking up
transformed samples using the base table.

All the predefined ones are
percentage based though, with the exception of byg, byr, gyr, and ryg
which all contain "0 white". Perhaps those 0 rules should be removed now
that GRASS has NULL support?

Quite possibly; I just translated src/libes/gis/colr_*.c literally.

--
Glynn Clements <glynn.clements@virgin.net>

4

On Apr 25, 2004, at 5:26 AM, Hamish wrote:

[*] I'm pretty much finished with TrueColor support for core modules
now; let me know if there are any others you want done.

Well, since you mention it, the Cell driver is lacking TrueColor support. If it was there, I could do TrueColor tiff output in d.out.tiff.

I commented out the code for non-referenced color-only rules, as a) they
don't work, and b) I can't figure out what they are supposed to be doing
in the first place.

I'm not clear what you are commenting out. If you mean referring to colors by name (blue, green, etc.) they work for me and are helpful many times. But perhaps you mean something else. Sorry to be dense.

Michael Barton

e.g.

blue
green
200:40:120

_____________________________
C. Michael Barton, Professor & Curator
Department of Anthropology
Arizona State University
Tempe, AZ 85287-2402

Phone: 480-965-6262
Fax: 480-965-7671

5

Michael Barton wrote:

> [*] I'm pretty much finished with TrueColor support for core modules
> now; let me know if there are any others you want done.

Well, since you mention it, the Cell driver is lacking TrueColor
support. If it was there, I could do TrueColor tiff output in
d.out.tiff.

Most of the necessary code is already present in the PNG driver.

However, there's one significant issue: generating a 24-bpp colour
table is *really* slow (this is why r.composite defaults to 15 bpp).
Realistically, a true-colour CELL driver would need to either:

a) generate three separate R/G/B maps, or

b) reduce the colour depth to a level for which a colour table could
reasonably be generated.

Short version:

Large colour tables aren't practical with the current implementation.

Longer version:

The underlying problem is that the code to add a rule to a colour
table checks for overlap with the existing rules. The time taken to do
this is proportional to the total number of rules, so the total time
taken to construct a colour table is proportional to the square of the
number of rules.

For 15-bpp (5 bits/32 levels per component), you need 32 * 32 = 1024
rules (each covering 32 categories). For 24-bpp (8 bits/256 levels per
component), you need 256 * 256 = 65536 rules, which is 64 times as
many rules and takes ~4000 times as long.

Try comparing "r.composite ... levels=256" with the default
(levels=32); the extra time taken is entirely down to building the
colour table.

BTW, if that was the only issue, I suppose that we could create
additional functions for use in such situations (i.e. constructing a
colour table from scratch where it is known that rules never overlap).
But there is still the issue that the time taken to perform lookups
would increase in proportion to the number of rules.

> I commented out the code for non-referenced color-only rules, as a)
> they
> don't work, and b) I can't figure out what they are supposed to be
> doing
> in the first place.

I'm not clear what you are commenting out. If you mean referring to
colors by name (blue, green, etc.) they work for me and are helpful
many times. But perhaps you mean something else. Sorry to be dense.

No; he is referring to rules which only specify a colour, but not a
value.

--
Glynn Clements <glynn.clements@virgin.net>

6

On 4/25/04 5:36 PM, "Glynn Clements" <glynn.clements@virgin.net> wrote:

Michael Barton wrote:

[*] I'm pretty much finished with TrueColor support for core modules
now; let me know if there are any others you want done.

Well, since you mention it, the Cell driver is lacking TrueColor
support. If it was there, I could do TrueColor tiff output in
d.out.tiff.

Most of the necessary code is already present in the PNG driver.

However, there's one significant issue: generating a 24-bpp colour
table is *really* slow (this is why r.composite defaults to 15 bpp).
Realistically, a true-colour CELL driver would need to either:

a) generate three separate R/G/B maps, or

b) reduce the colour depth to a level for which a colour table could
reasonably be generated.

Short version:

Large colour tables aren't practical with the current implementation.

Longer version:

The underlying problem is that the code to add a rule to a colour
table checks for overlap with the existing rules. The time taken to do
this is proportional to the total number of rules, so the total time
taken to construct a colour table is proportional to the square of the
number of rules.

For 15-bpp (5 bits/32 levels per component), you need 32 * 32 = 1024
rules (each covering 32 categories). For 24-bpp (8 bits/256 levels per
component), you need 256 * 256 = 65536 rules, which is 64 times as
many rules and takes ~4000 times as long.

Try comparing "r.composite ... levels=256" with the default
(levels=32); the extra time taken is entirely down to building the
colour table.

BTW, if that was the only issue, I suppose that we could create
additional functions for use in such situations (i.e. constructing a
colour table from scratch where it is known that rules never overlap).
But there is still the issue that the time taken to perform lookups
would increase in proportion to the number of rules.

Oh well. I figured there was a good reason or it would have already been
done.

I commented out the code for non-referenced color-only rules, as a)
they
don't work, and b) I can't figure out what they are supposed to be
doing
in the first place.

I'm not clear what you are commenting out. If you mean referring to
colors by name (blue, green, etc.) they work for me and are helpful
many times. But perhaps you mean something else. Sorry to be dense.

No; he is referring to rules which only specify a colour, but not a
value.

Check.

--

Michael Barton