ENVI: Resize + Orthorectification + Sharpening

[AndreyL]

Единственная настройка в LPS, это Refinement With Polynomials со степенью – есть подозрение, что это именно то, о чем Вы говорили «аффинная (в некоторых источниках говорят полином^1) трансформация». После триангуляции (высоты брались с SRTM) точность 1.5 метра – не плохо, по-моему.

Жалко, что приходится две программы использовать – моя Лейка, похоже, не знает алгоритма Грамма-Шмидта.

[pendduduk]

Единственная настройка в LPS, это Refinement With Polynomials со степенью – есть подозрение, что это именно то, о чем Вы говорили «аффинная (в некоторых источниках говорят полином^1) трансформация». После триангуляции (высоты брались с SRTM) точность 1.5 метра – не плохо, по-моему.

Именно так, только все равно по поводу точности не обольщайтесь

Жалко, что приходится две программы использовать – моя Лейка, похоже, не знает алгоритма Грамма-Шмидта.

Тогда попробуйте PCI там собственно реализован алгоритм pan_sharp который используют у себя GeoEYE и DigitalGlobe

[AndreyL]

только все равно по поводу точности не обольщайтесь

На самом деле все GPS-ные точки и треки легли с приемлемой точностью, этого достаточно, спасибо за советы.

Тогда попробуйте PCI там собственно реализован алгоритм pan_sharp который используют у себя GeoEYE и DigitalGlobe

К сожалению, PCI у меня нет

[pendduduk]

На самом деле все GPS-ные точки и треки легли с приемлемой точностью, этого достаточно, спасибо за советы.

Не за что, надеюсь что помог

К сожалению, PCI у меня нет

Ну можно ScanEx , тоже приличная прога.

[Boris]

А в ScanEx то как загрузить RPC коэфициенты?

[pendduduk]

А в ScanEx то как загрузить RPC коэфициенты?

В диалоговом окне Plynomial Transformation есть радиокнпка RPC и три варианта файлов коэфф. (OrthoKit - IKONOS, GeoEye, CARTOSAT и тд.; QB - QB, WorldView; NITF - это для PRISM только я обнаружил что коэфф. у PRISM корявые, нужно предварительно их править), а так же режим как править (сдвиг и аффинка). Там же в диалоге указывается DEM или константная высота. Это все актуально для версии 3.0 если не ошибаюсь.

[AndreyL]

только я обнаружил что коэфф. у PRISM корявые, нужно предварительно их править)...

А как обнаружили, в чем "корявость" и как нужно править? У меня PRISM и надирный и обратный без контрольных точек легли прекрасно в той же ЭНВИ

[pendduduk]

А как обнаружили, в чем "корявость" и как нужно править? У меня PRISM и надирный и обратный без контрольных точек легли прекрасно в той же ЭНВИ

Да все очень просто... RPC - вещь стандартная, собственно говоря я когда работал с PRISM-ом решил что обрабатывать его по линейкам - это садизм над собой, и написал утилиту которая сшивает линейки в единый растр. Поскольку в состав продукта 1B0 входит RPC на полный растр такое решение мне казалось оправданным. Только вот когда я попытался использовать этот RPC файл, получил большую ошибку. Стал разбираться и обнаружил что у них иногда не правильно записан параметр SAMP_OFF (вместо того что бы указать там, как положено центр строки указано непонятное мне число). Это исправляется элементарно, но потом я стал сравнивать результаты орторектификации в различном ПО и обнаружил, что кроме всего прочего для параметра SAMP_OFF еще присутствует сдвиг (в 21 пиксел). Сдвиг я обнаружил сконвертировав NITF-RPC (стандарт ALOS) в OrthoKit (мне так удобнее смотреть на цифири). Так вот результаты ортотрансформирования по одним и тем же коэфф., но в разных форматах записи - дали разный результат. Насколько я понимаю это просто кривизна Японцев, а в ENVI и LPS (только в них проверял) просто знают об этом баге и его учитывают. Так что будьте осторожны с АЛОС-ом господа

[AndreyL]

Весьма странно. Я тоже собирал из полос, но перед этим проверил, насколько совпадают PRC по полосам с пятым PRC по всей теме. Просто написал маленькую программульку, считающую положение пикселя для заданных координат и плюс еще со смещением полосы при сшивке. Получил, что все четыре PRC по полосам бьют с пятым PRC по всей теме с точностью не более 1 пикселя. После чего спокойно все сшил и орторектифицировал по пятому PRC. Никаких проблем с SAMP_OFF не было. Сшивал в той же ЭНВИ тупо задавая смещение в пикселях. А Вы как сшивали? Сколько перекрытие между полосами?

[pendduduk]

Весьма странно. Я тоже собирал из полос, но перед этим проверил, насколько совпадают PRC по полосам с пятым PRC по всей теме. Просто написал маленькую программульку, считающую положение пикселя для заданных координат и плюс еще со смещением полосы при сшивке. Получил, что все четыре PRC по полосам бьют с пятым PRC по всей теме с точностью не более 1 пикселя. После чего спокойно все сшил и орторектифицировал по пятому PRC. Никаких проблем с SAMP_OFF не было. Сшивал в той же ЭНВИ тупо задавая смещение в пикселях.

Ну вот пожалуйста посмотрите что у меня написано в RPC для F: 00799919598 (LINE_OFF=007999, SAMP_OFF=19598) размер растра на выходе 19616х16000, так вот для такого растра SAMP_OFF должно быть 19616/2=9808. А то что у вас в ENVI все получилось ... я же говорил ранее что они видимо эту фитчу Японскую учитывают. Попробуйте просто сконвертировать RPC в другой формат и применить в том же ENVI (например, выдав АЛОС за CARTOSAT или IKONOS).

А Вы как сшивали? Сколько перекрытие между полосами?

Написал утилитку - на входе CEOS на выходе TIFF, внутри tiff-а записана сетка координат (в виде GCP) рассчитанная по полиному хранящемуся внутри LEADER файла. Перекрытие там всегда стандартное 32 пикселя (это описано в в спецификации).

[AndreyL]

Да, действительно, странно. У меня для всех полос 00799902494 (LINE_OFF=007999, SAMP_OFF=02494), размер полосы samples = 4992, lines = 16000

А в пятом 00799909936 (LINE_OFF=007999, SAMP_OFF=09936), т.е. все корректно.

[pendduduk]

Да, действительно, странно. У меня для всех полос 00799902494 (LINE_OFF=007999, SAMP_OFF=02494), размер полосы samples = 4992, lines = 16000

У надирных (4-х полосых) как правило всегда размер правильный, а вот у F и B лажа постоянно.
Но забавно другое, если применить эти коэфф. в том виде в котором они записаны файле (например те что у вас) получаются совсем другие координаты (ошибка около 50-ти метров по Х)

[AndreyL]

Для B той же стереопары:
для полос 00799902462, для пятого 00799909806.
Никакой лажи при этих смещениях не обнаружено – все легло как надо без GCP, все GPS-ные точки и треки на месте, где-то в районе 10-15 метров – грех жаловаться, я GCP вряд ли точнее поставлю. Посмотрел смещения из HDR-файла ЭНВИ – точно такие же. Тем более, что я их проверял на соответствие. ЭНВИ, правда, косячил при построении связующих точек автоматом, а Лейка все делала правильно.

[AndreyL]

Да, кстати, если я правильно понимаю, то Refinement With Polynomials с нулевой степенью в LPS как раз повлияет только на LINE_OFF и SAMP_OFF – попросту скорректирует их по контрольным точкам. Правда, не знаю, удастся ли их потом выцепить, исправленные.

[pendduduk]

Для B той же стереопары:
для полос 00799902462, для пятого 00799909806.

А у меня более 300 штук этих АЛОС-ов, и у половины лажа

Никакой лажи при этих смещениях не обнаружено – все легло как надо без GCP, все GPS-ные точки и треки на месте, где-то в районе 10-15 метров – грех жаловаться, я GCP вряд ли точнее поставлю. Посмотрел смещения из HDR-файла ЭНВИ – точно такие же. Тем более, что я их проверял на соответствие. ЭНВИ, правда, косячил при построении связующих точек автоматом, а Лейка все делала правильно.

Я же говорю... ENVI и LPS знают про эту фичу (по этому там и дается разделение при импорте RPC - IKONOS, ALOS и т.д), они просто учитывают сдвиг.

Да, кстати, если я правильно понимаю, то Refinement With Polynomials с нулевой степенью в LPS как раз повлияет только на LINE_OFF и SAMP_OFF – попросту скорректирует их по контрольным точкам. Правда, не знаю, удастся ли их потом выцепить, исправленные.

Да 0 - это простой сдвиг. Узнать можно только по точкам... вычесть конец из начала и сосчитать.