[Dcmlib] Integration gdcm dans ITK

[Luis Ibanez]

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
> 
> 
> 
>