2009/01/21(水) [n年前の日記]
#1 [iappli] ムービー中のパターン検出はある程度できたのだけど
考えてみれば、ムービーの最初・最後に到達したかを、シークバー？の見た目の状態で検出してるので、正確な全フレーム数は出ないよなと。QuickTime Player のコマ送り機能が、正確にコマ送りしてくれてるかどうかも微妙だし。実は数フレーム飛ばしながら表示してたら、かなりアバウトな値が出てきそうな。
そのあたりを考えると、QuickTime形式から連番画像に変換して、連番画像を対象に判別していくほうが良かったのかもしれないなと。連番画像にすれば、前後のフレームをチェックして、フレームが大きく変化したか・特定領域が変化したかを検出することもできたかもしれない。また、画像ファイル数をカウントするだけで、正確な全フレーム数が判っただろうし。まあ、その方法だと、HDDの容量はガンガン食うだろうけど。
そのあたりを考えると、QuickTime形式から連番画像に変換して、連番画像を対象に判別していくほうが良かったのかもしれないなと。連番画像にすれば、前後のフレームをチェックして、フレームが大きく変化したか・特定領域が変化したかを検出することもできたかもしれない。また、画像ファイル数をカウントするだけで、正確な全フレーム数が判っただろうし。まあ、その方法だと、HDDの容量はガンガン食うだろうけど。
◎ メールにサンプルデータが書いてあったのだけど。 :
サンプルの数値データテーブルから、日本語表記のテーブルに、変換スクリプトを通して変換したら、なんだか奇妙なテーブルが出力された。元の数値データを眺めていくと、ヘッダ中のデータ数指定部分と、実際のデータ数が一致していない。
やはり、こういったデータは、スクリプト等を通して、ある程度は自動で数値化・コンピュータに計算させてバイナリ化したほうが良さそうだなと。手打ちで数値データを作っていくと、簡単にミスが発生しそう。いや待て。変換スクリプトにバグがあって変なデータを出力してしまうときもあるだろうし。また、数値データを直接打つほうが打鍵量は圧倒的に少なかったりもするだろうし。そうなると、ちと判断が難しい、のかしら。
やはり、こういったデータは、スクリプト等を通して、ある程度は自動で数値化・コンピュータに計算させてバイナリ化したほうが良さそうだなと。手打ちで数値データを作っていくと、簡単にミスが発生しそう。いや待て。変換スクリプトにバグがあって変なデータを出力してしまうときもあるだろうし。また、数値データを直接打つほうが打鍵量は圧倒的に少なかったりもするだろうし。そうなると、ちと判断が難しい、のかしら。
[ ツッコむ ]
以上です。