Hamish wrote: > > 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:
That's a completely different issue. Apart from anything else, -e uses integer categories. > > 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: > or diff'd with the previous (r30909, G_add_d_..()): > - % 0.010000000000000003677613769071 64.565417527653337970150460023433 > + % 0.010000000000000000208166817117 64.565417527653323759295744821429 Right; that makes sense. The difference corresponds to the bottom few bits of a double. > but now -g does bad things to the original CELL 0-65534 map: You don't say ;) log(0) is negative infinity; applying a logarithmic colour table to a map which extends to (or below) zero isn't going to work. > should it be like > if (i == 0) > - x = min; > + x = exp(lmin); > > etc. ? No; if any change is required, it's more like: if (min <= 0) G_fatal_error(...) > > 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. That's why I suggested it as an option. I suspect that the default colour was intended primarily for use with discrete categories; I'm not sure whether it makes much sense for floating-point data. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev