[GRASS-user] low radiance values after i.atcor and i.topo.corr

GRASS GRASS user
1

Hi,

After implementing gain and bias correction and topographic
correction, I get very low values for landsat data data
for example range of values of band1:

GRASS 6.3.1svn (p112r056):~ > r.info lsat7_2000.toar.1 -r
min=0.030303
max=0.372067
[Raster MASK present]
GRASS 6.3.1svn (p112r056):~ > r.info tcor.lsat7_2000.toar.1 -r
min=0.039443
max=0.442334

Running these range of values to an i.cluster reports very low separability:

means and standard deviations for 3 bands

means 0.00 0.00 0.00
stddev 0.06 0.00 0.00

initial means for each band

class 1 -0.05 0.00 0.00
class 2 -0.05 0.00 0.00
class 3 -0.05 0.00 0.00
class 4 -0.05 0.00 0.00
class 5 -0.04 0.00 0.00
class 6 -0.04 0.00 0.00
class 7 -0.04 0.00 0.00
class 8 -0.04 0.00 0.00
class 9 -0.03 0.00 0.00
class 10 -0.03 0.00 0.00
class 11 -0.03 0.00 0.00

... "More output here but mostly 0 value for means and stdev"

######## iteration 1 ###########
2 classes, 100.00% points stable
class distribution
       2161 7

########## final results #############
1 classes (convergence=100.0%)

class separability matrix

         1

  1 0

class means/stddev for each band

class 1 (2161)
  means 0.00 0.00 0.00
  stddev 0.00 0.00 0.00

#################### CLASSES ####################

1 classes, 100.00% points stable

######## CLUSTER END (Mon Jun 16 15:12:59 2008) ########

I assume this is due to the very low range of values (0.0xxx) of the
input images. Running r.rescale.eq to "stretch" the range of values
doesn't also help.
Any ideas on converting the radiance values to a range acceptable to
i.cluster and i.maxlik?

cheers,
maning

PS. Running i.landsat.rgb gives very good result to the output image
(less topographic effects) but this just changes the color rules and
not the actual values.

--
|---------|----------------------------------------------------------|
| __.-._ |"Ohhh. Great warrior. Wars not make one great." -Yoda |
| '-._"7' |"Freedom is still the most radical idea of all" -N.Branden|
| /'.-c |Linux registered user #402901, http://counter.li.org/ |
| | /T |http://esambale.wikispaces.com|
| _)_/LI
|---------|----------------------------------------------------------|

2

On Mon, Jun 16, 2008 at 11:59 AM, maning sambale
<emmanuel.sambale@gmail.com> wrote:

After implementing gain and bias correction and topographic
correction, I get very low values for landsat data data
for example range of values of band1:

GRASS 6.3.1svn (p112r056):~ > r.info lsat7_2000.toar.1 -r
min=0.030303
max=0.372067

...

Running these range of values to an i.cluster reports very low separability:

As far as I see it is related to the fact that i.cluster reads in as
integer (CELL)
through G_get_c_raster_row():
http://download.osgeo.org/grass/grass6_progman/gis_2get__row_8c.html
...

I assume this is due to the very low range of values (0.0xxx) of the
input images. Running r.rescale.eq to "stretch" the range of values
doesn't also help.

You may try to multiply the values with 100 or 1000 using r.mapcalc.

Please let us know how it works.

Markus

3

Thanks! Multiplying by 1000 with r.mapcalc gives better results. Any
chance adding floating points (FCELL) to i.cluster?

On 6/16/08, Markus Neteler <neteler@osgeo.org> wrote:

On Mon, Jun 16, 2008 at 11:59 AM, maning sambale
<emmanuel.sambale@gmail.com> wrote:

After implementing gain and bias correction and topographic
correction, I get very low values for landsat data data
for example range of values of band1:

GRASS 6.3.1svn (p112r056):~ > r.info lsat7_2000.toar.1 -r
min=0.030303
max=0.372067

...

Running these range of values to an i.cluster reports very low
separability:

As far as I see it is related to the fact that i.cluster reads in as
integer (CELL)
through G_get_c_raster_row():
http://download.osgeo.org/grass/grass6_progman/gis_2get__row_8c.html
...

I assume this is due to the very low range of values (0.0xxx) of the
input images. Running r.rescale.eq to "stretch" the range of values
doesn't also help.

You may try to multiply the values with 100 or 1000 using r.mapcalc.

Please let us know how it works.

Markus

--
|---------|----------------------------------------------------------|
| __.-._ |"Ohhh. Great warrior. Wars not make one great." -Yoda |
| '-._"7' |"Freedom is still the most radical idea of all" -N.Branden|
| /'.-c |Linux registered user #402901, http://counter.li.org/ |
| | /T |http://esambale.wikispaces.com|
| _)_/LI
|---------|----------------------------------------------------------|

4

maning sambale wrote:

>> After implementing gain and bias correction and topographic
>> correction, I get very low values for landsat data data
>> for example range of values of band1:
>>
>> GRASS 6.3.1svn (p112r056):~ > r.info lsat7_2000.toar.1 -r
>> min=0.030303
>> max=0.372067
> ...
>> Running these range of values to an i.cluster reports very low
>> separability:
>
> As far as I see it is related to the fact that i.cluster reads in as
> integer (CELL)
> through G_get_c_raster_row():
> http://download.osgeo.org/grass/grass6_progman/gis_2get__row_8c.html
> ...
>> I assume this is due to the very low range of values (0.0xxx) of the
>> input images. Running r.rescale.eq to "stretch" the range of values
>> doesn't also help.
>
> You may try to multiply the values with 100 or 1000 using r.mapcalc.
>
> Please let us know how it works.

Thanks! Multiplying by 1000 with r.mapcalc gives better results. Any
chance adding floating points (FCELL) to i.cluster?

I had a brief look at the code[1], and cannot see any obvious reason
why the values would need to be integers, so I'm assuming that it's
just a legacy of the days before FP support was added.

[1] Most of the code is actually in the lib/imagery/c_*.c files. That
should either be made part of i.cluster (nothing else uses it), or at
least split into a separate library.

--
Glynn Clements <glynn@gclements.plus.com>

5

On 6/18/08, Glynn Clements <glynn@gclements.plus.com> wrote:

maning sambale wrote:

>> After implementing gain and bias correction and topographic
>> correction, I get very low values for landsat data data
>> for example range of values of band1:
>>
>> GRASS 6.3.1svn (p112r056):~ > r.info lsat7_2000.toar.1 -r
>> min=0.030303
>> max=0.372067
> ...
>> Running these range of values to an i.cluster reports very low
>> separability:
>
> As far as I see it is related to the fact that i.cluster reads in as
> integer (CELL)
> through G_get_c_raster_row():
> http://download.osgeo.org/grass/grass6_progman/gis_2get__row_8c.html
> ...
>> I assume this is due to the very low range of values (0.0xxx) of the
>> input images. Running r.rescale.eq to "stretch" the range of values
>> doesn't also help.
>
> You may try to multiply the values with 100 or 1000 using r.mapcalc.
>
> Please let us know how it works.

Thanks! Multiplying by 1000 with r.mapcalc gives better results. Any
chance adding floating points (FCELL) to i.cluster?

I had a brief look at the code[1], and cannot see any obvious reason
why the values would need to be integers, so I'm assuming that it's
just a legacy of the days before FP support was added.

[1] Most of the code is actually in the lib/imagery/c_*.c files. That
should either be made part of i.cluster (nothing else uses it), or at
least split into a separate library.

Excellent! I hope it gets fixed. I am glad reporting such problems
(though at times trivial) helps improve the GRASS code.

cheers,

maning

--
Glynn Clements <glynn@gclements.plus.com>

--
|---------|----------------------------------------------------------|
| __.-._ |"Ohhh. Great warrior. Wars not make one great." -Yoda |
| '-._"7' |"Freedom is still the most radical idea of all" -N.Branden|
| /'.-c |Linux registered user #402901, http://counter.li.org/ |
| | /T |http://esambale.wikispaces.com|
| _)_/LI
|---------|----------------------------------------------------------|