A certain engineer "COMPLEX"

開発メモ135 OpenCVに組み込んだlibjpeg-turbo 1.5.3と2.0.0を比較

Introduction


前回の続き。

Introduction掲題そのまま。結構、このネタはそこら辺に転がっているんだけど、 計測していない エンコードだけ計測みたいなネタでげんなりしたので自分で実施し...

libjpeg-turboに2.0.0が登場しているため、1.5.3との性能を比較します。

Condition


条件は前回とほとんど変わりません。
違うのはリンクするlibjpeg-turboが2.0.0になっただけです。

  1. Intel Cire i7-8700 (3.20GHz)
  2. 32.0GB
  3. Visual Studio 2017 Update 7 (15.7)
  4. OpenCV 3.2.0 (動的リンク、world形式でビルド。IPP、CUDAは除外)
  5. libjpeg-turbo 2.0.0
  6. libjpeg-turbo.libをリンク

Test


実験も前回と同様、3種の画像、エンコードとデコードを計測します。
計測対象は下記。

  1. libjpeg-turbo 2.0.0 自家製ビルドOpenCV
  2. libjpeg-turbo 1.5.3 自家製ビルドOpenCV

また、実験ソースも前回と変わりません。
生成されたopencv_world320.dllを差し替えるだけです。

Result

実験結果は下記になります。
速度はいずれも平均速度です。

Decode

 640x3601280x7202560x1440
2.0.01.05651 ms4.67864 ms25.9939 ms
1.5.31.16508 ms5.11916 ms28.0259 ms
Improvement+10%+9%+7%

Encode

 640x3601280x7202560x1440
2.0.01.15707 ms4.3723 ms17.9123 ms
1.5.31.37863 ms5.03018 ms20.6569 ms
Improvement+19%+15%+15%

Conclusion

劇的な改善はありませんが、着実に性能が向上しています。

開発メモ134 OpenCVにlibjpeg-turboをリンクして性能比較

Introduction


掲題そのまま。
結構、このネタはそこら辺に転がっているんだけど、

  1. 計測していない
  2. エンコードだけ計測

みたいなネタでげんなりしたので自分で実施してみました。

実験ソースは下記になります

Sample source code for Demonstration, Experiment and Test - takuya-takeuchi/Demo

Condition


条件は下記になります。

  1. Intel Cire i7-8700 (3.20GHz)
  2. 32.0GB
  3. Visual Studio 2017 Update 7 (15.7)
  4. OpenCV 3.2.0 (動的リンク、world形式でビルド。IPP、CUDAは除外)
  5. libjpeg-turbo 1.5.3
  6. libjpeg-turbo.libをリンク

になります。
また、libjpeg.liblibjpeg-turbo.libのどちらをリンクするかで意見が割れていますが、ここではlibjpeg-turbo.libをリンクしました。

OpenCVのビルドのためのCMakeのコマンドは下記のようになります。

libjpeg-turbo 有効

libjpeg-turbo 無効

Test


実験は、

  1. libjpeg-turbo有効の自家製ビルドOpenCV
  2. libjpeg-turbo無効の自家製ビルドOpenCV
  3. 公式のOpenCVバイナリ

に対して比較します。
また、画像は、

  1. 640x360
  2. 1280x720
  3. 2560x1440

の3種類を用意し、それぞれのデータのデコードとエンコードを1000回繰り返します。

実験ソースは下記です。
ベースとして、下記のページを参考にさせていただきました。

Result

実験結果は下記になります。
速度はいずれも平均速度です。

Decode

 640x3601280x7202560x1440
Enable libjpeg-turbo1.16508 ms5.11916 ms28.0259 ms
Disable libjpeg-turbo2.15667 ms9.02238 ms40.7576 ms
original binary2.44517 ms10.1288 ms46.2685 ms

Encode

 640x3601280x7202560x1440
Enable libjpeg-turbo1.37863 ms5.03018 ms20.6569 ms
Disable libjpeg-turbo5.18752 ms19.4827 ms83.4678 ms
original binary5.69063 ms21.4501 ms91.6039 ms

Conclusion

エンコード性能は著しい改善を見せており、3.5-4.0倍の速度をたたき出しています。
デコードも、1.6-2.2倍の速度と良い感じです。

高々数十msの違いかもしれませんが、OpenCVのVideoCapture等でWebカメラをキャプチャした際、MotionJPEG形式ならデコード処理がそのままfpsに跳ね返ってきます。
1280X720で従来20ms要していたということは、30fpsのカメラでも事実上、1フレームに33ms+20msの53ms、つまり20fps程度しか性能が出なかったことになります。
これが5msになれば、33ms+5msの38msなら26fpsと改善できます。

Source Code

https://github.com/takuya-takeuchi/Demo/tree/master/libjpeg-turbo-decode

開発メモ132 Visual Studio 2017 15.7 に CUDA 9.2 をインストールする

Introduction


CUDA Toolkitには、Visual Studioと統合されるVisual Studio Integrationが含まれています。
しかしながら、このツール、Visual Studioのバージョンをチェックしているのか、2018/09/01現在、最新のCUDA Toolkit、cuda_9.2.148_win10.exeでもインストールに失敗します。
というのも公式にも対応しているのは、Visual Studio 2017 15.6となっており対応していないことがうかがえます。
既に、15.8の登場が控えている状況でこれは非常にまずいです。

ということでその対応。

Resolution


公式のフォーラムでもこの問題は話題になっています。
Nvidiaの対応に不満の声が。

そんな中、下記のスレッドのinstalling CUDA 9.2 with VS2017 integration worked for me this way:と言う投稿で対応策が提示されました。

要点は、

  1. cuda_9.2.88_win10.exeをWinRARとかで展開
  2. CUDAVisualStudioIntegration\CUDAVisualStudioIntegration.nviを書き換える
  3. setup.exeを実行
  4. C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.hを書き換える

です。
私の試した手順だと、

  1. cuda_9.2.88_win10.exeを実行し、インストーラを起動して最初の画面で待機
  2. CUDAVisualStudioIntegration.nviを書き換える
  3. インストール続行
  4. C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.hを書き換える

でOKでした。

少し具体的に書くと、

CUDAVisualStudioIntegration.nvi を書き換える

インストーラを起動してから書き換える場合は、"%TEMP%\CUDA\CUDAVisualStudioIntegration\CUDAVisualStudioIntegration.nviが書き換える対象です。
そして、テキストエディタでCUDAVisualStudioIntegration.nviを開き、下記の箇所を削除します。

host_config.h を書き換える

インストール完了後、C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v9.2\include\crt\host_config.hを書き換えます。
これを書き換えないと、CUDAを使ってコンパイルする際にエラーが出てコンパイルが停止します。
130行目付近の

を、下記のようにします。

開発メモ131 CSliderCtrlの背景色が変更されない

Introduction


MFCなんかレガシーもいいところですが、仕事である以上使わざるを得ません。
そんな中、CSliderCtrlの背景色をCDialog::OnCtlColor経由で変更したところ、背景色が変わらない問題が発生。

CWnd::UpdateWindowCWnd::InvalidateRectを駆使しても効果が無い。
なぜ?とネットを彷徨った際の備忘録(今後使う可能性は低いが)

ソースは下記になります

Sample source code for Demonstration, Experiment and Test - takuya-takeuchi/Demo

Resolution


CSliderCtrlは下記の、少し奇妙な関数を持っています。

  • CSliderCtrl::ClearSel
  • CSliderCtrl::ClearTics
  • CSliderCtrl::SetRange
  • CSliderCtrl::SetRangeMax
  • CSliderCtrl::SetRangeMin

これらの関数は最後の引数に BOOL bRedraw = FALSE をとります。
これらの関数にTRUEを渡すことで背景の更新が可能になります。

Spyで確認したのですが、これらの関数は内部で WM_PAINTを使っているようです。
そのため CWnd::UpdateWindow を使って同じ状況を作り出したにもかかわらず、CWnd::UpdateWindow は効果が無い。

この現象に言及した唯一の記事が下記。

I am working on a C++ MFC project and bumping in the following. I have a CSliderCtrl on my form which I call MFC_scKINECTANGLE. To make it the way I want it ...

上記の関数以外にも、CWnd::EnableWindowでも更新が可能だと言っています。
しかし、この関数を使う場合は、一度現在のEnable/Disableと反対の値を設定する必要があるため、著しくちらつく欠点があります。

ですので、最初に紹介した関数を使うことで、ちらつきを押さえて背景色を更新できます。
つまり、現在の設定と同じ値を使って更新するのです。

後は、SliderをGUIで操作して値を変更することでも背景が更新されますが、コードから変更しないと意味が無いので却下。
サンプルは下記のような感じです。

Source Code

https://github.com/takuya-takeuchi/Demo/tree/master/MFC1