[GRASS-dev] [bug #5212] (grass) default color map range does not cover full data

[Glynn Clements]

Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=5212
> -------------------------------------------------------------------------
> 
> Subject: default color map range does not cover full data
> 
> Hi,
> 
> if you create a map as follows:
> 
> g.region n=50 s=0 w=0 e=50 res=1
> r.mapcalc colorbug="x()*y()"
> d.rast colorbug
> 
> you can see the top right cell has no color.

Actually, it's white rather than "no colour" (run e.g. "d.erase green"
first).

> d.what.rast shows that the cell has data, (2450.25 = 49.5^2, center of top-
> right cell)
> 
> r.colors colorbug rule=rainbow   # doesn't fix it (thankfully)
> 
> nor do any of the other dynamic color rules (same with color=).
> 
> using a fixed-rule color map like rule=terrain is ok.
> 
> The bug is not seen with CELL maps:
> r.mapcalc colorbug="int(x()*y())"
> 
> tweak beyond-color-range check from >= to >, or add GRASS_EPSILON to range_max
> before applying rules for FP maps?

This isn't an issue with colour tables per se, but with the range
calculation. "r.info colorbug" says:

 |   Range of data:    min = 0.250000  max = 2400.750000                      |

Likewise, the colour table for the map ends at 2400.75.

If I manually edit the colour table to end at 2450.25, the top-right
cell has the correct colour.

Note that 2400.75 = 48.5 * 49.5.

Changing the region to:

$ g.region n=25 s=0 w=0 e=50 res=1
$ r.mapcalc colorbug="x()*y()"
$ r.info colorbug | fgrep Range
 |   Range of data:    min = 0.250000  max = 1188.250000                      |

Note that 1188.25 = 48.5 * 24.5.

So, it's missing the right-most cell on the top row.

Looking at G_row_update_fp_range():

	int G_row_update_fp_range (
	    void *rast,int n,
	    struct FPRange *range,
	    RASTER_MAP_TYPE data_type)
	{
	    DCELL val = 0L;
	
	    while (n-- > 0)
	    {
		switch(data_type)
		{
		   case CELL_TYPE: val = (DCELL) *((CELL *) rast); break;
		   case FCELL_TYPE: val = (DCELL) *((FCELL *) rast); break;
		   case DCELL_TYPE: val = *((DCELL *) rast); break;
	        }
	
	        if (G_is_null_value(rast, data_type))
		{
	           rast = G_incr_void_ptr(rast, G_raster_size(data_type));
		   continue;
	        }
	        if (range->first_time)
	        {
	           range->first_time = 0;
	           range->min = val;
	           range->max = val;
	           continue;
	        }
		if (val < range->min)
		    range->min = val;
		if (val > range->max)
		    range->max = val;
	
	        rast = G_incr_void_ptr(rast, G_raster_size(data_type));
	    }
	
	    return 0;
	}

For the first cell processed, it sets both min and max to the cell's
value, then executes a "continue", which skips the G_incr_void_ptr()
(but n is still decremented). Thus, it's processing the first cell
twice, and missing the last cell.

Fix:

--- range.c	23 Jul 2006 01:32:16 -0000	2.3
+++ range.c	17 Oct 2006 14:22:09 -0000
@@ -565,12 +565,14 @@
            range->first_time = 0;
            range->min = val;
            range->max = val;
-           continue;
         }
-	if (val < range->min)
-	    range->min = val;
-	if (val > range->max)
-	    range->max = val;
+	else
+	{
+	   if (val < range->min)
+	       range->min = val;
+	   if (val > range->max)
+	       range->max = val;
+	}
 
         rast = G_incr_void_ptr(rast, G_raster_size(data_type));
     }

With the above fix, r.info reports the correct range, and the white
pixel is gone.

Committed to CVS.

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