利便性とパフォーマンスは通常、逆相関します。コードが使いやすい場合は、あまり最適化されていません。最適化すると利便性が低下します。効率的なコードは、実際に何がどのように実行されているかの核心的な詳細に近づく必要があります。

私は、癌研究のために DeepCell 細胞セグメンテーションを実行および最適化するという進行中の作業の中で、一例を見つけました。 DeepCell AI モデルは、どのピクセルがセル内に存在する可能性が最も高いかを予測します。そこから、セルの境界 (あるしきい値より下) に到達するまで、最も可能性の高いピクセルから「塗りつぶし」を行います。

このプロセスの一部には、予測された細胞内の小さなギャップを滑らかにすることが含まれます。これはさまざまな理由で発生する可能性がありますが、生物学的には不可能です。 (細胞の多孔質膜ではなく、ドーナツの穴を考えてください。)

穴埋めアルゴリズムは次のようになります:

• オブジェクト (同じ数値 ID を持つ特定のセル ラベルを持つ連続したピクセル) を識別します。
• これらのセルの「オイラー数」、つまり形状の表面の尺度を計算します。
• オイラー数が 1 未満の場合 (サーフェスにギャップがある場合)、穴を滑らかにします。

ウィキペディアの記事からのオイラー数の例を次に示します。円 (線部分のみ) のオイラー特性は 0 ですが、円盤 (「塗りつぶされた」円) の値は 1 です。

ただし、オイラー数の定義や計算について話すためにここにいるわけではありません。オイラー数を計算するためのライブラリの簡単な方法がいかに非効率的であるかについて説明します。

まず最初に。 Speedscope:

regionprops で約 32 ミリ秒 (約 15%) が費やされたことが示されています。このビューは左に偏っています。タイムライン ビューに移動してズームインすると、次のようになります:

(これを 2 回行うため、ここでは ~16ms、他の場所では ~16ms になることに注意してください。)

これはすぐに疑わしいです。find_objects でオブジェクトを見つける際の「興味深い」部分は、最初の 0.5 ミリ秒です。ジェネレーターではなくタプルのリストを返すので、それが完了したら完了です。それで、他のものはどうなっているのでしょうか？私たちは、RegionProperties オブジェクトを構築しています。そのうちの 1 つを拡大してみましょう。

小さな部分 (拡大しません) はカスタム __setattr__ 呼び出しです。RegionProperties オブジェクトはエイリアシングをサポートしています。たとえば、属性 ConvexArea を設定すると、標準属性 area_convex にリダイレクトされます。それを利用していないにもかかわらず、属性コンバーターを通過します。

さらに: 領域プロパティで計算されたプロパティのほとんどは使用されていません。オイラー数のみを考慮します:

props = regionprops(np.squeeze(label_img.astype('int')), cache=False)
for prop in props:
    if prop.euler_number 



次に、これは領域プロパティの最も基本的な側面、つまり find_objects によって検出された画像領域 (元の画像のスライス) のみを使用します。

そこで、コードを fill_holes コードに変更して、regionprops 汎用関数を単純にバイパスしました。代わりに、find_objects を呼び出し、結果の画像サブ領域を euler_number 関数 (RegionProperties オブジェクトのメソッドではありません) に渡します。

プル リクエストは次のとおりです: deepcell-imaging#358 領域プロパティの構築をスキップします

中間オブジェクトをスキップすることで、fill_holes 操作のパフォーマンスが大幅に向上しました:

画像サイズ
前に
後
スピードアップ
260,000 ピクセル
48ミリ秒
40ミリ秒
8ms (17%)
1億4,000万画素
15.6秒
11.7秒
3.9秒 (25%)


大きな画像では、4 秒は全体の実行時間の約 3% であり、大部分ではありませんが、それほど粗末でもありません。