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
I did i.histo.match on two test images and it looks fine. So now the rest of bands, and then band composite and supervised classification (I’ve found nice tutorial on youtube, so I’m gonna follow it, or I will try semi-automatic classification plugin for qgis).
but only one shade, one color-no scale of colors. Forunately, Moritz was right, thanks a lot! Now it looks normal.