Fwd: Re: [Dcmlib] Integration gdcm dans ITK

Jean-Pierre ROUX jean-pierre.roux at creatis.insa-lyon.fr
Sun Apr 25 00:31:38 CEST 2004 

>Date: Fri, 23 Apr 2004 14:57:01 -0400
>From: Luis Ibanez <luis.ibanez at kitware.com>
>To: Jean-Pierre Roux <jpr at creatis.insa-lyon.fr>
>Subject: Re: [Dcmlib] Integration gdcm dans ITK
>X-Virus-Scanned: by AMaViS snapshot-20020222
>Cc: Jean-Pierre Roux <Jean-Pierre.Roux at creatis.insa-lyon.fr>,
>   Mailing list gdcm <dcmlib at creatis.insa-lyon.fr>,
>   Mathieu Malaterre <mathieu.malaterre at kitware.com>
>
>

Bonsoir, les gdcmlibeux et les info-teamiens !

Il faudrait vraiment qu'on leur réponde, à Kitware !
Apparement, Luis Ibanez pense qu'on hésite à laisser le code de gdcm 
dans le domaine public, alors que la volonté du Labo, c'était bien 
qu'il *soit* dans le domaine public, non?
Quant au problème du CMakeLists.txt, ce n'en est pas un, car il est 
*déja* dans la distrib standard, et c'est Mathieu qui le tient à 
jour, car personne ne s'en sert à creatis.
Et, d'après la discussion informelle de la semaine dernière, Eric 
voyait qq avantages à ce qu'on l'utilise (il est cross-platform), et 
Fabrice était d'accord, à condition qu'on garde également les 
auto-tools en local, pour Linux, c'est bien ça?

Bon...
Faut faire une réunion 'officielle', ou bien Hugues se charge de répondre ?

See You

>Au risque de repeter ce qui Mathieu a deja dit,
>Je voudrais revenir sur les points que nous voyons
>comme essentiels pur faire possible l'utilization
>de GDCM en combination avec ITK.
>
>  1) Un license plus ouverte que LGPL et GPL.
>     La license MIT est certaintment de cette
>     qualite car elle n'impose aucune restriction
>     a l'utilisation du logiciel.
>  2) Une configuration Multi-platforme.
>     Cela se traduit en utiliser CMake. Nous comprenons
>     bien que pas tout le monde est interese en utiliser
>     CMake pour ses projects. En consequence typiquement
>     nous trouvons que un bon compromis est celui d'inclure
>     le fichier CMakeLists.txt avec la distribution du
>     logiciel. De cette facon, ceux qui veulent utiliser
>     CMake peuvent le faire, tandis que ceux qui sont
>     attaches a d'autres methodes mois generales peuvent
>     continuer a utiliser des outils telles que autoconf
>     car les fichiers necesaires seront toujour la.
>
>     Si le fichier CMakeLists.txt est inclus avec la libraries
>     il serait tres facile pour nous de configurer a Nightly
>     Dashboard pour GDCM. De cette facon, s'il y a jamais des
>     modification qui brisent la configuration nous le saurons
>     dans les 24 heures qui suivent, et pourront le resoudre
>     rapidement.
>
>Cela dit, I'l faut remarquer que une autre option est celle
>de faire GDCM une librairie optionelle, comme nous avons deja
>fait pour FFTW. Dans ce ca la, nous ajoutons des option dans
>le CMakeLists.txt de ITK pour compiler la classe itk::GDCMImageIO 
>seulement quand la librairie GDCM est disponible.  Ceci est
>independant du choix de la part de GDCM d'utiliser CMake ou pas.
>
>Neanmois, il serait enormement plus facile de le faire si one
>ajoute un fichier CMakeLists.txt au repositoire CVS de GDCM.
>Dans cette scenario, vous n'aurais pas a changer la license.
>Simplement, ceux qui veulent utiliser GDCM avec ITK devron
>decharger GDCM depuis votre serveur, le compiler, et ensuite
>configurer ITK a nouveau.
>
>En dehors de cettes questions plutot techniques, il y a un point
>essentiel que sera a vous d'en reflechir:
>        Est-ce que vous etez d'accord en laissant
>        que cette librarie soit utilise par des
>        produit commerciels ou pas.
>Nous avons pris cette decision depuis le debut de ITK ainsi
>que VTK. Mais, nous comprenons que pas tout les developeurs
>veulent laisser leur code dans le domain publique.
>
>  Amicalement,
>       Luis
>
>
>
>----------------------
>Jean-Pierre Roux wrote:
>
>>Mathieu Malaterre wrote:
>>
>>>
>>[...]
>>
>>>
>>>> - ce qui inquiétait un peu Eric, c'est de recevoir des images 
>>>>'Dicom-Like' du monde entier, qui casseraient gdcm, à cause de 
>>>>bugs-contructeur dans l'entete
>>>
>>>
>>>
>>>Je vois pas bien le rapport avec le changement de license ? Est-ce 
>>>que BSD-like apporte plus d'utilisateurs ? Ou bien est-ce le fait 
>>>d'etre visible a travers ITK qui vous inquiete ? Dans tous les cas 
>>>on reste dans le monde de l'opensource, et les gens sont -en 
>>>general- assez tolerant si ils rencontrent un probleme... sinon il 
>>>se prennent des 'envoi un patch si t'es pas content' ;)
>>
>>
>>Le changement de licence n'a naturellement rien à voir là dedans ....
>>
>>[...]
>>
>>>
>>>>- autre chose plus sérieuse : si vous faites des modifs 
>>>>incompatibles avec que que l'on est en train de faire ...
>>>>  on risque d'avoir une version gdcm-creatis et une version gdcm-kitware ?
>>>
>>>
>>>
>>>Hum, en theorie oui, mais en pratique qu'est-ce que tu appelles 
>>>une modif incompatible ? Si on change le code c++ c'est 
>>>generalement pour ne pas casser sur des plateformes exotiques, 
>>>donc ca passera toujours sous linux/win32 qui sont les deux archis 
>>>pour gdcm ?
>>>
>>>Le seul enui que je vois se profiler c'est la difference de 
>>>build-system. Vous avec les autotools, nous avec cmake. Il est 
>>>hors de question que l'on utilise les autotools (il y a trop de 
>>>choses implementees dans cmake que l'on ne trouve pas dans les 
>>>autotools). J'espere que ca se passera bien. Pour SWIG, on y 
>>>arrive meme si certains ici grincent des dents.
>>
>>
>>Je crois la position au sujet de Cmake est en train d'evoluer au Labo.
>>
>>>
>>>>En ce qui concerne la *compression* jpeg, on ne s'en sert pas 
>>>>pour le moment.
>>>>J'avais laissé les fonctions, car je m'étais fixé comme objectif 
>>>>de ne faire *aucune* modif sur la librairie récupérée chez IJG 
>>>>(Independent JPEG Group)
>>>>L'utilisation effective de la compression n'est pas à l'ordre du 
>>>>jour, mais ne peut pas être exclue.
>>>
>>>
>>>
>>>Euh je ne comprends pas ? gdcm lie bien les dicom compressees ? 
>>>Est-ce que c'est au moment de l'ecriture que ce n'est pas 
>>>implemente ?
>>
>>
>>Le seul mode d'écriture implanté pour le moment, c'est 'Explicit 
>>Value Representation'.
>>Notre problème, c'etait de lire toutes les 'Transfert Syntax', pas 
>>de les ré-écrire toutes.
>>
>>>
>>>[...]
>>
>>
>>Il faudra que l'on fasse une réunion formelle du KKK d'info-team ...
>>On te prévient.
>>
>>See You
>>
>>JPRx
>>
>>
>>
>>
>
>
>
>_______________________________________________
>Dcmlib mailing list
>Dcmlib at creatis.insa-lyon.fr
>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib

  Jean-Pierre ROUX
  UMR CNRS 5515-CREATIS
  Laboratoire de Radiologie Experimentale
  Hopital Cardiologique
  28 Avenue du Doyen LEPINE
  B.P. Lyon-Montchat
  69394 Lyon Cedex 03

  Tel      : (+33) 04 72 35 74 12
  Fax      : (+33) 04 72 68 49 16
  URL      : http://www.creatis.univ-lyon1.fr
  e-mail   : jpr at univ-lyon1.fr

More information about the Dcmlib mailing list