前回は3.Xへの更新について説明を行いました。
Introduction
現状の.NETのUIといえば、UWPがメインに据えられ(Microsoft的な意味で)、WPFが微妙な立ち位置になり、WinFormsがレガシーとなっていますが、UI以外の面では System.Drawing 名前空間は、GDIという太古からのレガシーを受け継いでいたため、WPFでは互換性維持程度のAPIサポートしかなくなりました。
でも、いつ解放されるかわからない System.Windows.Media.Imaging.BitmapSource よりも、System.IDisposable を実装している System.Drawing.Bitmap のが、メモリ管理という点では管理しやすいのは事実です。
なので、Bitmapを使っている既存ライブラリを活用するため、BitmapSourceから、あるいはその逆変換を行う必要は結構あると思います。
そういう事情を反映してか、OpenCVSharpも便利な拡張メソッド BitmapSource OpenCvSharp.Extensions.ToBitmapSource を提供しています。
これはBitmapをBitmapSourceに変換する拡張メソッドですが、BitmapSourceに変換したいだけなら、ちょっと一手間加えるだけで、速度面で改善を加えることができます。
それは下記のソースになります。
1 | [ ] |
これを使って、OpenCVと比較しました。
以下サンプルソースです。
1 | using System; |
600x400の32bit画像を10000回BitmapSourceに変換するだけです。
以下テスト結果です。
- OpenCVSharp: Total: 55023 ms. Average: 5.5 ms
- better: Total: 16843 ms. Average: 1.6 ms
結果は圧勝です。
BitmapSourceにして、System.Windows.Controls.Image に表示したいだけなら、断然後者です。
性能差の原因は?
OpenCVSharpのToBitmapSourceのソースを見ればわかりますが、けっこう色々やっています。
1 | public static BitmapSource ToBitmapSource(this Bitmap src) |
ざっくりと説明すると、BitmapをMemoryStreamにSaveし、MemoryStreamからBitmapSourceを生成しています。
MemoryStreamへ保存している時点で全バイトデータのコピーが走るでしょうし、WritableBitmapSourceを作成するときも、MemoryStreamからメモリデータの転送が実行されるわけです。
そりゃ時間がかかるでしょう。CPUのキャッシュに乗る量なら良いですが、画像データのメモリコピーは(CPUからすれば)遅いです。
CreateBitmapSourceFromHBitmap もメモリのコピーはあるはずでしょう。
また、ToBitmapSourceは戻ってくるBitmapSourceが最初からFreezeされています。
なので、編集したい場合は使えないです。
こうすると、ToBitmapSourceを使うメリットが無いですねぇ..
Conclusion
性能が出ないとき、全てを疑うのは時間の無駄ですが、一番ボトルネックになりそう、っていう勘どころをつかめると楽ですね。
今回はそれが理由でパフォーマンスを調査したのが始まりでした。