I use i.atcorr modul, but I have one question:
- in the "run_i_atcorr(radiance_flag, input_band, input_range, elevation,
visibility, parameters, output, output_range)" party,
what is the input_range output_range, you take this from MTL.txt or from
Radiance min and max values, or you fixed it 1:255 (because of DN)?
I think the reason for the input and output range(s), being set by
default to [0,255], is the kind of "need" at the time of the module's creation.
Most programs and applications were somewhat and somehow "restricted"
to 8-bit. In other words, yes, "because of DN"s ranging in [0,255] for various
This is, in my view, something we need to rethink about, given the many
different sensors and the need to update programs to be able to deal with more
than 8-bit data.
If the input data are:
- Spectral Radiance values, it greatly varies and depends on the sensor
and the band. Since you mention "MTL.txt", which implies you are handling
Landsat data, in my attempt to automate the process for Landsat
the actual minimum and maximum values for each input band are set. I think
this is no harm. Though having some nominal input range might be better (?).
Looking at the definition of Spectral Radiance (which derives from radiance),
the units are: W / m^2 / str / nm, that is: Watts per Square meter per
Steradian per Nanometer.
Obviously, the "dynamic" range of spectral radiance values, depend on a
sensor's radiometric characteristics. Worth mention (?), a sensor's
capacity may be appreciated via its bitness: how many bits is the sensor
capable of (digitising the incident electromagnetic energy)? 6, 8, 10, 11 or
even 12? And, practically, for users, what is the bitness of the distributed
products (usually 8 or 16-bit)?
- reflectance values, then it is [0,1].
The output of i.atcorr, is *always* Spectral Reflectance. The option to
rescale is, im my understanding, a "helper" to get the data ready for
subsequent processing with modules or else that expect values ranging in
[0,255]. In this sense, the default [0,255] is "correct" as long as the actual
input is equal or less than 8-bit and/or an 8-bit output is wanted _and_
there is less care to loose radiometric detail in case the input data are of
more than 8-bits.
In general, I keep the output in [0,1], as is the module's intended
The question is "what is the (end-)user's need?"
In case the input is of >8-bit and the subsequent purpose is more than simple
visualisations, then it is better to think about how to proceed and keep the
output being (corrected) spectral radiance ranging in [0,1]. Rescale
accordingly, later on depending on if and what exactly is needed. Or directly
(re)set the output to something larger than [0,255] via the rescale option.
Directed to @grass-dev
I think it is good to update the description of the module's input and output
elements as well as rethink the output scale. I suggest at the very least
svn diff main.cpp
--- main.cpp (revision 69474)
+++ main.cpp (working copy)
@@ -463,6 +463,7 @@
struct Options opts;
opts.iimg = G_define_standard_option(G_OPT_R_INPUT);
+ opts.iimg->description = _("Spectral radiance (or reflectance with -r) input
opts.iscl = G_define_option();
opts.iscl->key = "range";
@@ -490,12 +491,13 @@
opts.icnd->description = _("Name of input text file with 6S parameters");
opts.oimg = G_define_standard_option(G_OPT_R_OUTPUT);
+ opts.oimg->description = _("Spectral reflectance output image");
opts.oscl = G_define_option();
opts.oscl->key = "rescale";
opts.oscl->type = TYPE_INTEGER;
opts.oscl->key_desc = "min,max";
- opts.oscl->answer = "0,255";
+ opts.oscl->answer = "0,1";
opts.oscl->required = NO;
opts.oscl->description = _("Rescale output raster map");
opts.oscl->guisection = _("Output");
I suggest to further customize descriptions of "input" and "output"
options, i.e. to modify the "Name of..." (which derives from the standard set of
options), for most imagery modules. Why not being explicit about what the
expected input is?
Thank you very much for your help.
UMR 5600 Environnement Ville Société, CNRS
Centre de recherche en géographie et aménagement, LCRE, Université Lyon 3
0649 07 25 75
grass-dev mailing list