¿Por qué el resultado de la fusión de múltiples ráster es tan grande? [cerrado]


10

Intento fusionar 14 geotiff así:

ingrese la descripción de la imagen aquí

Cada geotiff es de unos 50Mb. Necesito un geotiff en la salida

Mi flujo de trabajo:

gdalbuildvrt -input_file_list list.txt test.vrt 

(donde mi lista contiene el nombre de los tifs)

Entonces :

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

Funciona, ¡pero el resultado es un geotiff de 13,3 Gb! Para 14 archivos, cada 50 Mb, intenté un geotiff de 700 Mb, no 13 Gb.

Sé que gdal no se comprime por defecto, así que probé este comando:

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

Pero la "fusión" del archivo es demasiado grande para la compresión 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
...

Así que probé otro flujo de trabajo y convertí todos mis archivos tif en jpeg (14 Mb cada uno), construí un archivo vrt y lo traduje con compresión LZW. Pero el geotiff de salida es de aproximadamente 5 Gb.

¿Podría decirme cuál es la mejor práctica para hacer el trabajo y si es posible obtener un geotiff de 14 * 50Mb?

No lo intenté, pero pensé en fusionar estos tifs en Photoshop, luego volver a georreferenciar con las coordenadas superior izquierda / inferior derecha. Con este flujo de trabajo, creo que tendré 14 * 50 Mb, pero no estoy seguro. Y quiero aprender las mejores prácticas de gdal, así que no lo intenté por el momento


llegando a las picaduras: si la entrada es tif con 8 bits y la exportación es de 32 bits por defecto, tendrá serios problemas. así que asegúrese de mantener su definición de bytes tal como está. Y recuerde: el tif completo será prob. tener 20x 50mb como tiff siempre es rectangular

Si entiendo, ¿el número que señalé en verde en esta captura de pantalla tiene que ser el mismo a la izquierda y a la derecha?

pedacitos

Su imagen de salida tendrá más píxeles que la suma de sus imágenes de entrada, pero esto no explica la gran diferencia. Le sugiero que mire las características de sus imágenes basadas en gdalinfo para ver qué compresión se usa y verifique que las extensiones sean correctas.

Los 14 tifs de 50 Mb eran originalmente 14 tifs de 700 Mb que procesé con gdal_translate con -co COMPRESS = JPEG. Comprimí el ráster para reducir la cantidad de Mb, pero ¿tal vez no fue una buena idea?

Esta captura de pantalla representa la información de 2 gdal del mismo geotiff (01.tif), a la izquierda de la captura de pantalla está el gdalinfo del Gtiff no comprimido de 700 Mb, finalice a la derecha el mismo Gtiff con COMPRESS = JPEG, por lo que 50 Mb, con la diferencia en verde:

no comprimir y comprimir gdalinfo del archivo 01.tif

Según yo, las extensiones son correctas porque en qgis coincide con otra fuente de datos e imágenes satelitales.

* suponiendo que sus imágenes de entrada tengan el mismo tamaño, genera 20000 * 12000 píxeles por imagen de entrada, que es grande para una imagen de 50 Mb, tal vez esté cruzando la extensión de su sistema de coordenadas cuando cree el mosaico. *

No estoy seguro de entender lo que quieres decir con "cruzar la extensión". Pero intenté abrir mi LZW de 5 Gb en QGIS, y la extensión es buena, porque coincide con otra fuente de datos.

Tu respuesta me hace darme cuenta de que los Gtiff no tienen el mismo tamaño, ¿crees que podría ser la causa del aumento del tamaño cuando se fusionan? Porque gdal prefiere un archivo del mismo tamaño. Hice un gdalinfo en cada Gtiff para obtener su tamaño, hay una diferencia muy pequeña entre el tamaño de 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

Luego, debe observar la profundidad de píxeles de sus imágenes: si su entrada estuviera en Bytes,> debería mantener los bytes. gdal_translate -of Gtiff -ot Byte -co COMPRESS = LZW test.vrt test.tif

Intenté este comando pero el gdal me dijo que se había excedido el tamaño del 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.

Pero si tengo que crear un gran tiff, no resuelve mi problema porque es más de 4 Gb. ¿La profundidad de píxeles es importante en mi caso? (Foto HD de mapas, luego georreferenciada, no DEM)

Observación 1: Convertir sus imágenes a jpeg antes de construir un vrt no ayuda y puede perder datos.

No es grave si pierdo un poco de información. Prefiero no perderlo, por supuesto, pero si tengo que hacerlo no es un problema. Estaba convencido de que la salida sería más ligera si trabajara con jpeg, pero como conclusión, no es cierto cuando la salida es Gtiff. Entonces esta no es una buena solución. Renuncio a esta solución.

> Observación 2: usar un vrt es útil: ¿estás seguro de que necesitas GTiff?

Sí, necesito un Gtiff, porque tengo que importarlo en una aplicación móvil que necesita entrada geotiff para funcionar (creo que la aplicación también puede tomar entrada geoespacial en PDF, pero nunca trabajo con él, y quiero entender mi problema con Gdal, porque no es la primera vez que lo tengo).


Intenté -co tiled = yes -co bigtiff = yes -co compress = jpeg -co photometric = ycbcr y probé -co TILED = yes -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512

Estos 2 comandos funcionan bien, tengo un tamaño de ~ 700 Mb. Es exactamente lo que esperaba.

Ahora tengo otro problema: QGIS no puede abrirlo rápidamente. Tengo que esperar 15 minutos (pero salí antes de que QGIS abra el tif con éxito). No se porque. Y en mi aplicación de Android, no funciona (tal vez por "mosaico = sí"). Tengo que leer algunos documentos por mi cuenta.


Use -co tiled = yes -co bigtiff = yes -co compress = jpeg -co photometric = ycbcr
user30184

Respuestas:


2

Su imagen de salida tendrá más píxeles que la suma de sus imágenes de entrada, pero esto no explica la gran diferencia. Le sugiero que mire las características de sus imágenes basadas en gdalinfo para ver qué compresión se usa y verifique que las extensiones sean correctas. (suponiendo que sus imágenes de entrada tengan el mismo tamaño, genera 20000 * 12000 píxeles por imagen de entrada, que es grande para una imagen de 50 Mb, tal vez esté cruzando la extensión de su sistema de coordenadas cuando cree el mosaico). Entonces debería mire la profundidad de píxeles de sus imágenes: si su entrada estaba en Bytes, entonces debería mantener bytes.

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

Observación 1: Convertir sus imágenes a jpeg antes de construir un vrt no ayuda (se descomprimirá antes del siguiente paso) y podría perder datos.

Observación 2: usar un vrt es útil: ¿estás seguro de que necesitas GTiff?

EDITAR: No hay milagro con el tamaño de sus imágenes, pero debe usar un tif en mosaico como salida para que pueda usar la compresión jpeg con sus datos grandes (-co TILED = yes -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512 ) Si sigue siendo demasiado grande, la única solución es usar gdalwarp para volver a muestrear a una resolución más baja.


llegando a las picaduras: si la entrada es tif con 8 bits y la exportación es de 32 bits por defecto, tendrá serios problemas. así que asegúrese de mantener su definición de bytes tal como está. Y recuerde: el tif completo será prob. tener 20x 50mb como tiff siempre es rectangular.
Riccardo

¿De dónde sacaste 20000 x 12000? El resultado que se muestra en la pregunta sugeriría que la imagen de entrada es 79841 x 59955.
Evil Genius

79841, 59955 es el tamaño de la entrada vrt. pero hay 5 filas y 4 columnas, así que dividí ~ 80000 por 4 y ~ 60000 por 5. Como dije, esto supone que las imágenes tienen el mismo tamaño y están posicionadas como en la figura.
radouxju

Respondí editando mi pregunta original, espero que sea así, tengo que continuar.
grimdaemon
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.