Perché il risultato dell'unione di più raster è così grande? [chiuso]


10

Cerco di unire 14 geotiff in questo modo:

inserisci qui la descrizione dell'immagine

Ogni geotiff è di circa 50 Mb. Ho bisogno di un geotiff in uscita

Il mio flusso di lavoro:

gdalbuildvrt -input_file_list list.txt test.vrt 

(dove la mia lista contiene il nome del tif)

Poi :

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

Funziona, ma il risultato è un geotiff di 13,3 Gb! Per 14 file, ciascuno da 50 Mb, ho tentato un geotiff di 700 Mb, non di 13 Gb.

So che gdal non si comprime per impostazione predefinita, quindi ho provato questo comando:

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

Ma la "fusione" del file è troppo grande per la compressione 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
...

Quindi ho provato un altro flusso di lavoro e ho convertito tutti i miei tif in jpeg (14 Mb ciascuno), ho creato un file vrt e tradotto con compressione LZW. Ma il geotiff di output è di circa 5 Gb.

Potresti dirmi qual è la migliore pratica per fare il lavoro, e se è possibile ottenere un geotiff di 14 * 50 Mb?

Non l'ho provato, ma ho pensato di unire questo tif in Photoshop, quindi ri-georeferenziazione con coordinate in alto a sinistra / in basso a destra. Con questo flusso di lavoro penso che avrò 14 * 50 Mb, ma non ne sono sicuro. E voglio imparare le migliori pratiche di gdal, quindi per il momento non l'ho provato


venendo ai morsi: se l'input è tif con 8 bit e l'esportazione è 32 bit per impostazione predefinita, si verificheranno seri problemi. quindi assicurati di mantenere la definizione dei byte così com'è. E ricorda: il tif completo sarà prob. avere 20x 50mb come un tiff è sempre rettangolare

Se ho capito, il numero che ho indicato in verde in questo screenshot deve essere lo stesso a sinistra e a destra?

bit

L'immagine di output avrà più pixel della somma delle immagini di input, ma ciò non spiega la grande differenza. Ti suggerisco di guardare le caratteristiche delle tue immagini in base a gdalinfo al fine di vedere quale compressione viene utilizzata e verificare che le estensioni siano corrette.

I 14 tif da 50 Mb erano originariamente 14 tif da 700 Mb che ho elaborato con gdal_translate con -co COMPRESS = JPEG. Ho compresso il raster per ridurre il numero di Mb, ma forse non è stata una buona idea?

Questo screenshot rappresenta le informazioni 2 gdal dello stesso geotiff (01.tif), a sinistra dello screenshot c'è la gdalinfo del Gtiff non compresso di 700 Mb, termina a destra lo stesso Gtiff con COMPRESS = JPEG, quindi 50 Mb, con il diff in verde:

non comprime e comprime gdalinfo del file 01.tif

Secondo me, le estensioni sono corrette perché in qgis corrisponde ad altre fonti di dati e immagini satellitari.

* supponendo che le tue immagini di input abbiano le stesse dimensioni, produce 20000 * 12000 pixel per immagini di input, che è grande per un'immagine di 50 Mb, forse stai attraversando l'estensione del tuo sistema di coordinate quando crei il mosaico. *

Non sono sicuro di capire cosa intendi per "attraversare l'estensione". Ma ho provato ad aprire il mio LZW da 5 GB in QGIS, e l'estensione è buona, perché corrisponde ad altre fonti di dati.

La tua risposta mi fa capire che Gtiff non ha le stesse dimensioni, pensi che potrebbe essere la causa dell'aumento delle dimensioni una volta unito? Perché gdal preferisce file della stessa dimensione. Ho creato un gdalinfo su ogni Gtiff per ottenere le sue dimensioni, c'è una differenza molto piccola tra le dimensioni di 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

Quindi dovresti guardare la profondità in pixel delle tue immagini: se il tuo input fosse in Byte,> allora dovresti conservare i byte. gdal_translate -of Gtiff -ot Byte -co COMPRESS = LZW test.vrt test.tif

Ho provato questo comando ma la gdal mi ha detto che la dimensione della tiff era stata superata.

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.

Ma se devo creare un grande tiff, non risolve il mio problema perché è più di 4 GB. La profondità dei pixel è importante nel mio caso? (Foto HD di mappe, quindi georeferenziate, non DEM)

Nota 1: Convertire le immagini in jpeg prima di creare un vrt non aiuta e potresti perdere dati.

Non è grave se perdo un po 'di informazioni. Preferisco non perderlo, ovviamente, ma se devo non è un problema. Ero convinto che l'output sarebbe più leggero se avessi lavorato con jpeg, ma come conclusione, non è vero quando l'output è Gtiff. Quindi questa non è una buona soluzione. Rinuncio a questa soluzione.

> Nota 2: usare un vrt è utile: sei sicuro di aver bisogno di GTiff?

Sì, ho bisogno di un Gtiff, perché devo importarlo in un'applicazione mobile che ha bisogno dell'input geotiff per funzionare (penso che l'app possa accettare anche l'input pdf geospaziale, ma non ci lavoro mai e voglio capire il mio problema con gdal, perché non è la prima volta che ce l'ho).


Ho provato -co piastrellato = sì -co bigtiff = sì -co compress = jpeg -co fotometrico = ycbcr e ho provato -co TILED = sì -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512

Questi 2 comandi funzionano bene, ho una dimensione di ~ 700 Mb. È esattamente quello che mi aspettavo.

Ora ho un altro problema: non può essere aperto rapidamente da QGIS. Devo aspettare 15 minuti (ma ho chiuso prima che QGIS aprisse correttamente il tif). Non so perché. E nella mia app Android, non funziona (forse causa di "piastrellato = sì"). Devo leggere alcuni documenti per conto mio.


Usa -co piastrellato = sì -co bigtiff = sì -co compress = jpeg -co fotometrico = ycbcr
user30184

Risposte:


2

L'immagine di output avrà più pixel della somma delle immagini di input, ma ciò non spiega la grande differenza. Ti suggerisco di guardare le caratteristiche delle tue immagini in base a gdalinfo al fine di vedere quale compressione viene utilizzata e verificare che le estensioni siano corrette. (supponendo che le tue immagini di input abbiano le stesse dimensioni, produce 20000 * 12000 pixel per immagini di input, che è grande per un'immagine di 50 Mb, forse stai attraversando l'estensione del tuo sistema di coordinate quando crei il mosaico.) Quindi dovresti guarda la profondità in pixel delle tue immagini: se il tuo input fosse in Byte, dovresti conservare i byte.

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

Nota 1: Convertire le immagini in jpeg prima di creare un vrt non aiuta (sarà decompresso prima del passaggio successivo) e potresti perdere dati.

Nota 2: usare un vrt è utile: sei sicuro di aver bisogno di GTiff?

EDIT: Non c'è miracolo con la dimensione delle tue immagini, ma dovresti usare un tif piastrellato come output in modo da poter usare la compressione jpeg con i tuoi dati di grandi dimensioni (-co TILED = yes -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512 ). Se rimane troppo grande, l'unica soluzione è quindi utilizzare gdalwarp per ricampionare a una risoluzione inferiore.


venendo ai morsi: se l'input è tif con 8 bit e l'esportazione è 32 bit per impostazione predefinita, si verificheranno seri problemi. quindi assicurati di mantenere la definizione dei byte così com'è. E ricorda: il tif completo sarà prob. avere 20x 50mb come un tiff è sempre rettangolare.
Riccardo

Da dove hai preso 20000 x 12000? L'output mostrato nella domanda suggerirebbe che l'immagine in ingresso è 79841 x 59955.
Evil Genius

79841, 59955 è la dimensione dell'input vrt. ma ci sono 5 righe e 4 colonne, quindi ho diviso ~ 80000 per 4 e ~ 60000 per 5. Come ho detto, questo presuppone che le immagini abbiano le stesse dimensioni e siano posizionate come nella figura.
Radouxju,

Ho risposto modificando la mia domanda originale, spero sia che devo procedere.
grimdaemon,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.