[GRASS-dev] Landsat 5TM pre-processing - histogram matching - problem

[Moritz Lennert]

On 05/05/15 17:18, joanna mardas wrote:
> Hello! It's me again :)
>
>  > 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.
>
> 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?

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


> I was trying to convert to integer through *r.mapcalc* (the only other
> way I've found) with the function *int(x)* and x was my map (I hope it
> was ok to put map instead of x) but the result was a map with "one
> shade" of grey, so maybe it was wrong to put a map instead of x...

int() rounds, so if you maps varies between 0 and 1, rounding will make 
you lose almost all information. You have to multiply your values by a 
multiple of ten corresponding to the degree of precision you want before 
converting it to int. I.e. for a value of 0.12345678, if you want to 
keep the first five numbers after the decimal point, you have to do 
something like this:

newMap = int(oldMap * 100000)

>
> According to*i.atcorr* there is an option "output raster map as integer"
> (i), so if my input file will be _toar2 at konfa (float) and I check that
> option I will have a map with integer values, right?

Yes.

>
> 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?

Yes, these are default values which might not be applicable to your case.

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.

A site I find convenient for that is http://www.ogimet.com/.

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

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.

Moritz