Le portail francophone de la géomatique

La librarie ECW a elle-même son propre cache RAM pour ces petites activités, qui te bouffe 1/4 de la RAM par défaut. Cf la variable d'environnement GDAL_ECW_CACHE_MAXMEM pour controler ça mentionnée dans http://gdal.org/frmt_ecw.html. Récemment je me suis aperçu d'un bug dans la lib ECW sur Linux 64bit avec 8 GB de RAM : le truc essaye de te bouffer toute ta RAM. ECW est vraiment a PITA comme disent les anglophones... Erdas ne permettant même plus son libre téléchargement, c'est le signe de passer à autre chose!

"Sur certains sites on peut lire qu'il faut mettre GDAL_CACHEMAX à la même valeur que la taille du fichier input" ... Ouais, il n'y a pas de règle en fait. Tout dépend de l'algo GDAL utilisé, du format, de la taille des blocs, de l'entrelacement pixel ou canal etc... Il faut surtout être raisonnable dans la valeur qu'on met pour que ça reste dans les clous de la RAM disponible. Je dirais que rien ne sert de monter au delà de 300 MO.

Quant à -wm, ça augmente généralement les performances à la reprojection, mais pas toujours, voire ça peut les diminuer dans certains cas particuliers... La meilleure source d'information est : http://trac.osgeo.org/gdal/wiki/UserDocs/GdalWarp

Dernière modification par rouault (Wed 03 March 2010 22:32)

Bon ben que dire de plus : merci Even ! (je viens de voir que tu fais partie de l'équipe qui développe GDAL, je comprends mieux d'un coup, toutes tes interventions toujours exactes...)

J'avais jamais entendu parler de cette variable-là...Même en cherchant des infos sur les différentes variables, même sur cette page ce n'est pas marqué ! http://trac.osgeo.org/gdal/wiki/ConfigOptions

Bon et comme par hasard, ça marche Le fichier que j'essayais de créer a fonctionné, et l'utilisation mémoire du processus n'a pas dépassé les 100Mo, comme prévu.

Le seul truc que je ne comprends toujours pas c'est pourquoi cela a marché l'autre fois, avec GDAL_CACHEMAX. Et je suis sûr à 99% que ça a marché, vu que j'ai toujours les fichiers sur le pc, et vu la taille (~400Mo), il n'a pu être créé que comme ça (parce que quand je sors le fichier en TIFF, pas de souci d'utilisation mémoire, mais quand je le convertis ensuite en ECW, la taille de l'ecw n'est plus du tout la même).

Finalement il y a aussi un autre truc que je ne comprends pas...
J'ai défini la variable à 100000 : SET GDAL_ECW_CACHE_MAXMEM=100000
Ok, ça marche, le processus ne monte pas au-dessus des 100Mo.

Mais quand je redéfinis la variable, ça n'a plus aucun effet. Pourtant, la variable est bien définie
C:\Program Files\FWTools2.4.7>SET GDAL_ECW_CACHE_MAXMEM
GDAL_ECW_CACHE_MAXMEM=500000

Sauf que le processus gdal_translate est bloqué à 100Mo quand même. Même en faisant la commande dans une autre fenêtre FWTools (et là la variable n'est plus définie).
Par contre, en définissant la variable GDAL_CACHEMAX à 300, là le processus gdal_translate monte (mais plus lentement que d'habitude) jusqu'à...370Mo (va savoir pourquoi). Donc l'utilisation mémoire est plus importante, et pourtant la création du fichier est plus longue (40min contre 35min pour le premier, donc le GDAL_ECW_CACHE_MAXMEM à 100000)...

Suite des tests : le fichier ECW à 1.4go est finalement passé !
Avec la même configuration que quand j'ai réussi le fichier de 400Mo en limitant le processus à 100Mo d'utilisation mémoire. Là pour le fichier d'1.4Go, gdal_translate montait à 270Mo, mais en restant apparemment à cette limite. La création du fichier a duré 3h47.
Maintenant le dernier morceau, le fichier d'origine en ECW est à 2.5Go, on va voir si ça va passer...

Pour l'instant le processus oscille entre 400 et 460 sans jamais dépasser les 460.

Dernière modification par Sam_Dalembert (Fri 05 March 2010 08:43)