Pyradiomics: Profilerstellung von PyRadiomics für sehr große Segmentierungen

@blezek Ich habe @Radiomics/developers erwähnt, dass Sie auf Leistungsprobleme stoßen würden, wenn Sie versuchen, Radiomics auf ganzen Gehirnen auszuführen, also hat

Ein kurzer Blick auf den glszm- Code sieht so aus, als gäbe es viel Spielraum, um die Implementierung zu optimieren.

Im C-Code? Haben Sie eine allgemeine Idee, wie Sie es angehen können?

Im C-Code? Haben Sie eine allgemeine Idee, wie Sie es angehen können?

Vielleicht könnten Sie versuchen, Threads zu verwenden

Das heißt, die Verwendung von Threading-Bibliotheken mit Vanilla-C-Code kann schwierig sein, richtig zu machen.

Ich denke, dass die Implementierung von ITK-Filtern hilfreich sein könnte (zB als ITK-Remote-Modul), dann könnte man die zugehörige plattformübergreifende Bildverarbeitungs- und Threading-API nutzen. Diese Filter könnten dann durch SimpleITK . freigelegt werden

@thewtex @jbvimort Ich frage mich, ob Sie irgendwelche Erkenntnisse haben ...

Es wäre am besten, eine zeilenweise Profilerstellung durchzuführen, aber ich vermute, dass dieser Satz verschachtelter Schleifen ziemlich langsam ist. Die Verwendung von numpy.where kann langsam sein und gibt lange Koordinatenlisten zurück.

Ich stimme Jc zu, dass diese Operation mit einem Thread versehen werden könnte, da jedes Pixel unabhängig sein sollte. Auch eine SimpleITK-Implementierung der gleichen Operation könnte viel schneller sein. Aber ich würde mit der Profilerstellung beginnen und sehen, ob es Möglichkeiten gibt, den vorhandenen Python-Code einfach zu optimieren.

@pieper Aus der Profilerstellung geht hervor, dass Joost bereits durchgeführt hat, dass _calculateCMatrix 77% der Zeit

Ich sehe, Sie sagen, es ist wahrscheinlich dieser Aufruf dieses Codes . Ja, das sieht ziemlich rechenintensiv aus.

Wenn diese Funktion wirklich informativ ist und große Bildmasken ein wichtiger Anwendungsfall sind, dann könnte es sein, dass der Ansatz der "einfachen C-Bibliothek" zumindest in der derzeit geschriebenen Form nicht ausreicht. Es ist möglich, den C-Code effizienter zu gestalten oder andere Optionen wie Threading oder SimpleITK-Implementierung zu untersuchen.

@pieper @fedorov , es ist tatsächlich dieser Anruf . Ich schaue mal, ob man es effizienter machen kann.

Wenn ich kann, möchte ich Multithreading hier aus 2 Gründen vermeiden

1. Dadurch wird der C-Code viel komplexer
2. Wenn ich Features für mehrere Patienten extrahiere, erhöhe ich die Leistung durch Multithreading auf Patientenebene (jeder Patient 1 Thread). In diesem Fall habe ich SimpleITK auch auf Single-Thread gesetzt, um den Single-Thread der Patientenextraktion beizubehalten.

Nebenbei bemerkt, der Hauptgrund dafür, dass c GLSZM so viel Zeit benötigt, ist, dass es rechenintensiv ist und 12-mal aufgerufen wird (aufgrund der unterschiedlichen abgeleiteten Bilder). Der Aufruf des Labelshapestatistics-Bildfilters von SimpleITK ist der Aufruf, der für einen einzelnen Aufruf die meiste Zeit in Anspruch nimmt, aber nur einmal pro Extraktion aufgerufen wird (da er Teil von shape ist und daher nur auf dem ursprünglichen Bildtyp berechnet wird).

Was den SimpleITK-Aufruf angeht, der so viel Zeit in Anspruch nimmt. Dies liegt am berechneten Feret-Durchmesser (max. 3D-Durchmesser).
Wenn Sie den Bildfilter "labelshapestatistics" mit und ohne diesen Durchmesser ausführen, ergibt sich ein Zeitunterschied von 271053 ms gegenüber 21 ms für die vollständige brain1-Maske.

Es gibt jetzt ein Python-Paket , itk-texturefeatures , das hier hilfreich sein könnte.

@JoostJM hast du dir die itk-texturefeatures angesehen? Es wäre interessant zu wissen, wie sich die Geschwindigkeit vergleicht und ob die Feature-Sets mit dem vergleichbar sind, was wir jetzt im Pyromics-C-Code haben.

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

@pieper ,
Ich habe einige Profilierungen mit PyRadiomics und ähnlichen Masken durchgeführt, die von den ITK-Texturfunktionen verwendet wurden (um eine voxelweise Berechnung zu implementieren). Die Leistung der Pyromics war der Leistung von ITK ähnlich.
Der Nachteil von PyRadiomics ist, dass es nur 3D-Eingaben akzeptiert, während ITK N-dimensional ist. Auf der anderen Seite erreicht PyRadiomics diese Leistung im Single-Thread-Modus und berechnet mehr Features in GLCM.

In Bezug auf den Funktionsumfang sind die Formeldefinitionen, soweit ich sehen kann, ähnlich, wobei PyRadiomics sowohl in GLCM als auch in GLRLM mehr Funktionen bietet. Die Texturfunktionen von ITK haben nur eine Funktion (in GLCM), die PyRadiomics nicht hat, aber dies ist eine ähnliche Implementierung von correlation von PyRadiomics, die in ITK als Haralick's correlation . Davon abgesehen glaube ich immer noch, dass es einige Unterschiede geben wird, da ITK eine feste Bin-Anzahl verwendet hat, im Gegensatz zur festen Bin-Breite in PyRadiomics.

Vielen Dank für die Überprüfung bei @JoostJM -- klingt so, als sollten wir entscheiden, ob wir eine unabhängige Implementierung in PyRadiomics beibehalten oder mit der ITK-Community zusammenarbeiten möchten, um die itk-texturefeatures zu verbessern. Meine reflexartige Reaktion ist, wenn immer möglich, die Bemühungen der Community zu bevorzugen, in der Hoffnung, dass die Codepflege effizienter wird.