Embed Size (px)
Citation preview
1
NEBBAKI Mehdi
2014/2015
Rapport de stage
Doppler Transcrânien – Développement C++
Echographie haute fréquence – Démonstrateur Web
INSA de Lyon Creatis
Département Génie Electrique
Enseignant responsable du stage : Tuteur de stage :
M. Philippe DELACHARTRE M. Blaise Kévin GUEPIE
NEBBAKI Mehdi
2014/2015
2
Doppler Transcrânien – Développement C++
Echographie haute fréquence – Démonstrateur Web
INSA de Lyon Creatis
Département Génie Electrique
Enseignant responsable du stage : Tuteur de stage :
M. Philippe DELACHARTRE M. Blaise Kévin GUEPIE
3
Remerciements
Pour m’avoir accompagné et soutenu durant mon stage, je souhaiterais en premier lieu
adresser quelques remerciements à mes encadrants et collègues :
- Monsieur Delachartre Philippe, qui m’a permis d’effectuer mon stage au sein de
Creatis, et m’a encadré afin que je puisse mener mon projet du mieux possible ;
- Monsieur Petit Lionel, qui a été mon enseignant tuteur et m’a notamment aiguillé et
orienté lors du choix de mon stage ;
- M. Sciolla Bruno, pour son aide très précieuse sur tout un pan de mon projet ainsi que
pour tout ce qu’il m’a appris;
- M. Guépié Blaise Kevin, lui pour aussi pour son aide sur le second pan de mon projet
et son encadrement pour m’aider à comprendre mon environnement de travail ;
- M. Valette Sebastien, qui a développé l’un des principaux outils dont je me suis servi ;
- M. Bernard Olivier, pour les explications d’utilisation de l’outil développé par M.
Vallet ;
- M. Ferrier Pierre, pour toute l’aide logistique ainsi que les multiples installations sur
mon poste qui m’ont été nécessaires en début de stage.
Et plus généralement je remercie l’équipe avec laquelle j’ai travaillé ainsi que le personnel de
Creatis, à la fois pour les échanges très instructifs, mais aussi pour les nouvelles perspectives
qu’ils m’ont offert : Charpy Bastien, Pinatel Emilie, Ceccato Paola et bien d’autres.
4
Sommaire
Remerciements ......................................................................................................................... 3
Sommaire ................................................................................................................................. 4
Introduction .............................................................................................................................. 7
I. Présentation de Creatis, Atys Medical et AtysCrea .............................................................. 8
1. Creatis ..................................................................................................................... 8
2. Atys Medical .......................................................................................................... 9
3. AtysCrea ................................................................................................................. 9
II. Les projets AtysCrea ........................................................................................................... 10
1. Présentation des deux projets ................................................................................. 10
2. Objectifs ................................................................................................................. 13
3. Environnement de travail et outils utilisés ............................................................. 18
III. Démonstrateur web – échographie haute fréquence........................................................... 25
1. Prise en main de la librairie desk ............................................................................ 25
2. Etude d’un code existant ........................................................................................ 27
3. Programmation de l’interface ................................................................................. 33
4. Gestion de la prise de points ................................................................................... 37
5. Lancement des exécutables et affichage ................................................................. 38
6. Perspectives d’évolution ......................................................................................... 40
IV. Développement C++ - Doppler transcrânien ..................................................................... 42
1. Etude du code matlab ............................................................................................. 42
2. Programmation des blocs modules ......................................................................... 45
3. Tests comparatifs entre matlab et c++ et résultats obtenus .................................... 50
V. Mon projet professionnel ..................................................................................................... 54
Conclusion technique ............................................................................................................... 55
Conclusion personnelle ............................................................................................................ 56
Bibliographie ............................................................................................................................ 57
Sommaire des annexes ............................................................................................................. 58
Annexes .................................................................................................................................... 59
5
Table des illustrations :
Figure 1 : Doppler transcrânien et moniteur de débit cardiaque .............................................. 9 Figure 2 : Echographie du rat, et échographie d’un ongle ....................................................... 10
Figure 3 : Performances de l’imagerie selon la fréquence d’échographie ............................... 11
Figure 4 : Appareil TCD-X ...................................................................................................... 11
Figure 5 : Illustration du fonctionnement d’un doppler transcrânien ....................................... 12
Figure 6 : Exemple d’utilisation du desk pour la segmentation d’images de poumons ........... 14
Figure 7 : Architecture de l’infrastructure d’un desk et interactions entre les couches ........... 14
Figure 8 : Image résultant de la segmentation sur un algorithme de traitement ...................... 15
Figure 9 : Illustration du signal audio obtenu à partir de l’enregistrement du TCD-X ............ 16
Figure 10 : Idée du modèle de représentation pour la chaîne de traitement du programme C++
.................................................................................................................................................. 17
Figure 11 : Fenêtre principale du desk ..................................................................................... 19
Figure 12 : Utilisation de la commande console.log pour pister la variable pos ..................... 21
Figure 13 : Putty Gen, qui permet de générer la clé SSH d’une machine ................................ 21
Figure 14 : Accès au serveur du desk depuis FileZilla ............................................................. 21
Figure 15 : Arborescence d’un desk ......................................................................................... 23
Figure 16 : Equivalence entre interface navigateur et desk côté serveur ................................. 23
Figure 17 : Modification d’un exécutable .sh pour le lier aux librairies .................................. 24
Figure 18 : Démo cube nativement présente sur le desk .......................................................... 26
Figure 19 : Première analyse de code ....................................................................................... 26
Figure 20 : Cube sans contours ................................................................................................ 27
Figure 21 : Visualisation des 3 coupes animées, en 3D ........................................................... 28
Figure 22 : Visualisation d’une coupe ...................................................................................... 28
Figure 23 : Représentation du volume 3D ............................................................................... 30
Figure 24 : Création d’une fenêtre avec boutons et zones d’affichage .................................... 30
Figure 25 : Fonction d’appui sur le bouton SAX ..................................................................... 31
Figure 26 : Appui sur le bouton SAX ...................................................................................... 31
Figure 27 : Squelette du programme ........................................................................................ 32
Figure 28 : Esquisse de l’interface finale ................................................................................. 33
Figure 29 : Fenêtre de l’interface du démonstrateur ................................................................ 34
Figure 30 : Ajout du panel de sélection .................................................................................... 34
6
Figure 31 : Ajout de l’arborescence des fichiers ...................................................................... 35
Figure 32 : Changement d’image sur l’interface ...................................................................... 35
Figure 33 : Fonction illustrant le repositionnement des trois images, et fonction permettant le
déplacement de l’image associée au bouton front .................................................................... 36
Figure 34 : Illustration des modifications pour redimensionner la fenêtre selon la résolution de
l’écran de l’utilisateur, en utilisant innerWidth et innerHeight ................................................ 36
Figure 35 : Prise de points ........................................................................................................ 37
Figure 36 : Bouton Select et autorisation de prise de points .................................................... 38
Figure 37 : Bouton de lancement de la segmentation .............................................................. 38
Figure 38 : Fonction segmentation ........................................................................................... 39
Figure 39 : Fichier .json ........................................................................................................... 39
Figure 40 : Schéma récapitulant les interactions mises en jeu par le lancement d’un exécutable
.................................................................................................................................................. 40
Figure 41 : Spectrogramme obtenu après transformée de fourier à court terme ...................... 42
Figure 42 : Chaîne de traitement du signal du doppler transcrânien ........................................ 43
Figure 43 : Enveloppe du spectrogramme ................................................................................ 44
Figure 44 : Problème rencontré lorsqu’on est en dehors des limites d’un tableau tel que défini
par Eigen .................................................................................................................................. 46
Figure 45 : Schéma bloc du calcul de l’enveloppe ................................................................... 47
Figure 46 : Représentation de la boucle ................................................................................... 48
Figure 47 : Concaténation de tableaux ..................................................................................... 49
Figure 48 : Courbe d’erreur matlab et C++ (enveloppe_indices – patient 38) ......................... 51
Figure 49: Courbe d’erreur matlab et C++ (enveloppe_indices – patient 40) .......................... 52
Figure 50: Temps de calcul de l’algorithme sur trois patients – matlab et c++ ....................... 53
7
Introduction
J’ai effectué mon projet de fin d’études au sein du laboratoire Creatis à l’INSA de Lyon. Il
s’inscrit dans la continuité de mon projet professionnel, et me permettra, je l’espère de
poursuivre dans la voie que je désire par la suite.
Le laboratoire Creatis, situé sur le campus de l’INSA de Lyon, est spécialisé dans l’imagerie
médicale. Plusieurs équipes de chercheurs travaillent sur des thèmes et aspects scientifiques
bien particuliers, en réponse à des problématiques passées, actuelles et futures. Plusieurs
projets sont donc actés au sein du laboratoire, que ce soit en partenariat avec des entreprises,
ou directement avec les chercheurs eux-mêmes.
Ayant intégré l’équipe Ultrasons dirigée par M. Delachartre, j’ai effectué mon projet en marge
d’une partie de l’équipe, du moins sur l’aspect technique, mais en complète complémentarité
avec l’ensemble de mes collègues.
En particulier, je suis intervenu sur les projets d’échographe haute fréquence ainsi que doppler
transcrânien, en partenariat avec l’entreprise Atys Medical. Ces deux projets ont pour but le
développement d’algorithmes de calcul destinés à être implémentés sur des appareils d’Atys
Medical.
Mon projet s’est axé sur ces 2 volets, bien distincts dans leur approche et les ressources mises
en œuvre.
Je vais ainsi d’abord présenter Creatis ainsi qu’Atys Medical, puis le contexte de mes deux
projets, et enfin entrer plus en détails dans les spécificités de l’échographe et du doppler.
8
I. Présentation de Creatis, Atys Medical et AtysCrea
I.1. Creatis
Le laboratoire Creatis, pour Centre de recherche en acquisition et traitement de l’image pour
la santé, est une unité de recherche en imagerie médicale située à Villeurbanne, sur le campus
de l’INSA de Lyon. Il est rattaché au CNRS et à l’INSERM. C’est l’un des principaux
laboratoires de recherche européen en imagerie médicale, réunissant des savoirs en sciences
de l’ingénieur, de l’informatique et du vivant.
Il a pour mission de développer des méthodes, algorithmes et dispositifs instrumentaux
d’imagerie médicale en réponse aux problématiques posées par la médecine.
Plusieurs équipes de recherche étudient divers aspects en imagerie médicale :
- Cœur, vaisseaux, poumons : concerne le développement de méthodes d’analyse
d’images dédiées à l’étude de phénomènes biologiques et médicaux. Ces méthodes
sont principalement expérimentées dans deux applications médicales : Imagerie des
pathologies cardio-vasculaires et Imagerie de l'agression pulmonaire ;
- Images et modèles : concerne l'identification et la résolution des problèmes
méthodologiques liés au traitement d’images médicales ;
- Imagerie tomographique et thérapie par rayonnements : concerne le développement de
méthodes pour la tomographie et la thérapie par rayonnements, notamment pour
l’imagerie cellulaire 3D du tissu osseux et le traitement de cancers;
- RMN et optique, Méthodes et Systèmes : concerne l’étude des phénomènes en champ
proche (magnétisme) et champ lointain (optique). Les travaux menés sont des
développements instrumentaux et méthodologiques en imagerie biomédicale ;
- Imagerie cérébrale : concerne l’étude des pathologies du cerveau, notamment
l’accident vasculaire cérébrale et la sclérose en plaques ;
- Imagerie ultrasonore : les travaux de recherche de l’équipe ultrasonore concernent à la
fois l'interaction physique signal pour les systèmes d'imagerie ultrasonore et le
développement de méthodes permettant d’extraire les paramètres pertinents des
images/signaux dans le but de caractériser les tissus biologiques.
Le laboratoire regroupe environ 200 personnes, comprenant chercheurs, mais aussi
ingénieurs, doctorants, stagiaires et personnels administratifs. Il présente plus de 250
publications par an, et une centaine d’articles de revues.
Le budget annuel du laboratoire avoisine les 2M€.
9
En outre, c’est aussi un vecteur d’innovation puisque plusieurs start-ups ont été créées et des
dizaines de logiciels et brevets ont été développés et déposés.
I.2 Atys Medical
Atys Medical est une PME de 10 personnes fondée en 1990 située à Soucieu-en-Jarrest, une
petite commune au sud-ouest de Lyon. Spécialisée dans la conception, la fabrication et la
vente d’appareils médicaux de diagnostic, elle présente une large gamme de produits tels que
des dopplers transcrâniens, des échographes, un moniteur de débit cardiaque, etc… Sur la
figure 1 sont visibles deux appareils commercialisés par Atys : un doppler transcrânien et un
moniteur de débit cardiaque.
Figure 1 : Doppler transcrânien et moniteur de débit cardiaque
Portée par l’innovation, plus de la moitié du personnel est centré sur la R&D. L’entreprise a
notamment su s’entourer de médecins, professionnels de santé et universitaires afin d’être très
compétitive sur les innovations techniques et médicales.
L’entreprise est résolument tournée vers l’international, effectuant plus de 80% de son chiffre
d’affaires à l’étranger via des distributeurs exclusifs, et 20% via son propre réseau
commercial en France.
I.3 AtysCrea
AtysCrea est le partenariat issu du rapprochement entre l’entre Atys Medical et une partie de
l’équipe ultrasonore de Creatis. Deux projets principaux ont démarré en 2014 : le
développement des algorithmes pour le doppler transcrânien, et l’échographe haute fréquence
pour de la caractérisation tumorale.
C’est dans ce contexte que j’ai effectué mon stage de fin d’études. Travaillant à Creatis, j’ai
eu à interagir avec Atys Medical pour tout un pan de mon projet, notamment pour comprendre
les besoins de l’entreprise.
10
II. Les projets AtysCrea
II.1 Présentation des deux projets
L’équipe ultrasons de Creatis a engagé un partenariat avec Atys Medical en 2014 afin de
mener à bien le développement de nouveaux algorithmes de calcul pour deux appareils
médicaux en particulier : un échographe haute fréquence et un appareil de doppler
transcrânien.
L’échographie haute fréquence
L’objectif de la collaboration sur l’échographe haute fréquence est de développer un
algorithme exploitant les ultrasons haute fréquence pour le développement d’un échographe.
Une telle utilisation des hautes fréquences permettra de visualiser des images à très faible
profondeur : 6mm à 25MHz (chez le rat, sur la figure ci-dessous) ou encore directement
l’ongle à 3mm et 50MHz. De telles images sont illustrées sur la figure ci-dessous (figure 2).
Figure 2 : Echographie du rat (à gauche), et échographie d’un ongle (à droite) - [SCIO-15a]
11
Les applications sont multiples : dermatologie, imagerie du petit animal, cosmétique,
ophtalmologie, etc…
A terme, cet échographe permettra donc de se diriger vers une imagerie micrométrique, dont
les ordres de grandeur des performances sont à titre d’exemple répertoriés ci-dessous (figure 3).
Figure 3 : Performances de l’imagerie selon la fréquence d’échographie – [SCIO-15a]
Le doppler transcrânien
Atys développe et commercialise un outil de Doppler transcrânien nommé TCD-X. Il a pour
objectif de détecter la présence d’éventuels emboles dans le flux sanguin cérébral.
Ces derniers sont entre autres responsables des risques d’accidents vasculaires cérébraux, qui
touchent plus d’une centaine de milliers de personnes chaque année en France.
Les AVC représentent un défi formidable pour la médecine, puisque c’est une des principales
causes de mortalité pour les hommes, et la première pour les femmes.
Les emboles sont responsables de 30% des AVC, qui sont des caillots de sang obstruant les
artères. Les détecter améliore considérablement la réponse à ces accidents et c’est la pierre
angulaire de ce projet.
Le TCD-X est un appareil portatif affublé d’un casque à poser sur la tempe crânienne, comme
illustré sur la figure 4.
12
Figure 4 : Appareil TCD-X
Une sonde ultrasonore va relever le flux sanguin et notamment détecter les emboles dans
l’artère cérébrale moyenne, où circule 80% de flux sanguin, comme illustré sur la figure 5.
Figure 5 : Illustration du fonctionnement d’un doppler transcrânien [LIN-14b]
L’inconvénient de plusieurs des appareils existants utilisés est qu’ils sont statiques, c’est-à-
dire qu’ils nécessitent que le patient ne bouge pas lors du relevé effectué par l’appareil.
L’intérêt principal du TCDx est qu’il est portatif et non invasif, et donc il ne nécessite pas de
ressources logistiques. Le patient peut se déplacer durant la prise d’informations qui dure 1 à
2 heures, et l’enregistrement peut ensuite être exploité par le médecin. Bien qu’il ne supplante
pas l’expertise médicale du médecin (la machine peut se tromper, le médecin a l’expérience),
il complémente grandement son exercice en le délestant.
Le partenariat avec Creatis a pour objectif de développer des algorithmes à implémenter dans
le TCD-X afin d’améliorer les paramètres de performance et de fiabilité des mesures du flux
sanguin et de la détection des emboles.
13
II.2 Objectifs
Ma contribution à ces deux projets s’est faite au travers de deux axes principaux :
- la portabilité du code vers un langage plus facilement exploitable pour un industriel : Matlab
vers C++ ;
- la réalisation d’un démonstrateur web, faisant office de façade du savoir-faire de Creatis.
Je ne suis pas directement intervenu sur le développement des algorithmes des deux projets
puisque mon rôle a été l’intégration du code sous un nouveau format, néanmoins une certaine
compréhension m’a été nécessaire, pour efficacement porter les codes et obtenir des résultats
conformes à l’original dans les deux cas.
C’est pourquoi mon approche se focalise bien plus sur la compréhension du code et de
l’environnement, et moins sur l’étude des modèles mathématiques.
Démonstrateur Web
L’idée derrière la réalisation d’un démonstrateur web est notamment de promouvoir le savoir-
faire de Creatis au travers d’un outil utilisable en ligne et exploitant les algorithmes
développés par les laborantins.
En l’occurrence, j’ai travaillé sur le démonstrateur de l’échographe haute fréquence. Le
docteur Bruno Sciolla et Paola Ceccato ont développé l’algorithme à implémenter dans
l’échographe.
Le démonstrateur doit donc pouvoir faire fonctionner le programme à partir d’une fenêtre en
ligne, le tout avec une prise en main instantanée.
14
La solution retenue sera d’utiliser la librairie open source desk développée par Sébastien
Valette à Creatis. Les avantages sont multiples et collent parfaitement à notre cas, notamment
en regard de ce qui a déjà été développé avec par d’autres chercheurs du laboratoire. La figure
6 illustre l’idée qui repose derrière cette librairie. A partir d’images médicales et du traitement
effectué en utilisant desk, on peut réaliser des programmes permettant des applications
spécifiques pour l’imagerie médicale. Par exemple, sur la figure ci-dessous, on réalise la
segmentation d’images de poumons.
Figure 6 : Exemple d’utilisation du desk pour la segmentation d’images de poumons – [JACI-12]
L’architecture est tout à fait adaptée à la visualisation et le traitement d’images médicales.
Côté client, c’est-à-dire du côté de l’utilisateur du démonstrateur, cette dernière repose sur les
technologies web HTML5 pour l’interface utilisateur et WebGL pour la programmation de
cette dernière. On peut ainsi visualiser des images volumiques depuis un serveur et interagir
avec des modèles médicaux en 3D.
Côté serveur, l’implémentation est basée sur un schéma de gestion de fichiers simple et
robuste nommé RPC (Remote Procedure Call) pour des applications très hétérogènes.
Elle est notamment gérée grâce à un protocole réseau, et le PhP permettra de lancer des
exécutables depuis le serveur. La figure 7 modélise schématiquement les interactions entre les
différents langages évoqués :
15
Figure 7 : Architecture de l’infrastructure d’un desk et interactions entre les couches – [JACI-12]
Par ailleurs, la librairie desk intègre elle-même des librairies javascript. Qooxdoo, par
exemple, permet de réaliser et programmer toute la structure de l’interface depuis n’importe
quel poste pouvant accéder au desk, et sans aucune installation, puisque la librairie est située
sur le serveur.
Par ailleurs, Qooxdoo est notamment pratique en ce sens qu’elle permet de créer des classes
d’objets bien spécifiques pour les modules de la librairie. Par exemple, l’arborescence de
fichiers à l’ouverture d’une nouvelle fenêtre desk, ou même la fenêtre principale en elle-même
sont issus de classes développées pour Qooxdoo.
La documentation de la librairie desk est accessible à l’adresse suivante :
https://desk.creatis.insa-lyon.fr/user/application/api/#desk.MeshViewer
Deux autres librairies ont été utilisées pour l’affichage et l’exploitation des images :
- la librairie THREE.JS, qui permet de visualiser et représenter des modèles
volumiques 3D ;
- la librairie open-source VTK qui permet de réaliser les coupes 2D nécessaires à la
visualisation du volume final. Les coupes 2D sont exploitées pour reconstruire le
volume, avec un exemple donné sur la figure 8.
16
Figure 8 : Image résultant de la segmentation sur un algorithme de traitement
Il est important de noter qu’il est impossible, ou très dangereux, de lancer des exécutables
depuis une fenêtre de navigateur, pour des raisons de sécurité et de prévention, pour qui
cliquerait malencontreusement sur un site suspicieux.
Cela dit, le desk contourne ce problème puisque le code javascript et les exécutables sont
lancés depuis le serveur et non sur le PC de l’utilisateur. Les interactions modélisées par la
figure 7 sont ainsi complètement transparentes pour l’utilisateur.
En particulier, les interactions portant sur le lancement des exécutables sont basées sur
l’utilisation de fichiers .json, qui permettent de passer les paramètres d’entrée des exécutables
depuis la fenêtre de navigateur et donc depuis le côté client. Je donnerai un exemple de
syntaxe par la suite. Il est ainsi possible de lancer les requêtes RPC sur le serveur et
d’effectivement faire interagir le code développé sur la fenêtre de navigateur, avec les
exécutables.
Doppler transcrânien
L’objectif principal de ce projet pour Creatis est de réaliser l’algorithme qui effectue la
détection d’emboles. La sonde, après enregistrement, fournit des signaux ultrasons qui sont
ensuite démodulés pour obtenir un signal audio. Le schéma de la figure 9 illustre cette chaîne.
17
Figure 9 : Illustration du signal audio obtenu à partir de l’enregistrement du TCD-X – [LIN14b]
A partir de ce signal modulé, l’algorithme va détecter les instants où des emboles sont
présents, et notamment les séparer des bruits qui n’en sont pas.
L’exemple de la figure 10 fait apparaître la présence d’un embole sur la zone délimitée par le
rectangle vert, ce qui se traduit par une forte variation d’amplitude de l’intensité en cette zone.
La difficulté réside donc dans la bonne détection des emboles, notamment aux instants où
plusieurs signaux de haute intensité sont relevés, et auxquels cas il pourrait y avoir confusion
entre la signature d’un artefact et celle d’un embole. Il s’agit donc de bien définir emboles et
artefacts.
La particularité de l’algorithme est d’implémenter une méthode basée sur une transformée de
fourier à court terme avec une représentation en temps/fréquence pour l’estimation des
paramètres de détection, puis d’effectuer un calcul mathématique dit de vraisemblance pour
séparer le flux sanguin du bruit.
Une partie du code à implémenter dans le TCDx a été développé par une stagiaire présente sur
le même projet. J’ai principalement travaillé de concert avec elle sur son projet afin de
retranscrire du mieux possible et avec le minimum d’écart son code. L’objectif était un code
structuré et conforme au code implémenté sous matlab.
La transposition du code matlab du doppler a fait l’objet d’une étude en amont afin de bien
clarifier et séparer les tâches à effectuer. A partir du spectrogramme, le code calcule
l’enveloppe et donne la vitesse maximale du flux à chaque instant.
Une représentation de la chaîne de traitements avec les différentes entrées et sorties m’a
permis d’orienter mon travail. Le spectrogramme étant en l’occurrence fourni par Atys, je me
suis concentré sur l’algorithme effectuant les calculs de l’enveloppe et de la vitesse. J’ai
procédé en représentant la chaîne sous le format de plusieurs boîtes noires imbriquées, dont
l’idée est représentée sur la figure 10, en effectuant à chaque fois le distinguo entre entrées et
sorties de chaque fonction.
18
Figure 10 : Idée du modèle de représentation pour la chaîne de traitement du programme C++
Chaque étape de l’algorithme est codée indépendamment des autres, et testée avant d’être
implémentée dans la chaîne. Cette approche me permet de vérifier petit à petit la conformité
avec le code original, et à chaque fois de tracer des courbes d’erreur entre les résultats fournis.
Les deux grandes parties qui vont suivre vont me permettre d’aborder un aspect plus
technique et organisationnel de ma démarche, mais je souhaite d’abord présenter brièvement
mon environnement de travail.
II.3 Environnement de travail et outils utilisés
Cette partie a pour vocation de principalement détailler l’environnement de développement en
Javascript, notamment entourant l’utilisation du desk. J’aborderai aussi brièvement les
quelques outils dont je me suis servi en C++.
Environnement de développement Javascript
Comme évoqué auparavant, l’environnement de développement du desk repose sur le langage
JavaScript. C’est un langage de programmation de scripts principalement employé dans les
pages web interactives mais aussi pour les serveurs.
C’est un langage orienté objet, c’est-à-dire que les bases du langage et ses principales
interfaces sont fournies par des objets qui ne sont pas des instances de classes, mais qui sont
chacun équipés de constructeurs permettant de créer leurs propriétés, et notamment une
propriété de prototypage qui permet d’en créer des objets héritiers personnalisés.
En outre, les fonctions sont des objets de classe. Avant de débuter le projet, et étant novice en
Javascript, je me suis beaucoup servi de plusieurs références en ligne pour apprendre ce
langage :
19
- http://w3schools.com, qui proposait un ensemble de cours ergonomiques et toujours servis
d’exemples ;
- http://Stackoverflow.com, qui est un réseau social dédié à l’informatique, similaire à Quora
ou encore Answer.Yahoo. Le site est particulièrement utile pour comprendre toutes les
subtilités du Javascript. Il fonctionne sur la base de questions/réponses postées par des
développeurs;
- http://Openclassrooms.com, qui est aussi une très bonne alternative à w3schools, avec des
cours très complets ;
- https://desk.creatis.insa-lyon.fr/user/application/api/#desk.MeshViewer : documentation sur
les classes et objets Qooxdoo spécifiques au desk, utile pour commencer à appréhender le
desk, et pour se familiariser avec une majorité des fonctions qu’on va utiliser. Une bonne
partie de mes besoins en termes de codage a trouvé solution dans cette documentation ;
L’outil principal utilisé est le desk, accessible à l’addresse suivante : http://desk.creatis.insa-
lyon.fr/charpy.
Figure 11 : Fenêtre principale du desk
20
Sur la figure 11, 4 onglets sont présents : actions, code, data et demos. Ils correspondent à des
dossiers sur le desk côté serveur, que je détaille plus loin.
Un simple clic droit dans l’arborescence (par exemple dans data) permet de créer son fichier
.js et commencer à coder.
La sauvegarde est bien entendue présente et le fichier est enregistré sur le serveur.
L’exécution du code se fait via execute. L’avantage est une grande simplicité d’utilisation.
Cela dit, l’absence d’outils de débuggage est présente, et seule la console du navigateur
permet de grossièrement situer l’avancement de son code. Une utilisation judicieuse de lignes
de commande telles que console.log() pour afficher ses variables permet de pallier à cette
absence. La figure 12 illustre l’utilisation de la commande avec son résultat visible depuis la
console une fois le programme exécuté.
Figure 12 : Utilisation de la commande console.log pour suivre la variable pos
21
Afin d’approfondir, il est tout à fait possible d’interagir directement depuis le serveur pour
effectuer toutes les modifications désirées, y compris sur les fichiers qu’on code. L’interface
de la fenêtre de navigateur est donc avant tout un puissant outil d’ergonomie, et on retrouve la
même arborescence sur son desk, en y accédant directement depuis le serveur.
C’est là tout un pan de la programmation qu’il est intéressant de voir, puisqu’outre le
développement javascript, l’interaction avec les exécutables se fera en déposant les ressources
nécessaires aux bons endroits de son desk, sur le serveur.
Afin d’accéder et naviguer sur le serveur, je me suis servi de deux logiciels en particulier :
- Putty, pour générer la clé SSH nécessaire au référencement de ma machine sur le serveur et
pour pouvoir accéder à mon compte desk directement depuis le serveur, et non plus
seulement depuis la fenêtre de navigateur. La figure 13 illustre l’utilisation du logiciel, dont la
prise en main est instantanée ;
Figure 13 : Putty Gen, qui permet de générer la clé SSH d’une machine
22
- FileZilla, qui est un gestionnaire de fichiers. Il est très utile pour naviguer à distance sur le
desk, du côté serveur. La connexion se fait en renseignant le nom de l’hôte en protocole SFTP
sur la figure ci-dessous;
Figure 14 : Accès au serveur du desk depuis FileZilla
L’arborescence typique d’un desk est telle quelle :
Figure 15 : Arborescence d’un desk
On y retrouve les onglets tels que actions, code, data et demos qui sont en fait des dossiers
présents sur le desk, et dans lesquels il est donc possible de créer depuis le serveur des fichiers
23
en .js ou des images en .vtk. Ils se retrouveront dans l’arborescence visible depuis la fenêtre
du navigateur (figure 16).
Figure 16 : Equivalence entre interface navigateur et desk côté serveur
Cela dit, il est tout à fait possible de moduler la composition d’une architecture de desk en
créant ses propres répertoires, et en ne suivant pas forcément le modèle proposé nativement
par le desk. Il conviendra alors d’être prudent dans les liens entre les différents fichiers et
formats qu’il pourra y avoir, tels qu’entre un fichier en .js, un exécutable, et un .json.
Concrètement, l’accès au desk depuis le serveur nous permettra de pouvoir faire interagir code
(.js), fichiers de lien entre code et exécutables (.json), et exécutables (.sh). Il est à noter que le
serveur tourne sous Linux, et que j’ai utilisé des exécutables de Bruno Sciolla, compilés sous
une version Linux de Matlab2014b, car des problèmes de version avaient été rencontrés avec
Matlab 2015b en début de développement. Cela dit, à ce stade de développement, il n’est
donc pas à exclure d’effectuer des tests sur des exécutables compilés depuis d’autres version
de Matlab, notamment la 2015a.
Enfin, et selon l’exécutable, il est aussi nécessaire d’importer sur le serveur les librairies
Matlab appelées par l’exécutable, et de faire pointer ce dernier vers l’emplacement de ces
librairies sur le serveur. Il faut modifier le .sh, dont le contenu est visible sur la figure ci-
dessous.
24
Figure 17 : Modification d’un exécutable .sh pour le lier aux librairies
Environnement de développement C++
Je me suis servi de deux outils principaux pour le développement en C++ : l’interface de
développement QtCreator et la librairie Eigen.
QtCreator est une IDE gratuite et intuitive d’utilisation. Elle a d’office un compilateur GCC
fonctionnel avec la version la plus récente de C++. Il suffit de créer un projet en application
console et on peut commencer à coder. Elle est accessible à l’adresse
http://www.qt.io/download-open-source/
Eigen est quant à elle une librairie utilisée entre autres pour le traitement d’images, permettant
notamment l’utilisation de tableaux et matrices de façon dynamique. L’installation est très
25
rapide puisqu’il suffit de télécharger le pack Eigen contenant les .h et de les ajouter au projet
courant sous QtCreator.
Il est utile de préciser que chaque utilisation d’un type d’Eigen nécessite de préciser qu’il
appartient à Eigen. Plus précisément, pour utiliser le type ArrayXXd (tableau multi-
dimensionnel de double), il faudra spécifier using Eigen ::ArrayXXd. Toutes les subtilités de
la librairie sont très bien renseignées sur la documentation du site à l’adresse
http://eigen.tuxfamily.org/
La suite de ce rapport est consacrée à mon avancement et les réalisations effectuées à date de
rendu du rapport. J’aborderai notamment les perspectives d’évolution compte tenu de l’état
des deux projets.
III. Démonstrateur web – échographie haute fréquence
La démarche d’approche du démonstrateur web m’a demandé de pouvoir prendre du recul par
rapport à ce qui était attendu et les moyens que j’avais à disposition. Complètement novice, la
librairie desk utilisée en javascript a été l’occasion de m’initier à ce langage. Je vais donc
présenter la succession d’étapes qui m’ont permis d’arriver au résultat.
III.1. Prise en main de la librairie desk
J’ai au départ beaucoup travaillé avec un autre stagiaire, Bastien Charpy, qui a suivi des
études en DUT informatique. Il ne connaissait pas non plus le javascript, mais
26
l’environnement informatique lui était familier, et le travail en binôme avec lui pour la prise
en main du desk m’a été très profitable pour la suite.
Ayant de bonnes bases en C++, j’ai pu saisir rapidement les concepts et nuances par rapport à
ce langage, notamment en termes d’utilisation et d’implémentation. Cela dit, c’est avec la
réunion du club des développeurs de Creatis que j’ai pu en apprendre plus sur la librairie desk
que j’allais utiliser pour développer le démonstrateur.
La création d’un compte desk sur le serveur donne accès à quelques démos qui permettent
d’appréhender l’environnement. Je m’en suis servi pour explorer les différentes possibilités
permises par l’interface, notamment en termes d’exécution de code et de modification de
quelques lignes :
Figure 18 : Démo cube nativement présente sur le desk
27
Visible sur la figure ci-dessus, le code affiche dans une nouvelle fenêtre de l’interface un cube
en 3D qu’il est possible de manipuler.
Le détail du code commenté est donné ci-dessous :
Figure 19 : Première analyse de code
Il est ainsi tout à fait possible de modifier ces valeurs en utilisant par exemple un autre type
d’objet de la librairie threejs, ou encore simplement supprimer les contours (figure 20).
28
Figure 20 : Cube sans contours
Il est important de noter qu’en javascript les instructions sont concurrentes, c’est-à-dire que
toutes les actions s’effectuent au même instant. Il est possible de faire du séquentiel en
s’aidant d’outil tels que le timeout (une instruction qui génère un timer) ou le callback (appel
de fonction dans une fonction).
Ces quelques lignes de code ne présentent pas toutes les possibilités du desk, et c’est l’étude
d’un code existant, développé et pensé pour le desk qui m’a permis de saisir toutes les
fonctionnalités dont j’aurai besoin.
III.2. Etude d'un code existant
Ma méthodologie pour débuter le développement a été de partir d’un code existant développé
par Olivier Bernard, et présentant plusieurs fonctionnalités similaires à ce que je voulais faire.
Bien que les applications entre ce que je souhaite faire et ce qu’a fait Olivier soient différents,
plusieurs approches se recoupent et m’ont permis d’exploiter ce qu’il avait codé, notamment
en termes d’interface.
J’ai donc suivi une approche de « reverse-engineering », pour comprendre le fonctionnement
de l’interface, et remonter à la source du code.
J’ai utilisé un programme permettant l’affichage d’images médicales et de les recouper pour
créer une image 3D. Les différentes coupes sont animées et il est possible d’interagir sur
chaque instant de l’animation, et de sélectionner la coupe qu’on désire (illustrations
d’utilisation sur les figures 21 et 22).
Par ailleurs, il est aussi permis de réaliser le volume 3D associé à l’image (figure 23).
29
Figure 21 : Visualisation des 3 coupes animées, en 3D
Figure 22 : Visualisation d’une coupe
30
Figure 23 : Représentation du volume 3D
L’analyse du programme permet de comprendre la démarche de conception, notamment par la
structure du code, scindé selon un axe de développement particulier.
La première portion est dédiée à la déclaration des variables utilisées de manière récurrente
dans le programme tels que des flags, des objets, des dimensions.
La seconde, bien plus importante, comporte le code de l’aspect graphique de l’interface,
notamment les zones d’affichage, les boutons, arborescences, etc ...
31
Dans le petit exemple sur la figure ci-dessous, j’ai réutilisé plusieurs morceaux du code du
programme qui m’ont permis d’appréhender l’interface et d’obtenir une simple fenêtre avec
deux boutons et trois zones d’affichage (programme en annexe I) :
Figure 24 : Création d’une fenêtre avec boutons et zones d’affichage
A ce stade de développement, les zones n’affichent rien et le bouton n’appelle aucune
fonction, mais les fondations sont posées.
La suite du code détaille les fonctions appelées par l’interaction entre utilisateur et interface
(lignes 380 jusqu’à la fin du code).
Sur la figure 26, l’appui sur les boutons SAX, A4C ou A2C appelle respectivement une des
trois images dans la zone rectangulaire bleue, jaune ou rouge. Similairement, le clic sur un
autre patient dans l’arbre d’arborescence à gauche de la fenêtre appellera un autre jeu
d’images dans les trois zones d’affichage de droite.
32
Figure 25 : Fonction d’appui sur le bouton SAX
Sur la figure ci-dessus, la fonction onSAXButtonPressed() correspond à l’appui sur le bouton
SAX, et le positionnement de l’image du rectangle bleu au centre de la fenêtre.
Figure 26 : Appui sur le bouton SAX
Cela dit, simplement définir onSAXButtonPressed() ne suffit pas à faire fonctionner le bouton.
La dernière étape consiste à lier les deux éléments via un addlistener (détection
d’évènements), qui associe la fonction à l’élément graphique :
buttonSAX.addListener("execute", onSAXButtonPressed, this);
33
Ces quelques exemples d’analyse du code d’Olivier Bernard m’ont permis de comprendre les
fonctions et éléments de base dont j’aurai besoin par la suite. Au final, le schéma ci-dessous
résume le squelette du programme que je développerai :
Figure 27 : Squelette du programme
J’ai adopté cette structure pour la programmation de mon projet, et l’ai ajustée selon les
besoins du démonstrateur. Mon application nécessitant des interactions plus poussées avec
des programmes situés sur le serveur, il m’a donc été nécessaire d’innover sur la base de
l’architecture de ce code.
34
III.3. Programmation de l'interface
Une fois l’environnement mieux maîtrisé, je suis parti d’un fichier javascript vierge, et ai
progressivement codé l’interface. L’idée de départ était un modèle d’interface de la forme qui
suit, reprenant le formalisme du programme de la partie précédente :
Figure 28 : Esquisse de l’interface finale
35
La syntaxe utilisée est très similaire à ce que j’ai pu montrer auparavant, en décomposant
ainsi la programmation de l’interface suivant les axes suivants :
- La fenêtre de l’interface, dont la réalisation est très similaire à l’exemple donné en III.2. Elle
comprend les différentes zones d’affichage 0, X, Y, Z et 3D (figure 29);
Figure 29 : Fenêtre de l’interface du démonstrateur
- Un panel d’onglets permettant de sélectionner le type de vue à afficher sur la zone
d’affichage principale, et de lancer les fonctions spécifiques à ce démonstrateur. Les boutons
présents sur ce panel sont tous liés à des fonctions utilisées par l’algorithme, que ce soit pour
lancer le dit algorithme, ou interagir avec l’interface. Par exemple, sur la figure ci-dessous,
front déplace l’image de la zone X vers la zone 0, side déplace l’image de la zone Y vers la
zone 0, Select permet de sélectionner des points sur la zone 0 et enregistrer les coordonnées
associées, etc… ;
Figure 30 : Ajout du panel de sélection
36
- L’arborescence permettant de sélectionner les images associées à chaque patient (figure 31);
Figure 31 : Ajout de l’arborescence des fichiers
Le code est commenté et permet de comprendre chacun de ces axes de développement.
Cela dit, une première difficulté est survenue sur l’affichage des images sur le même espace
défini par pageSpace lorsqu’on clique sur un bouton pour changer d’image, comme illustré
sur la figure 32.
Figure 32 : Changement d’image sur l’interface
Compte tenu du fait que les images sont stockées dans la variable viewers, et qu’on déplace
viewers[i] (i étant l’indice correspondant à la première, deuxième ou troisième image) sur la
fenêtre principale 0, viewers[i] est alors attribuée à 0 et non plus à la fenêtre X.
37
En somme, la variable est sauvegardée sur la fenêtre principale 0 mais effacée de la fenêtre X.
Afin d’éviter d’écraser toutes les images sur la fenêtre principale en les appelant toutes avec
les boutons, il convient donc à chaque fois de repositionner les images au bon emplacement à
chaque appel d’une autre image. C’est une fonction dédiée qui réalise cette opération, dont le
détail du code est donné figure 33.
Figure 33 : Fonction illustrant le repositionnement des trois images, et fonction permettant le
déplacement de l’image associée au bouton front
En sus, il reste à optimiser la résolution de la fenêtre selon la taille de l’écran de l’utilisateur.
C’est un problème qui n’en est pas un puisque la modification concerne les dimensions
attribuées à chaque élément graphique de l’interface. Il convient donc de remplacer les
valeurs écrites en dur par le modèle que j’ai adopté pour définir la taille de la fenêtre
principale. L’idée de la réalisation est représentée sur la figure 34.
Figure 34 : Illustration des modifications pour redimensionner la fenêtre selon la résolution de
l’écran de l’utilisateur, en utilisant innerWidth et innerHeight
La seconde difficulté est apparue avec la gestion de la prise de points, c’est-à-dire enregistrer
les coordonnées de l’image quand on clique sur un point de l’image, et ce en 3D.
38
III.4. Gestion de la prise de points
La prise de points sur la zone d’affichage centrale permettra de lancer l’exécutable qui traitera
les données enregistrées par les multiples clics.
L’utilisateur sélectionne l’image sur laquelle il veut interagir, et clique sur les endroits qui
vont l’intéresser (figure 35) pour lancer l’algorithme de calcul. Cette fonction, qui réagit sur
un évènement clic de souris sur l’image de la fenêtre 0, est donc un aspect primordial du
démonstrateur.
Figure 35 : Prise de points (en jaune)
Comme précisé en III.2., il sera donc nécessaire de la faire interagir avec l’interface en elle-
même, c’est-à-dire que pour pouvoir cliquer et enregistrer les points sur l’image, il faut donc
« permettre » la prise de points.
Plus précisément, une fois le bouton Select enclenché, un clic sur l’image enregistrera les
coordonnées du point ciblé. Cette « sécurité » de la nécessité d’appui sur Select pour
enregistrer les points est réalisée au travers d’un drapeau d’initialisation mis à 1 lors d’un
appui sur le bouton, qui donne le feu vert à la fonction onMouseDown. Le détail du code est
donné sur la figure 36.
39
Figure 36 : Bouton Select et autorisation de prise de points
La prise de points étant permise par l’appui sur Select, chaque clic de souris sur l’image
présente dans la fenêtre 0 va correspondre à un évènement, qui permettra à la fonction
d’enregistrer notamment les coordonnées 3D de l’emplacement ciblé et y dessiner un point le
représentant.
Puis, de manière incrémentale et à chaque clic de souris, les positions seront progressivement
enregistrées dans un tableau qui sera l’entrée de notre exécutable.
III.5. Lancement des exécutables et affichage
L’aspect d’interaction avec le serveur où est installé le compte regroupant toutes les
fonctionnalités du desk a nécessité de comprendre le fonctionnement du projet développé par
Sébastien Valette en profondeur.
J’ai été beaucoup aidé de Bruno Sciolla sur cet aspect, notamment pour la compréhension du
lancement d’un exécutable.
Mon objectif est, depuis la fenêtre d’interface sur le web, de lancer l’exécutable après la prise
de points.
Afin de bien distinguer chaque rôle de chaque fonction de notre interface, j’ai choisi de
séparer le lancement de l’exécutable de la prise de points. C’est donc un bouton qui prendra
en paramètres les coordonnées précédemment enregistrées (figure 37). A ce bouton sera
associée une fonction, dans laquelle sera lancé l’exécutable.
Figure 37 : Bouton de lancement de la segmentation
40
La communication entre entre le programme javascript et le .json se fait au travers d’une des
fonctions du desk nommée launchAction, visible au sein de la fonction segmentation de la
figure 38.
Figure 38 : Fonction segmentation
Et plus spécifiquement, l’appel de la fonction Segmentation (figure 38) équivaut à la lecture
d’un fichier .json, qui va aller chercher à l’emplacement indiqué (sur le serveur) l’exécutable
qui lui est demandé. Plus concrètement, ce type de fichiers officie comme passerelle entre la
demande du programme javascript via launchAction, et l’objectif final qui est de lancer
l’exécutable.
On définit ainsi un certain formalisme (figure 39) sous le fichier .json, indiquant ce que doit
faire le programme javascript, c’est-à-dire lancer un exécutable, avec certains paramètres
d’entrées.
Figure 39 : Fichier .json
41
En l’occurrence, l’exécutable est nommé segmentation_v1_0, et le paramètre d’entrée de ce
dernier est argument, qui est une chaîne de caractères. Le parallèle peut être effectué avec la
figure 40.
Le schéma récapitulatif de la figure 41 permet de comprendre les interactions mises en jeu
entre les différents formalismes et types de langages.
Figure 40 : Schéma récapitulant les interactions mises en jeu par le lancement d’un exécutable
Depuis le navigateur, l’exécution du programme et plus spécifiquement l’appui sur le bouton
de segmentation pour lancer l’exécutable « active » le fichier .json. C’est ce dernier qui va
réellement permettre de lancer l’exécutable et qui contient les paramètres d’entrée de ce
dernier. Au final, via le .json, l’exécutable est ainsi lancé depuis la fenêtre de navigateur.
III.6. Perspectives d’évolution
A ce stade de développement, le démonstrateur de l’échographie haute fréquence est
fonctionnel. Cela dit, plusieurs axes d’évolution sont envisagés :
42
- Gagner en fluidité d’utilisation, et ainsi permettre à la segmentation, donc l’algorithme, de se
lancer dès la prise de points terminée. On éviterait ainsi d’utiliser deux boutons, Select et
Segmentation. Le problème actuel porte sur l’utilisation même du javascript puisque les
instructions sont concurrentes et non séquentielles. La solution serait d’utiliser des fonctions
de retour (callback), c’est-à-dire appeler la fonction de segmentation depuis la fonction de
prise de points ;
- Afficher les barres de chargement d’images, et de progression de l’algorithme de
segmentation, qui prend plus d’une minute à chaque fois ;
- Permettre à l’utilisateur d’effacer une sélection de points.
Par ailleurs, un autre démonstrateur, celui du doppler transcrânien, est à développer. Les bases
pour la réalisation de l’interface sont posées et peuvent être très similaires à celles de
l’échographie haute fréquence.
La gestion du lancement des exécutables peut être envisagée sous deux aspects :
- Etant donné que le doppler transcrânien est codé sous la forme de modules, il s’agirait de
décomposer l’algorithme en autant d’exécutables que de modules. Par conséquent, le
démonstrateur devrait être capable de pouvoir lancer plusieurs exécutables l’un à la suite de
l’autre ;
- La deuxième option consiste à concentrer tous les blocs modules en un seul exécutable. Il
faudrait alors être capable de sortir toutes les variables qui nous intéressent.
Dans les deux cas, il serait judicieux d’exploiter l’interface matlab codée par Emilie pour
savoir ce qu’on souhaite afficher comme informations. Et c’est là où l’utilité de lancer
plusieurs exécutables prend son sens. On peut ainsi sélectionner plus facilement à quel
emplacement de la chaîne de traitements on souhaite prélever une certaine sortie pour
l’afficher.
L’encapsulation dans un seul exécutable de tous les blocs modules pourrait nous limiter dans
le futur en termes de réutilisation et de modularité de l’interface. Il serait alors plus compliqué
d’ajouter ou supprimer des affichages car cela nécessiterait de modifier le code de
l’exécutable à sa source.
43
IV. Développement C++ - Doppler transcrânien
Autre volet de mon stage, le développement C++ du doppler transcrânien a pour finalité
d’être exploité par Atys Medical pour implémentation dans ses appareils médicaux. Le fil
directeur de ce portage est d’être conforme au code matlab, en termes d’entrées/sorties et de
résultats obtenus.
J’ai donc segmenté le développement suivant plusieurs modules, qui correspondent aux
différentes fonctions du code développé par l’équipe du laboratoire.
Il est à noter que le code que j’ai transposé ne correspond pas à la totalité de l’algorithme du
doppler transcrânien, mais au programme d’un laborantin, qui était alors finalisé et
transposable. D’autres blocs modules associés à d’autres pans du projet seront à développer
en C++.
IV.1. Etude du code matlab
Le code matlab est scindé en deux principaux axes : le calcul du spectrogramme depuis
l’enregistrement audio, et le calcul de l’enveloppe.
Le premier axe se focalise sur un aspect graphique pour réaliser la transformée de fourier à
court terme et ainsi afficher le spectrogramme correspondant à l’enregistrement audio, qui
prend ainsi la forme ci-dessous (figure 41).
Figure 41 : Spectrogramme obtenu après transformée de fourier à court terme
Atys Medical nous fournit les spectrogrammes que je peux utiliser pour développer la suite du
code. De plus, la priorité de l’entreprise portait sur le calcul de l’enveloppe.
44
Par conséquent, c’est surtout le codage du calcul de l’enveloppe qui nous intéresse. Afin de
bien distinguer tous les éléments de la chaîne de traitement, il est donc crucial de définir en
amont les entrées, sorties et fonctions à coder.
Le schéma de la figure ci-dessous m’a permis de jalonner mon travail et de m’orienter dans le
code de chaque module.
Figure 42 : Chaîne de traitement du signal du doppler transcrânien
L’entrée F_signal est issue du calcul du spectrogramme, c’est-à-dire que F_signal est un
tableau 2D qui représente les points de l’image du spectrogramme. L’enveloppe filtrée est le
résultat attendu par la chaîne de traitement, comme représentée sur la figure 43 en jaune.
Figure 43 : Enveloppe du spectrogramme (en jaune)
45
Suppression hautes amplitudes
Cette première fonction prend en entrée le spectrogramme. Dans notre cas, F_signal est un
tableau 2D dont les valeurs sont enregistrées depuis matlab dans un fichier texte. Elles seront
la suite exploitées en C++.
La fonction supprime les valeurs de F_signal qui seraient trop élevées par rapport à la
moyenne des points de l’image, et les remplace par cette dernière. On obtient ainsi le tableau
2D Image. L’objectif de ramener les valeurs de F_signal trop élevées à la moyenne est
d’éviter que l’enveloppe soit mal calculée et « tirée » vers le bas à cause du poids de ces
dernières.
Calcul de l’enveloppe
Cœur de l’algorithme, cette fonction agit en deux temps. Je vais me focaliser sur son
explication du point de vue informatique plus que fonctionnel. Une première étape
d’initialisation sur un certain nombre de colonnes permet de « préparer » l’algorithme au
calcul. La seconde étape concerne l’ensemble de l’image.
En prenant Image comme entrée et d’autres paramètres internes telles que le nombre de
colonnes initiales (pour l’initialisation) ou la position de certains pixels comme références de
calculs, l’algorithme va calculer l’enveloppe de l’image en se basant sur une méthode
statistique dite de recherche du maximum de vraisemblance sur chaque colonne de l’image.
Plus spécifiquement, la fonction va parcourir chaque colonne de l’image et appliquer une
succession d’étapes pour aboutir à la valeur de l’enveloppe sur la colonne :
- Une séparation en deux zones distinctes de la colonne ;
46
- Un calcul dit d’estimation de parzen ;
- Le calcul de log-vraisemblance ;
Il est à noter qu’un buffer glissant correspondant au nombre de colonnes initiales est utilisé
pour réaliser l’estimation de parzen, et donc celui est mis à jour au fil de la progression dans
la fonction. Il contient notamment les deux zones de chaque colonne.
Etant donné qu’on cherche le maximum de vraisemblance sur chaque colonne, on obtiendra
donc un point par colonne. Il en ressort ainsi Enveloppe indices qui est un tableau 1D
contenant les indices associés à la valeur d’enveloppe calculée. Plus de détails sur le schéma
bloc de la fonction même interviennent par la suite.
Filtrage sur les indices
Cette fonction permet, à partir des indices obtenus en sortie du précédent bloc, de lisser la
courbe pour obtenir l’enveloppe « finale ».
IV.2. Programmation des blocs modules
La programmation de tous les blocs modules a avant tout nécessité l’établissement d’un socle
sur lequel le projet repose. Plus précisément, j’ai ainsi créé un fichier d’en-tête qui recoupe
mes fonctions, et définit les variables constantes du projet. De la même manière, chaque
utilisation d’un objet ou d’un type de Eigen nécessite d’ajouter le préfixe Eigen ::XXX. J’ai
pris soin de référencer dans le code toutes les références à la librairie que j’ai fait en utilisant
la commande using dans le fichier d’en-tête.
Au stade de développement actuel, je me suis focalisé sur la programmation des fonctions de
suppression des hautes amplitudes et de calcul de l’enveloppe, conformément à la demande
d’Atys, étant donné que ce sont les fonctions principales qui régissent le cœur de l’algorithme.
La perte de signal, le filtrage sur les indices et le calcul de la vitesse maximale ne seront pas
abordées.
La première étape de programmation a concerné l’extraction du spectrogramme sous forme de
tableau 2D afin de le représenter conformément à sa variable correspondante sous matlab,
depuis le fichier texte sur lequel il a été enregistré.
47
Sous matlab, les valeurs du spectrogramme sont ainsi enregistrées dans un fichier texte les
unes à la suite des autres, ligne à ligne. Il n’y a donc pas de discontinuité et pas de moyen de
distinguer lignes et colonnes. Il convient donc d’être vigilant en C++ quand on utilise ces
données.
En utilisant le type fstream, j’ai récupéré les valeurs de chaque ligne du fichier et les ai
stockées dans un tableau 2D.
En somme, le nouveau tableau a été rempli colonne par colonne, où une colonne correspond à
une colonne de points du spectrogramme. Cet ordre de remplissage n’est pas foncièrement
important, et on aurait pu remplir ligne à ligne, mais le fil directeur est d’avoir toujours en tête
la définition des tableaux qu’on manipule, pour la raison que les tableaux ne sont pas déclarés
de la même façon en matlab et en C++.
Par exemple, un vecteur colonne est différent d’un vecteur ligne sous matlab, tandis qu’en
C++, il n’y a pas de distinction, si ce n’est celle que fait le développeur quand il code.
Suppression hautes amplitudes
La fonction de suppression a été la première à être confrontée à la notion de gestion des
tableaux. Là où sous matlab la taille des tableaux n’est pas gérée, il convient en C++ d’être
scrupuleusement vigilant sur la taille et les indices de nos tableaux.
Par exemple, quand sous matlab, un tableau commencera à l’indice 1, le même tableau
commencera à l’indice 0. Ce sont ces détails qui peuvent altérer grandement le résultat final,
étant donné que si on cible le mauvais indice, on peut tout à fait cibler une valeur au-dessus de
la taille du tableau. On obtiendra alors un message d’erreur d’Eigen (figure 44), concernant un
problème d’allocation d’espace à un tableau.
Figure 44 : Problème rencontré lorsqu’on est en dehors des limites d’un tableau tel que défini
par Eigen
Cela dit, il est à noter que bien que les tableaux Eigen soient dynamiques, il n’y a pas de
gestion d’allocation mémoire. Il n’est donc pas nécessaire d’allouer une adresse, ou encore de
détruire le tableau après utilisation.
Suppression hautes amplitudes effectue une moyenne sur les lignes et les colonnes de toute
l’image afin d’obtenir une valeur qui servira de plafond en cas de surintensité, c’est-à-dire une
valeur trop élevée (par rapport à la moyenne) en un point de l’image.
48
Ainsi, chaque valeur de l’image du spectrogramme (qui est le tableau 2D F_signal) supérieure
à la moyenne sera ramenée à cette dernière, et on obtiendra un nouveau tableau 2D Image.
Calcul de l’enveloppe
C’est le cœur de l’algorithme et la fonction qui a nécessité le plus de réflexion. Elle peut être
séparée en deux parties : une première qui concerne l’initialisation du calcul de l’enveloppe,
et une seconde pour le calcul en lui-même. Il m’a paru judicieux de représenter la fonction
sous forme de schéma bloc (figure 45).
Figure 45 : Schéma bloc du calcul de l’enveloppe
49
Au cours de l’initialisation, le programme doit parcourir les dix premières colonnes, et pour
chacune y effectuer un calcul de log-vraisemblance afin de définir l’enveloppe du
spectrogramme.
Le calcul de log-vraisemblance fait intervenir un calcul mathématique dit estimation de
parzen. La difficulté première est que ce calcul est effectué avec des tableaux dont la taille
varie dans une boucle for.
Plus précisément, et pour chaque colonne, deux zones, soit deux tableaux 1D (1D car on est
sur une colonne) sont définis chacun sur une certaine portion de la colonne. A chaque portion
son tableau, et donc sa taille. Or, la portion se « déplace » de 1 pixel à chaque incrément dans
la boucle. Par conséquent, le premier tableau gagne un emplacement, et le second en perd un.
L’exécution de cette boucle est représentée figure 46.
Figure 46 : Représentation de la boucle
Là où sous matlab les tailles étaient gérées automatiquement, il convient en C++ d’agir
autrement. La solution retenue est de créer à chaque tour dans la boucle, et donc à chaque fois
qu’on se déplace de un pixel, un nouveau tableau avec les bonnes dimensions. Eigen nous
permet ceci étant donné sa gestion ergonomique des tableaux.
Ainsi, à chaque tour dans la boucle, les deux zones vont être exploitées dans une sous-
fonction calcul_lv_premieres_colonnes, qui calcule la valeur de log-vraisemblance sur les
premières colonnes.
Comme précisé, cette dernière fonction fait intervenir l’estimation de parzen (fonction
parzen_e). La fonction calcul_lv_premiere_colonnes ne pose pas de difficulté majeure de
conception, à l’inverse de parzen_e.
50
En effet, de multiples fonctions mathématiques natives à matlab ne le sont pas en C++, telle
que la variance, qui n’est pas non plus présente sous Eigen. J’ai donc codé cette dernière, en
prenant soin de débugger avec précision les résultats obtenus.
Il a été par ailleurs nécessaire de comparer avec matlab l’état de chaque variable. Certains
résultats étaient aberrants et d’un ordre de grandeur complètement différent de celui attendu.
L’écart constaté était en effet dû aux subtilités du C++ en regard de matlab. En effet, tandis
que sous matlab, il est tout à fait possible d’exprimer la puissance sous la forme d’un quotient,
ce n’est pas vrai en C++, et le résultat sera équivalent à une puissance 0. Ces différences qui
peuvent paraître anecdotiques au départ ont donc été la clé de voûte de la programmation et
les principaux points bloquants.
Finalement, la dernière subtilité de la programmation de la fonction a été la concaténation de
plusieurs tableaux. Il est de nouveau question de gérer dynamique la taille de tableaux,
puisqu’on imbrique petit à petit un tableau initial avec à chaque fois un nouveau tableau. On
ne peut donc pas recréer constamment un tableau puisque le tableau initial serait écrasé. La
solution est donc d’utiliser un tableau tampon dont la taille est ajustée pour la concaténation,
puis d’attribuer ce tableau au tableau final. La figure 47 illustre ce fonctionnement.
Figure 47 : Concaténation de tableaux
Les difficultés étant levées sur la gestion des tableaux et les subtilités du C++, la
programmation de l’initialisation des colonnes permet de poursuivre le calcul en lui-même,
qui est pour le coup la continuité de l’initialisation. On va donc utiliser des fonctions
similaires.
51
IV.3. Tests comparatifs entre matlab et c++ et résultats obtenus
Chaque ligne de code du programme C++ ayant fait l’objet d’une comparaison pas à pas, une
comparaison du fonctionnement des fonctions permet néanmoins d’évaluer la conformité des
résultats au code matlab.
En l’occurrence, les tests sont effectués aux points critiques du code, et sujets aux plus grands
écarts.
Le premier test a concerné le portage du signal F_signal sous matlab, vers le c++, et la
vérification de l’absence de perte d’information, notamment sur le nombre de décimales après
la virgule.
L’export des données depuis matlab permet une certaine souplesse. On peut sélectionner le
signal F_signal, et ainsi conserver son intégrité, sans qu’il ne subisse aucune modification.
Cela dit, j’ai réalisé l’import de ces données vers le C++ à l’aide d’une méthode strtod, c’est-
à-dire qu’on lit la chaîne de caractères de chaque ligne du fichier texte, et on la transforme en
valeur de type double. L’inconvénient majeur est la limitation à 6 décimales après la virgule
des valeurs manipulées.
C’est donc une méthode qui produira toujours dans mon cas de très légers écarts, et c’est un
problème qui concerne uniquement mes tests puisque dans la continuité de la chaîne de
traitement, ce ne sera pas un fichier texte contenant les valeurs de la variable qui sera utilisé
mais bien la variable elle-même, éludant par là-même les intermédiaires et la perte
d’information.
Dans le cas présent, j’ai arrondi directement depuis matlab (fonction round) les variables à 6
chiffres après la virgule, afin d’avoir une similitude avec le C++. On obtient ainsi une variable
de départ (F_signal) strictement identique entre matlab et c++.
Les tests ont été réalisés sur les fonctions elles-mêmes. Comme déjà évoqué, le débugger est
un outil précieux pour suivre l’évolution des variables internes, et j’ai aussi réalisé des
comparaisons graphiques des entrées et sorties des fonctions aux points clés.
52
Par exemple, le premier test a concerné la suppression des hautes amplitudes. Je me suis en
particulier intéressé à la cohérence entre matlab et C++ du tableau 2D Image, qui est la sortie
de la fonction. Aucune erreur n’a été détectée puisqu’on obtient 0% d’erreur en comparant les
deux codes.
En effet, la fonction suppression hautes amplitudes va modifier certaines valeurs de l’image
pour les remplacer par la valeur de la moyenne. Une grande partie des valeurs du tableau
Image sera donc conservée et égale à son entrée, soit F_signal.
Si disparité il y a, elle ne peut concerner que le calcul de la moyenne, qui remplace certaines
valeurs du signal d’entrée.
Dans mon cas, la moyenne est identique sur plusieurs jeux de données : patient 31, 38 et 40,
avec une erreur de 0%.
Similairement, je me suis intéressé à une variable clé pour le cœur du calcul de l’enveloppe,
qui avait le plus de chances de présenter des disparités, à savoir le résultat du calcul
mathématique d’estimation : enveloppe_indices. Ce tableau en sortie de la fonction a dans un
premier temps présenté des résultats identiques pour les patients 31 et 40. Néanmoins, le
patient 38 présentait un effet de bord et donc une disparité des résultats sur une portion de
l’image, comme illustré sur la figure 48. Sur cette dernière sont représentées les enveloppes
sous matlab et c++, ainsi que l’erreur en jaune. Il est à noter que je ne dispose pas d’une
représentation temps/fréquence et donc l’image est représentée par les pixels qui la composent
(en abscisse et en ordonnée).
Figure 48 : Courbe d’erreur matlab et C++ (enveloppe_indices – patient 38)
1 6121 41 81 1016
1116 26
3136 46
5156 66
7176 86
9196 106
111116
121126
131136
141146
151156
161166
171176
181186
0
50
100
150
200
250
Courbes d'enveloppe matlab - c++ enveloppe_matlab
enveloppe_cplus_cplus
erreur
Position du pixel sur l'image
Pos
ition
du
pixe
l sur
l'im
age
53
La divergence sur le bord provenait d’une erreur de calcul sur la fonction suppression hautes
amplitudes, dont la moyenne calculée au sein de la fonction en c++ divergeait de 2% par
rapport à matlab, ce qui au final suffisait à proposer des résultats faux sur environ 5% de
l’image (sur la figure ci-dessus, une dizaine de pixels sur 189 diverge). Cette erreur est par
ailleurs notamment visible car au fil des calculs effectués par l’algorithme, l’erreur qui au
départ était minime s’en retrouve amplifiée à chaque incrémentation de la boucle de calcul.
Une fenêtre de représentation plus grande que 189 pixels mettrait davantage en exergue cette
erreur.
Néanmoins, ma méthodologie de pouvoir distinguer les points de test critiques m’a ainsi
permis de pouvoir rapidement remonter et trouver le défaut dans le code. Et au final, au fil des
calculs de vraisemblance sur toutes les colonnes, on obtient des résultats dont l’erreur
précédente est corrigée, comme par exemple sur le test 40, illustré sur la figure 49.
Figure 49 : Courbe d’erreur matlab et C++ (enveloppe_indices – patient 40)
Lors de l’utilisation du spectrogramme, et donc des vraies valeurs, il conviendra d’être
vigilant sur les écarts constatés aux points testés ci-dessus.
Cela passera notamment par une étude plus approfondie du fonctionnement des variables et de
la librairie Eigen, notamment car de matlab à C++, le langage fonctionne différemment et à
petite échelle, les différences peuvent tout à fait se justifier par des subtilités de langage
imperceptibles pour des applications qui seraient moins précises.
Au final, les résultats sont très satisfaisants puisqu’en utilisant l’approximation de matlab à 6
chiffres après la virgule, on conserve la même régularité de résultats que sous matlab. Les
tests ont d’ailleurs été effectués sur plusieurs jeux de données et donnent tous des résultats
similaires. Cela dit, il subsiste que j’ai utilisé des arrondis au travers de mes tests (fonction
round) à cause de ma méthode d’utilisation du fichier texte pour utiliser les spectrogrammes.
113
2537
4961
7385
975
9 1721 29
33 4145 53
57 6569 77
81 8993 101
105109
113117
121125
129133
137141
145149
153157
161165
169173
177181
185
0
50
100
150
200
250
Courbes d'enveloppe matlab - c++ enveloppe_matlab
enveloppe_cplusplus
erreur entre matlab et c++ (en pixel)
Position du pixel sur l'image
Positio
n d
u p
ixel s
ur
l'im
age
54
Il faudra donc implémenter l’algorithme que j’ai codé dans une chaîne de traitements
finalisée, c’est-à-dire qui contient le code du spectrogramme afin de valider le code.
Finalement, j’ai effectué quelques comparaisons sur les temps de calcul entre matlab et c++
pour la fenêtre de 189 colonnes (soit 1s). Les résultats sont présentés ci-dessous :
Patient 31 Patient 38 Patient 40
Temps d'exécution C++ 0,45s 0,47s 0,42s
Temps d'exécution matlab 2,8s 2,85s 2,75s
Figure 50 : Temps de calcul de l’algorithme sur les patients 31, 38, 40 – matlab et c++
Les résultats sont améliorés en comparaison de l’algorithme de matlab : 450ms en moyenne
en c++ contre 2.8s sous matlab. Cela dit, plusieurs améliorations sont encore possibles :
- Eviter l’utilisation d’intermédiaires au travers du fichier texte pour importer le
spectrogramme ainsi que l’utilisation de la méthode de conversion de chaînes de caractères,
qui alourdissent le calcul de l’algorithme. Il conviendrait d’effectuer des tests avec le
spectrogramme dans la continuité de la chaîne ;
- L’utilisation des tableaux Eigen pourrait clairement être optimisée, notamment car des
tableaux « tampons » ont été définis et utilisés pour éviter les problèmes de gestion de taille
dynamique. Ces derniers sont ainsi créés à chaque incrémentation dans la boucle du calcul de
l’enveloppe, soit au total 189 fois (correspondant aux 189 colonnes de l’image), ce qui ralentit
fortement l’algorithme. Au lieu de recréer le même tableau à chaque incrémentation dans la
boucle, il conviendrait de trouver une alternative aux tailles dynamiques en exploitant peut-
être des fonctions plus avancées d’Eigen ;
- Certaines portions de code sont encore trop « lourdes » et pourraient être synthétisées par
l’utilisation de fonctions d’Eigen optimisées. Par exemple, par souci de simplicité et de
compréhension de fonctionnement, j’attribuais à un tableau valeur à valeur d’un autre
tableau. Attribuer directement des block permettrait d’éviter cette lourdeur de code. Cette
modification a déjà été entamée et il faudrait donc continuer sur cette lancée ;
- Optimiser l’utilisation du compilateur. Par exemple, j’ai utilisé l’optimisation de niveau 3 pour
compiler (-o3) en lieu et place du niveau 2, ce qui a donné les performances ci-dessus (on
gagne environ 800ms par rapport à une optimisation de niveau 2). Il est très certainement
possible de moduler encore plus le compilateur, qui joue pour beaucoup dans l’exécution du
code ;
- Et finalement, envisager d’utiliser un double pointeur au lieu de la librairie Eigen pour
manipuler les tableaux 1D et 2D pourrait améliorer, ou non, la rapidité d’exécution, puisqu’on
n’a plus à définir de multiples tableaux Eigen, mais simplement à utiliser un seul double
pointeur.
55
V. Mon projet professionnel
J’ai effectué mon stage au sein de Creatis avec comme objectif la continuité de mon projet
professionnel. J’ai énormément appris au cours de mes études d’ingénieur, et souhaitais
capitaliser sur mon savoir, mais aussi développer de nouvelles compétences, telle que le
javascript et le C++.
Avec une réflexion sur la durée, je construis un projet de réorientation pour suivre des études
en médecine, notamment à la suite de mes stages qui m’ont mis en contact avec
l’environnement médical, bien que cela ait été du point de vue industriel.
Je ne souhaite pas m’insérer dans un environnement industriel et me focaliser sur le produit
ou la technique et c’est à force d’interaction avec médecins et personnels hospitaliers que mon
ambition se confirme.
Cela dit, je souhaite préparer ce changement de voie du mieux possible et confirmer ma
volonté sur la durée, tout en rattrapant mon retard sur les cours de médecine afin de préparer
mon dossier du mieux possible.
J’envisage donc pour l’instant d’expérimenter le métier d’ingénieur en lien avec le milieu
médical afin de favoriser mes chances de réorientation, mais aussi et surtout avoir une
expérience industrielle qui je pense me sera très instructive.
56
Conclusion technique
Les deux projets sur lesquels j’ai travaillé ont été une formidable occasion d’approfondir le
C++, et de découvrir l’environnement de développement web autour du javascript.
Etant donné que l’équipe ne disposait pas de connaissances sur l’environnement du desk et
n’avait jusqu’à alors pas débuté le codage en C++, cette expérience m’a aussi permis
d’apprendre à gérer mon temps, mes priorités et l’approche du projet.
Bien que j’ai pu solliciter l’aide de mes collègues concernant les aspects informatiques qui
m’échappaient, notamment en ce qui concerne l’environnement linux mais aussi javascript,
cela a été l’opportunité d’apprendre énormément étant donné que je partais de zéro.
A terme, j’ai pu consolider de bonnes bases en javascript, et appliquer concrètement mes
connaissances en C++ dans un contexte industriel.
Côté démonstrateur web, l’échographe haute fréquence est fonctionnel et donne un résultat
satisfaisant par rapport aux exigences initiales. Il sera cela dit toujours possible de l’optimiser,
notamment son interface et son ergonomie
Le démonstrateur pour le doppler transcrânien nécessitera quant à lui de faire appel à
plusieurs exécutables successifs étant donné la forme du code. Il sera donc judicieux de le
développer une fois que le code matlab du projet sera complètement porté en C++.
Similairement, le code C++du doppler est fonctionnel et exploitable. L’utilisation de la
librairie Eigen aura été un puissant vecteur pour la réalisation de ce projet. De même que le
démonstrateur de l’échographe, il est aussi toujours possible de l’optimiser en termes de
gestion et d’utilisation de variables, et il reste à coder les fonctions mises de côté jusqu’à
maintenant.
57
Conclusion personnelle
Ce stage de 6 mois aura été une vraie aubaine : j’y ai rencontré des gens patients, pédagogues
et très intéressants. J’ai énormément appris sur le fonctionnement d’un laboratoire, et le
domaine technique dans lequel il s’inscrit. C’était un volet différent de mon précédent stage,
qui avait été beaucoup plus industriel
J’ai été très bien accueilli, et tout a été fait pour que je m’intègre le plus vite et le mieux
possible à l’équipe, et que je prenne en main l’environnement des deux projets.
Par ailleurs, cette expérience est je pense cruciale pour la suite de mon projet personnel qui est
de suivre des études de médecine. Il a fait le pont avec mes études d’ingénieur, et m’a permis
de mettre un pied dans le monde médical, et de confirmer mon choix de réorientation.
58
Bibliographie
[JACI-12] H. Jacinto, R. Kéchichian, M. Desvignes, R. Prost, and S. Valette - A Web
Interface for 3D Visualization and Interactive Segmentation of Medical Images -
17th International Conference on 3D Web Technology (Web 3D 2012), Los-Angeles,
USA, pp. 51-58, 2012
Link: http://www.creatis.insa-lyon.fr/site/fr/publications/JACI-12
[SCIO-15a] B. Sciolla, P. Ceccato, L. Cowell, T. Dambry, B. Guibert, P. Delachartre-
Segmentation of inhomogeneous skin tissues in high-frequency 3D ultrasound
images, the advantage of non-parametric log-likelihood methods - International Congress on Ultrasonics, Metz, France, 2015
Link: https://www.creatis.insa-lyon.fr/site/fr/SCIO-15a
[LIN-14b] F. Lin, C. Saglio, M. Almar, B. Guibert, and P. Delachartre, "Micro-
embolic signal characterization based on long time Doppler time-frequency
image processing and statistics", IEEE International Conference on Signal
Processing, Hangzhou, China, pp. 1046-1051, 2014 Link: http://www.creatis.insa-lyon.fr/site/fr/publications/LIN-14b
Sitographie
http://www.creatis.insa-lyon.fr/site/ : site de Creatis
http://www.atysmedical.com/ : site d’Atys Medical
http://stackoverflow.com/ : réseau social informatique pour toutes les questions concernant
la programmation
http://w3schools.com/ : ensemble de cours de langages informatiques, notamment
javascript
http://Openclassrooms.com/ : ensemble de cours de langages informatiques, notamment
javascript
http://www.qt.io/download-open-source/ : Téléchargement et installation de l’interface de
développement QtCreator
http://www.cplusplus.com/ : référence du c++
http://fr.mathworks.com/ : référence des fonctions matlab
59
http://eigen.tuxfamily.org/ : site officiel de la librairie Eigen
http://sante.gouv.fr/les-chiffres-cles-de-l-avc.html : chiffres clés de l’AVC
https://desk.creatis.insa-lyon.fr/user/application/api/#desk.MeshViewer : documentation
des fonctions de la librairie qooxdoo (utilisée dans le desk)
Sommaire des annexes
Annexe I : Exemple de programme javascript sous desk ......................................................... 59
Annexe II : Données présentes sous Atyscrea.fr ...................................................................... 60
60
Annexes
Annexe I : Exemple de programme javascript sous desk
61
Annexe II : Données présentes sous Atyscrea.fr
J’ai laissé sous AtysCrea plusieurs documents que voici :
- Mon rapport, qui contient en particulier des informations concernant l’avancement
de la transposition du code matlab en c++ du projet doppler transcrânien. Sont
notamment détaillées les approches d’étude des fonctions et plus généralement de
l’algorithme, ainsi que les outils utilisés en c++. Le rapport présente aussi le
développement du démonstrateur web, avec un aspect « guide utilisateur » porté sur
la prise en main de l’environnement du desk, et des explications sur le démonstrateur
de l’échographie haute fréquence ;
- Le code C++ portant sur la partie « calcul de l’enveloppe », depuis l’utilisation du
spectrogramme, jusqu’à l’obtention de la vitesse maximale et de l’enveloppe. Le code
est commenté, notamment en ce qui concerne les subtilités du c++. Le code originel
matlab est disponible sous AtysCrea et a été developpé par Mlle Pinatel. ;
- Le lien du démonstrateur web redirigeant vers la fenêtre de développement du
démonstrateur échographie haute fréquence. Dans l’arborescence de la fenêtre
principale, mon code porte le nom développement_final_Mehdi et il est commenté.
Des versions moins avancées sont aussi disponibles sous le nom développement_vX
(X étant l’indice). Chaqueversion ajoute une fonctionnalité supplémentaire.
62
Résumé J’ai effectué mon projet de fin d’études en département Génie électrique à l’INSA de Lyon au
sein du laboratoire Creatis.
Il a été question d’intervenir sur deux projets afin de réaliser un démonstrateur web en
javascipt, et transposer un code matlab vers C++.
Le premier a été codé en utilisant la librairie javascript desk développée par M. Valette,
chercheur à Creatis. Elle se base sur des technologies web telles que HTML5, WebGL, etc…
pour permettre une interaction client/serveur transparente autorisant par exemple de lancer des
exécutables depuis le serveur, côté client.
J’ai porté le code matlab du doppler transcrânien en C++ en utilisant la librairie Eigen. Matlab
étant un outil très puissant, la portabilité en C++ a demandé réflexion afin de transposer le
plus efficacement le code d’un point de vue gestion des variables, architecture et syntaxe.
Au final, ce stage a certes nécessité des connaissances techniques, mais surtout une bonne
gestion du temps et des priorités, afin de me former efficacement et d’aborder les différents
aspects des projets efficacement.
Logos
