24 votos

¿Inflación normal del tamaño del archivo con gdalwarp?

Después de usar gdalwarp para proyectar y alinear a la red (a través de -tap ) una serie de rásters, observé que los rásters de salida eran significativamente mayores que los rásters originales. Una búsqueda bastante exhaustiva en la web resultó este tema de Trac :

Frank Warmerdam explicó el motivo:

"Revisando detenidamente, la diferencia en el archivo en cuestión se debe a que gdal_translate utiliza la interfaz TIFFWriteScanline() para escribir el archivo de salida desde dentro de GTiffDataset::CreateCopy?(), y esto sólo escribe tanto de la 'tira' final del archivo como sea necesario para completar el área de la imagen. Pero gdalwarp pasa por la interfaz de blockio, que escribe la tira final completa, incluso la parte que se cae al final del archivo."

Este tema Trac es ~ 7 años de edad, sin embargo, y sé que algunos cambios en las utilidades GDAL, incluyendo gdalwarp se han hecho desde entonces. Me gustaría saber si el razonamiento anterior sigue siendo válido y si la inflación del tamaño de archivo que estoy viendo es "normal". La palabra "normal" aquí podría entenderse como sin sorpresas o esperado pero, lo que es más importante: ¿Hay algo que se pueda hacer para mitigar los efectos, es decir, reducir el tamaño del archivo raster de salida? A continuación se muestra una tabla de la inflación de tamaño de archivo que estoy experimentando.

Input File Size (bytes)     Output File Size (bytes)    Inflation
1437380431                  1698334217                   18%
1428001178                  1698334433                   19%
  41683165                   137036637                  228%

Los archivos TIFF de entrada se crearon en ArcGIS y, por tanto, tienen archivos Worldfiles, XML y DBF externos, pero éstos no compensan la diferencia de tamaño de los archivos. He aquí una muestra gdalwarp tal y como la he utilizado en todos estos casos; la ejecución real se ha llevado a cabo mediante una llamada Python subprocess ( subprocess.Popen ) :

$ gdalwarp -tap -tr 30 30 -t_srs "+proj=aea +lat_1=20 +lat_2=60 +lat_0=40 +lon_0=-96 +x_0=0 +y_0=0 +ellps=GRS80 +datum=NAD83 +units=m +no_defs" -co "COMPRESS=LZW" input_file.tif output_file.tif

Entiendo que en casos raros la compresión hace un archivo más grande, pero el efecto es el mismo sin la compresión LZW. Los ratios de la tabla son con compresión LZW.

41voto

Lucas Puntos 128

Es un tema bien conocido y de larga data que gdalwarp no maneja bien la compresión . La solución es gdalwarp sin compresión y luego gdal_translate con compresión.

Para evitar dos procesos largos, gdalwarp a VRT primero, es realmente rápido, luego gdal_translate con la opción -co compress=lzw.

es decir

$ gdalwarp -tap -tr 30 30 -t_srs "etc..." -of vrt input_file.tif output_file.vrt
$ gdal_translate -co compress=LZW output_file.vrt output_file.tif

Si utiliza GDAL 2x puede combinarlo en una sola operación escribiendo el VRT en /vsistdout y pasarlo a gdal_translate y especificando /vsistdin como entrada. Por ejemplo:

gdalwarp -q -t_srs EPSG:32611 -of vrt input_file.tif /vsistdout/ | gdal_translate -co compress=lzw  /vsistdin/ output_file.tif

i-Ciencias.com

I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X