GDAL doit-il être configuré pour produire des fichiers GeoTIFF avec compression? Quel algorithme devrait être utilisé?


51

J'ai un dossier de données SIG constitué principalement de fichiers GeoTIFF. L'ensemble entier pèse environ 1.2 GB. J'ai remarqué que si j'emballe le contenu dans une archive, elle s'écrase à peu près 82 MB. Je voudrais vérifier l'ensemble dans un système de contrôle de révision pour qu'il puisse être travaillé par d'autres personnes et il semble qu'il y ait un espace qui peut être réduit.

La page du pilote GDAL GeoTIFF répertorie de nombreuses options pouvant être utilisées pour créer des fichiers GeoTIFF compressés. Il existe également de nombreuses options qui affectent le fonctionnement de chaque algorithme.

La page d’aide décrit bien les options, mais n’indique pas comment sélectionner un algorithme ni les compromis associés au niveau de compression variable. Cela conduit aux questions suivantes:

  • Les avantages de la compression sont une économie d'espace considérable. Quels sont les inconvénients? Des informations sont-elles perdues lorsque l'image est compressée?

  • Comment choisir un algorithme et un niveau de compression? Certains types d'images se prêtent-ils à un certain algorithme?

Réponses:


86

Pour sélectionner la méthode de compression, vous devez utiliser une commande telle que:

gdal_translate -co "COMPRESS=method" src_dataset dst_dataset

Lorsque vous utilisez la compression, le meilleur compromis est le temps de traitement supplémentaire nécessaire pour décompresser l'image. Après décompression, l'image consommerait toujours la même quantité de mémoire. À propos de la perte d’information, il existe deux types de compression de base :

  • sans perte - qui préserve les valeurs de données d'origine
  • avec pertes - qui dégradent les données pour économiser encore plus d'espace

Vous utiliserez des algorithmes sans perte lorsque les valeurs de données d'origine doivent être préservées, telles que les MNA ou les entités raster. Des algorithmes tels que PACKBITS , DEFLATE et LZW sont sans perte et peuvent être commandés en fonction du taux de compression:

  1. LZW - taux de compression le plus élevé, puissance de traitement la plus élevée
  2. DÉGONFLER
  3. PACKBITS - taux de compression le plus bas, puissance de traitement la plus faible

Le taux de compression dépend toujours des données. Si les données ont beaucoup de valeurs similaires, PACKBITS donnera de bons résultats.

Contrairement à sans perte, vous utiliseriez des algorithmes avec perte comme JPEG pour compresser les rasters qui ne doivent pas renvoyer de valeurs exactes. Par exemple, les orthophotos ou les images satellites peuvent être compressées à l'aide d'algorithmes avec perte.


5
+1 pour la bonne réponse. PACKBITS est une forme de codage de longueur d'exécution ( en.wikipedia.org/wiki/Run-length_encoding ) qui fonctionnera bien pour les données avec beaucoup de valeurs identiques adjacentes (si, par exemple, vous avez beaucoup de NULL ou un raster classifié) et LZW est un algorithme plus robuste qui est efficace sur plusieurs types de données. Le compromis général est entre l'espace et la vitesse, comme mentionné, de sorte que ce qui est approprié dépend de votre utilisation et de vos données. En outre, certains logiciels ne prennent pas en charge certains types de compression GeoTiff.
scw

3
C'est un bon message pertinent. linfiniti.com/2011/05/…
oeon

1
Bonne réponse, cela résume bien vos options. N'oubliez pas non plus que chacune de ces méthodes de compression dispose de paramètres que vous pouvez définir, ce qui influera considérablement sur le résultat. @ j03lar50n, heureux que vous avez trouvé mon article de blog utile ...
R Thiede

belle réponse! si simple et droit au but.
sys49152

@scw pourriez-vous en dire plus sur les logiciels qui ne prennent pas en charge certains types de compression - en particulier, existe-t-il un logiciel qui ne prend pas en charge Lzw ou Packbits? Ou faites-vous principalement référence à des algorithmes moins courants?
David LeBauer

29

L' utilisation de la compression lzwet de la deflatecompression -co predictor=2peut aider à obtenir des images qui varient doucement, car elles réduisent les différences de pixel en pixel au lieu des valeurs absolues. Celles-ci auront tendance à être petites et à présenter davantage de motifs ( ref ). Predictor seulement utile avec lzwet la deflatecompression, l'option n'a pas d' effet avec d' autres méthodes.

gdal_translate -co compress=lzw -co predictor=2 ...

Les économies prévisionnelles peuvent être dramatiques. Je viens de recompresser un répertoire de modèles d'élévation géotiff 16 bits en utilisant jusqu'à 17 Go avec les paramètres par défaut de LZW dans seulement 5 Go avec un prédicteur = 2.

Il y a d' informations contradictoires sur les différences entre les prédicteurs 2 et 3 et quand chacun est mieux appliqué ( ref1 , ref2 ). Peut-être du carburant pour une autre question.

Une autre option facile pour économiser est -co tiled=yes. Il existe certains logiciels qui ne peuvent pas lire les images en mosaïque, mais ceux-ci deviennent de plus en plus rares et la plupart du temps en dehors des SIG (je ne connais aucun logiciel SIG de flux principal qui ne les lis pas).

Pour donner suite à la réponse de @ alfonx qui consiste à utiliser des vues d' ensemble compressées : Cela permet de stocker l'image de base sans perte pour l'intégrité des données et les pyramides avec perte, pour la vitesse et un gain de place réduit. C'est presque le meilleur des deux mondes. Pour les aperçus les plus petits possibles avec gdaladdodes images RVB: utilisez la compression jpeg, le rééchantillonnage moyen ou gaussien à la place du plus proche voisin par défaut (rend les aperçus plus lisses) et l'aperçu photométrique YCBCR. Voir la page de référence de gdaladdo pour plus d’informations sur ces options (bien qu’elle ne dise pas grand-chose de ce qu’est la photométrie).

Cela fait partie d'un fichier batch Windows que j'utilise pour appliquer des aperçus JPEG externes à tous les tiffs d'un répertoire:

set _opts= -r gauss --config PHOTOMETRIC_OVERVIEW YCBCR ^
--config COMPRESS_OVERVIEW JPEG --config JPEG_QUALITY_OVERVIEW 85

for %%a in (*.tif) do gdaladdo -ro %_opts% %%a 2 4 8 16 32 64

Remarques

GDAL 1.6.0 a introduit le gaussré-échantillonnage qui peut donner de meilleurs résultats averageen cas d’arêtes vives avec un contraste élevé ou des motifs bruyants. Des puissances de 2 niveaux (2 4 8 ...) doivent être utilisées pour sélectionner un noyau gaussien rééchantillonnant 3x3.

JPEG_QUALITY_OVERVIEW 85 - si non spécifié, la valeur par défaut de 75% est utilisée, ce qui produit un fichier plus petit, mais je trouve que 85% est un meilleur compromis entre la taille et la qualité.

Mise à jour 2015: GDAL 1.8 et 2.0 ont introduit un grand nombre de nouvelles options non couvertes ici et que je n'ai pas eu le temps de digérer. Lisez la page officielle du format gtiff , je suis sûr que d’autres paramètres utiles sont détaillés.


10

Pour les grands rasters, GeoTiff offre la possibilité de stocker des aperçus pré-réduits en tant qu'images supplémentaires dans le fichier GeoTiff. Cela peut être fait avec gdaladdo (= Vue d'ensemble de GDAL ADD). Lors de la création de ces aperçus, vous pouvez indiquer manuellement à gdal de les compresser également:

gdaladdo --config COMPRESS_OVERVIEW JPEG 

Accélère l'affichage de vos données sans ajouter trop de taille. Remarque: les applications Geotools telles que Geoserver, uDig, AtlasStyler et Geopublisher peuvent toutes utiliser cette fonctionnalité et tirer parti des aperçus.



4

En fin de compte, vous devrez probablement expérimenter différentes options et voir ce qui répond à vos besoins.

J'utilise de plus en plus de GeoTIFF compressés en JPEG sur des formats basés sur des ondelettes. Mes résultats ont été plutôt bons. L'utilisation de GDAL à cette fin a permis d'obtenir des taux de compression comparables aux formats basés sur des ondelettes sans trop de perte de données. Les résultats obtenus avec la décompression sont acceptables.

Ce que j'aime le plus dans cette approche est que le support de GeoTIFF est presque universel, alors que le support des formats basés sur des ondelettes n'est pas toujours garanti et est parfois sujet à des problèmes de licence épineux.


3

Mon expérience de la comparaison entre la compression ECW ( Enhanced Compressed Wavelet ) de Earth Resource Mapping de GeoTIFF et celle de Earth Resource Mapping est que ECW est bien mieux ordonné lors de la compression de photos aériennes à haute résolution. Un autre avantage important de la compression basée sur les ondelettes est que, contrairement aux formats plus anciens tels que GeoTIFF, JPEG - et non JPEG 2000 -, une partie seulement de l'image peut être décompressée [réf. 1]. L’importance de cet avantage ne doit pas être sous-estimée, en particulier lorsque vous travaillez avec "plus de la moitié de la taille de la mémoire de votre ordinateur".

Il semble - je n’ai jamais eu la chance de le tester - que MrSID , un autre format de fichier basé sur des ondelettes, propose également des taux de compression plus élevés que les formats "anciens" et une décompression sélective.

réf. 1: http://www.ifp.uni-stuttgart.de/publications/phowo01/Ueffing.pdf


1
dariapra, rappelez-vous que GeoTIFF-Packbits ou GeoTIFF-LZW sont des compressions sans perte, tandis que ECW et JPEG entraînent des pertes. La compression sans perte ou avec perte doit être soigneusement choisie en fonction de l'utilisation future des données.
MarkusN

1
Je ne prétends pas qu'un format de compression souple est toujours un format de stockage valide. Ce que je voulais dire, c’est que l’utilisation d’un format tel que ECW convient à certains environnements de production. Par exemple, ECW est un format plus approprié que GeoTIFF si nous avons une instance MapServer servant des couches ortophoto via WMS. Rien n'interdit que vous stockiez également l'ortophoto en utilisant une compression sans perte.
dariapra

3

Les réponses de @dodobas et @ matt-wilkie couvrent presque tout ce qui concerne les actions de compression et de flou avec GDAL pour réduire la taille de l'image.

Je voudrais ajouter deux choses:

  • la documentation au format fichier de GDAL: http://www.gdal.org/frmt_gtiff.html ;
    • Voir les options de création ( -co), en particulier:
      • COMPRESS
      • NUM_THREADS
      • PREDICTOR
      • ZLEVEL
  • et qu'il est essentiel de vérifier que le logiciel qui consommera les GeoTIFF:
    • prend en charge la méthode de compression souhaitée;
    • recommande d'utiliser la compression.

Par exemple, GeoServer ne recommande pas de compresser les GeoTIFF :

Pour terminer, Geotiff prend en charge divers types de compression, mais nous suggérons de ne pas l’utiliser. Bien que cela permette de réduire considérablement le nombre de fichiers, le processus de décompression est coûteux et sera effectué à chaque accès aux données, ce qui ralentira considérablement le rendu. Selon notre expérience, le temps de décompression est supérieur à la lecture de données sur disque pur.

Cela est particulièrement vrai si vous utilisez déjà des aperçus, une mosaïque et des supports de stockage hautes performances (disque de niveau entreprise ou SSD).


J'ai également besoin de copier mon image jpeg car je ne parviens pas à convertir mon raster en tableau avec gdalin Python. Il montre une erreur de mémoire et parfois aussi un manque de mémoire. Quelqu'un pourrait-il avoir une idée de comment implémenter cette ligne (gdal_translate -co "COMPRESS = method" src_dataset dst_dataset) en python. Je suis nouveau dans l'utilisation de gdal. Donc, il m'est parfois difficile de comprendre la structure.
Shiuli Pervin

1
@ShiuliPervin, Premièrement, le format JPEG est déjà un format compressé (avec pertes). Deuxièmement, il semble que vous ayez un problème de morceau, pas de compression. Lisez le fichier en mosaïque, en lanière ou en morceau, au lieu de tout en même temps. Même si le fichier est compressé, il devra être décompressé lors de son utilisation (exemple: si un fichier de 4 Go utilise 2 Go sur le disque compressé, il occupera tout de même 4 Go de RAM lorsqu'il sera entièrement chargé pour le traitement. autre gain de place, vous pouvez regarder dans la mise en forme clairsemée pour GeoTIFFs .
Kevin

1
@ShiuliPervin, bien que je puisse mal comprendre votre question. La compression elle-même utilise souvent beaucoup de mémoire, mais ne doit pas saturer votre système, à moins d’un bogue dans la bibliothèque ou d’un argument invalide. Si vous rencontrez des problèmes avec JPEG comme type de compression pour un GeoTIFF, essayez peut-être LZMA ou DEFLATE.
Kevin

0

Pour ceux qui utilisent des versions plus récentes de GDAL, il existe également les choix disponibles de compression ZStandard ( ZSTD ) sans perte (GDAL> = 2.3) et de compression LERC ( Lossy Limited Error Raster Compression ) avec perte.

En règle générale, cependant, ZSTDles vitesses de lecture des données sont plus rapides que les deux LZWet DEFLATEavec des taux de compression similaires, bien que cela puisse être un peu plus lent lors de l’écriture du fichier (en fonction des paramètres que vous utilisez).

Si la précision des données ne vous préoccupe pas vraiment (par exemple, vous ne faites que la visualisation plutôt que l’analyse), cela LERCpourrait être une bonne option. Un MAX_Z_ERRORparamètre vous permet de modifier le degré de précision que vous êtes prêt à sacrifier. Par exemple, a MAX_Z_ERROR=0.001ou 1mm confère un gain de place de 50% sur un repère (voir réf .).

La meilleure partie est que vous pouvez également combiner LERCavec ZSTDutiliser COMPRESS=LERC_ZSTD! Ou si vous préférez utiliser DEFLATE, vous pouvez le faire COMPRESS=LERC_DEFLATE. Voir aussi la liste complète des combinaisons / paramètres dans la documentation officielle de GDAL GeoTIFF https://gdal.org/drivers/raster/gtiff.html#creation-options

Vous trouverez plus de détails et des comparaisons complètes des points de référence sur cette précieuse référence:

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.