Le portail francophone de la géomatique

Complètement d'accord Yves, le soucis, c'est que même l'IGN fourni désormais des orthophotos en ECW. Alors quand on doit convertir une région entière d'ortho ECW dans un autre format, je te dis pas le travail que ca représente, sans parler de la perte en qualité puisque l'ECW est destructeur !
Pour les périphériques nomades, c'est un peu le même soucis.
Donc sur le principe, oui abandonner l'ECW serait une bonne chose. Dans la pratique, c'est beaucoup plus dur à mettre en oeuvre et on met bien la en lumière la problématique de ces formats propriétaires !!

Dernière modification par Ludovic L (Tue 03 August 2010 11:38)

Bonjour,

oui je comprend bien ces soucis techniques y étant confronté également. Je viens de jeter un oeil sur la page de GDAL et il y a un nouveau format qui vient d'apparaitre : Epsilon (Wavelet compressed images)

http://www.gdal.org/frmt_epsilon.html

Y.
PS : je vais spliter la discussion pour ne pas brouiller celle de Dominique.

des infos rafraichies...
http://field-guide.blogspot.com/2010/09 … sktop.html

J'ai rien vu dans le SKD concernant le support des unix, je suis passé à côté ou bien c'est réellement passé à la trappe ?

Jeirhome > qu'il y ai un pilote gdal ne veut pas dire support unix si le SDK gratuit d'ERDAS (celui qui intèresse les plus de monde) ne permet pas de faire un *.so

Jérôme,

Sauf que la diffusion du SDK a légèrement changé (c'est d'ailleurs l'objet de ce fil) et les sources ne sont plus disponible. Seul un exécutable pour windows est fournie actuellement.

Que GDAL puisse lire l'ECW via ce SDK cela est connus, que cela puisse l'être dans le futur est un peu plus incertain. Le message de Frank apporte d'ailleurs une réponse intéressante puisqu'il a un client intéressé.

Cela ne supprime toutefois pas la problématique : que faire face a un fournisseur de lib qui change sa licence chaque année. Comment un développeur sous linux pourra installer facilement le sdk (s'il le faut encore, la questions se pose à priori) pour lire les fichiers ECW s'il n'a qu'un SDK pour Windows sous la main ?

Y.

Effectivement, le souci c'est que (au moins pour l'instant) le nouveau SDK 4.1 n'est pas disponible pour Linux. On ne sait pas si ERDAS a des plans pour le fournir sous Linux. F. Warmerdam aimerait idéalement que le driver ECW mis à jour supporte à la fois le SDK 3.3 et le 4.1, pour les "heureux" possesseurs du 3.3 qui est peut être bien la dernière version à fonctionner sous Linux... Ou alors il faudra se résoudre à faire fonctionner un build Windows  GDAL-ECW sous Wine. Bref cela illustre à merveille les aléas de la dépendance à un logiciel propriétaire... D'ailleurs, l'aspect propriétaire/fermé va même au delà du logiciel, et concerne le format en lui-même, puisque de souvenir, les entêtes des fichiers du code source du SDK ECW (3.3) mentionnaient un certain nombre de brevets couverts par le code. Donc même si quelqu'un de motivé et compétent s'amusait à ré implémenter de façon indépendante un décodeur, il enfreindrait probablement les brevets en question, ou alors serait sous la menace d'accusations de violation de brevet de la part d'ERDAS...

La situation n'est pas non plus toute rose du côté de JPEG2000, qui bien qu'étant un standard publié, souffre d'un doute sur le fait que certains brevets pourraient être nécessaires au décodage du format (cf http://en.swpat.org/wiki/JPEG_2000 )

Sur le pilote openjpeg, non je n'ai eu aucun retour. Cela dit, ça me surprend moyennement : j'imagine qu'un très faible pourcentage des utilisateurs testent les branches de dev, et vu qu'il y a du choix au niveau du nombre de pilotes JPEG2000 dans GDAL, ça fait de la concurrence interne ;-) Mais bon, ce constat ne doit pas être interprété comme un appel à la procrastination, bien au contraire !

En terme de perfos, le pilote openjpeg ne battera pas les implémentations propriétaires, mais en terme fonctionnel, il a plus de potentiel que celui basé sur Jasper car avec la branche v2 d'openjpeg, on en mesure de faire des lectures "par bloc" dans l'image, ce qui est donc compatible de la lecture de très grosses images. En plus contrairement à Jasper, le projet openjpeg vit (commits réguliers). Il ne reste plus qu'à attendre qu'ils sortent un jour une release de la branche v2.

ThomasG > RasterLite c'est un conteneur pas un format de compression comme le JPEG2000, le premier embarque le second dans un gros BLOB. Comme le souligne rouault, le principal intêret de la bibliothèque openjpeg c'est le support du protocole JPIP qui permet une lecture incrémentale et arbitraire d'un image, c-à-d accéder à une zone de l'image sans la charger entièrement et sans création de tuile avec une résolution réduite.

rouault > si la lib openjpeg v2 n'est pas trop compliquée à compiler je ferais un essai avec gdal-dev (et qgis).

http://media.baliz-geospatial.com/fr/co … eg2000-sdk

Frank a dégainé rapidement. Les modifs étaient assez légères tout compte fait. OSGeo4W a été mis à jour pour être compatible du SDK 4.1 Pour ceux qui sont intéressés, je vous invite à bien lire les notes suivantes : http://trac.osgeo.org/osgeo4w/wiki/pkg-gdal17-ecw