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