Herramienta M´
ovil para la
Segmentaci´
on Asistida y An´
alisis de
Im´
agenes M´
edicas
Mar´ıa Cecilia Sachetti
Trabajo de grado presentado como requisito para optar al t´ıtulo de: Ingenier´ıa de Sistemas
Directores: Dra. Mariana del Fresno
Dr. Lucas Lo Vercio
Universidad Nacional del Centro de la Provincia de Buenos Aires Facultad de Ciencias Exactas
Resumen
El uso de dispositivos m´oviles ha aumentado exponencialmente durante las ´ultimas d´ecadas, alcanzando diversos ´ambitos, incluido el de la medicina. En la actualidad existen diversas aplicaciones m´oviles desarrolladas para la asistencia al diagn´ostico y tratamientos m´edicos, capaces de procesar archivos en formato DICOM en estos dispositivos. Dentro del procesamiento de las im´agenes m´edicas, una de las etapas m´as importantes consiste en la segmentaci´on, es decir la delineaci´on de estructuras anat´omicas o patol´ogicas. En este punto es que existen limitaciones en las aplicaciones existentes, especialmente en la obtenci´on de segmentaciones completas y correctas de acuerdo al tejido que se observa. Este proyecto presenta una herramienta m´ovil para sistemas Android cuya funcionalidad principal consiste en corroborar la validez de distintos tipos de segmentaciones realizadas por el usuario. Seg´un la imagen m´edica, la herramienta proporciona las geometr´ıas y validaciones de forma correspondientes a los tejidos que pueden observarse. El desarrollo cuenta con un dise˜no flexible que facilita incluir nuevos tipos de segmentaciones y validaciones de manera sencilla. Las pruebas realizadas sobre distintos dispositivos muestran que la aplicaci´on hace un eficiente uso de la memoria. Tambi´en se comprob´o la adaptabilidad de las interfaces de la aplicaci´on a pantallas de distintos tama˜nos.
Agradecimientos
A mis familiares y amigos.
A mis pap´as, Cristina y Fernando, gracias por haberme dado, con tanto esfuerzo, la posibilidad de estudiar lo que eleg´ı, por crear este futuro para m´ı y por alentarme siempre a seguir adelante. A mis hermanos y amigos por cada palabra de felicitaci´on y apoyo ante cada paso que me acercaba m´as a esta meta, por m´as peque˜no que fuera. ¡Gracias!
A Daniel.
Gracias por acompa˜narme durante todo este tiempo, por tus consejos y aportes cada vez que los necesit´e, por entenderme en los momentos en que no parec´ıa f´acil finalizar este proyecto y siempre motivarme a seguir. Gracias por estar siempre a mi lado.
A la universidad p´ublica argentina.
Contenido
Res´umen I
Agradecimientos III
Lista de figuras VII
Lista de tablas IX
Lista de bloques de c´odigo X
1 Introducci´on 1
1.1 Motivaci´on . . . 1
1.1.1 Dispositivos m´oviles . . . 1
1.1.2 Asistencia al diagn´ostico por computadora . . . 2
1.2 Estado del arte . . . 4
1.2.1 Soluciones existentes para iOS . . . 4
1.2.2 Soluciones existentes para Android . . . 6
1.3 Propuesta . . . 7
2 Segmentaci´on de im´agenes m´edicas 9 2.1 Etapas del procesamiento de im´agenes m´edicas . . . 9
2.1.1 Captura . . . 11
2.1.2 Preprocesamiento . . . 11
2.1.3 Extracci´on de caracter´ısticas . . . 12
2.1.4 Segmentaci´on . . . 12
2.1.5 Registraci´on . . . 13
2.2 Segmentaci´on manual, autom´atica y semiautom´atica . . . 13
2.2.1 Modelos deformables . . . 14
2.3 Evaluaci´on de la segmentaci´on . . . 15
2.4 Segmentaciones de inter´es . . . 16
3 Dise˜no e implementaci´on 18 3.1 Consideraciones de programaci´on para dispositivos m´oviles Android . . . 18
3.1.1 Elecci´on de la API . . . 18
3.1.3 Memoria . . . 21
3.2 Programaci´on en Android . . . 22
3.2.1 Componentes de la aplicaci´on . . . 22
3.2.1.1 Activity . . . 23
3.2.1.2 Listeners . . . 23
3.2.2 Librer´ıa DICOM . . . 24
3.2.3 Framework de IoC e inyecci´on de dependencias . . . 25
3.2.4 M´etodo de segmentaci´on autom´atica . . . 28
3.2.5 Compatibilidad . . . 29
3.3 Implementaci´on . . . 30
3.3.1 Validadores . . . 33
3.3.2 Escenarios de validaci´on . . . 33
4 Resultados 37 4.1 Usabilidad . . . 37
4.1.1 Apertura y segmentaci´on v´alida de un archivo DICOM . . . 39
4.1.2 Errores de validaci´on . . . 42
4.1.3 Segmentaci´on autom´atica mediante modelos deformables . . . 42
4.2 Extensi´on . . . 43
4.2.1 Implementaci´on de nuevos validadores . . . 43
4.2.2 Mensajes de error . . . 46
4.2.3 Nuevos tipos de segmentaci´on . . . 49
4.2.4 Interfaz de usuario . . . 50
4.2.5 Segmentaciones implementadas . . . 53
4.2.5.1 Ultrasonido intravascular (IVUS) . . . 53
4.2.5.2 Retinograf´ıa . . . 55
4.2.5.3 Ultrasonido carot´ıdeo . . . 55
4.2.5.4 Tumor cerebral . . . 57
4.3 Uso de recursos computacionales . . . 57
4.3.1 Resultados en emuladores . . . 57
4.3.2 Resultados en dispositivos reales . . . 64
4.4 Pruebas en distintas pantallas . . . 64
5 Conclusiones y trabajos futuros 68 5.1 Conclusiones . . . 68
5.2 Trabajos Futuros . . . 69
Lista de Figuras
2-1. Etapas del procesamiento de im´agenes m´edicas. . . 10
3-1. Distribuci´on de dispositivos entre las versiones de la API. . . 20
3-2. Interfaz e implementaciones para la exportaci´on de la base de datos en dife-rentes formatos. . . 26
3-3. Pantallas de informaci´on y configuraci´on de la aplicaci´on en sistema Android 7.0 (API nivel 24) . . . 31
3-4. Diagrama de clases correspondiente al dise˜no de los tipos de segmentaciones y sus validadores. . . 34
3-5. Diagrama de secuencia correspondiente a la validaci´on de una segmentaci´on. 35 4-1. Apertura de un archivo DICOM . . . 40
4-2. Visualizaci´on del frame y selecci´on del tipo de segmentaci´on . . . 41
4-3. Segmentaci´on de lumen-´ıntima en un estudio IVUS. . . 42
4-4. Errores de validaci´on durante segmentaci´on de IVUS. . . 43
4-5. Segmentaci´on semiautom´atica mediante modelos deformables . . . 44
4-6. Interfaz a implementar para la creaci´on de nuevos validadores. . . 45
4-7. Implementaci´on del validador de contorno cerrado. . . 46
4-8. Implementaci´on del validador abstracto de contornos curvos conc´entricos . . 47
4-9. Implementaci´on del validador de exterioridad para contornos curvos conc´ entri-cos. . . 48
4-10.Implementaci´on del validador de interioridad para contornos curvos conc´ entri-cos. . . 48
4-11.Definici´on de claves para los mensajes de error utilizados por los validadores. 48 4-12.Definici´on de la traducci´on de los mensajes de error. . . 49
4-13.Definici´on del nuevo tipo de segmentaci´onIVUS lumen-intima eIVUS media-adventitia. . . 50
4-14.Definici´on de las segmentaciones relacionadas para los nuevos tipo de segmen-taci´on IVUS lumen-intima e IVUS media-adventitia. . . 51
4-15.Creaci´on de una nuevaactivity en el entorno de desarrollo Android Studio. . 52
4-16.Layout correspondiente a la nueva activity, incluyendo al archivo contenedor de los elementos de la vista content ivusseg.xml. . . 52
4-17.Layout contenedor de los elementos de la nueva vista para el estudio IVUS. . 53
4-19.Bot´on para la selecci´on del nuevo tipo de estudio IVUS en el layout de la
activity SelectSegmentationActivity . . . 54
4-20.Modificaciones en SelectSegmentationActivity para asignar comportamiento al nuevo bot´on asociado al estudio IVUS . . . 55
4-21.Diagrama de secuencia correspondiente a la validaci´on de una segmentaci´on de tipo IVUS media-adventitia . . . 56
4-22.Tipos de segmentaciones implementadas en la herramienta. . . 58
4-23.Uso de la memoria RAM durante el inicio de la aplicaci´on en el perfil de hardware 1. . . 60
4-24.Uso de la memoria RAM durante el inicio de la aplicaci´on en el perfil de hardware 2. . . 60
4-25.Uso de la memoria RAM durante la manipulaci´on de un archivo DICOM en el perfil de hardware 1. . . 61
4-26.Uso de la memoria RAM durante la manipulaci´on de un archivo DICOM en el perfil de hardware 2. . . 61
4-27.Uso de la memoria RAM durante la realizaci´on de segmentaciones en el perfil de hardware 1. . . 62
4-28.Uso de la memoria RAM durante la realizaci´on de segmentaciones en el perfil de hardware 2. . . 62
4-29.Uso de la memoria RAM y CPU durante la realizaci´on de segmentaciones en el perfil de hardware 1. . . 63
4-30.Uso de la memoria RAM y CPU durante la realizaci´on de segmentaciones en el perfil de hardware 2. . . 63
4-31.Uso de recursos en dispositivo Samsung Galaxy A3. . . 64
4-32.Uso de recursos en dispositivo Moto Z Play. . . 65
4-33.Adaptabilidad de las interfaces en dispositivo Samsung Galaxy A3. . . 66
4-34.Adaptabilidad de las interfaces en dispositivo Moto Z Play. . . 66
Lista de Tablas
1-1. Comparaci´on entre soluciones existentes y sus caracter´ısticas para la manipu-laci´on de im´agenes DICOM en sistemas iOS y Android . . . 8
3-1. Segmento del m´odulo DicomSegModule que provee una dependencia de tipo IDbExporter para la exportaci´on de la base de datos en formato XML . . . . 27
3-2. Componente MainActivityComponent encargado de inyectar las dependencias necesarias en la clase MainActivity . . . 27
3-3. Segmento de la actividad MainActivity que permite la inyecci´on mediante Dagger de una dependencia de interfaz IDbExporter . . . 28
3-4. Segmento del archivo manifiesto donde se indican los permisos requeridos por la aplicaci´on . . . 30
1 Introducci´
on
El auge de los dispositivos m´oviles en los ´ultimos a˜nos ha causado una gran repercu-si´on en muchos aspectos, no s´olo de la vida cotidiana de las personas, sino tambi´en de las tecnolog´ıas afines a su evoluci´on y desarrollo. El campo de la medicina no se vio exento de este crecimiento y se ha vuelto frecuente la adopci´on de estos dispositivos por parte de los profesionales de la salud para acceder r´apidamente a la informaci´on cl´ınica.
Las im´agenes m´edicas conforman uno de los aspectos m´as importantes de la informaci´on de un paciente, ya que su an´alisis permite al m´edico realizar tareas fundamentales como el diagn´ostico de enfermedades y el monitoreo de tratamientos. En los ´ultimos a˜nos ha tomado relevancia la asistencia que las herramientas inform´aticas pueden brindar en estos aspectos. Estas herramientas facilitan considerablemente el an´alisis y procesamiento, sobre todo en un contexto donde ha aumentado el n´umero de modalidades de captura existentes, y el tama˜no de las im´agenes.
En particular, la asistencia a la segmentaci´on o detecci´on de ´areas de inter´es dentro de una imagen es de particular importancia ya que permite reducir el tiempo y esfuerzo que esta tarea puede demandar por parte del especialista, a la vez que posibilita lograr resultados m´as precisos, completos y repetibles.
En la actualidad existen distintas aplicaciones para dispositivos m´oviles destinadas a la manipulaci´on de im´agenes m´edicas, cada una de ellas con distintas caracter´ısticas y limitaciones. Es entre estas limitaciones, relacionadas principalmente a la necesidad de ob-tener segmentaciones completas y correctas, que surge la motivaci´on para el desarrollo de la herramienta presentada en este trabajo.
1.1.
Motivaci´
on
1.1.1.
Dispositivos m´
oviles
La aparici´on de los smartphones sobre el final de los a˜nos 90 y la popularizaci´on de las
tablets hacia el a˜no 2010 trajeron consigo una creciente cantidad de aplicaciones destinadas a simplificar no solo actividades cotidianas sino tambi´en actividades laborales. As´ı, los dis-positivos m´oviles se integraron completamente a la rutina de las personas, formando parte de su vida no solo personal, sino tambi´en profesional. De esta manera, en medio del auge de las tecnolog´ıas m´oviles, se gener´o un ambiente propicio para el desarrollo de la denominada
computaci´on ubicua (oubicomp) [3], tecnolog´ıa que est´a disponible en todo momento y lugar, es decir, onmipresente.
1.1.2.
Asistencia al diagn´
ostico por computadora
Desde el descubrimiento de los rayos X, el campo de las im´agenes m´edicas ha evolu-cionado exponencialmente, tanto en la pr´actica cl´ınica como en el ´ambito acad´emico. Una imagen m´edica permite la visualizaci´on de partes del cuerpo, tejidos u ´organos, con el princi-pal objetivo de asistir al diagn´ostico, tratamiento y monitoreo de enfermedades [4]. Gracias a la tomograf´ıa computada (CT), las im´agenes de resonancia magn´etica (MRI), la tomo-graf´ıa por emisi´on de positrones (PET), el ultrasonido y otras modalidades de obtenci´on de im´agenes m´edicas, los m´edicos radi´ologos (profesionales especializados en llevar a cabo estudios mediante im´agenes m´edicas, y en su posterior an´alisis) y dem´as especialistas pueden observar el interior del cuerpo humano con gran detalle [5].
Desde sus comienzos, debido a la existencia de diversos fabricantes y m´etodos de ob-tenci´on de im´agenes m´edicas, los dispositivos utilizados para capturarlas dieron origen a dis-tintos formatos de im´agenes y formas de transmisi´on de dicha informaci´on. A fin de resolver estas diferencias y posibilitar la interconexi´on de los equipos surgi´o DICOM (Digital Imaging and Communications in Medicine), el est´andar aceptado mundialmente para el almacena-miento, visualizaci´on y transmisi´on de im´agenes m´edicas [6]. DICOM permite persistir en forma sistematizada im´agenes y anotaciones, y visualizar esta informaci´on en diferentes dis-positivos, independientemente de la plataforma en que se obtuvieron. Habitualmente, las im´agenes DICOM adquiridas en las instituciones de salud desde las distintas modalidades (CT, MRI, ultrasonido, rayos X, etc.) son almacenadas en sistemas PACS (Picture Archiving and Communication System) para su gesti´on eficiente. Un servidor PACS es un sistema que permite el almacenamiento y la transmisi´on de im´agenes m´edicas dentro de una instituci´on hospitalaria. Estos sistemas tambi´en proveen servicios para la visualizaci´on de las im´agenes DICOM y ofrecen distintas facilidades para acceder a ellas desde las estaciones de trabajo, bajo determinados protocolos de seguridad [7].
1.1 Motivaci´on 3
(Computer-Aided Diagnosis - CAD). Este tipo de herramientas han evolucionado notable-mente en los ´ultimos a˜nos, contando actualmente con distintas alternativas autom´aticas o semiautom´aticas, que en muchos casos se incorporan a la pr´actica cotidiana para asistir a los profesionales [8]. El avance en la tecnolog´ıa de adquisici´on de im´agenes m´edicas digitales y el incremento de modalidades y resoluci´on de las mismas han convertido al an´alisis autom´atico en un componente fundamental para el diagn´ostico y tratamientos en el ´ambito cl´ınico.
Entre las facilidades provistas por las aplicaciones CAD se encuentran la visualizaci´on, segmentaci´on y an´alisis de im´agenes m´edicas. La segmentaci´on consiste en particionar una imagen en diferentes secciones, segmentos o estructuras significativas [9]. Representa uno de los procesos fundamentales debido a que facilita la detecci´on, caracterizaci´on y visualizaci´on de las regiones de inter´es dentro de la imagen, y por lo tanto su resultado afecta las subse-cuentes etapas de an´alisis [10]. A partir de las segmentaciones obtenidas se pueden extraer diversos indicadores de utilidad sobre la geometr´ıa, estructura y medidas de las regiones de inter´es; por ejemplo, el ancho de la pared arterial para estimar el riesgo cardiovascular, o el nivel de vascularizaci´on en tumores cerebrales, para estimar la proyecci´on de evoluci´on del mismo.
Durante la utilizaci´on de aplicaciones de asistencia al diagn´ostico m´edico, los profesio-nales suelen efectuar anotaciones sobre las im´agenes, para dejar evidencia del diagn´ostico o tratamiento realizado. Por lo tanto, es necesario un correcto resguardo de las mismas junto a las im´agenes m´edicas y la informaci´on del paciente, ya que contribuye a enriquecer su historia cl´ınica. Adem´as, esta informaci´on es de utilidad en el desarrollo de interconsultas con otros especialistas, para transmitir y discutir diagn´osticos.
Por el lado de la investigaci´on en m´etodos de segmentaci´on y an´alisis de im´agenes, las anotaciones de los especialistas son especialmente requeridas para el dise˜no y validaci´on de los algoritmos computacionales para CAD. Para la investigaci´on sobre m´etodos de segmentaci´on autom´atica de im´agenes m´edicas, cuyo fin es obtener segmentaciones sin ning´un tipo de supervisi´on, es necesario contar con las correspondientes anotaciones de los especialistas para el entrenamiento de los algoritmos desarrollados o para determinar la exactitud de los resultados obtenidos [11].
en cuenta algunos aspectos importantes en el desarrollo de aplicaciones m´oviles, relativos a la seguridad y capacidad de transmisi´on y visualizaci´on de las im´agenes, dependiendo de la tecnolog´ıa utilizada [15].
La ´ultima generaci´on de dispositivos m´oviles se caracteriza por poseer pantallas t´ acti-les, que simplifican considerablemente su utilizaci´on. Esta caracter´ıstica puede facilitar a los profesionales tareas como la de seleccionar ´areas de inter´es sobre una imagen m´edica. En relaci´on a los requisitos necesarios para una correcta segmentaci´on puede ser de gran utili-dad para los m´edicos contar con ciertas gu´ıas que faciliten la obtenci´on de segmentaciones apropiadas y completas.
Es as´ı, en el contexto previamente presentado, que la computaci´on ubicua se ha inte-grado fuertemente en el ´ambito de la medicina, permitiendo que la tecnolog´ıa para asistir a los profesionales m´edicos est´e disponible en todo momento y lugar, colaborando muchas veces de forma transparente para conseguir resultados con mayor rapidez y cada vez m´as confiables en las ´areas de diagn´ostico y tratamiento de enfermedades.
1.2.
Estado del arte
Dentro de la amplia gama de dispositivos m´oviles t´actiles disponibles en el mercado, se ha estimado que alrededor de un 80 % de los mismos utilizan el sistema operativo Android [16]. Esta plataforma tiene la ventaja de ser open source, lo que permite tener acceso a su c´odigo fuente e implementar personalizaciones del mismo. Otra gran ventaja que posee, es que existen entornos de desarrollo gratuitos para implementar aplicaciones para dicho sistema, los cuales funcionan tanto en sistemas Linux como Windows. Actualmente, como se ver´a mas adelante, existen varias aplicaciones Android que permiten la visualizaci´on y an´alisis de archivos DICOM.
En segundo lugar, con una cuota de mercado de 13 % aproximadamente, se encuen-tra iOS [16]. A diferencia de la flexibilidad ofrecida por Android en cuanto al desarrollo de aplicaciones, en el caso de iOS es necesario contar con una computadora Mac, ya que los entornos disponibles no funcionan en ning´un otro sistema operativo m´as que iOs mismo. Tambi´en existen aplicaciones que operan sobre archivos DICOM para esta plataforma, como por ejemplo OsiriXR [17]. Esta aplicaci´on incluye entre sus caracter´ısticas, la visualizaci´on de las im´agenes y herramientas de ajuste y medici´on [18]. Pero, al igual que las aplicacio-nes existentes para Android, no dispone de una herramienta para marcar o segmentar las im´agenes considerando la geometr´ıa del objeto de inter´es.
1.2.1.
Soluciones existentes para iOS
1.2 Estado del arte 5
para la comunicaci´on de im´agenes y es capaz de recibir im´agenes transmitidas por dicho protocolo de comunicaci´on desde cualquier PACS.
Esta aplicaci´on es gratuita en su versi´on para 32 bits, pero su versi´on de 64 bits que alcanza mejores prestaciones, es paga. Tambi´en existe otra versi´on paga denominada OsiriX MD, que adem´as de incluir la versi´on para 64 bits, incluye soporte por email y plugins con ayuda al usuario.
Entre las caracter´ısticas m´as importantes con respecto a la manipulaci´on de im´agenes DICOM se encuentran las siguientes:
Lectura y visualizaci´on de archivos DICOM Una imagen 2D (dos dimensiones) consiste
en una imagen expresada en un plano. En su aplicaci´on en la inform´atica m´edica, las acciones sobre este tipo de im´agenes consisten simplemente en zoom y desplazamientos en cualquiera de las direcciones del plano. En el caso de im´agenes 3D (tres dimensiones), en cambio, se pueden realizar acciones propias de cuerpos en el espacio. Tradicionalmente, las im´agenes m´edicas generadas por los equipos son 2D, pero mediante la obtenci´on de muchos escaneos y su combinaci´on mediante algoritmos de reconstrucci´on apropiados pueden obtenerse modelos 3D. Por ´ultimo, las im´agenes 4D (4 dimensiones, o 3D+t) consisten en una serie temporal de im´agenes 3D, con las cuales los profesionales pueden observar movimientos y cambios a trav´es del tiempo en el estudio que se le realiza al paciente.
OsiriX cuenta con visualizaci´on de im´agenes 2D, 3D y 4D. Para los dos primeros tipos de visualizaciones posee herramientas que permiten ajustar el contraste y el brillo de la imagen, hacer zoom, moverse sobre la imagen, rotarla, medir distancias, entre otras.
Una limitaci´on de esta aplicaci´on con respecto a la visualizaci´on se presenta con im´ age-nes m´as grandes a 1024x1024 pixeles. En dicho caso, la aplicaci´on redimensionar´a la imagen para hacerla igual o m´as peque˜na que dicho tama˜no.
Formatos de im´agenes OsiriX puede manejar im´agenes DICOM, como as´ı tambi´en JPEG lossy, JPEG lossless, JPEG-LS, y JPEG 2000 [19].
Herramientas de segmentaci´on En relaci´on con esta funcionalidad, OsiriX provee una herramienta de pincel para hacer anotaciones sobre las im´agenes m´edicas y para indicar ´areas mediante rect´angulos o c´ırculos, pero carece de herramientas de segmentaci´on complejas. Sin embargo, existen algunos plugins que agregan dicha funcionalidad a la aplicaci´on para distintos formatos de im´agenes y distintos tipos de estudios, utilizando diferentes algoritmos.
Algunos ejemplos destacados de estos plugins [20] son:
Ejection Fraction: Permite medir la fracci´on de eyecci´on del ventr´ıculo izquierdo en resonancias magn´eticas card´ıacas, mediante un proceso semi autom´atico paso a paso.
Hip Arthroplasty Templates: Consiste en un plugin de planificaci´on digital preopera-toria para reemplazo de articulaciones en condiciones artr´ıticas de cadera. Permite al cirujano seleccionar de una biblioteca de plantillas y superponerlas electr´onicamente en una imagen DICOM. El cirujano puede entonces realizar las mediciones necesarias para el proceso de planificaci´on de plantillas y pre-operatorio en un entorno digital.
Memoria Dependiendo de la cantidad de im´agenes que se deseen abrir, lo cual tambi´en est´a determinado por el tipo de estudio que se quiere visualizar, hay que tener en cuenta la cantidad de memoria del dispositivo. OsiriX est´a preparado para levantar hasta 3000 im´agenes (como por ejemplo, una tomograf´ıa computada 4D), pero para ello requerir´a estar corriendo en un dispositivo con al menos 4GB de memoria RAM.
1.2.2.
Soluciones existentes para Android
Actualmente existen varias aplicaciones desarrolladas para la plataforma Android que manipulan im´agenes DICOM, pero con muy pocas caracter´ısticas en comparaci´on con las que ofrece Osirix de iOS.
La gran mayor´ıa de las aplicaciones de este tipo que se encuentran disponibles para descargar enGoogle Play Storeconsisten meramente en visualizadores que no poseen ninguna cualidad extra adem´as de la posibilidad de ver la imagen y su metadata en el dispositivo, y funciones simples como zoom,panning (movimiento paralelo sobre el plano de vista actual, utilizado generalmente cuando la imagen es m´as grande que la pantalla en la cual se est´a mostrando) y exportaci´on de la imagen hacia alg´un otro formato como jpeg o png. Entre ellas se destaca DICOM Droid Pro [21], que adem´as posee filtros para ajustar el contraste y brillo de la imagen, herramientas de medici´on y dibujo de formas como c´ırculos, rect´angulos o mano alzada.
En menor medida, Google Play Store tambi´en ofrece una serie de aplicaciones que permiten visualizar im´agenes m´edicas pre-cargadas, orientadas a estudiantes de medicina con fines did´acticos. En este tipo de aplicaciones, las im´agenes disponibles (las cuales no est´an representadas en todos los casos en el formato est´andar DICOM) le permiten al usuario realizar un diagn´ostico sobre la imagen y poner a prueba sus conocimientos de an´alisis. Ejemplo de aplicaciones de este tipo son Radiology 4 Med Students [22] e Imaging Anatomy
[23].
1.3 Propuesta 7
completamente todos los tags y metadata que contengan para asegurar la confidencialidad de la informaci´on del paciente al que pertenece el estudio.
Por ´ultimo, existen otras aplicaciones desarrolladas en entornos de investigaci´on que otorgan nuevas funcionalidades. Una de ellas, m3DICOM, consiste en una arquitectura cliente-servidor, de la cual se obtienen las segmentaciones de un archivo DICOM y con ellas se generan modelos 3D de las mismas del lado del cliente m´ovil [25]. Otra aplicaci´on existente permite la colaboraci´on online de varios usuarios para analizar im´agenes m´edicas, donde se pueden hacer anotaciones simult´aneamente y marcar ´areas de inter´es en tiempo real sin alterar los datos originales [26]. Sin embargo, entre todas sus caracter´ısticas, no posee una verificaci´on de las anotaciones a mano alzada sobre las im´agenes, as´ı como tampoco permite almacenarlas en el archivo de la imagen.
En la tabla 1-1 se resumen las caracter´ısticas m´as importantes para la manipulaci´on de im´agenes DICOM presentes en las soluciones existentes para los dos sistemas en conside-raci´on, iOS y Android.
1.3.
Propuesta
El objetivo de este trabajo final ha sido el desarrollo de una aplicaci´on para dispositivos t´actiles m´oviles con sistema operativo Android, que permita al m´edico seleccionar ´areas de inter´es sobre una imagen m´edica, aprovechando las ventajas de la computaci´on ubicua. El sistema provee soporte para asistir y agilizar la tarea del profesional en el an´alisis de una imagen o una secuencia de im´agenes diagn´osticas que sean consideradas.
2 Segmentaci´
on de im´
agenes m´
edicas
Una imagen m´edica es toda imagen que permite observar el interior del cuerpo humano o partes de ´el, obtenida mediante la irradiaci´on de distintos tipos de energ´ıa que interact´uan con la muestra, es decir, con el paciente. Com´unmente se denomina “modalidades de imagen” a las diferentes t´ecnicas de obtenci´on de im´agenes m´edicas. Las im´agenes m´edicas produ-cen informaci´on cl´ınica fundamental para obtener diagn´osticos precisos y tomar decisiones acertadas en el tratamiento de enfermedades.
Debido a la existencia de diferentes modalidades de captura, as´ı como tambi´en de la existencia de distintos fabricantes de dispositivos para dicho fin, surgi´o la necesidad de unificar el formato de las im´agenes m´edicas. De esta forma nace el est´andar DICOM, el cual define no solo un formato de almacenamiento com´un para las im´agenes, sino tambi´en todo un protocolo de comunicaci´on de las mismas. En el presente trabajo, es de inter´es el ´area de almacenamiento del est´andar DICOM.
A partir de la estandarizaci´on del almacenamiento provista por DICOM, los dispositivos de distintas modalidades y fabricantes almacenan las im´agenes resultantes de un estudio en un ´unico archivo, el cual incluye no solo las im´agenes mismas, sino tambi´en informaci´on del paciente (identificador, nombre, sexo, fecha de nacimiento), informaci´on del estudio (m´edico tratante, hora, fecha, descripci´on), datos del equipo (modelo, fabricante), entre otros datos. Mantener toda esta metadata en un solo archivo es de gran utilidad, ya que de ´esta manera es imposible que una imagen sea separada de su correspondiente informaci´on por error.
Uno de los problemas fundamentales en el an´alisis de im´agenes m´edicas es la segmen-taci´on de las mismas, la cual consiste en el particionamiento de una imagen en distintas regiones significativas [7], permitiendo identificar los l´ımites de estructuras anat´omicas o re-giones de inter´es (por ejemplo, ´organos o tumores) dentro de una imagen [27]. La importancia de la segmentaci´on radica en que permite la localizaci´on de anomal´ıas, asistir al diagn´ostico, cuantificar las diferencias que podr´ıan existir en estudios de seguimiento de una anomal´ıa previamente detectada y asistir en el planeamiento de tratamientos o cirug´ıas [28].
2.1.
Etapas del procesamiento de im´
agenes m´
edicas
Mejoramiento de la imagen: Por ejemplo, reducci´on del ruido o aumento de la nitidez.
Reconocimiento de patrones: Por ejemplo, detecci´on autom´atica de una determinada forma o textura.
Reducci´on de datos a informaci´on m´as f´acil de manejar o interpretar: Por ejemplo, la reducci´on de una imagen a un conjunto de objetos, caracter´ısticas o medidas.
S´ıntesis: Consiste en crear nuevas im´agenes a partir de otras ya existentes. Por ejemplo, reconstrucci´on de una escena tridimensional a partir de fotograf´ıas bi-dimensionales.
Combinaci´on de im´agenes: Combinar im´agenes correspondientes a la misma escena, pero que fueron creadas con dos modalidades diferentes.
Compresi´on de datos: Para reducir el tama˜no de los archivos de im´agenes y acelerar la transmisi´on de los mismos a trav´es de una red.
El procesamiento de im´agenes m´edicas se puede dividir en cinco etapas diferentes (fi-gura 2-1), de las cuales solo algunas pueden llegar a ser necesarias dependiendo de los requerimientos de la aplicaci´on involucrada. En primer lugar se encuentra la etapa de cap-tura de la imagen (Secci´on 2.1.1) mediante alg´un dispositivo. A continuaci´on, en la etapa de preprocesamiento (Secci´on 2.1.2) se mejora el aspecto de la imagen mediante diferentes t´ecnicas para facilitar las etapas subsiguientes. En la etapa de extracci´on de caracter´ısticas (Secci´on 2.1.3) se obtienen propiedades de inter´es de la imagen, ´utiles para la aplicaci´on en la cual ser´a utilizada. En la etapa de segmentaci´on (Secci´on 2.1.4) se delimitan las ´areas de inter´es a analizar. Finalmente, en la etapa de registraci´on (Secci´on 2.1.5) es posible combinar distintas im´agenes de la misma escena, con el fin de correlacionar informaci´on.
2.1 Etapas del procesamiento de im´agenes m´edicas 11
2.1.1.
Captura
La primera etapa del procesamiento de im´agenes m´edicas est´a siempre dada por la captura de la imagen y consiste en la obtenci´on de la misma mediante alguna t´ecnica o modalidad espec´ıfica.
El factor que define las diferentes modalidades es el tipo de energ´ıa utilizada. Alguna de las modalidades m´as usadas son: radiaci´on electromagn´etica por rayos X, radiaci´on elec-tromagn´etica por rayos gamma (medicina nuclear), radiaci´on electromagn´etica por ondas de radio (resonancia magn´etica) y energ´ıa ultras´onica (ecograf´ıa) [30]. Para obtener la imagen m´edica, diferentes dispositivos de acuerdo a la modalidad utilizada, registran la interacci´on de la energ´ıa con la muestra. Finalmente, esa informaci´on es procesada por computadora para traducirla en im´agenes que los profesionales m´edicos pueden analizar o que pueden ser la entrada para la siguiente etapa del procesamiento de im´agenes.
2.1.2.
Preprocesamiento
El prepocesamiento de las im´agenes m´edicas tiene como objetivo mejorar la apariencia visual de la imagen, resaltar caracter´ısticas importantes y suprimir o atenuar las carac-ter´ısticas no deseadas. Mediante el preprocesamiento se obtienen im´agenes cuya posterior utilizaci´on o interpretaci´on resulta m´as sencilla.
Com´unmente la calidad de una imagen m´edica se ve deteriorada debido a la heteroge-neidad de los tejidos, la presencia de cuerpos extra˜nos o artefactos, errores de hardware y
software, o movimientos del paciente durante la captura. Estos defectos pueden ocultar de-talles anat´omicos y por ende, reducir la detectabilidad de lesiones [31]. El preprocesamiento de las im´agenes tiene como fin corregir estos defectos mediante diferentes t´ecnicas.
Algunas de las t´ecnicas de preprocesamiento son:
Resampleo (resampling): Se trata de una t´ecnica cuyo fin es crear una nueva versi´on de la imagen, con diferente ancho y alto en p´ıxeles. Para agrandar una imagen ( up-sampling), esta t´ecnica hace que aumente la cantidad de p´ıxeles, lo cual suele resultar en una imagen m´as borrosa debido a la disminuci´on de informaci´on por p´ıxel. Por otro lado, al achicar una imagen (downsampling), es necesario descartar informaci´on de la imagen original, sin embargo ´esto puede resultar en una imagen m´as n´ıtida [32].
Realce de contraste: Es com´un que las im´agenes 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 de la imagen [33]. La existencia de contraste en una imagen permite diferenciar m´as f´acilmente distintos objetos de inter´es.
de las im´agenes m´edicas. A estos componentes se los conoce como ruido de fondo [34]. 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 preprocesa-miento, dependiendo el tipo de ruido en cuesti´on, se encargan de eliminar la intensidad de dichos p´ıxeles para lograr una imagen de mayor calidad.
2.1.3.
Extracci´
on de caracter´ısticas
Esta etapa del procesamiento de im´agenes m´edicas consiste en extraer diferentes propie-dades o indicadores de las im´agenes, las cuales son de utilidad para el especialista encargado de su an´alisis. Una caracter´ıstica o indicador es un escalar que cuantifica una determinada propiedad de un punto o vecindario de la imagen. Dependiendo del problema a abordar, se determinar´an las caracter´ısticas que ser´a necesario extraer de la imagen.
El espacio de caracter´ısticas puede dividirse en tres categor´ıas generales [35]:
De intensidad: Caracterizan cada regi´on de inter´es de la imagen mediante los valores de niveles de gris de las mismas. Otra aproximaci´on para la obtenci´on de este tipo de caracter´ıstica consiste en medir la diferencia entre el nivel de gris medio de la regi´on y el nivel de gris medio de los p´ıxeles circundantes.
Geom´etricas: Se basan en la forma de las regiones de inter´es a analizar dentro de la imagen, calcul´andose por ejemplo, a partir del tama˜no, ´area y borde de las mismas.
De textura: El an´alisis de la textura de regiones de inter´es tiene importantes aplica-ciones en la pr´actica cl´ınica, como por ejemplo la segmentaci´on y la diferenciaci´on de lesiones. Las caracter´ısticas de textura se pueden obtener mediante diferentes t´ecnicas, las cuales se diferencian en su manera de medir las interrelaciones entre los p´ıxeles de la imagen [36].
2.1.4.
Segmentaci´
on
Como se mencion´o en la introducci´on al cap´ıtulo, la segmentaci´on es el proceso de ex-traer una o m´as regiones de inter´es de una imagen. En las im´agenes m´edicas, la segmentaci´on consiste en delinear estructuras anat´omicas o patol´ogicas, las cuales resultan homog´eneas respecto a una o m´as caracter´ısticas (como intensidad, color o textura).
2.2 Segmentaci´on manual, autom´atica y semiautom´atica 13
En la secci´on 2.2 se detallar´an los distintos tipos de segmentaci´on existentes, inclu-yendo las ventajas y desventajas de cada uno. Tambi´en se har´a hincapi´e en el m´etodo de segmentaci´on de modelos deformables que se ha considerado en este trabajo (Secci´on 2.2.1).
2.1.5.
Registraci´
on
La registraci´on de im´agenes consiste en alinear y combinar distintas im´agenes de la misma escena, encontrando puntos de una imagen que puedan ser mapeados a los corres-pondientes puntos de la otra imagen.
En el caso de las im´agenes m´edicas, esta etapa del procesamiento es de gran utilidad para correlacionar informaci´on procedente de im´agenes capturadas mediante distintas mo-dalidades. Las im´agenes utilizadas durante la etapa de registraci´on pueden provenir de un mismo paciente (registro intra-paciente), o de distintos pacientes (registro inter-paciente).
Para llevar a cabo el registro de im´agenes generalmente se utiliza alguno de los siguien-tes criterios:
Marcadores: Consiste en la alineaci´on mediante puntos caracter´ısticos (denominados marcadores olandmarks) que describen a un objeto de inter´es dentro de la imagen, los cuales pueden ser identificados en cada una de las im´agenes que se desean combinar. Dichos puntos pueden ser indicados manual o autom´aticamente.
Segmentaci´on:Consisten en la alineaci´on de forma r´ıgida o deformable de estructuras previamente segmentadas. El ´exito de estos tipos de registros de im´agenes depende del preprocesamiento previo y de la segmentaci´on.
Intensidad: Compara los patrones de intensidad en las im´agenes. A pesar de que alinear im´agenes seg´un este criterio es el m´as costoso en cuanto a recursos computacio-nales, es el m´etodo que logra el mayor nivel de precisi´on [38].
2.2.
Segmentaci´
on manual, autom´
atica y semiautom´
atica
Existen diferentes t´ecnicas de segmentaci´on de im´agenes, las cuales se distinguen por el grado de intervenci´on humana como parte del proceso y su grado de automatizaci´on.
La segmentaci´on autom´atica es aquella en la cual las regiones de inter´es son deter-minadas autom´aticamente mediante algoritmos que procesan la imagen, sin la necesidad de intervenci´on humana. Este tipo de segmentaci´on resulta muy ´util para segmentar una gran cantidad de im´agenes, ya que es capaz de realizar las segmentaciones con gran rapidez. Sin embargo, la segmentaci´on puramente autom´atica frecuentemente no es muy precisa en presencia de m´ultiples objetos y en la ausencia de bordes definidos [41].
Por ´ultimo, la segmentaci´on semiautom´atica se refiere al proceso en el cual uno o varios pasos manuales preceden o siguen a un paso autom´atico, con el fin de lograr resultados m´as exactos. Por ejemplo, algunas t´ecnicas de segmentaci´on semiautom´atica pueden requerir el ingreso manual de puntos de referencia o de inicio que luego ser´an tomados como entrada para el algoritmo de segmentaci´on autom´atica. En otros casos de segmentaci´on semiautom´atica, las segmentaciones arrojadas por el paso automatizado son corroboradas y editadas por un experto para obtener un resultado final m´as preciso.
2.2.1.
Modelos deformables
Debido a la complejidad y variabilidad de las estructuras anat´omicas, la segmentaci´on de ´areas de inter´es es uno de los principales problemas del procesamiento de im´agenes m´ edi-cas. Es com´un que los tejidos blandos (tejidos no ´oseos como m´usculos, vasos sangu´ıneos, grasa y ´organos) dentro de una misma imagen m´edica no sean lo suficientemente diferen-ciables unos de otros. As´ı mismo, las deficiencias de los dispositivos de captura y el ruido pueden hacer que los l´ımites de las estructuras sean confusos y desconectados [42].
Los modelos deformables, tambi´en conocidos como contornos activos o snakes, son t´ecnicas semiautom´aticas extensamente utilizadas para la detecci´on de bordes de los objetos de una imagen. Seg´un la propuesta original [43], la aplicaci´on de este modelo comienza con la definici´on manual de una curva inicial, cercana al objeto de inter´es que se desea delimitar. A continuaci´on, esta curva es deformada din´amicamente, cambiando su forma, orientaci´on y tama˜no en base a informaci´on extra´ıda de la imagen subyacente. Finalmente, la curva detiene su evoluci´on al alcanzar su objetivo, es decir, los bordes del ´area de inter´es.
Matem´aticamente, una curva deformable o snake es una curva C(s) = (X(s), Y(s)), donde S ∈ [0,1]. La curva se desplaza a trav´es del dominio de la imagen de manera que se minimice la funci´on de energ´ıa especificada. Esta funci´on de energ´ıa, puede variar depen-diendo de la implementaci´on deseada, pero generalmente se trata de una funci´on formada por dos partes: fuerzas internas y fuerzas externas.
Esnake =Einterna+Eexterna (2-1)
2.3 Evaluaci´on de la segmentaci´on 15
los cuales controlan la tensi´on y la rigidez de la curva, respectivamente. Por su lado,Eexterna tiende a alejar o empujar la curva hacia los bordes de acuerdo a las propiedades de la imagen. La posici´on final de la curva estar´a dada por la soluci´on m´ınima de la ecuaci´on de fuerzas 2-1.
A continuaci´on se detalla la ecuaci´on que describe la evoluci´on de la curva en el tiempo, en particular en el intervalo de tiempo t a t + ∆t. Las fuerzas internas est´an dadas por α(t)i que representa las fuerzas de tracci´on,βi(t) las fuerzas de flexi´on,γi(t)las fuerzas inflacionarias y finalmente δ(t)i que representa las fuerzas externas:
x(it+∆t) =x(t)−∆t(aαi(t)+bβi(t)−cγi(t)−dδ(it)) (2-2)
2.3.
Evaluaci´
on de la segmentaci´
on
Debido a la existencia de diferentes m´etodos de segmentaci´on, es necesario contar con m´etricas que sean capaces de determinar la calidad de los contornos resultantes de cada uno de ellos. Algunos m´etodos de segmentaci´on podr´ıan ser m´as eficaces para delimitar ciertas estructuras anat´omicas, y no tan eficientes en otras. Por ello, es importante medir las prestaciones de cada m´etodo en la segmentaci´on de la misma regi´on de inter´es.
Para evaluar eficientemente un m´etodo de segmentaci´on, es necesario considerar los siguientes tres criterios [44]:
Precisi´on: Grado en que el contorno generado se corresponde con la realidad.
Eficiencia: Cantidad de tiempo y esfuerzo requeridos para realizar la segmentaci´on.
Repetibilidad: Medida en la cual se producir´ıa el mismo resultado en diferentes sesiones se segmentaci´on, para el mismo contorno a delimitar.
A continuaci´on, se detallan algunas m´etricas existentes para la evaluaci´on de segmen-taciones:
Jaccard Index (JI): Los p´ıxeles de una imagen pueden ser considerados como per-tenecientes al objeto siendo segmentado (tanto en la realidad como en el resultado de la segmentaci´on), o como no pertenecientes al mismo. El ´ındice (o medida) de Jaccard es una relaci´on entre el n´umero de p´ıxeles coincidentes y el n´umero total de p´ıxeles coincidentes y p´ıxeles no coincidentes.
Hausdorff Distance (HD):Mide el grado de diferencia entre dos segmentaciones A y B, calculando la distancia del punto de A que est´e m´as lejos de cualquier punto de B y viceversa.
2.4.
Segmentaciones de inter´
es
Como se mencion´o en la secci´on 2.2, la segmentaci´on manual suele ser la m´as exacta. Sin embargo, como todo m´etodo que involucra intervenci´on humana, no est´a exento de erro-res. Para que una segmentaci´on sea precisa, no solo debe delimitar correctamente la regi´on de inter´es, sino tambi´en cumplir con las propiedades geom´etricas inherentes al objeto segmenta-do. Por ejemplo, algunas estructuras anat´omicas son representadas por un contorno cerrado y es posible que durante la segmentaci´on el profesional m´edico realice una segmentaci´on que no cumple con esta caracter´ıstica.
Seguidamente, se describen algunos estudios m´edicos y las regiones de inter´es com´ unmen-te segmentadas en cada uno de ellos:
Ultrasonido Intravascular (IVUS):Es un estudio por ultrasonido realizado con un cat´eter introducido en las arterias coronarias, el cual toma im´agenes axiales donde se pueden observar las paredes de dichas arterias.
Este procedimiento permite observar la totalidad de la pared de la arteria y proporcio-nar informaci´on importante sobre la acumulaci´on de placa. La placa est´a compuesta por grasas, colesterol, calcio y otras sustancias que se encuentran en la sangre. Dicha placa provoca un engrosamiento de las paredes y puede llegar a obstruir el flujo normal en la arteria. Es por esto que es de inter´es medir el tama˜no de la misma, indicando el borde exterior de la pared denominado com´unmente como interfaz media-adventicia (MA) y el borde interior denominado interfaz lumen-´ıntima (LI).
Retinografia:Es una prueba diagn´ostica no invasiva que permite obtener una imagen del fondo del ojo mediante un sistema de lentes acoplados a una c´amara fotogr´afica. En este estudio se puede observar la retina, el disco ´optico o pupila y los vasos sangu´ıneos que alimentan la retina.
Ultrasonido Carot´ıdeo:Consiste en un estudio por ultrasonido que genera im´agenes laterales de las arterias car´otidas, ubicadas a cada lado del cuello y que se encargan de transportar la sangre desde el coraz´on al cerebro. De igual manera que el estudio IVUS, permite observar posibles obstrucciones o estrechamientos de las arterias, producto del engrosamiento de sus paredes debido a la placa o co´agulos.
Para determinar el estrechamiento, es de inter´es para los profesionales m´edicos analizar las interfaces lumen-´ıntima y media-adventicia de las arterias involucradas en el estudio.
2.4 Segmentaciones de inter´es 17
La plataforma Android est´a basada en Linux, y al igual que el mismo tiene una ar-quitectura de capas de software de c´odigo abierto. Una de estas capas ofrece un completo
framework que permite a los desarrolladores crear aplicaciones para una amplia gama de dis-positivos m´oviles en un entorno de lenguaje Java. La API Java de Android ofrece diferentes componentes y servicios como un sistema de vista para crear las interfaces y administra-dores de recursos, notificaciones y actividades, los cuales facilitan el desarrollo mediante la reutilizaci´on.
En el siguiente cap´ıtulo se enumeran todos los aspectos que fueron considerados para la implementaci´on de la herramienta presentada, as´ı como tambi´en el uso de distintas librer´ıas externas. Dichas librer´ıas fueron integradas para llevar adelante no solo los requerimientos propuestos por este trabajo (Secci´on 1.3), sino que esta implementaci´on tambi´en pueda ser extendida en el futuro.
Finalmente, se presentan los dise˜nos resultantes para la funcionalidad de segmentaci´on y sus validaciones, lo que representa una de las caracter´ısticas m´as importantes de la apli-caci´on, as´ı como tambi´en los distintos escenarios existentes para la validaci´on exitosa y no exitosa de una segmentaci´on.
3.1.
Consideraciones de programaci´
on para dispositivos
m´
oviles Android
3.1.1.
Elecci´
on de la API
Una API (Aplication Programming Interface) es una interfaz proporcionada por una aplicaci´on, que permite que otras aplicaciones se comuniquen con ella y puedan hacer uso de sus funciones. Para este caso de estudio, adem´as, la interfaz del sistema operativo Android proporciona un nivel de abstracci´on entre distintas capas de software, como la capa del sistema y la de las aplicaciones de usuario. Por lo tanto, la API de Android permite a los desarrolladores crear aplicaciones que interact´uen con dicho sistema, accediendo a los m´etodos que provee.
3.1 Consideraciones de programaci´on para dispositivos m´oviles Android 19
hardware, nuevas tecnolog´ıas emergentes y experiencia de los usuarios, los sistemas opera-tivos para m´oviles, en particular Android, est´an en continuo cambio y mejora. Mantenerse actualizado con la ´ultima versi´on de una API, a pesar del posible esfuerzo que podr´ıa impli-car, siempre trae los grandes beneficios de desarrollar aplicaciones m´as completas, seguras y eficientes.
Lograr un alcance a la mayor cantidad de usuarios posibles es un aspecto muy impor-tante a la hora de decidir que versi´on de una API utilizar para desarrollar una aplicaci´on. Es as´ı como, entre los criterios m´as importantes a tener en cuenta, se encuentra la cantidad de dispositivos compatibles con cada una de las versiones. En el caso de la API de Android, existen muchas versiones a´un vigentes. En la tabla3-1 se muestran las estad´ısticas actuales de la distribuci´on del total de dispositivos existentes entre cada una de las versiones de la API de dicha plataforma. La figura 3-1representa estos mismos datos de forma gr´afica [45].
Versi´on Nombre API Distribuci´on 2.3.3 -2.3.7 Gingerbread 10 0.6 % 4.0.3 -4.0.4 Ice Cream Sandwich 15 0.6 %
4.1.x 16 2.3 %
4.2.x 17 3.3 %
4.3
Jelly Bean
18 1.0 %
4.4 KitKat 19 14.5 %
5.0 21 6.7 %
5.1 Lollipop 22 21.0 %
6.0 Marshmallow 23 32.0 %
7.0 24 15.8 %
7.1 Nougat 25 2.0 %
8.0 Oreo 26 0.2 %
Tabla 3-1: Distribuci´on de dispositivos entre las versiones de la API. No se incluyen versiones con un porcentaje menor al 0,1 %
Figura 3-1: Distribuci´on de dispositivos entre las versiones de la API.
3.1.2.
Tama˜
no de pantalla
Android es capaz de ejecutarse en distintos dispositivos que poseen diferentes tama˜nos y resoluciones de pantallas. Esta plataforma proporciona un entorno de desarrollo unifor-me para que las aplicaciones funcionen en todos los dispositivos y se encarga de la mayor parte del trabajo para adecuar la interfaz de usuario a la pantalla en la que se muestra. A pesar de estas facilidades, para que la misma aplicaci´on se vea de forma apropiada en to-das las configuraciones de pantalla compatibles, a´un es necesario seguir las buenas pr´acticas recomendadas y hacer ciertos ajustes a las interfaces.
En el desarrollo de aplicaciones Android, un layout es un contenedor de una o m´as vis-tas, que controla el comportamiento de las mismas, as´ı como la posici´on de los elementos que contienen. Existen diferentes tipos de layouts que pueden utilizarse para diversos fines. Sin embargo, como buena pr´actica se aconseja usar RelativeLayout, que aplica posicionamiento relativo para distribuir las vistas/elementos secundarias/os [46]. Este tipo delayout permite, por ejemplo, especificar que un bot´on aparezca “a la derecha de” un campo de entrada de texto.
Las densidades de pantalla para los sistemas Android se miden en dpi (dots per inch
- puntos por pulgada). Esta medida indica la cantidad de p´ıxeles por pulgada que posee la pantalla. Cuanto mayor sea este n´umero, mayor ser´a la densidad de p´ıxeles. Existen varias densidades disponibles seg´un cada dispositivo:
ldpi: lowdensity (∼120 dpi) mdpi: mediumdensity (∼160 dpi)
3.1 Consideraciones de programaci´on para dispositivos m´oviles Android 21
xhdpi: extra high density (∼320 dpi)
Otra pr´actica recomendada que ayuda a que una aplicaci´on se vea adecuadamente en distintas pantallas, es la utilizaci´on de la unidad de medida dp (density-independent pixels
o p´ıxeles independientes de la densidad) dentro de los layouts. Esta medida consiste en una unidad de p´ıxeles virtuales para expresar las dimensiones o la posici´on del dise˜no con independencia de la densidad. Se utiliza con prop´ositos de desarrollo y es la que se debe usar al definir el dise˜no de la interfaz del usuario. Un dp es equivalente a un p´ıxel f´ısico en una pantalla de 160 dpi, la cual se considera como valor de referencia para una pantalla de densidad media. Luego, en tiempo de ejecuci´on, estas unidades son mapeadas por el sistema Android a la densidad real de la pantalla. Entonces, utilizando esta unidad de medida, los tama˜nos de pantalla se agrupan en cuatro categor´ıas generales:
xlarge:al menos 960dp x 720dp large:al menos 640dp x 480dp normal:al menos 470dp x 320dp small:al menos 426dp x 320dp
Es relevante destacar que para obtener una buena calidad de imagen deben tenerse en cuenta ambos par´ametros: los p´ıxeles por pantalla y el tama˜no de la misma (aunque este ´
ultimo se mida en p´ıxeles independientes de la densidad, como se mencion´o, dicha medida es solo para fines de desarrollo). Por ejemplo, si se cuenta con una gran pantalla pero con una poca cantidad de p´ıxeles por pulgada, la calidad de los detalles ser´a bastante pobre. Por el contrario, si disponemos de una pantalla con una alta cantidad de dpi y un tama˜no de pantalla normal o reducido, el resultado ser´a una calidad de imagen mucho mayor. Por lo tanto, ambos criterios van de la mano a la hora de determinar la resoluci´on de un dispositivo.
3.1.3.
Memoria
La memoria RAM de un dispositivo m´ovil posee caracter´ısticas f´ısicas muy diferentes a la memoria RAM presente en una computadora de escritorio, como su tama˜no mucho menor y su eficiencia orientada a consumir la menor cantidad posible de bater´ıa. En general, la memoria RAM de una computadora de escritorio es ampliamente m´as r´apida que la presente en un dispositivo m´ovil. Es por ello que es de suma importancia que las aplicaciones desarrolladas para sistemas m´oviles hagan un uso eficiente de la misma, utilizando la menor cantidad posible.
Otro concepto importante del manejo de la memoria en Android, es que la memoria RAM no utilizada es considerada como memoria desperdiciada. Por tal motivo, se intenta utilizar la mayor cantidad de memoria posible, sin llegar nunca al l´ımite disponible, para aumentar la eficiencia. Cuantas m´as aplicaciones que se usan frecuentemente se encuen-tren pre-cargadas en memoria, mayor ser´a la eficiencia y menor el consumo de bater´ıa del dispositivo.
Para desarrollar aplicaciones que hagan un uso ´optimo de la memoria, es necesario tener en cuenta todos los conceptos mencionados con respecto a la administraci´on de la misma en sistemas Android. Existe una lista de consejos y buenas pr´acticas [47] que los desarrolladores deben seguir para mejorar el uso de la memoria en aplicaciones Android, entre los cuales se encuentran los siguientes que fueron especialmente tenidas en cuenta para el desarrollo de la herramienta presentada:
Evitar la creaci´on innecesaria de objetos. No ocupar memoria con objetos temporales o con un corto ciclo de vida si puede evitarse. De esta forma, cuando la creaci´on de objetos sea la m´ınima posible, el proceso de garbage collection ocurrir´a con menor frecuencia.
Hacer uso de servicios con precauci´on. Los servicios son un tipo de componente de una aplicaci´on Android que puede realizar operaciones de larga ejecuci´on en segundo plano y que no proporciona una interfaz de usuario.
Utilizar librer´ıas externas optimizadas. Muchas librer´ıas externas frecuentemente est´an escritas para dispositivos no m´oviles y pueden funcionar ineficientemente en Android.
Evitar el uso de clases embebidas (inner classes) no est´aticas en lasactivities (compo-nente de una aplicaci´on Android que ser´a detallado en la siguiente secci´on). En Java, las clases an´onimas no est´aticas tienen una referencia impl´ıcita a su clase contenedo-ra. Si no se tienen precauciones, mantener estas referencias puede resultar en que la
activity sea retenida cuando de otra manera ser´ıa eligible por el garbage collect. No olvidar cerrar los cursores luego de consultar una base de datos. Si se requiere mantener un cursor por un tiempo considerable, el mismo debe ser utilizado cuidado-samente y ser cerrado tan pronto como concluya la tarea sobre la base de datos.
3.2.
Programaci´
on en Android
3.2.1.
Componentes de la aplicaci´
on
3.2 Programaci´on en Android 23
definir el comportamiento general de la herramienta. Cada componente es ´unico, y puede requerir de otros componentes para llevar a cabo sus tareas. A continuaci´on se describen los principales componentes utilizados en este trabajo.
3.2.1.1. Activity
Una actividad o activity es un componente que representa una pantalla dentro de la aplicaci´on, mediante la cual el usuario puede interactuar y realizar las tareas que est´en disponibles dentro de la misma.
La representaci´on de la pantalla en s´ı misma, no se encuentra dentro de este tipo de componente, sino en archivos xml denominados layouts asociados a cada uno de ellos. Cada activity, entonces, tiene su correspondiente layout el cual le permite acceder a todos los elementos de la vista para asignarle a cada uno de ellos el comportamiento que debe ejecutarse cuando el usuario realiza acciones sobre ellos.
Una aplicaci´on est´a normalmente formada por m´ultiplesactivities que se vinculan entre s´ı, determinando el flujo de la misma. Generalmente, una de lasactivities de la aplicaci´on se denomina como “principal”, por ser la primer pantalla que se le presenta al usuario. A partir de all´ı, laactivitity principal puede iniciar otrasactivities de acuerdo a las acciones realizadas por el usuario, y as´ı sucesivamente con cada una que se vaya ejecutando a continuaci´on.
Para mantener un registro de lasactivities ejecutadas, cada vez que se inicia una nueva, la misma capta el foco del usuario y es agregada a la denominada “pila de activities”. Esta pila sigue un mecanismo FIFO (First In, First Out), lo que significa que cuando el usuario termina de interactuar con la activity actual y presiona el bot´on “atr´as” del dispositivo, la misma es removida de la pila (y por lo tanto destruida), reanud´andose la activity anterior.
3.2.1.2. Listeners
Un listener es una interfaz que se registra en una vista y cuya funci´on es capturar un evento. Los eventos son interacciones que el usuario realiza sobre los elementos de la vista. Por ejemplo, para que la aplicaci´on responda cuando un usuario hace click (o tap) sobre un bot´on, dicho elemento debe tener registrado unlistener mediante su m´etodo setOnClic-kListener, y dicho listener implementar el m´etodo onClick. Com´unmente, para implementar esta funcionalidad se debe extender la clase listener deseada e implementar los m´etodos correspondientes, pero dado que las vistas utilizan los listeners recurrentemente para hacer sus tareas, ´esto no ser´ıa pr´actico. Para evitar ´esto, las clases de vista contienen una colec-ci´on de interfaces anidadas concallbacks que permiten definir estos m´etodos m´as f´acilmente, directamente en el c´odigo de la clase de la vista.
Uno de loslisteners m´as destacados de la aplicaci´on, es el que se registra para el elemen-to que visualiza la imagen DICOM. Estelistener se encarga de capturar el evento onTouch, es decir, cuando el usuario toca y desliza sobre la imagen para realizar la segmentaci´on del
3.2.2.
Librer´ıa DICOM
En la actualidad existen varias librer´ıas o toolkits que permiten manipular archivos DICOM mediante el lenguaje de programaci´on Java. Algunas de ellas soportan la manipu-laci´on de estructuras de datos DICOM (no solamente im´agenes, sino tambi´en waveforms o reportes estructurados) y/o servicios provistos por el est´andar (como el env´ıo de mensajes, encriptaci´on y firma electr´onica) [48]. Tambi´en existen librer´ıas que ´unicamente permiten realizar operaciones sobre las im´agenes, como lectura de frames, lectura de encabezados y conversi´on de las im´agenes a otro formato m´as convencional como JPG.
Para la elecci´on de la librer´ıa con la cual desarrollar la aplicaci´on, no solamente se debi´o tener en cuenta que la misma provea las funcionalidades necesarias para llevar a cabo las tareas requeridas sobre los archivos DICOM, sino tambi´en otros aspectos como la licencia a la cual estuviera sujeto su uso, y la posibilidad de integraci´on con una implementaci´on para el sistema Android.
Entre las librer´ıas mencionadas en [48] se destaca dcm4chee, una librer´ıa open source
muy completa y ampliamente utilizada para manipular archivos DICOM en aplicaciones Java. La misma fue considerada como primera opci´on para el desarrollo de la aplicaci´on, pero debi´o ser descartada ya que no es posible su integraci´on con un desarrollo para Android. Esto se debe a quedcm4chee utiliza clases del paquete AWT de Java, el cual no es soportado en Android.
Otras librer´ıas, como DeCaMino y Java Dicom Toolkit, fueron directamente descar-tadas por poseer s´olo licencias comerciales ya que uno de los objetivos propuestos es una aplicaci´on extensible, y las licencias privativas puede ser un limitante para futuros desarro-llos.
Finalmente, se determin´o queImebra [49] era la librer´ıa adecuada ya que cumple con todas las condiciones necesarias. Esta librer´ıa, adem´as de realizar las operaciones habituales sobre archivos DICOM, como lectura de frames, lectura de valores de tags, modificaci´on y escritura dedatasets, entre otras, posee una versi´on compatible para el desarrollo en Android. Por ´ultimo, Imebra se encuentra bajo licencia GPLv2 (GNU General Public License), con lo cual su utilizaci´on para proyectos sin fines de lucro y c´odigo abierto es gratuito.
A pesar de haber encontrado la librer´ıa adecuada, en el primer intento de uso de la mis-ma para leer unframe dentro de alg´un archivo DICOM, se obten´ıa constantemente un error. El mismo no daba demasiados detalles sobre qu´e era lo que estaba fallando exactamente. Ante la imposibilidad de saber qu´e era lo que estaba sucediendo, se contact´o con el autor de la librer´ıa para obtener ayuda. Muy amablemente, el autor constat´o que el error proven´ıa de un bug dentro de la misma librer´ıa. Luego de arreglarlo, y de realizar otras modificaciones para que los errores obtenidos no fueran tan cr´ıpticos, actualiz´o la versi´on disponible en la sitio web de Imebra.
3.2 Programaci´on en Android 25
las operaciones requeridas por la aplicaci´on desarrollada.
3.2.3.
Framework de IoC e inyecci´
on de dependencias
Como parte de los requerimientos de la herramienta, es necesaria la exportaci´on de los datos generados en alg´un formato que pueda ser luego importado en otras herramien-tas. Debido a que los formatos requeridos por ´estas pueden ser variados, es necesaria una implementaci´on flexible de esta funcionalidad, de manera que nuevos formatos puedan ser soportados sin que ´esto implique un engorroso cambio de la implementaci´on.
La inversi´on de control o IoC (Inversion of Control) es un mecanismo provisto por diferentes librer´ıas mediante el cual el control del flujo de la aplicaci´on pasa a ser, en gran parte, controlado por la misma librer´ıa en lugar de el desarrollador.
Una de las formas de la IoC es la inyecci´on de dependencias, que consiste en quitar de las clases la responsabilidad de encontrar las referencias a los objetos que necesitan en tiempo de ejecuci´on. Esto ayuda enormemente a evitar el acoplamiento, consiguiendo un dise˜no flexible y reutilizable.
Sin embargo, los sistemas Android poseen ciertas caracter´ısticas que dificultan el uso de librer´ıas de inyecci´on de dependencias en sus aplicaciones. Las m´as relevantes son [50]:
No es recomendable mantener demasiados objetos en desuso en la memoria del dispo-sitivo. A pesar del significativo incremento de la memoria disponible en smartphones
y tablets, mantener un solo grafo de objetos puede resultar perjudicial.
Las activities son las clases de entrada de toda aplicaci´on Android. Este tipo de clase es creada por el sistema a partir de reflexi´on, con lo cual no es posible sobreescribir sus constructores, algo fundamental que debe llevar a cabo todoframework que busque la inversi´on de control.
El sistema Android posee la caracter´ıstica de detener aplicaciones en caso de necesitar recuperar memoria. Si esto sucede, el usuario abrir´a la aplicaci´on nuevamente y espera que ´esta inicie r´apidamente.
Muchos de los frameworks existentes para inyecci´on de dependencias en Android uti-lizan reflexi´on, e inicializan las aplicaciones escaneando el c´odigo en busca de annotations. Este procedimiento es ineficiente en el contexto de un dispositivo m´ovil, ya que consume una significativa cantidad de ciclos de CPU y memoria RAM, provocando una notable demora al momento de iniciar la aplicaci´on.
El cambio principal enDagger2 se basa en que el grafo de dependencias es creado, en su mayor´ıa, en tiempo de compilaci´on. De esta manera es posible detectar errores que antes solo eran descubiertos en tiempo de ejecuci´on, antes de que inicie la aplicaci´on. Por consiguiente, esto mejora enormemente el tiempo de arranque, ya que el grafo de dependencias no se genera cada vez que inicia la aplicaci´on, algo de suma importancia en aplicaciones m´oviles.
Dagger se compone principalmente de los siguientes elementos:
M´odulos: Son clases que contienen las dependencias que luego ser´an utilizadas en otras clases mediante la anotaci´on @Inject. Dichas dependencias son obtenidas me-diante una serie de m´etodos proveedores. Un m´odulo puede estar asociado a uno o m´as componentes.
Componentes:Son las clases encargadas de inyectar las dependencias.
La herramienta presentada hace uso de Dagger2 para conseguir una implementaci´on flexible de la exportaci´on de la base de datos. Por medio de la inyecci´on de dependencias, resulta muy sencillo reemplazar la implementaci´on de la clase exportadora, por diferentes instancias que realicen la tarea en distintos formatos.
En la figura 3-2 se muestra la interfaz IDbExporter, encargada de definir los m´etodos necesarios para la exportaci´on de la base de datos, as´ı como tambi´en su implementaci´on para formato XML. Tambi´en se incluyen dos posibles implementaciones m´as para otros formatos, JSON y alg´un formato personalizado.
Figura 3-2: Interfaz e implementaciones para la exportaci´on de la base de datos en diferentes formatos.
El m´odulo DicomSegModule se encarga de proveer las instancias de las dependencias que requieran otras clases de la aplicaci´on. En el bloque de c´odigo 3-1 se muestra un seg-mento de dicho m´odulo, y el m´etodo provideDbExporter() que provee una instancia de la implementaci´on de la interfaz exportadora para el formato XML.
El componente MainActivityComponent, cuyo c´odigo se muestra en el bloque 3-2, es el encargado de inyectar las dependencias requeridas por la clase asociada (en este caso
3.2 Programaci´on en Android 27
@ M o d u l e
p u b l i c c l a s s D i c o m S e g M o d u l e {
p u b l i c D i c o m S e g M o d u l e () {
}
...
@ P r o v i d e s @ S i n g l e t o n
I D b E x p o r t e r p r o v i d e D b E x p o r t e r () {
r e t u r n new D b X m l E x p o r t e r () ;
}
... }
Bloque de C´odigo 3-1: Segmento del m´odulo DicomSegModule que provee una dependencia de tipo IDbExporter para la exportaci´on de la base de datos en formato XML
@ S i n g l e t o n
@ C o m p o n e n t( m o d u l e s = { D i c o m S e g M o d u l e .c l a s s})
p u b l i c i n t e r f a c e M a i n A c t i v i t y C o m p o n e n t {
v o i d i n j e c t ( M a i n A c t i v i t y m a i n A c t i v i t y ) ;
s t a t i c f i n a l c l a s s I n i t i a l i z e r {
p r i v a t e I n i t i a l i z e r () {
}
p u b l i c s t a t i c M a i n A c t i v i t y C o m p o n e n t i n i t () {
r e t u r n D a g g e r M a i n A c t i v i t y C o m p o n e n t . b u i l d e r ()
. d i c o m S e g M o d u l e (new D i c o m S e g M o d u l e () ) . b u i l d () ;
} } }
Finalmente, la clase MainActivity que requiere una instancia de un exportador de la base de datos, simplemente hace eso de su respectivo componente,MainActivityComponent, para lograr la inyecci´on de la dependencia, tal como se muestra en el bloque de c´odigo 3-3.
p u b l i c c l a s s M a i n A c t i v i t y e x t e n d s A p p C o m p a t A c t i v i t y {
@ I n j e c t
p u b l i c I D b E x p o r t e r d b E x p o r t e r;
@ O v e r r i d e
p r o t e c t e d v o i d o n C r e a t e ( B u n d l e s a v e d I n s t a n c e S t a t e ) {
...
M a i n A c t i v i t y C o m p o n e n t c o m p o n e n t = M a i n A c t i v i t y C o m p o n e n t . I n i t i a l i z e r . i n i t () ;
c o m p o n e n t . i n j e c t (t h i s) ; ...
}
}
Bloque de C´odigo 3-3: Segmento de la actividad MainActivity que permite la inyecci´on mediante Dagger de una dependencia de interfaz IDbExporter
De igual manera que para la exportaci´on de la base de datos en distintos formatos, la inyecci´on de dependencias tambi´en es utilizada para asignar de forma flexible las clases que proveen las fuerzas externas al algoritmo snakes de segmentaci´on semi-autom´atica. Dichas fuerzas podr´ıan requerir de nuevas implementaciones para modificar el funcionamiento del algoritmo, y mediante la inyecci´on de dependencias, este cambio puede llevarse a cabo sin esfuerzo.
3.2.4.
M´
etodo de segmentaci´
on autom´
atica
Una caracter´ıstica extra de la aplicaci´on presentada es la posibilidad de generar una segmentaci´on mediante semi-automatizaci´on. Una vez realizada una segmentaci´on, el m´edico puede optar por ajustarla autom´aticamente. Esta tarea es llevada a cabo mediante la t´ecnica de modelos deformables mencionada en detalle en la secci´on 2.2.1.
Para llevar a cabo este requerimiento, fueron evaluadas las librer´ıas m´as utilizadas para el procesamiento de im´agenes que ya incluyen alguna implementaci´on de modelos deforma-bles.
3.2 Programaci´on en Android 29
A continuaci´on, se puso el foco sobre ImageJ2, una librer´ıa que no tiene dependencia alguna con ImageJ sino que consiste una reescrituraci´on completa de dicha API. En esta reescrituraci´on se puso un ´enfasis particular para no hacer uso de clases de AWT. Sin em-bargo, a pesar de que todas las dependencias con AWT fueron eliminadas, a´un hace uso de otras clases que tampoco son soportadas por Android.
Otra librer´ıa considerada fue OpenCV4Android, la cual es una versi´on adaptada de
OpenCV para programaci´on en Android, tambi´enopen source. A pesar de que fue posible su integraci´on con el entorno de desarrollo para Android, en OpenCV4Android no se encontr´o una implementaci´on del algoritmo snakes como con la que cuenta OpenCV en su primera versi´on. Esto se debe a que el proyectoOpenCV4Android surge a partir de la segunda versi´on de OpenCV, en la cual se migr´o casi toda la funcionalidad hacia una API enteramente en C++, reemplazando la anterior en C. Desgraciadamente, el algoritmo snakes, entre otros, qued´o fuera de dicha migraci´on. En comunicaciones con desarrolladores que colaboran en el proyecto OpenCV, los mismo confirmaron que dichos algoritmos no van a ser incluidos por el momento, con lo cual el uso de esta librer´ıa fue finalmente descartado para la herramienta presentada.
Agotadas las opciones de librer´ıas posibles, se decidi´o integrar al proyecto una imple-mentaci´on en Java del algoritmo snakes provista por un usuario del foro franc´es Develop-pez.com [52]. ´Unicamente fue necesaria la adaptaci´on del c´odigo alcore java de Android, ya que el mismo utilizaba clases que se encuentran fuera de ´el.
3.2.5.
Compatibilidad
Como se mencion´o en la secci´on 3.1.1, la m´ınima versi´on de la API de Android para desarrollar la aplicaci´on, se determin´o en la de nivel 19. En el otro extremo, como versi´on m´axima soportada, se eligi´o el nivel 26, lo que significa el ´ultimo nivel existente al d´ıa de la fecha. De esta manera se lograr cubrir la mayor cantidad posible de dispositivos soportados. Sin embargo, cubrir un amplio rango de versiones como en este caso, puede acarrear el problema de tener que incluir c´odigo extra para lograr la compatibilidad con alg´un nivel espec´ıfico de la API.
