Pyradiomics: Perfilado de PyRadiomics para segmentaciones muy grandes

@blezek Le mencioné a @ Radiomics / developers que tendrías problemas de rendimiento al intentar ejecutar radiomics en cerebros completos, así que @JoostJM hizo algunos perfiles.

De un vistazo rápido al código glszm , parece que hay mucho espacio para optimizar la implementación.

¿En el código c? ¿Tiene una idea general de cómo abordarlo?

¿En el código c? ¿Tiene una idea general de cómo abordarlo?

Quizás podrías considerar el uso de hilos

Dicho esto, el uso de bibliotecas de subprocesos con código c vanilla puede ser un desafío para hacerlo bien.

Creo que la implementación de filtros ITK podría ser útil (por ejemplo, como módulo remoto ITK), entonces podrá aprovechar el procesamiento de imágenes multiplataforma asociado y la API de subprocesos. Estos filtros podrían luego exponerse a través de SimpleITK

@thewtex @jbvimort Me pregunto si tiene alguna idea ...

Sería mejor hacer un perfil línea por línea, pero supongo que este conjunto de bucles anidados es bastante lento. Usar numpy.where puede ser lento y devolverá largas listas de coordenadas.

Estoy de acuerdo con Jc en que esta operación podría estar enhebrada ya que cada píxel debería ser independiente. Además, una implementación de SimpleITK de la misma operación podría ser mucho más rápida. Pero comenzaría por hacer el perfil y vería si hay formas de optimizar el código Python existente.

@pieper , a partir del perfil, Joost ya hizo que _calculateCMatrix representa el 77% del tiempo (si interpreto el resumen del perfil correctamente):

Ya veo, está diciendo que probablemente sea esta llamada a este código . Sí, parece bastante intensivo en computación.

Si esta característica es realmente informativa, y las máscaras de imágenes grandes son un caso de uso importante, entonces podría ser que el enfoque de "biblioteca C simple" no sea suficiente, al menos como está escrito actualmente. Es posible que el código C se pueda hacer más eficiente o podríamos explorar otras opciones como la implementación de subprocesos o SimpleITK.

@pieper @fedorov , de hecho es esta llamada . Echaré un vistazo para ver si se puede hacer más eficiente.

Si puedo, me gustaría evitar la implementación de subprocesos múltiples aquí por 2 razones

1. Esto hará que el código C sea mucho más complejo.
2. Cuando extraigo características para varios pacientes, aumento el rendimiento al realizar múltiples subprocesos a nivel de paciente (cada paciente 1 subproceso). En este caso, también configuré SimpleITK en un solo hilo para mantener la extracción del paciente en un solo hilo.

En una nota al margen, la razón principal por la que c GLSZM toma tanto tiempo es porque es computacionalmente intensivo y se llama 12 veces (debido a las diferentes imágenes derivadas). La llamada al filtro de imagen labelshapestatistics de SimpleITK es la llamada que toma más tiempo para una sola llamada, pero solo se llama una vez por extracción (ya que es parte de la forma y, por lo tanto, solo se calcula en el tipo de imagen original).

En cuanto a la llamada de SimpleITK que lleva tanto tiempo. Esto se debe al cálculo del diámetro de Feret (diámetro máximo 3D).
Si ejecuta el filtro de imagen labelshapestatistics con y sin este diámetro, hay una diferencia de tiempo de 271053 ms frente a 21 ms para la máscara completa del cerebro1.

Ahora hay un paquete de Python disponible, itk-texturefeatures , que podría ser útil aquí.

@JoostJM, ¿

https://github.com/InsightSoftwareConsortium/ITKTextureFeatures/tree/2b4544fe39e0ece9007a0d87c396c8586c6f4df5/example

@pieper , Acabo de regresar de mis vacaciones, pero esto es ciertamente interesante.
Hice algunos perfiles usando PyRadiomics y una máscara similar a la utilizada por las características de textura de ITK (implementando un cálculo sabio de vóxeles). El rendimiento de la piradiómica fue similar al rendimiento de ITK.
La desventaja de PyRadiomics es que solo acepta entrada 3D, mientras que ITK es N-dimensional. Por otro lado, PyRadiomics logra este rendimiento en el modo de un solo hilo y calcula más funciones en GLCM.

En términos de conjunto de características, por lo que puedo ver, las definiciones de las fórmulas son similares, y PyRadiomics tiene más características tanto en GLCM como en GLRLM. Las características de textura de ITK tienen solo una característica (en GLCM) que PyRadiomics no tiene, pero esta es una implementación similar de correlation de PyRadiomics, que está presente en ITK como Haralick's correlation . Dicho esto, sigo creyendo que habrá algunas diferencias, debido al hecho de que ITK usó un recuento de contenedores fijo, a diferencia del ancho de contenedor fijo en PyRadiomics.

Gracias por consultar @JoostJM ; parece que deberíamos decidir si queremos mantener una implementación independiente en PyRadiomics o trabajar junto con la comunidad de ITK para mejorar las características de itk-texture. Mi reacción instintiva es preferir el esfuerzo de la comunidad siempre que sea posible con la esperanza de que el mantenimiento del código sea más eficiente.