[GRASS-user] i.landsat.toar comments have only 0 value

Hi all,

I just ran i.landsat.toar to get the radiance values for a TM5 image and I noticed that the comments in the output metadata (from r.info) have some problem.

  1. I asked for radiance output but the comments says the image is reflectance. Image values are consistent with radiance values so I believe the line in the comments is wrong.

  2. Values for earth-sun distance, digital number range etc are all 0.

I’m using OSGeo4W, Grass7svn revision 54962

Bellow is the output from r.info so you can see what I mean

±---------------------------------------------------------------------------+
| Layer: rad2005_cor.1 Date: Fri Feb 15 08:38:31 2013 |
| Mapset: PERMANENT Login of Creator: daniel |
| Location: corr_Atm_utm23s |
| DataBase: C:\grassdata |
| Title: ( rad2005_cor.1 ) |

Timestamp: none
Type of Map: raster Number of Categories: 0
Data Type: DCELL
Rows: 7001
Columns: 7951
Total Cells: 55664951
Projection: UTM (zone -23)
N: 7548415.00000001 S: 7338385 Res: 30
E: 623415 W: 384884.99999999 Res: 30
Range of data: min = 0 max = 194.52
Data Description:
generated by i.landsat.toar
Comments:
Reflectance of Landsat-5 TM (method corrected)
----------------------------------------------------------------
Acquisition date … 2005-05-15
Production date … 2012-12-01
Earth-sun distance (d) … -0.00000000
Digital number (DN) range … 0 to 0
Calibration constants (Lmin to Lmax) … +0.000 to +0.000
DN to Radiance (gain and bias) … -0.00000 and +0.00000
Mean solar irradiance (ESUN) … -0.000
Reflectance = Radiance divided by … -0.00000
-----------------------------------------------------------------
i.landsat.toar -r input_prefix=“tm5_2005_orig.” output_prefix="rad20\
05_cor." metfile="C:\projetos\agspec\correcao_landsat\LT521807620051\
35CUB00\LT52180762005135CUB00_MTL.txt" sensor=“tm5” method="correcte\
d" date=“2005-05-15” sun_elevation=37.184 product_date=“2012-12-01” \
percent=0.01 pixel=1000 rayleigh=0.0
±---------------------------------------------------------------------------+

Thanks
Daniel

On Friday 15 of February 2013 08:58:48 Daniel Victoria wrote:

Hi all,

Hi Daniel!

I just ran i.landsat.toar to get the radiance values for a TM5 image and I
noticed that the comments in the output metadata (from r.info) have some
problem.

Which metadata file did you use? *MTL.txt or *MTLold.txt?

1) I asked for radiance output but the comments says the image is
reflectance. Image values are consistent with radiance values so I believe
the line in the comments is wrong.

True, I confirm this when using *MTL.txt (the new version/structure for Landsat
metadata files) -- didn't check with the old yet about this issue.

(cc-ing YannC as there are a few other minor glitches.)

2) Values for earth-sun distance, digital number range etc are all 0.

Again, using the old *MTLold.txt file, this looks fine (e.g. tested with the
scene LE71840312002041SGS00.

[rest deleted]

Nikos

Daniel,

if you have the old MTL files beforehand, it might be better right now. Along
with another few changes, I've sent a diff to Yann C who will submit them
probably tonight.

Best, N

I upgraded to Grass 7svn rev 55062. That’s the latest version available in OSGeo4W

  1. Using i.landsat.toar with the NEW MTL and verbose command output:

Output in the “Command output” window shows the expected values for calibration constants, DN etc for each band

r.info on the output images DO NOT SHOW calibration parameters and states that the image is Reflectance of landsat-5 TM, even thou I asked for radiance (-r flag)

  1. Using i.landsat.toar with the OLD MTL and verbose command output:

Same as using the new MTL, that is, parameters show up in the command window but do not appear in r.info output

Bellow ir r.info output of image generated using old MTL.

···

On Fri, Feb 15, 2013 at 11:14 AM, Nikos Alexandris <nik@nikosalexandris.net> wrote:

Daniel,

if you have the old MTL files beforehand, it might be better right now. Along
with another few changes, I’ve sent a diff to Yann C who will submit them
probably tonight.

Best, N


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

Dear All,

I have been running i.landsat.toar but have just noted this problem. For me
it shows zeros both in the command output (verbose) and output metadata
(r.info). An example for one of the bands:

From command output:

LANDSAT: 5 SENSOR: TM
ACQUISITION DATE 2011-07-05 [production date 2011-11-29]
   Earth-sun distance = 0.00000000
   Solar elevation angle = 0.00000000
   Atmospheric correction = dos4
   Percent of solar irradiance in path radiance = 0.0000
-------------------
BAND 1 (code 1)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.000 to 0.000
   at-surface radiance = 0.00000000 * DN + -0.000
   mean solar exoatmospheric irradiance (ESUN): -0.000
   at-surface reflectance = radiance / 0.00000
   the darkness DN with a least 1000 pixels is 1
   the DN mode is 53
-------------------

From r.info for the same band:

| Earth-sun distance (d) ................ -0.00000000
|
| Digital number (DN) range ............. 0 to 0
|
| Calibration constants (Lmin to Lmax) .. +0.000 to +0.000
|
| DN to Radiance (gain and bias) ........ +0.00000 and +0.00000
|
| Mean solar irradiance (ESUN) .......... 0.000
|
| Reflectance = Radiance divided by ..... 0.00000
|
|
|
| Dark object (1000 pixels) DN = ........ 1
|
| Mode in reflectance histogram ......... 0.00000

Running i.landsat.toar -p results to

number=5
creation=2011-11-29
date=2011-07-05
sun_elev=45.585310
sensor=TM
bands=7
sunaz=44.259879

Which I think confirms that i.landsat.toar can read input values from my
metafile. The output bands have values in the range of surface
reflectance/temperature (for band 6). For example

Band 1 output - Range of data: min = 0.01 max = 0.461925184292249, Data
Units: unitless
Band 2 output - Range of data: min = 0.01 max = 0.925906812458597, Data
Units: unitless
Band 3 output - Range of data: min = 0.01 max = 0.785829845850446, Data
Units: unitless
.
.
Band 6 output - Range of data: min = 203.371307953013 max =
327.669907753679, Data Units: Kelvin

I have same results when using MTL or MTLOld as source of metadata, on TM or
ETM+ sensors and different atmospheric correction methods (uncorrected,
DOS). I am running winGRASS7 revision 57466.

Is there a problem with the printed output from r.info/command output or are
these zeros the actual values that i.landsat.toar uses as input to
computations?

Thanks,
Beatrice.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/i-landsat-toar-comments-have-only-0-value-tp5034509p5075199.html
Sent from the Grass - Users mailing list archive at Nabble.com.

On Friday 30 of August 2013 02:56:14 Beatrice wrote:

Dear All,

Good Day Beatrice,

I have been running i.landsat.toar but have just noted this problem. For me
it shows zeros both in the command output (verbose) and output metadata
(r.info). An example for one of the bands:

From command output:

LANDSAT: 5 SENSOR: TM
ACQUISITION DATE 2011-07-05 [production date 2011-11-29]
   Earth-sun distance = 0.00000000
   Solar elevation angle = 0.00000000
   Atmospheric correction = dos4
   Percent of solar irradiance in path radiance = 0.0000
-------------------
BAND 1 (code 1)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.000 to 0.000
   at-surface radiance = 0.00000000 * DN + -0.000
   mean solar exoatmospheric irradiance (ESUN): -0.000
   at-surface reflectance = radiance / 0.00000
   the darkness DN with a least 1000 pixels is 1
   the DN mode is 53
-------------------

From r.info for the same band:
| Earth-sun distance (d) ................ -0.00000000
|
| Digital number (DN) range ............. 0 to 0
|
| Calibration constants (Lmin to Lmax) .. +0.000 to +0.000
|
| DN to Radiance (gain and bias) ........ +0.00000 and +0.00000
|
| Mean solar irradiance (ESUN) .......... 0.000
|
| Reflectance = Radiance divided by ..... 0.00000
|
|
|
| Dark object (1000 pixels) DN = ........ 1
|
| Mode in reflectance histogram ......... 0.00000

This doesn't look healthy. However, I think it is a past problem which is
fixed.

Running i.landsat.toar -p results to

number=5
creation=2011-11-29
date=2011-07-05
sun_elev=45.585310
sensor=TM
bands=7
sunaz=44.259879

Which I think confirms that i.landsat.toar can read input values from my
metafile. The output bands have values in the range of surface
reflectance/temperature (for band 6). For example

Band 1 output - Range of data: min = 0.01 max = 0.461925184292249, Data
Units: unitless
Band 2 output - Range of data: min = 0.01 max = 0.925906812458597, Data
Units: unitless
Band 3 output - Range of data: min = 0.01 max = 0.785829845850446, Data
Units: unitless
.
.
Band 6 output - Range of data: min = 203.371307953013 max =
327.669907753679, Data Units: Kelvin

I have same results when using MTL or MTLOld as source of metadata, on TM or
ETM+ sensors and different atmospheric correction methods (uncorrected,
DOS). I am running winGRASS7 revision 57466.

Is there a problem with the printed output from r.info/command output or are
these zeros the actual values that i.landsat.toar uses as input to
computations?

I doubt that r.info has a problem reading the metadata that pertain to a
queried raster map. If I am not wrong, it merely reads simple text files that
reside inside the "hist" directory inside the corresponding Mapset.

My guess is that you use an older version of i.landsat.toar whicj, indeed,
produces empty raster maps. Unfortunately, I do not use (nor have any access
to a Windows machine) so as to be in position to help directly. We need
feedback from someone with a Windows OS.

(
On/Off-Topic: is there a way to run and test GRASS in an emulated Windows
environment for those who don't have a legally licensed Windows OS?
)

Best, Nikos

On Wed, Sep 4, 2013 at 10:17 AM, Nikos Alexandris
<nik@nikosalexandris.net>wrote:

On Friday 30 of August 2013 02:56:14 Beatrice wrote:

> Dear All,

Good Day Beatrice,

> I have been running i.landsat.toar but have just noted this problem. For
me
> it shows zeros both in the command output (verbose) and output metadata
> (r.info). An example for one of the bands:

> From command output:
>
> LANDSAT: 5 SENSOR: TM
> ACQUISITION DATE 2011-07-05 [production date 2011-11-29]
> Earth-sun distance = 0.00000000
> Solar elevation angle = 0.00000000
> Atmospheric correction = dos4
> Percent of solar irradiance in path radiance = 0.0000
> -------------------
> BAND 1 (code 1)
> calibrated digital number (DN): 0.0 to 0.0
> calibration constants (L): 0.000 to 0.000
> at-surface radiance = 0.00000000 * DN + -0.000
> mean solar exoatmospheric irradiance (ESUN): -0.000
> at-surface reflectance = radiance / 0.00000
> the darkness DN with a least 1000 pixels is 1
> the DN mode is 53
> -------------------

> From r.info for the same band:
> | Earth-sun distance (d) ................ -0.00000000
> |
> | Digital number (DN) range ............. 0 to 0
> |
> | Calibration constants (Lmin to Lmax) .. +0.000 to +0.000
> |
> | DN to Radiance (gain and bias) ........ +0.00000 and +0.00000
> |
> | Mean solar irradiance (ESUN) .......... 0.000
> |
> | Reflectance = Radiance divided by ..... 0.00000
> |
> |
> |
> | Dark object (1000 pixels) DN = ........ 1
> |
> | Mode in reflectance histogram ......... 0.00000

This doesn't look healthy. However, I think it is a past problem which is
fixed.

> Running i.landsat.toar -p results to
>
> number=5
> creation=2011-11-29
> date=2011-07-05
> sun_elev=45.585310
> sensor=TM
> bands=7
> sunaz=44.259879
>
> Which I think confirms that i.landsat.toar can read input values from my
> metafile. The output bands have values in the range of surface
> reflectance/temperature (for band 6). For example
>
> Band 1 output - Range of data: min = 0.01 max = 0.461925184292249,
Data
> Units: unitless
> Band 2 output - Range of data: min = 0.01 max = 0.925906812458597,
Data
> Units: unitless
> Band 3 output - Range of data: min = 0.01 max = 0.785829845850446,
Data
> Units: unitless
> .
> .
> Band 6 output - Range of data: min = 203.371307953013 max =
> 327.669907753679, Data Units: Kelvin
>
> I have same results when using MTL or MTLOld as source of metadata, on
TM or
> ETM+ sensors and different atmospheric correction methods (uncorrected,
> DOS). I am running winGRASS7 revision 57466.
>
> Is there a problem with the printed output from r.info/command output
or are
> these zeros the actual values that i.landsat.toar uses as input to
> computations?

I doubt that r.info has a problem reading the metadata that pertain to a
queried raster map. If I am not wrong, it merely reads simple text files
that
reside inside the "hist" directory inside the corresponding Mapset.

My guess is that you use an older version of i.landsat.toar whicj, indeed,
produces empty raster maps. Unfortunately, I do not use (nor have any
access
to a Windows machine) so as to be in position to help directly. We need
feedback from someone with a Windows OS.

(
On/Off-Topic: is there a way to run and test GRASS in an emulated Windows
environment for those who don't have a legally licensed Windows OS?
)

​There are two options that I am aware of:

1) Create a virtual machine and install windows on it (meh..)

2) Use WINE, which as they state in their site they are "a compatibility
layer capable of running Windows applications on several POSIX-compliant
operating systems".

http://www.winehq.org

​Nikos.​

Best, Nikos
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Nikos A:

> (
> On/Off-Topic: is there a way to run and test GRASS in an emulated Windows
> environment for those who don't have a legally licensed Windows OS?
> )

Nikos V:

> ​There are two options that I am aware of:
1) Create a virtual machine and install windows on it (meh..)

Why not? Sounds good, as long as one has a legally licensed Windows
installation media... :-). I don't!

2) Use WINE, which as they state in their site they are "a compatibility
layer capable of running Windows applications on several POSIX-compliant
operating systems".

I have used Wine in the past (among others, very successful in working with
ArcGIS -- that was before 2007!). Is it really a good choice to test
WinGRASS?

Greets, Nikos

On Fri, Aug 30, 2013 at 11:56 AM, Beatrice <beatrice.tarimo@umb.no> wrote:

Dear All,

I have been running i.landsat.toar but have just noted this problem. For me
it shows zeros both in the command output (verbose) and output metadata
(r.info).

...

Please try the updated version in GRASS 6.4.svn (thanks to E. Jorge Tizado).
The GRASS 7 update is hopefully forthcoming, too.

Markus

I just noticed the same. Does this mean that i.landsat.toar did not read the values from the MTL file and, as a consequence, reflectances are wrong or is just a verbose display issue?

···

2013/10/2 Markus Neteler <neteler@osgeo.org>

On Fri, Aug 30, 2013 at 11:56 AM, Beatrice <beatrice.tarimo@umb.no> wrote:

Dear All,

I have been running i.landsat.toar but have just noted this problem. For me
it shows zeros both in the command output (verbose) and output metadata
(r.info).

Please try the updated version in GRASS 6.4.svn (thanks to E. Jorge Tizado).
The GRASS 7 update is hopefully forthcoming, too.

Markus


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


Saludos,

Yasser

On Sat, Oct 5, 2013 at 5:20 AM, Yasser Said Lopez de Olmos Reyes
<biolyasser@gmail.com> wrote:

I just noticed the same. Does this mean that i.landsat.toar did not read the
values from the MTL file and, as a consequence, reflectances are wrong or is
just a verbose display issue?

Do you use the bugfixed version in from current SVN? Please post the output of
g.version

Markus

I used osgeo4w stable version and 6.5.x svn yesterday’s version. Both had 0s in verbose output. Sorry, I’m not in my desktop right now.

···

2013/10/5 Markus Neteler <neteler.osgeo@gmail.com>

On Sat, Oct 5, 2013 at 5:20 AM, Yasser Said Lopez de Olmos Reyes
<biolyasser@gmail.com> wrote:

I just noticed the same. Does this mean that i.landsat.toar did not read the
values from the MTL file and, as a consequence, reflectances are wrong or is
just a verbose display issue?

Do you use the bugfixed version in from current SVN? Please post the output of
g.version

Markus


Saludos,

Yasser

Hi all,

I'm also noticing the same problem that Beatrice and Yasser mentioned.
I'm using WinGrass7_svn rev 58021 (installed using OSGeo4W).

If I run i.landsat.toar and ask it to print the metadata (-p flag), it
gives me the correct information from the MTL file
---
(Thu Oct 17 17:26:35 2013)
i.landsat.toar -p --overwrite --verbose input_prefix=tm5_2005_orig.
output_prefix=reflec_topo_2005.
metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
number=5
creation=2012-12-01
date=2005-05-15
sun_elev=37.184012
sensor=TM
bands=7
sunaz=39.877237
Metada file is MTL file: new format
---

But when I actually run i.landsat.toar (no -p flag), I get a bunch off zeros:
---
i.landsat.toar --overwrite --verbose input_prefix=tm5_2005_orig.
output_prefix=reflec_topo_2005.
metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
Metada file is MTL file: new format
RADIANCE & QUANTIZE from data of the metadata file
LANDSAT: 5 SENSOR: TM
ACQUISITION DATE 2005-05-15 [production date 2012-12-01]
   Earth-sun distance = 0.00000000
   Solar elevation angle = 0.00000000
   Atmospheric correction: UNCORRECTED
-------------------
BAND 1 (code 1)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.00000 to 0.00000
   at-sensor radiance = -0.00000000 * DN + -0.00000
   mean solar exoatmospheric irradiance (ESUN): -0.00000
   at-sensor reflectance = radiance / -0.00000
-------------------
BAND 2 (code 2)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.00000 to 0.00000
   at-sensor radiance = 0.00000000 * DN + -0.00000
   mean solar exoatmospheric irradiance (ESUN): 0.00000
   at-sensor reflectance = radiance / 0.00000
-- clip --

I seem to recall the command was working fine on Linux but I'm not sure...

Cheers
Daniel

On Sat, Oct 5, 2013 at 11:27 PM, Yasser Said Lopez de Olmos Reyes
<biolyasser@gmail.com> wrote:

I used osgeo4w stable version and 6.5.x svn yesterday's version. Both had 0s
in verbose output. Sorry, I'm not in my desktop right now.

2013/10/5 Markus Neteler <neteler.osgeo@gmail.com>

On Sat, Oct 5, 2013 at 5:20 AM, Yasser Said Lopez de Olmos Reyes
<biolyasser@gmail.com> wrote:
> I just noticed the same. Does this mean that i.landsat.toar did not read
> the
> values from the MTL file and, as a consequence, reflectances are wrong
> or is
> just a verbose display issue?

Do you use the bugfixed version in from current SVN? Please post the
output of
g.version

Markus

--
Saludos,

Yasser

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

Updating my last email. I also see the same problem in WinGrass 6.4.3

And on a similar topic, i.landsat.toar in Grass6 has one extra
correction method when compared with Grass7.
In grass6 there is a Corrected at-sensor values options which I don't
see in Grass7. Why is that?

Cheers
Daniel

On Thu, Oct 17, 2013 at 5:45 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:

Hi all,

I'm also noticing the same problem that Beatrice and Yasser mentioned.
I'm using WinGrass7_svn rev 58021 (installed using OSGeo4W).

If I run i.landsat.toar and ask it to print the metadata (-p flag), it
gives me the correct information from the MTL file
---
(Thu Oct 17 17:26:35 2013)
i.landsat.toar -p --overwrite --verbose input_prefix=tm5_2005_orig.
output_prefix=reflec_topo_2005.
metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
number=5
creation=2012-12-01
date=2005-05-15
sun_elev=37.184012
sensor=TM
bands=7
sunaz=39.877237
Metada file is MTL file: new format
---

But when I actually run i.landsat.toar (no -p flag), I get a bunch off zeros:
---
i.landsat.toar --overwrite --verbose input_prefix=tm5_2005_orig.
output_prefix=reflec_topo_2005.
metfile=C:\projetos\agspec\correcao_landsat\LT52180762005135CUB00\LT52180762005135CUB00_MTL.txt
lsatmet=number,creation,date,sun_elev,sensor,bands,sunaz,time
Metada file is MTL file: new format
RADIANCE & QUANTIZE from data of the metadata file
LANDSAT: 5 SENSOR: TM
ACQUISITION DATE 2005-05-15 [production date 2012-12-01]
   Earth-sun distance = 0.00000000
   Solar elevation angle = 0.00000000
   Atmospheric correction: UNCORRECTED
-------------------
BAND 1 (code 1)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.00000 to 0.00000
   at-sensor radiance = -0.00000000 * DN + -0.00000
   mean solar exoatmospheric irradiance (ESUN): -0.00000
   at-sensor reflectance = radiance / -0.00000
-------------------
BAND 2 (code 2)
   calibrated digital number (DN): 0.0 to 0.0
   calibration constants (L): 0.00000 to 0.00000
   at-sensor radiance = 0.00000000 * DN + -0.00000
   mean solar exoatmospheric irradiance (ESUN): 0.00000
   at-sensor reflectance = radiance / 0.00000
-- clip --

I seem to recall the command was working fine on Linux but I'm not sure...

Cheers
Daniel

On Sat, Oct 5, 2013 at 11:27 PM, Yasser Said Lopez de Olmos Reyes
<biolyasser@gmail.com> wrote:

I used osgeo4w stable version and 6.5.x svn yesterday's version. Both had 0s
in verbose output. Sorry, I'm not in my desktop right now.

2013/10/5 Markus Neteler <neteler.osgeo@gmail.com>

On Sat, Oct 5, 2013 at 5:20 AM, Yasser Said Lopez de Olmos Reyes
<biolyasser@gmail.com> wrote:
> I just noticed the same. Does this mean that i.landsat.toar did not read
> the
> values from the MTL file and, as a consequence, reflectances are wrong
> or is
> just a verbose display issue?

Do you use the bugfixed version in from current SVN? Please post the
output of
g.version

Markus

--
Saludos,

Yasser

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

Daniel Victoria wrote:

Updating my last email. I also see the same problem in WinGrass 6.4.3

And on a similar topic, i.landsat.toar in Grass6 has one extra
correction method when compared with Grass7.
In grass6 there is a Corrected at-sensor values options which I don't
see in Grass7. Why is that?

Daniel, I only see the same for both versions:

"Options: uncorrected,dos1,dos2,dos2b,dos3,dos4"

Can you post more details?

Nikos

[rest deleted]

@Beatrice

(after reading Daniel's e-mail, it reminded me that) I completely forgot to
keep-up as promissed to test some Landsat scenes related with the issue
reported in this thread. I am really sorry, I got work and other issues to
think about the past few weeks so I simply forgot it... :frowning:

Hope you found a solution anyway.

Nikos

Niko,

Attached goes a screenshot showing my Grass version (6.4.3) and the
correction methods available in i.landsat.toar
Noticed the "corrected" method option.

Also, you can see in the GIS Layer Manager the output of r.info of one
of the reflectance images. Notice how all values are equal to zero...

This is what the manual says about the "corrected" method:
----
Corrected at-sensor values (method=corrected)
At-sensor reflectance values range from zero to one, whereas at-sensor
radiance must be greater or equal to zero. However, since Lmin can be
a negative number then the at-sensor values can also be negative. To
avoid these possible negative values and set the minimum possible
values at-sensor to zero, this method corrects the radiance to output
a corrected at-sensor values using the equations (not for thermal
bands):

radiance = (uncorrected_radiance - Lmin)

reflectance = radiance / sun_radiance
Note: Other possibility to avoid negative values is set to zero this
values (radiance and/or reflectance), but this option is ease with
uncorrected method and r.mapcalc.
-----

Cheers
Daniel

On Fri, Oct 18, 2013 at 5:35 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Daniel Victoria wrote:

Updating my last email. I also see the same problem in WinGrass 6.4.3

And on a similar topic, i.landsat.toar in Grass6 has one extra
correction method when compared with Grass7.
In grass6 there is a Corrected at-sensor values options which I don't
see in Grass7. Why is that?

Daniel, I only see the same for both versions:

"Options: uncorrected,dos1,dos2,dos2b,dos3,dos4"

Can you post more details?

Nikos

[rest deleted]

(attachments)

wingrass_i.landsat.toar_methods.png

Daniel Victoria wrote:

Niko,

(thanks for paying attention to details, correct, in Greek you have to omit
the final "s" when you call someone by its name, the vocative case!)

Attached goes a screenshot showing my Grass version (6.4.3) and the
correction methods available in i.landsat.toar
Noticed the "corrected" method option.

I think I recall (now) seeing it also in the past (in the 6.4.x series).
Hemm... ? Not present now in

g.version -rg
version=6.4.4svn
revision=57976
date=2013
libgis_revision=50937
libgis_date="2012-02-25 15:14:51 +0200 (Sat, 25 Feb 2012) "

here.

Also, you can see in the GIS Layer Manager the output of r.info of one
of the reflectance images. Notice how all values are equal to zero...

This must be (one of) the old buggy version of the code -- otherwise, there is
no reason to get all-zero except, I guess, if you feed all-zero data.

This is what the manual says about the "corrected" method:

(Below ignore most of my comments, I just repeat things for my own practice.)

So, this is for 6.4.3
(<http://trac.osgeo.org/grass/browser/grass/tags/release_20130727_grass_6_4_3/imagery/i.landsat.toar/description.html#L63&gt;\):

----
Corrected at-sensor values (method=corrected)
At-sensor reflectance values range from zero to one,

right, it's a unitless ratio (see Wikipedia or else on Reflectance -- there is
also an old post in which I asked Yann Chemin about it...)

whereas at-sensor radiance must be greater or equal to zero.

right, Spectral Radiance is W · sr^−1 · m^−3 or W · m^-2 · sr^-1 · μm^-1
and it's normal to have values ranging above 1.

However, since Lmin can be a negative number then the at-sensor values can
also be negative. To avoid these possible negative values and set the
minimum possible values at-sensor to zero, this method corrects the radiance
to output a corrected at-sensor values using the equations (not for thermal
bands):

radiance = (uncorrected_radiance - Lmin)

reflectance = radiance / sun_radiance

Note: Other possibility to avoid negative values is set to zero this
values (radiance and/or reflectance), but this option is ease with
uncorrected method and r.mapcalc.
-----

It was removed in r57858:

<http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/imagery/i.landsat.toar/description.html?rev=57858#L15&gt;

?

Browsing more of the source code, I found a comment: "Deleted in 2013". Let's
ask Jorge :-).

Nevertheless and in general, I think, we require Spectral Reflectance values
to practice remote sensing. So having Radiance values, in a way "corrected
Radiances" to do away with issues arising from "negative" values, doesn't mean
you'd want to use them directly. You'd probably need to convert them to
Reflectances, right?

By the way, a nice overview is the presentation entitled

"Calibrated Landsat Digital Number (DN) to Top of Atmosphere (TOA) Reflectance
Conversion" by Richard Irish.

Greetings, Nikos

[..]

On Fri, Oct 18, 2013 at 12:30 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

Daniel Victoria wrote:

Niko,

(thanks for paying attention to details, correct, in Greek you have to omit
the final "s" when you call someone by its name, the vocative case!)

It was actually a typo! I forgot to hit the S key. I was not aware of
those differences in Greek. But hey, it worked :slight_smile:

Just another piece of information. Even though the r.info output shows
all zeros, both the radiance and TOA reflectance values looks correct.
At least for band 1, when compared with radiance and reflectance
calculated manually (using gain/bias and Solar radiance formulas).

Cheers
Daniel

On Thu, Oct 17, 2013 at 11:00 PM, Daniel Victoria
<daniel.victoria@gmail.com> wrote:

Updating my last email. I also see the same problem in WinGrass 6.4.3

And on a similar topic, i.landsat.toar in Grass6 has one extra
correction method when compared with Grass7.
In grass6 there is a Corrected at-sensor values options which I don't
see in Grass7. Why is that?

Both versions are currently not completely in sync (GRASS 7 lagging
behind since Jorge develops for G6).
Hope that gets fixed soon.

Markus