Projet : Au sein d'une Tierce Maintenance Applicative pour le compte France Télécom/Orange, refonte de l'application centrale (RPG, AS/400, DB2) en une application cible Java J2EE. Projet de 2500j, faisant intervenir une quinzaine de personnes.
Rôle :
Mise en œuvre du processus de reprise des données de l'application en cours de refonte (ETL Genio, $Universe).
Rédaction de spécifications fonctionnelles pour la refonte des interfaces de flux de données entre cette application et les autres applications du SI, ainsi que vers des SI extérieurs. Rédaction de spécifications pour la prise en compte des impacts sur les autres applications du SI (reprise de données). Chiffrage et spécifications d’autres évolutions dans le cadre de la TMA. Échanges en direct avec le client.
Création et modification des interfaces entre les différentes applications du SI (Genio, $U, CFT). Prise en charge des mises en recette client.
Qualification interne des évolutions sur les interfaces.
Projet : Tierce Maintenance Applicative pour le compte France Télécom, de 1500j/an dans une équipe de 6 à 10 personnes.
Rôle :
Chiffrage d'évolutions, rédaction de spécifications fonctionnelles, échanges avec le métier
Mise en œuvre du processus de reprise des données pour la migration de la base d’une application type CRM vers celle d'une nouvelle application Java (ETL Genio ; projet cible de l’étude de 700j)
Création et modification des interfaces de flux de données entre les différentes applications du Système d’Information (Genio, $Universe, CFT). Création de nouvelles interfaces. Tests unitaires. Prise en charge des mises en recette client. Prise en charge et supervision des mises en pré-production, et en production.
Supervision quotidienne des flux de données en production. Analyse et prise en charge des incidents (Genio, $Universe, CFT)
Définition et éxécution plan de tests de recette et de montée en charge sur la refonte d’une application existante.
-- Environnement technique : Genio (ETL), Dollar Universe (Ordonnanceur), CFT, Oracle, MySQL, Test Director, AS/400, DB2.
Projet d'école en relation avec l'entreprise Projet : Application mobile multi-plate-forme de synchronisation de contacts
Interface graphique, gestion des inscriptions, connexions et déconnexions à l’application. Importation/exportation des données des contacts d’un téléphone. Interaction avec la base de données d’un site via webservice.
Création de nouvelles fonctionnalités dont un outil d’ajout automatisé de nouvelles langues pour l’interface du site -- Environnement technique : PHP, Javascript, MySQL
Projet : application Android de création collaborative de dictionnaires
Bases de développement pour Android -- Environnement technique : Java
Projet d'école en relation avec l'entreprise Projet : Outil web de visionnage d’images radiologiques
Evolution sur un outil de conversion d'images radiologiques (problématique d'encodage de pixels, de volume et de format d'image)
Adaptation de l'outil de visionnage au nouveau format d’images
Création et amélioration de fonctionnalités (variation de contraste/luminosité, enregistrement d’annotations sur les images, calculs médicaux) -- Environnement technique : Java, Javascript, AJAX, PHP
Détails de l'expérience
Il s'agit d'un projet professionnel en équipe de 3 confié par l'école Polytech' Montpellier, dans le cadre de mes études, en relation avec l'entreprise Xray-files.
Le projet portait sur le développement d'un outil de visionnage en ligne d'images radiologiques. L'objectif de cet outil, pour notre demandeur, était de permettre à des apprentis radiologues d'apprendre et de s'exercer au travers d'exercices s'appuyant directement sur des images, que l'on pourrait visionner en ligne de la même façon qu'avec du matériel professionnel dans un hôpital.
La problématique principale du projet était de pouvoir utiliser des fichiers d'images radiologiques dans un outil web. En effet, le format spécifique des images radiologiques (DICOM), les rend inadaptées aux navigateurs web, et très lourdes dû à la grande qualité d'image.
Le projet s'est donc articulé en deux parties interdépendantes.
La première partie a consisté en l'élaboration d'un outil, sur mesure, en Java, de conversion d'images DICOM en images légères, exploitables par un navigateur, et surtout gardant la qualité d'images nécessaire à un diagnostic médical. La seconde partie nous a demandé d'adapter l'outil de visionnage existant, pour y intégrer une fonctionnalité de régulation du contraste et de l'intensité de l'image, afin de restituer l'intégralité de l'information contenue dans nos images "sur mesure", de qualité supérieure.
Voici un détail plus complet :
Dans une image radiologique DICOM (noir et blanc), chaque pixel est représenté par une série de 12 bits déterminant son niveau de gris : douze 1 représentent un pixel complètement blanc, tandis que douze 0 représentent un pixel complètement noir. De l'un à l'autre, on peut avoir 4096 nuances de gris différentes.
Dans une image classique affichée par un navigateur, un pixel est représenté par 24 bits : 8 bits définissant la quantité de rouge, 8 pour le vert, et 8 pour le bleu. Cela donne 256 niveaux pour chaque couleur, et le mélange des trois niveaux de rouge-vert-bleu donne une couleur pour le pixel. Il faut savoir que trois niveaux égaux donnent un pixel gris.
Avant que nous soyons acteurs du projet, un outil de conversion existait mais n'était pas satisfaisant. Il fonctionnait en prenant la valeur (entre 0 et 4095) de chaque pixel des images DICOM, en la divisant par 16 et en l'arrondissant pour obtenir une valeur entre 0 et 255, et l'attribuer aux trois parties d'un pixel d'une image rouge-vert-bleu. En procédant de la sorte, on peut ainsi afficher, via un navigateur, une image grise dont on aura divisé la qualité par 16, ce qui rend l'image inexploitable car trop imprécise (pour faire simple, un trou dans un os ne serait pas distinguable).
Notre contribution a commencé par la création d'un autre convertisseur gardant toute l'information des images radiologiques dans des fichiers d'images qui ne sont pas affichables directement : les 12 bits d'information sont gardés, 4 étant mis dans la partie verte, et 8 dans la partie bleue. Cela donne des images en couleur, déformées, que notre outil web pourrait lire, et afficher différemment par le biais de fonctions que l'on aurait créées.
Le problème de qualité d'image était résolu, le problème de format également (images converties en PNG, affichables par un navigateur), mais le problème de poids des images, bien que considérablement réduit, était toujours présent. Cela avait pour conséquence un upload des fichiers trop long, mais surtout un temps de chargement des images par le navigateur trop long, étant donné que les examens d'images radiologiques reposent en général sur plusieurs centaines d'images (empilages de coupes horizontales ou verticales) que l'on fait défiler. Nous avons donc étudié plusieurs pistes pour réduire le poids des images (autres bibliothèques de traitement d'image, autres formats d'images, algorithmes de compression) et testé les résultats, pour finalement réduire la qualité de façon mesurée pour que cela ne soit pas gênant et pour que l'on ait des fichiers assez légers.
En parallèle, nous avons dû nous pencher sur des fonctions pour afficher notre image dans l'outil de visionnage (HTML5/Javascript/CSS), sachant que d'une part, nous partons d'une image composée de vert et de bleu, que l'on veut afficher en gris, et que d'autre part, quoi qu'il en soit, le navigateur n'affichera pas plus de 256 nuances de gris (alors qu'on en veut au mieux 4096). L'application de méthodes d'affichage des outils radiologiques classiques nous a été utile pour cela, notamment les notions d'intensité et de contraste. L'intensité, réglable par l'utilisateur grâce à des éléments de l'interface graphique, lui permet de visualiser, au choix, les parties les plus sombres de l'image en détail (par exemple, les pixels de valeur entre 0 et 255 sont affichés selon les 255 nuances de gris, et les pixels de valeurs 256 à 4095 sont affichés en blanc), ou les parties les plus claires (par exemple, les pixels de valeur entre 3840 et 4095 sont affichés selon les 255 nuances de gris, et les pixels de valeurs inférieures sont affichés en noir). Le contraste, réglable également par l'utilisateur, lui permet de réduire ou d'élargir cette "fenêtre de détail", pour, par exemple, répartir les 256 couleurs de façon régulière sur l'intervalle de valeurs [0;511], avec une nuance de gris pour deux valeurs. Pour résumer, ces deux fonctionnalités, couplées aux images de qualité qui ont été créées, permettent au radiologue de voir les parties sombres en détail (muscles, nerfs, tendons...), les parties claires en détail (os, métal), ou un ensemble en perdant un peu en qualité.
Enfin, d'autres fonctionnalités plus simples ont été implémentées, permettant d'afficher à l'écran la valeur moyenne des pixels d'une zone sélectionnée (permettant au radiologue d'identifier la nature d'un élément inhabituel d'une image), de mesurer des distances réelles, ou encore aux "administrateurs" de dessiner des flèches sur les images et les enregistrer en base de données (AJAX) (leur permettant de pointer des indications sur des dossiers, qui pour rappel, sont consultés dans un but pédagogique). Les formulaires de soumission de dossiers ont été également retouchés, principalement pour réaliser l'upload de dossiers sur le serveur (PHP).