サブサンプリング4：4：4 Jpeg保存dllの処理速度計測

前回のVB.netプログラムでｄｌｌ処理時間をｄｌｌのビルド条件を変えて計測した。
ｄｌｌのビルドオプション条件は
  * Debugビルド
  * Releaseビルドで最適化オプション無し
  * Releaseビルドで最大の最適化指定
の3条件で比較した。

使用画像は画素数の異なる以下の5種類。
  * 600 x 400 pix
  * 1860 x 1050 pix
  * 3200 x 2400 pix
  * 7360 x 4912 pix
  * 10000 x 10000 pix

Jpeg品質はQ=95としてみた。
結果は以下の通り。



各条件とも8回の試行の平均値で、処理時間の単位はm Sec.。

Releaseビルドにしても最適化オプション無しではDebugビルドと大差なかった。
（もう少し明瞭なスピード改善があると予想していたのだが・・・）

逆に、最適化は期待以上の改善効果があり、
10000 x 10000 pixでは28秒かかっていた処理が4秒半に短縮されている。
いったい何処をどう最適化させたのかは知らないが、感謝感激である。
コレだけの処理速度が出ればシロート作成プログラムとしては大満足である。

なお、10000 x 10000 pixのBMP画像は多数の画像をベタベタ貼って作った
コラージュ品で約286MBである。
コレを前回のVB.netにかけると、イキナリ以下のエラーが報告され、
表示画像は×印になる。



しかしながら、試しにエラーを無視することにして「続行」を押して続けると・・・
あ～ら不思議。何事も無かったかのように、無事Jpegファイルが完成する。
モチロンJpegファイルはキチンと表示可能で、怪しげなノイズなど微塵も無い。
「足りないメモリ」って何処のメモリで、足りなくってあふれたデータはどうしたんだろ？
（ちなみにQ=100で97.9MB、Q=95で41.2MBのJpegファイルになった）

こういう結果になるのはワタシのPC環境だけなのか、
誰がどんなPC環境でやっても同じことになるのかは知らんけど・・・

兎も角、Jpeg保存dllは完成した。
めでたし、めでたし

4：4：4 Jpeg保存dll作成シリーズ終了