Consultez le rapport

CREATIS - UCBL

Traitement de données scanner CT corps entier

Stage de fin d’études

PORTEJOIE pierre

10/09/2015

Stage de fin d’études – PORTEJOIE Pierre

1


2

CONTENU DU RAPPORT

1 Environnement ............................................................................................................................................... 4

1.1 CREATIS .................................................................................................................................................. 4

1.2 LBMC IFSTTAR ........................................................................................................................................ 4

2 Sujet ................................................................................................................................................................ 5

2.1 Le projet PIPER....................................................................................................................................... 5

2.2 Problématique ....................................................................................................................................... 5

2.3 Organisation du temps .......................................................................................................................... 6

2.3.1 Etat de l’art / Prise en main .......................................................................................................... 7

2.3.2 Conversion des données ............................................................................................................... 7

2.3.3 Stitching ........................................................................................................................................ 7

2.3.4 Cropping ........................................................................................................................................ 7

2.3.5 Création de l’Atlas ......................................................................................................................... 7

2.3.6 Recalage / Segmentation .............................................................................................................. 7

2.3.7 Rapport ......................................................................................................................................... 7

2.4 Méthodologie de travail ........................................................................................................................ 8

2.4.1 Outils ............................................................................................................................................. 8

2.4.2 Organisation du développement .................................................................................................. 8

2.4.3 License .......................................................................................................................................... 8

3 Travail réalisé ................................................................................................................................................. 9

3.1 Traitement des données ........................................................................................................................ 9

3.1.1 Conversion .................................................................................................................................... 9

3.1.2 Choix ........................................................................................................................................... 10

3.2 Stitching ............................................................................................................................................... 11

3.2.1 Première approche ..................................................................................................................... 11

3.2.2 Pipeline ....................................................................................................................................... 12

3.2.3 Validation .................................................................................................................................... 17

3.3 Rognage ............................................................................................................................................... 21


3

3.3.1 Première approche ..................................................................................................................... 21

3.3.2 Pipeline ....................................................................................................................................... 22

3.4 Recalage ............................................................................................................................................... 27

3.4.1 Méthode choisie ......................................................................................................................... 27

3.4.2 Résultats ..................................................................................................................................... 29

4 Conclusion, retour d’expérience et projet professionnel............................................................................. 31

5 Glossaire ....................................................................................................................................................... 32

6 Bibliographie ................................................................................................................................................ 33

6.1 Publications ......................................................................................................................................... 33

6.2 Outils.................................................................................................................................................... 33


4

1 ENVIRONNEMENT

Mon stage s’est effectué entre 2 laboratoires : CREATIS et le laboratoire de Biomécanique et Mécanique des

Chocs (LBMC), unité mixte Université Lyon 1 / IFSTTAR. Il aura constitué à transférer des compétences en

traitement d’images de CREATIS vers le LBMC n’ayant que peu d’expérience en la matière.

Les deux laboratoires participent au Labex PRIMES.

1.1 CREATIS

Le laboratoire Creatis est une Unité de recherche en imagerie médicale regroupant environ 200 personnes

dont les domaines de recherche privilégiés sont au croisement de deux grands axes:

-L’identification des grandes questions de Santé pouvant être abordées par l'Imagerie

- L’identification des verrous théoriques en traitement du signal & des images, en modélisation & en

simulation numérique dédiés à l’imagerie du vivant.

Creatis répond à ces défis par une approche transdisciplinaire reposant sur une organisation matricielle

mettant en interaction ses six équipes de recherche appartenant aux sciences et technologies de l’information

et de la communication, aux sciences pour l’ingénieur et aux sciences du vivant.

Citation de : https://www.creatis.insa-lyon.fr/site/

J’ai été, dans ce laboratoire, rattaché à la tutelle de Thomas Grenier.

1.2 LBMC IFSTTAR

Le LBMC (UMR_T 9406), est une Unité Mixte de Recherche Ifsttar - Université Claude Bernard Lyon 1. Elle

dépend du Département Transport Santé Sécurité (TS2) de l'Ifsttar et de la Faculté des Sciences et

Technologies, Département de Mécanique, de l’UCBL.

Le LBMC développe des recherches dans le domaine des transports en lien avec la protection et le confort des

usagers et dans le domaine de la santé en lien avec l'orthopédie et la rééducation fonctionnelle, visant à

l’amélioration des conditions de vie des citoyens et pour une mobilité durable et responsable. Les compétences

de l’Unité s’articulent autour des Sciences et Techniques, en particulier la Mécanique (Biomécanique, Systèmes

Dynamiques, Structures, Matériaux, …) avec une ouverture forte vers les Sciences du Vivant (Physiologie,

Chirurgie orthopédique et de réadaptation, Ergonomie …). Pour mener à bien son programme scientifique et

ses activités de recherche, le LBMC est organisé autour de quatre équipes correspondant à des thèmes de

recherche propres

- Biomécanique des Chocs

- Biomécanique et Orthopédie

- Biomécanique et Ergonomie

- Structures

Citation de : http://www.lbmc.ifsttar.fr/

La personne m’ayant encadré dans ce laboratoire fut Philippe Beillas, qui fait partie de l’équipe biomécanique

des chocs.


5

2 SUJET

2.1 LE PROJET PIPER

Dans le domaine de la sécurité, les modèles corps humain avancés pour la prévention des blessures basés sur

les modèles éléments finis ont le potentiel de représenter la variabilité de la population et de fournir des

modèles précis de prévention des blessures.

Cependant ces modèles corps humain avancés sont sous-utilisés dans l’industrie R&D pour cause de difficultés

à positionner les modèles –qui sont le plus souvent disponible dans une seule posture – dans l’environnement

véhicule et le manque de familles de modèles représentant la variabilité de la population.

L’objectif principal du projet PIPER, auquel j’ai tété rattaché, est de développer de nouveaux outils pour

positionner et personnaliser ces modèles corps humain avancés. En facilitant la génération de populations et

de modèles corps humains avancés pour des sujets spécifiques ainsi que leur usage dans des environnements

de production, ces outils permettront l’émergence de nouvelles applications dans la R&D pour la conception de

systèmes restreints ainsi que la création de nouveaux champs de recherche.

Le projet est fondé par la commission Européenne dans le programme FP7.

Il est coordonné par l’Université Claude Bernard (Philippe Beillas) et différents personnels du LBMC sont

impliqués dans le projet. Le projet regroupe 10 partenaires provenant de 5 pays différents et s’étale sur une

période de 3 ans et demi. Le budget total atteint 3,8 millions d’Euros dont 2,9 financés par la commission

Européenne.

2.2 PROBLEMATIQUE

Le projet se divise en 4 « work packages » (WP), j’ai été rattaché au WP2 dont l’un des objectifs de fournir des

descriptions statistiques qui serviront de support au changement de forme des modèles humains éléments

finis. Un grand nombre de scanners CT corps entier étant disponibles chez les partenaires, il est nécessaire de

segmenter les différentes parties du corps humain, tout d’abord les os puis éventuellement certains organes,

en partant de ces images.

Cette segmentation peut se faire manuellement mais elle prend un temps très long. 3 segmentations

complètes ont à ce jour été faites par plusieurs laboratoires à l’étranger (Angleterre et Inde.)

Mon rôle dans ce projet fut d’implémenter des outils afin d’automatiser certaines parties de la segmentation,

voire toutes. Je décrirai, dans la suite de ce rapport, les différents pipelines que j’ai développés.


6

2.3 ORGANISATION DU TEMPS

Le temps fut organisé de la façon suivante. Les différentes parties présentes dans la légende sont décrites et

détaillées par la suite.

Semaine Lundi Mardi Mercredi Jeudi Vendredi

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21


7

Etat de l’art / Prise en main

Conversion des données

Stitching

Cropping

Création de l’Atlas

Recalage / Segmentation

Rapport

2.3.1 ETAT DE L’ART / PRISE EN MAIN

Cette partie aura consisté à examiner l’état de l’art des différentes méthodes pouvant être employées lors des

étapes du projet. Il aura aussi été nécessaire de s’approprier les données, c’est-à-dire de comprendre leur

organisation et de sélectionner celles qui seront utilisées.

2.3.2 CONVERSION DES DONNEES

Les données étant dans un format de permettant pas de les traiter de façon optimale, il aura été nécessaire de

les convertir dans un format standard.

2.3.3 STITCHING

Les données corps entier étant séparées en plusieurs parties, il fut nécessaire de rassembler ces parties pour

obtenir une image finale correspondant à l’ensemble du corps.

2.3.4 CROPPING

Il aura été nécessaire, pour des questions d’utilisation de mémoire, de rogner une partie des données afin

d’avoir une image finale contenant simplement le corps, l’image de départ étant plus grande. On s’est aussi

attaché, dans cette partie, à supprimer des objets étrangers gênant les étapes suivantes.

2.3.5 CREATION DE L’ATLAS

Cette partie comprend la voxelisation d’un modèle maillé de référence en attribuant différents labels aux

différents os.

2.3.6 RECALAGE / SEGMENTATION

Ici on se sera attaché à recaler les différents corps sur le modèle de référence ainsi qu’à créer un pipeline

d’évaluation de la méthode.

2.3.7 RAPPORT

Rédaction du rapport de stage et préparation de la soutenance.


8

2.4 METHODOLOGIE DE TRAVAIL

2.4.1 OUTILS

Le développement du projet s’est fait autour de 2 principaux aspects :

- Analyse des outils existants, appropriation et utilisation de ceux-ci

- Développement de programmes pour le traitement d’images

La première partie du travail fut donc de rechercher si des outils existants correspondaient déjà aux objectifs, si

oui il aura fallu les rendre opérationnels pour le projet, sinon il aura fallu les développer à la main.

Les programmes ont été développés en C++ à l’aide de la bibliothèque de traitement d’images ITK puis scriptés,

d’abord en bash windows puis en bash Linux.

2.4.2 ORGANISATION DU DEVELOPPEMENT

Les différentes parties du projet ont toutes été développées selon un framework commun que l’on peut décrire

de la façon suivante :

- Description de la problématique

- Recherche de solutions existantes

o Appropriation puis utilisation de la solution existante

OU

o Développement d’une nouvelle solution

- Validation de la solution par un rapport de test

- Rédaction documentaire sur le fonctionnement de la solution et instructions pour sa mise en place

dans un environnement.

La partie logicielle a été stockée et enregistrée à l’aide du gestionnaire de versions CVS.

2.4.3 LICENSE

Les outils développés vont être publiés avec une licence Open Source. La licence choisie est Apache 2.0,

similaire à ITK. Celle-ci a été choisie pour des raisons de flexibilité avec les autres briques du projet.


9

3 TRAVAIL REALISE

Dans cette partie je vais lister les outils que j’ai mis en place en expliquant le raisonnement m’ayant conduit à

les développer.

3.1 TRAITEMENT DES DONNEES

Tout d’abord il est nécessaire de d’expliquer avec quelles données je travaillais et comment je les ai rendues

plus accessibles.

3.1.1 CONVERSION

Le projet a à sa disposition plus de 100 scans CT (rayons X) de sujets d’anatomie acquis dans des conditions

similaires. Ces scans comprennent le sujet complet depuis la tête jusqu’aux pieds. Il aurait été démesuré de

travailler sur la totalité des données, il m’a donc été transmis 16 scans CT.

Chaque scan pèse environ 10GO et est enregistré en format DICOM. Ce format n’est pas optimal pour pratiquer

du traitement d’images car il est constitué d’une collection de plusieurs milliers d’images organisées par

dossiers ou chaque image présente un sous-volume (slice) du scan (image 2D, partie de l’image finale 3D). Il a

donc été décidé de convertir ces images au format Nifti qui est plus facile à manipuler.

Pour cela j’ai dû développer 2 scripts et 2 exécutables. Ceux cis s’exécutent à la racine du dossier que l’on m’a

confié contenant toutes les données DICOM organisées dans différents dossiers.

- GetDicomSeries.exe : cet exécutable permet de récupérer les séries DICOM et de les ressortir

dans un document .csv. En effet les DICOM sont organisés par « séries » : un dossier contenant les

slices DICOM (2D) peut contenir plusieurs images 3D (la somme de toutes les images 2D ne

constitue pas forcément une image unique.) Cet exécutable permet donc d’obtenir la liste des

images 3D contenues dans un dossier DICOM

- DicomToNifti.exe / DicomToTiff.exe : ces exécutables permettent de convertir une image DICOM

en une image Nifti ou Tiff. Il faut cependant préciser le numéro de série que l’on aura obtenu

grâce à l’exécutable précédent.

- CreateNifti.bat : ce script utilise les 2 exécutables précédents pour créer un sous dossier Nifti dans

chaque dossier contenant des images DICOM et y inclure les images converties.

- RemoveSpaces.bat : ce script permet de supprimer les espaces dans les noms de dossiers afin que

le script précédent s’exécute correctement

Les exécutables ont été codés en C++ à l’aide de la bibliothèque très répandue en traitement d’images ITK. Les

scripts ont été codés en batch, langage de script de windows.


10

3.1.2 CHOIX DES DONNEES A TRAITER

Une fois les images converties, il est temps de constater de quoi est constituée chaque acquisition (sessions et

filtres). Quelles données a-t-on pour chaque sujet ? Les différents scans sont les suivants, tous sont de taille

512*512*x :

- Image haute résolution de la région tête cou à laquelle est appliqué le filtrage OS

- Image haute résolution de la région tête cou à laquelle est appliqué le filtrage MOU

- Image de la région tête cou à laquelle est appliqué le filtrage OS

- Image de la région tête cou à laquelle est appliqué le filtrage MOU

- Image de la région thorax abdomen pelvis à laquelle est appliqué le filtrage OS

- Image du de la région thorax abdomen pelvis à laquelle est appliqué le filtrage MOU

- Image des membres inférieurs (incluant le pelvis) à laquelle est appliqué le filtrage OS

- Image des membres inférieurs (incluant le pelvis) à laquelle est appliqué le filtrage MOU

- Parenchyme

Le filtrage OS permet d’avoir une meilleure visibilité des os, le filtrage MOU permet d’avoir une meilleure

visibilité des tissus mous (par exemple muscles.) Sur les images suivantes on peut voir que les contours sont

plus marqués pour le filtrage OS.

Figure 1 : comparaison des filtrages OS (droite) et MOU (gauche)

Pour la suite, comme on aura à traiter en priorité le squelette, on conservera seulement les images auxquelles

a été appliqué le filtrage OS.

La prochaine étape sera de reconstituer un corps entier à partir des différentes parties, pour cela il sera

nécessaire de « stitcher » les images. Afin de reconstituer le corps entier on veut que les images à rassembler

soient si possible de même résolution et que l’ensemble des images couvre bien le corps tout entier. Suite à

cette sélection, nous décidons de garder les images suivantes auxquelles nous donneront des noms simples :

- Image de la tête et du cou à laquelle est appliqué le filtrage OS : Tile_01

- Image thorax abdomen pelvis à laquelle est appliqué le filtrage OS : Tile_02

- Image des membres inférieurs à laquelle est appliqué le filtrage OS : Tile_03


11

3.2 STITCHING

L’objectif est maintenant de reconstituer le corps entier à partir des 3 images sélectionnées. N’ayant pas trouvé

d’équivalent français pour ce mot, on utilisera « stitching » pour désigner la mise en correspondance puis

fusion de 2 images afin de reconstituer une image continue.

3.2.1 PREMIERE APPROCHE

3.2.1.1 VERIFICATION DU CONTRASTE

Il convient d’abord de vérifier que les différentes images ont le même contraste (qu’il n’y a pas de différences

d’intensité entre les différentes tiles). Pour cela on effectue 2 vérifications, tout d’abord on regarde la

répartition des intensités sur une même zone de 2 images (ligne jaune.)

Figure 2 : comparaison des répartitions d’intensités sur une ligne de 2 sous volumes correspondant à la même partie anatomique

On compare ensuite la répartition de l’intensité sur 2 slices similaires de 2 tiles.

Figure 3 : comparaison des répartitions d’intensités sur 2 sous-volumes entiers appartenant à la même partie anatomique

Ces 2 constatations visuelles sont suffisantes pour déduire qu’il n’y a pas de différence de contraste

significatives entre les différentes tiles.


12

3.2.1.2 OUTILS EXISTANTS

J’ai donc cherché des outils permettant de réaliser le stitching mais il s’est avéré qu’aucun d’entre eux ne

correspondait à nos attentes :

- XuVTools : Permet seulement de stitcher en 2D.

- Slicer : Pas d’outils de stitching disponibles.

- Vaa3D : 4 plugins de stitching disponibles mais aucun n’est fonctionnel.

- Terastitcher : Permet seulement de stitcher en 2D.

De plus lors de cette recherche un nouveau problème est apparu : les tiles de peuvent être pas alignées à l’aide

d’une simple translation : en effet il existe une légère rotation entre Tile_02 et Tile_03 qu’il faudra corriger.

La première approche aura constitué à utiliser imageJ (Fiji) pour le stitching avec le plugin « Pairwise Stitching »

en corrigeant la rotation à la main. Pour cela on estime que le centre de rotation est le centre de l’image. Il est

constaté que la rotation varie entre 5° et -5°. Les résultats suivants comparent le stitching effectué par ImageJ

sans rotation (à gauche) et avec rotation (à droite.)

Figure 4 : comparaison du stitching effectué sans rotation (gauche) et avec rotation (droite)

Grâce à cette méthode, on peut obtenir une image corps entier à partir des 3 images de base cependant cela

requiert plusieurs manipulations qui peuvent s’avérer fastidieuses si on doit les reproduire sur 100 sujets. On

aura néanmoins prouvé que cela était possible, on va s’attacher par la suite à l’automatiser.

3.2.2 PIPELINE

Devant l’insatisfaction donnée par les outils existants, il a été décidé de développer en C++ un pipeline

permettant d’effectuer le stitching automatiquement sans intervention humaine dans le processus. En

réfléchissant à notre problème, on se rend compte qu’il peut être décomposé en 3 étapes principales :

- La recherche de la correspondance au niveau de la troisième dimension entre les 2 images à

stitcher

- La recherche de la transformation entre les deux images (car nous avions vu qu’il existait une

légère rotation)

- Et enfin la fusion des 2 images


13

Le pipeline d’exécution du stitching peut être résumé par le schéma suivant :

Figure 5 : pipeline d’exécution du stitching

Voyons maintenant ces étapes en détail.

3.2.2.1 RECHERCHE DU Z

3.2.2.1.1 METHODE

La première approche pour la recherche de la correspondance en Z entre les 2 images à stitcher a d’abord été

de comparer les slices unes à unes en utilisant comme métrique la somme des valeurs absolues des différences

entre elles. La recherche se faisait sur une partie définie de l’image afin de gagner en performances. Le

processus était le suivant pour 2 images dites I1 et I2.

- Extraction de la dernière slice d’I1

- Extraction d’une slice d’I2

- Calculer la somme des valeurs absolues des différences pixel à pixel

- Stocker la valeur obtenue si elle est inférieure à la valeur déjà enregistrée

- Répéter pour chaque slice d’I2


14

Cette méthode paraît efficace mais révèle beaucoup de faux positifs et n’est donc pas fiable. Ceci est dû au fait

qu’on utilise qu’une seule slice de chaque image pour trouver la similarité.

Une nouvelle méthode a donc été implémentée, cette fois utilisant une zone 3D de l’image en la comparant

avec une zone 3D de l’image de référence. Dans un soucis d’optimisation, on a cette fois utilisé la classe

itk::MeanSquaresImageToImageMetricv4 d’ITK pour la mesure de similarité. Les résultats obtenus furent

satisfaisants.

3.2.2.1.2 ARGUMENTS

La fonction développée permet donc de trouver la correspondance en Z en fournissant les arguments suivants :

- Image fixe

- Image mobile

- Approximation du Z évaluée par l’utilisateur 1

- Distance sur laquelle on doit rechercher le Z 2

- Pas entre chaque vérification 3

- Nom d’un fichier de sortie

Cette fonction renvoie la valeur du Z dans le fichier texte spécifié.

3.2.2.1.3 UTILISATION

Les arguments 1, 2 et 3 permettent d’optimiser la fonction au niveau de temps. En effet on pourrait scanner

toute l’image avec un pas de 1 mais cela prendrait un temps trop long pour que la fonction soit utilisable en

pratique.

Dans le script lançant le pipeline, nous avons utilisé cette fonction 2 fois afin d’optimiser le temps :

- On effectue une recherche grossière du Z sur la zone où l’on sait qu’il se situe (pour toutes les

images, c’est-à-dire les 16 qui m’ont été fournies) puis on renvoie la valeur grossière

- On effectue ensuite une recherche fine entre les 2 pas de la recherche grossière

Ceci permet d’obtenir une estimation optimale du Z.


15

3.2.2.2 RECHERCHE DE LA TRANSFORMATION

3.2.2.2.1 METHODE

Maintenant qu’on connait où se situe la correspondance entre les 2 images 3D, on va extraire dans chacune

une slice 2D en correspondance puis on va chercher à évaluer la transformation entre ces 2 images 2D si elle

existe.

On va donc effectuer un recalage 2D classique. L’outil que l’on va utiliser est la bibliothèque ITK.

Pour effectuer un recalage, ITK a besoin de 4 informations principales :

- Quel sera la métrique ?

- De quel type sera l’optimisation ?

- De quel type sera l’interpolation ?

- Quelle transformation sera utilisée ?

Pour la métrique on utilisera itk::MeanSquaresImageToImageMetric utilisant la moyenne au carré,

l’interpolation sera linéaire : itk:: LinearInterpolateImageFunction , l’optimisation par descente de gradient :

itk::RegularStepGradientDescentOptimizer et enfin la transformation permettra les rotation, translations et

changement d’échelle, ce que permet de faire itk::CenteredSimilarity2DTransform.


La fonction a besoin de 2 paramètres en entrée :

- Image fixe

- Image mobile

Et renvoie 2 sorties :

- L’image transformée

- Les paramètres de la transformation

Ce qui nous intéresse ici n’est pas l’image 2D transformée mais bien les paramètres de la transformation que

l’on applique ensuite en 3D pour faire correspondre l’image mobile avec l’image fixe.


16

3.2.2.3 FUSION DES IMAGES

3.2.2.3.1 PRINCIPE

Une fois le Z trouvé ainsi que le défaut induit par l’éventuelle transformation corrigé il faut fusionner les 2

images. On procède pour cela de la façon suivante pour fusionner Tile_01 et Tile_02 :

- On copie Tile_01 ligne par ligne dans une image plus grande (en hauteur) jusqu’à arriver à la zone

de fusion.

- Une fois dans la zone de fusion on copie une ligne de Tile_01 dont l’intensité est pondérée ainsi

qu’une ligne de Tile_02 dont l’intensité est inversement pondérée. La pondération est

décroissante jusqu’à la fin de la zone de fusion.

- On copie la fin de Tile_02 une fois la zone de fusion dépassée

Figure 6 : mécanisme de fusion de 2 images

3.2.2.3.2 ARGUMENTS

La fonction de fusion développée prend en entrée les arguments suivants afin de produire une image de sortie

fusionnée

- Image n°1

- Image n°2

- Nom de l’image de sortie

- Index de l’offset en Z

- Taille de la zone de fusion


Le principal paramètre à optimiser est celui de la taille de la zone de fusion. Dans le script du pipeline, on utilise

une zone de seulement 5 lignes, cela est amplement suffisant pour qu’on ne puisse pas constater les liens entre

les différentes images.


17

3.2.3 VALIDATION

3.2.3.1 BILAN

Le pipeline de stitching comprend donc les exécutables suivants :

- GetZOffset.exe

o entrées : 2 images 3D, valeur approximative du Z

o sortie : valeur exacte du Z indiquant le chevauchement entre les 2 images

- ExtractSlice.exe

o entrées : image 3D, index

o sortie : image 2D correspondant à l'index

- ImageRegistration.exe

o entrées : 2 images 2D

o sortie : valeurs de la transformation entre les 2 images

- ImageTransform.exe

o entrées : image 3D, paramètres de la transformation

o sortie : image 3D transformée

- BlendImages.exe

o entrées : 2 images 3D

o sortie : 1 image 3D


18

3.2.3.2 EVALUATION VISUELLE

Les images suivantes présentent les zones où des anomalies étaient présentes avec le « Pairwise Stitching » de

Fiji :

Figure 7 : images fusionnées en utilisant l’algorithme « pairwise stitching » de Fiji


19

Les images suivantes présentent les résultats de notre méthode sur le même set de données.

Figure 8 : images fusionnées utilisant la méthode développée


20

L’image suivante montre la constitution du modèle corps humain final en fonction des différentes tiles qui le

constituent.

Figure 9 : image finale comprenant les 3 images initiales

Enfin voici trois exemples de corps recalés sur le plan axial.

Figure 10 : exemples d’images traitées

Au total 15 stitchings ont été effectués et validés.

Un problème s’étant présenté pour le 16e sujet, celui-ci n’a pas pas pu être traité. En effet Tile_03 présentait

des différences par rapport à Tile_02, sûrement dues à un problème d’acquisition.

Le temps nécessaire au recalage est de 40 minutes pour des images à demi-résolution (256*256*X) et de 4h

pour la pleine résolution (512*512*X.). Il est à noter que ce recalage n’est à effectuer qu’une seule fois par jeu

de données. Comme le processus est entièrement automatique et peut être tourné sous forme de batch, il n’a

pas été jugé nécessaire de travailler à essayer de réduire le temps de calcul.


21

3.3 ROGNAGE

Comme on peut le constater sur les images précédentes, les données contiennent des objets de calibrations,

des artéfacts, ainsi qu’une boite rigide entourant le sujet. Cette partie s’attache à les supprimer afin de pouvoir

initier un meilleur recalage.

3.3.1 PREMIERE APPROCHE

3.3.1.1 METHODE

La première approche fut simplement de découper un cadre autour de l’image pour supprimer les bords noirs.

Cette approche peut se résumer comme suit :

- Application d’une seuillage par la méthode d’Otsu

- Eroder l’image binaire obtenue

- Dilater l’image binaire obtenue

- Créer une boite englobante autour de l’image binaire obtenue

- Découper l’image de départ à l’aide de la boite englobante obtenue

L’algorithme de la boite englobante est le suivant :

Figure 11 : algorithme de boite englobante

Celui-ci doit être répété afin de trouver Xmax, Ymin, Ymax, Zmin, Zmax.


22

3.3.1.2 RESULTATS

Les images suivantes montrent les résultats obtenus pour différentes slices (l’algorithme ayant été utilisé sur

les tiles plutôt que sur le corps entier.)

Figure 12 : résultats du premier algorithme de boite englobante

On peut constater que certaines parties sont supprimées. De plus, afin de pouvoir effectuer un recalage correct

il sera nécessaire de supprimer la boite totalement ainsi que les artéfacts. Cette méthode n’est donc pas

optimale.

3.3.2 PIPELINE

3.3.2.1 PRINCIPE

La nouvelle méthode implémentée se base aussi sur la morphologie mathématique (érosion et dilatation) mais

cette fois en niveaux de gris et introduit cette fois ci l’algorithme watershed (Bassins versant) pour se

débarrasser des artéfacts présents. Le pipeline d’exécutions est le suivant :

- Erosion en niveaux de gris

- Dilatation en niveaux de gris

- Seuillage d’Otsu

- Application des watershed

- Application du masque binaire à l’image de départ


23

3.3.2.2 IMPLEMENTATION

Les éléments du pipeline ont été implémentés en C++ à l’aide d’ITK à l’exception des watershed. Les

exécutables ayant été codés sont les suivants :

- GrayscaleDilate.exe : applique une dilatation à une image en niveaux de gris

o Entrées : image à traiter, nombre d’itérations

o Sortie : Image dilatée en niveaux de gris

- GrayscaleErode.exe : applique une érosion à une image en niveaux de gris

o Entrées : image à traiter, nombre d’itérations

o Sortie : Image érodée en niveaux de gris

- OtsuThresholding.exe : applique un seuillage selon la méthode d’Otsu

o Entrée : image à seuiller

o Sortie : Image binaire seuillée

- BinaryMask.exe : applique un masque binaire à une image en niveaux de gris, on conservera

seulement les parties de l’image où le masque binaire est à 1

o Entrée Image binaire et image en niveaux de gris

o Sortie : Image en niveau de gris à laquelle le masque aura été appliqué

Pour les watershed, on a utilisé la méthode présente dans le logiciel MIPAV, basé sur ITK. Les germes utilisés

sont présentés dans l’image suivante :

Figure 13 : positionnement des points pour l’algorithme watershed


24

3.3.2.3 VALIDATION

Les résultats obtenus sont présentés dans les images suivantes. On peut constater que la boite ainsi que les

artéfacts ont disparu mais quelques parties de certaines zones se retrouvent supprimées (entourées en rouge.)

Voici les résultats au niveau de la tête et des poumons (en haut post traitement, en bas pré traitement.)

Figure 14 : image avant traitement de rognage (haut) et après rognage (bas)


25

Les résultats suivants montrent les légères suppressions en niveau des doigts (en haut post traitement, en bas

pré traitement.)

Figure 15: image avant traitement de rognage (haut) et après rognage (bas)


26

L’image suivante est l’image de différence entre l’image de départ et l’image d’arrivée. On peut constater que

la majorité de la boite et des artéfacts est supprimée.

Figure 16 : image de différences montrant les effets du rognage

On a donc développé une méthode de suppression de données non nécessaires à l’aide d’ITK et de MIPAV.

Cette méthode pourrait nécessiter quelque ajustement pour éviter la suppression de zones anatomiques.


27

3.4 RECALAGE

Comme nous l’avons vu, un des objectifs du projet est d’automatiser la segmentation des données image. Il

existe 3 segmentations ayant déjà été effectuées à la main, celles-ci ayant pris un temps considérable.

La méthode d’automatisation choisie est de se baser sur une segmentation de référence (effectuée à la main)

et de la déformer par un recalage non linéaire pour la faire correspondre aux autres modèles et ainsi simplifier,

voire effectuer complètement leur segmentation.

3.4.1 METHODE CHOISIE

3.4.1.1 VOXELISATION

Afin d’effectuer le recalage, il a d’abord été nécessaire de voxeliser les données segmentées à la main

enregistrées sous forme de maillage. Pour cela on a utilisé l’outil binvox 3D Mesh Voxeliser.

Cet outil permet, à partir des données maillages en .stl, de créer une image au format choisi, ici .nrrd qui sera

converti en .tif.

On a donc voxelisé chaque os un par un puis les avons placé dans un répertoire. On a ensuite développé en

C++, à l’aide d’ITK, un programme permettant d’assembler toutes les images. On a aussi permis d’attribuer une

valeur différente d’intensité à chaque os pour créer une image segmentée.

A la fin de ce processus on a donc créé 2 images à partir des données maillage :

- Un atlas comprenant le squelette entier

- Un atlas labellisé comprenant le squelette entier ayant une valeur d’intensité différente pour

chaque os


28

3.4.1.2 RECALAGE

Le principe de notre méthode est de propager l’atlas sur une autre image via un recalage non linéaire. On

utilise pour cela l’outil elastix

Figure 17 : logo du logiciel elastix

Elastix est une boîte à outils permettant d’effectuer des recalages rigides ou non-rigides. C’est un outil open

source basé sur la bibliothèque ITK. Le logiciel contient un ensemble d’algorithmes utilisés communément pour

résoudre des problèmes de recalage d’images. Le logiciel permet de configurer, comparer et tester plusieurs

méthodes de recalage pour une application spécifique. L’interface en ligne de commande permet de traiter un

grand nombre de données.

L’application que l’on va faire de ce logiciel est le recalage de l’atlas labellisé ou non sur l’image que l’on veut

traiter afin d’obtenir une segmentation de cette image. Pour effectuer ces opérations on a besoin d’éditer des

fichiers de configuration, on éditera 2 fichiers car on veut effectuer les opérations suivantes :

- Un recalage linéaire : configuré dans parameters.similarity.txt

- Un recalage non-linéaire : configuré dans parameters.NCC.txt

Les paramètres de recalage utilisés sont les suivants :

3.4.1.2.1 INTERPOLATION

- Linéaire : interpolateur B-spline d’ordre 3

- Non- linéaire : interpolateur B-spline d’ordre 3

3.4.1.2.2 METRIQUE

- Linéaire : coefficient de corrélation normalisé

- Non- linéaire : coefficient de corrélation normalisé

3.4.1.2.3 OPTIMISATION

- Linéaire : descente de gradient adaptative

- Non-linéaire : descente de gradient adaptative

3.4.1.2.4 TRANSFORMATION

- Linéaire : transformation de similarité (7 paramètres)

- Non-linéaire : transformation B-spline (105

à 106 paramètres)

Les paramètres des 2 transformations sont stockés dans un fichier qui sera utilisé pour application la

transformation à l’image en pleine résolution. En effet le recalage se fait à moitié voire quart de résolution

pour des raisons de capacité de mémoire.


29

3.4.2 RESULTATS

L’image suivante présente le résultat du recalage de l’atlas labellisé sur une image corps entier. Chaque os à

une couleur différente constituant le label.

Figure 18 : Atlas labellisé transformé


30

L’image suivante présente le résultat du recalage sur les plans axial, sagittal et coronal. L’image verte est

l’image de l’atlas déformé, l’image rouge est l’image fixe sur laquelle on a déformé l’atlas. L’image jaune est

donc la correspondance entre l’atlas recalé et l’image à segmenter.

Figure 19 : image de différences entre l’atlas labellisé transformé et l’image à segmenter

Si des différences visibles dans certaines régions devraient être améliorées dans le cas présenté (ex : tête du

sujet), la correspondance semble proche dans d’autres régions qui seraient délicates à segmenter

manuellement (ex : colonne, cage thoracique). Ceci semble prometteur. L’approche développée pourrait alors :

- être utilisée telle qu’elle si les paramètres visés par l’analyse statistique des squelettes sont

relativement globaux (ex : dimensions osseuses) et qu’une correspondance très locale n’est pas

indispensable

- être utilisée pour initialiser un autre processus de segmentation plus manuel si l’analyse

statistique s’intéresse à des formes plus locales.

Au niveau des temps de calcul, il faut compter :

- 1h pour la voxelisation

- 10 minutes pour la création de l’atlas

- 20 minutes pour le recalage.


31

4 CONCLUSION, RETOUR D ’EXPERIENCE ET PROJET PROFESSIONNEL

Le projet aura donc mené à la création de 4 outils/procédures bien distinctes. En premier lieu j’ai géré le

traitement des données avec un outil de conversion des images. Ensuite j’ai assuré le regroupement de ces

données en une image corps entier définie et utilisable pour la suite du projet. Par ailleurs j’ai conçu une

méthode pour supprimer les parties de l’image entravant la suite du traitement. Enfin j’ai donné des pistes

pour la segmentation automatique des données grâce à un recalage par atlas. Ces outils vont maintenant être

transférés au reste du projet PIPER et publiés avec une licence Open Source. La licence choisie est Apache 2.0,

similaire à ITK. Celle-ci a été choisie pour des raisons de flexibilité avec les autres briques du projet. Les

documentations et les instructions de compilations sont aussi fournies en annexe.

Je serai monté en compétence sur le plan technique en développement en langage C++ en utilisant la

bibliothèque ITK. J’aurais aussi appris à utiliser certains outils en ligne de commande (binvox, elastix) et à les

utiliser efficacement dans des scripts.

Une partie de mon travail aura été la documentation ainsi que la description des procédures d’installation des

outils dans différents environnements, en effet, mon travail doit être réutilisable pour la suite du projet.

Enfin j’ai pu découvrir les challenges résidant dans le travail entre deux laboratoires.

Pour mon avenir j’ai pour but de continuer dans le développement informatique, C++ ou autre langages. J’ai

pour objectif du commencer par la technique pour évoluer vers des postes à plus grandes responsabilités. Une

opportunité m’a été proposée par une entreprise pour continuer dans le milieu du traitement d’images sur des

données médicales, ceci donnerait donc une suite logique à ce stage et au précédent, ayant aussi été effectué à

CREATIS.

Pour conclure je remercierais chaleureusement Thomas Grenier et Philippe Beillas m’ayant fourni une aide et

un encadrement adapté tout au long du stage.


32

5 GLOSSAIRE

Cropping : Le recadrage, ou rognage, est l'opération qui consiste à supprimer une partie périphérique d'une

image dans le but de l'améliorer (meilleur cadrage, accentuation du sujet, suppression de défauts ou du

vignettage, etc.) ou de modifier son format.

Pipeline : Suite d’instructions.

Recalage : En traitement d'image, le recalage est une technique qui consiste en la « mise en correspondance

d'images », ceci afin de pouvoir comparer ou combiner leurs informations respectives.

Slice : Coupe 2D d’une image 3D.

Stitching : On peut traduire cela par assemblage de photos, qui est un procédé consistant à combiner plusieurs

images numériques se recouvrant, dans le but de produire un panorama ou une image de haute définition.

Segmentation : La segmentation d'image est une opération de traitement d'images qui a pour but de

rassembler des pixels entre eux suivant des critères prédéfinis. Les pixels sont ainsi regroupés en régions, qui

constituent un pavage ou une partition de l'image. Il peut s'agir par exemple de séparer les objets du fond.

Tile : Mot utilisé dans ce document pour désigner une image qui est une partie de l’image corps entier que l’on

veut obtenir lors du stitching.

Watershed : En traitement d'images, la segmentation par ligne de partage des eaux désigne une famille de

méthodes de segmentation d'image issues de la morphologie mathématique qui considèrent une image à

niveaux de gris comme un relief topographique, dont on simule l’inondation.


33

6 BIBLIOGRAPHIE

6.1 PUBLICATIONS

[1] C. Mullins, R. Gessner, and S. Aylward. Using tubetk to automatically merge volumes. 01 2014.

[2] Stephan Preibisch, Stephan Saalfeld, and Pavel Tomancak. Globally optimal stitching of tiled 3d microscopic image acquisitions. Bioinformatics,25(11):1463{1465, 2009.

[3] Olivier Commowick.Design and Use of Anatomical Atlases for Radiother-apy. Theses, Université

de Nice Sophia Antipolis, February 2007.

[4] Ayman El-Baz and G. Gimel'farb. Global image registration based on learn-ing the prior

appearance model. pages 1{7, June 2008.

[5] Stephan Preibisch, Stephan Saalfeld, and Pavel Tomancak. Globally op-timal stitching of

tiled 3d microscopic image acquisitions.Bioinformatics,25(11):1463{1465, 2009.

[6] Joaquim Salvi, Carles Matabosch, David Fo, and Josep Forest. A reviewof recent range image

registration methods with accuracy evaluation.ImageVision Comput., 25(5):578{596, May 2007

6.2 OUTILS

ITK : http://www.itk.org/

ImageJ : http://imagej.nih.gov/ij/

Slicer : http://www.slicer.org/

MIPAV : http://mipav.cit.nih.gov/

Binvox : http://www.cs.princeton.edu/~min/binvox/

Elastix : http://elastix.isi.uu.nl/

Consultez le rapport

Documents

Transcript of Consultez le rapport