падение ArcGis при работе с растрами

[new_sergei]

Добрый день!
Периодически происходит крэш ArcGis при попытке просмотра растра.
Вижу стандартное окно с предлоежнием отправить отчёт об ошибке.




При попытке работать с этим растром через ArcPy я всегда (в отличие от работы "руками" в Desktop) получаю следующее сообщение:



Т.е., он Python вылетает и ругается на gdal.
Насколько я понимаю, эти 2 крэша - это одно и тоже.
Проблема, очевидно, в растре. Но вот как диагностировать её? Дело в том, что никакого другого софта по работе с растрами у меня нет (можно использовать только лицензионное ПО). А такие крэши Python'ом никак не отлавливаются, т.к. Python от такого сам загибается.
Сам снимок придоставить на обозрение, к сожалению, не могу. Но судя по имени (дата_wv2_orps_6507.tif), это WorldView. Снимое 4-х канальный.
Как можно побороть эту проблему?

[new_sergei]

Да, и ещё, Exception Code из собщения указывает на деление на 0, но это что-то для Экселя, и явно с этим не связано

[Boris]

Я не являюсь специалистом в ArcGIS, но раз в каком то случае вы получаете сообщения от библиотеки GDAL, которая используется ArcGIS, то GDAL имеет несколько утилит командной строки (бесплатных, не имеющих лицензионных ограничений), которые должны облегчить ответ на ваш вопрос, а может и снять его.
Для начала к проблемному расту надо вызвать GdalInfo и результат приложить к вопросу, а затем попробовать запустить gdal_translate из формата TIF в какой-нибудь сложный формат типа Erdas Imaging.
На вскидку, я могу предположить, что вы имеете растр большого размера, который в распаковованном формате больше 4ГБ, т.н. BigTiff, а какой то из промежуточных модулей GDAL его не понимает. В прочем в моей практике работы с GDAL был случай, когда одна из версий GDAL не понимала один из вариантов сжатия LZW и падала при обращении к таким TIF файлам. Что к стати может давать как раз деление на 0, поскольку формат сжатия допускает использование внутренних данных в формате данных плавающей точкой, а по умолчанию ожидается, что формат будет целочисленным.

[new_sergei]

Спасибо за обстоятельный ответ.
Завтра попробую на работе

[new_sergei]

Борис, вот что у меня получилось в результате экспериментов:
1) размер проблемного файла чуть больше 1 Гб
2) результат gdalinfo для проблемного растра в атачменте (на первый взгляд - ничего подозрительного)
3) результаты gdal_translate для конвертации в .img такие:



Честно говоря, пока ничего подозрительного не вижу

[new_sergei]

Кстати, в QGIS растр открывается без проблем

[Boris]

Что видно сразу:
1. gdal_translate создал не Erdas Imagine (.img), а GeoTIFF, поскольку нет оператора -f "HFA", задающего результирующий формат файла.
2. Но это не плохо, поскольку дало таки новые данные - при конвертации TIF->TIF : программа говорит, как я понимаю, что метаданные из исходного GeoTIFF слишком велики, что бы их поместить в результирующий GeoTIFF.
3. Теперь по исходному растру:
а) он 16-битный
б) похоже он создан в Erdas, и видимо, там же настроен для отображения, а затем еще раз пропущен через какую то из утилит GDAL.
в) метаданные просто огромные. И судя по всему смешанные - есть метаданные от Erdas Imagine и есть метаданные от GDAL.
Теперь предположения:
1. В метаданных есть блоки "STATISTICS_HISTOBINVALUES=" и "<GDALRasterAttributeTable " с огромным количеством цифр, видимо, они задают способ отображения 16-битного растра на экране. Можно предположить, что ArcGIS использует первый из них, поскольку имеет большие связи с ERDAS, а QGIS - второй, поскольку построен на 100% GDAL. Это объясняет разницу в отображении.
2. 16-битовый раст просто для просмотра редко используют, т.к. на экране он все равно приводится к 8-битам. Такой раст может быть исходным у WV, или использоваться в программе анализа, но для просмотра надежней его перевести в 8-битный. Правда для этого нужна программа, которая умеет реализовывать некоторый алгоритм "свертки" 16-бит в 8-бит. В реальности никогда не бывает занято все 16-бит, но подстройка гистограммы или ее трансформация - это отдельная работа. Вроде бы gdal_translate что то такое умеет, но я не пробовал - я делал только в экранных программах обработки растров.
Выводы:
1. и 16-бит с таблицей перекодирования цветов и огромные метаданные могут переполнять какой-нибудь внутренний буфер в ArcGIS, который потом может портить другие данные программы и вызывать ее падение.
2. В блоке "STATISTICS_HISTOBINVALUES" метаданных огромное количество нулей, не знаю его истинного смысла, но если он сформирован не правильно, то это может вызывать ошибки деления на 0.
Возможные решения:
1. почистить метаданные. Фотошоп отлично убивает все метаданные, которых не знает, а не знает он никаких пространственных тегов. Где то в утилитах GDAL есть "gdal_edit" - утилита для корректировки метаданных. На самый простой случай сойдет и gdal_translate TIF->TIF с опцией "PROFILE=GeoTIFF", которая должна убрать тэги не соответствующие стандартному GeoTIFF.
2. Привести растр к 8-битам и настроить каналы RGB, поскольку в исходном растре их 4. Для уменьшения разрядности с настраиваемым сжатием цветового пространства стоит использовать опцию "-scale" из gdal_translate. Но, на мой вкус, ПО, предназначенное для обработки растров с отображением результата на экране, а ля фотошоп (убьет привязку - ее необходимо сохранить заранее, как и другие гео-тэги), ENVI, Erdas Image, Scanex IP - подойдет в этом случае лучше.
3. Если и после этого файл будет "ронять" ArcGIS, то придется построить новые гипотезы, или просто поделить его на 4 части.
...
Хотя, вот только сейчас пришло в голову, что такое было у ArcGIS, не помню версии, когда она автоматом пытается строить растровые пирамиды при открытии растра, и умирает не осилив этой задачи. Для этого случая, можно попробовать самому построить пирамиды заранее, и в отдельном файле, что бы не перегружать исходный, утилитой "gdaladdo -ro".

[new_sergei]

Борис, срасибо за обстоятельный ответ. Переварю то, что Вы написали, потом буду пробовать что-то из Ваших советов