[GRASS-dev] Re: [GRASS-user] low radiance values after i.atcor and i.topo.corr

[Glynn Clements]

Markus Neteler wrote:

> > I'm just not familiar with the specifics of i.cluster (e.g. whether it's finding
> > clusters in geographic space or colour space, what the output
> > signifies, etc).
> 
> It takes several maps and builds up a multi-dimensional feature space
> from the pixel (spectral, ...) values. Those are then clustered.

Right. So the geographic position of each cell is ignored; a group of
rasters is just a "set" of points in "colour space" (i.e. each
coordinate is the intensity of a particular band)?

> >> What's needed since we cannot change the format
> >
> > No? If the format was changed to %g (i.e. like %f for "typical"
> > values, like %e for particularly large or small values), it would
> > remain compatible with anything using scanf("%f"), atof(), strtod()
> > etc, as those functions all understand exponential notation.
> 
> Ah, sounds good.
> 
> > [About the only plausible situation where switching from %f to %g or
> > %e can cause problems is when code tries to match FP literals against
> > a regexp such as "[0-9]+\.[0-9]*".]
> >
> > You would need to add an explicit scale= (e.g.) option. As there's no
> > way to pass the scale factor out to the user, the user would have to
> > pass the scale factor in.
> >
> > OTOH, a scale= option and switching to %g aren't mutually exclusive;
> > but %g would largely eliminate the need for scale=, and would probably
> > be more useful.
> 
> If there is no scanning problem, I would appreciate to just increase
> the precision and don't introduce a scale parameter. I guess it then
> just works.

It shouldn't be necessary to increase the precision. For %g, the
precision (default = 6) is the number of significant digits, not the
number of decimal places, even when exponential form isn't used:

    printf("%f\n", 0.000100001);
=>	0.000100

    printf("%f\n", 0.000099999);
=>	0.000100

    printf("%g\n", 0.000100001);
=>	0.000100001

    printf("%g\n", 0.000099999);
=>	9.9999e-05

So the default precision should be fine unless you actually get images
with intensity values accurate to 1PPM or better.

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