Страница 1 из 1

Атмосферная коррекция i.atcorr

Добавлено: 05 ноя 2014, 17:04
darsvid
Провожу атмосферную коррекцию данных Landsat 8 OLI (каналы 1-7), GRASS 7.0 beta 3, ОС Windows 7 64 bit.
Растры каналов предварительно переведены в radiance, тип 32float.

Вопросы:

1) нужно ли корректировать input range (и если нужно, то до каких значений), который по умолчанию [0,255]

2) похоже, что в справке неверно указаны параметры файла атмосферной коррекции для Landsat 8, а именно
Спойлер
17 Landsat 8, а нужно 18 Landsat 8
Спойлер
115 Landsat 8 Coastal Aerosol Band (0.427nm - 0.459nm), а нужно 116
116 Landsat 8 Blue Band (436nm - 527nm), нужно 117
117 Landsat 8 Green Band (512nm-610nm), нужно 118
118 Landsat 8 Red Band (625nm-691nm), нужно 119
119 Landsat 8 Panchromatic Band (488nm-692nm), нужно 120
120 Landsat 8 NIR Band (829nm-900nm), нужно 121
121 Landsat 8 Cirrus Band (1340nm-1409nm), нужно 122
122 Landsat 8 SWIR1 Band (1515nm - 1697nm), нужно 123
123 Landsat 8 SWIR2 Band (2037nm - 2355nm), нужно 124
определила это при чтении результата команды - там пишется канал при считывании файла с параметрами. Проблема возникает при коррекции 7 канала с номером 124 - информация о канале интерпретируется верно, но модуль выдает предупреждение и работа прекращается
Спойлер
i.atcorr --overwrite --verbose input=LC8_2014_162_band7_radiance@Landsat elevation=srtm_bt_aoi_utm35@Landsat parameters=G:\grassdata/bt_transition_potential/Landsat/.tmp/unknown/5080.8 output=LC8_2014_162_band6_atcor rescale=0,1
wavelength less than 0.25 micron:
let's take s(l)=s(0.25)
WARNING: Unsupported iwave value: 124
3) при коррекции канала 5 все значения становятся равными 1 - никак не могу понять в чем дело (geotiff во вложении).
Спойлер
18 - geometrical conditions=Landsat 8
6 11 9.14 24.345 48.234 - month day hh.ddd longitude latitude
2 - atmospheric mode=midaltitude summer
1 - aerosols model=continental
0 - visibility [km] (aerosol model concentration)
0.022 - aerosol optical depth 550 nm (from MODIS data)
-1.067 - mean target elevation above sea level [km]
-1000 - sensor height (here, sensor on board a satellite)
121 - 5th band of OLI Landsat 8
В общем и целом, изменений в композитах на основе атмосферно скорректированных данных по сравнению с DN/radiance не заметила, хотя по идее они же должны стать ярче/контрастнее?

Re: Атмосферная коррекция i.atcorr

Добавлено: 05 ноя 2014, 19:21
Ariki
А высота над уровнем моря -1.067 км - это не ошибка?
Про номер 17 - очевидная опечатка в мануале.
По поводу input range - сам ломаю голову. Нашёл вот это:
osgeo-org.1560.x6.nabble.com/Using-i-atcorr-on-SPOT4-and-SPOT5-imagery-td4985772.html
Но что-то они здесь ни к какой конкретике не пришли.

Re: Атмосферная коррекция i.atcorr

Добавлено: 05 ноя 2014, 20:01
darsvid
А высота над уровнем моря -1.067 км - это не ошибка?
не ошибка, горная территория (Карпаты) - средняя высота области исследования 1067 м, т.е. 1.067 км - пишется отрицательное значение в км
По поводу input range - сам ломаю голову. Нашёл вот это:
osgeo-org.1560.x6.nabble.com/Using-i-atcorr-on-SPOT4-and-SPOT5-imagery-td4985772.html
спасибо, почитала - нужно будет попробовать вариант с введением реальных мин/макс, хотя тоже как-то не уверена

Re: Атмосферная коррекция i.atcorr

Добавлено: 06 ноя 2014, 12:34
Ariki
Я склоняюсь к тому, что трогать input range не надо, иначе результаты будут зависеть от обрабатываемой территории. Значения radiance - они ведь в физических единицах. Там в коде входные значения приводятся к диапазону [0;1], используя этот самый input range, и в таком виде передаются модели 6S для вычислений. Выходные значения аналогично масштабируются обратно с использованием параметров rescale. Понять, что происходит внутри 6S, не в моих силах.
Для контроля можно сравнить результаты с simplified at-surface values, полученными с помощью методов DOS (i.landsat.toar). Думаю, если вкралась грубая ошибка, она будет видна. Хотя в правильности интерпретации метаданных Landsat 8 документация i.landsat.toar как-то не очень уверена.

Re: Атмосферная коррекция i.atcorr

Добавлено: 06 ноя 2014, 13:30
Ariki
Что касается кодов каналов - мне кажется, в справке всё правильно. По крайней мере, с кодом 120 у меня отрабатывает нормально на вашем 5 канале, а с кодом 121 все значения получаются равными 255.

Re: Атмосферная коррекция i.atcorr

Добавлено: 06 ноя 2014, 14:10
Ariki
А то, что в результатах он выводит неправильное имя канала, - это баг, там в коде из-за дублирующегося значения съехало соответствие названий индексам в массиве строк. На работу модуля влиять не должно.

Re: Атмосферная коррекция i.atcorr

Добавлено: 07 ноя 2014, 12:12
Ariki
Исправлено в r62638.

Re: Атмосферная коррекция i.atcorr

Добавлено: 20 июл 2015, 16:58
Tifoso
Ariki писал(а):Я склоняюсь к тому, что трогать input range не надо, иначе результаты будут зависеть от обрабатываемой территории. Значения radiance - они ведь в физических единицах.
Судя по приведённой информации в данной статья, корректировать значения входного интервала необходимо, и это логично. Хотя мне не совсем понятно, почему модуль не считывает эти данные из метаданных обрабатываемого файла.
Авторы рекомендуют указывать значения input range исходя из значений оптической плотности растра, при этом округляя их до целых. Но не вполне ясно, что тогда делать, если максимальные значения составляют, допустим, 1,1 - округлять до 1 и потерять часть данных, или округлять до 2, тем самым уменьшив получаемые значения почти на половину?

Re: Атмосферная коррекция i.atcorr

Добавлено: 24 июл 2015, 17:19
Ariki
Там в статье они используют флаг -r и подают на вход i.atcorr растр, содержащий reflectance, то есть отражающую способность, которая не может быть больше единицы. Но на практике эти значения чаще всего представлены не в формате с плавающей точкой (так они занимали бы слишком много места), а в виде целочисленного растра, то есть отмасштабированы. Для восьмибитного растра (наиболее распространённый случай) диапазон будет от 0 до 255. Поэтому эти значения и выбраны в качестве разумного умолчания, и именно поэтому границы диапазона округляются до целого: масштабировать значения с плавающей точкой нет смысла.

Поэтому я думаю, что авторы статьи, используя фактический диапазон значений растра вместо диапазона масштабирования, искажают значения отражающей способности. И если бы программе требовался фактический диапазон, она могла бы посчитать его сама по входному растру, даже метаданных ей для этого не нужно.

А вот что происходит, если в качестве входных данных у нас top-of-atmosphere radiance, я пока так и не разобрался.