Le portail francophone de la géomatique

sylpingus · Mon 30 January 2012 15:35

Bonjour,

Je suis en train de faire quelques tests d’extraction de données en utilisant GDAL. J’ai fait une installation de GDAL 1.8.1 et 1.9 sous Debian squeeze avec le support de l’ECW (lui-même compilé avec les sources de la version 3.3 avec gcc 4.4.5). L’installation s’est bien passée et la commande gdalinfo –formats me renvoie bien les formats ECW et JP2ECW.

Pour information, voici mon ./configure :

Code:

./configure --with-threads=yes --with-static-proj4=/usr/local/lib --with-libz=internal --with-liblzma=yes --with-pg=/usr/local/pgsql/bin/pg_config --with-pcraster=internal --with-png=internal --with-libtiff=internal  --with-geotiff=internal --with-jpeg=internal --with-gif=internal --with-ecw=/usr/local/lib --with-jasper=/usr/lib --with-mysql=/usr/bin/mysql_config --with-xerces=yes --with-expat=yes --with-curl=/usr/lib --with-geos=/usr/local/bin/geos-config --with-perl --with-php --with-python --with-libkml=no

Mes interrogations portent sur le scénario suivant (sachant que je fais les tests en parallèle avec GDAL 1.8.1 Windows, GDAL 1.8.1 MacOSX package KingChaos et mon GDAL compilé sous Linux) :

Je pars d’un fichier assemblé en ECW sur une ortho à 20 cm. J’extrait et reprojette du L93 vers le LIII Sud une portion de ce fichier en passant vers un Tiff.

A ce stade, Les Tiff résultants de tous les tests sont identiques (même volume, même rendu visuel, etc…) avec les trois instances de GDAL.
Puis je convertis ce Tiff en ECW avec la commande gdal_translate suivante :

Code:

gdal_translate -of "ECW" -co LARGE_OK="YES" -co TARGET="90" -co DATUM="NTF" -co PROJ="LM1FRE3D" file_in.tif file_out.ecw

Et là, au niveau des résultats obtenus, ça se corse. Pour les instances de GDAL Windows et MacOSX, j’ai un fichier ECW résultant qui pèse 7.1 Mo et pour mon instance Linux il pèse 4.1 Mo. Pour en avoir le cœur net, j’ai fait la même extraction depuis ErMapper et j’ai également un fichier en sortie qui pèse 7.1 Mo et qui est identique aux deux premiers. En termes d’aspect visuel et radiométrique (cf PJ), j’ai une différence entre les deux, comme si l’ECW généré depuis l’instance GDAL sous Linux comportait un voile sur l’image (ça se voit bien sur le couvert végétal ou sur la définition de la route au Nord de l’image).

Ma question est donc la suivante : est-ce que certains d’entre vous ont déjà rencontré ce cas de figure et, si oui, quelle peut en être la cause (problème de compilation, incompatibilité de version, etc…) ? Dans l’état actuel des choses, mon serveur Linux est « inutilisable » car il délivre des fichiers ECW dégradés par rapport à ce qu’ils devraient être. Je n’arrive pas à trouver la cause. J’ai lancé mes commandes gdal_translate en mode debug mais je n’ai pas de message d’erreur si ce n’est, à l’ouverture du fichier ECW global avant convertion en tiff, et lors de la création de l’ECW final depuis le tiff le message suivant : ECW: NCScbmOpenFileView(file.ecw): eErr = 0

Merci par avance pour vos retours.

rouault · Mon 30 January 2012 18:23

Tu a vraiment utilisés -co TARGET=90 dans tous les cas ? S'il s'agit d'une image RGB, la valeur par défaut du paramètre est 95% . Et comme le passage de 90% à 95% divise par 2 la taille du fichier final, ça pourrait être compatible de ce que tu observes si jamais tu avais oublié de spécifié l'option TARGET. Si ce n'est pas ça et que tu utilises bien les mêmes paramètres à chaque fois, alors là, je sèche.

Petite info : pour savoir si des rasters reconnus par GDAL ont le même rendu visuel, tu peux exécuter "gdalinfo -checksum monfichier". Pour chaque bande, ça renverra un nombre, ce qui permet objectivement de comparer des fichiers entre eux sans même les regarder. Prudence tout de même pour les formats compressés par contre : il pourrait être possible, au moins sur le plan théorique, qu'un même fichier ouvert sur 2 builds différents de GDAL donne des résultats différents à cause de problème d'approximation numérique

sylpingus · Mon 30 January 2012 23:03

J'utilise bien la même paramètre -co TARGET=90 pour tous les tests. De plus, le test avec ErMapper a été fait avec un taux de compression à 10 qui correspond à un -co TARGET=90... Pour vérifier, j'ai fait un "report ECW file" depuis ErMapper, et cela sur chaque fichier résultant et hormis le volume final qui diffère et la qualité du rendu, j'ai exactement les mêmes paramères pour chaque test (GDAL Windows, GDAL MacOSX, GDAL Linux et ErMapper).

Merci pour l'information sur la commande "gdalinfo -checksum monfichier", je ne connaissais pas. Du coup je l'ai lancée sur les différents résultats de test et voici ce que j'obtiens, sachant qu'on est exactement sur les mêmes emprises :

** ECW créé depuis gdal_translate compilé sous Linux :

Band 1 Block=5490x1 Type=Byte, ColorInterp=Red
Checksum=39143
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 7586, 56547, 24795, 37890, 10983
Band 2 Block=5490x1 Type=Byte, ColorInterp=Green
Checksum=16644
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 36039, 15745, 16948, 33187, 9440
Band 3 Block=5490x1 Type=Byte, ColorInterp=Blue
Checksum=43418
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 43868, 13703, 18008, 21727, 8785

** ECW créé depuis gdal_translate binaire Windows :

Band 1 Block=5490x1 Type=Byte, ColorInterp=Red
Checksum=20926
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 64276, 16735, 26955, 42838, 10662
Band 2 Block=5490x1 Type=Byte, ColorInterp=Green
Checksum=14618
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 19900, 62545, 12776, 36715, 7432
Band 3 Block=5490x1 Type=Byte, ColorInterp=Blue
Checksum=34951
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 35787, 51654, 35130, 24830, 8001

** ECW créé depuis gdal_translate binaire MacOSX :

Band 1 Block=5490x1 Type=Byte, ColorInterp=Red
Checksum=60015
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 41193, 18472, 34533, 43595, 10617
Band 2 Block=5490x1 Type=Byte, ColorInterp=Green
Checksum=31334
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 26552, 54162, 6890, 35179, 7529
Band 3 Block=5490x1 Type=Byte, ColorInterp=Blue
Checksum=59706
Overviews: 2745x2660, 1372x1330, 686x665, 343x332, 171x166
Overviews checksum: 39347, 38904, 29034, 23704, 7493

J'avoue ne pas trop comprendre ce que ça signifie clairement. Ce que je ne m'explique pas, c'est pourquoi il y a une telle différence de rendu entre la version compilé sous Linux et les autres tests (binaires windos et mac + ermapper). Suis-je le seul à faire ce constat ou si certains d'entre vous ont les moyens de faire un test rapide, est-ce que vous constatez la même chose sur vos installations linux respectives (dans un sens ça ma rassurerait). On dirait que les sorties ECW depuis GDAL_TRANSLATE sous Linux sont pastellisées et floutées ce qui peut poser problème sur des orthos haute résolution (avec un volume en sortie qui quasi deux fois moins important). Et mon plus gros problème à l'heure actuelle est que je vois pas comment résoudre ce point dans la chaîne d'extraction que j'ai mis en place, si ce n'est passer mon serveur sous Windows, ce qui n'est pas possible à l'heure actuelle.

Merci par avance pour vos retours et/ou commentaires et observations.

Dom.Marro · Wed 01 February 2012 19:47

Bonsoir,
Est-ce que tu sais si les versions de GDAL sous Windows et MacOSX (que tu n'as pas compilées toi-même si j'ai bien compris) utilisent la même version du SDK que GDAL sous Linux que tu as compilée avec le SDK 3.3 ?
Est-ce que c'est la première fois que tu observes ce phénomène de "voile" sous Linux ?
Cordialement

sylpingus · Thu 02 February 2012 11:52

Me revoilà. J'ai fait quelques erreurs dans la remontée des checksum de mon précédent post. Afin de refaire une série de tests probants, je suis parti tout simplement d'une dalle tiff d'origine en Lambert 93 (ortho à 20 cm) de 300 Mo.

A chaque fois, j'ai fait un simple GDAL_TRANSLATE, toujours avec la même commande :

Code:

gdal_translate -of "ECW" -co LARGE_OK="YES" -co TARGET="90" -co DATUM="RGF93" -co PROJ="LMFRAN93" file_in.tif file_out.ecw

J'ai fait des tests avec ma version GDAL compilée sous Linux (avec libecwj2-3.3-2006-09-06, dernière release qui était à disposition), avec la version de FWTools Linux 2.0.6 (qui utilise la même version de la librairie ecw, histoire de dissiper les doutes concernant une erreur de compilation de ma part), avec les binaires Windows distribués ici http://www.gisinternals.com/sdk/ et avec les binaires MacOSX distribués ici http://www.kyngchaos.com/software:frameworks et, enfin avec ErMapper.

Tous les fichiers résultants ont bien un taux de compression à 10 d'après ErMapper (ce que je souhaite obtenir). Donc pas de soucis du côté de la prise en compte de l'option TARGET dans GDAL.

Comme me l'a suggéré Even, j'ai fait un checksum sur chaque fichier résultant et j'ai également renvoyé les stats et l'histogramme. Les résultats sont sans appels (cf tableaux comparatifs joints). J'ai des résultats de checksum similaires entre Windows, Mac et ErMapper (les quelques écarts observés peuvent s'expliquer, je pense, par les problèmes d'approximation numériques évoqués par Even) qui confirme mon analyse "visuelle". Les deux résultats de Linux sont également similaires entre eux. Par contre, si on compare Linux et les autres tests, on a des écarts énormes sur les checksum des différentes bandes (beaucoup trop de vert et pas de bleu pour Linux) ce qui pourrait expliquer la différence que l'on obtient visuellement et l'aspect flouté ou pastellisé des images ECW sortant de GDAL Linux. Idem pour la comparaison des hisogrammes, c'est tout aussi parlant. La différence de volume entre les fichiers Linux et les autres est importante, ce qui signifie qu'il y a bien un problème de "perte d'information" étant donné que le taux de compression demandé est le même.

Aupravant, j'avais principalement fait des extractions similaires sur des SCAN de l'IGN ou de l'ortho à 50 cm. On voyait une légère différence à l'oeil nu mais ça restait acceptable. Dès qu'on augmente la résolution du pixel, la différence est de plus en plus visible et la "perte" de qualité plus importante.

Si certains d'entre vous (qui dispose d'une installation linux et la possibilité de tester sous Windows) ont le temps de faire des tests comparatifs similaires aux miens et de me communiquer leur résultats, ça serait génial. Cela permettrait de confirmer ou pas mes observations.

Je suis bien évidemment preneur de toute une idée sur la cause du problème. Si d'autres font le même constat, j'essayerai de relayer le problème sur la liste de dev de GDAL, sans être certain d'avoir une réponse par rapport à une librairie qui n'est plus maintenure.

Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

sylpingus · Thu 02 February 2012 14:23

Je continue. J'ai oublié de préciser que la même question avait été posée sur ForumSIG (http://www.forumsig.org/showthread.php? … post285862).

Je relaye ci-dessous un retour de Sylvain33

Bonjour,

Es-tu allé voir ici : http://www.gdal.org/frmt_ecw.html
Notamment en modifiant toi même le Target en plus élevé. visiblement le sdk 3.3 dégrade plus que le nouveau sous windows : le 4.1 ou 4.2

Et ma réponse :

Je rattrape la discussion et répond à Sylvain33

Tous les tests que j'ai mené (Windows, Mac, Linux) sont sur la base du SDK 3.3, donc à base de comparaison équivalente.

Je n'ai pas pu faire de test sur la version 4.1 et 4.2 qui sont payantes (en mode écriture) et uniquement disponibles sous Windows.

Ma question porte vraiment sur l'usage du SDK 3.3 qui est encore librement utilisable même si elle n'est plus maintenue par ERDAS (sauf erreur de ma part car la licence du 3.3 n'est pas très claire sur le sujet).

Pour résumer, j'ai mis en place une chaîne d'extraction de données raster et vecteur à partir de GDAL et d'une surcouche en PERL (sous plateforme linux). Compte tenu du constat que je peux faire sur la différence de qualité des fichiers résultants, je cherche (désespérément) à trouver une issue...

Merci pour vos retours et vos tests pour ceux qui auront le temps, la gentillesse et la possibilité de les faire

sylpingus · Thu 02 February 2012 14:54

La suite des discussion sur ForumSIG (message de Sylvain33) :

Intéressant, je vais faire les tests et je suis surpris des résultats !

Tu as testé sans compression sous linux voir la taille du fichier

Dernière modification par sylpingus (Thu 02 February 2012 16:15)

sylpingus · Thu 02 February 2012 15:38

Ma réponse sous Forum SIG

Je viens de tester sans compression (TARGET=0 ? même si je ne suis pas sur de ça) :

Volume du fichier GDAL/WINDOWS : 72677 Ko
Volume du fichier GDAL/LINUX (les deux install) : 64498 Ko

Le gdalinfo -checksum pour GDAL/WINDOWS et ErMapper (avec compression 0) :
BAND1(Red) : Checksum=40381
BAND2(Green) : Checksum=55962
BAND3(Blue) : Checksum=36506

Le gdalinfo -checksum pour GDAL/LINUX :
BAND1(Red) : Checksum=11197
BAND2(Green) : Checksum=34986
BAND3(Blue) : Checksum=23542

Il semblerait qu'il y ait vraiment un problème à la création de l'ECW ou à la lecture/interprétation de l'image d'origine sous Linux (ErMapper constituant pour moi la référence).

sylpingus · Thu 02 February 2012 16:15

La suite de ForumSIG (toujours Sylvain33) :

J'ai une VM ubuntu je teste dedans

Parce sous debian je ne penses pas que le patch ici soit appliqué :
http://www.kyngchaos.com/macosx/build/ecw#patches

Je vais vérifier dans le code si ce patch concerne des modification de la librairie ou juste le changement des path

Ma réponse :

J'ai déjà fait un test en appliquant ce patch au code source de la librairie et de tout recompilé...

Ca n'a rien changé pour moi. Status quo.

Dernière modification par sylpingus (Thu 02 February 2012 16:16)

sylpingus · Fri 03 February 2012 16:32

Suite de débat sur Forum SIG (par Sylvain33) :

Je vient de constater le même soucis. Hors il y a plein de patch et non pas un seul pour cette lib dont un qui parle de profile icc et rgb.
Je suis en train de tester, je te fais un retour dans un petit moment

Et ma réponse :

Dans un sens ça me rassure que tu constates le même problème de ton côté.

Ce qui l'est moins, en revanche, c'est que même les binaires FWTools Linux, même s'ils sont anciens, présentent le même dysfonctionnement.

A ton avis, ça viendrait donc de la librairie ECW 3.3 qu'il faudrait patcher pour assurer un fonctionnement correct sous un environnement Linux ?

Les patchs additionnels dont tu parlais, tu les a trouvé où ? De mon côté, la recherche sur le net n'a pas été très fructueuse.

J'attends impatiemment ton retour sur les tests additionnels .

sylpingus · Mon 06 February 2012 10:20

La suite sur forum SIG (message de Sylvain33) :

Bon ben non même avec les patchs appliqués => 5 rien n'y fait ! J'ai toujours le même soucis de compression comparé à un encodé dans global mapper via wine

Je teste une modif manuelle de la lib. Mais pour moi ça ne fait aucun doute que c'est elle qui est en tort. Si tu as un doute su gdal fait un test avec d'autres formats.

En fait il existe un patch qui supprime tout le lcms ( http://en.wikipedia.org/wiki/Linux_color_management | http://www.littlecms.com/ ) de la libecw !!! Si on ne compile pas avec ce patch on a un conflit avec cette lib sous linux. Chose que j'avais déjà remarqué. Je soupçonne que ça puisse venir de là

Ce qui est bizarre ce sont les résultats mac osx qui se rapproche de ceux de windows alors qu'ils devraient plutôt se rapprocher de ceux de linux : c'est quasiment la même compilation et surtout les mêmes sources il me semble. C'est surtout ça que je n'explique pas.

Enfin en tant qu'alternative, je te propose de trouver le taux de compression se rapprochant le plus de ceux de windows et de faire des conversions comme ça mais ça vaut le coup de poser la question sur la liste gdal

Pour ce qui est des patch, je regardes toujours ce qui se fait sur les distributions de type KISS (Keep It Simple Stupid) style archlinux. Voici ici :
https://aur.archlinux.org/packages.php?ID=38915
Si tu veux des détails pour l'install tu regardes le pkgbuild

Et pour l'install (autoconf, gcc, g++ doivent être installés) :
Code:

wget http://mirror.ovh.net/gentoo-distfil...2006-09-06.zip
unzip libecwj2-3.3-2006-09-06.zip
wget https://aur.archlinux.org/packages/l...ibecwj2.tar.gz
tar -xzvf libecwj2.tar.gz; mv ./libecwj2/*.patch ./ ; rm -rf libecwj2
cd libecwj2-3.3/
patch -p0 -i ../libecwj2-3.3-3245a.patch
patch -p0 -i ../libecwj2-3.3-3245b.patch
patch -p0 -i ../libecwj2-3.3-NCSPhysicalMemorySize-Linux.patch
patch -p0 -i ../libecwj2-3.3-2593.patch
patch -Np 0 -i ../libecwj2-3.3-nolcms.patch
rm -rf Source/C/libjpeg Source/C/NCSEcw/lcms/
sed -i -e "s:includeHEADERS_INSTALL:INSTALL_HEADER:" Source/NCSBuildGnu/Makefile.am
autoreconf -i
./configure --prefix=/usr
make
sudo make install

Voilà si jamais tu poses sur al liste gdal, un retour serait apprécié

Ma réponse :

Merci pour le retour.

Du coup, ça signifierait que tout ceux (moi y compris) qui utilisent Linux pour générer de l'ECW sortent des fichiers qui ne sont pas "optimaux" ? Si c'est le cas, ça me laisse perplexe...

La solution de trouver des taux de compression qui se rapproche de windows ne règle pas le problème (j'ai déjà fait le test). Si on joue la dessus pour arriver à des volumes sensiblement équivalent, il n'empêche que la ventilation des informations dans les 3 bandes RGB n'est toujours pas bonne et donne un aspect différent.

Je continue à creuser ce week-end et je pense poster sur la liste gdal-dev en début de semaine prochaine. Je ne manquerai pas de faire suivre les informations.

En attendant, si d'autres ont des idées, des suggestions ou peuvent faire des tests complémentaires sur leurs installations, vous êtes les bienvenus.

La réponse de Sylvain33 :

Moi aussi ça me laisse perplexe !

En tout cas merci, je vais définitivement abandonner l'ecw. hop du tif partout plus besoin de recompiler ce sera très bien !!
*******
EDIT
*******
A tester peut-être avec le jpeg2000 fournit dans la libecw voir si le problème est le même !

Et mon retour tout frais de ce matin :

Bonjour, me revoilà après mes tests du week-end.

Ce n'est pas très porteur. J'ai eu beau faire des tests dans tous les sens. Pas mieux. Il semble vraiment y avoir un problème avec la lib ECW 3.3 sous Linux. N'étant pas un as du C++, j'ai regardé un peu le code source de la librairie mais ça ne me parle pas beaucoup .

J'ai fait des tests avec le JPEG2000 (JP2ECW). Et là, surprise ! En effet, j'ai les mêmes "erreurs" en comparant GDAL/Linux avec GDAL/Windows et Ermapper. Ce qui est plus surprenant c'est que GDAL/Macosx donnait des résultats identiques à Windows pour l'ECW alors que pour le JPEG2000, j'ai les mêmes résultats que pour Linux (qui ne sont donc pas bons).

De mon côté, je trouve ça dommage de laisser tomber l'ECW, c'est quand même bien utile sur des images volumineuses (ortho HR notamment).

Je (re)lance un appel à la communauté des utilisateurs GDAL/Linux : il y aurait-il quelqu'un qui a réussi à compiler GDAL avec la lib ECW 3.3 et qui donne des résultats identiques à GDAL/Windows ou Ermapper ?

Merci par avance.

sylpingus · Mon 06 February 2012 13:08

La suite (message de Sylvain33) sur ForumSIG :

Même avec les patchs ?
Faut aller sur la liste gdal je penses pour poser le problème à présent

Ma réponse :

Oui, même avec les patchs...

Effectivement, je vais essayer de poster sur la liste de GDAL-DEV en ce début de semaine.
*******
EDIT
*******
Une dernière info. J'ai fait le test avec la version 2006-09-06 et la version 2007-05-09 (qui était celle téléchargeable sur le site d'Ermapper auparavant) et j'ai le même résultat dans les deux cas.

Message de Lud :

Peux tu donner le lien vers la lib ecw 3.3, j'essaierai de tester si je trouve un peu de temps

Réponse de Sylvain33 :

C'est ici Lud !
Ça c'est celle du 6 septembre 2006. J'en ai une autre du 9 Mai 2007. Peut-être qu'il en existe d'autres et peut-être que le problème vient de là !

Dernière modification par sylpingus (Mon 06 February 2012 14:01)

sylpingus · Thu 09 February 2012 09:25

Je continue à relayer le débat sur le même sujet sur Forum SIG :

Réponse de jcr83 :

Bonjour,

Je confirme le problème. Je viens de tester GDAL avec un échantillon gratuit de l'IGN (dispo sur la page http://professionnels.ign.fr/3/echantillons.htm). J'ai choisi le fichier ORTHO HR.
Comme le fichier est déjà en ECW, j'ai commencé par le convertir en TIFF, puis je l'ai reconverti en ECW :
Code:

gdal_translate 0468_6739-20.ecw 0468_6739-20.tif
gdal_translate -of ECW -co TARGET=90 0468_6739-20.tif test.ecw

Voici les caractéristiques du fichier test.ecw :

Sous Windows XP, avec GDAL 1.8.0 :
Taille : 23 216 592
Checksums :
Band 1 Block=10000x1 Type=Byte, ColorInterp=Red
Checksum=1016
Band 2 Block=10000x1 Type=Byte, ColorInterp=Green
Checksum=6603
Band 3 Block=10000x1 Type=Byte, ColorInterp=Blue
Checksum=51172

Sous Gentoo Linux 64 bits, avec GDAL 1.9.0 :
Taille : 15 654 851 octets
Checksums :
Band 1 Block=10000x1 Type=Byte, ColorInterp=Red
Checksum=41594
Band 2 Block=10000x1 Type=Byte, ColorInterp=Green
Checksum=39062
Band 3 Block=10000x1 Type=Byte, ColorInterp=Blue
Checksum=46689

Par curiosité, pourriez-vous calculer les checksums sur le même fichier, pour voir si nous trouvons les mêmes, à système d'exploitation identique ?

Complément de even.roualt :

Intéressante expérience.

- Résultats strictement identiques à ceux sous Gentoo avec mon Ubuntu 10.04 64bit et un GDAL trunk (ce qui doit être strictement équivalent à 1.9.0 pour l'instant)
- Fichiers très proches en taille (23215569 octets) avec Windows 32bit et un libecwj2.dll provenant de http://www.gisinternals.com/sdk/Pack...e-1500-dev.zip . Les checksums diffèrent de ceux de Jean-Claude évidemment.

Visuellement la qualité de l'ECW produit sous Windows est effectivement meilleure que celle de celui produit sous Linux.

Y a donc vraiment un problème avec le SDK ECW sous Linux...

Et retour de Sylvain33 :

Citation:
Envoyé par even.rouault
Y a donc vraiment un problème avec le SDK ECW sous Linux...

Ou gdal non ? Un petit oubli pour la version linux ça peut arriver !
Ce qui est bizarre c'est la fifférence mac osx et linux. J'aurais pensé que les fichiers produits seraient identiques !!!

sylpingus · Thu 09 February 2012 09:54

Ma réponse aux dernières remarques sur Forum SIG :

Bonjour,

Merci à Jean Claude et Even pour les tests effectués.

De mon côté, je me suis livré à quelques tests complémentaires. Je dispose d'un PC sous Windows 7 64 bits. Du coup, j'ai relancé le même test avec une version 64 bits de gdal qui est disponible sur http://www.gisinternals.com/sdk/(auparavant j'ai fait mes tests avec une version 32 bits des binaires GDAL Windows). Et là surprise, j'ai une dalle en sortie qui fait 16315 Ko, comme sous Linux. Et quand je passe en 32 bits j'ai 23045 Ko, comme ErMapper. Du coup, j'ai refait mes tests en compilant sous Debian en 32 Bits. Mais sous Linux, que ce soit avec un OS en 32 bits ou en 64 bits, j'ai les mêmes résultats.

J'ai également réalisé les mêmes tests en générant du JPEG2000 (JP2ECW) et voici les résultats :

** Linux compilé, Linux Binaires, MacOSX, Binaires Windows 64 bits : résultats identiques.
** Binaires Windows 32 bits, ErMapper : résultats identiques et meilleurs que les précédents.

Ce qui est donc surprenant c'est qu'avec les binaires MacOsx, on a un ECW qui est correct et un JP2ECW qui est "mauvais". Bref, je ne suis pas plus avancé mais ça permets (peut-être) d'apporter de l'eau au moulin.

Even, crois-tu qu'il soit pertinent que je poste ce point sur la liste gdal-dev ou est-ce que c'est inutile (étant donné que le SDK ECW 3.3 n'est plus maintenu et que le problème semble venir de ce dernier) ? D'autre part, existe-t-il un canal de communication sur le site de GDAL pour informer les utilisateurs du SDK 3.3 du problème. Si oui, est-ce opportun de faire remonter l'information ?

Merci pour vos réponses

sylpingus · Thu 09 February 2012 10:56

Réponse de Sylvain33 :

Citation:

Envoyé par sylpingus
pour informer les utilisateurs du SDK 3.3 du problème.

+1.
Je n'avais pas connaissance du problème donc ej penses que ça peut être bon de faire remonter !

sylpingus · Fri 10 February 2012 09:36

Réponse d'Even Rouault :

Résultats complémentaires intéressants et troublants qui tendraient à montrer que ce n'est pas qu'une simple histoire Linux vs Windows, ou 32 bits vs 64 bits, mais que les combinaisons entre ces 2 facteurs comptent. A mon humble avis, je pense vraiment que le problème vient du SDK ECW. GDAL fait essentiellement passe-plat pour l'ECW et je serais extrêmement surpris que le driver GDAL ECW soit la cause du problème. J'ai jeté un coup d'oeil rapide dans ecwcreatecopy.cpp et il n'y a rien de flagrant : pas de chemin de code différent entre Linux ou Windows, pas d'utilisation du type long qui pose souvent problème entre 32 et 64 bits. Mais bon tant que personne ne s'est arraché les cheveux pour investiguer (et en disant ça, ne pas entendre que je me porte volontaire ), on ne peut pas être complètement certain d'où vient le problème.

Il peut être intéressant de signaler ce problème sur gdal-dev en effet pour que les utilisateurs soient avertis. Quant à mettre quelque chose sur le site de GDAL, ça pourrait être une mention sur la page Wiki concernant le format ECW : http://trac.osgeo.org/gdal/wiki/ECW

Pour info, j'ai évoqué rapidement ce problème hier sur le canal IRC GDAL avec Frank Warmerdam, et ça ne lui évoquait rien. Il était bien conscient de quelques petites différences, mais apparemment pas significatives. Cela étant dit, tant qu'on n'a pas vraiment regardé le problème de près, on peut passer à côté. Sur l'exemple proposé par Jean-Claude, on voit certes une différence, mais il faut zoomer à la meilleure résolution. En regardant rapidement ou en dé-zoom, on ne perçoit pas la différence.

Un test intéressant serait de voir ce que ça donne sous Win64, mais avec le nouveau SDK 4.X, mais il faut trouver quelqu'un qui a acheté la licence.

Sinon, il me semblait qu'il y a des exemples de code source de test fournis avec le SDK. S'il y a dedans ce qu'il faut, ça pourrait être un moyen de découpler les variables GDAL / SDK ECW.

sylpingus · Fri 10 February 2012 09:39

Complément de Sylvain33 :

Euh si on recompile à partir des sources sous windows 32bit, je suis susceptible d'avoir le même résultat c'est ça ?
Je veux bien essayer de recompiler à partir des sources sous windows pour voir si la faute c'est les sources ou le binaire fournit par ermapper !

sylpingus · Thu 16 February 2012 11:53

Remarque de jcr83 :

Cela me semble une bonne idée. Si j'ai bien suivi la discussion, dans le cas qui donne de bons résultats, c'est la DLL fournie par ErMapper qui a été utilisée, et dans tous les autres cas (mais j'ai un doute pour Windows 64), c'est une bibliothèque compilée à partir des sources ?

sylpingus · Wed 22 February 2012 09:01

Mes compléments sur Forum SIG :

Bonjour,

Désolé pour mon silence de ces derniers jours. J’étais pas mal occupé et je me suis également livré à des tests complémentaires.

Even, merci pour tes réponses. Je partage ton point de vue et je penche plutôt sur un problème du SDK sous Linux, sur la fonction « compress ». En fait, j’ai compilé les exemples de code source (compress examples) livrés avec le SDK. Malheureusement on ne peut pas ouvrir de Tiff mais je me suis quand même livré à un test en compressant un ecw existant et le résultat est sans appel : même problème en sortie par rapport à du ErMapper. Donc, pas besoin de passer par GDAL pour avoir ce comportement étrange.

D’autre part, j’ai fait des tests de décompression (GDAL_TRANSLATE ECW vers TIFF) et j’obtiens un résultat similaire sur toutes les plateformes de tests. Le problème se situerait bien sur la compression. J’ai également fait un test depuis une FreeBSD 9.0 (architecture similaire à Darwin / MacOSX) en utilisant les ports précompilés (un certain nombre de patchs sont par ailleurs appliqués à la libecw) et j’ai les mêmes « défauts » en sortie.

Pour ce qui est de la qualité des résultats, la différence est quasiment nulle sur des images avec des résolutions faibles (2,5 ou 1m). Par contre sur des hautes résolutions, on commence à voir une différence, notamment sur les zones continues de couvert végétal (un peu embêtant pour des orthos infra-rouge et/ou à haute résolution).

Concernant les remarques de jcr83 et sylvain33, les bons résultats ne sont pas seulement issus de la DLL fournie par ErMapper (binaires MacOSX).

Comme le disait Even, il faudrait investiguer. En ce qui me concerne, je n’ai pas les compétences nécessaires en C/C++ pour aller plus loin dans les investigations. Je n’ai pas encore posté sur gdal-dev mais j’espère que ça pourra débloquer la situation...

sylpingus · Wed 22 February 2012 10:44

Message de Sylvain33 :

Tu fais bien de relancer. Malheureusement, je n'ai pas le temps en ce moment de compiler sous windobe (c'est surtout que je ne suis pas habitué donc utiliser visual C/C++ ou encore Code Blocks donc ça va prendre le temps que je m'y intéresse ) qui plus est dans une VM mais j'ai bien envie de faire ce test.

Moi ce que je ne comprends toujours pas c'est le binaire MacOSX, il a été compilé à partir des sources par kingchaos

Et ma réponse :

Ok.

Concernant le fait que les binaires MacOSX fonctionnent, même s'il ont été compilés depuis les sources, ça ne m'étonne pas.

Même si je ne suis pas expert, j'ai quand même passé un certain temps ces derniers jours à essayer de comprendre le code source de la librairie ECW 3.3 et je me suis rendu compte que pour le process de compilation il y a un certain nombre de "case" selon la distribution (WIN32, Linux, MacOSX, HP-UX, Solaris, etc...). Cela pourrait expliquer que la compilation sous MacOSX donne de bons résultats et pas celle sous Linux.

sylpingus · Wed 22 February 2012 12:09

Réponse de Gene sur Forum SIG :

Vous pouvez toujours demander à William Kyngesburye comment il fait kyngchaos@texte-a-enlever.kyngchaos.com

Il est en général très disponible, sauf pour le moment.

Ses explications données à
http://www.kyngchaos.com/macosx/build/gdal suffisent généralement, hormis pour le plugin ecw

Réponse de Sylvain 33 :

Merci Gene !
@Sylpingus : tu demandes ou je le fais ?

Et la mienne :

Si tu as le temps de poser la question je suis preneur. Je viens de poster sur gdal-dev et il va falloir que j'assure le suivi de la discussion.

sylpingus · Fri 16 March 2012 16:02

Je me permets de clôturer la discussion. La suite des débats a lieu ici : http://www.forumsig.org/showthread.php?t=33227.

Communauté	Ressources	L'emploi	Le marché	L'association	Fils RSS
Forum Blogs Wiki Planet Sites amis	Agenda Biblio Fiches AMO-CNIG Paris PCGIS Téléchargements	Offres d'emploi Banque de CV Formations Démarche Métiers	Geo-Entreprises Geo-Communiqué Appels d'offres	L'association Qui sommes-nous ? Nous aider Bienfaiteurs Partenaires Historique Statuts	Tout le site Job Géomatique Services GeoBlogs ...	Faire un don Mentions légales

Le portail francophone de la géomatique

Annonce

#1 Mon 30 January 2012 15:35

Problème GDAL_TRANSLATE en ECW sous Linux

Code:

Code:

#2 Mon 30 January 2012 18:23

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#3 Mon 30 January 2012 23:03

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#4 Wed 01 February 2012 19:47

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#5 Thu 02 February 2012 11:52

Re: Problème GDAL_TRANSLATE en ECW sous Linux

Code:

#6 Thu 02 February 2012 14:23

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#7 Thu 02 February 2012 14:54

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#8 Thu 02 February 2012 15:38

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#9 Thu 02 February 2012 16:15

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#10 Fri 03 February 2012 16:32

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#11 Mon 06 February 2012 10:20

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#12 Mon 06 February 2012 13:08

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#13 Thu 09 February 2012 09:25

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#14 Thu 09 February 2012 09:54

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#15 Thu 09 February 2012 10:56

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#16 Fri 10 February 2012 09:36

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#17 Fri 10 February 2012 09:39

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#18 Thu 16 February 2012 11:53

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#19 Wed 22 February 2012 09:01

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#20 Wed 22 February 2012 10:44

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#21 Wed 22 February 2012 12:09

Re: Problème GDAL_TRANSLATE en ECW sous Linux

#22 Fri 16 March 2012 16:02

Re: Problème GDAL_TRANSLATE en ECW sous Linux

Pied de page des forums