Чи слід налаштувати GDAL для створення файлів GeoTIFF із стисненням? Який алгоритм слід використовувати?


51

У мене є папка даних GIS, яка складається в основному з файлів GeoTIFF. Весь набір важить приблизно в 1.2 GB. Я помітив, що якщо я запакую вміст у тарбол, він розтрощиться до приблизно 82 MB. Я хотів би перевірити цей набір в системі керування ревізією, щоб над ним могли працювати інші люди, і, схоже, є якийсь простір, який можна вичавити.

На сторінці драйверів GDAL GeoTIFF перелічено безліч опцій, які можуть бути використані для створення стислих файлів GeoTIFF. Існує також безліч варіантів, які впливають на роботу кожного алгоритму.

Сторінка довідки добре описує параметри, але не пояснює, як вибрати алгоритм або компроміси, пов'язані з різним рівнем стиснення. Це призводить до наступних питань:

  • Плюси використання стиснення - це драматична економія простору. Які мінуси? Чи втрачається інформація при стисненні зображення?

  • Як слід піти про вибір алгоритму та рівня стиснення. Чи піддаються деякі типи зображень певним алгоритмом?

Відповіді:


85

Для вибору методу стиснення потрібно використовувати таку команду, як:

gdal_translate -co "COMPRESS=method" src_dataset dst_dataset

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

  • без втрат - які зберігають вихідні значення даних
  • втрата - які погіршують дані, щоб заощадити ще більше місця

Ви б не втратили алгоритми, коли потрібно зберегти вихідні значення даних, як DEM або растрові функції. Алгоритми, такі як PACKBITS , DEFLATE та LZW , без втрат і їх можна замовити відповідно до коефіцієнта стиснення:

  1. LZW - найвищий коефіцієнт стиснення, найвища потужність обробки
  2. ВИЗНАЧИТИ
  3. PACKBITS - найнижчий коефіцієнт стиснення, найменша потужність обробки

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

На відміну від втрат, ви б використовували алгоритми втрат, як JPEG, для стиснення растрових файлів, яким не потрібно повертати точні значення. Наприклад, ортофото або супутникові знімки можна стиснути за допомогою алгоритмів втрат.


5
+1 за гарну відповідь. PACKBITS - це форма кодування довжини пробігу ( en.wikipedia.org/wiki/Run-length_encoding ), яка буде добре працювати з даними з великою кількістю суміжних однакових значень (якщо, наприклад, у вас багато NULL або класифікований растр) і LZW - це більш надійний алгоритм, який ефективний для більшої кількості даних. Загальний компроміс - це між простором і швидкістю, як було зазначено, тому те, що підходить, залежить від використання та даних. Крім того, деяке програмне забезпечення не підтримує певні види стиснення GeoTiff.
scw

3
це хороший, відповідний пост linfiniti.com/2011/05/…
ойон

1
Хороша відповідь, вона добре підсумовує ваші варіанти. Пам'ятайте також, що кожен із цих методів стиснення має параметри, які ви можете встановити, що значно впливатиме на результат. @ j03lar50n, радий, що ти знайшов корисну мою статтю в блозі ...
R Thiede,

прекрасна відповідь! так просто і правильно.
sys49152

@scw Ви можете сказати більше про те, яке програмне забезпечення не підтримує певні типи стиснення, зокрема, чи є програмне забезпечення, яке не підтримує lzw або packbits? Або ви здебільшого маєте на увазі менш поширені алгоритми?
Девід Лебоуер

29

Використання lzwта deflateстиснення -co predictor=2може допомогти із зображеннями, які плавно змінюються, оскільки вони стискають відмінності від пікселя до пікселя замість абсолютних значень, і вони, як правило, будуть невеликими та матимуть більше шаблонів ( ref ). Провісник корисно тільки з lzwі deflateстиснення, опція не має ніякого ефекту з іншими методами.

gdal_translate -co compress=lzw -co predictor=2 ...

Економія прогнозів може бути драматичною. Я щойно повторно стиснув каталог 16-ти бітних моделей висоти геотифу, використовуючи до 17 ГБ з налаштуваннями LZW за замовчуванням, всього на 5 ГБ з прогнозкою = 2.

Існує суперечлива інформація про відмінності між предикторами 2 та 3 та коли найкраще застосовувати кожен ( ref1 , ref2 ). Можливо, пальне для іншого питання.

Ще один простий варіант заощадження - це -co tiled=yes. Є певне програмне забезпечення, яке не може читати кахельні зображення, але вони стають все рідшими і здебільшого поза межами ГІС (я не знаю жодного основного потоку ГІС-програмного забезпечення, яке їх не читає).

На основі відповіді @ alfonx використання стислих оглядів : Це дозволяє зберігати базове зображення без втрат, для цілісності даних, а піраміди - втрачати, для швидкості та економії місця. Це майже найкраще з обох світів. Для найменших оглядів з gdaladdoзображеннями на RGB: використовуйте стиснення jpeg, усереднене або гауссова перестановка замість найближчого сусіда за замовчуванням (робить огляди більш плавними) та фотометричний огляд YCBCR. Дивіться довідкову сторінку gdaladdo для отримання додаткової інформації про ці параметри (хоча це не дуже багато говорить про фотометричні).

Це частина пакетного файлу Windows, яку я використовую для застосування зовнішніх оглядів jpeg до всіх тифів у каталозі:

set _opts= -r gauss --config PHOTOMETRIC_OVERVIEW YCBCR ^
--config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 85

for %%a in (*.tif) do gdaladdo -ro %_opts% %%a 2 4 8 16 32 64

Примітки

GDAL 1.6.0 представив gaussперекомпонування, що може призвести до кращих результатів averageу разі гострих країв з високим контрастом або шумними малюнками. Потрібно використовувати повноваження 2 рівня (2 4 8 ...), щоб було вибрано ядро ​​Гаусса 3x3 перекомпонування.

JPEG_QUALITY_OVERVIEW 85 - якщо не вказано, використовується 75% за замовчуванням, що дає менший файл, але я вважаю, що на 85% кращий компроміс у розмірі порівняно з якістю торгується.

Оновлення, 2015: GDAL 1.8 і 2.0 ввели багато нових варіантів, які тут не висвітлюються, і які я не встиг перетравити. Прочитайте офіційну сторінку формату gtiff , я впевнений, що є додаткові корисні налаштування, детально описані.


10

Для великих растерів GeoTiff пропонує можливість зберігати (попередньо) огляди зменшеного масштабу як додаткові зображення у файл GeoTiff. Це можна зробити за допомогою gdaladdo (= Огляд GDAL ADD). Створюючи ці огляди, ви можете вручну сказати gdal, щоб їх також стиснути:

gdaladdo --config COMPRESS_OVERVIEW JPEG 

Прискорює перегляд даних, не додаючи занадто великого розміру. Примітка. Такі програми Geotools, як Geoserver, uDig, AtlasStyler, Geopublisher, можуть використовувати цю функцію та отримувати прибуток від оглядів.



4

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

Я широко використовував стиснуті JPEG GeoTIFF-файли через формати на основі вейвлетів. Мої результати були досить хорошими. Використання GDAL для цього дало коефіцієнти стиснення, порівнянні з форматами на основі вейвлет, без надто великої втрати даних. Хіт продуктивності, який поставляється з декомпресією, був прийнятним.

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


3

Мій досвід порівнювання стиснення ECW ( Enhanced Compression Wavelet ) GeoTIFF та Earth Resource Mapping - це те, що ECW на порядок краще на стискання повітряних фотографій високої роздільної здатності. Ще одна важлива перевага компресії на основі вейвлетів полягає в тому, що на відміну від старих форматів, таких як GeoTIFF, JPEG - а не JPEG 2000 -, лише частина зображення може бути декомпресована [див. 1]. Важливість цієї переваги не варто недооцінювати, особливо при роботі з "більшим приблизно від половини розміру пам'яті комп'ютера."

Здається - я ніколи не мав шансу тестувати це - що MrSID , інший пропітерний формат файлів на основі вейвлетів, також демонструє більш високі коефіцієнти стиснення, ніж "старіші" формати та селективну декомпресію.

реф. 1: http://www.ifp.uni-stuttgart.de/publications/phowo01/Ueffing.pdf


1
dariapra, пам’ятай, що GeoTIFF-Packbits або GeoTIFF-LZW - стискання без втрат, тоді як ECW та JPEG - втрати. Стиснення без втрат або втрат потрібно обережно вибирати залежно від майбутнього використання даних.
markusN

1
Я не претендую на те, що формат стиснення в стилі завжди є дійсним форматом зберігання. Що я хотів би мати на увазі, що використання такого формату, як ECW, підходить у деяких виробничих середовищах. Наприклад, ECW є більш підходящим форматом, ніж GeoTIFF, якщо у нас є екземпляр MapServer, який обслуговує ортофото шари через WMS. Ніщо не забороняє також зберігати ортофото, використовуючи стиснення без втрат.
dariapra

3

Відповіді @dodobas та @ matt-wilkie охоплюють більшість всього, що стосується актів стиснення та розмивання за допомогою GDAL для зменшення розміру зображення.

Я хотів би додати дві речі:

  • документація файлового формату від GDAL: http://www.gdal.org/frmt_gtiff.html ;
    • Дивіться параметри створення ( -co), зокрема:
      • COMPRESS
      • NUM_THREADS
      • PREDICTOR
      • ZLEVEL
  • і що важливо переконатися, що програмне забезпечення, яке споживає GeoTIFF:
    • підтримує потрібний метод стиснення;
    • рекомендує використовувати стиснення.

Наприклад, GeoServer не рекомендує стискати GeoTIFF :

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

Це особливо актуально, якщо вже використовуються оглядові, плиткові та високопродуктивні носії інформації (корпоративний диск або SSD).


Мені також потрібно стиснути своє зображення jpeg, оскільки я не в змозі перетворити свій растровий масив на gdalin Python. Він показує помилку пам'яті, а також іноді поза пам'яттю. Хтось може мати якусь ідею, як я можу реалізувати цю лінію (gdal_translate -co "COMPRESS = метод" src_dataset dst_dataset) у python. Я новачок у використанні gdal. Отже, мені часом важко зрозуміти структуру.
Шиулі Первін

1
@ShiuliPervin, По-перше, JPEG - це вже стислий (втрачений) формат. По-друге, це здається, що у вас виникли проблеми, а не стиснення. Прочитайте файл у плитках, смужках або фрагменті, а не відразу відразу. Навіть якщо файл стиснений, його потрібно буде нестискати, коли ви його використовуєте (наприклад: якщо 4 Гб файли використовують 2 Гб на диску при стисненні, він все одно займе 4 ГБ оперативної пам’яті, коли він завантажений для обробки. Як альтернатива економії місця, можливо, ви захочете вивчити стисне форматування для GeoTIFF .
Кевін,

1
@ShiuliPervin, Хоча, можливо, я неправильно розумію ваше запитання. Сама компресія часто використовує багато пам’яті, але не повинна переповнювати вашу систему, якщо тільки в бібліотеці немає помилок або вам не присвоєно недійсний аргумент. Якщо у вас є проблеми з JPEG як типом стиснення для GeoTIFF, можливо, спробуйте LZMA або DEFLATE.
Кевін

0

Для тих, хто використовує новіші версії GDAL, також є можливість стиснення ZStandard ( ZSTD ) без втрат (GDAL> = 2.3) та втрата з обмеженою компресією Raster Raster Compression ( LERC ) (GDAL> = 2.4).

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

Якщо ви не так метушитеся щодо точності даних (наприклад, ви робите лише візуалізацію, а не аналіз), то це LERCможе бути хорошим варіантом. Існує MAX_Z_ERRORнастройка, яка дозволяє налаштувати, на яку точність ви готові пожертвувати. Наприклад, розміром MAX_Z_ERROR=0.0011 або 1 мм, економія місця склала 50% на одному орієнтирі (див. Посилання ).

Найкраще, що ви також можете поєднувати LERCз ZSTDвикористанням COMPRESS=LERC_ZSTD! Або якщо ви віддаєте перевагу користуванню DEFLATE, можете зробити COMPRESS=LERC_DEFLATE. Дивіться також повний перелік комбінацій / налаштувань на офіційних документах GDAL GeoTIFF https://gdal.org/drivers/raster/gtiff.html#creation-options

Більш детальну інформацію та повні порівняння можна порівняти з цією посиланням:

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.