[GRASS-user] GRASS 6.4.3 - Technical questions on Landsat TM/ETM+/OLI and other

[Nikos Alexandris]

Nuno Sá wrote:

> Hey!

Hi!  Just a quick-feed-back, hoping it'll help a bit and not add more noise 
:-)

> This is my first post, unfortunate it's not to help somebody but to ask for
> some help.. I do have to say, GRASS seems to be great so far and I feel my
> problems are probably user related.

> I am pre-processing Landsat data (at the moment only TM and ETM) to use for
> a classification later, doesn't matter.
> 
> Since all the data I'm acquiring comes as L1T  (204/032), then the
> pre-processing workflow was done as follows:
> 
> DN -> TOA reflectance(&temperature) -> Cloud detection and masking (if
> necessary) -> Topographic correction using ASTERM 30m DEM.

Topo correction: which method? Did you try Minaert (I was advised from Experts 
in the past to check it out for Landsat).

> All data projection is as delivered by USGS (I don't remember if I
> reprojected the DEM but most probably I did).
> 
> Imagery dates - 204/32:
> 
> TM4 - 1989001 (January 1, 1989)
> TM5 - 2007027 (January 27,2007)
> ETM+ - 2003023 (January 23,2003)
> 
> 
> All until here seems fine I guess, but I am having the following issues:
> 
> 
>    - Band seems saturated or affected by some "multiplier". Such as TM4
>    composites look "normal" or as expected but TM5 and ETM+ seem pinkish or
>    saturated as if one of the bands is saturated.

For all (the above included) try "i.landsat.rgb r=B3 g=B2 b=B1" before 
rendering (obviously, this is for a true-color like RGB) or any other 
combination that serves your task.

>    - Since TM4 looks the most "normal", all the others seem affected by
>    some kind of noise (white noise?). Should I apply a Low pass filter of
> some kind?

I would first check that it isn't simply a color-ing issue (since you 
"equalise" all bands greyscale). If indeed the images are too noisy (what do 
the related metadata say about Cloud percentage?), you may want to try i.pca 
(in GRASS7) which can perform first a forward PCA, filter Components 
(essentialy keep only Components whose sum of eigenvalues are >= than a user-
defined threshold), then backward PCA and check if it did any good in removing 
some noise.

So... another idea: the topo-corr method. Maybe this causes the evil?

>    - Both i.landsat.rgb (runs endlessly)...

A-ha, here you have it! Strange... So we need to find out why? Too large 
region? Region extents? Resolution?  Output of "g.region -p".

>... and i.landsat.dehaze (says it
>    can't find the GUI, I've re-installed it without success)
> 
> 
> If you need added information, please ask and I'll send you the commands.
> Here are the ones who generated the attached image:
> 
> 
> -------------------
> 
> Calling the file
> r.in.gdal
> input=C:\Invader_B\GRASS_Workfolder_01\01_LT5\LT52040322007027MPS00\LT520403
> 22007027MPS00_B1.TIF output=RAW_2007027_LT5_B.1
> 
> (...)
> 
> (i used DOS2 in this latest attempt since both uncorrected and DOS1 yield
> similar problems)
> i.landsat.toar sensor=tm5 method=dos2 --overwrite --verbose
> input_prefix=RAW_2007027_LT5_B. output_prefix=2007027_LT5_B.
> metfile=C:\Invader_B\GRASS_Workfolder_01\01_LT5\LT52040322007027MPS00\LT5204
> 0322007027MPS00_MTL.txt
> 
> 
> i.landsat.acca --overwrite --verbose -5 input_prefix=2007027_LT5_B.
> output=2007027_CloudMask
> (The mask is not used by me since i visually see there are no clouds [there
> is snow in Serra da Estrela, famous place here])
> 
> Getting the illumination raster
> i.topo.corr -i --overwrite base=ASTER_30m zenith=63.09559142
> azimuth=153.85758094 out=ASTER.illu.prj
> 
> i.topo.corr base=ASTER.illu.prj zenith=63.09559142 method=c-factor
> --verbose --overwrite
> input=2007027_LT5_B.1,2007027_LT5_B.2,2007027_LT5_B.3,2007027_LT5_B.4,200702
> 7_LT5_B.5,2007027_LT5_B.6,2007027_LT5_B.7 out=npca_topo_CM
> 
> r.colors -e map=npca_topo_CM.2007027_LT5_B.1 at 01_LT5 color=grey
> (...)
> 
> d.rgb to display the image in attachment.

Best Nikos