Capítulo 5: Integración de Modelo de Superficie
5.3 Arquitectura de Burger
5.4.2 Actualización del módulo Interfaz
Una segunda etapa de desarrollo consistió en incluir el nuevo modelo basado en superficies dentro SIMECO.
Se añadieron clases nuevas que facilitan la comunicación entre el modelo de mallas y la interfaz de SIMECO. Estas clases fueron agregadas siguiendo el diseño original de la relación entre interfaz con el modelo de volumen, haciendo uso de la herencia que abstrae cada uno de los ejercicios que pueden ser ejecutados. En la siguiente tabla se especificará cada una de las clases que fueron agregadas:
Class Descripción
BurgerThead
Esta clase hereda de la clase burgerClient. El objetivo principal de esta clase es inicializar un modelo de mallas con sus respectivos archivos de configuración y ejecutarlo en un thread distinto al que utiliza la interfaz.
ExeciseMesh
Esta clase hereda ExerciseNode. El objetivo principal de esta clase es generar un ejercicio correspondiente al modelo de mallas. Se debe implementar el método start(), el cual crea una nueva instancia de BurgerThread y cuando éste actualiza el frame (el cual contiene la información de la simulación) por medio de la señal frameFinished, se comunicara con
UltrasoundLabel quien será la encargada de mostrar la matriz resultante en la interfaz.
ExercisePMesh
Esta es una herencia de ExeciseMesh, la cual fue diseñada para ejercicios de práctica correspondientes al modelo de mallas. Esta clase está pensada para que en un futuro, si se desean agregar ejercicios básicos y de medición simplemente se deba crear una nueva clase similar con las configuraciones correspondientes al ejercicio.
En la figura 5.4.2.1 se puede apreciar el resultado de incluir las nuevas clases en el diagrama de clases del módulo interfaz.
Figura 5.4.2.1: diagrama de clases parcial del módulo Interfaz
El archivo CmakeList de SIMECO debe incluir la librería de la misma forma que hace con el otro modelo, las sentencias para a agregar son:
find_package(BURGER REQUIRED) if (BURGER_FOUND)
include_directories(${BURGER_INCLUDE_DIR}) target_link_libraries(interfaz ${BURGER_LIBRARIES}) endif()
cuando se ejecuta el archivo CmakeList se tiene que definir la variable BURGER_DIR con la ruta del directorio de la librería para que el archivo de módulo la encuentre.
Finalmente la figura 5.4.2.2 muestra una vista general de cómo se comunican las entidades dentro de
la librería y cómo se desarrolla el nexo de ésta con SIMECO. Figura 5.4.2.2: vista general que muestra la relacion entre burger con SIMECO
5.5 Comparación entre los modelos implementados en SIMECO
La simulación de procesos físicos implica modelar los fenómenos físicos acordes, algunos de loscuales no se entienden completamente o resultan demasiados complejos para modelarlos de manera
eficiente. Como consecuencia se obtiene modelos simplificados o incompletos que no pueden imitar
correctamente los fenómenos del proceso modelado. Para la validación y comparación de modelos
para la simulación de imágenes de ultrasonido, la dificultad no solo radica en los fenómenos físicos,
sino también en el modelado de la forma y las propiedades de los tejidos además de los procesos
aleatorios de dispersión y ruido. Debido a estas limitaciones, no es posible obtener imágenes 100%
realistas y las evaluaciones bajo este criterio fracasarán. Entonces hay que definir la simulación en
términos de realismo aceptable o adecuado y para ello primero hay que definir cuales son los
criterios. La validación se divide en tres partes: el realismo percibido, la precisión de los resultados y el
rendimiento en cuanto a framerate. Existen varios factores que impactan directamente sobre estas características. Se pueden identificar:
● La cantidad de rayos: Aumentar o disminuir la cantidad de rayos afecta el tiempo de renderizado y artefactos como el enfoque.
● Tamaño del modelo: Para el caso del modelo de superficie, una geometría altamente detallada se compone de una cantidad más elevada de triángulos, esto se traduce a un número mayor de colisiones y por consiguiente mayor cantidad de cálculos que afectan a la performance.
● Efectos simulados: artefactos como la refracción, deformación y ruido speckle generan un mayor número de cálculos que pueden afectar negativamente al rendimiento; ajustar su calidad u omitirlos es una alternativa para mejorar el rendimiento.
La combinación óptima de estos factores es relativa a los requisitos y limitaciones de hardware disponibles. Existe un trade off entre precisión e interactividad. Cuanto más interactivo se pretende ser, se simulan menos efectos y se disminuye el número de rayos, lo que da como resultado imágenes nítidas y planas. En sentido contrario, cuando se busca mayor precisión, las sombras, reflejos y estructuras se ven borrosas lo que resulta ser una imagen más realista.
Figura 5.5.1: Trade off entre interactividad y precisión
Al comparar el modelo de volúmenes contra el modelo de mallas pudimos detectar los siguientes aspectos importantes:
● El modelo de volúmenes muestra un corte del modelado 3D obtenido a partir de las imágenes de CT, esto simula estructuras anatómicas como realmente son. En contraparte el modelo de mallas capta el tiempo que pasa en recibir un eco y ésta es la forma en que funciona un ecógrafo real.
● La atenuación en el modelo de volúmenes se calcula a partir de aplicar un decaimiento lineal sobre el volumen generado a partir de las imágenes de CT. En el Modelo de mallas la atenuación es una propiedad que puede ser configurada.
● El modelo de volúmenes no puede simular artefactos dependientes de la vista, como la refracción. El modelo de mallas sí tiene en cuenta la refracción al cambiar la dirección de las ondas durante se realizan los cálculos.
Todos los fenómenos físicos incorporados en el modelo de mallas generan más artefactos de las
imágenes de ultrasonido como la refracción y la distorsión de rango mostrando imágenes más
precisas. Sin embargo trae aparejado un notable decaimiento de performance como para mantener la
interactividad mínimamente requerida. Se realizaron pruebas de simulación con dos ejercicios del modelo de mallas. El primero compuesto por dos mallas, un cuadrado de material grasa y una bola de material hueso. Al
ser pocos elementos relativamente sencillos de modelar con triángulos se logró mantener en ejecución una media de 4 frames por segundo. Cuando se probó con las mallas que modelan la
anatomía humana los frames por segundo bajaron a menos de 1 debido a la complejidad en el
modelado de los tejidos. Si bien la calidad y precisión de la imagen mejoran en gran medida como se
muestra en la figura 5.5.2, el modelo de mallas no puede competir contra lo 10 frames por segundos
que propone el modelo de volumen para mantener una interactividad respetable. Sin embargo los datos obtenidos no pueden considerarse concluyentes ya que se están ejecutando los
modelos sobre CPU cuando el máximo potencial de ambos modelo de se puede lograr con la paralelización en GPU.
Figura 5.5.2: Comparación de imagen de ultrasonido de Receso hepatorrenal generada por ambos modelos. a) Imagen real b) Modelo de volumen c) Modelo de superficies
Capítulo 6
6.1 Conclusiones
En el transcurso del proyecto se establecieron tres puntos elementales a destacar.
Con la integración del modelo de ruido speckle en tiempo real se observó que el rendimiento de la performance aumento debido a la disminución del consumo de memoria durante la ejecución y del tiempo de carga de los ejercicios.
En la reestructuración de la arquitectura se implementó una librería dinámica del módulo de simulación, lo que permitió una mejora en los tiempos de compilación y la posibilidad de reutilizar el motor de simulación como una librería third-party para programas ajenos que necesiten recrear una imagen de ultrasonido.
El último punto a destacar es la integración efectiva de un nuevo modelo de simulación basado en mallas, implementando, al igual que en la reestructuración de la arquitectura, una librería dinámica. Con dicho proceso se amplió la complejidad del simulador al incorporarse un nuevo modelo que genera imágenes más reales como resultado de una mejora en la simulación de los fenómenos físicos, a costa de una potencial disminución significativa de interactividad. No se pueden establecer como resultados concluyentes a causa de que todos los procesos son realizados en CPU, cuando se obtienen resultados considerablemente mejores con GPU.