Швидкість різних форматів растрових даних

У мене виникають проблеми з розміщенням будь-якої дискусії або порівняльного тестування різних форматів растрових файлів (наприклад, для використання в аналізі даних на R). Хтось має уявлення про те, чому конкретні формати можуть бути швидшими чи повільнішими? Або різниці повинні бути мінімальними?

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

Ось моя стара стаття в блозі, яка розглядає розмір файлу та час доступу форматів. Я не досліджував швидкість запису, лише час доступу. Я б сказав, що вони, ймовірно, будуть безпосередньо пов’язані, але не зможуть поручитися за це.

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

Якщо припустити, що єдине, що має відношення до R у цьому випадку - це те, наскільки швидко він може прочитати дані з файлу, як і будь-який інший процес, то це повинно дати вам хорошу вказівку.

Для операцій читання / запису ви можете перевірити швидкість цих операцій за допомогою system.time (). Ось декілька результатів завантаження файлу DEM в R (пакет растрових), переведеного на чотири формати (ASCII, IMG і TIF без стиснення та зменшення рівня). Наприклад, на растрі ~ 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 / wiki.

Але оскільки це GIS-форум, де використання Python знаходиться в відносному висхідстві, я зазначу, що в роботі з растровими даними в масиві Python numpy є переваги, що мають схожу залежність від бібліотек gdal для завантаження, перетворення та експорту растра. Деякі люди вважають, що управління пам’яттю та структурою коду в Python є кращим перед рідним R - можливо, подивіться на RPy2 або PypeR, як це може бути доречним для вашого аналізу.

Велике питання полягає в тому, чи збираєтесь ви прочитати весь растр із файлу в пам'яті перед його обробкою, чи файл настільки великий, що ви будете його обробляти поступово, або обробляти якийсь підмножина загального файлу.

Якщо ви завантажите все це в пам'ять, тоді ви будете робити переважно послідовний доступ, а найшвидшим форматом буде перекидання між звичайним та стислим сховищем (залежно від речей, таких як швидкість вашого процесора проти диска). Будь-який із форматів бінарних файлів, ймовірно, буде досить близьким (ASCII буде повільніше).

Якщо вам потрібно обробити підмножину дуже великого файлу, формат, який групує підмножину, яку ви хочете зблизити, може бути швидшим - наприклад: плитки або формат, який може обчислювати компенсації. Іноді тут отримують нестиснені підходи, тому що обчислити там, де будь-яка задана частина зображення знаходиться у файлі, може бути тривіально, особливо якщо вам потрібна лише частина дуже великого рядка, але стиснення може бути виконане детально, що добре працює для деяких схеми доступу.

Вибачте, але вам, мабуть, доведеться орієнтуватись залежно від схеми доступу, а не отримувати єдиний розмір. Звичайно, це може залежати не тільки від формату файлу та вищезазначених факторів, але і від драйверів цього формату та вашого програмного забезпечення.

Те, як ви думаєте про подібні проблеми, полягає в тому, як ваша програма звертається до вашого файлу, порівняно з тим, як дані містяться у вашому файлі. Ідея полягає в тому, що якщо ви можете отримати доступ до своїх даних послідовно, це буде набагато ефективніше, ніж якщо ви отримуєте доступ до них випадковим чином.

GeoTIFF - це набір 2D "зображень" або масивів. NetCDF - це сховище загального призначення для багатовимірних масивів. Але якщо ви зберігаєте масиви таким же чином у netCDF, як вони є в GeoTIFF, ви отримаєте таку ж продуктивність, більш-менш.

Можна також переставити дані в netCDF, так що в принципі можна оптимізувати для вашої схеми читання. Я здогадуюсь, що більшість GIS-програм оптимізовані для макетів GeoTIFF 2D, тому їх не так багато, щоб отримати від перестановки.

Нарешті, я скажу, що це дійсно має значення лише тоді, коли у вас дуже великі файли, принаймні десятки мегабайт.

Я прочитав кілька сторінок про це кілька років тому і з тих пір використовував тифф з компресією packbits, оброблений плиткою із заголовком геотифа, і був щасливий.

стаття команди arcpad

вікі

Але прочитавши наступне, я перегляну і, можливо, використаю сорт дефляту.

Сайт Arcpad

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

[Редагувати: посилання скориговано]