電子情報通信学会 ヒューマンコミュニケーショングループ 食メディア研究会
Multimedia on Cooking and Eating Activities, Human Communication Group, IEICE
[[関係者限定]] - [[国プロ申請案]](別ページが開きます) ''皆様，検討課題の回答をお願いいたします．'' #contents * プロジェクトの概要 [#z24deb68] 料理メディア研究会発足より2年を終えて，多分野より情報提供頂くなかで，メタボ対策・食事療法・医療費削減・食育・食文化・食料自給率・安心安全・コミュニケーション等，料理の支援に関して社会的ニーズがあることを再確認した．料理の専門家のためではなく，一般の利用者の役に立つアプリケーションが求められている．しかし当研究会の若手メンバーがこれまで行ってきた研究の多くは，産業用カメラ，IEEEカメラ，赤外線カメラなど高性能カメラ等，高額なデバイスを使い，数台のPCを使い分散処理するなど，理想的な環境下で動作することを想定していた．また，研究は映像処理やインタラクション部分に注目しており，実際に利用してもらう仕組みに関しては用意していなかった． そこで，このプロジェクトでは，H21〜22年度の2年間で，一般家庭で使ってもらえる実用化アプリを世に送り出すことを目標とする． * アプリケーションの満たすべき条件 [#s8f5e6a0] - 一般家庭で使用できるアプリケーションであること - 一般の主婦・主夫が毎日使いたいと思うアプリケーションであること - 遠隔料理教室のように，一般家庭とつなぐならば，片方がスタジオなど特殊な環境でもいい * 何を支援するのか？ [#t321a926] - 料理の楽しさ - 遠隔地間のコミュニケーション - 安心・安全・健康 * 動作環境 [#s13c2b2d] ** 一般家庭内で使用するリソース [#p829cc62] 当アプリケーションは一般家庭で使ってもらうことが大前提であるため，アプリケーションで使用できるデバイス等は，入手の容易さ，またコスト的にも一般家庭で所有可能なものを使って以下のものとする． - USBカメラ(基本1台，多くて3台) - パソコン（ポータブルPC)1台 - インターネット - ヘッドセット（マイク＋イヤホン/ヘッドフォン/スピーカ） 全部使わなくてもOK. ** スタジオ（研究室）において使用するリソース [#ne199ed6] 料理の専門家と一般家庭とを遠隔通信でつないで料理支援するアプリケーションを考える場合は，料理の専門家側の環境については商用のカメラやマイク，高スペックのコンピュータなどを使用してもよいとする． * 基本仕様 [#z8c7bb5f] ** 使用デバイス [#xb47ac53] - USBカメラ，マイク，ヘッドフォンがつながっていて、Windows、かつインターネットが使える - Windowsの詳細な要件については、再度確認しておきます。 - 仮としてVGA/15fpsと設定 -- フレームレート重視か、画質重視かのご意見を聞きたい． -- 手軽なWebカメラであればVGAが上限とはなるかと思いますが． -- 逆に、いくつか設定可能にして欲しいという意見もあるかと思います ** ソフトウェアの基本仕様 [#db4ea64c] USBカメラなどのデバイスから取り込んだ1フレームごとにプラグインを呼び出すような形式です。 これは以下のようなソフトウェア構成を想定しております。 *** アプリケーション: [#d8329156] - DirectShowでUSBカメラなどからキャプチャする。 - 1フレームごとにプラグインを呼び出す。 -プラグインが処理したフレームを圧縮しRTPで送信する。 *** プラグイン: 情報技研からヘッダファイルなどのSDKを提供 [#n9ddbac5] -アプリケーションからフレームのビットマップのポインタなどを引数として呼び出される。必要に応じて画像処理を行い、リターンする。 （受信側も、同様に１フレームのデコードが完了する度にプラグインを呼び出す） プラグインは、C言語などでDLLとして作成していただき、 それをこちらで作成するアプリケーションから呼び出すという方法を考えています。 * 検討課題（以下に回答してください) [#h27cbfba] ** DirectShowのテンプレートにVC++で記述で大丈夫か？ [#pc7eccc9] - 佐野・宮脇: - 佐野・宮脇:はい．大丈夫です． - 村瀬・井手研： - 美濃研: 恐らく大丈夫です． - 中村研: 大丈夫です．DirectShowを使っている人はいませんが，Linuxにするのは難しいと思いますので：）（テンプレートとプラグインってちょっと違う？） - 山肩: 大丈夫です．というかそれがいいです． ** どのようなAPIがあるとよいか？ [#h0bef534] *** 任意のフレームの取り出し関数は？ [#z116e916] - 佐野・宮脇: - 佐野・宮脇:他の皆様の意見に従います． - 村瀬・井手研：オンラインで処理するためには必要です。アーカイブ的利用の場合は不要（というか同様のことを別方法で実装します） - 美濃研:オンラインで処理する際には，最新のデータだけにアクセスできれば十分です（各時刻でのデータを何らかの形でバッファリングしますが，それが画像そのものである必要はありません）．オフラインで処理する際には，任意とまではいかなくても，順次画像にアクセスできる機能は欲しいです． - 中村研:カメラからもリモートからも（関数呼び出ししたときに）最新のフレームをメモリ上に確保できるだけでOKです．もちろん，そのフレームの撮影時刻や発信時刻がミリ秒単位で分かるとすごくうれしいですが，撮影時刻のほうは難しいですよね．発信時刻も映像埋め込みになりそうですが，そういうのってRTPの枠組みにないのでしょうか？ - 山肩: 次の2種類がほしいです． -- 接続しているカメラから送られてくる映像より，現時点で最も最後に送られてきたフレームを取り出す関数 -- リモートから配信されてきた映像より，nフレームごと，あるいはn秒ごとのフレームを取り出す関数 取り出さなかったフレームについては，捨てるか，記録するかを選べると嬉しいです． *** ストリームに同期したメッセージング関数は？ [#j5f1a413] - 佐野・宮脇: - 佐野・宮脇:他の皆様の意見に従います． - 村瀬・井手研： - 美濃研:下記山肩さんのご意見と同じです． - 中村研:非同期でOKですが，フレームと番号などで対応付けられるといいですね． - 山肩: カメラやマイクで得た情報を処理して，映像に添付して送りたいと思っています．映像との同期は，処理終了を待ってあわせて送ると映像の配信が遅れてしまうので，処理後のデータに処理対象のフレーム番号でも付けることとして，特に必要ありません． *** その他，必要な関数は？ [#yb3f0f78] - 辻（参考意見）：フレーム単位に任意のメタデータ（自由な16bytesとか）を埋め込めるとか？ - 佐野・宮脇: - 村瀬・井手研： - 美濃研:アーカイブの閲覧機能もリアルタイム配信のPlayerと同様のもので提供いただけるのであれば，リアルタイム配信に加えてSeekやPlayが欲しいです（リアルタイム配信ではSeekは不要ですよね…）． - 中村研:今のところ特に思いつきません． - 山肩: -- 処理後の画像データのシーケンスを配信するのと同じフォーマットの映像に順次変換・保存する関数 -- 映像なしのデータのみをリモートに送る関数 -- 映像なしのデータのみで送られてきたデータを取り込む関数 -- 「フレーム単位に任意のメタデータ（自由な16bytesとか）を埋め込める」関数は汎用性がありそうなので是非ほしいです． ** エンコードのコーデックは？ [#p05a54a2] - 辻（参考意見）： -- エンコードの必要性はありますでしょうか？ -- 研究用途で画質重視の場合もあることから、inter-frame処理を行わないMotion-Jpegの方がよかったりしますかね？ -- コーデックはMPEG2/MPEG4あたりでしょうが、案外MPEG4はコーデックの遅延も大きかったりするかも？です。 - 佐野・宮脇: - 村瀬・井手研：うちもMotionJpegとMPEG2かな。 - 美濃研:ご提案の通りで結構です． - 中村研:MotionJpegとMPEGを選びたいですね：） - 山肩: たしかに配信されてきた映像の画像処理を考えるならinter-frame処理は行わないに越したことはないと思いますが，Motion-Jpegだとデータ量が多いことによる問題が起きないでしょうか？（遅延やフレーム落ちが起こるとか）選べると一番嬉しいですが・・・ ** 複数のカメラに対応する必要性は？ [#bac1a3e4] *** 最大何台か？ [#jf425235] - 辻（参考意見): -- 1台のPCで扱えるカメラの数は、CPUの処理能力、フレームレート、解像度などで変わってくると思いますが、最近の製品なら1台のPCで少なくともカメラ2台は扱えると思います。 -- カメラを4台接続して同時にキャプチャしながら画像処理を行いストリームに流すような使い方では、 例えば4コアのCPUを使うなど、やや高価なPCが必要になると思います。 - 佐野・宮脇: - 村瀬・井手研：ひとまずは1台で。台数が増えてもこちらの処理はあまり変わらないはずですが。 - 美濃研: こちらもひとまずは1台で結構です．（自宅キッチンは変な柱があいだに挟まっているので，多分3台でもカバーできない…） - 中村研: キッチンがカバーできるだけのカメラが…というのが実際のところです． - 山肩: 最大3台をUSBハブ経由で接続 *** 複数台使用する場合は，それらのカメラをどう使用するつもりか？ [#mb3f989d] - 佐野・宮脇: - 村瀬・井手研：同一対象を撮影するなら、複数台使うことで、動作検出の性能向上に使えるかもしれません。別対象を撮影するなら、調理場所が異なる様々な動作を分類できるようになるかも。 - 美濃研:観測できない範囲を極力減らすことが目的となり，ユーザが映っていない映像は処理しないという，中村研と同じ使い方ですかね． - 中村研:まずどのカメラの位置にユーザがいるか特定して，その後はユーザの写っているカメラしか処理しません． - 山肩: n秒ごと，3台のカメラからそれぞれ一番最近送られてきた画像を取り出し，処理して1枚の画像に編集しなおす，あるいは3枚の画像のうち1枚を選択して，1枚の画像にしてリモートに送ります．CPUパワーが低くて処理が間にあわない分は，フレームレートを下げて対応します（よって，各カメラから画像を取り込んだ時間がずれていても仕方がないとします） ** 双方向通信をするときに許容される遅延は？ [#ma21c7b3] - 辻（参考意見）： -- どの程度の遅延が予想されるかは、ネットワーク環境次第です。 -- 大前提として、パケット落ちを許容するかしないかで大きく変わります。 -- UDPでパケット落ちを許容してもらえるのであれば、ある程度遅延は抑えられると思います。 -- また、遅延の揺らぎに対してどこまで許容してもらえるかもポイントです。 -- 遅延の揺らぎを吸収するためにはある程度のバッファが必要で、バッファを大きくすると安定しますが、遅延は大きくなってしまいます。 -- 片方向品質重視、双方向遅延重視によって方針は大きく変わります。 - 佐野・宮脇: - 村瀬・井手研：アーカイブ的使用の場合、気にしませんが、フレームが落ちるのは気になります。 - 美濃研:いまのところアーカイブ的使用のため，特に問題ありません． - 中村研:全生徒が話しているか否かを判断する必要があります．1秒ほど遅延しただけでもインタラクションは滞りますが，致命的というほどではありません．パケット落ちは問題ないので，UDPで遅延少なめモードを選べるとうれしいです． - 山肩: 私のアプリケーションでは，画像処理はカメラを接続しているローカルPCで行うこととし，配信映像はあくまで人間が見る用です（送った先で画像処理はしない）．なので，パケット落ちを許容するので，なるべく遅延が少ないほうがいいです．多少不安定でも，遅延の揺らぎも小さいほうがいいです (skypeと同じ感じで）．双方向遅延重視です． ** 1対多通信が必要か？必要ならばどういうものか？ [#jeced026] - 辻（参考意見）：例えばNOVAでやっているような画面分割での通信なら，4分割くらいであればできるかとおもいますが、 16分割レベルだと、ちょっと最初は勘弁してくださいといった感じです（汗。 - 佐野・宮脇: - 村瀬・井手研：ひとまず、関係ないと思います。 - 美濃研:いまのところアーカイブ的使用のため…． - 中村研:ベースアプリとしてもやはり一対多のほうが良いように思います．人数はこだわりありません．（一対多というのを完全に理解できていませんが，ある生徒が他の生徒の話している内容を知ることができないとちょっと困ります） - 山肩:1対4で十分です（遅延のある遠隔コミュニケーションで，1名の先生が相手にできる生徒の数は4名が限界だと思います） ** フレームワーク管理体系はどうしましょうか？ [#ja98b273] - 辻（参考意見）： -- 一番簡単なのは、アプリの特定ディレクトリに作成したプラグインのDLLを入れれば適用されるという方法です。 -- もう少し踏み込むと、複数のプラグインがある場合にどれをロードするかを選択できるユーザーインターフェースを用意すれば、いくつかのプラグインを切り替えて試してみられます。 -- また適当なWebサーバを用意して、作成したプラグインのバイナリをアップロード/ダウンロードできるようにしておけば、 「ユーザーが自分でダウンロードして所定のディレクトリに保存する」という方法で試せると思います。（これが素敵です by 尾関） *** 各研究チーム毎にカスタマイズしたい？ [#q574b47d] - 佐野・宮脇: - 村瀬・井手研： - 美濃研:全チームで共通の方がいいと思います． - 中村研:本体はカスタマイズしないで済ませたいですね．ベースアプリが分岐するのは避けたいところです．ところで，参加者全員がインストールしなくてはいけないアプリはどのようにして全参加者に伝えるのでしょう． - 山肩:すみません，この質問に答えるには私は理解が足りていません(T T)皆様がいいと思うのものを使わせていただきたいなと・・・ *** 共用するのであれば機能管理、ユーザ管理体系は？あなたの研究室は担当できますか？[ネットワーク的にムリ?やろうと思えばできる?] [#u679ed35] - 佐野・宮脇: - 村瀬・井手研：ネットワーク的には可能ですが、人的資源が足りないかもしれません。出口さん次第です。 - 美濃研:機能管理については，大規模開発の経験が浅いため辛いです．ネットワーク的には可能だと思います．人的資源はうちも乏しいですが… - 中村研:いまは人的に無理ですが，中村先生に興味を持っていただき，助教のどちらかが料理研究に関われば可能かもしれません． - 山肩:ネットワーク的に無理です・・・すみません． ** 映像の解像度，フレームレートは？ [#a1579501] - 辻（参考意見）：発表資料にあった「VGA/15fps」については仮置きしたもので、むしろ、フレームレート重視か、画質重視かのご意見を聞きたいです。手軽なWebカメラであればVGAが上限とはなるかと思いますが。 - 佐野・宮脇: - 村瀬・井手研：VGAでいいですが、あまり圧縮はかけないでほしいです。フレームレートは15fpsを切ると辛くなってくると思います。じゃあ12fpsじゃダメかと言われると、多分いけますが。。。 - 美濃研:QVGA以上は欲しいですが，基本的には解像度よりも画質重視です（カメラ依存でしょうが…）． - 中村研:解像度はVGAで十二分です．ノイズのほうが嫌ですね，フレーム間差分を使うと思いますので．うちはフレームレートは7.5fpsくらいまで下がっても大丈夫だと思います． - 山肩: 手軽なWebカメラの使用を想定しているので，VGAでOKです．フレームレートも15fpsで大丈夫です．