1.1 研究の目的と背景

現在の情報科学が解決すべき本質的問題とは何か？そう考えたときに、重要なものの一つとして情報検索があげられるであろう。現在さまざまな情報が、新聞・放送・雑誌・インターネットなどを通じて溢れ返っている。我々は特にインターネットにある情報に関してはだれでもいつでもアクセスすることができる。しかしながら、あまりにも多種多様な情報は必ずしも、個人一人一人において重要であるとは限らない。ある人にとってその情報は重要であっても別の人にとっては重要でないということが日常的に起こりうる。インターネットから個人に特化した情報を取ってくるためにWeb検索などの技術が盛んに研究・実用化されている。Webページに対する検索ではGoogle等が有名であり、十分実用的なレベルにあると考えられ、筆者も愛用している。しかし、それはテキスト検索やイメージ検索などに限られ、動画や音楽などのコンテンツに対しての検索は実用化されていない。それはなぜか。その理由は二つあると考えている。第一に、Webページのように無料でいつでも誰でも見られるビデオコンテンツはまだ少ないということ、第二に、ビデオコンテンツに対する検索はテキスト検索に比べて難しく、検索コストがかかることが考えられる。しかしながら、これからの時代、FTTH(Fiber To The Home)やADSL(Asymmetric Digital Subscriber Line )に代表される広帯域インターネットの発達に加え、ビデオカメラの低価格化・ハードディスクの容量増加により個人ページ・商用ページ問わずデジタル動画コンテンツが氾濫する時代がくることは容易に想像される。現在でも毎日膨大に放送されるテレビ放送に対する検索と蓄積は難題であり、また検索・要約等の要求は非常に大きいと考えられる。

動画コンテンツに対する検索には様々な手法があるが、コンピュータで全自動解析した結果を元に検索することは非常に難しい。せいぜい、音声認識と画像のパターンマッチングやオプチカルフロー等を組み合わせるのが限界であり、現状のノイズや環境音に弱い音声認識技術、特殊な条件下でしか機能しない画像処理技術では限界だと思われる。検索の精度を十分に実用的なレベルに引き上げるためにはビデオコンテンツに検索や変換・編集等に有効な意味内容記述（本研究ではアノテーションと呼ぶ）をなんらかの方法により付加する必要がある。そこで、本研究では、動画コンテンツに対し、コンピュータが自動解析した結果をユーザが効率よく修正・補完できるツールを作成した。つまり、コンピュータが得意な問題はコンピュータが自動解析し、人間が得意な問題は人間が担当するという、人とコンピュータの協調作業を支援するツールである。さらにそのツールを使用して得られたXMLアノテーションデータに基づいて、高度な意味的ビデオ検索を、Webブラウザを用いて自然言語で行うシステムを試作した。

動画コンテンツに対する意味内容を記述する規格として、XMLベースのMPEG-7が存在するが、現状ではそれほど普及していない・まだ規格化の段階である・記述方式が複雑であるという理由から採用を見送ったが、将来的には対応も考えている。また、アノテーション一般に言えることだが、コンピュータによる自動解析も含まれるが、ある程度人間が介入する必要がありそれには少なからず労力が必要である。そのために、アノテーションを作成することはナンセンスであるという人もいる。しかし、それは間違いである。アノテーションを必要とせずに動画コンテンツに対する検索ができればそれほど素晴らしいことはないが、動画に対する検索・要約は古くから研究されている分野であるにも関わらずまだ十分な精度で検索できる例はない。それよりも、アノテーションの手助けによって、動画コンテンツに対する検索を実現した方がよいだろう。まだ、アノテーションに対する労力は大きく面倒なものであるが、面倒であればあるほど便利にしようとする欲求が高まり、研究目的が分かりやすくなり、より発展すると考えられる。アノテーション作成が自動化されれば、それは動画コンテンツに対し全自動で解析したといえるわけで、アノテーションによる半自動解析であろうが、全自動解析を目指すものであろうが、最終的な目標は同じである。コンピュータによる全自動解析がトップダウンから攻める技術だとすれば、アノテーションツールの解析はボトムアップから攻める技術である。コンテンツを解析するという点において本質的に両者は同じであり、アノテーションベースの方が機械や人間が何をやっているかを明確に示すことができる分有用であると考えている。また、アノテーションは動画コンテンツ製作者側が使用すればそのコンテンツの内容を正確に相手に伝えるという使い方も可能である。動画を要約する場合は、このように要約して欲しいという製作者側の思いもあるはずなのでそれを動画コンテンツに重要度の形で記述できれば製作者と要約をする編集者（場合によってはユーザ自身）の間での意思疎通が図りやすくなる。

さらに、動画コンテンツにアノテーションを作成する場合、著作権上の問題も考えなければならない。製作者側がアノテーションを作成する分には問題ないが、ユーザが独自にアノテーションを作成して、インターネット等で公開する場合、アノテーションを作成したデータにはシナリオや発言情報の知的財産が含まれる可能性があるので、アノテーションデータを不特定多数の人と共有する場合、知的所有権の問題も考えなければならない。アノテーションはアノテーションを作成する人の主観と機械での自動解析による客観的データが含まれているが、批評や感想の一種であるととらえれば、著作権的に問題ないように思われるが、現行法での正確な捉え方は筆者の理解の範疇を超えるので詳しく追及することはしないが十分な注意が必要であることは留意しなければならない。

動画コンテンツにアノテーションを行ううえで重要なことは、大きく分けて３つあると考えている。１つはアノテーションする負担がなるべく小さいこと。２つ目は、アノテーションしたデータが特定のアプリケーションに依存することなく、検索・要約・編集等さまざまな場面で活用できること。３つ目はアノテーションしたデータの意味を人間・機械ともに一意に特定できることである。それらの点を踏まえたうえで今回の研究を行うことにした。

1.2 本研究で提案するシステムの概要

本研究では、MPEGビデオなどの動画コンテンツに対し、いかにして簡単かつ十分なアノテーションを行うかについて議論し、さらにその支援ツール及び応用システムの実装を目的とする。具体的には、本研究で製作されたツールをもとにして得られたアノテーションデータを元に、自然言語での意味的ビデオ検索を実現した。

本ツールによって作成されるXMLアノテーションデータには、コンピュータによって自動解析されるデータと、ユーザがツールを使って付与されるデータが含まれている。コンピュータによって自動解析されるデータには、動画像に含まれるカットの時間位置や、カラーヒストグラム情報、オブジェクトトラッキング情報などがある。ユーザーがツールを使って付与するデータには、シーンやオブジェクトに対する意味情報をあらわす意味属性情報やコメント情報などが含まれる。さらに、それぞれの意味属性は検索や要約に便利な意味内容も定義されている。つまり、解析されたデータとともに、そのデータの意味する内容も記述されており、アノテーションデータ単独で、意味内容が理解できるよな仕組みになっている。そのために特定のアプリケーションに依存しにくく、永続性・独立性の高いアノテーションデータが得られるように工夫している。

本システムの概要は図のように、インターネットで扱うことを想定したシステムとなっている。複数のユーザがインターネット上に存在するMPEGムービーコンテンツに対し、ビデオアノテーションエディタを用いて、アノテーションデータを作成しそれをデータベースに登録する。現状ではアノテーション管理サーバは未実装であるが、複数ユーザが同一のムービーコンテンツに対してアノテーションする場合などに、バージョン管理や複数データの統合などを考慮する必要がありそのためのサーバとしてアノテーション管理サーバが必要になると考えられる。現在はアノテーション管理サーバは未実装なので直接XMLデータベースにデータを入れている。ユーザが検索サーバに検索要求を出すと、検索サーバがアノテーションデータをもとにして検索を行い、検索結果をWebブラウザに表示する仕組みである。検索結果をユーザに適した形で表示するために、長尾らが開発したSemantic Transcodingも利用することを検討している。

図1.1: システム概略図

また、このアノテーションデータを元にXMLデータベースであるXindiceを用いてデータベースを構築し、Java Servletを用いて、従来は困難だと考えられていた自然言語による動画像検索システムをも試作し、アノテーションとその利用方法についても言及することにより、より実用的なビデオアノテーションについての提案をすることができた。

また、本研究では動画像を映像の立場から研究することにした。音声部分の研究は今回は対象外とした。

2.1 開発環境と動作環境

2.2 カットの自動検出と修正機能

カットの自動検出機能を備える。本研究におけるカットとは、映像の途切れから次の途切れまでの一連のストリーム映像である。カットの自動検出とは、そのカットをコンピュータによる全自動解析により検出する手法である。カットの検出画面は[図に示す。

図2.2: カット検出画面

カット検出アルゴリズムとしては以下のようになる。

DirectShowの機能の一部としてあるSampleGrabberの機能を用いて動画から静止画を１フレームごとにとりだして評価を行う。数フレーム置きに行っても良いが、MPEGなどの圧縮形式は１フレームごとに前フレーム情報を利用してデコードする必要があるため、数フレームごとにやるのは効率がよくないためである。まず個々のフレームにおいてヒストグラムを生成する。本研究ではRGB要素それぞれ４ビット分合計１２ビット、４０９６分割して生成した。ヒストグラムでの前フレームとの比較により、ある閾値以上の差が生じた場合は新たなカットとして検出するプログラムである。さらに、動画の任意での位置で右クリックのコンテキストメニューを選択することにより、カット分割・カット併合をマウスで簡単に行えるようにもした。

カット検出の具体的なアルゴリズムは次のようになる。

1. DirectShowのSampleGrabber機能を使いMPEGコンテンツから静止画をとりだす。

2. RGB要素をそれぞれ4ビット合計１２ビット（４０９６）分割をしてヒストグラムを計算する

3. 前フレームとのヒストグラムの要素ごとの絶対値誤差の合計を求める。

4. 3.の絶対値誤差の合計がある閾値以上になったら、カットであると認識し終了。

5. メディア時間を1フレーム分進めたのち1.に戻る。

このままでもカットの検出は可能であるが、動きが激しいシーンではカットが大量に誤検出してしまう。そこで、動きが激しいカットをひとつのカットであると認識するために以下の手法を用いた。

1. 上記アルゴリズムでカット検出を行う。

2. 1.を繰り返し、8フレーム以内に再びカット検出を行ったら、それをカット検出とはせずに、２へ。

3. １へ飛ぶ。

8フレームとしたのは、秒間３０フレームとすると、0.26秒にあたり、人間の目では、これ以上短いカットはカットと認識しないだろうという限界であると考えたからである。

今回はカメラの物理的なカットごとに分割したので、サッカー中継や講義ビデオなど同じシーンが長く続くような映像に対してのカット検出の自動化には対応していない。それは、講義ビデオ等は物理的なカメラのカットは少なく、話の論理的な推移やPowerPointのスライド等に応じて推移するべきであるからである。しかしながら、手動でカット分割も行えるので映像をみつつ、ここでカットであるということがわかればカット分割も行える仕様ではあり、自動化はされていないものの手動で簡単にカット分割・併合が行えるので、実用上はそれほど問題がないと思われる。

2.3 カット・シーンの重要度の推定と修正機能

カットやシーンに対して、重要度というものがアノテーションできると考えられる。ここでいう重要度とは、そのカットがストーリ上重要なカットであるかをあらわす指標であり、主にビデオコンテンツの要約をする場合などに使える。さらに検索時にも重要なシーンほど上位に検索結果がでるのがよいので検索などにも利用可能であると考えられる。

重要度というものは、ある時（ある検索要求時）には重要であるけれども、そうでない場合はそれほど重要でないという場合もあり、ある意味曖昧な指標である。それでも、ある程度は客観的にこのシーンは重要で、別のシーンは重要でないという事が考えられる。そこで、本ツールはカット一つ一つに対して重要度をアノテーションできる機能もある。さらに、重要度をある程度自動推定する機能もつけた。重要度は基本的に長いカットほど重要であるという過程のもとに以下のようなアルゴリズムを用いた。

おのおののカットに対し重要度の推定と修正機能をつけた。重要度をI、カットの時間をx、全カット数をmのビデオコンテンツの全時間をLとすると、

\begin{displaymath}I = \frac{x m}{L}\end{displaymath}

で表現した。つまり長いカットほど重要ということにしたのだが、もちろんこれでは直感にそぐわない場合もある。その場合カットをShiftキーで押しながらマウスでドラッグすることにより、簡単かつ直感的に重要度を修正できるように工夫している。その様子の操作画面を図に示す。

図2.3: 構造解析と修正画面

映像の長さだけでそのシーンの重要度を推定するのは危険が多い。同じ静止画面が永遠と続く映像と、動きの激しい映像とでは重要度が違うであろうし、無音映像と雑音映像と人が話している映像とではまた重要度は変わってくると考えられる。これらの情報を使いつつシーンの重要度というものを推定することは可能であると思われるが、必ずしも一意で決まるとは思えない。重要度を推定するにはストーリ展開などが重要になってくると思われ、「しかし」、「つまり」などの言葉がストーリを理解するうえでキーとなる言葉であるとは思われるが、それだけでストーリを得る事はできない。そのあたりの重要度の推定は非常に難しくまたあいまいな部分も多く今後の課題となる。むしろその部分は人間が得意な分野であり人間が推定するのが適切であるとも思われる。

2.4 カットの階層構造の推定と修正機能

カットにはシーンごとの固まりなど階層構造が存在すると考えられる。ここでいう階層構造というのは、カットのストーリ上の階層的構造のことでありストーリを理解するために役に立つ。具体的には、ある連続するAというカットとB,C...というカットが同じ内容であるカットであるとするならばそれは、同じシーンであると考えられB,C...というカットはAというカットの子になると考えられる。さらに、もっと大域的なストーリの流れを考えると、起承転結などのストーリ上のまとまりがあるとかんがえられ、それをひとまとまりにすれば、階層構造が表現できると考えられる。このようにして、複数存在するカットを意味的な階層構造により表現できると考えられる。

その階層構造をある程度自動的に推定するためにシーンのまとまりを自動抽出することにした。連続するカットA1, A2, A3, ...とすると、A1とA2が同じシーンであるとの認識にはヒストグラムを用いて、A1のカットの全フレームのヒストグラムの合計をH1、A1のフレーム数をm1、A2の全フレームヒストグラムの合計をH2、A2のフレーム数をm2とするとA1とA2が別シーンである確率Pを

\begin{displaymath}P＝|\frac{H1}{m1} - \frac{H2}{m2}|\end{displaymath}

として、Pがある閾値以上ならば同じシーンであると認識した。ただし、これで検出できる階層構造は二段階までであるので修正機能としては、マウスでドラッグすることにより、階層構造を変更できるようにした。

今回は映像は階層構造であるという前提で研究を行ったが、必ずしも階層構造であるとは限らないと思われる。あるいはグラフ構造であらわせるのかもしれない。特に時系列情報を持ったコンテンツは単純な構造をもたない場合もある。またたとえ存在しても、分かりにくいものもある。しかしながら、カットの集合でシーンが成り立っているなど局所的な階層構造は必ず存在するわけで、階層構造を記述することは悪くないと思われる。

階層構造が表現できれば、検索結果を表示する場合ある特定のカットだけを表示するよりもそれよりも上位階層、つまり１シーンを表示したほうがよいからである。

2.5 内容に関する意味的属性アノテーション

カットやオブジェクトに対してアノテーションを行う場合は、自然言語で無秩序に記述するよりも、あらかじめ登録されている意味属性を入力したほうが、意味内容が一意に捕らえることができ都合がよい場合が多い。また、意味属性をあらかじめカテゴリ化されたメニューからマウスで選択したり数値を選択したりできたとすればそちらのほうがアノテーションしやすく使い勝手がよいと思われる。ただ、意味属性を入力するとすればそれで表現できる事項は限られてしまうので複数の意味属性を組み合わせてやることにより、正確な表現が記述できる。たとえば、若い男が話しているというものをアノテーションしようとする場合、「若い」「男」「話す」という三つの意味属性を同時選択してやればよい。それでも、意味属性の数は膨大になってしまうので、カテゴリわけすることによりある程度意味属性を探しやすくなるように工夫した。具体的には、項目をカテゴリと詳細の二段階に分けた。たとえば、humanのカテゴリには、male,female,young,child,old,adultなどの意味属性があるなど、意味的に分類可能な意味属性を整理している。操作画面を図に示す。

図2.4: 内容に関する意味的属性アノテーションの操作画面

カットに対する意味的属性アノテーションの定義ファイルとして、sceneDefinitions.xmlという定義ファイルを用意した。また、オブジェクトに対するアノテーション定義ファイルとして、objectDefinitions.xmlを用意した。定義ファイルの形式としては以下のリストのようにした。

<?xml version ="1.0" encoding="Shift_JIS"?>
<objectDefinitions version="0.1">
  <category id="カテゴリ意味属性" jp="カテゴリ名（日本語）">
    <item id="詳細意味属性" jp="詳細名（日本語）">
      <synonym word="同義語"/>
               ... (synonymが複数存在)
    </item>
     ... (itemが複数存在)
  </category>
     ... (categoryが複数存在)
</objectDefinitions>

リスト1　objectDefinitions.xmlの定義ファイル形式

<?xml version ="1.0" encoding="Shift_JIS"?>
<sceneDefinitions version="0.1">
  <category id="カテゴリ意味属性" jp="カテゴリ名（日本語）">
    <item id="詳細意味属性" jp="詳細名（日本語）">
      <synonym word="同義語"/>
              ...
    </item>
     ...
  </category>
     ...
</sceneDefinitions>

リスト2　sceneDefinitions.xmlの定義ファイル形式

また、定義ファイルは、ユーザによって追加される場合も想定している。これは、あらかじめ用意された定義ファイルでは適切でないオブジェクトやシーンもあると考えられるためである。しかしながら、単に新しい定義（意味属性）を追加しただけでは、コンピュータはその定義の意味を理解できない。今回は動画コンテンツを自然言語レベルでの取り扱いにしようとしているために、新しく追加される定義（意味属性）に対し、新しい定義に対する同義語を列挙する形でその意味属性の意味を定義した。単なる日本語一語での意味記述では、検索時に完全一致での検索にマッチしないので、複数個同義語を記述することにより一致する可能性が広がるためであると考えている。現段階では複数の意味を手入力で記述しているが、同義語辞典であるシソーラスなどを用いれば、自動入力も可能であると考えている。ただ、単純にシソーラスで追加すると、あまり関連のない語まで追加される可能性があるので、修正を可能にする必要性もあると考えている。

XML定義ファイルには、新たな項目を作るだけでなくその項目の説明をする方法にはRDFスキーマなどグラフ構造を用いた定義の表現方法が存在するが今回はより簡略かつ検索に使いやすいように、新しい項目に関するさまざまな同義語(日本語、英語を含む)を列挙することにした。この方式ならば、手軽に項目追加が可能であるし、検索時に完全一致、あるいは、部分一致が容易であると考えられるからである。

今回は、カテゴリと詳細の二段構成にしたが、かならずしも二段である必然性はなく三段、四段構成である可能性もある。

2.6 オブジェクトトラッキング

ここでいうオブジェクトとは、人や動物、物やテキスト等映像中に登場する独立した物体をいう。テロップや字幕等編集によってつけられた人工データもオブジェクトとする。

オブジェクトにアノテーションをする場合、カットにアノテーションをする場合と同様にそのオブジェクトが出現する時間と消滅する時間を正確に知ることが重要な場合が多い。単なる検索の場合は、その時間は正確である必要性は薄いが、要約や編集等の利用時において重要になる場合が多いからである。そのオブジェクトの動作を追尾する必要があり、手法としては一般的なテンプレートマッチングを採用している。キーフレームのオブジェクト矩形選択範囲との画素間比較により絶対値誤差の合計が閾値以内であればオブジェクトが存在していると認識している。

一般に、MPEG等の圧縮された動画形式はランダムアクセスや逆順シークが苦手である。それは、動画の場合、画面全体の情報を全て記憶しているIフレームからの差分情報を記憶しているために、Iフレームから目的のフレームまで１フレームごとに計算する必要があるためである。しかしながら、動画解析の場合は、時間軸とは逆方向に順に検索したりする必要もあるが、それは非常に効率が悪い。そこで、逆方向にシークする場合は、あらかじめ時間軸過去方向にごとに３秒ごとに無圧縮状態に展開したのちバッファにため処理を行うことにより、高速化する工夫をした。本来ならば、Iフレームを基準に展開するのがすじであるがその方法が分からなかったので、３秒ごとにバッファリングすることにした。

また、トラッキングした時間が正確であるかどうかを認識するために、開始フレームと終了フレームそれにその前後0.1秒のフレームを表示することにより一目で確認できるように工夫している。

オブジェクトトラッキングの操作画面として図に示す。

図2.5: オブジェクトアノテーションの操作画面

2.7 アノテータ情報・コンテンツ情報の付与

アノテーションを行う場合、アノテーションを行う人（本研究ではアノテータと呼ぶ）によってアノテーション結果が大きく異なる場合が多い。そのためにだれがアノテーションしたかという情報が重要であり、それを付与する必要がある。そのためのダイアログも作成した。将来的には、同一のコンテンツに複数の人がアノテーションした場合などにそれぞれのアノテーション結果をマージする等の操作が必要となってくるが、その場合にもアノテータ情報は重要になると考えられるので、その意味もこめて付与した。また、コンテンツ情報を格納するダイアログボックスも作成した。コンテンツのタイトル情報や製作者情報・著作権情報などコンテンツ全体に関わる情報を付与するダイアログである。両ダイアログともWindowsの標準インタフェースを用いている。コンテンツタイトルの操作画面は図に、アノテータ情報の操作画面は図に示す。

図2.6: コンテンツタイトルダイアログ

図2.7: アノテータ情報ダイアログ

2.8 XML形式での入出力

編集結果を保存する形式としてXMLを採用した。これは、将来的にMPEG-7への対応のしやすさと拡張性の高さを配慮したためである。XMLの利点は第一章でも述べたが、拡張性の高さと機種やアプリケーションに依存しない形式、プレーンテキストであるので時代が経ってもデータとしては劣化しない永続性の高さがあげられ、今回みたいな多くの人で共有し残していく事が重要なアノテーションには最適なフォーマットである。欠点として、バイナリデータに比べてファイルサイズが大きくなってしまう事だが、１年で２倍近く伸びるハードディスクの容量を考慮すれば、全くといっていいほど問題ではない。詳しいフォーマットは以下の形式である。

<?xml version="1.0" encoding="Shift_JIS"?>
<VideoAnnotation version="0.1">
  <VideoHeader>
    <filepath>ローカルファイルのパス</filepath>
    <url>インターネット上コンテンツのURL</url>
    <filesize unit="byte">ファイルサイズ</filesize>
    <winsize width="352" height="240"/>
    <description>詳細情報の記述</description>
  </VideoHeader>
  <VideoTitleInfo>
    <title>ビデオコンテンツのタイトル</title>
    <subtitle>サブタイトル</subtitle>
    <creator>製作者</creator>
    <copyright>著作権表示</copyright>
    <description>詳細情報の記述</description>
  </VideoTitleInfo>
  <AnnotatorInfo>
    <author>アノテーションをした人</author>
    <email>foo@hoge.com</email>
    <group>authorの所属グループ</group>
    <url>annotatorのHP</url>
    <address>住所</address>
    <tel>電話番号</tel>
    <post>ポスト</post>
    <description>詳細情報の記述</description>
  </AnnotatorInfo>
  <VideoTracks>
    <track stime="開始時間" etime="終了時間" keytime="キーとなるフレームの時間">
      <histogram r="4" g="4" b="4"> // ヒストグラム情報
        <item r="0" g="0" b="0">0.1112</item>
        ... (itemがr×g×b×個存在)
      </histogram>
      <place>このシーンの場所</place>
      <annotation>
        <item category="カテゴリ意味属性" detail="詳細意味属性"/>
          ... (itemが複数存在)
      </annotation>
      <description>詳細情報の記述</description>
    </track>
     ... (trackが0以上複数存在)
  </VideoTracks>
  <Objects>
    <object stime="開始時間" etime="終了時間" keytime="キーの時間"> // object以下は省略
      <histogram r="4" g="4" b="4"> // ヒストグラム情報
        <item r="0" g="0" b="0">0.1112</item>
        ... (itemがr×g×b×個存在)
      </histogram>
      <name>このオブジェクトの名前</name>
      <trackedRect left="左端" right="右端" top="上" bottom="下"/> // オブジェクトの存在矩形範囲
      <annotation>
        <item category="カテゴリ意味属性" detail="詳細意味属性"/>
          ... (itemが複数存在)
      </annotation>
      <description>詳細情報の記述</description>
    </object>
     ... (objectが0以上複数存在)
  </Objects>
  <VoiceItems>
    <w in="開始時間" out="終了時間">ことば</w>
      ... (wタグが複数存在)
  </VoiceItems>
</VideoAnnotation>

リスト３　出力XMLのフォーマット

フォーマットは、大きく分けると、４つの項目になる。一つ目は、ヘッダ情報を示すタグのタグ。ファイルの存在する位置やファイルサイズ動画フォーマット等を記述している。二つ目は、タイトル情報を示すタグ。ビデオのタイトルや著作権情報が記述されている。三つ目は、アノテーションした人の情報をあらわすタグ。アノテーションした人の名前やメールアドレス等を記述する。四つ目は、シーン情報をあらわすタグ。カットごとにカットの開始時刻と終了時刻およびカラーヒストグラムに選択式アノテーション情報の意味属性等を列挙している。五つ目はオブジェクト情報を示すタグ。オブジェクトの存在する開始時刻と終了時刻それにオブジェクトの存在矩形範囲、選択式アノテーションや記述情報を列挙している。六つ目は音声情報である。音声とその開始時間と終了時間を記述してある。

VideoTracksタグとObjectsタグの中身を説明する。VideoTracksタグの中にはtracksタグが存在する。ひとつのtracksタグでビデオコンテンツのひとつのカットからカットまでのまとまりを示す。Objetctsタグはビデオコンテンツの中に現れるオブジェクトを示す。書式としては以下のようになる。

2.9 アノテーションツールの評価

本ツールの評価であるが、アノテーションツールとして比較になるソフトを持ち合わせていないことと、使いやすさの評価は主観に頼る部分が多く、定量的な評価が難しい。が、カット検出等一部で定量的な評価ができる部分が存在するので、その部分の定量的評価を行ってみたい。

2.9.1 カット検出の評価

カット検出の精度について評価を行う。評価に利用するコンテンツは、56個のニュース映像から無作為にとりだした6つのニュース映像を利用している。

表2.1:

実験方法は、本ツールを使ってカットの自動検出を行った。修正機能等は利用していない。正しく認識したカット数を正検出数、本来カットではない部分をカットであると認識した数は、誤検出数、本来カットである部分をカットであると認識した部分の数を、未検出数として実験を行った。閾値等のパラメータはすべての映像で同一にした。なお検出率は以下の式により計算した。

\begin{displaymath}(検出率) = \frac{(正検出数) - (誤検出数)}{(正検出数) + (未検出数)}\end{displaymath}

表2.2:

全ての正検出数・誤検出数・未検出数をそれぞれ足したものでの検出率は92.5%である。

誤検出の例としては、図のように同じカットではあるものの、信号の色が赤になるなどの場合は、カットとして検出してしまう。未検出の例としては。図のように、画面全体の色変化がおきないでカットが変わる場合などである。

図2.8: 誤検出例：信号の色が変わってる事により新たなカットであると誤検出している例

図2.9: 未検出例：映像が左から右へと徐々に変わっていく例

誤検出や未検出の主要因は、画面全体のヒストグラムを求めているので局所的な変化に対応していない点である。単純なヒストグラムではなく位置情報も考慮した手法を考えなければならないと考えている。

3.1 使用したデータベースと開発環境

本研究では、XMLデータベースとして、Xindiceを用いた。XindiceはApacheによって作られたネイティブXMLデータベースであり、XPathを用いたデータベース検索ができるという特徴があり、MPEG-7や本アノテーションデータなど、XMLデータの蓄積には適したデータベースである。また、サーバサイドのプログラミング環境として、Sun Java Developer Kit 1.41を使用しApatchとTomcatを連携させたサーバでの検索をしている。

しかしながら、XindiceはJavaベースのデータベースであり検索・特に全文部分一致検索(contains関数)が非常に遅いという欠点がある。そのために、なるべくcontains関数を使わない検索アルゴリズムを心がけているが、Xindiceを使う以上ある程度の遅さは我慢しなければならない。当研究室ではXindiceの高速化に関する研究も行っているが残念ながら、本研究によって作られたアノテーションデータには適用しても十分な高速化が図れないので採用は見送った。

3.2 検索アルゴリズム

検索は、本研究で作られたXMLデータをXindiceに登録したデータを元に検索している。データベースに登録されている情報としては、動画コンテンツに対するタイトル情報とアノテーション情報、カットとオブジェクトに対するカラーヒストグラム情報や選択式アノテーションによる意味属性情報とその意味属性の意味内容記述（ここではその意味属性が意味する言葉とその類義語の列挙）カットとオブジェクトの存在時間範囲とオブジェクトの存在位置、動画の音声部分の音声認識結果とその存在時間が登録されている。

本研究の特徴としては、人間が介在する意味属性の付与と、基本的に全自動解析されるヒストグラム情報やオブジェクトトラッキング結果、カット検出結果のみを用いて検索を行っており、人間と機械の両方のアノテーション結果をうまく使い分けている点である。

本研究では主に、マウスで選択するだけで簡単にアノテーションできる意味属性情報とコンピュータで自動抽出されるカラーヒストグラム情報と、オブジェクトおよびカットの存在時間範囲だけを利用して検索を行っている。音声部分の情報や、キーボードで情報を入力したものは利用しておらず、人間が介在する部分は意味属性の付与とオブジェクトの存在時間範囲の修正のみである。

この条件のもとに、以下のアルゴリズムを用いて検索を行った。

1. まず第一段階として、検索キーワードの形態素解析を行った。形態素解析には、茶筅という形態素解析のソフトを用いて行っている。その茶筅から、動詞・形容詞・名詞・未知語をキーワードとして使用している。なお、未知語とは茶筅に登録されていない単語であり、名詞や英語などの場合が多い。今回は未知語を全て名詞と仮定して使用している。

2. 次に、形容詞・名詞から色や明暗を表す単語（たとえば、赤い・黒い・青い・暗い・明るい等）を色を表現する単語として認識した。色を表現する単語（便宜上、色名詞と呼ぶことにする）は、アノテーションデータの中に含まれるカラーヒストグラムとのマッチングを行うために使用するためである。

3. 検索アルゴリズムには、基本的にアノテーションデータと検索キーワードの形態素解析済み単語（名詞・形容詞・動詞・未知語）との完全一致した場合、そのオブジェクトやシーンに対して得点をつけ、得点が高い順に検索結果をソートする方式を取っている。アノテーションデータには、シーンやカット情報を表す「track」XMLツリーと、人や物などをあらわす「object」XMLツリーの集合が存在している。検索キーワードの中に場面やシーンを表す語、具体的には「場面」「光景」「風景」「シーン」「画面」「様子」等が含まれている場合はオブジェクト情報をあらわす