Чому результат злиття декількох растрових настільки великий? [зачинено]


10

Я намагаюся об'єднати 14 геотифів так:

введіть тут опис зображення

Кожен геотиф приблизно 50Mb. Мені потрібен геотиф на виході

Мій робочий процес:

gdalbuildvrt -input_file_list list.txt test.vrt 

(де мій список містить ім'я tifs)

Тоді :

gdal_translate -of Gtiff test.vrt test.tif
Input file size is 79841, 59955

Це працює, але результат - геотиф 13,3 Гбіт! Для 14 файлів, кожні 50 Мб, я спробував геотіф 700 Мб, а не 13 Гбіт.

Я знаю, що gdal не стискається за замовчуванням, тому я спробував цю команду:

gdal_translate -of Gtiff -co COMPRESS=JPEG test.vrt test_compressed.tif

Але "злиття" файлу занадто велике для стиснення JPEG:

Input file size is 79841, 59955
0ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: JPEGPreEncode:Strip/tile too large for JPEG
ERROR 1: WriteEncodedTile/Strip() failed.
ERROR 1: An error occured while writing a dirty block
...

Тож я спробував ще один робочий процес і перетворив всі мої тифи в jpeg (14 Мб кожен), створив файл vrt і перевів його на стиснення LZW. Але вихідний геотиф становить приблизно 5 Гб.

Чи можете ви сказати мені, яка найкраща практика виконувати цю роботу, і чи можливо отримати один геотиф 14 * 50 Мб?

Я не пробував цього, але подумав про об'єднання цих тифів у Photoshop, а потім повторну геореференцію з верхньою лівою / нижньою правою координатами. З цим робочим процесом я думаю, що у мене буде 14 * 50 Мб, але я не впевнений. І я хочу навчитися найкращим практикам gdal, тому на даний момент не спробував


прийдеш до укусів: якщо введення тиф з 8 біт, а експорт за замовчуванням 32 біт, ви отримаєте серйозні проблеми. тому переконайтеся, що ви дотримуєтеся байтового визначення таким, яким воно є. І пам’ятайте: повний тиф буде намагатися. мати 20х 50 мб, оскільки тиф завжди прямокутний

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

біт

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

14 тифів об'ємом 50 Мб спочатку були 14 тифів 700 Мб, які я обробляв gdal_translate за допомогою -co COMPRESS = JPEG. Я стиснув растр, щоб зменшити кількість Мб, але, можливо, це була не дуже добра ідея?

Цей скріншот відображає інформацію 2 gdal того ж геотифа (01.tif), зліва від скріншоту - gdalinfo нестисненого Gtiff 700 Мб, кінець праворуч той самий Gtiff з COMPRESS = JPEG, так 50 Мб, з різницею зеленого кольору:

не стискати та стискати gdalinfo файлу 01.tif

На мою думку, розширення є правильними, оскільки в qgis він співпадає з іншими джерелами даних та супутниковими знімками.

* якщо припустити, що ваші вхідні зображення мають однаковий розмір, він складає 20000 * 12000 пікселів на вхідні зображення, що є великим для зображення 50 Мб, можливо, ви перетинаєте ступінь вашої системи координат при створенні мозаїки. *

Я не впевнений, що розумію, що ви маєте на увазі під "переступом міри". Але я намагався відкрити свої 5 Gb LZW в QGIS, і ступінь хороша, тому що вона співпадає з іншими джерелами даних.

Ваша відповідь дає мені зрозуміти, що Gtiff не мають однакового розміру, ви вважаєте, що це може бути причиною збільшення розміру при злитті? Тому що gdal віддає перевагу файлу однакового розміру. Я зробив gdalinfo для кожного Gtiff, щоб отримати його розмір, між розмірами Gtiff є дуже мала різниця:

02.tif Size is 19956, 11981
03.tif Size is 19959, 11993
04.tif Size is 19961, 11992
05.tif Size is 19958, 11993
06.tif Size is 19958, 11990
07.tif Size is 19956, 11984
08.tif Size is 19956, 11993
09.tif Size is 19958, 11993
10.tif Size is 19958, 11989
11.tif Size is 19958, 11985
12.tif Size is 19958, 11993
13.tif Size is 19959, 11993
14.tif Size is 19960, 11994

Тоді слід переглянути глибину пікселів ваших зображень: якщо ваш вхід знаходився в байтах,> тоді ви повинні тримати байти. gdal_translate -of Gtiff -ot Byte -co COMPRESS = LZW test.vrt test.tif

Я спробував цю команду, але gdal сказав мені, що розмір tiff перевищений.

Input file size is 79841, 59955
0...10...20...30...40...50..ERROR 1: TIFFAppendToStrip:Maximum TIFF file size exceeded. Use BIGTIFF=YES creation option.
ERROR 1: WriteEncodedTile/Strip() failed.

Але якщо мені доведеться створити великий тиф, це не вирішить мою проблему, оскільки це більше 4 Гбіт. Чи важлива глибина пікселів у моєму випадку? (HD фотографій карт, то геореференційне, а не DEM)

Зауваження 1: Перетворення зображень у jpeg перед побудовою саду не допомагає, і ви можете втратити дані.

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

> Зауваження 2: використання саду корисно: ви впевнені, що вам потрібен GTiff?

Так, мені потрібен Gtiff, тому що я повинен імпортувати його в мобільний додаток, для якого потрібен геотифний ввід (я думаю, що додаток може приймати геопросторовий pdf-вхід, але я ніколи з ним не працюю, і я хочу зрозуміти свою проблему з gdal, тому що це не перший раз у мене є).


Я спробував -co плитковий = так -co bigtiff = так -co компрес = jpeg -co фотометричний = ycbcr, і я спробував -co ПЛОСЛЕНО = так -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512

Ці 2 команди добре працюють, у мене розмір ~ 700 Мб. Це саме те, чого я очікував.

Тепер у мене є ще одна проблема: її не можна швидко відкрити QGIS. Мені потрібно почекати 15 хвилин (але я кину, перш ніж QGIS успішно відкриє тиф). Я не знаю чому. І в моєму додатку для android це не працює (можливо, причина "плитка = так"). Я повинен прочитати якийсь документ самостійно.


Використовуйте -co tiled = так -co bigtiff = так -co компрес = jpeg -co фотометричний = ycbcr
користувач30184

Відповіді:


2

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

gdal_translate -of Gtiff -ot Byte -co COMPRESS=LZW test.vrt test.tif 

Зауваження 1: Перетворення ваших зображень у jpeg перед побудовою саду не допоможе (воно буде нестисненим до наступного кроку), і ви можете втратити дані.

Зауваження 2: використання саду корисно: ви впевнені, що вам потрібен GTiff?

EDIT: Немає дива з розмірами ваших зображень, але ви повинні використовувати плитку tif як вихід, щоб ви могли використовувати компресію jpeg з великими даними (-co TILED = так -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512 ). Якщо вона залишається занадто великою, єдиним рішенням є використання gdalwarp для повторної вибірки з меншою роздільною здатністю.


прийдеш до укусів: якщо введення тиф з 8 біт, а експорт за замовчуванням 32 біт, ви отримаєте серйозні проблеми. тому переконайтеся, що ви дотримуєтеся байтового визначення таким, яким воно є. І пам’ятайте: повний тиф буде намагатися. мати 20х 50 мб, оскільки тиф завжди прямокутний.
Ріккардо

Звідки ти взяв 20000 х 12000? Вихідні дані, що відображаються у запитанні, дозволять запропонувати вхідне зображення 79841 x 59955.
Evil Genius

79841, 59955 - розмір вхідного саду. але є 5 рядків і 4 стовпчики, тому я розділив ~ 80000 на 4 і ~ 60000 на 5. Як я вже сказав, це передбачає, що зображення мають однаковий розмір і розміщуються як на малюнку.
radouxju

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