Embed Size (px)
Citation preview
Graduado en Ingeniería Informática
Universidad Politécnica de Madrid
Escuela Técnica Superior deIngenieros Informáticos
TRABAJO FIN DE GRADO
Implementación del algoritmo SLICO en EspINA
Autor: Álvaro Muñoz Fernández
Director: Pablo Toharia Rabasco
Co-tutor: Félix de las Pozas Álvarez
MADRID, JULIO DE 2017
A quienes confiaron en mí en los momentos en los que yono era capaz de aportarme esa confianza a mí mismo; A aquellos cercanos a mí que no handejado de serlo en ningún momento; A quienes me han acompañado en el largo camino quees la vida, uno mucho más largo que este humilde proyecto.
Especial mención a Félix de las Pozas, cuya ayuda y experiencia han sido invaluablespara el desarrollo de este trabajo.
Índice general
Resumen VII
Abstract IX
1. INTRODUCCIÓN Y OBJETIVOS 1
1.1. Definición del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. EspINA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Qt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4. ITK y VTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.6. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. ANTECEDENTES 7
2.1. SLIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. SLICO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. ASLIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Otros algoritmos de segmentación . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1. Normalized Cuts - NC05 . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Graph-based Segmentation - GS04 . . . . . . . . . . . . . . . . . . . 9
2.4.3. Seam Carving - SL08 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.4. Quick Shift - QS08 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I
2.4.5. Watershed - WS91 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.6. Turbopixel - TP09 . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3. DESARROLLO 11
3.1. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Preparación del entorno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3. Adaptación de SLIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1. Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.2. Compresión de resultados . . . . . . . . . . . . . . . . . . . . . . . 21
3.4.3. Optimizaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4. RESULTADOS Y PRUEBAS 23
4.1. Entorno de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1. Informe de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2. Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5. CONCLUSIONES Y TRABAJOS FUTUROS 31
5.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Bibliografía 33
Índice de figuras
3.1. Pseudocódigo algoritmo SLIC . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Pseudocódigo algoritmo SLIC adaptado . . . . . . . . . . . . . . . . . . . . 15
3.3. Interfaz extensión SLIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Comparación S10-20, O10-20 y A10-20 . . . . . . . . . . . . . . . . . . . . 28
4.2. Comparación de tamaño de supervoxel O10-20 y O20-20 . . . . . . . . . . . 29
4.3. Comparación de diferentes pesos de la diferencia de color . . . . . . . . . . . 30
III
Índice de tablas
4.1. Especificaciones del equipo de pruebas . . . . . . . . . . . . . . . . . . . . . 23
4.2. Especificaciones de las imágenes de prueba . . . . . . . . . . . . . . . . . . 24
4.3. Referencia de pruebas y resultados . . . . . . . . . . . . . . . . . . . . . . . 26
V
Resumen
EspINA[1] es una herramienta de código libre que realiza tareas de segmentación, aná-
lisis y visualización de modelos volumétricos a partir de imágenes tridimensionales (stacks)
obtenidas por microscopios electrónicos y confocales, y empleada por neurólogos para el
estudio de las neuronas y sus componentes. Para ello emplea un abanico de algoritmos de
tratamiento de imágenes al que se quiere añadir el algoritmo SLIC[2] (Simple Linear Iterati-
ve Clustering), y sus variantes SLICO (Zero-parameter) y ASLIC (Adaptive).
El desarrollo de este proyecto corresponde a la adaptación de dicho algoritmo a las ne-
cesidades de EspINA y su implementación e integración en la herramienta. Se describirán
los pasos realizados para cumplir los objetivos propuestos y se analizarán los resultados ob-
tenidos en el proceso. También se reflejará la toma de decisiones y las justificaciones para
elegir el algoritmo SLIC, y se comparará con otros algoritmos similares que se encuentren
publicados.
VII
Abstract
EspINA[1] is an open-source tool used for the segmentation, analysis and rendering of
volumetric images (stacks) retrieved by electronic microscopes. It is used by neuroscientists
as a tool to study neurons and their composition. This tool makes use of a wide range of
algorithms which SLIC (Simple Linear Iterative Clustering) is to be added to that list along
with its variants: SLICO (Zero-parameter) and ASLIC (Adaptive).
In this final project the SLIC algorithm will be adapted to the needs of EspINA and it
will be implemented and integrated into the tool. The document will walk through the steps
taken to achieve the proposed goals and will highlight the achieved results. It will also go
through the decission-making and explain why SLIC was chosen instead of similar published
algorithms.
IX
Capítulo 1
INTRODUCCIÓN Y OBJETIVOS
1.1. Definición del proyecto
La fascinación por descubrir el funcionamiento de las cosas lleva al ser humano a invertir
tiempo y esfuerzo en investigación para obtener respuestas a estas dudas. Una de las mayores
incógnitas es el funcionamiento de nuestro propio cerebro, pero tratándose de un organismo
tan complejo es necesario apoyarse en herramientas que faciliten la labor de investigación y
reduzcan tanto el esfuerzo como el tiempo necesario para llegar a obtener resultados. Para
cubrir estas necesidades han surgido multitud de herramientas, y en el caso concreto de la
investigación de sinapsis neuronales se destaca la aplicación EspINA.
En análisis del funcionamiento del cerebro humano es muy complicado y las herramientas
como EspINA, esenciales para el avance en estos campos, deben avanzar igual que lo hacen
las propias investigaciones. Por este motivo se ha planteado la posibilidad de añadir un nuevo
algoritmo a la lista de herramientas de EspINA que ayude a la segmentación automatizada
de las imágenes microscópicas y facilite la ejecución de otros algoritmos más complejos que
permitan realizar un análisis exhaustivo de las imágenes.
A raíz de esa propuesta ha surgido este proyecto, que tiene como finalidad la integra-
ción del algoritmo de segmentación SLIC[2] en la herramienta EspINA. A continuación se
explicará qué es EspINA a grandes rasgos y los elementos que la componen, por qué es ne-
cesario un nuevo algoritmo de segmentación y por qué se ha optado por SLIC en lugar de las
alternativas.
Para poder realizar la implementación primero será necesario analizar y adaptar SLIC a
las necesidades de EspINA. La implementación de SLIC está diseñada principalmente para
ser utilizada en imágenes a color en un espacio bidimensional, por lo que será necesario
definir el algoritmo en base a un espacio tridimensional y en un espacio de color de una
1
sola dimensión (escala de grises) con las características peculiares de los stacks utilizados en
neurociencia.
Tras realizar la adaptación del algoritmo será necesario decidir la mejor forma de inte-
grarlo en EspINA para que sea accesible y compatible con otras herramientas integradas en
EspINA.
1.2. EspINA
EspINA[1][3] (Esp. Interactive Neuron Analyzer) es una aplicación de código libre desa-
rrollada principalmente por el Cajal Blue Brain Project[4], ubicado en el Centro de Tecno-
logía Biomédica[5] de la Universidad Politécnica de Madrid, utilizada para la segmentación,
análisis y representación de imágenes tridimensionales y modelos volumétricos, así como el
conteo y análisis de sinapsis neuronales. Estas imágenes son obtenidas mediante microsco-
pios electrónicos y EspINA proporciona herramientas para visualizar secciones transversales
(slices) en los diferentes ejes, selección de voxels de similar tonalidad a partir de un paráme-
tro de tolerancia, y otras herramientas orientadas a facilitar la labor de neurólogos a la hora
de analizar el cerebro humano. La herramienta se apoya en varias librerías de entre las que se
destacan Qt, ITK y VTK.
El código fuente de la aplicación se encuentra disponible en el repositorio de Bitbucket
de EspINA[6].
1.3. Qt
Qt es una librería destinada a la creación de interfaces de usuario de forma sencilla y con
compatibilidad para múltiples plataformas. Además ofrece un sistema de gestión de depen-
dencias y administración de proyectos similar a CMake, llamado QMake.
Las principales ventajas de Qt, además del soporte multiplataforma, son la inclusión de
diversos plugins que permiten incrustar incluso contenido web o simular prácticamente to-
dos los controles y componentes existentes en los sistemas de generación de interfaces de
usuario, un editor integrado que permite "dibujar"las interfaces de forma sencilla y eficaz,
una documentación extensa y organizada y la posibilidad de ser utilizado sin ningún coste en
proyectos de código libre.
2
1.4. ITK y VTK
ITK[7] es un conjunto de herramientas orientadas al análisis de imágenes. Al surgir como
un proyecto por y para personal médico, su principal uso es para la manipulación de imáge-
nes obtenidas por microscopios y otros instrumentos médicos. Permite, de forma eficiente y
simplificada, realizar operaciones como puede ser el alineamiento de imágenes, la configura-
ción del espaciado, el recorrido iterativo, la superposición de imágenes de múltiples fuentes,
etc. Todas ellas son necesarias en EspINA, por lo que ITK es una herramienta adecuada y
que facilita las labores de carga de imágenes y segmentación en gran medida.
VTK[8] complementa a ITK proporcionando herramientas para la visualización de imá-
genes de diversos tipos, desde imágenes 2D hasta modelos volumétricos. Proporciona Wid-gets para facilitar la integración de las representaciones y tiene integración con Qt, también
usado en el proyecto, por lo que es una gran combinación de herramientas. Permite seleccio-
nar diferentes parámetros de visualización, como podría ser el suavizado de modelos.
Ambos sistemas son de código libre y desarrollados en C++, extensamente documentados
y de extenso uso a nivel global.
1.5. Motivación
Uno de los mayores beneficios de utilizar aplicaciones para analizar las imágenes médicas
es la posibilidad de automatizar algunas tareas. Esta automatización puede ser más o menos
precisa, pero generalmente la precisión tiene un alto coste de computación. Por ejemplo,
existen algoritmos de grafos que permiten realizar un análisis a partir de una imagen, pero a
medida que la resolución de la imagen aumenta se multiplican los tiempos de procesamiento.
Los algoritmos basados en grafos son sólo un ejemplo, pero sirven para dar sentido a la
necesidad de un algoritmo como SLIC en EspINA. Con SLIC pueden generarse supervoxels
(agrupaciones o clusters de voxels) que posteriormente pueden ser tratados como nodos de
un grafo, simplificando la entrada de datos para los algoritmos de grafos reduciendo la canti-
dad de datos incluso en órdenes de magnitud. También pueden utilizarse sus resultados como
entrada de datos para otros tipos de algoritmos o simplemente para crear secciones agrupadas
en la imagen. Un ejemplo de cómo utilizar un algoritmo de segmentación sobre una imagen
para después utilizar algoritmos más complejos sobre los resultados se puede ver en el artícu-
lo A Fully Automated Approach to Segmentation of Irregularly Shaped Cellular Structuresin EM Images[9], en el que SLIC es utilizado en conjunto con algoritmos basados en grafos
reduciéndose los tiempos de ejecución y aumentándose la calidad de los resultados al salvar
algunas limitaciones de los algoritmos basados en grafos.
Aunque existen diversos algoritmos que cumplen la misma función que SLIC, se ha op-
3
tado por este para la implementación en EspINA ya que, como su nombre indica, tiene una
complejidad lineal y además demuestra producir resultados precisos cuando los parámetros
son calibrados correctamente.
1.6. Objetivos
Objetivo general
Del apartado anterior se puede concluir que el objetivo principal del proyecto será pro-
porcionar una herramienta que permita a usuarios dentro del ámbito de la medicina, y con-
cretamente dentro de la neurología, realizar de forma sencilla y eficiente la segmentación de
una imagen, para posteriormente visualizar o reutilizar los resultados.
Para llevarse a cabo este objetivo es necesario desglosarlo en partes más específicas:
Adaptar el algoritmo a las características específicas del entorno; Realizar una implemen-
tación en código funcional; Comprobar el correcto funcionamiento del algoritmo e imple-
mentación; Generar una interfaz que permita al usuario realizar la segmentación con los pa-
rámetros elegidos y posteriormente visualizarla; Optimizar el código una vez implementado
para reducir el uso de memoria, de disco y de CPU, y reducir los tiempos de ejecución.
Como es de esperar, estos objetivos no serán independientes y estarán fuertemente inter-
conectados. El cumplimiento de todos ellos será necesario para cumplir el objetivo general
de la implementación del algoritmo SLIC dentro de la herramienta EspINA.
Adaptación del algoritmo a las necesidades
Para poder realizar la implementación del algoritmo es necesario estudiar el algoritmo y el
entorno en el que se aplicará. Debido a las necesidades específicas de la herramienta EspINA
es necesario adecuar las operaciones a las características de las imágenes empleadas.
Estas imágenes, extraídas mediante microscopios electrónicos y confocales, son tridimen-
sionales y dispuestas en stacks (es decir, apiladas en capas o slices), de gran tamaño (llegando
a los 5GB y decenas de millones de voxels) y cuyos valores se encuentran dentro de la escala
de grises. Además estos stacks tridimensionales pueden tener diferente espaciado en cada una
de las dimensiones, es decir, los voxels que lo componen no serán necesariamente cubos y
debido a la forma de obtención de las imágenes las capas pueden no estar alineadas.
Estas características crean problemas y dificultades añadidas que requieren de una adap-
tación del algoritmo, que inicialmente fue propuesto para imágenes en espacio de color RGB,
de dos dimensiones, de tamaño de pixel regular y sin desplazamientos.
4
Implementación e integración del algoritmo
Este es quizás el objetivo más crítico y que más tiempo requiere. Dependerá del análisis
previo del anterior objetivo y principalmente consistirá en la codificación del algoritmo y la
integración con otras herramientas de EspINA.
Durante los primeros análisis del entorno y discusiones sobre el proyecto se decidió que
aunque SLICO es un algoritmo adecuado se implementarían también el algoritmo original
(SLIC) y la variante adaptativa (ASLIC), lo que añade más carga de trabajo a este objetivo.
Pruebas
Será necesario realizar pruebas que servirán tanto para asegurar el correcto funcionamien-
to del algoritmo y la implementación, como para hacer el análisis posterior de resultados y
formular conclusiones. Estas ejecuciones se realizarán con diferentes parámetros para ayudar
a definir los rangos de valores más óptimos para los parámetros.
Representación de resultados
La implementación debe integrarse en la interfaz de la aplicación, permitiendo al usuario
elegir los parámetros a utilizar durante la ejecución del algoritmo y visualizar el resultado. La
representación visual de resultados debe ser descriptiva para el usuario y generarse instantá-
neamente a partir de los resultados calculados durante la ejecución. Además será necesaria
para poder analizar de forma visual los resultados, realizar las distintas pruebas de funciona-
miento y formular conclusiones.
Esta representación se mostrará en la interfaz de la aplicación y deberá además incluir
controles para manipular los parámetros del algoritmo e iniciar su ejecución.
Optimizaciones
Uno de los objetivos más importantes tras implementar el algoritmo será el de optimizar la
implementación para reducir el uso de recursos lo máximo posible y, cuando no sea posible
reducirlos, equilibralos para proporcionar la mejor experiencia de usuario. Las principales
métricas a tener en cuenta para las optimizciones serán el tiempo de ejecución, el uso de
memoria y el espacio en disco empleado para el almacenamiento de resultados.
5
6
Capítulo 2
ANTECEDENTES
2.1. SLIC
SLIC es un algoritmo de clustering, descrito en el paper SLIC Superpixels Compared toState-of-the-Art Superpixel Methods[2] por R.Achanta, A. Shaji y K. Smith, con la función
de recibir un conjunto de pixels (una imagen) como entrada y devolver una salida en la que
dichos pixels están agrupados en base a ciertos requisitos y relación entre ellos. Es decir,
es una función que recibe pixels como entrada y devuelve agrupaciones de dichos pixels
como salida. Generalmente estos algoritmos reciben parámetros que determinarán su com-
portamiento. SLIC (Simple Linear Iterative Clustering)[2] es un algoritmo de agrupación de
pixels en función a una relación definida en el ámbito espacial y del espacio de color, lo que
significa que a la hora de seleccionar que pixels se agruparán utiliza tanto la distancia entre
dichos pixels en el espacio euclideo como la diferencia entre los colores que representan.
SLIC además es iterativo, lo que quiere decir que se ejecuta múltiples veces en cadena
produciendo cada vez resultados más precisos. A diferencia de otros algoritmos similares
SLIC es extremadamente rápido, ya que mientras otros algoritmos toman los pixels toda la
imagen como posibles candidatos para pertenecer a cada superpixel, SLIC utiliza únicamente
un área de tamaño definido alrededor de cada superpixel para definir dichos candidatos.
SLIC recibe dos parámetros para su ejecución: por un lado recibe ya sea un espaciado
entre superpixels, con lo que calculará el número de superpixels necesarios para cubrir todo el
área de la imagen, o un número de superpixels total, con lo que calculará sus posiciones para
distribuirlos en la superficie de la imagen; como segundo argumento recibe un parámetro de
tolerancia de color que se usará para calcular el peso que tiene la diferencia de color respecto
del peso que tendrá la distancia euclidea entre pixels. Estos parámetros también son utilizados
en las variantes SLIC y ASLIC, pero a continuación se explicarán las diferencias en su uso.
7
2.2. SLICO
SLICO (SLIC Zero-parameter) es la versión "sin parámetros"de SLIC. Se comporta de la
misma forma que SLIC con la diferencia de que al final de cada iteración recalcula el valor
del parámetro de distancia utilizado para calcular el peso que tendrá la distancia espacial
respecto de la distancia de color. El valor utilizado será diferente para cada superpixel y será
la distancia máxima a los pixels que conforman el superpixel. De esta forma los superpixels
podrán ser o más o menos compactos o irregulares en zonas donde los bordes sean más o
menos irregulares.
Para iniciar la ejecución de SLICO sólo es necesario definir la densidad o tamaño de los
superpixels y el peso de las distancias en el espacio de color.
2.3. ASLIC
Como ocurría con SLICO, en esta versión también se actualiza en cada iteración el pará-
metro de distancia máxima de cada superpixel. En este caso además se actualiza también el
parámetro de tolerancia de color utilizando la distancia de color máxima entre el centro del
superpixel y cada uno de los pixels que lo conforman. Con esta modificación ASLIC presenta
mejor adherencia a bordes cuando las imágenes son muy irregulares, ya que adapta sus pará-
metros a cada zona de la imagen de forma independiente. Para su ejecución sólo es necesario
aportar la densidad o tamaño de los superpixels, aunque puede proporcionarse un peso inicial
para la diferencia de color.
2.4. Otros algoritmos de segmentación
En SLIC Superpixels Compared to State-of-the-Art Superpixel Methods[2] se puede en-
contrar una recopilación de algoritmos y su comparación con SLIC en varios aspectos, cuyas
conclusiones serán resumidas en esta sección. Los algoritmos destacados son los siguientes:
2.4.1. Normalized Cuts - NC05
[10] Este algoritmo realiza particiones recursivas de un grafo generado a partir de los
pixels de la imagen teniendo en cuenta valores tanto de forma como de textura. Los resultados
son agrupaciones regulares, con la consecuencia de que no se adhieren a los bordes de la
imagen. Además se trata de un algoritmo de complejidad exponencial.
8
En la comparativa se muestra que los superpixels generados son muy compactos y con
muy poca adherencia a bordes. Es excesivamente lento y el memory footprint es tan alto que
provocó errores por falta de memoria durante las pruebas.
2.4.2. Graph-based Segmentation - GS04
[11] Este algoritmo genera agrupaciones en base a la generación de árboles de mínima
conectividad entre los nodos de un grafo. La ventaja respecto a NC05 es que no tiene comple-
jidad exponencial, pero el inconveniente es que aunque se alinea a los bordes de la imagen,
los resultados son formas demasiado irregulares.
En la comparativa muestra buena adherencia a los bordes, el que mejor adherencia de los
algoritmos analizados, pero genera superpixels muy irregulares. Además es rápido, pero la
alta irregularidad de los superpixels generados acentúa los problemas de baja segmentación
que tiene.
2.4.3. Seam Carving - SL08
[12] Este algoritmo utiliza una técnica similar al Seam Carving, un algoritmo utilizado
para reescalado de imágenes, para generar caminos óptimos en el grafo generado. La com-
plejidad es exponencial y además requiere de computación previa de los datos.
2.4.4. Quick Shift - QS08
[13] Este algoritmo, denominado Quick Shift, es el primero de los algoritmos descritos en
el paper previamente citado que no está basado en grafos. A pesar de tener buena adherencia a
los bordes de la imagen, su complejidad es exponencial y no admite parámetros para controlar
el tamaño o densidad de superpixels.
En la comparativa demuestra tener buena adherencia a bordes y no tener problemas de
baja segmentación. Por desgracia los tiempos de ejecución son muy altos, y los parámetros
que recibe son poco intuitivos y poco controlables. Además no asegura la conectividad en los
superpixels.
2.4.5. Watershed - WS91
El algoritmo Watershed[14] busca los mínimos de gradiente locales en la imagen que
utilizará como puntos desde los que seleccionará los pixels circundantes con gradiente as-
9
cendente, generando así agrupaciones de pixels. Esto produce superpixels irregulares y que
no tienen adherencia a los bordes, pero con tiempos de ejecución relativamente rápidos. No
permite controlar la densidad de los superpixels.
2.4.6. Turbopixel - TP09
[15] El algoritmo Turbopixel selecciona pixels en posiciones iniciales y posteriormen-
te extiende estas selecciones usando el flujo de gradiente. Produce superpixels distribuidos
regularmente y con tamaños regulares. A pesar de tener complejidad lineal es uno de los
algoritmos más lentos entre los listados y presenta una pobre adherencia a los bordes de la
imagen.
En la comparativa se muestra como el algoritmo más lento, empatado con NC05, y mos-
trando una de las peores adherencias a bordes de entre los algoritmos analizados. Comparado
con SLIC, bajo las condiciones del experimento, los tiempos de ejecucion fueron 100 ve-
ces mayores. Sus puntos a favor son que los superpixels generados son muy compactos y
regulares.
10
Capítulo 3
DESARROLLO
3.1. Análisis de requisitos
El primer paso en el desarrollo del proyecto fue un análisis de las necesidades, situación
actual y objetivos.
Para establecer las necesidades del proyecto es necesario conocer la situación y los ob-
jetivos. El procedimiento más lógico sería un acercamiento a la herramienta EspINA y sus
componentes, así como del algoritmo que será implementado, SLIC. Tanto el análisis del en-
torno y estado actual como los objetivos pueden encontrarse en el capítulo 1 Introducción yobjetivos y el capítulo 2 Antecedentes de este documento, respectivamente.
Las necesidades coinciden en gran medida con los objetivos propuestos. Por un lado es
necesario estudiar y adaptar el algoritmo para facilitar su implementación en la herramienta.
Por otro lado es necesario conocer el funcionamiento básico de EspINA y de sus librerías
para poder realizar las modificaciones necesarias. Tratándose de librerías tan importantes
y extensas no es posible estudiarlas completamente, por lo que deberá ir consultándose la
documentación progresivamente en función de las necesidades específicas surgidas en cada
momento. Además es necesario estudiar el lenguaje de programación utilizado en el proyecto,
C++. Para condensar la adquisición de estos conocimientos se realizó un proyecto paralelo
llamado BSVC Qt[16], un pequeño proyecto open-source consistente en la modificación de
BSVC[17], un simulador de Motorola 68000 (programado en C), y la adición de una interfaz
de usuario desarrollada en Qt.
11
3.2. Preparación del entorno
Una de las mayores dificultades encontradas durante el desarrollo del proyecto fue durante
la preparación del entorno de desarrollo. EspINA es una herramienta desarrollada principal-
mente en y para sistemas operativos Linux. Aunque es posible su compilación y ejecución en
sistemas operativos Windows, no se dispone de instrucciones para la preparación del entorno
ni información exacta de compatibilidad.
En un primer intento se utilizó el IDE Visual Studio 2017 junto con el compilador de Mi-
crosoft. El primer obstáculo fue la compilación de las librerías de las que EspINA depende.
Algunas de ellas incluían proyectos para versiones antiguas de Visual Studio que tras peque-
ñas modificaciones sirvieron para compilarlos en la versión actual, pero otros sólo incluían
scripts de autoconfiguración que requerían el uso de un entorno *nix y para los que fue ne-
cesaria la instalación del entorno MSYS[18] junto con MinGW[19] (Minimalistic GNU for
Windows). A pesar de haberse compilado todas las librerías correctamente en Visual Studio,
a la hora de compilar la aplicación EspINA surgieron errores de compilación. Algunos de
ellos fueron solucionables con pequeñas modificaciones de código pero algunas secciones de
código dependían del uso del compilador GCC y no se podrían solucionar sin una gran rees-
critura de partes básicas de la aplicación, por lo que finalmente se descartó el uso de Visual
Studio como compilador.
Para poder iniciar el desarrollo del proyecto sin más demoras innecesarias se procedió a la
compilación del proyecto en el entorno WSL[20] (Windows Subsystem for Linux) incluído
en Windows 10 utilizando MinGW como cross-compiler, produciendo binarios para su eje-
cución en Windows. Este método tampoco dio resultados satisfactorios por lo que finalmente
la compilación se realizó para Linux siendo ejecutados los binarios en el propio WSL. Para
poder visualizar la interfaz en el entorno Windows se empleó Xming[21], el servidor de X
Window System. Debido a los problemas de rendimiento ocasionados por la ineficiencia en
las operaciones de I/O (Input/Output) en WSL y por el uso de Xming, este método tampoco
proporcionaba un entorno de desarrollo óptimo y tuvo que ser descartado.
Finalmente se probaron diversas versiones de GCC proporcionadas por MinGW para rea-
lizar una compilación en Windows dentro del entorno MSYS. Surgieron nuevos problemas
dependiendo de las versiones utilizadas tanto de GCC como de las librerías a compilar, entre
los que se destaca la incompatibilidad del MOC de Qt4 con las macros de las librerías de
Boost, que requirieron tiempo para localizar y solucionarse. Concretamente esa incompatibi-
lidad entre Boost y Qt sólo ocurre en versiones de Qt previas a la versión 5 al ser compiladas
las librerías con la implementación de GCC de MinGW y su solución requiere localizar to-
dos los usos de la macro conflictiva y añadir una directiva de compilador que las excluya
durante el procesado de MOC. Una vez compiladas todas las librerías con GCC se pudo
compilar posteriormente la herramienta EspINA y ejecutarse nativamente en Windows. La
compilación debe realizarse a través de scripts Makefile generados por CMake. A pesar de
12
que Visual Studio ahora incluya soporte para la compilación a través de este tipo de scripts, se
optó por desarrollar en el IDE Eclipse para mantener consistencia en el uso de herramientas
dentro del equipo de desarrollo.
3.3. Adaptación de SLIC
Descripción del algoritmo
La implementación descrita en el paper original es simple. Se inicializa el algoritmo con
dos parámetros que actuarán como pesos para el cálculo de la distancia total a partir de la
distancia espacial y de color. Esta distancia total, combinación de ambas distancias, será la
que dictamine la distancia de un pixel a los superpixels circundantes, asignándose el pixel
al cluster con menor distancia total. Además se establece un número máximo de iteraciones
y opcionalmente un parámetro de tolerancia que permitirá terminar la ejecución antes de
cumplir las interaciones.
El primer parámetro, la distancia entre superpixels, puede ser también el número de su-
perpixels deseado y a partir de él calcular la distancia entre ellos para distribuirlos equidistan-
temente en la imagen. Este parámetro influirá en el peso que tiene la distancia euclidea entre
el superpixel y los pixels candidatos al calcular la distancia total. Usando el parámetro de
distancia entre clusters o el de densidad de clusters se generan los superpixels en los puntos
correspondientes de la imagen, convirtiéndose dichos puntos en los centros de los respectivos
supervoxels. Para evitar que un cluster se inicie en un borde se calcula el gradiente en un área
de 3x3 alrededor de este pixel y se desplaza este centro al pixel con menor gradiente. Una
vez definidos todos los superpixels y sus centros se puede proceder a agrupar los pixels.
El segundo parámetro corresponde al peso que tendrá la diferencia de color entre el super-
pixel y los pixels candidatos. Una vez calculadas ambas distancias y aplicados los pesos estas
se suman para obtener la mencionada distancia total. Para cada pixel se realiza este cálculo
con respecto a todos los superpixels circundantes que se encuentren dentro del rango de posi-
bles candidatos. El paper define que la distancia máxima entre un pixel y su supercuster será
como mucho dos veces la distancia entre superpixels. Es decir, dos veces el valor del primer
parámetro que recibe el algoritmo. Esto es equivalente a que cada superpixel tenga un rango
máximo de dos veces la distancia entre superpixels y que cada superpixel compruebe todos
los pixels en ese área para comprobar si pertenecen o no a él. Al estar limitada esta distancia
de búsqueda se evita que el aumento del tamaño de imagen incremente de forma exponencial
los tiempos de ejecución ya que no es necesario comprobar para cada superpixel la perte-
nencia de todos los pixels de la imagen, sólo los de su región. Esta es la característica que
convierte a SLIC en un algoritmo de complejidad lineal y lo que le permite ofrecer tiempos
de ejecución tan rápidos comparado con otros algoritmos similares.
13
Una vez asignados los pixels a sus clusters correspondientes se finaliza la iteración y se
recalcula el valor medio de cada cluster tanto de color como de posición. Así se obtiene el
color del supervoxel y su centro, que será empleado en los cálculos de la siguiente iteración.
Este proceso se repetirá tantas veces como iteraciones se hayan establecido, o hasta que se
cumpla para todos los clusters que el desplazamiento entre la posición inicial del centro de
cada cluster y la nueva posición calculada sea menor a la tolerancia, es decir, ninguno se haya
desplazado más distancia que la definida por la tolerancia.
Terminada la ejecución cada uno de los supervoxels habrá sido asignado a un cluster,
pero este algoritmo no asegura conectividad y quedarán pixels huérfanos no conectados a
su cluster por lo que deberá utilizarse un algoritmo de conectividad para agruparlos en los
clusters contiguos si quieren obtenerse volúmenes continuos para cada supervoxel.
Definición del algoritmo
Desde un punto de vista más matemático y técnico la descripción del algoritmo puede
traducirse a pseudocódigo y operaciones que facilitarán su posterior implementación.
1: Crear clusters (labels) Ck = [lk, ak, bk, xk, yk]T a intervalos definidos por S.
2: Centrar los clusters en el pixel de menor gradiente en un área de 3× 3.
3: label l(i) = −1 para cada pixel i4: distancia d(i) = ∞ para cada pixel i.5: repeat6: for cada centro de cluster Ck do7: for cada pixel i en un área 2S × 2S alrededor de Ck do8: Calcular distancia D entre Ck y i.9: if D < d(i) then
10: d(i) = D11: l(i) = k
12: Recalcular centros de clusters.
13: Calcular error residual E (desplazamientos).
14: until E ≤ tolerancia
Figura 3.1: Pseudocódigo algoritmo SLIC
Como se puede apreciar en el pseudocódigo de la figura 3.1, extraído del paper original,
cada cluster se puede definir como un vector cuyas componentes son la unificación de los
vectores que definen la posición y el color. En este caso se utiliza un espacio euclideo bi-
dimensional y el espacio de color CIELab[22]. Los clusters se encuentran posicionados en
intervalos de distancia S, que corresponde al parámetro pasado al algoritmo como tamaño de
supervoxel.
14
Para los propósitos de EspINA se emplean un espacio euclideo tridimensional en lugar de
bidimensional y un espacio de color de una sola dimensión de luminosidad. Su equivalencia
es directa a la luminosidad en el espacio CIELab, simplemente es necesario normalizar el
valor ya que la luminosidad en CIELab tiene un rango de valores de 0 a 100 y en escala de
grises tiene un rango de valores de 0 a 255.
En el paper se describen además las diferencias entre SLIC y las variantes ASLIC y
SLICO. Estas se reducen únicamente a que cada cluster mantendrá valores propios para los
pesos de la distancia espacial en el caso de SLIC, y de distancia espacial y de color en el caso
de ASLIC. Estos valores se actualizarán en cada iteración con las diferencias máximas en
distancia espacial o de color entre los pixels pertenecientes al cluster y permitirán que cada
cluster sea más o menos compacto dependiendo de las variaciones de color en la zona.
Aplicando las modificaciones necesarias al algoritmo obtenemos el pseudocódigo que
posteriormente se ha implementado.
1: Crear clusters (labels) Ck = [lk, xk, yk,msk,mck]T a intervalos definidos por S.
2: Centrar los clusters en el pixel de menor gradiente en un área de 3× 3.
3: label l(i) = −1 para cada pixel i4: distancia d(i) = ∞ para cada pixel i.5: repeat6: for cada centro de cluster Ck do7: for cada pixel i en un área 2S × 2S alrededor de Ck do8: Calcular distancia D entre Ck y i.9: if D < d(i) then
10: d(i) = D11: l(i) = k
12: Recalcular centros de clusters.
13: Actualizar ms (SLICO/ASLIC) y mc (ASLIC) para cada cluster.
14: Calcular error residual E (desplazamientos).
15: until E ≤ tolerancia
Figura 3.2: Pseudocódigo algoritmo SLIC adaptado
En el pseudocódigo adaptado de la figura 3.2 los clusters incluirán sólo la información del
canal de luminosidad pero almacenarán una dimensión espacial más y los valores propios de
sus pesos. ms hará referencia a la distancia espacial máxima y mc a la distancia de color má-
xima observada dentro de cada cluster. Al pasar a un espacio tridimensional la terminología
pasará a ser voxels en lugar de pixels y supervoxels en lugar de superpixels.
Habiendo definido el algoritmo sólo queda definir las operaciones para calcular la distan-
cia D entre dos pixels o voxels en este caso. En la ecuación 3.1 se muestran los cálculos de la
distancia espacial y de color, y la aplicación de los pesos a cada una de ellas para el cálculo
15
de la distancia total. En la ecuación 3.2 se muestra la misma ecuación simplificada.
dc =√
(lj − li)2 + (aj − ai)2 + (bj − bi)2
ds =√
(xj − xi)2 + (yj − yi)2
D′ =
√(dcNc
)2 + (dsNs
)2
(3.1)
El valor de Ns corresponderá al parámetro inicial S que define la distancia entre clusters.
Este será actualizado tras cada iteración en SLICO y ASLIC y tomará el valor de la distan-
cia espacial máxima entre voxels de cada cluster. El valor de Nc corresponderá al parámetro
inicial que determina el peso de la diferencia de color. Este podrá tomar valores en el rango
[1,40]. Su valor se actualizará cada iteración en ASLIC con la máxima diferencia de color
entre los supervoxels de cada cluster. En SLIC los valores tanto de Ns como de Nc perma-
necerán constantes. En ASLIC y SLIC los valores corresponderán a los parámetros iniciales
durante la primera iteración y a los valores calculados en la iteración previa, ms y mc, durante
las siguientes iteraciones.
D =
√d2c + (
dsNs
)2N2c (3.2)
La adaptación de estas ecuaciones a las dimensiones de las imágenes de espina es sencilla.
Las operaciones modificadas pueden verse en la ecuación 3.3. La ecuación simplificada usada
en la implementación puede verse en la ecuación 3.4.
dc =√
(lj − li)2 = lj − li
ds =√
(xj − xi)2 + (yj − yi)2 + (zj − zi)2
D′ =
√(dcNc
)2 + (dsNs
)2
(3.3)
Rápidamente puede verse que la distancia de color, al tener una sola componente, pue-
de simplificarse cancelándose la raíz con la potencia. Esto simplificará posteriormente los
cálculos durante la implementación. En el resto de la ecuación no hay más cambios, salvo
una componente extra en el cálculo de la distancia euclidea.
16
D =
√d2c + (
dsNs
)2N2c
=
√(lj − li)2 + d2s(
Nc
Ns
)2(3.4)
La ecuación simplificada permitirá durante la implementación evitar divisiones innecesa-
rias al calcularse el factor únicamente una vez por cluster y después aplicarse a través de una
multiplicación.
3.4. Implementación
El punto de partida se decidió que fuese la creación de una extensión, llamada StackS-
LIC, dentro de la aplicación. Esta extensión se aplica a un stack o imagen tridimensional y
almacena la información relativa al algoritmo pudiendo ser accedida desde otras extensiones
y módulos dentro de EspINA. La extensión proporciona funciones para acceder a la informa-
ción del estado del cómputo del algoritmo y para iniciar o detener su ejecución. El código
fuente de esta extensión se puede encontrar en el repositorio de EspINA, actualmente bajo la
rama de desarrollo feature/SLIC.
Siguiendo el pseudocódigo de la sección anterior implementar una versión básica del
algoritmo no es complicado, pero debido a las características de las imágenes empleadas en
EspINA hay que hacer cambios importantes en la implementación que complican la labor
y son una fuente de errores y problemas. Estas dificultades y sus soluciones se explican
brevemente a continuación.
Para tratar con el desplazamiento de slices se emplea una de las extensiones de EspINA,
ChannelEdges, que calcula qué región de cada slice corresponde a imagen y cuál a márgenes
externos. Los márgenes son parte de la información de la imagen pero deben ser ignorados
al procesar la imagen. Estos desplazamientos provocan que la imagen no esté definida por
un prisma rectangular y complica el posicionamiento de centros y el cálculo de las zonas de
búsqueda. Por suerte la extensión ChannelEdges simplifica la labor en gran medida, pudien-
do dividirse el área de búsqueda (cúbica) en slices y reajustando el área a utilizar en cada
slice mediante la extensión. Otra de las peculiaridades de estas imágenes es el escalado inde-
pendiente en cada uno de los ejes. Al no ser necesariamente cúbicos los voxels es necesario
tenerlo en cuenta a la hora de calcular las distancias tanto de búsqueda como las necesarias
para operar durante los cálculos del algoritmo. Por este motivo es neceario aplicar el escalado
a todas las operaciones. Estas han sido las principales complicaciones a la hora de adaptar e
integrar el algoritmo.
17
Durante la implementación se han tenido que tomar decisiones como pueden ser el tama-
ño de variables a utilizar o la información almacenada en memoria durante la ejecución. En
un principio, siguiendo la definición original del algoritmo, se almacenó para cada voxel el
cluster (label) al que pertenece y la distancia calculada a dicho cluster. Esta distancia se com-
pararía con la distancia calculada a otros clusters candidatos en cada iteración. Al trabajarse
con imágenes en escala de grises cuyos valores se almacenan en un char, cada voxel de la
imagen original corresponde a un byte de información. El tamaño de las imágenes empleadas
en EspINA requiere de un límite alto en el número de supervoxels máximos. Esto supone
necesitar una variable de tipo unsigned int (4 bytes) para almacenar el supervoxel al que per-
tenece cada voxel. Para almacenar la distancia es necesario una variable de tipo double (8
bytes) o reducir la precisión y usar el tipo float (4 bytes).
De los cálculos anteriores se extrae que para cada byte de información, correspondiente
al valor de luminosidad de cada voxel, de la imagen original son necesarios al menos 8 ó 12
bytes de información en memoria. Como se podía esperar esta implementación causó proble-
mas de falta de memoria y fue completamente inviable. Para reducir el impacto en memoria
de la ejecución se valoraron dos opciones: Utilizar un mapa de memoria sacrificando rendi-
miento al tener que hacer lecturas y escrituras constantes en disco, o reducir la información
almacenada para cada voxel. Se optó por la segunda opción, almacenando solamente el su-
pervoxel al que pertenece cada voxel y recalculando la distancia cuando fuese necesaria para
realizar comparaciones. Este cambio permite que el algoritmo pueda ejecutarse incluso con
las imágenes de mayor tamaño, aunque el uso de memoria para la ejecución del algoritmo
sigue siendo aproximadamente cuatro veces el tamaño de la imagen original. No se ha en-
contrado ninguna forma de reducirlo salvo usar distintos tamaños de variable dependiendo
del número de supervoxels generados, pero este cambio sólo beneficia a imágenes de muy
pequeña resolución o tamaño. Las imágenes de gran tamaño son las más afectadas por el uso
de memoria y seguirían necesitando 4 bytes para identificar el cluster.
La integración con la herramienta se ha realizado a través de una tab (pestaña) en uno
de los dialogs de la aplicación destinado a la información específica del stack y las extensio-
nes. Para evitar el bloqueo de la interfaz se genera una Task específica para la ejecución del
algoritmo y mediante eventos se informa del progreso al resto de módulos de la aplicación.
El progreso es mostrado en la interfaz específica de SLIC además del listado de progreso de
tareas propio de EspINA.
Terminado el procesamiento se puede descartar toda la información en memoria que ya
no sea necesaria, pero el grueso de la información debe ser almacenado ya que corresponde a
los datos de color y posición de cada supervoxel y el cluster asignado a cada voxel. Para poder
manipular estos datos ha sido necesario comprimirlos siguiendo el método detallado al final
de este capítulo. En la propia extensión se proporcionan métodos para acceder a estos datos y
generar una representación de una slice como un ImageData de ITK, que será empleado para
dibujar la vista previa en la interfaz de usuario.
18
En etapas finales de codificación se ha refactorizado el código para modularizarlo en la
medida de lo posible y se ha añadido soporte para la ejecución del algoritmo sólo en regiones
específicas de la imagen. Esta última característica, aunque soportada, aún no está disponible
al momento de la publicación de este documento ya que es necesario integrar el sistema de
ROI (Regions of Interest) de EspINA para utilizar como parámetros estas regiones.
3.4.1. Interfaz
La interfaz es sencilla, mostrando por un lado controles para la manipulación y ejecución
del algoritmo y por otro una previsualización del stack actualmente cargado con una super-
posición de los resultados de la última ejecución de SLIC, en casos de existir, o un mensaje
indicando que es necesario ejecutar primero el algoritmo.
Los controles están agrupados por finalidad, como puede verse en la figura 3.4.1. En la
parte superior del panel de controles se encuentran los destinados a la manipulación de pará-
metros de ejecución, permitiendo seleccionar el tipo de algoritmo a ejecutar mediante radio
buttons, y de alterar los parámetros iniciales de la ejecución y las condiciones de finalización.
Los valores iniciales de los controles serán los correspondientes a la última ejecución del
algoritmo, o en caso de no haberse ejecutado previamente serán los siguientes valores por
defecto: Algoritmo SLIC, Supervoxels de tamaño 10x10x10, peso de color 20, iteraciones
máximas 10 y tolerancia 0 (desactivada). Los controles limitan los valores de cada parámetro
al rango de valores válidos, que son de 10 a 254 para el tamaño de supervoxel, 1 a 40 para el
peso de color, 2 a 40 iteraciones y 0 a 10 para la tolerancia.
Los controles de la vista previa permiten seleccionar el modo de representación de resul-
tados, pudiendo elegir entre la representación de los supervoxels por su media de color o por
colores aleatorios, y alterar la opacidad de la capa de resultados superpuesta sobre el stack
original. También se muestran los resultados de la última ejecución y el estado actual, junto
con una barra de progreso de la ejecución en curso. Además se puede iniciar o detener la
ejecución del algoritmo a través de los dos botones dispuestos en la parte inferior del panel.
La vista previa muestra el stack original y una superposición con los resultados calculados
en la última ejecución del algoritmo. Esta superposición, como se mencionaba anteriormente,
tiene un valor de opacidad ajustable para facilitar la visualización y comparación de resulta-
dos. Los resultados son una representación sólida del color medio de cada supervoxel en la
región que ocupa en el slice, pudiéndose alternar a una representación por colores aleatorios
que permitan distinguir los límites de dos supervoxels próximos con color similar. Además
se representan los centros de supervoxels mediante pequeñas cruces en las capas en las que
se encuentren dichos centros. Estos centros sólo se muestran en la capa correspondiente a su
posición en el eje Z, por lo que al encontrarnos en un entorno tridimensional no todas las
capas mostrarán centros y no todos los supervoxels tendrán un centro dibujado en cada capa.
19
Figura 3.3: Interfaz extensión SLIC
20
3.4.2. Compresión de resultados
Los resultados de uso de memoria y disco obtenidos durante la implementación hacían
casi inviable el tratamiento de los datos directamente en memoria. Después de valorarse múl-
tiples opciones se optó por añadir una compresión simple a los datos que permitiese alma-
cenarlos comprimidos en memoria, y descomprimir y recuperar datos de secciones y slices
on-the-fly, necesario para poder generar la previsualización de resultados. Este método se ha
preferido sobre mantener la información en disco sin compresión.
La compresión elegida ha sido RLE (Run Length Encoding), almacenándose para cada
fila de la imagen el supervoxel y la cuenta de voxels que pertenecen a dicho supervoxel,
secuencialmente. La información se almacena en memoria en un QByteArray, pudiendo ser
escrito directamente a disco para recuperarse en sesiones posteriores. Por limitaciones de la
implementación del QByteArray este sólo admite un máximo de 1GB de datos, por lo que el
guardado se realiza en un QByeArray por cada slice, permitiendo acceder a ellas de forma
independiente y descomprimir cada una de ellas cuando sea necesario.
Los motivos para elegir esta compresión son que se trata de un algoritmo sencillo, de
fácil implementación y que permite reconstruir los datos originales eficiente y rápidamente.
Se han barajado otras alternativas, como es el uso de librerías de compresión lossless, pero al
escapar del ámbito de este proyecto se han descartado en esta primera iteración y propuesto
como futuras mejoras sobre el proyecto.
3.4.3. Optimizaciones
Como ya se ha mencionado previamente, han sido necesarias algunas optimizaciones
respecto al algoritmo original. La más destacable corresponde a la reducción de la memoria
necesaria mediante el recálculo de la distancia entre un voxel y su supervoxel en lugar de
almacenarla, siendo una optimización necesaria para que sea posible la ejecución en imágenes
de tamaño medio o grande. Además ha sido necesaria la compresión en memoria de los
resultados para poder reducir el impacto en memoria a la hora de manipular los resultados.
Para aumentar la eficiencia, las operaciones para el cálculo de distancias se han realizado
evitando el uso de raíces cuadradas todo lo posible dentro de los bucles. Las comparaciones
de distancias se realizan entre las distancias cuadradas y sólo al final de la iteración se calcula
la raíz de la distancia máxima encontrada en cada supervoxel para actualizar el parámetro
para la siguiente iteración. Además el cálculo del factor de ajuste en la suma de la distancia
espacial y de color se realiza solamente una vez por supervoxel, evitando divisiones y usando
una multiplicación en su lugar.
Otras optimizaciones propuestas pero no implementadas corresponden a la paralelización
de las operaciones que puedan realizarse en varios threads y el uso de instrucciones AVX
21
para realizar múltiples operaciones por ciclo. Al no ser parte de los objetivos del proyecto no
se han implementado, pero se han propuesto como posibles mejoras futuras.
22
Capítulo 4
RESULTADOS Y PRUEBAS
4.1. Entorno de Pruebas
Todas las pruebas de ejecución se han realizado en un mismo equipo de escritorio cuyas
especificaciones se describen en la tabla 4.1.
Nombre Información
CPU i7-8700K 6 cores @ 5GHz, 12 threads
Memoria G.SKill TridentZ 16GB 3200MHz DDR4 CL14
Disco duro Seagate Barracuda 7200rpm, rev. 14
Sistema Operativo Windows 10 Spring Creators Update (1803)
Tabla 4.1: Especificaciones del equipo de pruebas
A excepción de una de las pruebas, que se ha realizado para medir los tiempos de ejecu-
ción y uso de memoria en imágenes de tamaños extremos, el resto de pruebas se han realizado
sobre una imagen de pequeño tamaño que servirá para realizar múltiples ejecuciones y pos-
teriormente analizar y comparar los resultados obtenidos en cada una de las pruebas. Para
distinguir ambas imágenes el documento se referirá a ellas como grande y peque respecti-
vamente. Ambas son imágenes en escala de grises. Las características de cada una de las
imágenes pueden encontrarse en la tabla 4.2.
En el caso de peque se realizarán pruebas para las tres variantes del algoritmo con 12
conjuntos diferentes de parámetros, haciendo un total de 48 pruebas. Para facilitar la com-
prensión de los resultados se utilizará la siguiente nomenclatura para las pruebas: Primero
una inicial para el tipo de algoritmo, S, O, A, para SLIC, SLICO y ASLIC respectivamente;
después un número que indicará el valor del parámetro de tamaño de supervoxel; a conti-
nuación un guión (’-’) que actuará de separador; por último un número que indicará el valor
23
Grande Peque
Nombre original w35-15-L3-1-003-365-rigid peque
Formato TIF RAW
Tamaño 1.84GB 41MB
Profundidad de color 8 bits 8 bits
Ancho 2452 699
Alto 2232 536
Profundidad 363 115
Espaciado (X/Y/Z) 1/1/1 1/1/2
Desplazamientos Sí No
Tabla 4.2: Especificaciones de las imágenes de prueba
del parámetro del peso de la diferencia de color. En la tabla 4.3 se puede observar la lista de
pruebas con sus parámetros y su referencia.
Todas las pruebas utilizarán un máximo de 10 iteraciones y no se establecerá una tole-
rancia. La decisión de utilizar 10 iteraciones corresponde a la recomendación de los autores
originales del algoritmo que consideran que es el número suficiente para conseguir resultados
óptimos y a partir del cual las ganancias son mínimas.
4.2. Resultados
Debido al alto número de pruebas realizadas, los resultados más relevantes para cada
ejecución se mostrarán en formato tabular para una mejor comprensión y acceso a la infor-
mación. Estos datos se pueden ver en la tabla 4.3. En dicha tabla se muestra la referencia
asignada a cada prueba junto con sus parámetros de entrada, el tiempo de ejecución del algo-
ritmo en segundos, el máximo uso de memoria de la aplicación (no sólo el algoritmo) durante
la ejecución y el uso de memoria/disco de los datos tras la compresión RLE. Para añadir con-
texto a los valores de uso de memoria, la aplicación EspINA tiene un uso de memoria de
~70MB antes de cargar ninguna imagen, aumentando a ~150MB (2350MB para grande) una
vez cargada la imagen utilizada en las pruebas.
24
4.2.1. Informe de resultados
Parámetros Resultados
Referencia AlgoritmoDim.
cluster
Peso
colorClusters
Tiempo
(s)
RAM
(MB)
Disco
(MB)
S10-10 SLIC 10 10 83160 922 350 80
S15-10 SLIC 15 10 27072 821 348 75
S20-10 SLIC 20 10 10395 669 348 68
S30-10 SLIC 30 10 2898 562 345 61
S10-20 SLIC 10 20 83160 973 357 55
S15-20 SLIC 15 20 27072 832 349 50
S20-20 SLIC 20 20 10395 675 348 46
S30-20 SLIC 30 20 2898 559 346 43
S10-30 SLIC 10 30 83160 965 352 44
S15-30 SLIC 15 30 27072 830 349 37
S20-30 SLIC 20 30 10395 650 347 32
S30-30 SLIC 30 30 2898 584 348 29
S10-40 SLIC 10 40 83160 970 349 39
S15-40 SLIC 15 40 27072 832 348 30
S20-40 SLIC 20 40 10395 657 346 25
S30-40 SLIC 30 40 2898 570 345 21
O10-10 SLICO 10 10 83160 911 348 93
O15-10 SLICO 15 10 27072 807 359 88
O20-10 SLICO 20 10 10395 659 347 79
O30-10 SLICO 30 10 2898 554 348 69
O10-20 SLICO 10 20 83160 956 362 68
O15-20 SLICO 15 20 27072 831 339 66
O20-20 SLICO 20 20 10395 668 351 62
O30-20 SLICO 30 20 2898 542 348 57
O10-30 SLICO 10 30 83160 967 346 49
O15-30 SLICO 15 30 27072 818 349 47
O20-30 SLICO 20 30 10395 678 348 45
O30-30 SLICO 30 30 2898 560 352 44
O10-40 SLICO 10 40 83160 941 349 40
O15-40 SLICO 15 40 27072 830 348 33
O20-40 SLICO 20 40 10395 664 346 31
O30-40 SLICO 30 40 2898 574 351 30
A10-10 ASLIC 10 10 83160 920 350 86
A15-10 ASLIC 15 10 27072 852 347 81
A20-10 ASLIC 20 10 10395 645 348 74
25
A30-10 ASLIC 30 10 2898 582 347 65
A10-20 ASLIC 10 20 83160 982 339 86
A15-20 ASLIC 15 20 27072 836 347 82
A20-20 ASLIC 20 20 10395 632 347 74
A30-20 ASLIC 30 20 2898 540 346 66
A10-30 ASLIC 10 30 83160 934 348 87
A15-30 ASLIC 15 30 27072 812 346 82
A20-30 ASLIC 20 30 10395 649 351 75
A30-30 ASLIC 30 30 2898 578 348 66
A10-40 ASLIC 10 40 83160 921 347 87
A15-40 ASLIC 15 40 27072 832 349 82
A20-40 ASLIC 20 40 10395 644 347 75
A30-40 ASLIC 30 40 2898 582 348 67
Grande SLIC 10 20 1131500 23157 6740 1670
Tabla 4.3: Referencia de pruebas y resultados
En el caso de la ejecución sobre grande el algoritmo empleado ha sido SLIC y los pará-
metros con sus valores por defecto. Esta ejecución permitirá comparar las diferencias en el
tiempo de ejecución respecto del tamaño de la imagen y asegurar que el comportamiento del
algoritmo es el correcto en imágenes de gran tamaño. Los detalles de esta ejecución pueden
encontrarse al final de la tabla 4.3.
4.2.2. Observaciones
Además de los datos mostrados en la sección anterior existen resultados visuales que para
los propósitos de este proyecto serán valorados de forma subjetiva. A raíz de estas observacio-
nes se concluirán los valores más adecuados para uso en imágenes similares a la empleada en
las pruebas y el efecto que los distintos parámetros tienen en los resultados. Sólo se mostrarán
capturas de algunos de los resultados ya que mostrarlos para todas las pruebas se extendería
en exceso.
A partir de los resultados mostrados en la tabla 4.3 se puede concluir que el uso de las
variantes SLIC o ASLIC no tienen ningún impacto sustancial en el tiempo de ejecución,
confirmando las afirmaciones hechas por los autores del algoritmo en su paper original. Sí
que puede observarse una reducción en el tiempo de ejecución al aumentar el tamaño de
supervoxel, con la consecuente reducción en el número de clusters generados. El parámetro
de peso del color no tiene ningún efecto sobre los tiempos de ejecución, siendo únicamente
el tamaño de supervoxel el que influye en los tiempos.
26
Al comparar los tiempos de ejecución de la ejecución de grande con la ejecución equiva-
lente en parámetros de peque, S10-20, se observa el comportamiento lineal del algoritmo: El
aumento en el volumen total de la imagen aumenta linealmente el tiempo de ejecución. En el
caso de grande se aprecia que incluso con el menor tamaño posible de supervoxel el número
de clusters es relativamente reducido. De un total de 1.986.649.632 voxels se han obtenido
1.131.500 supervoxels, una reducción de al menos 3 órdenes de magnitud. Siendo una de las
motivaciones para incluir este algoritmo en EspINA la posibilidad de utilizarlo para reducir
la entrada de datos en algoritmos basados en grafos, claramente este aspecto se cumple posi-
tivamente. El uso de memoria es elevado, pero acorde a los valores esperados y teorizados en
el apartado de implementación.
Volviendo a las ejecuciones sobre peque, el uso de memoria apenas varía entre ejecucio-
nes ya que los datos almacenados en memoria corresponden en casi su totalidad a la infor-
mación relativa a los clusters a los que pertenece cada voxel. Las variaciones son causadas
por la diferencia en el número de supervoxels (que al ser un pequeño número en comparación
con el número de voxels no tienen demasiada relevancia) y en aspectos técnicos propios de
EspINA e ITK y su manejo de imágenes en memoria.
En cuanto al uso de memoria y disco una vez comprimidos los resultados, se observan
resultados de aproximadamente un 20-60 % del tamaño descomprimido dependiendo de los
parámetros y algoritmo. Previamente se había calculado y comprobado que los datos nece-
sarios para el algoritmo equivalían a aproximadamente 4 veces el tamaño de los datos de la
imagen original, por lo que una vez realizada la compresión el uso en disco y memoria del
algoritmo pasa a ser entre un 50 % y un 200 % del tamaño original de la imagen. La compre-
sión es mayor según aumenta el tamaño de supervoxel. La irregularidad en los supervoxels
también tiene un efecto perceptible en la eficiencia de la compresión RLE, afectando muy
negativamente a la compresión en los resultados de ASLIC y SLICO. Esta compresión ha
sido suficiente para la realización de las pruebas pero tendrá que ser sustituida por un método
más eficiente en el futuro para que sea aceptable para casos de uso reales.
En el aspecto visual se pueden ver las diferencias entre el algoritmo SLIC, ASLIC y SLI-
CO en la figura 4.1. SLIC presenta supervoxels más regulares a lo largo de toda la imagen,
mientras que SLICO y ASLIC parecen ajustarse mejor a los bordes y formas en zonas menos
homogéneas. De entre estos dos últimos los mejores resultados parece proporcionarlos SLI-
CO al producir clusters ajustados a bordes pero más regulares que ASLIC, por lo que será el
algoritmo recomendado para uso en EspINA.
Cuando se hace una comparación de resultados entre diferentes valores en el parámetro
del peso asignado a la diferencia de colores se puede observar que tiene un gran efecto en
SLIC o SLICO pero que, como era de esperar ya que se reajusta en cada iteración, apenas
tiene un efecto en los resultados de ASLIC. En SLIC o SLICO se admite un rango de valores
para este parámetro de 1 a 40, pero en las muestras observadas parecen conseguirse buenos
resultados con un valor intermedio, de 20, que evita dar un peso demasiado alto o bajo a las
27
Figura 4.1: Comparación S10-20, O10-20 y A10-20
28
Figura 4.2: Comparación de tamaño de supervoxel O10-20 y O20-20
variaciones de color respecto a las distancias euclideas en zonas de la imagen que tengan
mucha o poca variación de color. En la figura 4.3 se pueden comprobar las diferencias entre
un valor de 10 y de 30 en los tres algoritmos y el efecto que tiene sobre los supervoxels.
El valor óptimo de este parámetro dependerá de la imagen a procesar por lo que no puede
hacerse una recomendación firme, pero sí sugerir el valor por defecto, 20.
El parámetro de tamaño de supervoxels también tiene un claro efecto en los resultados,
pero en las pruebas realizadas se han obtenido buenos resultados con valores de 10, 15 y 20,
siendo los mejores resultados los de mayor resolución, es decir, con menor tamaño de super-
voxel. Para el caso concreto de peque (o imágenes de resolución y características similares)
aumentar el tamaño de supervoxel por encima de 20 ha causado pérdidas perceptibles en los
detalles en las formas de la imagen. Se recomendará un rango de valores entre 10 y 20 para
el tamaño de supervoxel. Se puede ver un ejemplo del efecto del tamaño de supervoxels en la
figura 4.2
En las capturas además pueden verse marcados los centros de algunos de los supervoxels,
indicando que estos se han desplazado desde su posición inicial en una misma capa hasta
distribuirse en diferentes capas. Este desplazamiento, que será en los tres ejes y no sólo el
eje Z, será convergente y es la medida que se utiliza en las ejecuciones en las que se fije un
parámetro de tolerancia.
29
Figura 4.3: Comparación de diferentes pesos de la diferencia de color
30
Capítulo 5
CONCLUSIONES Y TRABAJOSFUTUROS
5.1. Conclusiones
Como se ha podido observar en el capítulo previo se han cumplido el objetivo general
de forma satisfactoria. Para el cumplimiento de este objetivo ha sido necesario finalizar con
éxito los subobjetivos detallados en la sección 1.6 Objetivos.
De lo expuesto a lo largo de este documento se puede concluir que SLIC es un algoritmo
eficiente y adecuado para su uso en EspINA. Los resultados obtenidos han sido acordes a
las expectativas y la integración con la aplicación ha sido fluida. El algoritmo tiene un lu-
gar apropiado dentro de la interfaz de usuario y sus resultados son accesibles al resto de la
aplicación.
Se trata de un proyecto de gran interés que no sólo implica el uso de lenguajes y he-
rramientas no empleados durante el transcurso de la carrera, si no que también implica un
logro personal y una experiencia en el entorno de un centro de investigación. El aporte de
satisfacción es a nivel profesional como personal a partes iguales.
Durante la realización de pruebas y el análisis de resultados se han confirmado algunas
suposiciones surgidas durante el desarrollo así como algunas afirmaciones hechas por los au-
tores del algoritmo. Por ejemplo se han podido confirmar los valores esperados de uso de
memoria y los límites mínimos teóricos de esta, y se han comprobado las diferencias espera-
das entre las variantes del algoritmo, proporcionando SLIC unos supervoxels más compactos
que las variantes y siendo SLICO el algoritmo más adecuado debido a su mayor adaptabili-
dad que SLIC pero sin la pérdida de control de la compactitud que ocasiona el uso de ASLIC.
También se han aportado valoraciones subjetivas sobre los valores más adecuados para los
31
parámetros de entrada.
5.2. Trabajos futuros
Durante el desarrollo del proyecto han surgido nuevas ideas que se suman a algunas de
las ideas iniciales que se propusieron como objetivos opcionales y no han podido llevarse a
cabo por falta de tiempo. Se destacan las siguientes:
Compresión más eficiente de resultados (zlib, quazip, zstd...)
Paralelización de la ejecución del algoritmo
Uso de instrucciones AVX para realizar múltiples operaciones por ciclo
Finalización del soporte para la implementación de ROI (Regions of Interest) de EspI-
NA
Integración con otras herramientas y algoritmos disponibles en EspINA
32
Bibliografía
[1] Espina Interactive Neuron Analyzer, http://cajalbbp.cesvima.upm.es/espina/,
[Online; último acceso 26-Abril-2018], 2018.
[2] R. Achanta, A. Shaji y S. et al., “SLIC Superpixels Compared to State-of-the-Art Su-
perpixel Methods”, IEEE Transactions on Pattern Analysis and Machine Intelligence,
vol. 34, n.o 11, págs. 2274-2282, 2012. DOI: 10.1109/tpami.2012.120. dirección:
http://dx.doi.org/10.1109/TPAMI.2012.120.
[3] ESPINA: a tool for the automated segmentation and counting of synapses in largestacks of electron microscopy images, https://www.frontiersin.org/articles/10.
3389/fnana.2011.00018/full, [Online; último acceso 26-Abril-2018], 2018.
[4] Cajal Blue Brain Project, http://cajalbbp.cesvima.upm.es/, [Online; último acceso
26-Abril-2018], 2018.
[5] Centro de Tecnología Biomédica, http://www.ctb.upm.es/, [Online; último acceso
26-Abril-2018], 2018.
[6] espina-developers / espina — bitbucket, https://bitbucket.org/espina-developers/espina, [Online; último acceso 03-Julio-2018], 2018.
[7] Insight Segmentation and Registration Toolkit, https://itk.org/, [Online; último
acceso 26-Abril-2018], 2018.
[8] Visualization Toolkit, https://www.vtk.org/, [Online; último acceso 26-Abril-2018],
2018.
[9] A. Lucchi, K. Smith, R. Achanta, V. Lepetit y P. Fua, “A Fully Automated Approach
to Segmentation of Irregularly Shaped Cellular Structures in EM Images”, MedicalImage Computing and Computer-Assisted Intervention – MICCAI 2010 Lecture Notesin Computer Science, 463–471, 2010. DOI: 10.1007/978-3-642-15745-5_57.
[10] J. Shi y J. Malik, “Normalized cuts and image segmentation”, IEEE Transactions onPattern Analysis and Machine Intelligence, vol. 22, n.o 8, 888–905, 2000. DOI: 10.
1109/34.868688.
33
[11] P. F. Felzenszwalb y D. P. Huttenlocher, “Efficient Graph-Based Image Segmentation”,
International Journal of Computer Vision, vol. 59, n.o 2, 167–181, 2004. DOI: 10.1023/
b:visi.0000022288.19776.77.
[12] S. Avidan y A. Shamir, “Seam carving for content-aware image resizing”, ACM SIG-GRAPH 2007 papers on - SIGGRAPH 07, 2007. DOI: 10.1145/1275808.1276390.
[13] A. Vedaldi y S. Soatto, “Quick Shift and Kernel Methods for Mode Seeking”, LectureNotes in Computer Science Computer Vision – ECCV 2008, 705–718, DOI: 10.1007/
978-3-540-88693-8_52.
[14] L. Vincent y P. Soille, “Watersheds in digital spaces: an efficient algorithm based on
immersion simulations”, IEEE Transactions on Pattern Analysis and Machine Intelli-gence, vol. 13, n.o 6, 583–598, 1991. DOI: 10.1109/34.87344.
[15] A. Levinshtein, A. Stere, K. Kutulakos, D. Fleet, S. Dickinson y K. Siddiqi, “Tur-
boPixels: Fast Superpixels Using Geometric Flows”, IEEE Transactions on PatternAnalysis and Machine Intelligence, vol. 31, n.o 12, 2290–2297, 2009. DOI: 10.1109/
tpami.2009.96.
[16] BSVC Qt, https://github.com/GoLoT/BSVC_Qt, [Online; último acceso 15-Junio-
2018], 2018.
[17] BSVC, https://github.com/BSVC/bsvc, [Online; último acceso 27-Junio-2018], 2018.
[18] MSYS, http://www.mingw.org/wiki/MSYS, [Online; último acceso 15-Junio-2018],
2018.
[19] MinGW, http://mingw.org/, [Online; último acceso 15-Junio-2018], 2018.
[20] Windows Subsystem for Linux, https://docs.microsoft.com/en-us/windows/wsl/
about, [Online; último acceso 15-Junio-2018], 2018.
[21] Xming X System Server, https://sourceforge.net/projects/xming/, [Online; último
acceso 15-Junio-2018], 2018.
[22] CIELAB color space, https://en.wikipedia.org/wiki/Lab_color_space/, [Online;
último acceso 26-Abril-2018], 2018.
Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,
C=ES
Fecha/Hora Mon Jul 09 15:37:32 CEST 2018
Emisor delCertificado
[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES
Numero de Serie 630
Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe Signature)
