r.colors: make nice random colors like r.watershed

[hamish]

r.watershed has some color rule creation code it in which makes the random rules not quite pastel in nature, but cool. it's a lot more pleasant than r.color's color=random method.

see the r.watershed examples here:

​http://grass.osgeo.org/screenshots/raster.php

it would be nice to move that rule generation code into libgis and then add a new "r.colors color=random_cool" or similar option. (and simplify r.watershed in the process)

My preference is that the seed would not be constant by default, so if you don't like the result you just run r.colors again and d.redraw.

thanks, Hamish

[hamish]

'd.vect -c' could use it too

Hamish

[glynn]

Replying to hamish:

r.watershed has some color rule creation code it in which makes the random rules not quite pastel in nature, but cool. it's a lot more pleasant than r.color's color=random method.

see the r.watershed examples here:

​http://grass.osgeo.org/screenshots/raster.php

it would be nice to move that rule generation code into libgis and then add a new "r.colors color=random_cool" or similar option. (and simplify r.watershed in the process)

If I'm reading the code correctly, it creates a set of random colours, then replaces any dark colours with non-random colours selected from generated gradients. IOW, it's a fudge which shouldn't be elevated to a library function.

If you just want to eliminate dark or saturated colours, it would be preferable to add transformation functions to adjust and/or clip the intensity, saturation and hue, which could then be applied to any existing colour rule, not just random colours.

[hamish]

Replying to glynn:

If I'm reading the code correctly, it creates a set of random colours, then replaces any dark colours with non-random colours selected from generated gradients. IOW, it's a fudge which shouldn't be elevated to a library function.

ok. fwiw I'm looking at a r.watershed map with one color as 27:36:70, fairly dark.

If you just want to eliminate dark or saturated colours,

this is the core of the wish I suppose,

it would be preferable to add transformation functions to adjust and/or clip the intensity, saturation and hue, which could then be applied to any existing colour rule, not just random colours.

r.colors -m # for "mute" ?

It would be a nice excuse to create proper G_hsv2rgb() and G_rgb2hsv() fns. ie calculate hue angle using real sine/cosine, not just use the hexagon approx to the circle. ​http://www.mandelbrot-dazibao.com/HSV/HSV.htm

I am also a little confused in my r.cpt2grass GMT color scale -> GRASS colr/ rules converter: "value" = 0.0 is white, but is 1.0 black and 0.5 "maximum"? or is 1.0 full-scale color? Some of the GMT rules (/usr/share/gmt/cpt/GMT_topo.cpt) have S all < 0.5 and look washed out with my script unless you do S*=2. And another (GMT_sealand.cpt) has value all = 1.0, and AFAICT that all becomes black?

​http://article.gmane.org/gmane.comp.gis.grass.user/23635/ ​http://trac.osgeo.org/grass/browser/grass-addons/raster/r.colors.tools/r.cpt2grass

Maybe I just have to elevate my brain sugar and study it again. (eg mixing up S and V and/or HSV and HIS)

the wikipedia page on it suggests V=0.0 is white and 1.0 is black. ​http://en.wikipedia.org/wiki/HSL_and_HSV shrug.

but I digress, Hamish

[hamish]

re. the fairly dark r.watershed color rule:

raster/r.watershed/ram/close_maps2.c

if((blue*.11 + red*.30 + green*.59) < 100) { 
   G_set_color(r, rd, gr, bl, &colors);

Matlab (or Octave) calc:

>> rgb = [ 27 36 70 ]
>> mult = [.11 .30 .59]
>> sum(rgb .* mult) 
ans =

   55.0700

55.07 < 100 ???

Hamish