Pyradiomics: 为非常大的分割分析 PyRadiomics

@blezek我向@Radiomics/developers 提到，您在尝试在整个大脑上运行放射组学时会遇到性能问题，因此@JoostJM进行了一些分析。

从快速查看glszm代码来看，似乎有很多优化实现的空间。

在c代码中？ 你对如何解决它有一个大致的想法吗？

在c代码中？ 你对如何解决它有一个大致的想法吗？

也许你可以考虑使用线程

也就是说，使用带有普通 c 代码的线程库可能很难做到正确。

我认为实现 ITK 过滤器可能会有所帮助（例如作为 ITK 远程模块），然后您将能够利用相关的跨平台图像处理和线程 API。 然后可以通过 SimpleITK 公开这些过滤器

@thewtex @jbvimort我想知道您是否有任何见解...

最好进行逐行分析，但我的猜测是这组嵌套循环非常慢。 使用 numpy.where 可能会很慢，并且会返回很长的坐标列表。

我同意 Jc 这个操作可以线程化，因为每个像素应该是独立的。 同样操作的 SimpleITK 实现可能会更快。 但我会先做分析，看看是否有办法优化现有的 python 代码。

@pieper从分析看来，Joost 已经做了_calculateCMatrix占 77% 的时间（如果我正确解释了分析摘要）：

我明白了，你是说这可能是对这段代码的调用。 是的，这看起来非常计算密集型。

如果此功能真的很有用，并且大图像蒙版是一个重要的用例，那么“简单的 C 库”方法可能是不够的，至少在目前编写的情况下是这样。 有可能使 C 代码更高效，或者我们可以探索其他选项，如线程或 SimpleITK 实现。

@pieper @fedorov ，确实是这个电话。 我会看看它是否可以提高效率。

如果可以，我想避免在这里实现多线程有两个原因

1. 这将使 C 代码变得更加复杂
2. 当我为多个患者提取特征时，我通过在患者级别（每个患者 1 个线程）进行多线程来提高性能。 在这种情况下，我还将 SimpleITK 设置为单线程以保持患者提取单线程。

附带说明一下，c GLSZM 花费如此多时间的主要原因是因为它是计算密集型的并且被调用了 12 次（由于不同的派生图像）。 对 SimpleITK 的 labelshapestatistics 图像过滤器的调用是单个调用花费最多时间的调用，但每次提取仅调用一次（因为它是形状的一部分，因此仅对原始图像类型进行计算）。

至于 SimpleITK 调用花费了这么多时间。 这是由于计算 Feret 直径（最大 3D 直径）。
如果您在使用和不使用此直径的情况下运行 labelshapestatistics 图像过滤器，则全脑 1 掩码的时间差为 271053 毫秒与 21 毫秒。

现在有一个可用itk-texturefeatures ，在这里可能会有所帮助。

@JoostJM你看过 itk-texturefeatures 吗？ 了解速度的比较方式以及特征集是否与我们现在在 pyradiomics c 代码中的内容相当会很有趣。

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

@pieper ，刚从我的假期回来，但这当然很有趣。
我使用 PyRadiomics 和 ITK 纹理特征使用的类似掩码进行了一些分析（实现了体素智能计算）。 Pyradiomics 的性能与 ITK 的性能相似。
PyRadiomics 的缺点是它只接受 3D 输入，而 ITK 是 N 维的。 另一方面，PyRadiomics 在单线程模式下实现了这种性能，并在 GLCM 中计算了更多特征。

在特征集方面，据我所知，公式定义是相似的，PyRadiomics 在 GLCM 和 GLRLM 中都有更多的特征。 ITK 的纹理特征只有 PyRadiomics 没有的 1 个特征（在 GLCM 中），但这是 PyRadiomics 的类似实现correlation ，它在 ITK 中以Haralick's correlation 。 话虽如此，我仍然相信会有一些差异，因为 ITK 使用固定的 bin 计数，而不是 PyRadiomics 中的固定 bin 宽度。

感谢您检查@JoostJM - 听起来我们应该决定是否要在 PyRadiomics 中保留一个独立的实现，或者与 ITK 社区合作来改进 itk-texturefeatures。 我的下意识反应是尽可能选择社区的努力，希望代码维护更高效。