i.atcorr return NULL values

[curvelo]

Hello, my name is Alexander.

I'm not able generate atmospherically corrected image from the band 3 of TM / Landsat 5 using i.atcorr.

No error occurs during the process, however, the output image appears to be invalid and all pixels are NULL value.

The input image is converted to the same band reflectance at the top of the atmosphere. The conversion was made by the module r.mapcalc.

I'm using version 6.4.2 of the GRASS GIS and working through the graphical interface.

My OS is Windows Vista Business SP2.

Attached I am sending the *. MTL and basic metadata of the raster output i.atcorr (r.info).

[curvelo]

Landsat metadata file

[curvelo]

Metadata Basic raster output i.atcorr (r.info)

[curvelo]

6S input text file (icnd)

[curvelo]

hi,

This was the command line used in the process: "i.atcorr -o iimg=L5181040_04020111020_B30_TOA@bug_2 icnd=input_grass_6.txt oimg=L5181040_04020111020_B30_TOA_iatcorr".

Thanks.

[gisix]

Hi,

i.atcor produces NULLs and strange output also for other sensors: I can confirm this for RapidEye data: Input Data: L3A RapidEye data without notable clouds and no blackfill. Bands used: bed / green / blue

As RapidEye data comes in 16bit, the input data was initially rescaled to 8bit [0-255]. The results were unexpected: Only three category values: Many zeroes and a few "1" and "2" values. This applied for all three bands.

In a next attempt, the original 16bit data was fed into i.atcorr. The results are described below. This was compared with a shifting (r.rescale) of the 16 bit value ranges of all bands to start with the value "0" [Example: original range: [4068-56975] (range: 52907) -> new range: [0 - 52907]]. The results from both kinds of input are similar:

For the red band, a reasonable result was produced. Statistics of red band (digital numbers) [r.univar]: n=49000000 null_cells=25249370 cells=74249370 min=1286 max=58603 range=57317 mean=4733.57011167347 mean_of_abs=4733.57011167347 stddev=1226.24474903503 variance=1503676.18453598 coeff_var=25.905283329616 sum=231944935472

For the green band, a NULL layer was produced.

Statistics of green band (digital numbers) [r.univar]: n=49000000 null_cells=25249370 cells=74249370 min=2464 max=54248 range=51784 mean=5646.62104434694 mean_of_abs=5646.62104434694 stddev=986.535495533873 variance=973252.283948265 coeff_var=17.471253831024 sum=276684431173

For the blue band, faulty values (looked like a binary image of the original scene) were produced.

Statistics of blue band (digital numbers) [r.univar]: n=49000000 null_cells=25249370 cells=74249370 min=4068 max=56975 range=52907 mean=6479.12217332653 mean_of_abs=6479.12217332653 stddev=859.459951841108 variance=738671.408818719 coeff_var=13.2650678417419 sum=317476986493

[gisix]

Another update:

The same data sets as described in my previous comment were used (Spearfish AOI, 2 L3A tiles, no blackfill).

The three bands red,green,blue were all processed by the controll files applicable for RapidEye-red/green/blue (i.e. each band was processed three times times, once with the control file intended for it, and also with the to other control files).

Results:

Control File "Blue": 13 05 09 18.00 -103.79170986 44.53451932 2 1 30 -1.100 -1000 88

Output: Reasonable results for red and green band, blue band produces stark black and white image.

---

Control File "Green":

13 05 09 18.00 -103.79170986 44.53451932 2 1 30 -1.100 -1000 89

Result: All bands produce just NULL values.

---

Control File "Red":

13 05 09 18.00 -103.79170986 44.53451932 2 1 30 -1.100 -1000 90

Result: All bands produce reasonable output.

Conclusion: There is an issue how the "green control" file controls the processing.

[neteler]

For the record, see also #1320