Самым простым способом решения этой проблемы для меня было использование виртуального формата GDAL . Этот формат позволил мне обработать весь набор изображений как один объект изображения и преобразовать его в три относительно простых шага.
Создание виртуального набора данных
GDAL (включая бинарные файлы GISInternals для Windows от Tamas Szekeres и последние версии OSGeo4W ) включает в себя утилиту gdalbuildvrt, которую можно использовать для создания исходного виртуального набора данных.
Один из простых способов использовать это - добавить все ваши изображения в текстовый файл, а затем использовать этот текстовый файл в качестве входных данных для gdalbuildvrt. Вот пример (вам нужно поместить вторую команду обратно в одну строку):
dir /b *.tif > my_images.txt
gdalbuildvrt
-hidenodata
-vrtnodata "255 255 255"
-resolution highest
-input_file_list my_images.txt
my_image.vrt
В результате у вас останется XML-файл, который вы можете рассматривать как одно изображение для всех операций GDAL. Он также внутренне представляет nodata белым цветом, но скрывает определение nodata от инструментов, считывающих его.
Создание пересмотренного обзора
Затем вы выполните повторную выборку и вывод обзорного изображения. Вы можете сделать это с помощью gdal_translate или gdalwarp . Для любого из них помните, что результирующий размер будет width * height * 3
(число 8-битных полос) байтов. Если это будет больше, чем 4 ГБ, вы захотите посмотреть опции GeoTIFF для синтаксиса, чтобы указать BigTIFF в качестве вывода (-co "BIGTIFF = YES").
Для gdal_translate вам необходимо определить размеры виртуального образа с помощью удобной команды gdalinfo . Возьмите эти размеры и разделите каждое на некоторый непротиворечивый коэффициент, чтобы определить ширину и высоту файла в пикселях.
Команда будет выглядеть примерно так (в одну строку):
gdal_translate
-outsize 53120 14000
-co "TILED=YES"
-co "PROFILE=GEOTIFF"
-co "BLOCKXSIZE=256"
-co "BLOCKYSIZE=256"
my_image.vrt
my_image.tif
Для gdalwarp вам нужно знать результирующий размер пикселя; в этом случае я использую 0,5 метра. Вы также захотите позвонить по методу повторной выборки. Я предпочитаю cubicspline для обзоров ортофото. Это мягче, но вы не собираетесь использовать их до полного разрешения, и, по моему опыту, оно создает более сжимаемое изображение, если вы используете что-то вроде JPEG или ECW.
gdalwarp
-r cubicspline
-of GTiff
-dstnodata "255 255 255"
-tr 0.5 0.5
-co "PROFILE=GEOTIFF"
-co "BIGTIFF=YES"
-co "TILED=YES"
-co "BLOCKXSIZE=256"
-co "BLOCKYSIZE=256"
my_image.vrt
my_image.tif
Вы также можете рассмотреть возможность использования параметров сжатия JPEG для этих обзоров GeoTIFF с измененной выборкой; он значительно сокращает выходной файл с ( по словам Фрэнка ) лишь незначительным снижением производительности.
-co "COMPRESS=JPEG"
-co "JPEG_QUALITY=80"
-co "PHOTOMETRIC=YCBCR"
Обзорные
Вам также нужно будет выполнить удобную команду gdaladdo над результирующим изображением, чтобы построить внутренние «пирамиды», чтобы запросы с меньшим разрешением, чем у полных измерений изображения, могли быть удовлетворены подмножеством данных. Увеличение производительности в большинстве случаев более чем стоит дискового пространства. Вам захочется поиграть с уровнями, которые вы используете здесь; для очень больших изображений вы можете удалить некоторые. Команда gdaladdo выглядит примерно так:
gdaladdo
-r average
my_image.tif
2 4 8 16 32 64 128 256
Я бы предложил поэкспериментировать с этими уровнями для оптимальной производительности. Вы можете обнаружить, что другой интервал повторной выборки лучше подходит для вашего приложения или, в зависимости от размера вашего изображения, вы можете отбросить некоторые из более высоких чисел (или что требуется больше)
Кроме того, если вы создаете внешний обзор (используя опцию -ro), попробуйте добавить строки конфигурации сжатия JPEG:
--config COMPRESS_OVERVIEW JPEG
--config PHOTOMETRIC_OVERVIEW YCBCR
--config INTERLEAVE_OVERVIEW BAND
(Я считаю, что они унаследованы от родительского GeoTIFF для встроенных обзоров)
Ноты
Когда я столкнулся с этой проблемой, я спросил на канале #gdal на freenode.irc.net. Это удивительный ресурс, и я глубоко признателен Говарду Батлеру, Фрэнку Вармердаму и Эвену Руо за помощь в этом.
^
для разрыва строки, который будет соединяться при выполнении (например, добавляйте^
в конец каждого примера строки кода выше, чтобы сохранить удобочитаемость и возможность выполнения). Важное предостережение: никогда не заканчивайте файл или командную строку с помощью каретки, если только вы не хотите вызывать использование всей памятиДа, но методом проб и ошибок я смог определить, что параметр -vrtnodata 255 помечает все, что является белым, как нодату, а не только не отображает карту, которую gdal2tiles затем обрабатывает с помощью прозрачности альфа в соответствии с флагом -a.
Таким образом, в конечном итоге некоторые исходные изображения становятся прозрачными, в моем случае - белыми частями пунктирных дорог. Это не терминал, но было бы неплохо иметь возможность указать для gdal2tiles цвет «no src image», либо в результате оригинальных пустот в vrt, либо в результате деформации. Для моего набора оттенок бледно-синего цвета был бы только вещью.
После еще большего количества проб и ошибок кажется, что ключом является hidenodata. Я не знаю, почему эти инструменты настолько минимально задокументированы. Вот что работает для меня, GDAL 1.8.
источник
Я не слишком знаком с GDAL, но я предполагаю, что метод или команда доступны, где вы можете установить пиксель определенного значения с другим значением?
Ничего общего с этим, но в простом SQL что-то вроде (просто для иллюстрации - это гораздо больше псевдокода):
ОБНОВЛЕНИЕ растра SET pixel = 255 WHERE pixel = NoData;
Я хотел бы знать ответ!
источник