ScilabのIPCV使わせていただいていて、Helpファイルのサンプルが正常に動かね～とかいう事態はアリガチ。今回もオブジェクト・トラッキングを行おうとしたらいけません。IPCVの関数がイケない？のかと疑ったらば、まさかの「矩形描画」関数の問題みたい。IPCVの関数は濡れ衣？代替手段ありーのでなんとかなったけれども。
※「手習ひデジタル信号処理」投稿順 Indexはこちら
※Windows11上の Scilab2024.0.0およびScilab上のScilab IPCVツールボックスを使用させていただいております。
Object Tracking
一連の画像（動画から切り出したフレーム等）の中を「動く」オブジェクトを「おっかけ」て行く処理であります。処理の手順としては以下みたいです。
-
- imtrack_init関数で、ターゲットのオブジェクトを指定し「トラッカー」を作成する
- imtrack_update関数に、続きの画像を食わせて、ターゲット・オブジェクトの位置をトラッキングする
- imtrack_unloadall関数で、トラッカーを閉じる
画像の枚数だけ２のステップを繰り返すことになります。またトラッキングのアルゴリズムについては以下をサポートしているみたいです。
BOOSTING, CSRT, GOTURN, KCF, MEDIANFLOW, MOSSE
今回はHELPファイルで使っていたCSRTというアルゴリズムを使ってみましたが、アルゴリズムをいろいろ変えて調べてみるのも面白い？
しかし、上記の手順をみれば当然、複数の関数が「記憶」を共有して連動する必要あり。この手の処理では、なにやら過去の履歴が悪さをすることもあり。警戒しながらHelpファイルの処理を行ってみました。
結果はこんな感じ。
ダメじゃん！ 緑の枠をみると移動する車を何やらトラッキングしているような雰囲気は出ているけれども、肝心の元画像が潰れてます。次々と縦に圧縮されとるような？
最初、トラッキング処理の何やらが悪いのかと疑って調べてみましたが、さにあらず。どうも悪さをしているのは、IPCVの外の関数である
imrects
のようでした。画像の上に重ねて矩形を描く関数です。なんてこともない関数？そして観察したところでは、１画面の処理は問題ないように見えますが、複数画面に対して何度も imrects 処理を行うと何か良からぬことが起きているようでした。トホホ。聞いてないよう。。。
問題回避の処理例
上記の問題を シンプルな矩形描画の rectangle関数で回避したコードが以下に。
n = aviopen(fullpath(getIPCVpath() + "/images/video.avi"));
S1 = avireadframe(n,1);
S2 = avireadframe(n,5);
S3 = avireadframe(n,10);
S4 = avireadframe(n,15);
rec = [136 49 38 24]';
tracker = imtrack_init(S1,rec,"CSRT");
rec2 = imtrack_update(tracker,S2);
rec3 = imtrack_update(tracker,S3);
rec4 = imtrack_update(tracker,S4);
im1=rectangle(S1, rec', [0 255 0]);
im5=rectangle(S2, rec2', [0 255 0]);
im10=rectangle(S3, rec3', [0 255 0]);
im15=rectangle(S4, rec4', [0 255 0]);
scf(0);
subplot(221); title('Frame 1'); imshow(im1);
subplot(222); title('Frame 5'); imshow(im5);
subplot(223); title('Frame 10'); imshow(im10);
subplot(224); title('Frame 15'); imshow(im15);
imtrack_unloadall();
これでちゃんとトラッキングできてる様子が得られるはず。
処理結果
結果が以下に。
道路を通行して行っているお車１台のトラッキングに成功しております。でもな、簡単すぎんか。まあ、処理例サンプルだし。。。でもその前に疲れたぞ、今回は（も）。