[GRASS-dev] r.colors "-e" not going to full range

[Glynn Clements]

Hamish wrote:

> I just created a v.surf.rst elevation surface from some point data which
> has a few negative values in it. After creating the surface I set the
> colors with 'r.colors -e color=bcyr'. It looks really nice but there are
> white holes in the d.rast display.
> 
> r.info -r shows:
> min=-1.510814
> max=146.157700
> 
> The colr/ file doesn't go to one integer beyond the full range:
> ----------------------------------
> % -1 145
> nv:255
> *:255
> -1:0:0:255 0:0:94:255
> ...
> 144:255:1:0 145:255:1:0
> ----------------------------------
> 
> ??

I didn't realise that "r.colors -e" even worked on FP data;
"r.colors color=grey.eq" doesn't.

Ultimately, the code is dependent upon the categories returned by
G_next_cell_stat(). If it only returns up to category 145, then the
colour table will only extend to that value.

> I also noticed for another map 'r.colors -e' made a massive and slow
> colr/ file (1 for each cat) when the raster values were +-250000. That
> was a diff map centered on zero and I was using r.colors.stddev (wiki
> addons) to set the colors. While it had those huge outliers 95% of the
> points were +-5 (hence using the -e flag to get useful colors). It took
> impossibly long to render of course, so I looked in the colr/ file and
> discovered it was huge.
> 
> Ok, maybe that's a feature of the -e method. But what I saw that was
> interesting was that between -265000 and -120 all the R:G:B values were
> identical, ie all those thousands and thousands of rules could have been
> condensed into a single "-265000:R:G:B -120:R:G:B". And that a little
> program to do that would probably be trivial.  I am a bit unsure if that
> condensing should happen as a addon script which reprocesses the file,
> when the colr/ file is created by 'r.colors -e', or when the color rules
> are read in upon d.rast. (or some combination of the above) It would seem like a nice enhancement to have that happen though.
> 
> I notice that even in my current -1.5 thru 146m map '-e' produces some redundant entries.

Can you test the attached patch?

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

-------------- next part --------------
Index: lib/gis/color_xform.c
===================================================================
RCS file: /grassrepository/grass6/lib/gis/color_xform.c,v
retrieving revision 2.2
diff -u -r2.2 color_xform.c
--- lib/gis/color_xform.c	11 Apr 2007 17:01:21 -0000	2.2
+++ lib/gis/color_xform.c	5 Dec 2007 16:51:01 -0000
@@ -65,6 +65,8 @@
     long count, total, sum;
     CELL cat, prev;
     int first;
+    int holding;
+    CELL hold;
 
     G_init_colors(dst);
 
@@ -89,6 +91,7 @@
     sum = 0;
     prev = 0;
     first = 1;
+    holding = 0;
 
     G_get_d_raster_color(&min, &red, &grn, &blu, src);
 
@@ -105,7 +108,24 @@
 	G_get_d_raster_color(&x, &red2, &grn2, &blu2, src);
 
 	if (!first)
-	    G_add_color_rule(prev, red, grn, blu, cat, red2, grn2, blu2, dst);
+	{
+	    if (red == red2 && grn == grn2 && blu == blu2)
+	    {
+		if (!holding)
+		{
+		    holding = 1;
+		    hold = prev;
+		}
+	    }
+	    else if (holding)
+	    {
+		G_add_color_rule(hold, red, grn, blu, prev, red, grn, blu, dst);
+		G_add_color_rule(prev, red, grn, blu, cat, red2, grn2, blu2, dst);
+		holding = 0;
+	    }
+	    else
+		G_add_color_rule(prev, red, grn, blu, cat, red2, grn2, blu2, dst);
+	}
 
 	sum += count;
 	first = 0;
@@ -115,6 +135,9 @@
 	grn = grn2;
 	blu = blu2;
     }
+
+    if (holding)
+	G_add_color_rule(hold, red, grn, blu, prev, red, grn, blu, dst);
 
     return 0;
 }