Quel format et quels paramètres utiliser pour les photos aériennes dans QGIS?

Question suivante qui concernait davantage la gestion des antennes avec ArcGIS:

Format le plus efficace pour gérer la photographie aérienne pour visualisation uniquement

Il semble qu'il existe 2 options principales pour stocker / rééchantillonner / reprojeter des antennes, etc.:

1. JP2000 / JP2 / JPEG 2000 (récemment 5 codes pour la gestion GDAL)
2. ECW (ondelettes compressées ERDAS (.ecw))
3. tout autre que j'ai raté?

Ce que j'ai compris en fonction de la version de QGIS pour les deux, il faut généralement installer des bibliothèques supplémentaires. ECW a quelques limites - pour compresser les besoins d'achat de licence?

J'ai testé jpeg que je ne peux pas utiliser pour les gros fichiers (limitation de dimension max) et il est également lent avec des dimensions plus grandes.

La réponse doit contenir:

1. Qu'est-ce qui est disponible par défaut avec QGIS 2.0.1 desktop et / ou OSGEO?
2. Comment ça marche avec les gros fichiers - zoom avant / arrière (pyramides)?
   • 'est-ce que Creation Options - RESOLUTIONS for jp2 pyramids?

Sur la base des réponses de huckfinn, de quelques autres commentaires et de mes conclusions:

Le format gagnant est JPEG2000 (pourquoi et quelle version est mentionnée ci-dessous Pourquoi pas les autres )

Pourquoi pas les autres:

1. JPEG
   • Limitation de la taille et des dimensions des données (4 Go et 65500x65500)
   • pas de possibilité de pyramides (internes) = plus l'image est grande, plus il faut de temps pour l'afficher lors d'un panoramique / zoom avant / zoom arrière
2. GeoTIFF
   • Bon pour les grilles mais pour l'imagerie raster, il n'y a pas de compression avec perte efficace sauf JPEG = même problème que JPEG
3. ECW et M. SID
   • Vous avez besoin d'une licence spéciale pour pouvoir enregistrer dans ECW et Mr. SID - vous ne pouvez pas le faire par défaut avec GDAL (QGIS). Si vous avez une licence spéciale, vous n'avez probablement pas besoin de lire cette réponse car le traitement des images est votre pain quotidien (notre entreprise obtient généralement des images au format ECW de nos clients)
4. Serveur de base de données / carte
   • C'est certainement une bonne option si vous avez déjà un serveur de base de données / carte en cours d'exécution ou si vous savez au moins comment le faire facilement et rapidement. Dans ce cas, les données peuvent être enregistrées dans GeoTIFF ou autre chose et sont généralement envoyées au format JPEG à votre client - un navigateur Web ou un logiciel de bureau comme QGIS. Mais si vous n'avez pas de serveur et que vous voulez quelque chose de facile à charger / voir facilement des images dans QGIS, c'est trop compliqué.

POURQUOI JPEG2000:

Comme je l'ai posté dans ma question - GDAL fournit plus d'options pour enregistrer au format JPEG2000 mais comme indiqué sur le site Web de GDAL, aucun ne devrait être fourni dans la version par défaut de GDAL. J'ai essayé probablement 6 versions différentes de QGIS lors des tests et toutes avaient au moins une option JPEG2000 (sous Windows 7). Pour m'assurer que je suggère d'installer la version OSGeo4W (32 ou 64 bits) de QGIS et de vérifier dans le shell OSGeo4W si un code JPEG2000 est disponible. (sous Windows, il suffit d'exécuter le shell OSGeo4W à partir du menu Démarrer / programmes et d'y écrire la commande gdal_translate --formatsou gdalwarp --formats).

Dans toutes les versions de QGIS, j'ai essayé le code JP2OpenJPEG (bibliothèque OpenJPEG (v2)). Et après des tests plus longs, y compris d'autres, j'ai trouvé celui-ci le plus pratique.

Avantages de JP2OpenJPEG

• libre d'utiliser pour ouvrir / enregistrer
• pas de "petite" taille limite (peut certainement aller bien au-dessus de 65500x65500)
• compression très efficace (possibilité de définir%)
• inclut des pyramides (aperçus) pour une visualisation rapide (également possible de définir)

(options pour définir la compression ( -co QUALITY ), les pyramides ( -co RESOLUTIONS ) et quelques autres - http://www.gdal.org/frmt_jp2openjpeg.html )

Exemple simple de conversion dans QGIS en utilisant gdal_translate (dans QGIS, allez dans Raster / Converion / Translate , définissez tout ce dont vous avez besoin et cliquez éventuellement sur le bouton Modifier pour ajuster la commande en fonction de vos besoins):

gdal_translate -of JP2OpenJPEG -co QUALITY=10 srcGridOrImage image.jp2  

Pour le sujet 2: Voici une enquête plus longue sur JP2, car j'étais également intéressé, pour utiliser une compression plus efficace. Et le résultat IMO est: Dans GDAL / QGIS (en tant que QgsRastrerDataProvider), vous ne pouvez pas combiner d'une manière simple les options de compression jpeg2000 et de mise en cache rapide comme les ensembles de tuiles et les structures de blocs.

Normalement, je préfère GeoTiff pour Raster-DB, il est bien pris en charge par GDAL depuis longtemps et possède de nombreuses fonctionnalités pour vous faciliter la vie.

Vous pouvez trouver les capacités du pilote de données JP2 sur la page gdal. Pour vos besoins jp2k, le JPEG2000 (dépendances libjasper) est répertorié sur cette page: http://www.gdal.org/frmt_jpeg2000.html . Comme indiqué sur http://www.gdal.org/formats_list.html, le "pilote" prend en charge la lecture, l'écriture, est limité à 2 Go et intégré depuis GDAL version 1.9 et a quelques options de blocage ...

Donc, pour être sûr de ce qui est possible avec JP2, j'ai créé un jeu de test.

J'utilise de grandes photos aériennes pour détecter les oiseaux marins dans la mer Baltique avec une taille d'environ. 12000 par 10000 pixels (RVB) et une résolution au sol de 2 cm (j'espère qu'il est assez grand). J'ai actuellement 270 fichiers avec une capacité d'environ 130 Gio dans mon projet QGIS. Et cela fonctionne parfaitement sur un système d'exploitation Debian 7.0 Linux 64 bits avec des cœurs Opteron 8 Go et 4xAMD. ... mais avec GeoTiff.

Pour obtenir un accès rapide dans GIS-Tool, les images sont référencées et rééchantillonnées avec GDAL en utilisant les étapes et options suivantes (.. désolé pour le style de script bash):

Référencement de l'image avec les jeux de données du 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

Les variables $ [u | o] [l | r] [x | y] sont les coins de l'image donnée par le calcul photogrammétique et la variable $ wd est la largeur de l'image, $ hg la hauteur de l'image et $ cwd $ chg la Point central.

Déformez l'image avec des options de jeu de tuiles dans le monde réel:

    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

Les paramètres: --config GDAL_CACHEMAX 2000 -wm 2000 -wo NUM_THREADS = 4 indique au fer à repasser d'utiliser beaucoup de cache et quatre threads de processeur pour calculer la substance. Le rééchantillonnage se fait de manière bilinéaire et le système de coordonnées est UTM-32 .. mais je veux des tuiles de bloc 512x512, pour rendre les opérations de navigation (zoom, pan, point) rapides et fluides. Cela se fait par les options -co TILED = YES -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512.

Écrivez des pyramides dans le GeoTiff aux niveaux de zoom 2, 4, 8 et 16:

    gdaladdo -r gauss $geo_tif 2 4 8 16

Le GeoTiff résultant montré par gdalinfo est:

 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

Donc, dans GeoTiff, tout va bien! Si j'essaie de créer un JP2 avec une étape de conversation directe:

 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)

et ça échoue. Le message d'erreur peut vous donner un indice ou un autre format que vous pouvez utiliser.

L'essai avec l'outil gdal_translate vous donnera un JP2000 correct

 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

et le taux de compression est de 1: 8 mais nous perdons les propriétés du bloc et du jeu de tuiles comme indiqué par 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)

Le dernier test était d'utiliser le GeoTiff avec une compression JPEG interne mais on obtient:

 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.
  ....

Alors, où aller d'ici. La page lib du pilote JP2000 Jasper de GDAL répertorie certains paramètres pour créer l'image jp2000 avec des options de bloc:

 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.

mais la question est, laquelle utilisera qgis.

Pour la rubrique 1. QGIS utilise GDAL en tant que QgsRasterdataProvider. Ainsi, les capacités de lecture et d'écriture d'un format raster sont implémentées par la lib GDAL. Vous pouvez trouver un format pris en charge sous le lien suivant http://www.gdal.org/formats_list.html . La commande gdal-config --formats vous donne un aperçu des éléments de format à intégrer à votre bibliothèque ou édition. Ce qui est fourni par votre édition dépend de votre package, de votre système d'exploitation, etc. Pour plus d'informations, consultez http://trac.osgeo.org/gdal/wiki/BuildHints .