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

Nuno_Sa · December 17, 2013, 5:56pm

Hey!

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.

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.
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?
Both i.landsat.rgb (runs endlessly) 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\LT52040322007027MPS00_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\LT52040322007027MPS00_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,2007027_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@01_LT5 color=grey

(…)

d.rgb to display the image in attachment.

–

Nuno César de Sá
+351 91 961 90 37

(attachments)

Example_lansat_dehaze error.jpg

NikosAlexandris · December 19, 2013, 1:23am

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@01_LT5 color=grey
(...)

d.rgb to display the image in attachment.

Best Nikos

NikosAlexandris · December 19, 2013, 1:27am

Nikos:

..

i.pca (in GRASS7) which can perform first a forward PCA, filter Components
(essentialy keep only Components whose sum of eigenvalues are >=...

..

It's too late here... so correction: the above would be the importance
percentage. And, obviously, if you check the i.pca manual (G7 only), the
parameter is called "percent". What a surprise

Nikos

Nuno_Sa · December 19, 2013, 11:26am

Hey, thank you so much :)!

I gave up on using the i.pca since it was giving reeaally unexpected results but I think i was doing it wrong.

Regarding cloud cover on this LS TM 5 image (lets use it as “benchmark”) i:

CLOUD_COVER = 0.00
IMAGE_QUALITY = 9

Can’t really evaluate the output of with the minnaert, it gave obviously a bit different colouring after streching but the overall thing is similiar, besides:

Band 2007027_LT5_B.1:
Minnaert constant = 0.000000
Color table for raster map <npca_topo_minna_CM.2007027_LT5_B.1> set to ‘grey’

So, am I doing something wrong here? maybe I should input a slop layer somehow or verify if the output of illumination is COS(i) or i?

i.landsat.rgb and i.landsat.dehaze keep failing… I also tried to plot feature spaces using d.correlate as an experiment and it says its not implemented in the GUI, for me to use the command line. Is that the the command box that comes with a GUI or is it something somewhere else?

I’ll try the i.pca correction now. With a 3x3 avg filter it “looks nice’er” but not nice enough, the image really looks very saturated with expected greens being yellowish :\

···

On 19 December 2013 01:27, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Nikos:

…

i.pca (in GRASS7) which can perform first a forward PCA, filter Components

(essentialy keep only Components whose sum of eigenvalues are >=…
…

It’s too late here… so correction: the above would be the importance
percentage. And, obviously, if you check the i.pca manual (G7 only), the
parameter is called “percent”. What a surprise

Nikos

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

–

Nuno César de Sá
+351 91 961 90 37