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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev