Intel Edisonでタイムラプス撮影 その2

大体の下準備は済んだので、実際に撮影しながら色々と試してみた。

pkTriggerCord

--resolutionで解像度を変更しても、ダウンロードされるjpegファイルには反映されないバグがあると書かれているけれども、実際に試してみると保存されるjpegは指定した解像度になっている。
ただし、不思議なことにカメラからの転送にかかる時間は解像度に関わらず4秒ちょっとかかる。RAWで撮影するとサイズが大きくなるのでもっと時間がかかるけれども、jpegだと解像度/サイズに関わらず4秒ちょっとかかる。
ダウンロードした後にリサイズでもしているんだろうか? 最大解像度でも最低解像度でも同じ時間がかかるなら、最大解像度で残しておくに越したことはない。それに10秒毎に撮影するなら余裕だし、6秒毎に1時間くらい撮影してみたけれども常に4秒以上5秒未満だった。

ImageMagick (GraphicsMagick)

撮影画像を16:9のアスペクト比にクロップして、さらに1920x1080にリサイズすると、1枚処理するのに20秒くらいかかる。これでは撮影間隔に比べて時間がかかり過ぎる。ImageMagickから派生したGraphicsMagickは処理が早いということなので、試してみると少し短かくなって15秒くらいだった。できれば撮影間隔と同じか短かい時間に抑えたいので、15秒でも遅い。試しにリサイズをやめてクロップだけにしてみると、10秒くらいかかることが分った。
単純に先頭と後尾の部分を読み飛ばして16:9にクロップするプログラムを、libjpegを使ってCで書いてみたけど、IM/GMと同様に10秒くらいかかった。(同じライブラリを使用しているのだから、当然の結果か?) 何とかならないかなぁとlibjpegのマニュアルを読んでいたら、デコードの段階でスケール(scale_numとscale_denom)を変更すると非常に早くなると書いてあった。K20Dの最高解像度は4672x3104なので、1/2にしても1920x1080よりは大きい。そこで1/2のスケールでデコードしてみた。すると3秒まで縮んだ。

OpenCV

自作のクロップ プログラムが出力したファイルをImageMagickでリサイズしてもいいけれども、ファイルI/Oが増えることになるし、クロップと同時にリサイズもやってしまうことにした。OpenCVライブラリが既にパッケージになっていたので、opkgでインストールして利用した。リサイズにかかる時間は実行時間にほとんど影響がないくらい速く、リサイズのコードを追加した後でも3秒くらいのままだった。これなら撮影間隔未満なので十分と言える。
余談になるけれど、libjpegとOpenCVではメモリに展開したイメージデータの構造が同じなので、そのまま受け渡しができた。ただしRGBデータの順序が違っている。本来ならば、データを受け渡しする際に順序を揃えなければならないし、順序を変更するためのメソッドも用意されていた。けれども、リサイズだけなら色情報は関係ないんじゃないかと思い、順序の変更なしにリサイズ処理をしてみたら、予想通り問題無くリサイズできた。

inotify-tools

pkTriggerCordが撮影して保存が完了するのに合わせて、クロップ/リサイズ プログラムを走らせる必要がある。inotifywaitというコマンドがちょうどその用途に合っているのだけれども、Intel Edisonにはインストールされておらず、opkgにもなかった。
inotifyの仕組み自体はカーネルの機能らしいので、inotify-toolsをgitからcloneしてインストールしてみた。インストールは、
# ./autogen.sh
を実行するとconfigureが生成されるので、
# ./configure
を実行して、あとはmakeとmake installするだけ。
テストしてみたところ問題無く動いている。

これで、撮影しながら同時に画像変換もできるようになった。