Nikos: > > > If you go all the way from DN to Top-of-Atmosphere reflectances (via > > > i.landsat.toar), then to Top-of-Canopy (via i.atcorr), you'll have > > > floating point values ranging in [0, 1.0]. If you recode this back to > > > 8-bit, you should consider whether there is an important loss of the > > > radiometric resolution. > > > So, recoding to another range is different than converting to integer > > > numbers and trying to preserve the range.
joanna: > > The thing that worries me is that I don't know how to check if the loss > > of the radiometric resolution is important :/ What should I compare? Moritz: > I'm not sure that for Landsat 5 the loss is so important, but you can > visually compare an image recoded to 0-255 with the one coming out of > i.landsat.toar... Nor am I sure about it. Landsat5 is 8-bit. But one should definitively consider it, and mention the decisions taken while documenting the process. [some text removed] joanna: > > According to*i.atcorr* there is an option "output raster map as integer" > > (i), so if my input file will be _toar2@konfa (float) and I check that > > option I will have a map with integer values, right? Moritz: > Yes. joanna: > > However, the most confusing thing for me with i.atcorr is /"the aerosol > > optical depth"/. I don't have "meteorological parameter visibility". I > > have images from 1984 and 2007. I've found files for Global Aerosol > > Climatology (1981-2006) on this > > website http://gacp.giss.nasa.gov/data_sets/ I've found the proper row > > and column in the asci format, but they don't have data for 2007. I was > > trying to find it on different > > pages http://modis-atmos.gsfc.nasa.gov/MOD04_L2/acquiring.html but areas > > of my interest are black - so no data. On your page github with > > i.landsat.toar and i.atcorr you wrote"/the value for aerosols optical > > depth (AOD), is set to 0.111 for winter and 0.222 for summer > > aquisitions" /Are these default values? For DOS methods? Moritz: > Yes, these are default values which might not be applicable to your case. There is a paper, also, suggested by Moritz quite some time ago: <http://www.opticsinfobase.org/ao/abstract.cfm?uri=ao-34-15-2765>. In it, there is "Table 4. Rayleigh Optical Depths at 0-km Altitude for Six Different Atmosphere Models". Perhaps useful. > AFAIU, you could use the vibility in km instead of the aerosol optical > depth. i.atcorr will then calculate optical depth based on a standard > model. To get visibility find a meteorological station close to your > image and get the info for the relevant date from that station. Yes, that should do as well. > A site I find convenient for that is http://www.ogimet.com/. Thanks for the tip :-) > > Can I use*i.landsat.toar with DOS3 * instead of i.atcorr? The others > > where using > > this > > http://gis.stackexchange.com/questions/126742/which-dos-method-use-to-convert-at-sensor-radiance-to-at-surface-values-in-grass > > And also on your graph (the one on github) Nikos, this DOS method leads > > to "corrected" reflectance. So it means that I can omit i.atccor, right? > i.atcorr provides a much more sophisticated algorithm for atmospheric > corrections. This does not necessarily mean that is "more correct", but > at least that it tries to take into account more information. DOS is a > very simple algorithm of correction with the advantage that you don't > need much info to run it, but it is generally even more of an > approximation than i.atcorr. > > I'm thinking about preprocessing of my images like this:*i.landsat.toar > > + DOS3*, then*r.recode* (I don't know the other way to change float to > > integer), then*i.histo.match* And after that classification joanna, once again, the easy "other way" is posted in my first reply, I think. You just need to multiply with 1000, perform the histogram matching, then divide by 1000.0 to get back to floats. > I'm not sure that histogram matching is really necessary, or even > advisable, before classification, but why not try the path you propose > and then check the validity of the results. If they are not good enough > for your purpose then you can try to improve by using more sophisticated > correction. As we all know, if one tries to compare scenes over the same area, aqcuired at different times, it's necessary to relatively normalise'em (different dates, different solar geometries, variations in the spectral response of the same surfaces). The same, I think, is valid if one combines multiple scenes acquired at the same date but cover adjacent areas. A relative normalisation can help, in such cases, a lot to make classification results comparable. For the latter, perhaps it is not necessary in flat areas!? Of course, if the approach is going to be one, independent, classification per scene, and then try to compare the outcomes, things are very different. It might work well without undergoing relative normalisation actions. Histogram matching could be used as a mean for relative atmospheric correction. Also, there is an effort to do something more sophisticated in this direction by Tomas Brunclik: <http://www.researchgate.net/publication/275020325_i.grid.correl.atcor_version_0.91b>. I haven't checked what's the latest status of it, nor had I any contact with the author recently (we did discuss something in the past). I am very interested in his work as I have performed similar computations in the past using messy scripts in GRASS combined with some linear regressions in R. Maybe his tool is more mature now? Nikos _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
