ローカルネットワーク上の複数のデバイスに対していくつかの監視機能を実行する小さなAtomベースのMicro-ATXボックスで実行されるシェルスクリプトがあります。この機能の1つは、いくつかのビデオフィード(仮想マシンのスクリーンショットとセキュリティカメラフィード)を重要な変更があるかどうかを監視することです。データをキャプチャすることは問題ではないようですが、画像を比較して変更が重要であることを確認することは、ボックスを殺すことです。
現在の設定で時間がかかる唯一のものはImageMagickのcompare
コマンドです。このコマンドは次のように実行されます。
compare -metric PHASH previous.png current.png null:
これは、画像がどれくらい似ているかを判断するのにかなり便利な数字を提供しますが、永遠にランニング。AE
他の設定など他の指標も試してみましたが、-fuzz
ランタイムの違いはわずかなようです。
私は60K 640x480画像のペアを操作していますが、コマンドを実行するのに約30秒かかります。数GBの空きRAMがあれば、確実にCPUが停止します。コマンドの実行中に、4つのコアがすべて一時停止します。比較のために私のfatsoデスクトップで同じ画像を試しましたが、実行時間はほぼ2秒でした。これは私が達成しようとしている作業に比べてとんでもない量のCPU時間です。
サムネイルを作成し、どれだけ変化したかを確認できるという良いアイデアが浮かび上がりました。簡単です。一致する64x48サムネイルを作成してcompare
実行します。結果は平均約25秒でほとんど区別できませんでした。 6x4ピクセルの画像でさらに圧縮してもプロセス速度は大幅に向上しませんでしたが、それでも実行に約25秒かかりました。
私が間違って設定した可能性がありますか?なぜこれがリソースを大量に使用するのか、そして画像サイズが重要ではないのはなぜですか? 2つの画像が特定のしきい値を超えて漏れていることを確認する別の方法はありますか? (スクリーンショットのデータはピクセル数を強く変更する方がトリックなので簡単ですが、ビデオデータは静的であり、違いの数を把握するにはぼかしが必要です。)
答え1
これはS / Wの問題でもAtomの問題でもないようです。私はArch Linuxを実行するホスト(D945GCLF2)としてAtom 330を持っています。今このテストを行いました。
ttsiod@home ~/tmp
$ wget i.stack.imgur.com/fWwyu.png
--2014-10-29 14:30:08-- https://i.stack.imgur.com/fWwyu.png
Resolving i.stack.imgur.com (i.stack.imgur.com)... 103.31.7.31...
Connecting to i.stack.imgur.com (i.stack.imgur.com)|103.31.7.31|:80...
HTTP request sent, awaiting response... 200 OK
Length: 28576 (28K) [image/png]
Saving to: `fWwyu.png'
100%[==============================>] 28,576 --.-K/s in 0.06s
2014-10-29 14:30:09 (446 KB/s) - `fWwyu.png' saved [28576/28576]
ttsiod@home ~/tmp
$ wget https://i.stack.imgur.com/KQiJX.png
--2014-10-29 14:30:16-- https://i.stack.imgur.com/KQiJX.png
Resolving i.stack.imgur.com (i.stack.imgur.com)... 103.31.6.184
Connecting to i.stack.imgur.com (i.stack.imgur.com)|103.31.6.184|:80...
HTTP request sent, awaiting response... 200 OK
Length: 28212 (28K) [image/png]
Saving to: `KQiJX.png'
100%[==============================>] 28,212 --.-K/s in 0.06s
2014-10-29 14:30:17 (431 KB/s) - `KQiJX.png' saved [28212/28212]
ttsiod@home ~/tmp
$ identify KQiJX.png
KQiJX.png PNG 640x400 640x400+0+0 8-bit sRGB 28.2KB 0.000u 0:00.000
ttsiod@home ~/tmp
$ time compare -metric PHASH fWwyu.png KQiJX.png null:
0.191664
real 0m1.029s
user 0m2.863s
sys 0m0.177s
ttsiod@home ~/tmp
$ time compare -metric PHASH fWwyu.png fWwyu.png null:
0
real 0m1.027s
user 0m2.843s
sys 0m0.190s
compare
したがって、Atom330で2つの640 x 400画像を生成するのに必要な時間は1秒です。これは25秒よりはるかに高速です。
実行中にログ出力がなければstrace -f
私が推測できる唯一のことは...しない)拡張です。 。
しかし、カーネルが制限されないようにするには、まずrootとして次のようにします。
for i in /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor ; do
echo performance > $i
done
その後、テスト中にCPUの温度/周波数を監視しようとします。忘れるまで速度が遅くなりそうです...
compare
完全性のために上記のテストで使用したカーネルとバージョンは次のとおりです。
ttsiod@home ~/tmp
$ egrep '^model.na|^flags' /proc/cpuinfo | sort -u
model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz
flags : fpu vme de tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat clflush dts acpi
mmx fxsr sse sse2 ss ht tm pbe syscall
nx lm constant_tsc arch_perfmon pebs
bts nopl aperfmperf pni dtes64 monitor
ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe
lahf_lm dtherm
ttsiod@home ~/tmp
$ uname -a
Linux home 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13
CEST 2014 x86_64 GNU/Linux
ttsiod@home ~/tmp
$ compare --version
Version: ImageMagick 6.8.9-9 Q16 x86_64 2014-10-26 http://www.imagemagick.o
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC HDRI Modules OpenCL OpenMP
Delegates: bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms lqr ltdl
lzma pangocairo png ps rsvg tiff webp wmf x xml zlib