Interfaçage de la librairie graphique CLITK avec la norme ...

Auteur : Laurent ZAGNI

Version : 1.6 Date de création : 03/09/2006 Dernière mise à jour : 03/09/2006

Groupe de recherche Rayonnements, Images, Oncologie, Centre Léon-Bérard 28, rue Laennec 69 373 LYON Cedex 08

Interfaçage de la librairie graphique CLITK avec la norme DICOM-RT pour la manipulation de contours d’anatomie

définis sur TPS

Interfaçage de la librairie graphique CLITK avec la norme DICOM-RT pour la manipulation de contours

sur 40

SOMMAIRE

1 GLOSSAIRE................................................................................................................................3 2 Introduction..................................................................................................................................4 3 Analyse des besoins .....................................................................................................................5

3.1 Normes DICOM-RT et RT Structure Set Object.................................................................5 3.1.1 Norme DICOM : ..........................................................................................................5 3.1.2 DICOM-RT..................................................................................................................6 3.1.3 RT Structure Set...........................................................................................................8

3.2 Fonctionnalités voulues........................................................................................................9 3.3 Diagramme de flux.............................................................................................................10

4 Spécification détaillées ..............................................................................................................11 4.1 Choix d’implémentation de la norme.................................................................................11

4.1.1 Attributs DICOM retenus...........................................................................................11 4.1.2 Lecture des points de contours et calcul d’index d’image 3D ...................................12 4.1.3 Lecture et Ecriture de fichiers DICOM......................................................................13 4.1.4 Format de fichier maison : RTS de stockage des contours ........................................13

4.2 Génie logiciel .....................................................................................................................14 4.2.1 GDCM........................................................................................................................14 4.2.2 Insight Segmentation and Registration Toolkit (ITK) ...............................................14 4.2.3 Command - Lines ITK (CLITK)................................................................................15 4.2.4 Contraintes de qualité.................................................................................................15

5 Conception et réalisation............................................................................................................17 5.1 Structures de données choisies...........................................................................................17

5.1.1 Diagramme de classes UML des containers ..............................................................17 5.1.2 Diagramme de classes des entrées/sorties..................................................................17

5.2 Exécutables ........................................................................................................................18 5.2.1 clitkDicomInfos .........................................................................................................18 5.2.2 clitkDicomRTStructToRTS .......................................................................................18 5.2.3 clitkRTSInfos .............................................................................................................18 5.2.4 clitkRTSToDicomRTStruct .......................................................................................19 5.2.5 clitkRTSToImage.......................................................................................................19

5.3 Interfaces des classes réalisées...........................................................................................19 6 Conclusion .................................................................................................................................20 7 Références bibliographiques ......................................................................................................21 8 Annexes......................................................................................................................................22

8.1 Tableaux de Conformité DICOM ......................................................................................22 8.2 Manuel des classes réalisées ..............................................................................................28

8.2.1 clitk::DicomRTStructSetFileReader Class Reference ...............................................28 8.2.2 clitk::DicomRTStructSetFileWriter Class Reference ................................................29 8.2.3 clitk::RTStructSet Class Reference............................................................................30 8.2.4 clitk::RTStructSetGrid Class Reference ....................................................................32 8.2.5 clitk::RTStructSetRoi Class Reference......................................................................33 8.2.6 clitk::RTStructSetContour Class Reference...............................................................35 8.2.7 clitk::RTSFileReader Class Reference.......................................................................36 8.2.8 clitk::RTSFileWriter Class Reference .......................................................................37 8.2.9 clitkDicomRTIOCommon.h File Reference..............................................................38

8.3 Exemple d’utilisation de GDCM .......................................................................................39 8.4 Norme DICOM-RT............................................................................................................40

1


sur 40

GLOSSAIRE DICOM : Digital Imaging Communication in Medicine [DIC01], norme pour l’échange d’images et de données médicales. Dosimétrie : en radiothérapie, ensemble des opérations qui permettent de connaître la dose de rayonnements et sa répartition dans le corps, les différents tissus et la tumeur traitée. Logiciel de planimétrie : en radiothérapie, le logiciel de planimétrie permet la préparation le suivi et le contrôle d’un traitement en se basant sur une image scanner du patient. La première étape de la préparation d’un traitement est le contourage des ROIs. ROI : ROI est l’acronyme de Region Of Interest en anglais. En planimétrie, il s’agit d’un terme générique qui englobe toutes les structures saisies manuellement sur l’image brute du patient (organes à risques, tumeur, isocentre des faisceaux, etc…). Dans le cas des organes à risques et de la tumeur, le médecin délimite ces volumes en procédant à un contourage 2D coupe par coupe de l’image scanner 3D du patient. Contour : ligne de délimitation d’un volume sur une coupe 2D. Structure Set (Ensemble des structures) : terme adopté par la norme DICOM désignant un ensemble de ROI.

Coupe scanner (CT slice) : La tomodensitométrie plus vulgairement scanner ou CT-scan en anglais est une technique d'imagerie médicale. Le patient est balayé par un faisceau de rayons X qui tourne autour de lui. Des récepteurs sont chargés de mesurer l'intensité des rayons après leur passage dans le corps du patient. Les données collectées sont traitées par ordinateur et permettent de reconstruire les vues en coupe des organes (CT-slice) dans un plan perpendiculaires à l’axe du patient. L’assemblage de ces coupes forme une image 3D du patient.


sur 40

2 Introduction La radiothérapie est une des techniques de traitement du cancer. Elle permet de délivrer au moyen de photons et/ou d’électrons une dose (énergie déposée par unité de masse) dans un volume tumoral tout en épargnant au maximum les tissus sains environnant.

Avant chaque traitement, on cherche à prévoir les doses qui seront déposées dans le corps du patient pendant son traitement. C'est la phase de dosimétrie. Afin de pouvoir déterminer et valider les doses reçues au sein de certains volumes tels que le volume de la cible (tumeur) ou ceux des Organes à Risques (OAR), il est nécessaire de disposer de masques définissant ces volumes sur les images de l’anatomie du patient. Dans le cadre de la préparation d’un traitement en radiothérapie, ces volumes sont en fait contourés à la souris sur chacune des coupes 2D de l’image scanner du patient par un médecin ou par un physicien. Les contours ainsi définis, de même que toutes les autres informations nécessaires au traitement, sont exportables dans un format spécifique à la radiothérapie : DICOM-RT. Pour importer ces contours sur notre plateforme de traitement d’image CLITK, il est donc nécessaire de lire le format DICOM-RT et de définir les structures de données adéquates pour manipuler ces contours. Notons par ailleurs que si ces contours sont des informations cruciales pour la planification des traitements en radiothérapie, le temps pour contourer manuellement sur toutes les coupes est très long (compter environ deux à trois heure pour chaque plan de traitement d’un patient). Une autre idée en développement au laboratoire est d’automatiser en partie ce fastidieux travail en déformant les contours d’une coupe à une autre par recalage. Ce travail nécessite aussi l’importation depuis DICOM-RT.


sur 40

3 Analyse des besoins

3.1 Normes DICOM-RT et RT Structure Set Object

3.1.1 Norme DICOM : Les professionnels du médical et les fabricants d’équipements biomédicaux ont développé le standard DICOM, Digital Imaging Communication in Medicine [DIC01] pour l’échange d’images et de données médicales. La norme a été créée par l’ACR (American College Of Radiology) en association avec la NEMA (National Electrical Manufactures Association) et en est aujourd’hui à sa troisième version.

DICOM permet, à partir d’un document de conformité émis par chaque machine respectant cette norme, d’interconnecter des appareils. Son deuxième point fort est qu’elle permet aussi de rendre unique chaque ensemble de données produit et de lui associer des informations spécifiques.

DICOM est utilisée dans de nombreuses spécialités médicales mettant en jeu des appareillages médicaux lourds. Elle spécifie un grand nombre d’opérations comme le stockage, l’échange, le traitement ou l’impression de données. Ces opérations sont définies par des Service Class. Celles-ci regroupent plusieurs SOP Class définissant précisément sur quel objet (plan de traitement de radiothérapie, coupe tomographique…) va porter ce service.

Les objets sont définis par des Information Object Definition (IOD) présentant les attributs décrivant l’objet. Ces attributs sont regroupés en modules. Les attributs DICOM sont identifiés de façon unique par un Tag Element codé sur 32 bits représenté par une paire de nombres en héxadécimal. Par exemple, [3006|0002] => Structure Set Label. Au sein d’un IOD, les modules n’ont pas tous la même importance, certains sont obligatoires (mandatory M), d’autres optionnels (user-defined U), enfin certains obligatoires sous certaines

([DIC01] PS 3.4)


sur 40

conditions (conditional C). De même au sein d’un module, chaque attribut est d’un type donné. Ces types sont définis en [DIC01] PS 3.5 :

Type Signification 1 � obligatoirement présent dans l’objet

� obligatoirement rempli (longueur du champs de valeur doit être différente de 0) 1C � obligatoire sous certaines conditions

� Si présent, obligatoirement rempli (longueur du champs de valeur doit être différente de 0)

2 � obligatoirement présent dans l’objet � pas obligatoirement rempli (longueur du champs de valeur peut être égale à 0)

2C � obligatoire sous certaines conditions � Si présent, pas obligatoirement rempli (longueur du champs de valeur peut être

égale à 0) 3 � optionnel (attribut peut être absent et/ou avoir une longueur de champs de valeur

nulle) Un service DICOM peut être employé en tant qu’utilisateur (Service Class User – SCU) ou que fournisseur (Service Class Provider – SCP). Par exemple pour la Media Storage Class, un appareil en mode SCU écrit un fichier tandis qu’en mode SCP, il en lit un. Le document de conformité ([DIC01] PS 3.5) va préciser pour chacun des modules d’un IOD quels sont les attributs qu’il implémente (SCU) et lit (SCP) et comment il le fait. Il se doit de respecter les obligations données par les types de ces attributs. On pourra se reporter aux exemples de documents de conformité donnés pour les systèmes de planimétrie (préparation de traitements de radiothérapie) General Electric Advantage en [DIC03] et CMS Xio en [DIC04]. Nous cherchons ici à lire et écrire des fichier de contours, par conséquent la classe qui nous intéresse ici est la Media Storage Service Slass ([DIC01] PS 3.4).

3.1.2 DICOM-RT L’extension DICOM-RT propose un ensemble d’objets correspondant aux données requises à toutes les étapes de préparation et de suivi d’un traitement en radiothérapie.

RT Image ([DIC01] PS 3.3 A.17) Cet objet contient des informations sur les images liées à la radiothérapie tels que celles produites par les simulateurs traditionnels, les simulateurs virtuels et les imageurs portals. Il contient notamment les modules, RT Series, RT Image, Cine, Multi-Frame et autres. RT Plan ([DIC01] PS 3.3 A.20) Cet objet contient les données géométriques et dosimétriques spécifiques à un faisceau de rayon X par exemple les angles et les intensités des faisceaux d’irradiation. Une instance de l’objet RT plan fait référence généralement à une instance de l’objet RT Structure Set pour définir un système de coordonnées et les structures de l’ensemble du patient. RT Dose ([DIC01] PS 3.3 A.18) Cet objet contient les données des doses à prescrire selon les systèmes de planification du traitement. On y trouve par exemple les données de doses tri-dimensionnelles, des courbes d’isodose, etc…


sur 40

Diagramme de workflow présentant la norme DICOM-RT

Diagramme Entités-Associations de l’extension DICOM-RT ([DIC01] PS 3.3 p 56)

RT Structure Set IOD ([DIC01] PS 3.3 A.19)


sur 40

Cet objet contient toutes les informations liées à l’anatomie du patient et entrées manuellement par le médecin, par exemple la position et forme des organes ciblés. Les modules contenus dans un objet RT Structure Set concernent le patient (PATIENT), l’étude (STUDY), la série d’image CT (IMAGE SERIES), l’équipement (EQUIPMENT) et les structures (STRUCTURE) qui contiennent un ensemble de ROI (Region Of Interest) pour chacune desquelles on dispose d’un ensemble de contours (liste de points formant une ligne courbe ouverte ou fermée) les délimitant sur chaque coupe scanner et un ensemble d’observations diverses. L’objectif de notre librairie est d’accéder aux contours tracés par le médecin autour de la tumeur et de certains organes et enregistrés sur le logiciel de planimétrie. Sur le diagramme de workflow précédent, l’objet correspondant à cette activité (ROIs drawing) est l’objet RT-Structure Set. Seul l’objet RT Dose peut contenir aussi les informations de contourage (Voir tableau suivant).

Localisation des informations sur les structures contourées ([DIC01] PS 3.3 p101) : RT Dose RT Struct Set

Structure Set C M

ROI Contour C M

RT Dose ROI C

RT ROI Observations M

3.1.3 RT Structure Set Le tableau suivant donne les différents modules contenus dans l’objet RT Structure Set (PS 3.3 p 127). On se rapportera au document donné en annexe sur DICOM pour obtenir la description des attributs contenus dans chaque module.


sur 40

3.2 Fonctionnalités voulues Les fonctionnalités ont été proposées et validées lors de réunions hebdomadaires sur les trois premières semaines du projet avec Vlad Boldea, chercheur dans l’équipe et David Sarrut, chef de l’équipe. Des fonctionnalités ont été ajoutées ou enlevées en fonction de ce que permettait ou non la norme DICOM-RT, étudiée parallèlement.

LISTE DES FONCTIONNALITES ATTENDUES

1. Afficher tout le contenu arborescent d’un fichier DICOM RT-Structure-Set 2. Lire les contours contenus dans un fichier DICOM RT-Structure-set 3. Etre capable de lire en plus dans un fichier DICOM RT-Structure-Set les informations suivantes :

- Etude concernée : nom / date / heure - Structure Set : nom / date / heure - Pour chaque ROI : id / nom / description / volume / observation / méthode de génération /

type / interpréteur de type - Pour chaque contour de chaque ROI: id / type de géométrie / liste de points

4. Dans un fichier DICOM RT-Structure-Set, être capable de modifier les informations et les contours associés à un ROI donné ou d’ajouter un ROI. 5. Stocker dans un fichier « .RTS » les contours en binaire, et, dans un entête ASCII les informations associées présentées en 3. Les contours qui se présentaient sous forme de listes de points avec 3 coordonnées dans le fichier DICOM RT-Structure-Set doivent être maintenant stockés dans le fichier « .RTS » sous forme de listes d’entiers donnant le numéro de chaque point dans l’image 3D numérisée du patient (ces numéros sont appelés offset en référence à la dénomination choisie dans la librairie ITK, [ITK01]). 6. Modifier les informations d’un fichier DICOM RT-Structure-Set avec les informations contenues dans un fichier RTS 7. Tracer tout ou partie du contenu d’un fichier RTS dans une image 3D au format « maison » de l’équipe : le VOX


sur 40

3.3 Diagramme de flux Les flèches oranges représentent les flux de contours entre les différentes entités logicielles.


sur 40

4 Spécification détaillées

4.1 Choix d’implémentation de la norme

4.1.1 Attributs DICOM retenus Ces attributs seront copiés dans des structures de données en mémoire dans un premier temps puis dans les fichiers RTS qui seront en usage au laboratoire. Module/Attribute Reference/Tag Usage/Type General Study Module (C.7-3, DICOM 2006 PS 3.3, page 259) M

• Study ID [0020|0010] 1 • Study Time [0008|0030] 2 • Study Date [0008|0020] 2

Structure Set Module (C.8-41, DICOM 2006 PS 3.3, page 469) M

• Structure Set Label [3006|0002] 1 • Structure Set Name [3006|0004] 3 • Structure Set Date [3006|0008] 2 • Structure Set Time [3006|0009] 2 Structure Set ROI Sequence [3006|0028] 3

• >ROI Number [3006|0022] 1C • >ROI Name [3006|0026] 2C • >ROI Description [3006|0028] 3 • >ROI Volume [3006|002C] 3 • >ROI Generation Algorithm [3006|0036] 2C

ROI Contour Module (C.8-42, DICOM 2006 PS 3.3, page 473) M

ROI contour Sequence [3006|0039] 1 • >Referenced ROI Number [3006|0084] 1 • >ROI Display Color [3006|002A] 3 Contour Sequence [3006|0040] 3

• >>Contour Number [3006|0048] 3 • >>Contour Geometric Type [3006|0042] 1C • >>Contour Data [3006|0050] 1C

RT ROI Observations Module (C.8-44, DICOM 2006 PS 3.3, page 476) M

RT ROI Observations Sequence [3006|0080] 1 • >Referenced ROI Number [3006|0084] 1 • >ROI Observation Label [3006|0085] 3 • >ROI Observation Description [3006|0088] 3 • >ROI Interpreted Type [3006|00A4] 2C • >ROI Interpreter [3006|00A6] 2C

Note 1 : les attributs en italiques ne sont pas copiés mais seulement utilisés par l’algorithme de lecture pour regrouper les informations ayant trait à un même ROI. Note 2 : en théorie pour un seul ROI il peut y avoir plusieurs observations stockées dans le module RT ROI Observations Module. Dans la pratique, rares sont les systèmes qui implémentent cette possibilité. Dans notre cas, comme nous ne souhaitons conserver qu’une observation par ROI, notre algorithme de lecture prend seulement la


sur 40

dernière (dernier objet). De même en écriture, si il y’a plusieurs observations stockées pour le ROI que l’on souhaite modifier, c’est la dernière observation qui sera écrasée. Note 3 : L’attribut Contour Number ne figure pas nécessairement dans la séquence des contours. En son absence, on prendra le numéro de l’objet dans la sequence des contours (Contour sequence) + 1 pour donner un identifiant unique à chaque contour.

4.1.2 Lecture des points de contours et calcul d’in dex d’image 3D Dans le champ DICOM Contour Data ([3006|0050]) donnant la liste des points de chaque contour sont donnés pour chaque point, ses coordonnées selon x, y et z en mémoire dans le repère du patient (repère physique). Or ces points doivent être maintenant stockés dans le fichier « .RTS » sous forme de listes d’entiers donnant le numéro de chaque point dans l’image 3D numérisée du patient (ces entiers sont appelé offset en référence à la dénomination choisie dans la librairie ITK, [ITK01]). Cela nécessite d’abord de connaître les coordonnées entières de chaque point dans le repère de l’image (appelé index en référence à la dénomination choisie dans la librairie ITK, [ITK01]). Correspondance entre le repère des points de l’image et le repère du patient Pour établir une correspondance entre le repère du patient et celui de l’image, en supposant que les axes de l’image et de ceux du repère du patient ont les mêmes sens et directions, on va avoir besoin des informations suivantes :

- Origine du repère de l’image dans le repère du patient - Espacement des voxels dans le repère du patient (spacing)

Notons que les images 3D sur lesquelles les médecins ont dessiné les contours sont en fait des ensembles de coupes 2D représentées chacune par un objet DICOM CT Image. Dans ces objets, le repère est donné par les attributs du module Image Plane Module ([DIC01] PS 3.3 C.7-10) :

• L’attribut Image Position (Patient) [0020,0032] donne les coordonnées sur x, y et z du coin supérieur gauche de l’image (centre du premier voxel transmis). Il donne en fait l’origine du repère du patient.

• L’attribut Image Orientation (Patient) [0020,0037] donne la matrice de rotation de correspondance de l’image 2D dans l’image 3D du patient (il donne les 3 cosinus des angles formés avec les axes du patient).

• L’attribut Pixel Spacing [0028,0030] donne la distance physique dans le patient entre les centres des pixels adjacents sur l’axe x et l’axe y.

• L’attribut Slice Thickness [0018,0050] donne l’épaisseur de la coupe. • L’attribut Slice Location [0020,1041] donne la position de la coupe sur l’axe z.

Note 1 : Toutes les distances sont données en mm. Note 2 : dans la pratique, pour simplifier les algorithmes on ne prend en compte les fichiers que si Image Orientation est égal à [1 0 0 0 1 0] (ce qui signifie que les axes de l’image et de ceux du repère du patient ont les mêmes sens et directions). Cette matrice semble être la plus couramment implémentée par les logiciels de planimétrie ([DIC03] et [DIC04]). Calcul d’index (coordonnées des pixels dans l’image) Une fois déterminées, les coordonnées des points déterminées dans le repère de l’image sont arrondies à 0 chiffre après la virgule afin de connaître les coordonnées des pixels correspondant. Si les coupes d’un même volume 3D ont toujours la même épaisseur, il n’est pas obligatoire qu’elles soient exactement à égale distance les unes des autres et c’est rarement le cas dans la réalité (imprécision mécanique lors du déplacement du patient dans le faisceau d’acquisition). Si l’on veut éviter que des points se retrouvent sur de mauvaises coupes lors du calcul des index correspondants, on peut déterminer l’index en z d’un point en cherchant quelle est la coupe dont l’attribut slice


sur 40

location est la plus proche, l’index du point en z est alors égal au numéro de la coupe le plus proche (coupes rangées dans l’ordre croissant de l’attribut slice location). Calcul d’offsets (numéro du pixel dans l’image) Une fois les index de chaque point obtenus, il est nécessaire de connaître les 2 dimensions de l’image sur x et y afin d’obtenir pour chaque index, un offset qui identifie un pixel de l’image par un entier. Ces dimensions sont données pour les images DICOM au sein du module Image Pixel Macro, la dimension de l’image sur x est donnée par l’attribut Columns [0028|0011], celle en y par Rows [0028|0010]. On utilise ensuite la formule suivante :

x y x z x yoffset index index dim index dim dim= + × + × ×

Calcul inverse Lors de l’écriture de contours au format DICOM, Il nous est nécessaire de faire le chemin inverse, c’est-à-dire de calculer à partir des offsets les coordonnées dans le repère du patient. On associera pour cela aux contours stockés en mémoire et dans les fichiers RTS les quatre informations nécessaires pour recalculer les coordonnées des points à partir des index :

- Espacement des voxels, sur x, y et z (champ spacing dans notre fichier) - Taille des images sur x et y et z (champ size dans notre fichier) - Origine du repère du patient (champ origin dans notre fichier) - éventuellement : liste des positions des coupes en z (champ slice locations dans notre

fichier) Note 1 : La taille des images sur z n’a pas d’utilité dans les calculs, c’est donc une donnée à valeur informative. Note 2 : De même si la liste des positions des coupes est renseignée, connaître l’espacement des voxels sur z n’a pas d’intérêt dans les calculs.

4.1.3 Lecture et Ecriture de fichiers DICOM Lorsqu’on souhaite lire un fichier DICOM RT-Structure-Set, il y a deux possibilités :

- Soit on indique le nom du fichier DICOM RT-Structure-Set à lire et on entre manuellement chacun des paramètres spacing, size et origin.

- Soit on indique un répertoire contenant à la fois le fichier DICOM RT-Structure-Set voulu et l’ensemble des fichiers DICOM CT-slice correspondants où le programme ira lire les attributs nécessaires.

On donne en annexe des tableaux de conformité présentant pour chaque attribut d’un fichier DICOM RT Structure Set les conditions auxquelles il doit répondre lorsqu’il est lu par notre classe de lecture et quelles sont les modifications éventuelles qu’il reçoit lorsqu’on fusionne le fichier DICOM avec des données issues d’un fichier RTS. Note : Il est à noter que les chaînes de caractères des éléments DICOM ne peuvent pas être de longueur impaire. C’est pourquoi on trouve souvent un caractère nul à la fin des chaînes de caractères.

4.1.4 Format de fichier maison : RTS de stockage de s contours 1. Entête ASCII: L’entête contient le contenu des différents attributs retenus hormis Contour Data (voir 3.1.1) séparés par des caractères de fin de ligne :


sur 40

Study ID Study time Study date Structure Set Label Structure Set Name Structure Set Date Stucture Set Time Size Spacing Origin Slice locations Number of ROIs

ROI ID ROI name ROI description ROI volume ROI generation algorithm ROI observation label ROI observation description ROI interpreted type ROI interpreter ROI display color Number of contours

Contour ID Contour geometric type number of contour points

Contour ID Contour geometric…

ROI ID ROI nam…

2. Index en binaires : Après l’entête, le conten de l’attribut, le contenu de l’attribut Contour Data, soit les index des points des contours (numéros des points dans l’image 3D) sont tous écrits à la suite sur 4 octets (entiers longs non signés : de 0 à 4 294 967 295). Les informations de l’entête permettent de les séparer en listes correspondant aux contours des différents ROI.

Note 1 : Pour représenter un champ DICOM vide, à la place de la valeur associée, l’entête contient la chaîne "///////NULL" Note 2 : Les champs composés de plusieurs valeurs (par exemple Slice Locations ou Origin) ont leurs valeurs séparées par des espaces.

4.2 Génie logiciel

4.2.1 GDCM GDCM (Grass roots DiCoM [GDC01]) est une librairie C++ dédiée à la lecture et au parsage de fichiers médicaux DICOM. Elle implémente le standard DICOM part 5 qui se concentre sur les format des fichiers d'images DICOM et la représentation des données. C’est un logiciel libre du laboratoire CREATIS qui est proposé en licence BSD et est compilable sur la quasi-totalité des plateformes. Sa souplesse d’utilisation, sa robustesse, son excellente maintenance et le fait qu’elle est devenue le parser DICOM par défaut de ITK (voir ci-dessous) nous ont fait nous tourné vers GDCM pour lire et parser nos fichiers DICOM.

4.2.2 Insight Segmentation and Registration Toolkit (ITK) ITK (Insight Toolkit [ITK01]) est un autre logiciel open source qui est prévu pour permettre le recalage et la segmentation d'images médicales. La segmentation et un procédé pour identifier et

n ROIS

mi contours

Structure Set Infos


sur 40

classer des données provenant d'une image échantillonnée. Typiquement, il s’agit d'images acquises par un appareillage médical comme les scanners tomodensitométriques (CT-scan) ou les IRM (MRI-scan). Le recalage est la tâche consistant à mettre en correspondance des points entre ces données. Techniquement, ITK est une librairie multi-plateforme implémentée en C++, qui utilise l'environnement CMake pour gérer la compilation. L'implémentation de ITK se réfère aux méthodes de programmation générique (utilisation des template) qui permet de proposer un code plus efficace et de découvrir la plupart des problèmes à la compilation et non à l'exécution. Le développement de la librairie ITK se fait de manière continue et est le produit du travail d'une communauté internationale qui l'utilise, la maintient et étend ses fonctions. La démarche de programmation mise en place est ici l'Extreme Programming qui repose sur un procédé itératif conception-implémentation-test. La communication est la clef de voûte de ce système. Pour valider chaque nouvelle version dans son intégralité sur plusieurs plateformes, la communauté ITK utilise un procédé automatisé de tests (DART) qui centralise les résultats de tests effectués par un grand nombre d’équipe dans le monde.

4.2.3 Command - Lines ITK (CLITK) CLITK (Command-Lines ITK [CLI01]) est une surcouche à la librairie ITK qui met à la disposition des utilisateurs un ensemble d'outils ou les types des pixels et les dimensions des images n'ont pas à être spécifiés mais sont compris par le programme. Le développement de CLITK, interne à l’équipe de recherche, est prévu en 3 phases :

1. Ecriture d'outils non-génériques CLITK 2. Ecriture d'outils génériques 3. Développement d'un générateur de code pour implémenter automatiquement le reste des

outils. Pour le moment, le développement en est à la deuxième phase. C’est au sein de cette surcouche que seront implémentées nos classes de lecture DICOM RT-Structure Set.

4.2.4 Contraintes de qualité Démarche qualité globale et bonnes pratiques Le développement devra se faire selon certaines normes de qualité afin d’éviter au maximum la perte de travaux, la production de codes illisibles ou provoquant des erreurs d’intégration.

- Afin que l’on puisse développer sans gêner les autres développeurs qui travaillent sur la même librairie, on utilisera CVS (Concurrent Version System [CVS01]) qui permet de centraliser le code source sur un serveur, d’être averti des modifications et de pouvoir télécharger facilement celles-ci. C’est aussi un moyen de sauvegarder son travail sur un serveur distant et de garder toutes les versions développées.

- Avant d’implémenter, on fera systématiquement valider les architectures afin d’éviter les erreurs grossières de conception.

- Le code devra être commenté de façon â être compréhensible rapidement par un autre membre de l’équipe.

Harmonisation du développement avec celui de CLITK Afin d’être en harmonie avec les méthodes de développement déjà utilisées par clitk [CLI01] :

- On utilisera le même outil de compilation : CMAKE [CMK01] et le même outil de production d’exécutables : Gengetopt [GGO01].

- On vérifiera aussi que l’on exploite au maximum les classes et fonctions communes déjà écrites afin d’éviter les doublons dans le code.

- On utilisera toujours et seulement le namespace clitk pour toutes les classes développées. Harmonisation des classes avec ITK


sur 40

De même puisque CLITK est une surcouche de ITK dont elle utilise la plupart des algorithmes et modes de représentation des images ([ITK02]), on restera dans la même philosophie.

- On utilisera au maximum les classes et types proposés par ITK notamment pour la représentation des images et de leurs paramètres (itk ::ImageBase ::OffsetType pour les offset, IndexType pour les index, PointType pour les points, SpacingType, SizeType pour les paramètres des images et RGBPixelType pour les couleurs.)

- Afin de gérer l’espace mémoire au mieux, ITK implémente un reference counter qui comptabilise pour chaque objet en mémoire, le nombre de références sur cet objet afin de pouvoir le détruire immédiatement quand il n’est plus utilisé. Tous nos objets hormis RTStructSetGrid hérite de l’objet itk ::LightObject qui implémente le reference counter

- Enfin, comme on l’a vu GDCM est le parser DICOM par défaut de ITK. Toutefois l’utiliser en passant par ITK impose d’utiliser une surcouche inutile qui a tendance à rigidifier GDCM et à limiter les possibilités. C’est pourquoi on accédera aux données DICOM en invoquant directement les méthodes et classes de GDCM (cf en annexe, un exemple d’utilisation de GDCM).

Tests et recette utilisateurs Pour valider les classes, on codera les exécutables répondant aux fonctionnalités voulues et on testera chacune des fonctionnalités avec plusieurs fichiers différents issus d’un logiciel de planimétrie utilisé en clinique au Centre Léon Bérard. La recette utilisateur se fera par des démonstrations montrant les possibilités de chaque éxécutable. De plus, il sera mis à disposition sur le site web wiki de l’équipe de recherche le manuel d’utilisation des exécutables ([CLI01] / http://www.creatis.insa-lyon.fr/rio/CLITK/DICOM-RT_Tools). Recette développeurs Le but du travail est avant tout de fournir aux chercheurs des classes leur permettant d’importer et de manipuler des contours. Par conséquent, on veillera à ce que la passation du relais se fasse dans les meilleures conditions :

- En impliquant l’équipe dans l’étape de définition de l’architecture et en évoquant avec elle les problèmes lorsqu’ils surviennent pendant la phase de réalisation.

- En commentant le code produit et en le rendant le plus compréhensible possible. - Par la documentation du code à l’aide d’un générateur automatique de documentation tel

que Doxygen et la mise à disposition à tous de cette documentation. - Par la livraison du présent rapport.


sur 40

5 Conception et réalisation

5.1 Structures de données choisies

5.1.1 Diagramme de classes UML des containers

5.1.2 Diagramme de classes des entrées/sorties


sur 40

5.2 Exécutables Voici la liste des exécutables générés avec Gengetopt [GGO01].

5.2.1 clitkDicomInfos Cet exécutable sert à visualiser l’entête d’un fichier DICOM (.DCM). Usage: clitkDicomInfos [OPTIONS]... [FILES]... -h, --help Print help and exit -V, --version Print version and exit --config=STRING Config file -i, --input=STRING DICOM input file

5.2.2 clitkDicomRTStructToRTS Cet exécutable sert à sauvegarder le contenu d'un fichier DICOM-RT-Structure-Set (.DCM) dans un fichier binaire RT-Structure (.RTS) :

- Soit en indiquant l’adresse du fichier DICOM-RT-Structure-Set et tous les paramètres nécessaires au calcul des offsets des points dans l’image 3D du patient à partir de leurs coordonnées dans le repère du patient.

- Soit en indiquant un répertoire contenant à la fois le fichier DICOM-RT-Structure-Set et l’ensemble des coupes (fichiers DICOM CT-slice) formant l’image 3D du patient. Le programme se débrouille pour récuperer les paramètres nécessaires tous seuls.

Usage: clitkDicomRTStructToRTS [OPTIONS] -h, --help Print help and exit -V, --version Print version and exit --config=STRING Config file -i, --input=STRING DICOM input RT-Structure-Set file -o, --output=STRING RTS output file -x, --x=DOUBLE x-coordinate of the upper left hand corner -y, --y=DOUBLE y-coordinate of the upper left hand corner -z, --z=DOUBLE z-coordinate of the upper left hand corner --dx=DOUBLE pixel spacing on x --dy=DOUBLE pixel spacing on y --dz=DOUBLE pixel spacing on z --nx=INT image size along x --ny=INT image size along y --nz=INT image size along z -d, --ctdir=STRING DICOM CT-slices and RT-Structure-Set directory

5.2.3 clitkRTSInfos Cet exécutable sert à :

- lire un fichier RT-Structure (.RTS) et afficher tout le contenu - lire un fichier RT-Structure (.RTS) et afficher le contenu pour un ROI - lire un fichier RT-Structure (.RTS) et afficher le contenu pour un contour

Usage: clitkRTSInfos [OPTIONS] -h, --help Print help and exit -V, --version Print version and exit --config=STRING Config file


sur 40

-i, --input=STRING input rts file -r, --roi=INT ROI to print (ID) -c, --contour=INT contour to print (ID)

5.2.4 clitkRTSToDicomRTStruct Cet exécutable sert à modifier le contenu d'un fichier DICOM-RT-Structure-Set (.DCM) avec les infos issues d'un fichier RT-Structure-Set (.RTS). On spécifie si on souhaite que tous les rois soient fusionnés dans le fichier DICOM en sortie ou bien un seul, ou bien un seul contour d’un ROI donné. Il est possible aussi d’ajouter un ROI ou un Contour. Enfin, si l’on ne fusionne qu’un roi ou un contour, on peut spécifier quel R0I ou contour on veut écraser et même nettoyer le fichier de tout les autres ROIS. Usage: clitkRTSToDicomRTStruct [OPTIONS] -h, --help Print help and exit -V, --version Print version and exit --config=STRING Config file -i, --inputD=STRING Dicom input file -j, --inputR=STRING RTS input file -o, --output=STRING Dicom output file -r, --roi=INT ROI to merge (ID) -c, --contour=INT contour to merge (ID) -s, --toroi=INT destination ROI ID -d, --tocontour=INT destination contour ID --clean Erase previous data from Dicom Input File (default=off)

5.2.5 clitkRTSToImage Cet exécutable sert à :

- dessiner les points des contours de tous les rois issus d'un fichier RT-Structure (.RTS) vers un fichier image

- dessiner les points de tous les contours d'un roi issu d'un fichier RT-Structure (.RTS) vers un fichier image (.VOX)

- dessiner les points d’un contour d'un roi issu d'un fichier RT-Structure (.RTS) vers un fichier image (.VOX)

Usage: clitkRTSToImage [OPTIONS] -h, --help Print help and exit -V, --version Print version and exit --config=STRING Config file -i, --input=STRING RTS input file -o, --output=STRING VOX output file -r, --roi=INT ROI to draw (ID) -c, --contour=INT contour to draw (ID) --bg=INT background color --fg=INT foreground color (contours color)

5.3 Interfaces des classes réalisées Voir manuel des classes en annexe.


sur 40

6 Conclusion Nous avons atteint l’objectif qui était de lire et d’écrire des contours à la norme DICOM.Le système après plusieurs tests semble être relativement robuste et très facile d’utilisation pour la lecture des fichiers DICOM et la récupération des contours. L’algorithme est rapide et effectue un nombre suffisant de contrôle de validité des fichiers pour se prémunir des fichiers malformés ou incomplets. Cependant, l’importation de contours DICOM depuis des postes de planimétrie étant plus marginale que l’exportation, on n’a moins de recul sur cette opération. C’est pourquoi il est plus difficile de garantir la conformité des fichiers écrits par notre librairie avec les logiciels de planimétrie utilisés en clinique. L’utilisateur trouvera en annexe du présent rapport un tableau de conformité lui permettant de cerner facilement des incompatibilités éventuelles. Les objets développés pour implémenter les contours d’organes dans la librairie graphique clitk reconnaissent la notion de Structure Set, de ROI et de contour ainsi que les liens de parenté qui les relient. Ces objets sont manipulables indépendamment de manière flexible et intuitive tout en étant assez bien conçus pour éviter des erreurs d’intégrité (notion de grille d’image 3D associée à chaque objet). L’utilisation de smart pointers au lieu des pointeurs habituels pour ces objets permet en plus une gestion de la mémoire optimisée et sécurisée. L’utilisation de fichiers RTS « maison » contenant les listes de points de contours sous forme de numéros de pixels (offsets) codés en binaires permet d’optimiser les espaces disques et mémoire en divisant environ par 3 la taille des données (de 1 Mo à 500 ko en moyenne). Enfin, d’un point de vue personnel, ce travail qui venait en prolongement de mon travail de recherche fut très intéressant. J’ai pu mettre en pratique mes connaissances en gestion de projet et en ingénierie en écrivant les fonctionnalités, et en proposant une architecture. Cela s’est fait lors de réunions et de points d’avancement hebdomadaires avec les autres chercheurs de l’équipe. Cela a été l’occasion de découvrir aussi la norme d’échange de données médicales DICOM qui est implémentée dans la plupart des appareillages et logiciels médicaux. J’ai beaucoup appris aussi techniquement en travaillant sur les librairies graphiques CLITK et ILR qui sont implémentées de façon très moderne (utilisation de smart pointers, de pipelines, implémentation de design patterns). J’ai ainsi pu me perfectionner dans ma connaissance du C++, dans ses aspects avancés, comme les templates, qui sont très utilisés en imagerie.


sur 40

7 Références bibliographiques [CLI01] Gimenez C, Zagni, L. and others. « CLITK (Command Line ITK) documentation». Site de l’équipe Rayonnements – Images - Oncologie du Centre Léon Bérard, [En ligne]. http://www.creatis.insa-lyon.fr/rio/CLITK. (Dernière consultation le 28/08/2006) [CMK01] Kitware Inc. « Cross-platform Make ». CMake website. [En ligne]. http://www.cmake.org/HTML/Index.html. (Dernière consultation le 01/09/2006) [CVS01 CVS group « CVS - Concurrent Version System». Non GNU Software Website. [En ligne]. http://www.nongnu.org/cvs/ (Dernière consultation le 01/09/2006) [DIC01] National Electric Manufacturers Association. « Digital Imaging and Communications in Medicine». [En ligne]. http://medical.nema.org/dicom/2006/. (Dernière consultation le 28/08/2006) [DIC02] Seda, S. "Introduction à la norme DICOM et l’extension DICOM-RT Introduction à Geant4", rapport de DESS "Compétence complémentaire en Informatique ". Université Lyon I. 2004 [DIC03] General Electric. «Advantage Sim 6.0 Conformance Statement». GE healthcare : DICOM conformance statements for radiotherapy, [En ligne]. http://www.gehealthcare.com/usen/interoperability/dicom/products/rt_dicom.html. (Dernière consultation le 28/08/2006) [DIC04] Computerized Medical Systems. «XiO DICOM Conformance Statement ». Site de CMS, [En ligne]. www.cms-stl.com/docs/xio/XIO_DCS_A.pdf. (Dernière consultation le 28/08/2006) [DOX01] Van Heesch D. « Doxygen Introduction». Doxygen homepage. [En ligne]. http://www.stack.nl/~dimitri/doxygen/index.html. (Dernière consultation le 01/09/2006) [GDC01] CREATIS laboratory. « Gdcm Home Page». Site du laboratoire Creatis, [En ligne]. http://www.creatis.insa-lyon.fr/Public/Gdcm/. (Dernière consultation le 28/08/2006) [GGO01] GNU. « Gengetopt 2.17». [En ligne]. http://www.gnu.org/software/gengetopt/gengetopt.html. (Dernière consultation le 28/08/2006) [ITK01] Ibanez et al.. «ITK Software Guide updated for ITK 2.4». Site de la communauté Insight Toolkit, [En ligne]. http://www.itk.org/ItkSoftwareGuide.pdf. (Dernière consultation le 28/08/2006) [ITK02] ITK Community. « ITK Doxygen generated documentation». Site de la communauté Insight Toolkit, [En ligne]. http://www.itk.org/Doxygen/html/index.html. (Dernière consultation le 28/08/2006)


sur 40

8 Annexes

8.1 Tableaux de Conformité DICOM On présente pour chaque module obligatoire de l’objet RT Structure Set, les différents attributs de la norme et les traitements et vérification faits par notre programme en lecture (validation et copie de certains attributs dans un fichier RTS) et en écriture (fusion d’un fichier RTS dans un fichier DICOM)

Patient Module

Attribut Tag Type Notes

Patient’s Name (0010,0010) 2 LECTURE : non lu ECRITURE : inchangé

Patient ID (0010,0020) 2 LECTURE : non lu ECRITURE : inchangé

Patient’s Birth Date (0010,0030) 2 LECTURE : non lu ECRITURE : inchangé

Patient’s Sex (0010,0040) 2 LECTURE : non lu ECRITURE : inchangé

General Study Module


Study Instance UID

(0020,000D) 1 LECTURE : Si on laisse le programme parser un ensemble de fichiers DICOM CT Slice (coupes scanner) pour déterminer les paramètres de l’image du patient, cet attribut doit être identique dans les fichiers CT-Slice et le fichier RT Structure Set lu ECRITURE : inchangé


sur 40

Study Date (0008,0020) 2 LECTURE : attribut copié ECRITURE : valeur prise dans le fichier RTS à fusionner

Study Time (0008,0030) 2 LECTURE : attribut copié ECRITURE : valeur prise dans le fichier RTS à fusionner

Referring Physicians’ Name

(0008,0090) 2 LECTURE : non lu ECRITURE : inchangé

Study ID (0020,0010) 2 LECTURE : attribut copié ECRITURE : valeur prise dans le fichier RTS à fusionner

Accession Number


RT Series Module


Modality (0008,0060) 1 LECTURE : doit être égal à « RTSTRUCT » ECRITURE : doit être égal à « RTSTRUCT » pour le fichier DICOM

Series Instance UID

(0020,000E) 1 LECTURE : non lu ECRITURE : inchangé

Series Number


Series Description (00008,103E) 3 LECTURE : non lu ECRITURE : inchangé

General Equipment Module


Manufacturer (0008,0070) 2 LECTURE : non lu ECRITURE : inchangé

Station Name (0008,1010) 3 LECTURE : non lu ECRITURE : inchangé

Manufacturer’s Model Name


Device Serial Number


Software Versions (0018,1020) 3 LECTURE : non lu ECRITURE : inchangé

Structure Set Module


Structure Set Label

(3006,0002) 1 LECTURE : attribut copié ECRITURE : valeur prise dans le fichier RTS à fusionner

Structure Set Name

(3006,0004) 3 LECTURE : attribut copié si trouvé dans le fichier sinon la valeur «NULL» est copiée ECRITURE : valeur prise dans le fichier RTS à fusionner


sur 40

Instance Number (0020,0013) 3 LECTURE : non lu ECRITURE : inchangé

Structure Set Date (3006,0008) 2 LECTURE : attribut copié ECRITURE : valeur prise dans le fichier RTS à fusionner

Structure Set Time (3006,0009) 2 LECTURE : attribut copié ECRITURE : valeur prise dans le fichier RTS à fusionner

Referenced Frame of Reference Sequence

(3006,0010) 3 LECTURE : cet attribut doit être présent et la séquence doit contenir au moins un objet ECRITURE : cet attribut doit être présent dans le fichier DICOM et contenir au moins un objet

>Frame of Reference UID

(0020,0052) 1C LECTURE : au moins l’un des attributs Frame of Reference UID doit être égal à ceux données pour tous les ROIs dans la Structure Set Roi Sequence ECRITURE : dans le fichier DICOM au moins l’un des attributs Frame of Reference UID doit être égal à ceux données pour tous les ROIs dans la Structure Set Roi Sequence

>RT Referenced Study Sequence

(3006,0012) 3 LECTURE : cet attribut doit être présent et la séquence doit contenir au moins un objet ECRITURE : cet attribut doit être présent dans le fichier DICOM et doit contenir au moins un objet

>>Referenced SOP Class UID

(0008,1150) 1C LECTURE : non lu ECRITURE : inchangé

>>Referenced SOP Instance UID


>>RT Referenced Series Sequence


>>>Series Instance UID

(0020,000E) 1C LECTURE : non lu ECRITURE : inchangé

>>>Contour Image Sequence


>>>>Referenced SOP Class UID


>>>> Referenced SOP Instance UID


Structure Set ROI Sequence

(3006,0020) 3 LECTURE : si cet attribut n’est pas présent dans le fichier à lire, cela signifie qu’il n’y a pas de ROIs à stocker en mémoire. ECRITURE : si cet attribut n’est pas présent dans le fichier DICOM à fusionner, il sera créé

>ROI Number (3006,0022) 1C LECTURE : cet attribut doit être présent et complété pour permettre d’indexer tous les ROI lus et stockés en mémoire ECRITURE : cet attribut doit être présent et valoir un entier dans le fichier DICOM pour permettre de modifier les attributs concernant les ROI qui sont présents dans le fichier RTS à fusionner.

>Referenced Frame of Reference UID

(3006,0024) 1C LECTURE : la valeur de cet attribut doit être identique pour tous les ROI de la séquence et être retrouvée dans la séquence Referenced Frame of Reference Sequence.


sur 40

ECRITURE : inchangé

>ROI Name (3006,0026) 2C LECTURE : attribut copié ECRITURE : prends la valeur Roi name si le ROI fait partie des ROIs du fichier RTS à fusionner, sinon laissé tel quel

>ROI Description (3006,0028) 3 LECTURE : attribut copié ECRITURE : prends la valeur Roi description si le ROI fait partie des ROIs du fichier RTS à fusionner, sinon laissé tel quel

>ROI Volume (3006,002C) 3 LECTURE : attribut copié ECRITURE : prends la valeur Roi volume si le ROI fait partie des ROIs du fichier RTS à fusionner, sinon laissé tel quel

>ROI Generation Algorithm

(3006,0036) 2C LECTURE : attribut copié ECRITURE : prends la valeur Roi generation algorithm si le ROI fait partie des ROIs du fichier RTS à fusionner, sinon laissé tel quel

>ROI Generation Description


RT ROI Contour Module


Roi Contour Sequence

(3006,0039) 1 LECTURE : cet attribut doit être présent dans le fichier sinon lancement d’une exception ECRITURE : cet attribut doit être présent dans le fichier DICOM sinon lancement d’une exception

>Referenced ROI Number

(3006,0084) 1 LECTURE : cet attribut doit être lu pour permettre d’associer les attributs de la séquence avec des ROI en mémoire. Seuls seront lus les objets dont la valeur de l’attribut Referenced ROI Number a déjà été lue dans la séquence Structure Set ROI Sequence ECRITURE : cet attribut doit être lu pour permettre de fusionner correctement les données. Seuls les ROIs avec un numéro correspondant à un ROI du fichier RTS à fusionner auront des attributs modifiés

>ROI Display Color

(3006,002A) 3 LECTURE : attribut copié si trouvé sinon la valeur « 255 255 255 » est copiée ECRITURE : prends la valeur Roi Display Color si le ROI fait partie des ROIs du fichier RTS à fusionner, sinon laissé tel quel

>Contour Sequence

(3006,0040) 3 LECTURE : attribut lu si présent ECRITURE : les objets correspondant à des contours des ROIs à fusionner seront modifiés

>>Contour Number

(3006,0048) 3 LECTURE : si cet attribut n’est pas présent ou complété pour tous les objets de la séquence, il ne sera pas lu, et les contours seront numérotés selon le numéro de l’objet dans la séquence. ECRITURE : prends la valeur Contour number d’un Contour du fichier RTS à fusionner, sinon laissé tel quel.

>>Attached Contours



sur 40

>>Contour Image Sequence


>>>Referenced SOP Class UID


>>>Referenced SOP Instance UID


>>Contour Geometric Type

(3006,0042) 1C LECTURE : attribut copié (doit être présent impérativement pour lire les contours) ECRITURE : prends la valeur Contour geometric type d’un Contour du fichier RTS à fusionner, sinon laissé tel quel.

>>Contour Slab Thickness


>>Number of Contour Points

(3006,0046) 1C LECTURE : non lu (lit directement les points) ECRITURE : la valeur de cet attribut est donnée par le nombre de points d’un Contour du fichier RTS à fusionner, sinon laissé tel quel.

>>Contour Data (3006,0050) 1C LECTURE : attribut lu et copié sous formes d’offset (voir 3.1.2) ECRITURE : prends la liste des coordonnées des points d’un Contour du fichier RTS à fusionner (les coordonnées sont calculées à partir des offsets comme décrit en 3.1.2), sinon laissé tel quel.

RT ROI Observations Module


RT ROI Observations Sequence

(3006,0080) 1 LECTURE : cet attribut doit être présent sinon lancement d’une exception. Seuls seront lus les objets dont la valeur de l’attribut Referenced ROI Number a déjà été lue dans la séquence Structure Set ROI Sequence. Par ailleurs, pour chaque ROI un seul objet de la séquence sera lu, le premier dans l’ordre de lecture. ECRITURE : doit être présent impérativement dans le fichier DICOM. Pour chaque ROI à fusionner, un seul objet de la séquence seulement sera modifié, le premier dans l’ordre de lecture.

>Observation Number


>Referenced ROI Number

(3006,0084) 1 LECTURE : cet attribut doit être présent pour permettre d’associer les attributs de la séquence avec des ROI en mémoire. (Seuls sont lus les objets dont la valeur de l’attribut Referenced ROI Number a déjà été lue dans la séquence Structure Set ROI Sequence) ECRITURE : seuls les objets correspondant à des ROIs à fusionner seront modifiés

>ROI Observation Label

(3006,0085) 3 LECTURE : attribut copié si trouvé dans le fichier sinon valeur «NULL» copiée ECRITURE : prends la valeur ROI observation label d’un ROI à fusionner, sinon laissé tel quel.

>RT ROI Interpreted Type

(3006,00A4) 2 LECTURE : attribut copié ECRITURE : prends la valeur ROI interpreted type d’un ROI à fusionner, sinon laissé tel quel.

>ROI interpreter (3006,00A6) 2 LECTURE : attribut copié ECRITURE : prends la valeur ROI interpreter d’un ROI à fusionner, sinon laissé tel quel.


sur 40

SOP Common Module


SOP Class UID (0008,0016) 1 LECTURE : doit être égal à « 1.2.840.10008.5.1.4.1.1.481.3 » (RT Structure Set Storage) ECRITURE : idem pour le fichier à fusionner

SOP Instance UID (0008,0018) 1 LECTURE : non lu ECRITURE : inchangé

Specific Character Set


Instance Creation Date


Instance Creation Time


Instance Creator UID



sur 40

8.2 Manuel des classes réalisées Ces pages ont été générées à partir du code par l’outil Doxygen [DOX01] .

8.2.1 clitk::DicomRTStructSetFileReader Class Refer ence #include <clitkDicomRTStructSetFileReader.h>

8.2.1.1 Public Types • typedef DicomRTStructSetFileReader Self • typedef itk::LightObject Superclass • typedef itk::SmartPointer< Self > Pointer • typedef itk::SmartPointer< const Self > ConstPointer

8.2.1.2 Public Member Functions • void SetDirectory (const char *directory) • void SetFileName (const char *filename) • void SetImageAttributes (const double x, const double y, const double z, const double dx, const double dy, const

double dz, const long int nx, const long int ny, const long int nz) • void Read () • RTStructSet::Pointer GetOutput () • itkNewMacro (Self) • itkTypeMacro (DicomRTStructSetFileReader, Object)

8.2.1.3 Protected Attributes • RTStructSet::Pointer m_Output • gdcm::File * m_InputDicomFile • bool m_ImageAttributesDefined

8.2.1.4 Private Member Functions • DicomRTStructSetFileReader () • ~DicomRTStructSetFileReader ()


sur 40

8.2.2 clitk::DicomRTStructSetFileWriter Class Refer ence #include <clitkDicomRTStructSetFileWriter.h>

8.2.2.1 Public Types • typedef DicomRTStructSetFileWriter Self • typedef itk::LightObject Superclass • typedef itk::SmartPointer< Self > Pointer • typedef itk::SmartPointer< const Self > ConstPointer

8.2.2.2 Public Member Functions • void SetInputFileName (const char *filename) • void SetOutputFileName (const char *filename) • void ClearSequences () • void MergeWithRTStructSet (const RTStructSet::Pointer inputRTStructSet) • void Write () const • itkNewMacro (Self) • itkTypeMacro (DicomRTStructSetFileWriter , Object)

8.2.2.3 Protected Attributes • gdcm::File * m_InputDicomFile • char * m_OutputFileName • char * m_ReferenceFrameUID

8.2.2.4 Private Member Functions • DicomRTStructSetFileWriter () • ~DicomRTStructSetFileWriter ()


sur 40

8.2.3 clitk::RTStructSet Class Reference #include <clitkRTStructSet.h>

8.2.3.1 Public Types • typedef RTStructSet Self • typedef itk::LightObject Superclass • typedef itk::SmartPointer< Self > Pointer • typedef itk::SmartPointer< const Self > ConstPointer • typedef RTStructSetRoi Roi • typedef std::map< unsigned int, Roi::Pointer > RoiList • typedef RoiList::iterator iterator • typedef RoiList::const_iterator const_iterator

8.2.3.2 Public Member Functions • const_iterator begin () const • const_iterator end () const • unsigned int size () const • bool empty () const • const_iterator find (const unsigned int roiNumber) const • void erase (iterator pos) • void erase (const unsigned int roiNumber) • void clear (void) • void Print (std::ostream &os=std::cout, std::string const &indent="") const • Roi::Pointer SetRoi (const unsigned int roiNumber, const Roi::Pointer roi) • Roi::Pointer GetRoi (const unsigned int roiNumber) const • void DeleteRoi (const unsigned int roiNumber) • long GetNumberOfContourPoints (void) const • itkNewMacro (Self) • itkTypeMacro (RTStructSet, Object) • const char * GetStudyID (void) • const char * GetStudyTime (void) • const char * GetStudyDate (void) • const char * GetStructSetLabel (void) • const char * GetStructSetName (void) • const char * GetStructSetDate (void) • const char * GetStructSetTime (void) • const RTStructSetGrid * GetStructSetGrid (void) • void SetStudyID (const char *id) • void SetStudyTime (const char *time) • void SetStudyDate (const char *date) • void SetStructSetLabel (const char *label) • void SetStructSetName (const char *name) • void SetStructSetDate (const char *date) • void SetStructSetTime (const char *time) • void SetStructSetGrid (const RTStructSetGrid * grid)

8.2.3.3 Protected Attributes • RTStructSetGrid * m_Grid • char * m_StudyID • char * m_StudyTime • char * m_StudyDate • char * m_StructSetLabel • char * m_StructSetName • char * m_StructSetDate • char * m_StructSetTime • RoiList m_RoiList


sur 40

8.2.3.4 Private Member Functions • RTStructSet () • ~RTStructSet ()


sur 40

8.2.4 clitk::RTStructSetGrid Class Reference #include <clitkRTStructSetGrid.h>

8.2.4.1 Public Types • typedef RTStructSetGrid Self • typedef itk::ImageBase< 3 > ImageBaseType • typedef ImageBaseType::IndexType IndexType • typedef ImageBaseType::SizeType SizeType • typedef ImageBaseType::RegionType RegionType • typedef ImageBaseType::SpacingType SpacingType • typedef ImageBaseType::PointType PointType • typedef ImageBaseType::OffsetValueType OffsetValueType • typedef std::vector< PointType::ValueType > SliceLocationsType

8.2.4.2 Public Member Functions • const SizeType GetSize (void) • const SpacingType GetSpacing (void) • const PointType GetOrigin (void) • const SliceLocationsType GetSliceLocations (void) • const bool IsSpacingRegular (void) • void SetSize (const SizeType size) • void SetSpacing (const SpacingType spacing) • void SetOrigin (const PointType origin) • void SetSliceLocations (SliceLocationsType sliceLocations) • bool operator== (const RTStructSetGrid& x, const RTStructSetGrid& y)

8.2.4.3 Protected Attributes • PointType m_Origin • SizeType m_Size • SpacingType m_Spacing • SliceLocationsType m_SliceLocations

8.2.4.4 Private Member Functions • RTStructSetGrid () • ~RTStructSetGrid ()


sur 40

8.2.5 clitk::RTStructSetRoi Class Reference #include <clitkRTStructSetRoi.h>

8.2.5.1 Public Types • typedef RTStructSetRoi Self • typedef itk::LightObject Superclass • typedef itk::SmartPointer< Self > Pointer • typedef itk::SmartPointer< const Self > ConstPointer • typedef RTStructSetContour Contour • typedef std::map< unsigned int, Contour::Pointer > ContourList • typedef ContourList::iterator iterator • typedef ContourList::const_iterator const_iterator • typedef itk::RGBPixel< unsigned char > PixelType

8.2.5.2 Public Member Functions • const_iterator begin () const • const_iterator end () const • unsigned int size () const • bool empty () const • const_iterator find (const unsigned int contourNumber) const • void erase (iterator pos) • void erase (const unsigned int contourNumber) • void clear (void) • void Print (std::ostream &os=std::cout, std::string const &indent="") const • RTStructSetContour::Pointer SetContour (const unsigned int contourNumber, const

RTStructSetContour::Pointer contour) • RTStructSetContour::Pointer GetContour (const unsigned int contourNumber) const • void DeleteContour (const unsigned int contourNumber) • long GetNumberOfContourPoints (void) const • itkNewMacro (Self) • itkTypeMacro (RTStructSetRoi, Object) • char * GetRoiName (void) • const char * GetRoiDescription (void) • const char * GetRoiVolume (void) • const char * GetRoiGeneAlgo (void) • const char * GetRoiObservationLabel (void) • const char * GetRoiObservationDescription (void) • const char * GetRoiInterpretedType (void) • const char * GetRoiInterpreter (void) • const PixelType GetRoiDisplayColor (void) • const RTStructSetGrid * GetStructSetGrid (void) • const void SetRoiName (const char *name) • void SetRoiDescription (const char *desc) • void SetRoiVolume (const char *volume) • void SetRoiGeneAlgo (const char *algo) • void SetRoiObservationLabel (const char *label) • void SetRoiObservationDescription (const char *desc) • void SetRoiInterpretedType (const char *type) • void SetRoiInterpreter (const char *interp) • void SetRoiDisplayColor (const PixelType color) • void SetStructSetGrid (const RTStructSetGrid * grid)

8.2.5.3 Protected Attributes • RTStructSetGrid * m_Grid • ContourList m_ContourList • char * m_RoiName


sur 40

• char * m_RoiDescription • char * m_RoiVolume • char * m_RoiGeneAlgo • char * m_RoiObservationLabel • char * m_RoiObservationDescription • char * m_RoiInterpretedType • char * m_RoiInterpreter • PixelType m_RoiDisplayColor

8.2.5.4 Private Member Functions • RTStructSetRoi () • ~RTStructSetRoi ()


sur 40

8.2.6 clitk::RTStructSetContour Class Reference #include <clitkRTStructSetContour.h>

8.2.6.1 Public Types • typedef RTStructSetContour Self • typedef itk::LightObject Superclass • typedef itk::SmartPointer< Self > Pointer • typedef itk::SmartPointer< const Self > ConstPointer • typedef itk::ImageBase< 3 > ImageBaseType • typedef ImageBaseType::OffsetValueType OffsetValueType • typedef std::vector< OffsetValueType > OffsetList • typedef OffsetList::iterator iterator • typedef OffsetList::const_iterator const_iterator

8.2.6.2 Public Member Functions • iterator begin () • iterator end () • const_iterator begin () const • const_iterator end () const • unsigned int size () const • bool empty () const • void push_back (const OffsetValueType offset) • iterator insert (iterator pos, const OffsetValueType offset) • iterator erase (iterator pos) • void clear (void) • void Print (std::ostream &os=std::cout, std::string const &indent="") const • iterator InsertOffset (iterator pos, const OffsetValueType offset) • iterator DeleteOffset (iterator pos) • void AddOffset (const OffsetValueType offset) • OffsetList GetOffsetList (void) • const void SetOffsetList (const OffsetList offsetList) • itkNewMacro (Self) • itkTypeMacro (RTStructSetContour, Object) • const char * GetContourGeometricType (void) • const RTStructSetGrid * GetStructSetGrid (void) • void SetContourGeometricType (const char *type) • void SetStructSetGrid (const RTStructSetGrid * grid)

8.2.6.3 Protected Attributes • OffsetList m_OffsetList • RTStructSetGrid * m_Grid • char * m_ContourGeometricType

8.2.6.4 Private Member Functions • RTStructSetContour () • ~RTStructSetContour ()


sur 40

8.2.7 clitk::RTSFileReader Class Reference #include <clitkRTSFileReader.h>

8.2.7.1 Public Types • typedef RTSFileReader Self • typedef itk::LightObject Superclass • typedef itk::SmartPointer< Self > Pointer • typedef itk::SmartPointer< const Self > ConstPointer

8.2.7.2 Public Member Functions • void SetFileName (const char *filename) • RTStructSet::Pointer GetOutput (void) const • void Read () • itkNewMacro (Self) • itkTypeMacro (RTSFileReader, Object)

8.2.7.3 Protected Attributes • RTStructSet::Pointer m_OutputRTStructSet • char * m_FileName

8.2.7.4 Private Member Functions • RTSFileReader () • ~RTSFileReader ()

8.2.7.5 Static Private Member Functions • static const char * RTSFileReader::ReadCharArrayAttribute (const std::string att)


sur 40

8.2.8 clitk::RTSFileWriter Class Reference #include <clitkRTSFileWriter.h>

8.2.8.1 Public Types • typedef RTSFileWriter Self • typedef itk::LightObject Superclass • typedef itk::SmartPointer< Self > Pointer • typedef itk::SmartPointer< const Self > ConstPointer

8.2.8.2 Public Member Functions • void SetFileName (const char *filename) • void SetInput (const RTStructSet::Pointer rtStructSet) • void Write () • itkNewMacro (Self) • itkTypeMacro (RTSFileWriter , Object)

8.2.8.3 Protected Attributes • RTStructSet::Pointer m_InputRTStructSet • char * m_FileName

8.2.8.4 Private Member Functions • RTSFileWriter () • ~RTSFileWriter ()

8.2.8.5 Static Private Member Functions • static const char * WriteCharArrayAttribute (const char *att)


sur 40

8.2.9 clitkDicomRTIOCommon.h File Reference

8.2.9.1 Namespaces • namespace clitk

8.2.9.2 Functions • const std::string clitk::ConvertDicomSeparatorsToSpace (const std::string iString) • void clitk::TestDicomCTSerie (const gdcm::FileList serie) • void clitk::TestDicomRTStructSetFile (gdcm::File *file) • void clitk::TestFileExistanceAndReadability (const char *filename) • gdcm::SQItem * clitk::GetAnItemWithTagValue (gdcm::SeqEntry *seqEntry, const uint16_t group, const

uint16_t elem, const int value, const bool writeItem) • std::string clitk::WriteDicomContourData (const RTStructSetContour::OffsetList offsetList, const

RTStructSetGrid * grid) • RTStructSetContour::OffsetList clitk::ReadDicomContourData (const std::string contourData, const

RTStructSetGrid::PointType origin, const RTStructSetGrid * grid) • RTStructSetGrid::IndexType clitk::OffsetToIndex (const RTStructSetGrid::OffsetValueType offset, const

RTStructSetGrid::SizeType size) • RTStructSetGrid::OffsetValueType clitk::IndexToOffset (const RTStructSetGrid::IndexType index, const

RTStructSetGrid::SizeType size) • RTStructSetGrid::IndexType clitk::PointToIndex (const RTStructSetGrid::PointType point, const

RTStructSetGrid::PointType origin, const RTStructSetGrid::SpacingType spacing, const RTStructSetGrid::SliceLocationsType sliceLocations)

• RTStructSetGrid::PointType clitk::IndexToPoint (const RTStructSetGrid::IndexType index, const RTStructSetGrid::PointType origin, const RTStructSetGrid::SpacingType spacing, const RTStructSetGrid::SliceLocationsType sliceLocations)


sur 40

8.3 Exemple d’utilisation de GDCM #include "clitkDicomStruct_ggo.h" #include "clitkIO.h" #include "gdcmFile.h" #include "gdcmDocEntry.h" #include "gdcmSeqEntry.h" int main(int argc, char * argv[]) { // init command line GGO(args_info); CLITK_INIT; gdcm::File *header = new gdcm::File(); header->SetFileName(args_info.input_arg); header->SetMaxSizeLoadEntry(16384); //necessary for big contours (>250 points) header->Load(); gdcm::DocEntry* premier = header->GetFirstEntry(); gdcm::DocEntry* second = header->GetNextEntry(); uint16_t REFERENCED_FRAME_GROUP= = 0x3006, REFERENCED_FRAME_ENTRY= 0x0009; gdcm::SeqEntry* sequence = header->GetSeqEntry(REFERENCED_FRAME_GROUP,REFERENCED_FRAME_ENTRY); premier->Print(); std::cout<< std::endl; second->Print(); std::cout<< std::endl; sequence->Print(); std::cout<< std::endl; return 0; }

Résultat avec un fichier DICOM-RT Structure Set : V 0002|0000[UL] [Group Length] [190] x(be) B 0002|0001[OB] [File Meta Information Version] [gdcm::Binary data loaded;length = 2] S 3006|0010[SQ] [Referenced Frame of Reference Sequence] | --- SQItem number 0 | V 0020|0052[UI] [Frame of Reference UID] [2.16.840.1.114337.75252909586.5593.1152196173.0.2 ] | S 3006|0012[SQ] [RT Referenced Study Sequence] | | --- SQItem number 0 | | V 0008|1150[UI] [Referenced SOP Class UID] [1.2.840.10008.3.1.2.3.1 ] ==> [Detached Study Management SOP Class] | | V 0008|1155[UI] [Referenced SOP Instance UID] [2.16.840.1.114337.75252909586.5593.1152196173.0 ] | | S 3006|0014[SQ] [RT Referenced Series Sequence] | | | --- SQItem number 0 | | | V 0020|000e[UI] [Series Instance UID] [2.16.840.1.114337.75252909586.5593.1152196173.0.1.4 ]


sur 40

8.4 Norme DICOM-RT Voir document DICOM RT Modules sous forme papier (DICOM standard PS 3.3, C8-8, pp 449-593).

Interfaçage de la librairie graphique CLITK avec la norme ...

Documents

Transcript of Interfaçage de la librairie graphique CLITK avec la norme ...