Weird output of 'i.atcorr' in WorldView2 red channel (band 5)

[ppina]

I performed the atmospheric correction with 6S algorithm (i.atcorr) in a scene of WorldView2 satellite. It works nicely on the PAN band and on 7 of its 8 multispectral bands. The bad one is the red channel (band 5) which delivered weird results in some locations of the scene (sample details in a file attached). I tested different parameters of the algorithm, used radiance and reflectance images as input, but red band ouputs of i.atcorr always looked weird. On the contrary, all atmospheric correction outputs for all other bands showed to be 'normal'. Since this only happens with this specific band, I wonder if there is not a bug in its processing or on related filter functions.

[neteler]

We ave implemented the filter functions provided here:

​https://apollomapping.com/blog/new-documents-atmospheric-correction-digitalglobe-satellites-2

I just converted them once more and the resulting curves are the same. For the CSV files implemented, see ​https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_2/imagery/i.atcorr/sensors_csv

Question: You speak about band 5 = red. However, the filter functions are ordered as this:

1	2	3	4	5	6	7	8	  9
Pan	Blue	Green	Red	NIR1	Coastal	Yellow	Red Edge  NIR2

i.e. the 5th band is NIR1. May that be the reason (wrong band number)?

[neteler]

Several stability fixes were applied (r73183, r73188 etc). Does the problem persist in GRASS GIS 7.6.x or later?