Herramienta WEB para la visualizacion y segmentacion 3D de imagenes medicas

Vista previa del material en texto

Herramienta WEB para la Visualización y
Segmentación 3D de Imágenes Médicas
Gustavo Tajes Genga
Trabajo de grado presentado como requisito para optar al título de:
Ingeniería de Sistemas
Directores:
Dra. Mariana del Fresno
Dr. Juan D’Amato
1
Resumen
El análisis de imágenes médicas y el diagnóstico asistido por computadora es un campo en
continuo desarrollo. Con la evolución de la tecnología han ido surgiendo diferentes
modalidades de captura de imágenes médicas, que se usan para explorar el cuerpo humano
con el fin de diagnosticar, controlar o tratar afecciones. Las diversas técnicas utilizadas para
la obtención de dichas imágenes por parte de distintos fabricantes generó la definición de un
estándar, llamado DICOM, para estandarizar su almacenamiento y comunicación. Para su
análisis e interpretación, las imágenes suelen ser procesadas previamente. Dentro de las
distintas etapas de procesamiento, una de las etapas más importantes consiste en la
segmentación, es decir la delineación de estructuras anatómicas o patológicas que resulten de
interés. Actualmente existen numerosas herramientas para segmentación y visualización de
imágenes, pero en muchos casos son costosas, además de no estar consolidadas y depender de
componentes adicionales. Siguiendo la creciente tendencia al desarrollo de aplicaciones web,
en este trabajo se presenta el desarrollo de una herramienta web para gestionar, visualizar y
segmentar imágenes médicas 2D y 3D en formato DICOM. La herramienta proporciona
funcionalidades para la construcción de los algoritmos de procesamiento por parte del
usuario, además de permitir la interacción con las imágenes tanto en 2D como en 3D.
Palabras clave: imágenes médicas, procesamiento de imágenes, segmentación de imágenes,
dicom, web
2
Agradecimientos
Quiero hacer un agradecimiento por haber sido parte de esta aventura:
● A mis padres: Mirta y Rodolfo, por su esfuerzo, por apoyarme y animarme en toda
esta etapa. De ellos aprendí a perseverar y a levantarme con cada caída.
● A mi esposa: Angela, por ser mi apoyo y sostén durante este último tramo del
camino. Por su tiempo y su comprensión.
● A los hermanos y amigos que la vida me regaló: por alentarme en cada paso, por
sus oraciones y por su ayuda cada vez que la necesité.
● A mis directores: Mariana y Juan, por acompañarme y guiarme durante el desarrollo
de esta tesis. Por sus sugerencias, su disponibilidad y su ayuda constante.
● A todos los docentes y no docentes con los cuales compartí mi trayecto por la
Universidad pública: por su dedicación y por haber sido parte de mi formación como
profesional.
● A Dios: por las personas que puso en mi camino, las que están y las que ya no, pero
que de una u otra forma pusieron su granito de arena. Por su providencia, sin ella nada
de esto hubiera sido posible.
3
Contenido
Resumen 1
Agradecimientos 2
Lista de Figuras 5
Lista de Tablas 7
Lista de Bloques de Código 8
1 Introducción 9
1.1 Motivación y objetivo del trabajo 10
1.2 Organización del trabajo 11
2 Visualización y Segmentación de imágenes médicas 12
2.1 Imagen médica 12
2.2 Estándar DICOM 13
2.1 Etapas del procesamiento de imágenes médicas 14
2.1.1 Captura 15
2.1.2 Preprocesamiento 16
2.1.3. Extracción de características 16
2.1.4 Segmentación 17
2.1.5. Registración 18
2.1.6 Visualización 18
2.2 Análisis y Elección de Tecnologías 19
2.2.1 Tecnologías de Visualización 19
webDICOM 20
med3web 20
Papaya 21
OHIFViewers 22
4
2.2.2 Tecnologías de almacenamiento 25
DICOMcloud 25
Orthanc 26
2.2.3 Tecnologías de procesamiento 27
VTK 27
ITK 28
SimpleITK 28
2.2.4 Tecnologías de comunicación 28
3 Diseño e Implementación 30
3.1 Diseño del visualizador WEB 31
3.2 Diseño del segmentador de imágenes 35
3.2.1 Plugin de Orthanc 35
3.2.2 SimpleITK + Spring Boot 37
4 Resultados 44
5 Conclusiones y trabajos futuros 52
5.1 Conclusiones 52
5.2 Trabajos futuros 52
Anexo A: Utilización de la herramienta 54
A1. Interfaz web del servidor de imágenes DICOM 54
A2. Interfaz web del visualizador de imágenes 55
A3. Interfaz web del segmentador 57
A3-1. Interfaz basada en ReactJS 57
A3-2. Interfaz mediante Swagger UI 59
Bibliografía 63
5
Lista de Figuras
Figura 2-1. Etapas del procesamiento de imágenes médicas. 15
Figura 2-2. Interfaz gráfica de la herramienta webDICOM. 20
Figura 2-3. Interfaz gráfica de la herramienta med3web. 21
Figura 2-4. Visualizador 3D de la herramienta med3web. 21
Figura 2-5. Interfaz gráfica de la herramienta Papaya. 22
Figura 2-6. Interfaz gráfica de la herramienta OHIFViewer. 23
Figura 3-1. Módulos de la aplicación y flujo de interacción entre ellos. 31
Figura 3-2. Descripción del layout original del visualizador OHIF. 32
Figura 3-3. Herramientas para la manipulación de las vistas 3D. 34
Figura 3-4. Vista del selector de pipelines. 34
Figura 3-5. Diagrama de secuencia de una segmentación desde el visualizador. 35
Figura 3-6. Ejemplo de un pipeline de procesamiento ITK/SimpleITK. 37
Figura 3-7. Ejemplo de un pipeline de procesamiento ITK/SimpleITK simplificado. 38
Figura 3-8. Modelo de la entidad que representa a la tabla Pipeline. 39
Figura 3-9. Diagrama de clases de un filtro. 39
Figura 3-10. Endpoints para la consulta de filtros. 43
Figura 3-11. Endpoints para las operaciones CRUD sobre los pipelines. 43
Figura 4-1. Utilización de memoria y CPU del perfil 1 al momento del arranque del
segmentador. 45
Figuras 4-2. Capturas de pantalla de la segmentación del ventrículo cerebral
izquierdo vistas en diferentes ángulos. Vista frontal (izq.) y vista anterior derecha
(der.). 47
Figura 4-3. Vista 2D de un corte de la MRI (izq) y vista 3D (der) de la
segmentación. 47
Figura 4-4. Utilización de memoria y CPU del perfil 2 al momento del arranque del
segmentador. 48
6
Figura 4-5. Vistas 3D de la segmentación de pulmones y arterias pulmonares. 50
Figura A1-1. Vista general de la interfaz web del servidor DICOM. 54
Figura A1-2. Vista general de la interfaz web para la carga de estudios. 55
Figura A2-1. Vista general de la interfaz web de autenticación del visualizador. 55
Figura A2-2. Vista general de la interfaz web para listar los estudios existentes. 56
Figura A2-3. Vista general de la interfaz web para visualización de imágenes 2D y
3D. 56
Figura A3-1. Vista del listado de pipelines y botones para interactuar con los
mismos. 58
Figura A3-2. Vista de la configuración de filtros de un pipeline. 58
Figura A3-3. Vista de la configuración de parámetros de un filtro. 59
Figura A3-4. Vista de los controladores y endpoints del segmentador en Swagger. 59
Figura A3-5. Vista de un endpoint en Swagger. 61
7
Lista de Tablas
Tabla 2-1. Tabla comparativa de características y funcionalidades de las
herramientas evaluadas. 24
Tabla 2-2. Tabla comparativa de características y funcionalidades de los servidores
DICOM evaluados. 27
Tabla 4-1. Tabla de resultados del perfil 1 para la segmentación del ventrículo
cerebral izquierdo. 46
Tabla 4-2. Tabla de resultados del perfil 2 para la segmentación del ventrículo
cerebral izquierdo. 48
Tabla 4-3. Tabla de resultados del perfil 1 para la segmentación de los pulmones y
arterias pulmonares. 50
Tabla 4-4. Tabla de resultados del perfil 2 para la segmentación de los pulmones y
arterias pulmonares. 51
8
Lista de Bloques de Código
Bloque 3-1. Template del motor BlazeJS para visualización de imágenes 3D. 33
Bloque 3-2. Definición del endpoint rest en el plugin. 36
Bloque 3-3. Ejemplo de carga de una imagen con ITK. 36
Bloque 3-4. Modelo JSON de un Filtro. 37
Bloque 3-5. Ejemplo de filtro (RescaleIntensityImageFilter) sin instanciar en un
pipeline. 41
Bloque 3-6. Ejemplo de filtro (RescaleIntensityImageFilter) instanciado en un
pipeline. 42
9
1 Introducción
Durante los últimos años, la medicina se ha visto beneficiada por diversos avances científicos
y tecnológicos. Entre ellos, han surgido diferentes modalidades de imágenes médicas que se
usan para explorar el cuerpo humano con el fin de diagnosticar,controlar o tratar afecciones
[1]. La obtención de las diferentes imágenes implica, en muchos casos, irradiar al paciente
con algún tipo de energía y las distintas técnicas utilizadas se pueden clasificar en función de
la radiación que emplean, siendo éstas: radiación ionizante o no ionizante. Dentro del primer
grupo se distinguen las que emplean rayos X, siendo algunas de ellas: la radiografía, la
mamografía, la angiografía y la tomografía computada; como así también las técnicas de
medicina nuclear. En el caso de la radiación no ionizante, es decir, radiación electromagnética
y/o campos magnéticos, se incluyen la ecografía y las imágenes de resonancia magnética
[2,3].
Para llevar a cabo el diagnóstico o evaluación de tratamientos, en muchos casos los médicos
se basan en el análisis e interpretación de la información contenida en una o más imágenes.
Esta tarea requiere tiempo y esfuerzo, y en ciertos casos puede resultar tediosa y susceptible a
errores humanos, especialmente debido al gran volumen de datos que suelen contener algunas
modalidades. Es por este motivo que se han desarrollado diferentes aplicaciones para el
diagnóstico asistido por computadora (CAD, por Computer-Aided Diagnosis) y asimismo
para guiar la planificación y evaluación de tratamientos, temas que son objeto de
investigación y avances continuos [4].
El área del análisis de imágenes médicas ha progresado notablemente en los últimos años,
ofreciendo diversas alternativas para procesamiento, visualización y segmentación de
imágenes, ya sean automáticas o semiautomáticas. En algunos casos, a pesar de los avances
en computación gráfica y visualización computacional, las facilidades suelen realizarse sobre
los cortes bidimensionales (2D) de las imágenes, aunque sean volumétricas, siendo el médico
quien debe interpretarlas espacialmente como si estuviera viendo un modelo tridimensional
(3D). A tal fin, puede resultar de utilidad proporcionar vistas de los volúmenes o superficies
de los objetos de interés en dichas imágenes para asistir al profesional. Esta funcionalidad
puede complementarse con la aplicación de diversas técnicas de pre-procesamiento, como la
mejora del contraste, la supresión de “ruido” y la segmentación de la imagen seleccionando
las estructuras de interés en base a diferentes características [5].
https://sciwheel.com/work/citation?ids=10721426&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9938763,10721433&pre=&pre=&suf=&suf=&sa=0,0
https://sciwheel.com/work/citation?ids=11262439&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9278796&pre=&suf=&sa=0
10
1.1 Motivación y objetivo del trabajo
Existen numerosas herramientas CAD para el procesamiento de imágenes, disponibles para
fines de investigación y diagnóstico. Algunas de ellas, como por ejemplo 3D Slicer [6],
MIPAV [7] o 3D-Doctor [8], permiten preprocesar, segmentar y visualizar imágenes médicas
en 3D. Además, brindan soporte para el formato estándar DICOM (Digital Imaging and
Communication in Medicine), el cual desde hace años se considera el estándar para
transmisión y almacenamiento de imágenes médicas [9]. Sin embargo, muchas de estas
herramientas están disponibles sólo como aplicaciones locales, limitando el acceso a los datos
y su procesamiento desde estaciones de trabajo específicas [10].
Un requerimiento cada vez más importante a la hora de trabajar con imágenes médicas es la
capacidad de acceder de forma fácil y rápida a los datos. Es por esto que la evolución de las
tecnologías web y de las características de los navegadores han favorecido el desarrollo de
aplicaciones de imágenes médicas basadas en web [11]. Este tipo de soluciones se están
difundiendo, permitiendo así expandir las capacidades de exploración y análisis de
información médica según la creciente demanda de servicios hacia diversas áreas geográficas
incluso remotas, con beneficios en el área de la telemedicina y del trabajo colaborativo entre
especialistas [12].
Sin embargo, algunas de las herramientas web propuestas suelen tener una funcionalidad
deficiente de interfaz de usuario o requieren que el usuario descargue e instale componentes
adicionales, que generan dependencias con alguna otra aplicación o sistema operativo (por
ejemplo, la Java Virtual Machine para el caso de Java Applets o Windows en el caso de los
controles ActiveX). Esto ocasiona la pérdida de muchas ventajas de las aplicaciones web
basadas en estos componentes, además de ser utilizados para explotar vulnerabilidades o
riesgos de seguridad en las estaciones de trabajo donde son ejecutados [10]. Por estos
motivos, la tendencia actual es buscar el desarrollo de aplicaciones que faciliten la
visualización y procesamiento de imágenes médicas en el navegador, sin requerir instalación
o descarga previa de componentes, favoreciendo al mismo tiempo el acceso desde cualquier
estación de trabajo o dispositivo. Varios proveedores comerciales de equipos radiológicos han
comenzado a adoptar soluciones basadas en web. No obstante, hay una creciente tendencia
hacia el desarrollo de soluciones basadas en el concepto de software de código abierto (open
source), que brinden mayor flexibilidad y extensibilidad [13].
El objetivo de este trabajo es el desarrollo de una herramienta web open source para
gestionar, visualizar y segmentar imágenes médicas, para análisis de imágenes individuales o
de secuencias de imágenes DICOM 2D (planas) o 3D (volúmenes). La herramienta provee
acceso a las imágenes, controles básicos y facilidades de visualización. También permite la
configuración y combinación de diferentes algoritmos para procesamiento de las imágenes
basados en la librería ITK, a fin de asistir en la exploración y segmentación de estructuras de
interés, los que son ejecutados en un servidor de procesamiento. La comunicación entre los
https://sciwheel.com/work/citation?ids=10722320&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10722326&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10722361&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=11178354&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10722374&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=11178183&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=11178439&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10722374&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=11178415&pre=&suf=&sa=0
11
módulos se lleva a cabo a través de servicios REST, sin requerir la instalación de
componentes adicionales.
1.2 Organización del trabajo
Este documento se organiza en una serie de capítulos que abordan los distintos aspectos
involucrados en el desarrollo del presente Trabajo Final.
En el Capítulo 2 se introducen las características de las imágenes médicas, del estándar
DICOM utilizado para su almacenamiento y comunicación y de las etapas que abarca el
procesamiento de imágenes. También se aborda el análisis de tecnologías disponibles y la
elección de aquellas que fueron utilizadas en el trabajo.
El Capítulo 3 describe los diferentes aspectos considerados en el diseño e implementación de
la herramienta desarrollada, bajo el concepto de software libre.
En el Capítulo 4 se presentan algunos resultados obtenidos a fin de evaluar la performance de
la herramienta, realizados sobre diferentes perfiles de hardware.
Finalmente, en el Capítulo 5 se incluyen las conclusiones y posibles trabajos futuros.
12
2 Visualización y Segmentación de imágenes médicas
En este capítulo se presenta una introducción al concepto de imagen médica, sus
características y al estándar utilizado por la industria para el almacenamiento y comunicación
de las mismas. Luego se explican las etapas de procesamiento de imágenes médicas y
finalmente se describe el proceso de análisis y elección de tecnologías utilizadas en el
presente trabajo.
2.1 Imagen médica
Una imagen médica permite observar, ya sea interna o externamente, el cuerpo humano o
partes de él con propósitos clínicos, a fin de diagnosticar o tratar diversas enfermedades.
También son consideradascon propósitos científicos, brindando información para el estudio
de la anatomía o funcionamiento del organismo.
Las técnicas y procedimientos utilizados para la obtención de las imágenes, comúnmente
denominadas “modalidades de de imagen”, consisten en irradiar distintos tipos de energía
sobre el cuerpo humano o, en algún caso, desde el interior del mismo. Estas imágenes son
producidas por una amplia variedad de equipos, que en cada caso convierten las mediciones
obtenidas por los sensores a niveles de gris o tonos de color capaces de ser visualizados y
analizados posteriormente. Según el tipo de radiación utilizada, las modalidades de imagen se
pueden diferenciar según utilicen radiación ionizante, la cual debe usarse en forma controlada
para evitar daños sobre los tejidos con los que interaccionan, o no ionizante, que no tiene
capacidad de dañarlos [3].
En el primer grupo de técnicas de adquisición se encuentran la radiografía, que mediante el
uso de rayos X generan imágenes anatómicas planas del interior del cuerpo según la
capacidad de absorción de tales ondas por parte de los distintos materiales (los rayos X
atraviesan con facilidad los tejidos blandos como los órganos y la piel mientras que son
absorbidos por los tejidos duros como los huesos). También basadas en la utilización de rayos
X se encuentran la mamografía, que usa bajas dosis de radiación para la exploración de las
estructuras mamarias, la angiografía, que permite examinar los vasos sanguíneos mediante
inyección de contraste, y la tomografía computada (CT, por Computed Tomography), capaz
de generar imágenes tridimensionales a partir de cortes transversales reconstruidos desde
diferentes proyecciones del cuerpo humano (obtenidas en forma secuencial en los tomógrafos
tradicionales o con multidetectores en los tomógrafos helicoidales multicorte de última
generación). Además, se incluyen en este grupo las imágenes de medicina nuclear, como la
Tomografía por Emisión de Positrones (PET, por Positron Emission Tomography), en la cual
https://sciwheel.com/work/citation?ids=10721433&pre=&suf=&sa=0
13
se utilizan radiotrazadores administrados al paciente, cuyas emisiones son detectadas
mediante una cámara gamma para generar imágenes funcionales de la actividad corporal.
Por otra parte, se encuentran las imágenes de resonancia magnética (MRI, por Magnetic
Resonance Imaging), que mediante la utilización de un poderoso campo magnético y ondas
de radiofrecuencia logran alinear las moléculas de agua en el cuerpo y producir imágenes
tridimensionales detalladas de los tejidos blandos, articulaciones, etc. Otra modalidad
ampliamente utilizada es la ecografía, en la cual se emplea ultrasonido (US, por Ultra Sound)
para generar imágenes bidimensionales o tridimensionales a partir del eco recibido desde el
interior del cuerpo como respuesta a las ondas emitidas por un transductor.
Debido a la existencia de diferentes modalidades de captura, como así también de
características propias de almacenamiento según los distintos fabricantes de dispositivos,
surgió la necesidad de unificar el formato de las imágenes médicas. De esta forma, se crea el
estándar DICOM, el cual define no solo un formato de almacenamiento común para las
imágenes e información contextual, sino también todo un protocolo de comunicación de las
mismas [9]. A continuación se presenta una introducción a dicho estándar, y en particular, en
las áreas de almacenamiento y comunicación, las que son de interés para el presente trabajo.
2.2 Estándar DICOM
Existe un continuo desarrollo de nuevas técnicas en imágenes médicas y un incremento en las
modalidades de imágenes en formato digital. Esto ha ocasionado el desarrollo de sistemas de
administración de imágenes médicas llamados PACS (por Picture Archiving and
Communication System) [14,15].
La evolución en el diseño de PACS avanza hacia una arquitectura abierta, con equipos de
distintos proveedores basados en el estándar DICOM. Los principales objetivos de este
estándar son:
● Promover la comunicación de imágenes digitales sin importar el fabricante del
dispositivo.
● Facilitar el desarrollo y expansión de PACS que puedan interconectarse con otros
sistemas de información hospitalaria.
● Permitir la creación de bases de datos de información de diagnóstico que se puedan
consultar por una amplia variedad de dispositivos distribuidos geográficamente.
DICOM es un estándar que contempla el modelo orientado a objetos, buscando con ello que
los desarrollos en software del mismo sean más rápidos y que se elimine la necesidad de
reinventar cada vez que se hace una implementación de DICOM, dado que depende de
https://sciwheel.com/work/citation?ids=11178354&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899105,11178357&pre=&pre=&suf=&suf=&sa=0,0
14
modelos explícitos y detallados de cómo están descritos y relacionados los objetos (pacientes,
imágenes, reportes, etc). El diseño orientado a objetos proporciona una manera de describir la
información y qué hacer con ella, y DICOM hace uso de este concepto definiendo servicios
como “almacenar una imagen” u “obtener información del paciente”. Estos servicios se
implementan en DICOM usando construcciones conocidas como un conjunto genérico de
operaciones y notificaciones llamados Elementos de Servicio de Mensaje DICOM o DIMSE
(DICOM Message Service Element) [14].
Como se explica en [16], la forma en que se accede a la información provista por DICOM ha
ido cambiando a medida que las prestaciones aumentaron, de estar limitada dentro de un
hospital a ser compartida en toda la institución y entre instituciones. Estos cambios
requirieron nuevos requisitos de seguridad y políticas de tecnologías de la información para
DICOM. Como resultado, a partir de 2003 DICOM introdujo tecnologías web. Inicialmente
llamada WADO (por Web Access to DICOM Objects), esta tecnología definió un método para
recuperar objetos DICOM usando HTTP, la misma tecnología utilizada en la web. Con el
tiempo, se agregaron otros servicios a DICOM; esto incluyó la búsqueda a través de
QIDO-RS (consulta basada en ID para objetos DICOM) y la carga a través de STOW-RS
(almacenamiento en la web).
Posteriormente, WADO se actualizó a WADO-RS para seguir más de cerca el estilo RESTful
emergente de las interfaces web. En conjunto, estas tecnologías se conocieron como
DICOMweb. Las mismas agregan servicios web sobre HTTP a DICOM, modelados según el
estilo de REST (Representational State Transfer) [17]. REST se ha convertido en el estilo de
API dominante utilizado por empresas y mercados de todo el mundo [18].
Las imágenes médicas se definen en el estándar DICOM como objetos de información o
conjuntos de datos. Un objeto de información representa una instancia de un objeto de
información del mundo real (es decir, una imagen) y está compuesto de múltiples elementos
de datos que contienen los valores codificados de atributos de ese objeto. Cada elemento de
datos se compone de tres campos: la etiqueta del elemento de datos, la longitud del valor y el
valor del campo. La etiqueta del elemento de datos es un identificador único que consta de un
número de grupo y un número de elemento en notación hexadecimal, y se utiliza para
identificar el atributo específico del elemento. Por ejemplo, los datos de píxeles de una
imagen se almacenan en elementos con una etiqueta [7FE0, 0010], donde 7FE0 representa el
número de grupo y 0010 representa el número de elemento. La longitud del valor especifica
el número de bytes que componen el valor del campo. El valor del campo contiene los
valores del elemento de datos.
2.1 Etapas del procesamiento de imágenes médicas
El procesamiento de imágenes se puede definir como la manipulación y el análisis de la
información contenida en las mismas. En general, puede dividirse en 6 etapas (Figura 2-1), de
https://sciwheel.com/work/citation?ids=9899105&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=5234065&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899101&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9901932&pre=&suf=&sa=015
las cuales solo algunas pueden ser necesarias, dependiendo de los requerimientos de la
aplicación involucrada [19].
En primer lugar se encuentra la etapa de captura de la imagen mediante algún dispositivo. A
continuación, en la etapa de preprocesamiento, se puede mejorar el aspecto de la imagen
mediante diferentes técnicas para facilitar las etapas subsiguientes. En la etapa de extracción
de características se obtienen propiedades de interés de la imagen, útiles para la aplicación en
la cual será utilizada. En la etapa de segmentación se delimitan las áreas de interés a analizar,
utilizando diferentes algoritmos y criterios para diferenciarlas. En la etapa de registración es
posible combinar distintas imágenes, con el fin de correlacionar la información, usualmente
proveniente de distintas modalidades, y finalmente en la etapa de visualización se puede
analizar de forma gráfica el resultado del procesamiento.
Figura 2-1. Etapas del procesamiento de imágenes médicas.
A continuación se presenta una explicación más detallada de cada una de estas etapas.
2.1.1 Captura
La primera etapa del procesamento de imágenes consiste en la captura de la imagen mediante
alguna técnica o modalidad específica. En lo que respecta a imágenes médicas, según el tipo
de energía utilizada, algunas de las modalidades más utilizadas son: radiación
electromagnética por rayos X (radiología), radiación electromagnética por rayos gamma
(medicina nuclear), ultrasonido (ecografía), ondas de radio (resonancia magnética).
Con el avance de la tecnología y la aparición de nuevas modalidades, ha aparecido otro
criterio de clasificación en modalidades morfológicas (o estructurales) y funcionales. Las
primeras se caracterizan por producir imágenes de muy buena resolución, que permiten una
representación detallada de la anatomía del paciente. Las segundas, en cambio, se
caracterizan por aportar información sobre el funcionamiento de los diferentes órganos o
sistemas, algún rasgo de su metabolismo, su perfusión sanguínea, su capacidad para acumular
ciertas sustancias, etc.
En la etapa de captura, se registra la interacción de la energía con la muestra (el paciente).
Esta información es procesada y traducida en imágenes digitales que los médicos y/o
https://sciwheel.com/work/citation?ids=9919990&pre=&suf=&sa=0
https://lucid.app/documents/edit/e9daf5a0-2302-45d3-92e2-3858709a6a54/0?callback=close&name=docs&callback_type=back&v=678&s=595.4399999999999
16
profesionales pueden analizar, y que además sirve como información de entrada a la siguiente
etapa del procesamiento [2].
2.1.2 Preprocesamiento
Comúnmente la calidad de una imagen médica se ve deteriorada debido a la heterogeneidad
de los tejidos, la presencia de cuerpos extraños o artefactos, errores de hardware y software, o
movimientos del paciente durante la captura. Estos defectos pueden ocultar detalles
anatómicos y por ende, reducir la posibilidad de detectar lesiones [20]. El preprocesamiento
de las imágenes tiene como fin corregir estos defectos mediante diferentes técnicas, como así
también mejorar la apariencia visual de la imagen, resaltar características importantes y
suprimir o atenuar las características no deseadas. A continuación se describen algunas de
estas técnicas de preprocesamiento:
● Resampleo (resampling): Se trata de una técnica cuyo fin es crear una nueva versión
de la imagen, con diferente ancho y alto en píxeles. Para agrandar una imagen
(upsampling), esta técnica hace que aumente la cantidad de píxeles, lo cual suele
resultar en una imagen más borrosa debido a la disminución de información por pixel.
Por otro lado, al achicar una imagen (downsampling), es necesario descartar
información de la imagen original, sin embargo, esto puede resultar en una imagen
más nítida [21].
● Realce de contraste: Es común que las imágenes digitales posean un pobre contraste
debido a un rango de escala de grises reducido. Mediante ajustes en la intensidad de
cada píxel, puede mejorarse notablemente el contraste, a fin de poder diferenciar más
fácilmente distintos objetos de interés [22].
● Remoción o atenuación del ruido: Debido a variaciones en la fuente de energía o a
interferencias, es común que aparezcan componentes ajenos al objeto de interés
dentro de las imágenes médicas. A estos componentes se los conoce como ruido de
fondo. Los píxeles pertenecientes al ruido en una imagen tienen la característica de
tener un nivel de intensidad muy diferente a sus vecinos. Distintos algoritmos de
preprocesamiento, dependiendo el tipo de ruido en cuestión, se encargan de eliminar
la intensidad de dichos píxeles para lograr una imagen de mayor calidad.
2.1.3. Extracción de características
Esta etapa consiste en extraer diferentes propiedades o indicadores de las imágenes, que son
de utilidad para su análisis. Una característica o indicador es un escalar que cuantifica una
determinada propiedad de un punto o sector de la imagen. Dependiendo del problema a
https://sciwheel.com/work/citation?ids=9938763&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9963791&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9963914&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9964074&pre=&suf=&sa=0
17
abordar, se determinan las características que es necesario extraer de la imagen. El espacio de
características puede dividirse en tres categorías generales [19] :
● De intensidad: Caracterizan cada región de interés de la imagen mediante los valores
de niveles de gris de las mismas. Otra aproximación para la obtención de este tipo de
características consiste en medir la diferencia entre el nivel de gris medio de la región
y el nivel de gris medio de los píxeles circundantes.
● Geométricas: Se basan en obtener un indicador de la forma de las regiones de interés
a analizar dentro de la imagen, pudiendo calcularse por ejemplo, a partir del tamaño,
área y borde de las mismas.
● De textura: El análisis de la textura de regiones de interés tiene importantes
aplicaciones en la práctica clínica, como por ejemplo la segmentación y la
diferenciación de lesiones. Las características de textura se pueden obtener mediante
diferentes técnicas, las cuales se diferencian en su manera de medir las interrelaciones
entre los píxeles de la imagen.
2.1.4 Segmentación
La etapa de segmentación consiste en el proceso de extraer una o más regiones de interés de
una imagen. En las imágenes médicas, esta etapa consiste en delinear estructuras anatómicas
o patológicas, las cuales resultan homogéneas respecto a una o más características (como
intensidad, color o textura).
En este proceso, se pueden distinguir dos tareas complementarias: el reconocimiento y la
delineación [23]. Durante el reconocimiento se determina, a grandes rasgos, la ubicación del
objeto de interés dentro de la imagen. La delineación consiste en determinar la extensión
espacial del objeto de forma precisa. Estas dos tareas son cotidianamente llevadas a cabo por
un observador humano especialista, pero no es trivial para los algoritmos computacionales.
Las diferentes técnicas de segmentación de imágenes, se distinguen por el grado de
intervención humana durante el proceso y su automatización. La segmentación manual es
realizada por un profesional médico. A pesar de que, en general, existen diferencias entre las
segmentaciones realizadas por distintos expertos (variabilidad inter-observador), así como
también entre la misma segmentación realizada múltiples veces por el mismo experto
(variabilidad intra-observador), este tipo de segmentación es considerado el más preciso
[24], aunque consume esfuerzo y tiempo. La segmentación automática no requiere de
intervención humana. En este tipo de segmentación, las regiones de interés son determinadas
automáticamente mediante algoritmos que procesan la imagen. Son muy útiles para
segmentar gran cantidad de imágenes, pero frecuentemente presentan desafíos ante la
presencia de múltiples objetos y la ausencia de bordes definidos [25]. Por último, la
https://sciwheel.com/work/citation?ids=9919990&pre=&suf=&sa=0https://sciwheel.com/work/citation?ids=10319526&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=8726267&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10331114&pre=&suf=&sa=0
18
segmentación semiautomática implica una conjunción de las dos anteriores, ya que uno o
varios pasos manuales pueden preceder o proseguir a un paso automatizado. Por ejemplo,
algunas técnicas semiautomáticas pueden requerir el ingreso manual de puntos de referencia
o de inicio que luego serán tomados como entrada para el algoritmo automático. En otros
casos, el resultado de un paso automatizado, puede ser corroborado y editado manualmente
por un experto para obtener un resultado más preciso [19].
2.1.5. Registración
La registración de imágenes consiste en alinear y combinar distintas imágenes de la misma
escena, encontrando puntos de una imagen que puedan ser mapeados a los correspondientes
puntos de la otra imagen.
En el caso de las imágenes médicas, esta etapa del procesamiento es de gran utilidad para
correlacionar información procedente de imágenes, en general capturadas mediante distintas
modalidades (registro multimodal). Las imágenes utilizadas durante la etapa de registración
pueden provenir de un mismo paciente (registro intra-paciente), o de distintos pacientes
(registro inter-paciente).
Para llevar a cabo el registro de imágenes generalmente se utiliza alguno de los siguientes
criterios [26]:
● Marcadores: Consiste en la alineación mediante puntos característicos (denominados
marcadores o landmarks) que describen a un objeto de interés dentro de la imagen, los
cuales pueden ser identificados en cada una de las imágenes que se desean combinar.
Dichos puntos pueden ser indicados manual o automáticamente.
● Segmentación: Consisten en la alineación de forma rígida o deformable de
estructuras previamente segmentadas. El éxito de estos tipos de registros de imágenes
depende del preprocesamiento previo y de la segmentación.
● Intensidad: Compara los patrones de intensidad en las imágenes. A pesar de que
alinear imágenes según este criterio es el más costoso en cuanto a recursos
computacionales, es el método que logra el mayor nivel de precisión.
2.1.6 Visualización
La visualización de imágenes involucra la transformación, presentación e interacción con los
conjuntos de datos asociados a imágenes, especialmente tridimensionales. Mediante la
visualización se facilita la inspección visual de las imágenes médicas, pasando de la simple
inspección de las sucesivas secciones individuales adquiridas originalmente al análisis de la
anatomía tridimensional completa y su exploración desde distintas orientaciones. Estas
https://sciwheel.com/work/citation?ids=9919990&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10319536&pre=&suf=&sa=0
19
capacidades proporcionan herramientas poderosas de aplicación al diagnóstico y tratamiento,
como así también a la investigación clínica [5].
Se han propuesto diferentes métodos de visualización computacional para el desarrollo de
aplicaciones. Por una parte, mediante técnicas de reconstrucción multiplanar, es posible
generar vistas de los cortes ortogonales principales (sagital, coronal y axial, que es
comúnmente el considerado en la captura) o por la generación de planos oblicuos arbitrarios
[3]. Por otro lado, la visualización de imágenes volumétricas se puede llevar a cabo mediante
dos técnicas diferentes de rendering sobre la pantalla plana:
● Volume rendering: es una técnica poderosa y versátil, en la cual la visualización
resulta directamente de la composición de las contribuciones de los puntos que
componen la imagen, proyectados al plano de corte, llevada a cabo mediante
algoritmos de ray-casting.
● Surface rendering: que requiere una segmentación y clasificación previa del volumen
de la imagen a fin de determinar un modelo explícito para las superficies
correspondientes a las estructuras de interés. También es posible generar estos
modelos de iso-superficies directamente desde el volumen de la imagen mediante
algoritmos conocidos como marching cube.
2.2 Análisis y Elección de Tecnologías
2.2.1 Tecnologías de Visualización
Para el diseño del visualizador WEB que se detalla en la sección 3.1 se consideró que el
mismo tiene que poder ser ejecutado en un web browser permitiendo que el usuario interactúe
con las imágenes tanto 2D como 3D. Para ello, se realizó un relevamiento de algunas
herramientas de visualización existentes, que podrían servir como punto de partida del
visualizador a desarrollar. Entre los aspectos considerados para el relevamiento se tuvo en
cuenta que un usuario de este tipo de herramientas requiere:
● Rotar/Mover las imágenes y volúmenes 3D.
● Definir puntos o áreas de interés sobre las imágenes 2D y/o 3D.
● Ver el estado previo y posterior al procesamiento de una imagen.
https://sciwheel.com/work/citation?ids=9278796&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10721433&pre=&suf=&sa=0
20
webDICOM
En primera instancia se consideró la herramienta webDICOM [27]. Esta herramienta permite,
mediante Javascript y HTML5, visualizar y manipular imágenes DICOM. Entre sus
funcionalidades podemos encontrar: zoom, desplazamiento, medición de longitudes y control
de brillo y contraste. A continuación se presenta una captura de pantalla de la UI (Figura
2-2):
Figura 2-2. Interfaz gráfica de la herramienta webDICOM.
Es importante destacar que las imágenes sólo pueden ser cargadas manualmente desde una
carpeta local.
med3web
Luego se evaluó la herramienta med3web [28]. Ésta permite cargar imágenes desde archivo o
url. Provee funcionalidades para medición de longitudes, ángulos y áreas. También permite
zoom, anotaciones de texto y manipulación de brillo y contraste de las imágenes, como se
puede observar en la Figura 2-3:
https://sciwheel.com/work/citation?ids=9899106&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899092&pre=&suf=&sa=0
21
Figura 2-3. Interfaz gráfica de la herramienta med3web.
Posee también un visualizador 3D simple de las imágenes, con controles para modificar el
brillo y contraste, rotar y hacer zoom, como se puede observar en la Figura 2-4.
Figura 2-4. Visualizador 3D de la herramienta med3web.
La carga de archivos desde una url se debe realizar mediante un archivo de texto que
contenga una lista de imágenes a cargar.
Papaya
Seguidamente, se consideró la herramienta Papaya [29], cuyo entorno se muestra en la Figura
2-5. Esta herramienta está basada en HTML5 y Javascript, soporta los formatos DICOM y
NIFTI y permite cargar una imagen o una carpeta con imágenes desde un sistema de archivos
https://sciwheel.com/work/citation?ids=9899198&pre=&suf=&sa=0
22
local o una URL remota. Posee un visualizador ortogonal para mostrar las vistas axial,
coronal, y sagital de una imagen, como así también funcionalidades de zoom, ajuste de brillo
y contraste, desplazamiento y medición de longitudes.
Figura 2-5. Interfaz gráfica de la herramienta Papaya.
OHIFViewers
Finalmente, se evaluó la herramienta OHIFViewers [30]. Esta herramienta es un framework
de código abierto, desarrollado y mantenido por la Open Health Image Foundation [31], para
construir aplicaciones de imágenes médicas basadas en la web. El framework mencionado
anteriormente, utiliza las tecnologías HTML5, CSS y Javascript, en conjunto con la librería
Cornerstone [32], para visualizar y manipular imágenes médicas. Está construido con
MeteorJS [33], una plataforma Javascript full-stack basada en Node.js, que provee un sistema
de extensibilidad de las aplicaciones mediante packages que pueden ser desarrollados
específicamente para la aplicación, o pueden ser descargados desde el repositorio principal de
paquetes AtmosphereJs [34], u otros repositorios provistos por la comunidad. OHIFViewers
presenta 3 aplicaciones de visualización a modo de ejemplo:
● OHIF Viewer: Un visor DICOM de propósito general que puede ser ampliado
fácilmente para usos específicos. Entre sus funcionalidades principales, se puede
mencionar que permite visualizaruna lista de los estudios existentes y filtrar los
mismos en base a diferentes criterios (nombre del paciente, fecha del estudio,
modalidad, descripción del estudio, etc.). Además posee herramientas para realizar
anotaciones, diversas mediciones, cálculos de áreas, zoom, definir regiones de interés
https://sciwheel.com/work/citation?ids=9899098&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899102&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899095&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899104&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899103&pre=&suf=&sa=0
23
(ROI, por Region Of Interest), ajustar brillo y contraste, proyección en modo CINE de
las imágenes, rotación y espejado H/V.
● Lesion Tracker: Una aplicación de imagen enfocada en oncología, que está diseñada
para facilitar evaluaciones cuantitativas de la carga tumoral a lo largo del tiempo.
● Standalone Viewer: Un visor independiente, que solo ofrece las funcionalidades del
lado del cliente de OHIF viewer, con las páginas de la lista de estudios eliminadas.
Permite incluir cargadores de imagen adicionales para objetos que no sean DICOM
(por ejemplo, PNG, JPEG).
El visualizador OHIF Viewer puede ser extendido fácilmente e incluye una amplia variedad
de herramientas y funcionalidades para interactuar con las imágenes, y tanto su código como
la plataforma sobre la que está desarrollado son abiertos y libres.
En la Figura 2-6 se presenta una vista general de su interfaz gráfica donde puede verse la
barra de herramientas con algunos de los controles descritos anteriormente:
Figura 2-6. Interfaz gráfica de la herramienta OHIFViewer.
Meteor soporta distintos frameworks para la construcción de las interfaces gráficas, entre
ellos VueJS [35], ReactJs [36] y BlazeJS [37]; siendo este último el utilizado por OHIF como
motor de templates.
https://sciwheel.com/work/citation?ids=10867280&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10867281&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10867285&pre=&suf=&sa=0
24
Tabla 2-1. Tabla comparativa de características y funcionalidades de las herramientas
evaluadas.
Herramientas
Características y
funcionalidades
webDICOM med3web Papaya OHIFViewe
r
HTML5/CSS/JS ✓ ✓ ✓ ✓
Mediciones ✓ ✓ ✓ ✓
Zoom ✓ ✓ ✓ ✓
Brillo y contraste ✓ ✓ ✓ ✓
Desplazamiento ✓ ✗ ✓ ✓
ROI ✗ ✗ ✗ ✓
Rotación ✗ ✗ ✗ ✓
Espejado H/V ✗ ✗ ✗ ✓
Anotaciones de texto ✗ ✓ ✗ ✓
Visualización 3D ✗ ✓ ✗ ✗
Servidores DICOM ✗ ✗ ✗ ✓
Extensible ✓ ✓ ✓ ✓
Open source ✓ ✓ ✓ ✓
Soporte para segmentación ✗ ✗ ✗ ✗
25
En la Tabla 2-1 se resumen las características y funcionalidades de las herramientas relevadas
que se fueron mencionando anteriormente. Como se puede ver todas ellas se basan en
HTML5, CSS y Javascript, además de ser open source y permitir la extensibilidad. En
relación a las prestaciones y características de cada una, se puede observar que la mayoría de
las herramientas brindan las posibilidades de realizar mediciones, zoom, control de
brillo/contraste y desplazamiento de las imágenes. Las principales diferencias se hallan en
otras funcionalidades como ROI, rotación, espejado y visualización 3D.
Debido a que la herramienta webDICOM solo permite cargar imágenes desde un sistema de
archivos local y también a sus reducidas funcionalidades, esta herramienta fue descartada. En
el caso de med3web, como se mencionó anteriormente la misma no permite una carga de
imágenes dinámicamente de una forma sencilla, y posee un conjunto de funcionalidades
reducido. Es por ello que se decidió descartarla. Al igual que las dos herramientas anteriores,
Papaya presenta funcionalidades muy básicas además de no permitir conexión directa con un
repositorio DICOM, lo que también llevó a descartarla. Como conclusión, se puede
mencionar que se seleccionó la herramienta OHIFViewer como la más adecuada para ser
utilizada como punto de partida en el desarrollo del visualizador, ya que la misma posee la
mayoría de las funcionalidades y características esperadas y es la única que soporta
integración directa con servidores DICOM.
2.2.2 Tecnologías de almacenamiento
Dado que la herramienta de visualización elegida soporta integración con servidores DICOM
mediante DICOMWeb (RESTful DICOM) y DIMSE , para la elección y diseño del servidor
se realizó una evaluación de las soluciones existentes que permiten comunicación mediante
dichos protocolos.
DICOMcloud
En primera instancia, se consideró el servidor DICOMcloud [38]. Es un servidor DICOMweb
de código abierto escrito en C# .NET que puede ser ejecutado en sistemas operativos
Windows o en el cloud Azure [39]. Provee una implementación RESTful de los servicios
DICOMweb/WADO en DICOM parte 13. El servidor proporciona una implementación de los
siguientes servicios:
● QIDO-RS: Consulta basada en ID para objetos DICOM por servicios RESTful.
● WADO-RS: Acceso web a objetos DICOM por servicios RESTful.
● STOW-RS: Almacenado (STore) a través de la web por servicios RESTful.
https://sciwheel.com/work/citation?ids=9899099&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899100&pre=&suf=&sa=0
26
● DICOM WADO-URI: Acceso web a objetos DICOM por URI.
Además, el servidor implementa los siguiente servicios RESTful que no forman parte del
estándar DICOM:
● DELOW-RS: Borrado (DELete) a través de la web por servicios RESTful.
● DICOM OHIF-Viewer: Servicio de integración con el visualizador OHIF, para
devolver la información de los estudios (series e instancias), formateada según los
requisitos del mismo.
Orthanc
Orthanc [40] es un servidor DICOM ligero y open source para imágenes médicas. Tiene una
arquitectura liviana e independiente, por lo tanto no se requiere una administración compleja
de la base de datos, ni la instalación de dependencias de terceros. Está escrito en C++, lo cual
le brinda portabilidad con diferentes sistemas operativos. Proporciona una API RESTful, lo
que posibilita interactuar con el servidor desde cualquier lenguaje de computadora. También
presenta un mecanismo de plugins o complementos para agregar nuevos módulos que
amplían las capacidades principales de su API. Una implementación parcial del estándar
DICOMweb está actualmente disponible en forma gratuita como complemento. Algo
importante a mencionar es que Orthanc es el servidor de imágenes sugerido por los
desarrolladores de OHIF Viewer, lo que facilita la integración de ambos sistemas.
https://sciwheel.com/work/citation?ids=9899091&pre=&suf=&sa=0
27
Tabla 2-2. Tabla comparativa de características y funcionalidades de los servidores DICOM
evaluados.
Servidores
Características y
funcionalidades
DICOMcloud Orthanc
Open Source ✓ ✓
Multiplataforma ✗ ✓
DICOMweb/WADO ✓ ✓
Compilación y deployment ● Visual Studio 2017/2015
● Azure Cloud
● Visual Studio 2017/2015
● Cmake
● otros compiladores C++
● Disponibilidad de
binarios en repositorios
de algunas distribuciones
linux
● Docker
Dado que DICOMcloud presenta ciertas limitaciones en lo que respecta a las plataformas
donde puede ser ejecutado, finalmente se decidió optar por Orthanc como servidor de
imágenes.
2.2.3 Tecnologías de procesamiento
Para el diseño del segmentador, se comenzó realizando un relevamiento de las tecnologías
existentes para el procesamiento de imágenes, dado que se deseaban utilizar en la
implementación del mismo.
VTK
El Visualization Toolkit (VTK) [41] es un software de código libre orientado a objetos para
computación gráfica, visualización y procesamiento de imágenes. Posee algoritmos de
filtrado para suavizado de imágenes, obtención de contornos, conversión de tipos de imagen,
además de algunos widgets para segmentación. Admite una amplia variedad de algoritmos de
visualización y técnicas de modelado avanzadas, y aprovecha el procesamiento paralelo de
https://sciwheel.com/work/citation?ids=9899329&pre=&suf=&sa=0
28
memoria compartida y distribuida para velocidad y escalabilidad, respectivamente. VTK está
diseñado para ser independiente de la plataforma. Esto significa que puede serejecutado en la
mayoría de los sistemas operativos, en la web, e incluso en dispositivos móviles. Cabe
mencionar que este software tiene su principal foco en aspectos de visualización más que en
aspectos de manipulación y procesamiento de imágenes.
ITK
Insight Toolkit (ITK) [42] es una librería multiplataforma de código abierto que brinda a los
desarrolladores una amplia variedad de herramientas de software que permiten el análisis de
imágenes. El mismo está basado en una arquitectura probada para el procesamiento, la
segmentación y el registro de imágenes científicas en dos, tres o más dimensiones. Esta
librería es utilizada en miles de aplicaciones comerciales y de investigación, desde
laboratorios importantes hasta investigadores independientes.
SimpleITK
SimpleITK [43] es una interfaz de programación simplificada para los algoritmos y las
estructuras de datos de ITK. Admite bindings para múltiples lenguajes de programación,
incluidos C++, Python, R, Java, C#, Lua, Ruby y TCL. Estos bindings permiten a los
científicos desarrollar flujos de trabajo de análisis y procesamiento de imágenes en el
lenguaje de programación con el que están más familiarizados. El kit de herramientas admite
más de 15 formatos de archivo de imagen diferentes y proporciona más de 280 filtros de
análisis y procesamiento de imágenes.
Dado que las tecnologías evaluadas anteriormente no componen una herramienta o aplicación
en sí mismas, debido a que son librerías diseñadas para ser utilizadas en el desarrollo de
software, la elección final de la tecnología de procesamiento a utilizar será explicada en la
sección 3.2.2, ya que esta elección es parte de las decisiones de diseño correspondientes.
2.2.4 Tecnologías de comunicación
Como se mencionó en la sección 2.2.2, el servidor DICOM y el visualizador seleccionados
soportan integración entre sí mediante DICOMWeb. Es por esta razón que se decidió
implementar la comunicación entre el visualizador y el segmentador de imágenes mediante el
protocolo REST, y de esta manera unificar la comunicación entre los 3 módulos bajo un
mismo protocolo.
Los servicios REST, a diferencia de los servicios web tradicionales, presentan una interfaz
basada en el protocolo estándar HTTP, lo cual le otorga una interfaz sencilla con un conjunto
pequeño y conocido de operaciones estándar tales como POST, DELETE, PUT y GET los
cuales tienen una asociación intuitiva a las operaciones alta, baja, modificación y consulta
respectivamente. A través de estos métodos se puede crear (POST), eliminar (DELETE),
modificar (PUT) y listar (GET) un recurso. Un recurso es un elemento de información que se
https://sciwheel.com/work/citation?ids=9899335&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=9899347&pre=&suf=&sa=0
29
puede considerar como una entidad que representa un concepto de negocio que puede ser
accedido públicamente y es identificado por medio de un identificador uniforme de recursos
(URI, por Uniform Resource Identifier). Estos pueden tener múltiples formatos de
representación tales como HTML, XML, JSON, etc. Este estilo se centra en publicar recursos
en vez de un conjunto de métodos y operaciones. Los servicios REST no deben conservar el
estado del recurso, es decir, ningún estado (por ejemplo, de la sesión) se almacena en el
servidor, toda la información que se requiere para mostrar el recurso que se solicita debe estar
en la consulta por parte del cliente.
30
3 Diseño e Implementación
Uno de los principales aspectos considerados para el diseño de la herramienta fue que la
misma sea extensible, permitiendo incorporar módulos de segmentación de otros estudios de
imágenes, como así también extender las posibilidades de visualización e interacción del
usuario con la misma. Es por ello que los módulos principales que la componen, y que
detallaremos en este capítulo, fueron construidos bajo el concepto de software de código
abierto.
La herramienta desarrollada, como se puede ver en la Figura 3-1, se compone de 3 módulos
principales:
● Un visualizador WEB que permite mostrar los estudios médicos disponibles, como
así también visualizar y manipular las imágenes.
● Un Servidor de imágenes DICOM que permite almacenar los estudios, series,
imágenes, frames y metadatos.
● Un Servicio de segmentación de imágenes, que posibilita crear y almacenar distintos
pipelines de procesamiento, como así también ejecutarlos sobre un conjunto de
imágenes, con el fin de obtener las segmentaciones correspondientes.
31
Figura 3-1. Módulos de la aplicación y flujo de interacción entre ellos.
En lo que respecta al diseño del servidor DICOM, no se realizaron cambios significativos
sobre la implementación del mismo. Solo se hizo una prueba de concepto (PoC, por sus siglas
en inglés) del desarrollo de un plugin para resolver la segmentación de las imágenes, que
luego se decidió descartar debido a que no se pudieron satisfacer los requerimientos
esperados de la segmentación. Esta decisión será explicada en más detalle en la sección 3.2.2
correspondiente al diseño del segmentador de imágenes.
A continuación, se detallan todos los aspectos que fueron considerados para la
implementación de la herramienta, como así también el uso de distintas librerías externas.
3.1 Diseño del visualizador WEB
Para el diseño del visualizador se comenzó realizando una inspección de código con el fin de
comprender cómo estaba conformado el layout gráfico de la herramienta OHIFViewer, que
fue la herramienta elegida; específicamente el área de visualización de imágenes. Este
análisis permitió comprender que el mismo se compone de una grilla o cuadrícula,
configurable por el usuario en la cantidad de filas y columnas, que contiene en cada una de
sus celdas un viewport que permite visualizar una serie DICOM en 2D, junto con su
información y las anotaciones correspondientes. En la Figura 3-2 se muestra una vista de
dicho layout:
https://app.lucidchart.com/documents/edit/f02dda8a-1687-421a-badf-ed1d43c44fba/0?callback=close&name=docs&callback_type=back&v=1009&s=505
32
Figura 3-2. Descripción del layout original del visualizador OHIF.
Tanto la grilla como los viewports están modelados como templates de BlazeJS. Siguiendo
este modelado, se decidió crear un nuevo template (viewer3D.html) basado en el template de
viewport para la visualización de las imágenes en 3D, como se puede observar en el bloque
de código Bloque 3-1:
33
Bloque 3-1. Template del motor BlazeJS para visualización de imágenes 3D.
<template name="viewer3D">
<div id="imageViewerViewport3D" class='imageViewerViewport3D'
oncontextmenu='return false;'
unselectable='on'
onselectstart='return false;'
tabindex='0'
style="width: 100%; height: 100%; text-align: center">
<style>
.dg .c {
color: black;
}
#my-gui-container {
position: fixed;
top: 10px;
right: 10px;
z-index: 1;
}
</style>
<div class="dg ac" style="position: absolute; top: 0px" ></div>
<div id="my-gui-container"></div>
<canvas id="wglcanvas" style="width: 100%; height: 100%"></canvas>
</div>
</template>
El template creado implementa su lógica de negocio mediante un script de Javascript
(viewer3D.js). El mismo implementa la visualización 3D mediante la librería AMI (A
Medical Imaging toolkit) [44], la cual permite visualizar un stack de imágenes DICOM y
volúmenes 3D mediante una etiqueta canvas de HTML5 y que está construida sobre ThreeJS
[45], una poderosa librería Javascript de propósito general para visualización 3D. Junto con la
visualización, se proveen también controles para manipular la orientación de los planos del
stack (axial, coronal, sagital), los niveles de brillo y contraste, y la navegación del stack de
imágenes, permitiéndose además la variación de la opacidad del volumen visualizado y su
color (Fig 3-3).
https://sciwheel.com/work/citation?ids=10867383&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=10891465&pre=&suf=&sa=0
34
Figura 3-3. Herramientas para la manipulación de las vistas 3D.
Como se mencionó en la sección 2.2.1, las aplicaciones basadas enMeteorJS pueden ser
extendidas mediante packages. Aprovechando esta característica, se desarrolló un package
para poder mostrar los pipelines de segmentación existentes y seleccionar alguno de ellos
para generar una segmentación sobre la serie que se está visualizando actualmente en
pantalla. El componente se implementó mediante una lista desplegable que muestra los
pipelines por nombre, y también permite buscar los mismos mediante entrada de texto por
teclado (Fig 3-4).
Figura 3-4. Vista del selector de pipelines.
Finalmente, se incluyeron 2 botones junto a la lista desplegable (Fig 3-4). El primero de ellos,
denominado “Select mode”, activa el modo que permite seleccionar una segmentación 3D
para ajustar sus propiedades de color y opacidad mediante el conjunto de herramientas que se
visualiza en la Figura 3-3. En el caso del segundo, denominado “View 3D”, realiza la llamada
35
al servicio de segmentación para segmentar la serie 2D que se está visualizando, pasando por
parámetros los identificadores del estudio (studyId), la serie (serieId) y el pipeline
seleccionado en la lista desplegable (pipelineId). En la Figura 3-5 se presenta un diagrama de
secuencia que modela esta funcionalidad:
Figura 3-5. Diagrama de secuencia de una segmentación desde el visualizador.
3.2 Diseño del segmentador de imágenes
En lo que respecta al servicio de segmentación de imágenes, se desarrolló una
implementación propia, en vez de utilizar alguna existente, ya que se desea que el mismo
pueda ser reutilizado en otras aplicaciones. Esto implica que el funcionamiento y la interfaz
de comunicación del segmentador deben ser independientes del resto de los módulos que
conforman la arquitectura de la aplicación desarrollada. Otro requisito a considerar es que la
implementación debe basarse en las tecnologías de procesamiento evaluadas en la sección
2.2.3.
Para llevar a cabo el desarrollo del segmentador, se evaluaron distintas alternativas de
implementación:
3.2.1 Plugin de Orthanc
Se comenzó realizando una PoC con el propósito de verificar si la segmentación podía ser
realizada mediante un plugin que extendiera las funcionalidades del servidor Orthanc,
aprovechando que tanto el servidor como la librería ITK comparten el mismo lenguaje (C++).
La segmentación requiere del acceso a las imágenes, por lo que realizarlo directamente en el
repositorio es la forma más eficiente de acceder a las mismas, ya que se elimina el overhead
de transmitir las imágenes por red hacia otro módulo. El plugin desarrollado extiende la API
Rest del servidor añadiendo un nuevo endpoint que recibe los Ids del estudio y la serie que se
desea segmentar, como se observa en bloque siguiente:
36
Bloque 3-2. Definición del endpoint rest en el plugin.
ORTHANC_PLUGINS_API int32_t OrthancPluginInitialize(OrthancPluginContext *context) {
context_ = context;
OrthancPlugins::RegisterRestCallback<GetVtk>(context,
"/vtk/studies/([^/]*)/series/([^/]*)", true);
LogInfo("URI to VTK API: /vtk/");
return 0;
}
Luego de recibir un request, el plugin delega las tareas de procesamiento y segmentación a la
librería ITK. La primera dificultad encontrada con este enfoque fue que todas las etapas
(filtros) de los pipelines de procesamiento debían ser definidas a priori, ya que C++ es un
lenguaje fuertemente tipado y todos los tipos de datos utilizados se deben definir en tiempo
de compilación.
Dado que ITK no provee métodos para instanciar los filtros en tiempo de ejecución, se
decidió desarrollar una librería propia que implemente factory methods [46] para crear los
filtros de ITK en tiempo de ejecución. Con esta implementación, se logró resolver el
problema a la hora de instanciar las diferentes etapas del pipeline, pero la misma no logró
resolver totalmente el problema descrito anteriormente, ya que es necesario conocer de
antemano la representación de los pixeles de las imágenes para instanciar los filtros, como se
muestra en el bloque de código 3-3:
Bloque 3-3. Ejemplo de carga de una imagen con ITK.
constexpr unsigned int Dimension = 2;
using PixelType = unsigned char;
using ImageType = itk::Image<PixelType, Dimension>;
using ReaderType = itk::ImageFileReader<ImageType>;
ReaderType::Pointer reader = ReaderType::New();
reader->SetFileName(argv[1]);
reader->Update();
ImageType::Pointer image = reader->GetOutput();
Por último, esta implementación no satisface el requisito de independencia de otras
aplicaciones planteado al inicio de esta sección, ya que al ser un plugin del servidor DICOM
https://sciwheel.com/work/citation?ids=9899097&pre=&suf=&sa=0
37
no se podría reemplazar el segmentador sin un impacto directo en el servidor de imágenes y
viceversa. Estos inconvenientes determinaron que la PoC no sea satisfactoria y se decidió
descartar este enfoque.
3.2.2 SimpleITK + Spring Boot
Dado que el enfoque anterior no permitió obtener los resultados esperados, se decidió realizar
una nueva PoC, en este caso utilizando la librería SimpleITK e integrando la misma en una
aplicación web desarrollada con Spring Boot. Esta PoC tuvo resultados satisfactorios en lo
que respecta a los requerimientos del segmentador y fue la alternativa elegida finalmente para
su desarrollo.
Spring Boot facilita la creación de aplicaciones basadas en el framework Spring [47],
reduciendo considerablemente la configuración necesaria para su desarrollo. Mediante esta
tecnología, se desarrolló una aplicación web orientada a servicios (SOA) que permite la
creación de pipelines de procesamiento dinámicamente, es decir en tiempo de ejecución, sin
necesidad de que los mismos sean compilados previamente. A continuación, se detallan los
aspectos relevantes del diseño de esta aplicación.
Un pipeline lineal en ITK/SimpleITK se compone de objetos de datos (data objects) y objetos
de procesamiento (process objects). Mientras que los data objects (por ejemplo, imágenes y
mallas) son utilizados para representar datos, los process objects (por ejemplo, fuentes, filtros
y mapeadores) son clases que operan sobre los data objects y pueden producir nuevos data
objects. Las fuentes (sources) pueden generar imágenes sin necesidad de una entrada de
datos, es decir especificando las dimensiones y los píxeles, o por el contrario, a partir de una
entrada de datos (readers). Los filtros (filters) toman datos de entrada y los procesan para
producir nuevos datos y los mapeadores (mappers) reciben datos para enviarlos a un archivo
o algún otro sistema. En general, el término filtro se usa ampliamente para referirse a los tres
tipos. A continuación se presenta una vista, a modo de ejemplo, de un flujo de procesamiento:
Figura 3-6. Ejemplo de un pipeline de procesamiento ITK/SimpleITK.
https://sciwheel.com/work/citation?ids=9899094&pre=&suf=&sa=0
38
De una forma más general, e ignorando las imágenes intermedias, un pipeline puede ser visto
como un conjunto de sources, filters y mappers que interactúan secuencialmente:
Figura 3-7. Ejemplo de un pipeline de procesamiento ITK/SimpleITK simplificado.
En la aplicación desarrollada, los pipelines y los filtros son modelados como recursos REST
y son definidos mediante una notación JSON (Javascript Object Notation). Además son
persistidos en una base de datos Postgresql para su posterior utilización. El modelo de
persistencia, se compone de 3 atributos: id, name y json que representan el id autogenerado
para ese pipeline, el nombre definido por el usuario y la lista de filtros asociados,
respectivamente. Dicha lista de filtros se mantiene en formato json (texto plano) y se persiste
de la misma manera por comodidad. En la Figura 3-8 se puede apreciar la representación de
este modelo:
Figura 3-8. Modelo de la entidad que representa a la tabla Pipeline.
La aplicación provee servicios para la creación (POST), actualización (PUT), borrado
(DELETE) y consulta (GET) de pipelines. Por otro lado, también provee servicios para la
consulta (GET) de los filtros disponibles para la definición de los pipelines, y por último,
provee un servicio para lageneración y obtención de las segmentaciones en forma
volumétrica (3D).
Los recursos filter poseen la siguiente representación:
39
Bloque 3-4. Modelo JSON de un Filtro.
{
"filterClass": "string",
"links": {
"empty": true
},
"methods": [
{
"name": "string",
"parameters": [
{
"casting": "string",
"multidimensional": "string",
"name": "string",
"value": "string"
}
]
}
],
"uuid": "string"
}
Internamente, los filtros son modelados como clases cuyas relaciones pueden visualizarse en
el siguiente diagrama de clases de la Figura 3-9:
Figura 3-9. Diagrama de clases de un filtro.
Como se puede observar, un filtro (Filter) posee un identificador único (uuid) que es utilizado
para resolver la ambigüedad cuando existe más de un filtro con la misma clase en un pipeline,
una clase (filterClass) que lo representa en SimpleITK y una lista de métodos (methods)
asociados. De igual manera, un método (Method) posee un nombre (name) y una lista de
parámetros (parameters). Por último, un parámetro (Parameter) se compone de un nombre
que lo describe (name), un valor asociado (value), una clase de casting (casting) que es
https://app.lucidchart.com/documents/edit/4b2ac1bf-10c1-4071-a5f7-dcfb9c206e84/0?callback=close&name=docs&callback_type=back&v=805&s=594
40
utilizada para resolver los tipos de datos entre los wrappers y los datos primitivos en java, y
una clase opcional para el caso de parámetros multidimensionales (multidimensional), es
decir arreglos. El modelo de filtros es utilizado tanto para describir los filtros disponibles al
momento de construir un pipeline, como así también para instanciar los mismos al momento
de segmentar una imagen. Al describir los filtros disponibles, cada filtro contiene la lista
completa de métodos que dicho filtro posee con los valores de sus parámetros en estado nulo.
A modo de ejemplo, en el bloque 3-5 se presenta la descripción del filtro
RescaleIntensityImageFilter con algunos de sus métodos:
41
Bloque 3-5. Ejemplo de filtro (RescaleIntensityImageFilter) sin instanciar en un pipeline.
{
"uuid": "29e79c60-c641-4544-8047-bebd95da836a",
"filterClass": "org.itk.simple.RescaleIntensityImageFilter",
"methods": [
{
"name": "getName",
"parameters": []
},
{
"name": "getOutputMinimum",
"parameters": []
},
{
"name": "setOutputMaximum",
"parameters": [
{
"name": "arg0",
"casting": "java.lang.Double",
"value": null,
"hasValues": false,
"values": null
}
]
},
{
"name": "getOutputMaximum",
"parameters": []
},
{
"name": "setOutputMinimum",
"parameters": [
{
"name": "arg0",
"casting": "java.lang.Double",
"value": null,
"hasValues": false,
"values": null
}
]
}
]
}
Por el contrario, cuando un filtro es instanciado en un pipeline, solo contiene los métodos de
interés para dicha instanciación junto con los valores de sus parámetros, como se puede
observar en el bloque 3-6:
42
Bloque 3-6. Ejemplo de filtro (RescaleIntensityImageFilter) instanciado en un pipeline.
{
"id": 180,
"name": "lungs",
"filters": [
{
"uuid": "11b2d3c0-01b1-4f65-8375-8d8a6b35fdde",
"filterClass": "org.itk.simple.RescaleIntensityImageFilter",
"methods": [
{
"name": "setOutputMinimum",
"parameters": [
{
"name": "arg0",
"casting": "java.lang.Double",
"value": "0",
"hasValues": false,
"values": null
}
]
},
{
"name": "setOutputMaximum",
"parameters": [
{
"name": "arg0",
"casting": "java.lang.Double",
"value": "255",
"hasValues": false,
"values": null
}
]
}
]
}
]
}
Para la consulta de los filtros, la aplicación expone 2 endpoints que, respectivamente,
permiten consultar todos los filtros disponibles y también un filtro específico basándose en su
nombre de clase, ya sea en forma simple (BinaryThresholdImageFilter) o canónica
(org.itk.simple.BinaryThresholdImageFilter), como se puede observar en la Figura 3-10:
43
Figura 3-10. Endpoints para la consulta de filtros.
Como se mencionó anteriormente, la aplicación también provee endpoints para realizar
operaciones CRUD (Create, Read, Update, Delete) sobre los pipelines. En la Figura 3-11 se
presenta una vista de dichos endpoints:
Figura 3-11. Endpoints para las operaciones CRUD sobre los pipelines.
Para finalizar, cabe mencionar que en la etapa de diseño también se consideraron aspectos
referidos al despliegue (deployment) y ejecución de los módulos que componen la
herramienta. Para facilitar estas tareas se decidió proveer contenedores, mediante Docker
[48], que permitan desplegar y ejecutar dichos módulos independientemente de la
arquitectura o sistema operativo del servidor en donde sean ejecutados. De esta manera se
consiguió eliminar la dependencia de un sistema operativo específico o la necesidad de
instalar componentes adicionales para su ejecución. En el Anexo A, se presenta una guía de
uso de la herramienta y detalles del despliegue.
https://sciwheel.com/work/citation?ids=11312955&pre=&suf=&sa=0
44
4 Resultados
En este capítulo se exponen los resultados obtenidos de diferentes pruebas de segmentación
con el propósito de medir el rendimiento o performance del diseño presentado anteriormente.
Los mismos fueron realizados sobre diferentes perfiles de hardware y repetidos varias veces
para poder obtener indicadores promedio de dicho rendimiento.
A continuación se detallan los diferentes perfiles de hardware utilizados:
● Perfil 1:
○ Dispositivo: Notebook MSI
○ SO: Ubuntu 18.04.5 LTS, kernel 4.15.0-135-generic x86_64
○ CPU: Intel Core i3-3110M (4 cores) 2400Mhz
○ RAM: 12 GB
○ Browser: Google Chrome 88.0.4324.150 (64 bits)
○ Java: Oracle Java Runtime Environment (JRE) 11.0.10
● Perfil 2:
○ Dispositivo: Notebook Dell Latitude 7490
○ SO: Ubuntu 18.04.1, kernel 5.4.0-65-generic x86_64
○ CPU: Intel Core I7-8650U (8 cores) 1900Mhz
○ RAM: 16 GB
○ Browser: Google Chrome 88.0.4324.150 (64 bits)
○ Java: Open Java Runtime Environment (JRE) 11.0.10
Para las pruebas se realizaron 2 segmentaciones diferentes. La primera, denominada
segmentación 1, corresponde a un ventrículo cerebral izquierdo y fue generada a partir de una
MRI Orbital compuesta por 176 cortes (o slices) de 256x256 píxeles, obtenida de un paciente
masculino de 24 años. La segunda segmentación, denominada segmentación 2, se
corresponde con los pulmones y arterias pulmonares y fue generada a partir de una CT con
contraste (agente: Omnipaque 350) compuesta por 273 slices de 512x512 píxeles, obtenida de
un paciente anónimo.
45
Al momento del arranque de la aplicación con el perfil 1, la memoria utilizada por la JVM es
aproximadamente de 210 MB y el promedio de uso del CPU es del 14% (Fig 4-1).
Figura 4-1. Utilización de memoria y CPU del perfil 1 al momento del arranque del
segmentador.
Para generar la segmentación 1, se utilizó un pipeline compuesto por 4 filtros o algoritmos
ITK, cada uno con los parámetros que se indican debajo:
● Filtro para reducción de ruido (CurvatureFlowImageFilter):
○ Timestep: 0,125
○ Iterations: 5
● Segmentación mediante crecimiento de regiones utilizando de puntos similares
conectados (ConfidenceConnectedImageFilter):
○ Iterations: 2
○ Radius: 1
○ Multiplier: 3
○ Seed: [44.921875%, 30.46875%, 48.8636363636364%] equivalente al punto
[115, 78, 86]
● Operación morfológica de cierre (BinaryMorphologicalClosingImageFilter):
○ Kernel: Ball
○ Radius: 1
● Extracción de la región de interés (RegionOfInterestImageFilter):
○ Index: [0%, 0%, 47.159090909%] equivalente al punto [0, 0, 82]
46
○ Size: [100%, 100%, 52.840909091%] equivalente al punto [256, 256, 93]
Durante de las pruebas realizadas en el perfil 1 con dicha segmentación, se pudieron obtener
los resultados promedios de tiempos de segmentación, tiempos de visualización (desde que se
invocó al servicio de segmentación hasta que se finalizó con el renderizado), uso de memoria
y de CPU, que se muestran en la Tabla 4-1:
Tabla 4-1. Tabla de resultados del perfil 1 para la segmentación del ventrículo cerebral
izquierdo.
Iteración Tiempo de
Visualizació
n (ms)
Tiempo de
Segmentació
n (ms)
Memoria
(MB)Uso de
CPU
(%)
Tamaño de
archivo
generado
1 15036 ms 10390 ms 260 MB 58 %
92,1 KB
2 14996 ms 10410 ms 264 MB 47 %
3 14606 ms 10670 ms 346 MB 51 %
4 10463 ms 10290 ms 329 MB 48 %
5 14780 ms 10531 ms 334 MB 50 %
Totales 69880 ms 52291 ms 1533 MB 254 %
Promedio
s
13976 ms 10458,2 ms 306,6 MB 50,8 %
A modo de ejemplo, se adjuntan algunas capturas de pantalla de la segmentación realizada.
En la Figura 4-2, se puede observar la vista de la segmentación del ventrículo cerebral
izquierdo, desde diferentes ángulos:
47
Figura 4-2. Capturas de pantalla de la segmentación del ventrículo cerebral izquierdo vistas
en diferentes ángulos. Vista frontal (izq.) y vista anterior derecha (der.).
Mientras que en la Figura 4-3 se puede observar la misma segmentación, pero en este caso
junto con su vista 2D correspondiente a un corte de la MRI:
Figura 4-3. Vista 2D de un corte de la MRI (izq) y vista 3D (der) de la segmentación.
Al momento del arranque con el perfil 2, la memoria utilizada por la JVM es
aproximadamente de 150 MB y el promedio de uso del CPU es del 2% como se observa a
continuación en la Figura 4-4:
48
Figura 4-4. Utilización de memoria y CPU del perfil 2 al momento del arranque del
segmentador.
En las pruebas realizadas con el perfil 2, se pudieron obtener los siguientes resultados, que se
detallan en la Tabla 4-2:
Tabla 4-2. Tabla de resultados del perfil 2 para la segmentación del ventrículo cerebral
izquierdo.
Iteración Tiempo de
Visualizació
n (ms)
Tiempo de
Segmentació
n (ms)
Memoria
(MB)
Uso de
CPU
(%)
Tamaño de
archivo
generado
1 8979 ms 6170 ms 206 MB 34.6 %
92,1 KB
2 8243 ms 5470 ms 174 MB 33.4 %
3 8199 ms 5500 ms 205 MB 24.6 %
4 8498 ms 5410 ms 141 MB 24.8 %
5 8341 ms 5570 ms 197 MB 43 %
Totales 42260 ms 28120 ms 923 MB 160.4 %
Promedio
s
8452 ms 5624 ms 184.6 MB 32.08 %
49
Luego se procedió a realizar la segunda prueba, en este caso utilizando la segmentación 2,
donde se utilizó un pipeline compuesto por 3 filtros o algoritmos ITK:
● Filtro para reducción de ruido (CurvatureFlowImageFilter):
○ Timestep: 0,01
○ Iterations: 5
● Segmentación mediante umbralado de puntos conectados
(ConnectedThresholdImageFilter):
○ Lower: -990
○ Upper: -250
○ Seed: [152, 277, 152]
● Re-escalado de intensidades (RescaleIntensityImageFilter):
○ OutputMinimum: 0
○ OutputMaximum: 255
Para el caso del perfil 1, se obtuvieron los siguientes resultados, que se detallan en la Tabla
4-3:
50
Tabla 4-3. Tabla de resultados del perfil 1 para la segmentación de los pulmones y arterias
pulmonares.
Iteración Tiempo de
Visualizació
n (ms)
Tiempo de
Segmentació
n (ms)
Memori
a (MB)
Uso de
CPU
(%)
Tamaño de
archivo
generado
1 70895 ms 32640 ms 161 MB 49.2 %
36,2 MB
2 74539 ms 36320 ms 182 MB 53.3 %
3 73735 ms 35470 ms 208 MB 48.7 %
4 75210 ms 40220 ms 197 MB 51.8 %
5 74172 ms 39628 ms 203 MB 52.4 %
Totales 368551 ms 184278 ms 951 MB 255.4 %
Promedio
s
73710,2 ms 36855,6 ms 190.2
MB
51.08 %
A continuación se adjuntan algunas capturas de pantalla de dicha segmentación en donde
pueden visualizarse los pulmones y sus arterias desde una vista frontal con superposición del
eje axial (izq.) y del eje coronal (der.)
Figura 4-5. Vistas 3D de la segmentación de pulmones y arterias pulmonares.
51
Para el caso del perfil 2, se obtuvieron los siguientes resultados, que se detallan en la tabla
4-4:
Tabla 4-4. Tabla de resultados del perfil 2 para la segmentación de los pulmones y arterias
pulmonares.
Iteración Tiempo de
Visualizació
n (ms)
Tiempo de
Segmentació
n (ms)
Memori
a (MB)
Uso de
CPU
(%)
Tamaño de
archivo
generado
1 48878 ms 16160 ms 180 MB 24.6 %
36,2 MB
2 55355 ms 22320 ms 212 MB 28.1 %
3 54710 ms 21500 ms 113 MB 28.3 %
4 46567 ms 20000 ms 212 MB 15.3 %
5 62030 ms 23330 ms 211 MB 46.5 %
Totales 218300 ms 103310 ms 948 MB 142.8 %
Promedio
s
43660 ms 20662 ms 189.6
MB
28.56 %
Haciendo un análisis de los resultados obtenidos, se puede apreciar que tanto el uso promedio
de CPU, como así también los tiempos de segmentación, de visualización de los resultados y
la memoria utilizada difieren entre ambos perfiles. En primer lugar, los tiempos de
segmentación y la memoria utilizada dependen de los algoritmos empleados y de la cantidad
de slices a procesar, dado que la primer segmentación utiliza 4 algoritmos y reduce la
cantidad de slices mediante ROI, mientras que la segunda solo utiliza 3 algoritmos y no
aplica reducción de slices. En segundo lugar, los tiempos de visualización se ven afectados
en mayor medida a la diferencia de tamaño de los volúmenes VTK generados y la
transmisión de dichos volúmenes a través de la red, lo que genera mayores tiempos de
latencia. Por último, las disimilitudes en la utilización de CPU se deben principalmente a las
diferencias tecnológicas entre ambos procesadores.
52
5 Conclusiones y trabajos futuros
En el presente capítulo se resumen los aspectos más relevantes del trabajo realizado.
También, se recapitulan los resultados obtenidos mediante las pruebas de la herramienta en
diferentes perfiles de hardware. Finalmente, se enumeran los trabajos futuros que pueden
surgir a partir del presente trabajo.
5.1 Conclusiones
Aunque hoy existen diversas soluciones existentes para procesamiento y segmentación de
imágenes médicas, ninguna está consolidada de manera general ya que su utilización suele
depender del tipo de imagen y aplicación considerada. En este sentido, el uso de ITK como
soporte al procesamiento de imágenes permite cubrir diferentes situaciones de segmentación
con algoritmos complejos y puede ser extendida con nuevos algoritmos.
Otro aspecto a señalar es que las herramientas disponibles, en general, dependen de
componentes adicionales o están diseñadas para funcionar en un sistema operativo o
ambiente específico limitando su uso. En este trabajo se presentó el desarrollo de una
herramienta web open-source para la gestión, visualización y segmentación de imágenes
digitales 2D y 3D, que se diseñó buscando eliminar estas dependencias o limitaciones.
La herramienta provee un servidor DICOM para acceder a los estudios individuales o series
de imágenes e implementa un servicio de segmentación de las mismas, mediante varios de los
filtros provistos por la librería para análisis de imágenes ITK. También brinda facilidades de
visualización de las imágenes 2D o 3D y herramientas básicas para control de brillo y
contraste, rotación, zoom, anotaciones y mediciones. Su extensibilidad facilita la
incorporación de nuevas características y soportes. También es importante mencionar que al
utilizar tecnologías web multiplataforma, facilita el acceso y procesamiento de imágenes
desde cualquier estación de trabajo con acceso a internet.
El diseño de la herramienta se realizó teniendo en cuenta los estándares de comunicación
tanto de las imágenes DICOM (WADO, DICOMWeb) como también de los módulos que la
componen (REST), lo que facilita la integración de la herramienta con otras soluciones.
5.2 Trabajos futuros
Dadas las posibilidades de extensión de la herramienta y sus módulos, se podría considerar a
futuro la posibilidad de implementar la comunicación entre los mismos utilizando gRPC [49]
y Protocol Buffers [50] para mejorar su performance.
https://sciwheel.com/work/citation?ids=11009315&pre=&suf=&sa=0
https://sciwheel.com/work/citation?ids=11009324&pre=&suf=&sa=0
53
Por otro lado, podría considerarse implementar los pipelines de segmentación como grafos
para poder realizar procesamientos paralelos y soportar filtros ITK de múltiples imágenes de
entrada.
Finalmente, podría implementarse alguna integración del segmentador con Python, y de esta
manera hacer uso de la implementación de SimpleITK para este lenguage de scripting
posibilitando la incorporación de algoritmos basados en inteligencia artificial a las
segmentaciones; tema que tiene una amplia investigación y desarrollo en la actualidad.
54
Anexo A: Utilización de la herramienta
En este anexo se presenta una breve guía sobre la utilización