Pyradiomics: التنميط PyRadiomics للتجزئة الكبيرة جدًا

blezek لقد ذكرت لـ @ Radiomics / Developers أنك ستواجه مشكلات في الأداء تحاول تشغيل علم الأشعة على أدمغة كاملة ، لذا قام JoostJM ببعض التنميط.

من نظرة سريعة على كود glszm ، يبدو أن هناك متسعًا كبيرًا لتحسين التنفيذ.

في كود ج؟ هل لديك فكرة عامة عن كيفية التعامل معها؟

في كود ج؟ هل لديك فكرة عامة عن كيفية التعامل معها؟

قد يكون يمكنك النظر في استخدام المواضيع

ومع ذلك ، قد يكون استخدام مكتبات الترابط مع رمز c الفانيليا

أعتقد أن تنفيذ مرشحات ITK قد يكون مفيدًا (على سبيل المثال ، كوحدة ITK البعيدة) ، ستتمكن بعد ذلك من الاستفادة من واجهة برمجة تطبيقات معالجة الصور والترابط المرتبطة عبر الأنظمة الأساسية. يمكن بعد ذلك كشف هذه المرشحات من خلال SimpleITK

thewtexjbvimort أنا أتساءل عما إذا كان لديك أي أفكار ...

سيكون من الأفضل إجراء التنميط سطرًا بسطر ، لكني أعتقد أن هذه المجموعة من الحلقات المتداخلة بطيئة جدًا. يمكن أن يكون استخدام numpy.where بطيئًا وسيعرض قوائم طويلة من الإحداثيات.

أتفق مع Jc في أن هذه العملية يمكن أن تكون مترابطة لأن كل بكسل يجب أن يكون مستقلاً. كما يمكن أن يكون تنفيذ SimpleITK لنفس العملية أسرع بكثير. لكنني سأبدأ بإجراء التنميط ومعرفة ما إذا كانت هناك طرق لتحسين كود Python الموجود.

pieper يبدو من التنميط أن Joost فعل بالفعل أن حسابات _calculateCMatrix تمثل 77٪ من الوقت (إذا فسرت ملخص التنميط بشكل صحيح):

أرى ، أنت تقول أنه من المحتمل أن تكون هذه الدعوة إلى هذا الرمز . نعم ، هذا يبدو مكثفًا جدًا في الحوسبة.

إذا كانت هذه الميزة مفيدة حقًا ، وكانت أقنعة الصور الكبيرة حالة استخدام مهمة ، فقد يكون أسلوب "مكتبة C البسيطة" غير كافٍ ، على الأقل كما هو مكتوب حاليًا. من الممكن جعل كود C أكثر كفاءة أو يمكننا استكشاف خيارات أخرى مثل تنفيذ الترابط أو SimpleITK.

pieperfedorov، انها حقا هذه الدعوة . سألقي نظرة لمعرفة ما إذا كان يمكن جعله أكثر كفاءة.

إذا كان بإمكاني ، أود تجنب تطبيق multithreading هنا لسببين

1. هذا سيجعل كود سي أكثر تعقيدًا
2. عندما أقوم باستخراج ميزات لمرضى متعددين ، أقوم بزيادة الأداء عن طريق تعدد مؤشرات الترابط على مستوى المريض (كل مريض 1 مؤشر ترابط). في هذه الحالة ، قمت أيضًا بتعيين SimpleITK على مؤشر ترابط واحد للحفاظ على الخيط المفرد لاستخراج المريض.

في ملاحظة جانبية ، السبب الرئيسي في أن c GLSZM يستغرق الكثير من الوقت لأنه مكثف من الناحية الحسابية ويسمى 12 مرة (بسبب الصور المشتقة المختلفة). استدعاء مرشح صورة SimpleITK's Labelshapestatistics هو الاستدعاء الذي يستغرق معظم الوقت لمكالمة واحدة ، ولكن يتم استدعاؤه مرة واحدة فقط لكل عملية استخراج (لأنه جزء من الشكل وبالتالي يتم حسابه فقط على نوع الصورة الأصلي).

فيما يتعلق باستدعاء SimpleITK الكثير من الوقت. ويرجع ذلك إلى حساب قطر فيريت (أقصى قطر ثلاثي الأبعاد).
إذا قمت بتشغيل مرشح صورة Labelshapestatistics مع وبدون هذا القطر ، فسيكون هناك فارق زمني قدره 271053 مللي ثانية مقابل 21 مللي ثانية لقناع الدماغ 1 الكامل.

تتوفر الآن حزمة Python ، itk-texturefeatures ، والتي يمكن أن تكون مفيدة هنا.

JoostJM هل

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

pieper ، عدت للتو من
لقد قمت ببعض التنميط باستخدام PyRadiomics وقناع مشابه كما تم استخدامه بواسطة ميزات نسيج ITK (تنفيذ حساب voxel الحكيم). كان أداء Pyradiomics مشابهًا لأداء ITK.
الجانب السلبي في PyRadiomics هو أنه يقبل فقط الإدخال ثلاثي الأبعاد ، في حين أن ITK هو N-dimensional. من ناحية أخرى ، تحقق PyRadiomics هذا الأداء في وضع مؤشر ترابط واحد وتحسب المزيد من الميزات في GLCM.

من حيث مجموعة الميزات ، بقدر ما أستطيع أن أرى تعريفات الصيغة متشابهة ، مع وجود PyRadiomics لها المزيد من الميزات في كل من GLCM و GLRLM. تحتوي ميزات نسيج ITK على ميزة واحدة فقط (في GLCM) لا تمتلكها PyRadiomics ، ولكن هذا تطبيق مشابه لـ PyRadiomics correlation ، الموجود في ITK كـ Haralick's correlation . ومع ذلك ، ما زلت أعتقد أنه ستكون هناك بعض الاختلافات ، نظرًا لحقيقة أن ITK استخدم عددًا ثابتًا من الحاويات ، بدلاً من عرض الصندوق الثابت في PyRadiomics.

شكرًا للتحقق من JoostJM - يبدو أننا يجب أن نقرر ما إذا كنا نريد الاحتفاظ بتنفيذ مستقل في PyRadiomics أو العمل معًا مع مجتمع ITK لتحسين ميزات itk-texturefeatures. ردة فعلي السريعة هي تفضيل جهود المجتمع كلما أمكن ذلك على أمل أن تكون صيانة الكود أكثر كفاءة.