[GRASS-dev] G_exp_colors()?

[Hamish]

Hamish:
> > There are still slight differences (white spots),
> > 
> > G63> r.info -r A20023352002365.L3m_MO_CHLO_4.chlor_A
> > min=0.010000
> > max=64.565418
> > 
> > G63> r.colors A20023352002365.L3m_MO_CHLO_4.chlor_A col=bcyr -g
> > G63> cat colr/A20023352002365.L3m_MO_CHLO_4.chlor_A
> > % 0.010000000000000003677613769071 64.565417527653337970150460023433
> > nv:255
> > *:255
> > 0.010000000000000003677613769071:0:0:255 0.0109169168:0:7:255
> > 0.0109169168:0:7:255 0.0119179072:0:15:255
> > ....
> > 54.1751303026:255:16:0 59.1425389006:255:8:0
> > 59.1425389006:255:8:0 64.565417527653337970150460023433:255:0:0
> > 
> > 
> > the lowest values are less than the first color rule so they display
> > as white. As do the max cell values which are slightly bigger than
> > the color rule number with excessive number of decimal digits.
>
> Glynn:
> Bear in mind that "r.info -r" is approximating the min/max values to 6
> decimal places. The actual min/max will be much closer to the values
> in the first line of the colr file. IEEE "double" is ~15 significant
> decimal digits.

Ok, right. FWIW in this case min is set from (double)10^-2, so should be
as near to that as doubles can get.


> Given that this seems to be specific to the use of G_log_colors(),

is it?

for the same data 'r.colors -e color=bcyr' only gets half way through the
data range:
% 0 39
nv:255
*:255
0:127:255:128 1:255:1:0
1:255:1:0 2:255:1:0
2:255:1:0 5:255:1:0
5:255:1:0 6:255:1:0
6:255:1:0 7:255:1:0
7:255:1:0 10:255:1:0
10:255:1:0 11:255:1:0
11:255:1:0 16:255:1:0
16:255:1:0 22:255:1:0
22:255:1:0 39:255:1:0


> I suspect that the problem is due to slight errors in the calculation:
....
> However, real arithmetic and floating-point arithmetic aren't quite
> the same thing, and even the slightest error will cause the tests in
> the lookup code to fail.
> 
> I can modify G_log_colors() to use special cases for i==0 and
> i==samples (see attached patch).

Yes, that worked, this is the new colr/ file:
% 0.010000000000000000208166817117 64.565417527653323759295744821429
nv:255
*:255
0.010000000000000000208166817117:0:0:255 0.0109169168:0:7:255
0.0109169168:0:7:255 0.0119179072:0:15:255
0.0119179072:0:15:255 0.0130106801:0:22:255
0.0130106801:0:22:255 0.0142036512:0:30:255
....
45.4569157251:255:31:0 49.6249366001:255:23:0
49.6249366001:255:23:0 54.1751303026:255:16:0
54.1751303026:255:16:0 59.1425389006:255:8:0
59.1425389006:255:8:0 64.565417527653323759295744821429:255:0:0


or diff'd with the previous (r30909, G_add_d_..()):
- % 0.010000000000000003677613769071 64.565417527653337970150460023433
+ % 0.010000000000000000208166817117 64.565417527653323759295744821429
 ...
- 0.010000000000000003677613769071:0:0:255 0.0109169168:0:7:255
+ 0.010000000000000000208166817117:0:0:255 0.0109169168:0:7:255
  0.0109169168:0:7:255 0.0119179072:0:15:255
 ...
  54.1751303026:255:16:0 59.1425389006:255:8:0
- 59.1425389006:255:8:0 64.565417527653337970150460023433:255:0:0
+ 59.1425389006:255:8:0 64.565417527653323759295744821429:255:0:0



but now -g does bad things to the original CELL 0-65534 map:
(66535 is no-data, already reset to be NULL)

% 0 -1
nv:255
*:255
nan:0:7:255 0:0:0:255
nan:0:15:255 nan:0:7:255
nan:0:22:255 nan:0:15:255
....
nan:255:23:0 nan:255:31:0
nan:255:16:0 nan:255:23:0
nan:255:8:0 nan:255:16:0
65534:255:0:0 nan:255:8:0


should it be like
 	if (i == 0)
-	    x = min;
+	    x = exp(lmin);

etc. ?


> Another option would be to add an extra rule at each end, so that any
> values which are slightly out of range (by how much?) just use the end
> colours.
>
> But I'm wondering if it would be better to handle this in the lookup
> code, i.e. whether there should be an option for out-of-range colours
> to use the colour for the corresponding extreme (min or max).

you will see in the above colr/ file examples there is:
nv:255
*:255

nv: is the color to use for null values, *: is the color to use for out
of range.  (a single number there expands to n:n:n greyscale)

if we go slightly beyond min/max we will damage the *: functionality.



Hamish



      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com