Скорость различных форматов растровых данных

У меня возникают проблемы с поиском каких-либо обсуждений или сравнительного тестирования различных форматов растровых файлов (например, для использования в анализе данных в R). Кто-нибудь знает, почему определенные форматы могут быть быстрее или медленнее? Или различия должны быть минимальными?

В частности, меня интересует, стоит ли когда-либо преобразовывать растр (например, файл GEOTIFF) в другой формат (например, netCDF) с целью ускорения чтения / записи и других операций.

Вот моя старая статья в блоге, в которой рассматривается размер файла и время доступа к форматам. Я не исследовал скорость записи, только время доступа. Я бы сказал, что они, вероятно, будут иметь прямое отношение, но не смогут ручаться за это.

Краткое содержание статьи: Похоже, что Packbits дает вам лучшее время доступа (за счет дискового пространства), тогда как Deflate дает вам промежуточное / медленное время доступа для промежуточных / маленьких файлов. Кроме того, вы можете проверить время доступа более эмпирически, создав миниатюры разных размеров и времени, сколько времени это займет. Пример команды:time gdal_translate -outsize <thumbnail dimensions> -of GTiff <compressed image file> <thumbnail file>

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

Для операций чтения / записи вы можете проверить скорость этих операций с помощью system.time (). Вот некоторые результаты загрузки файла DEM в R (пакет Raster), переведенного в четыре формата (ASCII, IMG и TIF ​​без сжатия и Deflate). Например, на растре ~ 26 МБ:

> system.time(dem <- raster("~/workspace/TEMP/kideporegion.img"))
 user  system elapsed 
 0.154   0.002   0.157 

«Истек» показывает общее время (в секундах), затраченное на операцию Выполнение операций по 10 раз каждая и просмотр среднего времени:

              mean   diff
ASC         0.2237 0.3317
IMG         0.1544 0.0318
tif-Deflate 0.1510 0.0099
tif-none    0.1495 0.0000
tif-pack    0.1513 0.0118

TIFF без сжатия - самый быстрый ... за ним следуют Deflate (на 0,1% медленнее) и TIFF-Packbits (на 1,8% медленнее), затем IMG (на 3,2% медленнее) и ASC (на 33% медленнее). (Это на Macbook Pro 2,4 ГГц с SSD, поэтому быстрые операции с диском)

Это просто для загрузки файлов, а не манипулирования ими.

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

В любом случае, если вы собираетесь работать с растром в R, вы, вероятно, будете использовать пакеты rgdal и R ncdf для дополнения того, что содержится в пакете R растров . С основной опорой на gdalwarp . Нужно определить зависимости формата, чтобы сделать свой выбор растра. Вы найдете достаточное освещение в SO и на различных форумах / блогах / вики OSGEO и R.

Но так как это ГИС-форум, где использование Python находится в относительном порядке, я отмечу, что у работы с растровыми данными в массиве Python есть свои преимущества, с аналогичной зависимостью от библиотек gdal для загрузки, преобразования и экспорта растров. Некоторые люди считают, что управление памятью и структура кода в Python предпочтительнее нативного R - возможно, взгляните на RPy2 или PypeR, так как любой из них может подойти для вашего анализа.

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

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

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

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

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

GeoTIFF представляет собой набор 2D «изображений» или массивов. NetCDF - это хранилище общего назначения для многомерных массивов. Но если вы храните массивы таким же образом в netCDF, как и в GeoTIFF, вы получите такую ​​же производительность, более или менее.

Можно также переставить данные в netCDF, чтобы в принципе можно было оптимизировать их по шаблонам чтения. Я предполагаю, что большинство ГИС-приложений оптимизированы для 2D-разметки GeoTIFF, поэтому перегруппировка не принесет особой выгоды.

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

Я прочитал пару страниц об этом несколько лет назад и с тех пор использовал tiff со сжатием packbits, выложенный плиткой с заголовком geotiff, и был счастлив.

статья о команде arcpad

вики

Но после прочтения следующего я пересмотрю и, возможно, использую разновидность выкачивания.

Сайт Arcpad

Так много пакетов используют GDAL под капотом, например, rgdal, QGIS, GRASS и т. Д. Если бы я использовал один из этих пакетов, то я бы подумал о преобразовании своих изображений в vrt. Я часто видел, что рекомендуется, когда вам нужно использовать две команды GDAL, тогда промежуточный файл должен быть файлом vrt, потому что накладные расходы на чтение минимальны (например, http://www.perrygeo.com/lazy-raster-processing -с-GDAL-vrts.html ). Похоже, ваш рабочий процесс: конвертировать один раз и читать много раз. Может быть, VRT будет уместным.

[Изменить: ссылка настроена]