Pyradiomics: Criação de perfil PyRadiomics para segmentações muito grandes

@blezek Eu mencionei a @Radiomics / developers que você teve problemas de desempenho ao tentar executar o radiomics em cérebros inteiros, então @JoostJM fez alguns perfis.

Olhando rapidamente para o código

No código c? Você tem uma ideia geral de como lidar com isso?

No código c? Você tem uma ideia geral de como lidar com isso?

Pode ser que você possa olhar para o uso de tópicos

Dito isso, usar bibliotecas de encadeamento com código c vanilla pode ser um desafio para acertar.

Acho que a implementação de filtros ITK pode ser útil (por exemplo, como módulo remoto ITK), você seria capaz de aproveitar o processamento de imagem de plataforma cruzada associado e API de threading. Esses filtros podem então ser expostos por meio do SimpleITK

@thewtex @jbvimort Gostaria de saber se você tem alguma

Seria melhor fazer um perfil linha por linha, mas meu palpite é que esse conjunto de loops aninhados é muito lento. O uso de numpy.where pode ser lento e retornará longas listas de coordenadas.

Concordo com Jc que essa operação pode ser encadeada, pois cada pixel deve ser independente. Além disso, uma implementação SimpleITK da mesma operação pode ser muito mais rápida. Mas eu começaria fazendo o perfil e ver se há maneiras de apenas otimizar o código Python existente.

@pieper , parece que o perfil de Joost já fez que _calculateCMatrix responde por 77% do tempo (se eu interpretar o resumo do perfil corretamente):

Eu vejo, você está dizendo que é provavelmente esta chamada para este código . Sim, isso parece muito intensivo em termos de computação.

Se esse recurso for realmente informativo e as máscaras de imagens grandes forem um caso de uso importante, pode ser que a abordagem de "biblioteca C simples" não seja suficiente, pelo menos como está escrita atualmente. É possível que o código C se torne mais eficiente ou podemos explorar outras opções, como threading ou implementação SimpleITK.

@pieper @fedorov , é mesmo esta chamada . Vou dar uma olhada para ver se pode ser mais eficiente.

Se eu puder, gostaria de evitar a implementação de multithreading aqui por 2 motivos

1. Isso tornará o código C muito mais complexo
2. Quando extraio recursos para vários pacientes, eu aumento o desempenho por multithreading no nível do paciente (cada paciente 1 thread). Neste caso, também defino SimpleITK como thread único para manter o thread único de extração do paciente.

Em uma nota lateral, o principal motivo de c GLSZM demorar tanto é porque é computacionalmente intensivo e é chamado 12 vezes (devido às diferentes imagens derivadas). A chamada para o filtro de imagem labelshapestatistics do SimpleITK é a chamada que leva mais tempo para uma única chamada, mas é chamada apenas uma vez por extração (pois é parte da forma e, portanto, apenas calculada no tipo de imagem original).

Quanto à chamada SimpleITK demorando muito. Isso é devido ao cálculo do diâmetro de Feret (diâmetro máximo 3D).
Se você executar o filtro de imagem de estatísticas de rótulos com e sem esse diâmetro, haverá uma diferença de tempo de 271053 ms versus 21 ms para a máscara cerebral1 completa.

Agora existe um pacote Python disponível, itk-texturefeatures , que pode ser útil aqui.

@JoostJM , você deu uma olhada nos recursos de textura itk? Seria interessante saber como a velocidade se compara e se os conjuntos de recursos são comparáveis ​​ao que temos agora no código c da piradiômica.

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

@pieper , Acabo de regressar das minhas férias, mas isto é certamente interessante.
Fiz alguns perfis usando PyRadiomics e máscara semelhante à usada pelos recursos de textura ITK (implementando um cálculo inteligente de voxel). O desempenho da piradiômica foi semelhante ao desempenho do ITK.
A desvantagem do PyRadiomics é que ele só aceita entrada 3D, enquanto o ITK é N-dimensional. Por outro lado, PyRadiomics atinge esse desempenho no modo de thread único e calcula mais recursos no GLCM.

Em termos de conjunto de recursos, pelo que posso ver, as definições das fórmulas são semelhantes, com PyRadiomics tendo mais recursos em GLCM e GLRLM. Os recursos de textura do ITK têm apenas 1 recurso (no GLCM) que o PyRadiomics não tem, mas esta é uma implementação semelhante do PyRadiomics ' correlation , que está presente no ITK como Haralick's correlation . Dito isso, ainda acredito que haverá algumas diferenças, devido ao fato de que ITK usou uma contagem de bin fixa, em oposição à largura de bin fixa em PyRadiomics.

Obrigado por verificar @JoostJM - parece que devemos decidir se queremos manter uma implementação independente em PyRadiomics ou trabalhar em conjunto com a comunidade ITK para melhorar os recursos de textura itk. Minha reação automática é preferir o esforço da comunidade sempre que possível, na esperança de que a manutenção do código seja mais eficiente.