ENVI: Resize + Orthorectification + Sharpening

[AndreyL]

Возможно, кто-то делал, поделитесь опытом. Есть снимок с RPC, мультиспектр и панхром. Нужно вырезать из него маленький кусочек (панхром размером пару гигабайт), на выходе должен получится цветной снимок с разрешением панхрома и орторектифицированный. Каждая из этих операций сложности не представляет, а вот в какой последовательности лучше это делать и какие могут быть нюансы?

Пока понял, что при вырезании куска из снимка с подгруженными RPC в НDR-файле все RPC сохраняются кроме последних трех (реально предпоследних двух, если масштаб не менять). Насколько я понимаю, 91-й и 92-й элемент набора rpc info НDR-файла как раз отвечают за сдвиг центральной точки. Если вырезать кусок из панхрома, а потом скрестить его с мультиспектром (алгоритм Грама-Шмидта), вся RPC-инфромация пропадает – проекция указывается как Geographic lat/long, а не RPC Geographic lat/long, при попытке редактирования хедера говорит, что файл не содержит RPC. Притом что получившийся цветной рисунок не соответствует по размеру исходной вырезке панхрома (что странно) – например, исходный кусок панхрома 5573 x 5694 x 1, полученный цветной 5680 x 5810 x 4, т.е. просто вручную подставить RPC панхрома не получится. Если их географически слинковать в двух разных окнах, то линкуются полностью корректно. Проводить отдельно орторектификацию мультиспектра и панхрома нелогично – придется дважды вручную вводить GCP, к тому-же на панхроме они заносятся в 4 раза точнее (разрешение мультиспектра к панхрому 1/4). Вот такие наблюдения, может кто подскажет, что с этим дальше делать.

[AndreyL]

Если их географически слинковать в двух разных окнах, то линкуются полностью корректно.

Тут я тоже погорячился - два зума, включен географический линк и на обоих зумах включены пиксель-локаторы

Панхром

PH.png (7.02 КБ) 17417 просмотров

композит панхрома и мультиспектра

GS.png (7.84 КБ) 17420 просмотров

На один пиксель таки есть ошибка, что странно

[Boris]

Похоже мы с вами бродим вокруг соседних "граблей". Как я понимаю из ответов на свой вопрос, небольшого опыта и литературы, в которой написано не то, что ищешь:
1. RPC -все же принадлежность каждого набора данных - PAN и MULTI - имеют разные.
2. Ортофото - делается каждого набора раздельно. Получается растр в одинаковой проекции, но не обязательно совпадающий пиксель в пиксель. Думаю, что этой проблеме и посвящено желание запросить точки на земле перед тем, как делать трансформацию. Без них (а может и с ними) - ничего не гарантированно.
3. Затем надо совместить MULTI с PAN, поскольку заявленная абсолютная точность +-30 метров, связана именно с Pan. Наверное - это кажется глупым, с учетом того, что они использовали общую модель рельефа при ортофото, но тем не менее. Может, это означает, что при начале ортофото для PAN обязательно следует выбрать совпадающие точки на Landsat+SRTM-90, а при начале орто для MULTI следует выбрать эти точки уже на PAN?
4. Не обязательный пункт, хотя многие советуют, - принудительно привести MULTI к разрешению PAN выбранным методом (как правило выбор не велик между bilineal и bicubic). Хотя у того же Adobe - целых три bicubic.
5. Собственно только после этого делать fusion.

[pendduduk]

1. RPC -все же принадлежность каждого набора данных - PAN и MULTI - имеют разные.

Безусловно, коэфф. для RPC модели вычисляются по строгой модели методом трассировки лучей на земную поверхность (в большинстве случаев, для территории России и сопредельных государств этой моделью являются GTOPO-30, SRTM-90, GDEM в зависимости от наличия данных). При этом следует отметить что съемка в PAN и MS режимах проводится немного в разное время, и соответственно углы ориентации аппарата и камеры, а так же и его координаты для PAN и MS сцен будут разными.

2. Ортофото - делается каждого набора раздельно. Получается растр в одинаковой проекции, но не обязательно совпадающий пиксель в пиксель. Думаю, что этой проблеме и посвящено желание запросить точки на земле перед тем, как делать трансформацию. Без них (а может и с ними) - ничего не гарантированно.

На самом деле тут все зависит от качества RPC коэфф. и детальности и точности вашего DEM...
Например, коэфф. для QB рассчитаны плохо (модель не очень хорошая), для обеспечения высокой точности продукта необходимо выполнять аффинную коррекцию (block adjustment), а вот у IKONOS достаточно сдвига. С современными все еще лучше обстоит...
И я бы честно говоря этот шаг пропустил
Насколько я слышал в ENVI есть хваленый коррелятор... так отчего же не совместить PAN и MS (MS натянуть на PAN).

3. Затем надо совместить MULTI с PAN, поскольку заявленная абсолютная точность +-30 метров, связана именно с Pan. Наверное - это кажется глупым, с учетом того, что они использовали общую модель рельефа при ортофото, но тем не менее. Может, это означает, что при начале ортофото для PAN обязательно следует выбрать совпадающие точки на Landsat+SRTM-90, а при начале орто для MULTI следует выбрать эти точки уже на PAN?

Это тоже можно опустить (см. выше)

могу предложить альтернативную цепочку
1. Совмещаем корреляторм MS c PAN
2. Делаем Fusion, при этом насколько я себе представляю должен получится растр размером (в пикселях) равный PAN
3. Приаттачиваем к этому продукту RPC от PAN и вуаля...

[Boris]

А в какой проекции все это у нас происходит до слов

вуаля...

? Грузим мы их с учетом RPC коэффициентов или как простой растр?

[pendduduk]

? Грузим мы их с учетом RPC коэффициентов или как простой растр?

Для того что бы потом приаттачить RPC коэфф. от PAN необходимо, что бы выходной растр был того же размера что и PAN, по этому грузить нужно просто как тиф и ни какой коррекции предварительной не делать.
Соотв. растр будет в UTM.

[Boris]

Спасибо. Теперь если можно расшифруйте как именно приатачивать?

[AndreyL]

На самом деле можно автокоррелятором привязать цветной композит на панхром – если панхром открыт как RPC, то его коэффициенты приаттачатся цветной картинке. Орторектификация без GCP проходит нормально, а с GCP почему-то получается черная картинка в стиле Малевича.

Например, коэфф. для QB рассчитаны плохо (модель не очень хорошая), для обеспечения высокой точности продукта необходимо выполнять аффинную коррекцию (block adjustment), а вот у IKONOS достаточно сдвига.

Вот об этом можно поподробнее, у меня как раз Птица.

[pendduduk]

Спасибо. Теперь если можно расшифруйте как именно приатачивать?

Я бы просто сохранил результат pan_sharp как тиф и скопировал бы к нему исходный RPB (только его соотв нужно переименовать в file_name.RPB где file_name - это имя вашего тифа).

Вот об этом можно поподробнее, у меня как раз Птица.

Ну это обще известный факт... о том что это такое написана куча всяких статей.
В двух словах, для обеспечения "метровой" точности ортотрансформирования QB необходимо выполнить аффинную (в некоторых источниках говорят полином^1) трансформацию растра уже орторектифицированного по исходным RPC коэфф. Обычно это делается внутри процедуры ортотрансформирования (по крайней мере так дело обстоит в PCI Geomatics, LPS, Scanex IMAGE PRCR), причем тип коррекции задается пользователем.
Правда стоит отметить, если вы пытаетесь делать ортотрансформирование используя модель SRTM-90 то ни о какой точности говорить все равно нельзя, т.к. детальность модели для такого разрешения ну оооооочень мала , для высокого разрешения нужно по крайней мере 10м шаг. Кроме того падение точности усугубляется в зависимости от угла съемки, а по опыту для QB они как правило более 15 градусов.

А по поводу Малевича... пакет ENVI мягко говоря со странностями , я пробовал проделывать одни и те же (по смыслу) операции, на одном и том же наборе данных, в разных пакетах. И что забавно, результаты получал разные. Но результаты которые порождал ENVI всегда были несколько странными (при ортотрансформировании - жужжание более 4 часов и на выходе Малевич, при построении DEM - явно неправильно выполняется эпиполярное преобразование, и тд. и тп.).

[AndreyL]

Я бы просто сохранил результат pan_sharp как тиф и скопировал бы к нему исходный RPB (только его соотв нужно переименовать в file_name.RPB где file_name - это имя вашего тифа).

Перед шарпенингом нужно вырезать из снимка кусок, иначе выходной файл огромный будет. А тогда RPC изменятся. Кроме того, после шарпенинга размер картинки меняется – не знаю, почему, но факт. А ЭНВИвский хедер-файл кроме самой ЭНВИ, по моему, никто не читает, тем более, что там 93 коэффициента, а не 90

В двух словах, для обеспечения "метровой" точности ортотрансформирования QB необходимо выполнить аффинную (в некоторых источниках говорят полином^1) трансформацию растра уже орторектифицированного по исходным RPC коэфф.

Не понял. Если модель RPC смещена, то орторектификация на ДЕМ даст неверную картинку, которую потом ничем уже не исправить.

Обычно это делается внутри процедуры ортотрансформирования (по крайней мере так дело обстоит в PCI Geomatics, LPS, Scanex IMAGE PRCR), причем тип коррекции задается пользователем.

А в ЭНВИ такая опция есть? Я чего-то не видел, в ЭРДАСе помню, была. Может быть, можно ручками поправить смещения и масштабы? Вряд ли нужно трогать коэффициенты числителя и знаменателя. Существует ли описание алгоритмов? ДЕМ используется SRTM3 – другого нет, это примерно 90-на-60 метров, угол съемки 20 градусов к надиру

[pendduduk]

Перед шарпенингом нужно вырезать из снимка кусок, иначе выходной файл огромный будет. А тогда RPC изменятся. Кроме того, после шарпенинга размер картинки меняется – не знаю, почему, но факт. А ЭНВИвский хедер-файл кроме самой ЭНВИ, по моему, никто не читает, тем более, что там 93 коэффициента, а не 90

Тут нет проблем.. просто нужно будет подправить LINE_OFF и SAMP_OFF. Эти параметры определяются относительно центра растра (исходного) соотв., вам нужно вычислить смещение и вычесть его из исходный значений. И зачем вам хэдер ENVI? есть же исходный RPB, его и правьте.

Не понял. Если модель RPC смещена, то орторектификация на ДЕМ даст неверную картинку, которую потом ничем уже не исправить.

Тут есть 2 варианта (так пишут в статьях):
1. Сначала делается коррекция по точкам, а потом с учетом коррекции делается орторектификация по RPC коэфф.
2. Наоборот, сначала орто, а потом коррекция по точкам.

А в ЭНВИ такая опция есть? Я чего-то не видел, в ЭРДАСе помню, была. Может быть, можно ручками поправить смещения и масштабы? Вряд ли нужно трогать коэффициенты числителя и знаменателя. Существует ли описание алгоритмов? ДЕМ используется SRTM3 – другого нет, это примерно 90-на-60 метров, угол съемки 20 градусов к надиру

Я же писал ранее про забавность пакета ENVI... вполне возможно что где то оно есть но как оно работает мне не известно
Статей на эту тему вагон http://www.google.ru/#hl=ru&q=RPC+bundl ... 3e0f54e663

И какую вы планируете получить точность с таким набором данных? Одно из главных правил фотограмметрии гласит: "плановое смещение координат зависит от угла съемки и высоты местности dR=H*tan(A), где А - угол съемки, а H - высота местности", а у вас размер ячейки DEM 90м... так что любой перепад (например, откос эстакады, край обрыва и т.д) не выраженный в пикселе DEM даст вам ошибку трансформирования которую вы можете оценить по приведенной выше формуле. Единственное что для сканерной съемки это правило справедливо только вдоль строк сканирования (по ширине исходного - вообще без коррекции растра), поперек ошибки за рельеф не будет.

[AndreyL]

В нашей местности ошибка SRTM за счет пропусков где-то метров 10-15. Т.е. точность будет порядка 5 метров. Плюс еще точность GCP по GPS еще пять метров, итого должна получится планарная точность 10 метров.

Привязал композит в панхрому и перегнал в формат NITF – он Лейкой нормально читается. Кстати, каким инструментом в Лейке проще сделать орторектификацию – я не очень с ней знаком, у меня девятка есть. ЭНВИ действительно как-то странно себя ведет.

[pendduduk]

В нашей местности ошибка SRTM за счет пропусков где-то метров 10-15. Т.е. точность будет порядка 5 метров. Плюс еще точность GCP по GPS еще пять метров, итого должна получится планарная точность 10 метров.

Не совсем так... у вас будет средняя точность по больнице в лучшем случае такая... а вот локальная ошибка у вас будет больше за счет того, что в пикселе SRTM не выражен микрорельеф. Детальности у SRTM маловато.

Привязал композит в панхрому и перегнал в формат NITF – он Лейкой нормально читается. Кстати, каким инструментом в Лейке проще сделать орторектификацию – я не очень с ней знаком, у меня девятка есть. ЭНВИ действительно как-то странно себя ведет.

Дык тут один инструмент... LPS (то что раньше называлось Ortho Base). Там вроде просто все, я с первого раза разобрался и результат получил (не Малевича ).

[AndreyL]

... у вас будет средняя точность по больнице в лучшем случае такая... а вот локальная ошибка у вас будет больше за счет того, что в пикселе SRTM не выражен микрорельеф. Детальности у SRTM маловато.

10-15 метров, это как раз за счет гребешков и ямок, не попадающих в масштаб SRTM. Это выяснили, когда делали ДЕМ по аэрофотосъемке 5-тысячного масштаба на соседнем участке.

Дык тут один инструмент... LPS (то что раньше называлось Ortho Base). Там вроде просто все, я с первого раза разобрался и результат получил (не Малевича ).

У меня есть еще AutoSync и Image Geometric Correction, оба способны делать орторектификацию на ДЕМе, настройки немного разные.

[pendduduk]

10-15 метров, это как раз за счет гребешков и ямок, не попадающих в масштаб SRTM. Это выяснили, когда делали ДЕМ по аэрофотосъемке 5-тысячного масштаба на соседнем участке.

Ну вам повезло

У меня есть еще AutoSync и Image Geometric Correction, оба способны делать орторектификацию на ДЕМе, настройки немного разные.

Первый на сколько я помню - это коррелятор, а второе сильно упрощенная модель. Пользуйте LPS.
Ну или модули другого ПО - PCI (OrthoEngine), Image PRCR (тут в базе все есть вроде).