¿Qué formato y configuración usar para las fotos de antenas en QGIS?

10

Siguiente pregunta que era más sobre el manejo de antenas con ArcGIS:

El formato más efectivo para administrar fotografías aéreas solo para visualización

Parece que hay 2 opciones principales para almacenar / volver a muestrear / reproyectar, etc. antenas:

  1. JP2000 / JP2 / JPEG 2000 (recientemente 5 códigos para manejo de GDAL)
  2. ECW (ERDAS Compresas onduladas (.ecw))
  3. cualquier otro que me perdí?

formatos disponibles gdal

Lo que he entendido dependiendo de la versión de QGIS para ambos generalmente tiene que instalarse algunas bibliotecas adicionales. ECW tiene alguna limitación: ¿para comprimir necesita comprar una licencia?

Probé jpeg que no puedo usar para archivos grandes (limitación de dimensión máxima) y también es lento con dimensiones más grandes.

La respuesta debe contener:

  1. ¿Qué está disponible por defecto con el escritorio QGIS 2.0.1 y / o OSGEO?
  2. ¿Cómo funciona con archivos grandes: acercamiento / alejamiento (pirámides)?
    • Qué son las Opciones de creación - RESOLUCIONES para las pirámides jp2?
Miró
fuente
1
Solo el otro enfoque: grandes series de ortofoto a menudo se sirven como un servicio OGC WMS / WMTS con un proveedor de servicios de fondo como GeoServer o MapServer.
Jakob
2
GeoTIFF y NITF son comunes para las imágenes satelitales. También es compatible con GDAL, pero no estoy seguro de si QGIS es compatible con NITF.
BradHards
@Jakob: veo el punto. Pero aún así las imágenes deben guardarse de alguna manera en el servidor (en algún formato), ¿verdad?
Miro
@BradHards: Tiff fue mi primera opción, pero la única forma de guardarlo comprimido de manera efectiva es la compresión JPEG, que me lleva a la misma limitación de dimensiones máximas que si se guardara directamente en JPEG. La cuestión es que para las imágenes satelitales se necesita principalmente una compresión sin pérdidas. Pero esta pregunta se centra más en las fotos aéreas que pueden soportar algunas pérdidas en aras de guardar el enorme almacenamiento / transferencia de datos.
Miro

Respuestas:

8

Basado en las respuestas de huckfinn, algunos otros comentarios y junto con mis hallazgos:

El formato ganador es JPEG2000 (por qué y qué versión se menciona a continuación Por qué no otros )

¿Por qué no otros?

  1. JPEG
    • Limitación de tamaño, tanto tamaño de datos como dimensiones (4 GB y 65500x65500)
    • sin posibilidad de pirámides (internas) = ​​más grande es la imagen cuanto más tiempo se tarda en mostrarla cuando se desplaza / acerca / aleja
  2. GeoTIFF
    • Bueno para cuadrículas, pero para imágenes ráster no hay compresión con pérdida efectiva excepto JPEG = el mismo problema que JPEG
  3. ECW y el Sr. SID
    • Necesita una licencia especial para poder guardar en ECW y Mr. SID; no puede hacerlo de forma predeterminada con GDAL (QGIS). Si tiene una licencia especial, probablemente no necesite leer esta respuesta porque el procesamiento de imágenes es su pan de cada día (nuestra empresa generalmente obtiene imágenes en formato ECW de nuestros clientes)
  4. Servidor de bases de datos / mapas
    • Definitivamente es una buena opción si ya tiene algún servidor de bases de datos / mapas en ejecución o al menos sabe cómo hacerlo de manera fácil y rápida. En ese caso, los datos se pueden guardar en GeoTIFF o lo que sea y se envían generalmente como JPEG a su cliente: navegador web o software de escritorio como QGIS. Pero si no tiene un servidor y quiere algo fácil de cargar / ver imágenes fácilmente en QGIS, es demasiado complicado.

POR QUÉ JPEG2000:

Como publiqué en mi pregunta, GDAL ofrece más opciones para guardar en formato JPEG2000, pero como se indica en el sitio web de GDAL, no se debe proporcionar en la versión predeterminada de GDAL. Probablemente probé 6 versiones diferentes de QGIS durante las pruebas y todas tenían al menos una opción JPEG2000 (en Windows 7). Para asegurarme, sugiero instalar la versión OSGeo4W (32 o 64 bits) de QGIS y verificar en el shell OSGeo4W si hay algún código JPEG2000 disponible. (en Windows simplemente ejecute el shell OSGeo4W desde el menú de inicio / programas y escriba allí el comando gdal_translate --formatso gdalwarp --formats).

En todas las versiones de QGIS que probé había un código JP2OpenJPEG (biblioteca OpenJPEG (v2)) disponible. Y después de algunas pruebas más largas, incluidas otras, me pareció la más útil.

Ventajas de JP2OpenJPEG

  • de uso gratuito para abrir / guardar
  • sin límite de tamaño "pequeño" (definitivamente puede superar los 65500x65500)
  • Compresión muy efectiva (posible establecer%)
  • incluye pirámides (vistas previas) para una visualización rápida (también es posible configurar)

(opciones para configurar la compresión ( -co CALIDAD ), las pirámides ( -co RESOLUCIONES ) y algunas más: http://www.gdal.org/frmt_jp2openjpeg.html )

Ejemplo simple de conversión en QGIS usando gdal_translate (en QGIS vaya a Raster / Converion / Translate , configure lo que necesite y posiblemente haga clic en el botón editar para ajustar el comando para satisfacer sus necesidades):

gdal_translate -of JP2OpenJPEG -co QUALITY=10 srcGridOrImage image.jp2  
Miró
fuente
6

Para el tema 2: Aquí hay una investigación más larga de JP2, porque también estaba interesado, para usar una compresión más eficiente. Y el resultado IMO es: Dentro de GDAL / QGIS (como QgsRastrerDataProvider) no puede combinar la compresión adecuada jpeg2000 y las opciones de almacenamiento en caché rápido como conjuntos de mosaicos y estructuras de bloques de una manera simple.

Normalmente prefiero GeoTiff para Raster-DB's, está bien respaldado por GDAL desde hace mucho tiempo y tiene muchas características para facilitar la vida.

Puede encontrar las capacidades del controlador de datos JP2 en la página de gdal. Para sus necesidades jp2k, el JPEG2000 (dependencias de libjasper) se enumera en esta página: http://www.gdal.org/frmt_jpeg2000.html . Como se enumera en http://www.gdal.org/formats_list.html, el "controlador" admite lectura, escritura, está limitado a 2GiB y está integrado desde GDAL versión 1.9 y tiene algunas opciones de bloqueo ...

Entonces, para estar seguro de lo que es posible con JP2, he creado un conjunto de prueba.

Utilizo grandes fotos ariales para detectar aves marinas en el mar Báltico con un tamaño de ca. 12000 por 10000 píxeles (RGB) y una resolución de suelo de 2 cm (espero que sea lo suficientemente grande). Tengo actualmente 270 archivos con una capacidad de alrededor de 130 GiB en mi proyecto QGIS. Y funciona con fluidez y bien en un SO Linux Debian 7.0 de 64 bits con núcleos Opteron de 8GB y 4xAMD. ... pero con GeoTiff.

Para obtener un acceso rápido en la herramienta SIG, se hace referencia a las imágenes y se vuelven a muestrear con GDAL utilizando los siguientes pasos y opciones (... lo siento por el estilo de script bash):

Hacer referencia a la imagen con conjuntos de datos del gps-log:

    gdal_translate \
    -of GTiff \
    -gcp   0     0 $ulx   $uly \
    -gcp   0   $hg $llx   $lly \
    -gcp $cwd $chg $cpx   $cpy \
    -gcp $wd     0 $urx   $ury \
    -gcp $wd   $hg $lrx   $lry \
    -a_srs epsg:32632 \ 
    $raw_tif $ref_tif

Las variables $ [u | o] [l | r] [x | y] son ​​las esquinas de la imagen dada por el cálculo fotogramático y la variable $ wd es el ancho de la imagen, $ hg la altura de la imagen y $ cwd $ chg el punto central.

Deforma la imagen con las opciones de conjunto de mosaicos en el mundo real:

    gdalwarp \
    --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS=4 \
    -r bilinear -dstnodata '0 0 0' \
    -of GTiff \
    -t_srs epsg:32632 \
    -tr 0.02 0.02 \
    -co COMPRESS=LZW \
    -co TILED=YES \
    -co BLOCKXSIZE=512 \
    -co BLOCKYSIZE=512 \
    $ref_tif $geo_tif

Los parámetros: --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS = 4 le dice a la plancha que use mucho caché y cuatro hilos de procesador para calcular las cosas. El remuestreo se realiza por vía bilineal y el sistema de coordenadas es UTM-32 ... pero quiero bloques de bloques de 512x512, para que las operaciones de navegación (zoom, desplazamiento, punto) sean rápidas y fluidas. Esto se realiza mediante las opciones -co TILED = YES -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512.

Escriba las pirámides en el GeoTiff en los niveles de zoom 2,4,8 y 16:

    gdaladdo -r gauss $geo_tif 2 4 8 16

El GeoTiff resultante que muestra gdalinfo es:

 Driver: GTiff/GeoTIFF
 Files: CF006135.TIF
 Size is 12419, 9900
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 32N",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
             SPHEROID["WGS 84",6378137,298.257223563,
                 AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",9],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","32632"]]
Origin = (656099.007276594405994,5998980.139660121873021)
Pixel Size = (0.020000000000000,-0.020000000000000)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
  Upper Left  (  656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
  Lower Left  (  656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
  Upper Right (  656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
  Lower Right (  656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
  Center      (  656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)
Band 1 Block=512x512 Type=Byte, ColorInterp=Red
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 2 Block=512x512 Type=Byte, ColorInterp=Green
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619
Band 3 Block=512x512 Type=Byte, ColorInterp=Blue
 NoData Value=0
 Overviews: 6210x4950, 3105x2475, 1553x1238, 777x619

¡Así que en GeoTiff todo está bien! Si trato de crear un JP2 con un paso de conversación directa:

 gdalwarp -of jpeg2000 -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512 CF006135.TIF CF006135.jp2 
 Output driver `jpeg2000' not recognised or does not support
 direct output file creation.  The following format drivers are configured
 and support direct output:
   VRT: Virtual Raster
   GTiff: GeoTIFF
   NITF: National Imagery Transmission Format
   HFA: Erdas Imagine Images (.img)
   ELAS: ELAS
   MEM: In Memory Raster
   BMP: MS Windows Device Independent Bitmap
   PCIDSK: PCIDSK Database File
   ILWIS: ILWIS Raster Map
   SGI: SGI Image File Format 1.0
   Leveller: Leveller heightfield
   Terragen: Terragen heightfield
   netCDF: Network Common Data Format
   HDF4Image: HDF4 Dataset
   ISIS2: USGS Astrogeology ISIS cube (Version 2)
   ERS: ERMapper .ers Labelled
   RMF: Raster Matrix Format
   RST: Idrisi Raster A.1
   INGR: Intergraph Raster
   GSBG: Golden Software Binary Grid (.grd)
   PNM: Portable Pixmap Format (netpbm)
   ENVI: ENVI .hdr Labelled
   EHdr: ESRI .hdr Labelled
   PAux: PCI .aux Labelled
   MFF: Vexcel MFF Raster
   MFF2: Vexcel MFF2 (HKV) Raster
   BT: VTP .bt (Binary Terrain) 1.3 Format
   LAN: Erdas .LAN/.GIS
   IDA: Image Data and Analysis
   GTX: NOAA Vertical Datum .GTX
   NTv2: NTv2 Datum Grid Shift
   ADRG: ARC Digitized Raster Graphics
   SAGA: SAGA GIS Binary Grid (.sdat)

y falla Puede ser que el mensaje de error le dé una pista u otro formato que pueda usar.

La prueba con la herramienta gdal_translate le dará un JP2000 adecuado

 gdal_translate -of jpeg2000\
    -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
    CF006135.TIF CF006135.jp2

 ls -l 
 -rw-r--r-- 1 huckfinn huckfinn  63538529 Jan 28 23:55 CF006135.jp2
 -rw-r--r-- 1 huckfinn huckfinn       388 Jan 28 23:04 CF006135.jp2.aux.xml
 -rw-r--r-- 1 huckfinn huckfinn 519882980 Sep 30 21:01 CF006135.TIF

y la tasa de compresión es 1: 8 pero perdemos las propiedades del conjunto de bloques y mosaicos como se muestra en gdalinfo:

 gdalinfo CF006135.jp2 
 Driver: JPEG2000/JPEG-2000 part 1 (ISO/IEC 15444-1)
 Files: CF006135.jp2
        CF006135.jp2.aux.xml
 Size is 12419, 9900
 Coordinate System is:
 PROJCS["WGS 84 / UTM zone 32N",
     GEOGCS["WGS 84",
         DATUM["WGS_1984",
             SPHEROID["WGS 84",6378137,298.257223563,
                 AUTHORITY["EPSG","7030"]],
             AUTHORITY["EPSG","6326"]],
         PRIMEM["Greenwich",0],
         UNIT["degree",0.0174532925199433],
         AUTHORITY["EPSG","4326"]],
     PROJECTION["Transverse_Mercator"],
     PARAMETER["latitude_of_origin",0],
     PARAMETER["central_meridian",9],
     PARAMETER["scale_factor",0.9996],
     PARAMETER["false_easting",500000],
     PARAMETER["false_northing",0],
     UNIT["metre",1,
         AUTHORITY["EPSG","9001"]],
     AUTHORITY["EPSG","32632"]]
 Origin = (656099.007276594405994,5998980.139660121873021)
 Pixel Size = (0.020000000000000,-0.020000000000000)
 Metadata:
   AREA_OR_POINT=Area
 Corner Coordinates:
 Upper Left  (  656099.007, 5998980.140) ( 11d23'17.54"E, 54d 6'54.87"N)
 Lower Left  (  656099.007, 5998782.140) ( 11d23'17.17"E, 54d 6'48.47"N)
 Upper Right (  656347.387, 5998980.140) ( 11d23'31.21"E, 54d 6'54.60"N)
 Lower Right (  656347.387, 5998782.140) ( 11d23'30.84"E, 54d 6'48.20"N)
 Center      (  656223.197, 5998881.140) ( 11d23'24.19"E, 54d 6'51.54"N)

La última prueba fue utilizar GeoTiff con una compresión JPEG interna, pero obtenemos:

 gdalwarp -of GTiff \
  -co COMPRESS=JPEG \
  -co TILED=YES -co BLOCKSIZEX=512 -co BLOCKSIZEY=512\
  CF006135.TIF CF006135_IJPG.TIF
  Creating output file that is 12419P x 9900L.
  Warning 6: Driver GTiff does not support BLOCKSIZEX creation option
  Warning 6: Driver GTiff does not support BLOCKSIZEY creation option
  Processing input file CF006135.TIF.
  ....

Entonces, ¿a dónde ir desde aquí? La página lib del controlador JP2000 Jasper de GDAL enumera algunos parámetros para crear la imagen jp2000 con opciones de bloqueo:

 Encoding parameters, directly delivered to the JasPer library described in the JasPer documentation. Quoted from the docs:

``The following options are supported by the encoder:
imgareatlx=x    Set the x-coordinate of the top-left corner of the image area to x.
imgareatly=y    Set the y-coordinate of the top-left corner of the image area to y.
tilegrdtlx=x    Set the x-coordinate of the top-left corner of the tiling grid to x.
tilegrdtly=y    Set the y-coordinate of the top-left corner of the tiling grid to y.
tilewidth=w     Set the nominal tile width to w.
tileheight=h    Set the nominal tile height to h.
prcwidth=w  Set the precinct width to w. The argument w must be an integer  power of two. The default value is 32768.
prcheight=h     Set the precinct height to h. The argument h must be an integer power of two. The default value is 32768.
cblkwidth=w     Set the nominal code block width to w. The argument w must be an integer power of two. The default value is 64.
cblkheight=h    Set the nominal code block height to h. The argument h must be an integer power of two. The default value is 64.

pero la pregunta es, ¿cuál usará qgis?

huckfinn
fuente
1
Gracias, realmente aprecio esto. Mientras tanto, también hice mis propias pruebas. Como veo, JPEG2000 es el formato a seguir. Como mencioné antes, TIFF no debe usar porque solo puedo usar compresión JPEG (no JP2000), por lo que hay una limitación de tamaño. Usé el controlador (código) JP2OpenJPEG que está disponible en mi versión QGIS / GDAL y no tiene límite de tamaño. Y lo más importante es que tiene buenas opciones de creación, entre otras Resoluciones y TAMAÑO BLOQUEO * (ambos configurados con valores predeterminados razonables).
Miro
Gracias, esas son buenas noticias. Desafortunadamente, Debian Wheezy no es compatible con este controlador en este momento ... pero es bueno saber cuál de los muchos jp2000'ends es el correcto. -
huckfinn
5

Para el tema 1. QGIS usa GDAL como QgsRasterdataProvider. Entonces, las capacidades de lectura y escritura de un formato ráster son implementadas por la biblioteca GDAL. Puede encontrar un formato compatible en el siguiente enlace http://www.gdal.org/formats_list.html . El comando gdal-config --formats le da una visión general de qué formato está integrado en su lib o edición. Lo que proporciona su edición depende de su paquete, sistema operativo, etc. Para más información lea http://trac.osgeo.org/gdal/wiki/BuildHints .

huckfinn
fuente
Gracias por gdal-config --formats. Primera parte del rompecabezas hecha.
Miro
1
gdal-config --formats es solo para sistemas Unix. En Windows es posible hacer gdal_translate --formats o gdalwarp --formats para ver qué hay disponible.
Miro
Hm, eso es cierto gdal-config da a los compiladores de Unix un consejo para las deficiencias de la biblioteca. OK, eso no tiene sentido en Windows (cygwin o mingw exepted). Pero gdalinfo --format $ DRIVERNAME te da la información.
huckfinn