J'essaye de fusionner 14 geotiff comme ceci:
Chaque géotiff fait environ 50 Mo. J'ai besoin d'un géotiff à la sortie
Mon flux de travail:
gdalbuildvrt -input_file_list list.txt test.vrt (où ma liste contient le nom des tifs)
Alors :
gdal_translate -of Gtiff test.vrt test.tif
Input file size is 79841, 59955Cela fonctionne, mais le résultat est un géotiff de 13,3 Go! Pour 14 fichiers, chacun de 50 Mo, j'ai tenté un géotiff de 700 Mo, pas de 13 Go.
Je sais que gdal ne compresse pas par défaut, j'ai donc essayé cette commande:
gdal_translate -of Gtiff -co COMPRESS=JPEG test.vrt test_compressed.tifMais la "fusion" du fichier est trop importante pour la compression 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
...J'ai donc essayé un autre workflow et converti tous mes tifs en jpeg (14 Mo chacun), j'ai construit un fichier vrt et l'ai traduit avec la compression LZW. Mais le géotiff de sortie est d'environ 5 Go.
Pourriez-vous me dire quelle est la meilleure pratique pour faire le travail, et s'il est possible d'obtenir un géotiff de 14 * 50Mb?
Je ne l'ai pas essayé, mais j'ai pensé à fusionner ces tifs dans Photoshop, puis à re-géoréférencer avec les coordonnées en haut à gauche / en bas à droite. Avec ce flux de travail, je pense que j'aurai 14 * 50 Mo, mais je ne suis pas sûr. Et je veux apprendre les meilleures pratiques gdal donc je ne l'ai pas essayé pour le moment
venir aux piqûres: si l'entrée est tif avec 8 bits et l'exportation est 32 bits par défaut, vous aurez de sérieux problèmes. assurez-vous donc de conserver votre définition d'octet telle qu'elle est. Et rappelez-vous: le tif complet sera prob. avoir 20x 50mb car un tiff est toujours rectangulaire
Si je comprends bien, le nombre que j'ai indiqué en vert sur cette capture d'écran doit être le même à gauche et à droite?
Votre image de sortie aura plus de pixels que la somme de vos images d'entrée, mais cela n'explique pas la grande différence. Je vous suggère de regarder les caractéristiques de vos images basées sur gdalinfo afin de voir quelle compression est utilisée et de vérifier que les extensions sont correctes.
Les 14 tifs de 50 Mo étaient à l'origine 14 tifs de 700 Mo que j'ai traités avec gdal_translate avec -co COMPRESS = JPEG. J'ai compressé le raster afin de réduire le nombre de Mb, mais ce n'était peut-être pas une bonne idée?
Cette capture d'écran représente les 2 informations gdal du même géotiff (01.tif), à gauche de la capture d'écran se trouve le gdalinfo du Gtiff non compressé de 700 Mo, fin à droite le même Gtiff avec COMPRESS = JPEG, donc 50 Mo, avec le diff en vert:
Selon moi, les étendues sont correctes car en qgis cela correspond à d'autres sources de données et d'imagerie satellite.
* en supposant que vos images d'entrée ont la même taille, cela fait 20000 * 12000 pixels par images d'entrée, ce qui est grand pour une image de 50 Mo, peut-être que vous traversez l'étendue de votre système de coordonnées lorsque vous créez la mosaïque. *
Je ne suis pas sûr de comprendre ce que vous entendez par «traverser l'étendue». Mais j'ai essayé d'ouvrir mon 5 Gb LZW dans QGIS, et l'étendue est bonne, car elle correspond à une autre source de données.
Votre réponse me fait réaliser que les Gtiff n'ont pas la même taille, pensez-vous que cela pourrait être la cause de l'augmentation de la taille lors de la fusion? Parce que gdal préfère les fichiers de même taille. J'ai fait un gdalinfo sur chaque Gtiff pour obtenir sa taille, il y a une très petite différence entre la taille des 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, 11994Ensuite, vous devriez regarder la profondeur en pixels de vos images: si votre entrée était en octets,> vous devez conserver les octets. gdal_translate -of Gtiff -ot Byte -co COMPRESS = LZW test.vrt test.tif
J'ai essayé cette commande mais le gdal m'a dit que la taille du tiff était dépassée.
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.Mais si je dois créer un gros tiff, cela ne résout pas mon problème car il fait plus de 4 Go. La profondeur de pixels est-elle importante dans mon cas? (Photo HD de cartes, puis géoréférencées, pas DEM)
Remarque 1: convertir vos images en jpeg avant de créer un vrt n'aide pas et vous risquez de perdre des données.
Ce n'est pas grave si je perds un peu d'informations. Je préfère ne pas le perdre, bien sûr, mais si je le dois, ce n'est pas un problème. J'étais convaincu que la sortie serait plus légère si je travaillais avec jpeg, mais en conclusion, ce n'est pas vrai lorsque la sortie est Gtiff. Ce n'est donc pas une bonne solution. J'abandonne cette solution.
> Remarque 2: l'utilisation d'un vrt est utile: êtes-vous sûr d'avoir besoin de GTiff?
Oui, j'ai besoin d'un Gtiff, car je dois l'importer dans une application mobile qui a besoin d'une entrée géotiff pour fonctionner (je pense que l'application peut également prendre une entrée pdf géospatiale, mais je ne travaille jamais avec, et je veux comprendre mon problème avec gdal, car ce n'est pas la première fois que je l'ai).
J'ai essayé -co carrelé = oui -co bigtiff = oui -co compressé = jpeg -co photométrique = ycbcr et j'ai essayé -co TILED = oui -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512
Ces 2 commandes fonctionnent bien, j'ai une taille de ~ 700 Mb. C'est exactement ce que j'attendais.
Maintenant, j'ai un autre problème: il ne peut pas être ouvert rapidement par QGIS. Je dois attendre 15 minutes (mais je quitte avant que QGIS n'ouvre le tif avec succès). Je ne sais pas pourquoi. Et dans mon application Android, cela ne fonctionne pas (peut-être à cause de "tiled = yes"). Je dois lire un document par moi-même.
la source
Réponses:
Votre image de sortie aura plus de pixels que la somme de vos images d'entrée, mais cela n'explique pas la grande différence. Je vous suggère de regarder les caractéristiques de vos images basées sur gdalinfo afin de voir quelle compression est utilisée et de vérifier que les extensions sont correctes. (en supposant que vos images d'entrée ont la même taille, cela fait 20000 * 12000 pixels par images d'entrée, ce qui est grand pour une image de 50 Mo, peut-être que vous traversez l'étendue de votre système de coordonnées lorsque vous créez la mosaïque.) Ensuite, vous devriez regardez la profondeur de pixels de vos images: si votre entrée était en octets, alors vous devriez garder les octets.
Remarque 1: convertir vos images en jpeg avant de construire un vrt n'aide pas (il sera décompressé avant l'étape suivante) et vous risquez de perdre des données.
Remarque 2: l'utilisation d'un vrt est utile: êtes-vous sûr d'avoir besoin de GTiff?
EDIT: Il n'y a pas de miracle avec la taille de vos images, mais vous devez utiliser un tif en mosaïque en sortie pour pouvoir utiliser la compression jpeg avec vos grandes données (-co TILED = yes -co BLOCKXSIZE = 512 -co BLOCKYSIZE = 512 ). S'il reste trop grand, la seule solution est alors d'utiliser gdalwarp pour rééchantillonner à une résolution inférieure.
la source