[GRASS-user] (no subject)

[Nikos Alexandris]

Julita Dudek:

>Hello,

Hello Julita,

>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
sensors.

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.


Input range

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
  imagery, (see https://github.com/NikosAlexandris/i.landsat.atcorr/blob/master/i.landsat.atcorr.py#L419)
  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].


Output range

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
behaviour (see
https://github.com/NikosAlexandris/i.landsat.atcorr/blob/master/i.landsat.atcorr.py#L435).


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
something like:

--%<---
svn diff main.cpp

Index: 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 image");

     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?

Nikos


>Thank you very much for your help.
>
>Best regards
>-- 
>Julita Dudek
>UMR 5600 Environnement Ville Société, CNRS
>Centre de recherche en géographie et aménagement, LCRE, Université Lyon 3
>0649 07 25 75