画像の情報量というと、1 フレーム当たりの情報量と捉えがちですが、現実的に重要なものは 1 フレーム当たりではなく単位時間当たりの情報量(ビットレート)です。現実社会では、情報の価値は時間とともに低下します。

処理速度が重要であるからといっても、高スペックのマシンを高負荷で稼働させれば良いわけではありません。この点にも留意すれば、単位電力量当たりの情報量と考えた方が、より現実的かもしれません。

人間が目視で情報を得る場合には「1 フレーム当たりの情報量」を上げれば良いのですが、画像利用の自動化が進むこれからの時代では、「単位電力量当たりの情報量」という形で、システムとしてのパフォーマンスが重視されます。

単位電力量当たりの情報量を大きくするためには、画像処理アルゴリズムの計算量を圧縮しなければなりません。特に外部ライブラリを参照する場合、そのライブラリで何ができるのかということも重要ですが、計算量が充分に圧縮されているかも同様に重要です。

入力データ量に対する処理時間をプロットすれば、計算量を知ることは容易です。イニシャルの処理が入っているかもしれませんが、重要な部分は大きいデータ量に対する応答でしょう。漸近的な振舞いがわかれば充分です。

入力データ量に対して線型な処理時間の応答をするアルゴリズムは優秀です。パフォーマンスを阻害することはないので、積極的に利用しましょう。一方、入力データ量に対して2乗の処理時間応答をするアルゴリズムは避けた方が良いでしょう。

一般的には、線型よりも log(入力データ量) 分だけ大きい応答をするアルゴリズムが多いように感じます。

付け焼刃ですが、負荷の大きいアルゴリズムは、高負荷であることを隠蔽するように非同期で走らせると、欠点をごまかすことができます。

アルゴリズムを開発される場合には、目的の出力を得ることと同時に計算量の圧縮も実行されることをお勧めします。正しい出力が得られるかプロトタイピングを行なってから、次に計算量を圧縮するという、2 ステップに分けて開発を進める考え方もありますが、多くの場合作成するプログラムは全く違ったものとなり 2 重開発の無駄が生じます。正しい結果が出るか否かをリスクヘッジするためだけにプロトタイピングを行なうことはお勧めしません。(written by J.Nishigata)

その他7- 画像処理は処理速度が命