[Dcmlib] Integration gdcm dans ITK

[Mathieu Malaterre]

> --> Mathieu
>    au sujet de la licence :
>    - après avoir bien phosphoré sur GPL, LGPL, BSD (il semblerait qu'il 
> y en ai encore une autre qui s'appelle MIT, non?), on est arrivé à la 
> conclusion que, à partir du moment où on avait 'ouvert' le source, afin 
> de le mettre à la disposition du reste de l'humanité, la manière dont il 
> est utilisé était un peu secondaire. (qq'un me rectifiera si j'ai mal 
> interprété)

Parfait, mon mail etait une sorte de verification de derniere minute. Il 
y bcp de licenses opensource differentes, je crois que microsoft ou sun 
en a publie une recement...

>   - 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' ;)

>      (un certain nombre de bugs sont déja traités, pour pouvoir malgrè 
> tout traiter les images bug-ées uxquelles nous sommes confrontés.

C'etait mon avis quand j'ai propose GDCM comme solution.

>      Ma position, c'est que si c'est le problème est simple à 
> contourner, on le traite;       Si c'est *vraiment* du not-kosher Dicom 
> impossible à résoudre en un temps raisonnable, on fait comme e-film :
>       on dit à l'interlocuteur de prévenir son fournisseur que ses 
> images sont erronnées.

je suis d'accord.

>  - 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 certain 
ici grince des dents.

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

> (je ne suis pas absolument sur d'avoir tout bien respecté, en ce qui 
> concerne la licence de IJG (fichiers README, disclamer, etc   :-(

Ok, je vais voir ce qu'on a fais de notre cote.

Mathieu