ルックデータ定義及び高精細マルチメディアインタフェース上の伝送のための方法及びシステム
ルックデータ定義及び高精細マルチメディアインタフェース（ＨＤＭＩ）上の伝送のための方法及びシステムが提供される。当該方法は、ビデオコンテンツについてのメタデータを生成するステップを含む。当該メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を説明することでビデオコンテンツを表示前に修正するために用いられる。当該方法は、高精細マルチメディアインタフェース上の伝送のために当該ビデオコンテンツ及び当該メタデータを準備するステップを更に含む。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、非仮出願である「ルックデータ定義及び伝送のための方法及びシステム」と題する代理人文書番号ＰＵ０７０３０７号に関連し、該出願は共通に譲渡されその内容が引用によって本明細書に完全に組み入れられて共にここで出願される。
【０００２】
本原理は概略マルチメディアインタフェースに関する。特に、本原理は、特に詳細にはルックデータ定義及び高精細マルチメディアインタフェース（ＨＤＭＩ）上の伝送のための方法及びシステムに関する。
【背景技術】
【０００３】
現在、家庭使用又は専門家使用の何れかのためにビデオコンテンツ製品を配布する際には、そのビデオ配布製品についてなされた単一の色決定が存在し、これは通常、ビデオコンテンツクリエーターの意図の顕れである。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、コンテンツの色決定が改変されなければならないような、コンテンツに異なる使用実態が発生している。斯かる異なった使用実態は、例えば、フロントプロジェクションディスプレイ、直接視ディスプレイ又は携帯ディスプレイの如き異なるディスプレイタイプで発生し、これら各々は斯かるビデオコンテンツの最適表示を提供するために色決定に対して幾らかの変更を必要としている。
【課題を解決するための手段】
【０００５】
本原理の様々な実施形態に従った方法及びシステムは、ルックデータ定義及び高精細マルチメディアインタフェース（ＨＤＭＩ）上の伝送を提供することによって上記従来技術の欠点を解決する。
【０００６】
本原理のある態様による方法が提供される。本発明方法は、ビデオコンテンツのためのメタデータを生成するステップを含む。上記メタデータは、異なる表示装置間の多様性(variations)及びコンテンツクリエーターよる異なる創作意図間の多様性を説明する(account for)ことよって、その表示前に上記ビデオコンテンツを修正(alter)するためのデータである。上記方法は、高精細マルチメディアインタフェース上の伝送のために上記ビデオコンテンツ及び上記メタデータを準備するステップを含む。
【０００７】
本原理の別の態様によるシステムが提供される。本発明システムは、メタデータ生成器及びメタデータ伝送準備装置を含む。上記メタデータ生成器はビデオコンテンツのためのメタデータを生成するための装置である。上記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターよる異なる創作意図間の多様性を説明することよって、その表示前に上記ビデオコンテンツを修正するためのデータである。上記メタデータ伝送準備装置は高精細マルチメディアインタフェース上の伝送のために上記ビデオコンテンツ及び上記メタデータを準備する装置である。
【０００８】
本原理の教示は添付の図面と共に以降の発明の詳細な説明を考慮することよって容易に理解され得る。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に従って高精細マルチメディアインタフェース接続上でルックデータを送信するシステム１００の上位のブロック図である。
【図２】本発明の実施形態に従って連続したルックデータ伝送を実現している図１のシステム１００のより詳細な上位のブロック図である。
【図３】本発明の変形例に従って並行したルックデータ伝送を実現している図１のシステム１００のより詳細な上位のブロック図である。
【図４】本発明の実施形態に従ってルックデータ定義及び伝送のための方法を示すフローチャートである。
【図５】本原理の実施形態に従ってルックデータ５００の例示的な表現を示す図である。
【図６】本発明の実施形態に従ってルックデータエレメンタリメッセージにおける使用のためのメタデータ６００の例示的なＫＬＶ表記を示す図である。
【図７】本発明の実施形態に従って図６のメタデータ６００のＫＬＶ表記を更に詳細に示す図である。
【図８】本発明の実施形態に従って、８ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ８００を示す図である。
【図９】本発明の実施形態に従って、１０ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ９００を示す図である。
【図１０】本発明の実施形態に従って、８ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１０００を示す図である。
【図１１】本発明の実施形態に従って、１０ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１１００を示す図である。
【図１２】本発明の実施形態に従って、８ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１２００を示す図である。
【図１３】本発明の実施形態に従って、１０ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１３００を示す図である。
【図１４】本発明の実施形態に従って、１６ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１４００を示す図である。
【図１５】本発明の実施形態に従った、周波数レスポンス変更のための例示的なフィルタバンク１５００を示す図である。
【図１６】本発明の実施形態に従った、周波数イコライゼイションのための離散的な周波数１６００を示す図である。
【図１７】本発明の実施形態に従った、８ビット周波数イコライゼイションのための例示的なルックデータエレメンタリメッセージ１７００を示す図である。
【図１８】本発明の実施形態に従った、モーション挙動のための例示的なルックデータエレメンタリメッセージ１８００を示す図である。
【図１９】本発明の実施形態に従った、フィルム粒子のための例示的なルックデータエレメンタリメッセージ１９００を示す図である。
【図２０】本発明の実施形態に従った、ノイズのための例示的なルックデータエレメンタリメッセージ２０００を示す図である。
【図２１】本発明の実施形態に従った、編集上の制御に用いられ得る時間編集のための例示的なルックデータエレメンタリメッセージ２１００を示す図である。
【図２２】本発明の実施形態に従った、トーンマッピングのための例示的なルックデータエレメンタリメッセージ２２００を示す図である。
【図２３】本発明の実施形態に従った、本発明の実施形態が適用され得る例示的なＨＤＭＩ色域メタデータパケット２３００を示す図である。
【図２４】本発明の実施形態に従った、本発明が適用され得る例示的なＨＤＭＩ色域メタデータヘッダ２４００を示す図である。
【図２５】本発明が本発明の実施形態に従って適用され得るＨＤＭＩバージョン１．３における例示的な色域メタデータパッケージ２５００を示す図である。
【図２６】本発明の実施形態に従った、ベンダー指定のインフォ（info）フレームのための例示的なルックデータパケットヘッダ２６００を示す図である。
【図２７】本発明の実施形態に従った、本原理が適用され得るＣＥＡ８６１Ｄにおける例示的なベンダー指定のインフォフレーム２７００を示す図である。
【図２８】本発明の実施形態に従ってルックデータを送信するための例示的なベンダー指定のＣＥＣ命令２８００を示す図である。
【図２９】本発明の実施形態に従った、家電エレクトロニクスコントロールバスの用途のための例示的なネットワークレイヤモデル２９００を示す図である。
【図３０】本発明の実施形態に従った、ＣＥＣベンダー指定コマンドによるアプリケーション通信への適用を提供する例示的なＣＥＣプロセッシング３０００の上位のブロック図である。
【図３１】本発明の実施形態に従った、ＨＤＭＩを用いた伝送のためのフレームへのルックデータパケットの例示的な変換３１００を例示している上位のブロック図である。
【図３２】本発明の実施形態に従った、ルックデータ検証のための例示的なルックデータエレメンタリメッセージ３２００を示す図である。
【図３３】本発明の実施形態に従った、ＣＥＣ検証信号を生成する例示的な装置３３００を示す図である。
【図３４】本発明の実施形態に従った、ＣＥＣにおける検証信号伝送のための方法を示すフローチャートである。
【発明を実施するための形態】
【００１０】
図面は、本発明の概念を例示する目的のためにあり、本発明を例示する必ずしも唯一の可能な構成ではないことが理解されるべきである。理解を容易にするために、図面に共通である同一の要素には可能な場合同一の参照番号が付されている。
【００１１】
本原理は、ルックデータ定義及び高精細マルチメディアインタフェース（ＨＤＭＩ）上の伝送のための方法及びシステムを有利に提供する。本原理が発生源装置及び表示装置に関係する伝送システムの文脈内で主に説明されるにも関わらず、本発明の特定の実施形態は本発明の範囲を制限するものとして扱われるべきではない。
【００１２】
図に示される様々な要素の機能は、適切なソフトウェアと協働するソフトウェアを実行し得るハードウェアのみならず、専用ハードウェアの使用を介して提供され得る。プロセッサによって提供される場合、単一の専用プロセッサによって、単一の共有プロセッサよって、又は幾つかが共有され得る複数の個々のプロセッサによって、上記機能が提供され得る。更に、用語「プロセッサ」又は「コントローラ」の明示的な使用は、ソフトウェアを実行し得るハードウェアを排他的に意味するものとして解釈されるべきでなく、制限するものではないが、デジタル信号プロセッサ（「ＤＳＰ」）ハードウェア、ソフトウェア記憶のためのリードオンリーメモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、及び不揮発性記憶装置の使用を黙示的に含み得る。更に、本明細書において本発明の原理、態様及び実施形態、同様にそれらの特定の例を詳述している全ての文言は、それらの構造上及び機能上の均等物を含むことが意図されている。その上、斯かる均等物とは、将来開発される均等物（すなわち、構造に関わりなく同一の機能を実施するように開発された何らかの要素）と同様に現在周知の均等物の双方を含むことが意図される。
【００１３】
このように、例えば、本明細書で提示されているブロック図は、例示のシステムコンポーネントの概念及び／又は本発明の原理を実現している回路を表すことが当業者によって認識されるであろう。同様に、何らかのフローチャート、フローダイヤグラム、状態遷移図、疑似コード、及び同様物は様々なプロセスを表し、斯かるプロセスがコンピュータ読取可能媒体で実質的に表現され、コンピュータ若しくはプロセッサが明示的に示されているか否かに関わらず、斯かるコンピュータ若しくはプロセッサよって実行されてもよいことが認識されるであろう。
【００１４】
本原理の「１つの実施形態」及び「ある実施形態」に対する本明細書における参照は、特定の特徴、構造、特性、並びに、実施形態に関連して説明されたものが本原理の少なくとも１つの実施形態に含まれることを意味する。このように、本明細書の全体にわたって様々な所で現れる語句「１つの実施形態において」又は「ある実施形態において」とは必ずしも同一の実施形態全てを意味しない。
【００１５】
更に、本明細書で用いられるように、メタデータの伝送及び受信に関して、語句「帯動（in-band）」とは、斯かるメタデータと共に、消費者装置よって表示されるべき色修正された画像コンテンツを送信すること及び／又は受信することを意味する。対照的に、語句「非帯動（out-of-band）」とは、消費者装置よって表示されるべき色修正された画像コンテンツとは別に、斯かるメタデータを送信すること及び／又は受信することを意味する。
【００１６】
更に、本明細書で用いられるように、用語「シーン」とは、単一の「ショット」を元にして通常発生する動画像におけるある範囲の画像フレームを意味し、シーン変化間の一連の連続撮影を意味する。
【００１７】
また、本明細書で用いられるように、語句「ルックデータ管理」とはルックデータの編集、伝送及び適用を意味する。
【００１８】
その上、本明細書で用いられるように、語句「コンパクトディスクプレーヤ」とは、標準規格のコンパクトディスクプレーヤ、ブルーレイデジタルビデオディスクプレーヤ、高精細デジタルビデオディスクプレーヤ、その他を意味する。
【００１９】
更に、本明細書で用いられるように、「未使用色域プロファイル(unused gamut profile)」とは、ＨＤＭＩ標準のバージョン１．３（又は何らかの先行バージョン）において現在使われない色域プロファイルを意味する。
【００２０】
更に、本明細書で用いられるように、語句「ルックデータ」、及び斯かるルックデータに関連する用語「メタデータ」とは、色操作、空間フィルタリング処理、モーション挙動、フィルム粒子、ノイズ、編集及びトーンマッピング等について及び／又は関連する、例えば、整数、非整数値、及び／又はブール値の如き形式のデータを意味する。斯かるルックデータ及び／又はメタデータは、斯かる機能を実現するのに関連する機構を制御、ターンオン、ターンオフするのに用いられ、そしてそれらを修正するのに用いられてもよい。更に、ルックデータ及び／又はメタデータは、マッピングテーブルの仕様を含む。
【００２１】
例えば、色操作を志向する実施形態において、色マッピングテーブルは、１ＤＬＵＴ（１次元のルックアップテーブル）、３次元ＬＵＴ（３次元ルックアップテーブル）及び／又は３×３ＬＵＴによって実現されてもよい。例えば、３次元ＬＵＴの場合、斯かるＬＵＴは３つ入力値を受信するのに用いられ、各値が１つの色成分、例えば赤色、緑色若しくは青色を表し、個々の赤色、緑色及び青色の入力３連値毎に、例えば赤色、緑色及び青色である所定の出力３連値を生成する。この場合、コンテンツ発生源からコンテンツ消費装置（例えば表示装置）へのメタデータはＬＵＴ仕様を含む。
【００２２】
他の実施形態は、マッピング機能の仕様を含んでもよく、例えば、以下の式で定義される「ＧＯＧ」（利得、オフセット、ガンマ）を実行する回路及び／又は機能を含んでもよい。
【００２３】
カラー成分毎に、Ｖｏｕｔ＝Ｇａｉｎ＊（Ｏｆｆｓｅｔ＋Ｖｉｎ）∧ガンマ
斯かる場合、ルックデータ及び／又はメタデータは、９つの値、すなわち３つのカラー成分の各成分毎に利得、オフセット及びガンマからなる１組を含むことになる。
【００２４】
本明細書で用いられるように、ルックデータはこれらメカニズムに作用を与えるように用いられ、１つのだけでなく幾つかのルックデータの伝送／記憶を実現するために、幾つかの組のルックデータがあり得る。
【００２５】
もちろん、本原理は前述の実施形態に限られず、本明細書で提供される本原理の教示が与えられることで、ルックデータ及び／又はメタデータの他の実現を含む他の実施形態が、本原理の趣旨を維持しつつ、当業者によって容易に企図され得る。ルックデータは、本明細書において少なくとも図５に関して更に説明される。
【００２６】
例えば、図１は、本発明の実施形態に従った、ルックデータを高精細マルチメディアインタフェース接続上で送信するためのシステム１００の上位のブロック図を示す。図１のシステム１００は、例示として、コンテンツ発生源装置１１０、高精細マルチメディアインタフェース（ＨＤＭＩ）接続装置１２０、及び、表示装置１３０を含む、及び／又は、伴う。コンテンツ発生源装置１１０は、限定されないが、高精細デジタルビデオディスクプレーヤ、ブルーレイプレーヤ、及びネットワークアクセスユニット（例えば、セットトップボックス（ＳＴＢ））であって良いことが認識されるべきである。コンテンツ発生源装置１１０は、高精細マルチメディアインタフェース接続装置１２０を介してその表示のために表示装置１３０に向けて送信されるべきコンテンツを提供する。例えばルックデータを含んでいるメタデータは、コンテンツ発生源装置１１０から表示装置１３０へ提供され、且つ表示装置１３０からコンテンツ発生源装置１１０へ提供され得る。高精細マルチメディアインタフェース（ＨＤＭＩ）接続装置１２０が、限定するものではないが、高精細マルチメディアインタフェース（ＨＤＭＩ）ケーブルを含むことが認識されるべきである。
【００２７】
表示装置１３０（及び／又は伝送媒体１２０と表示装置１３０との間に配置され且つこれら装置に接続されている装置）は、受信器１６１、記憶装置１６２、及び／又は、メタデータをそれぞれ受信、記憶及び適用するためのメタデータ適用器１６２を含む。
【００２８】
例えば、図２は、本発明の実施形態に従った、連続したルックデータ伝送を用いている図１のシステム１００のより詳細な上位のブロック図を示す。図２の実施形態において、コンテンツ２０２及びルックデータデータベース２０４は、システム１００のコンテンツオーサリング部２１０に配置される。図２の実施形態において、ルックデータベース２０４はルックデータを記憶する。１つの実施形態において、システム１００のコンテンツオーサリング部２１０は、更に以降で説明されるように、ルックデータ２０６を生成するためのルックデータ発生器２８８、及び、ＨＤＭＩ上の伝送のためのルックデータを準備するためのルックデータ伝送準備装置２９９を含む。コンテンツ２０２及びルックデータ２０６は、コンテンツオーサリング部２１０で結合される（２０７）。１つ又はそれよりも多い伝送及び／又は記憶媒体２２０を用いることよって、コンテンツ２０２及びこれに対応するルックデータ２０６は、システム１００のコンテンツ表示部２３０に順番に送られ、ここでコンテンツ２０２及びルックデータ２０６は切り離されて処理される。システム１００のコンテンツ表示部２３０は、例えば図１に示される表示装置１３０を含むことができる。ルックデータ２０６は、システム１００のコンテンツ表示部２３０に配置されるルックデータデータベース２３２に次いで記憶される。図２に示されて伝送及び／又は記憶媒体２２０は、コンテンツ２０２及び／又はルックデータ２０６の連続した伝送及び／又は記憶をまとめていることが認識されるべきである。
【００２９】
図３は、本発明の変形例に従って並行ルックデータ伝送を実現している図１のシステム１００のより詳細な上位のブロック図を示す。図３の実施形態において、コンテンツ３０２及びルックデータデータベース３０４は、システム３００のコンテンツオーサリング部３１０に配置される。図３の実施形態において、ルックデータベース３０４はルックデータ３０６を記憶する。１つの実施形態において、システム３００のコンテンツオーサリング部３１０は、以降で更に説明されるように、ルックデータ３０６を生成するためのルックデータ発生器３８８、及び、ＨＤＭＩ上で伝送するためにルックデータ３０６を準備するルックデータ伝送準備装置３９９を含む。コンテンツ３０２及びルックデータ３０６はコンテンツオーサリング部３１０で結合される（３０７）。１つ又はそれよりも多い伝送及び／又は記憶媒体３２０を用いることよって、コンテンツ３０２及びこれに対応するルックデータ３０６はシステム３００のコンテンツ表示部３３０に並行して送信され、ここでコンテンツ３０２及びルックデータ３０６は切り離されて処理される。システム３００のコンテンツ表示部３３０は、例えば図１に示された表示装置１３０を含むことができる。ルックデータ３０６は、システム３００のコンテンツ表示部３３０に配置されるルックデータデータベース３３２で次いで記憶される。図３に示された伝送及び／又は記憶媒体３２０は、コンテンツ３０２及び／又はルックデータ３０６の並列伝送及び／又は記憶をまとめていることが認識されるべきである。
【００３０】
図４は、本発明の実施形態に従ったルックデータ定義及び伝送のための方法のフローチャートを示す。方法４００はステップ４０２で始まり、ここでルックデータがビデオコンテンツのために生成される。斯かるルックデータは、制限されないが、操作、空間フィルタリング処理、モーション挙動、フィルム粒子、ノイズ、編集、トーンマッピング、その他に関連し得る。斯かるルックデータは、前述の斯かる機能を実現し且つ修正する機構に関連するターンオン及びターンオフを制御するのに用いることができる。本方法は次いでステップ４０４に進む。
【００３１】
ステップ４０４において、ルックデータが伝送のために準備され、限定されないが、ルックデータ（ステップ４０２で以前に生成された）のための１つ又はそれよりも多いルックデータエレメンタリメッセージを生成すること、１つ又はそれよりも多いルックデータエレメンタリメッセージを含む１つ又はそれよりも多いルックデータパケットを生成すること、ルックデータをディスク等に記憶すること、及びその他を含む。本方法は次いでステップ４０６に進む。
【００３２】
ステップ４０６において、ルックデータ及びビデオコンテンツはＨＤＭＩを用いて表示装置に伝送される。斯かる伝送は、限定されないが例として、ＨＤＭＩ色メタデータ、ＣＥＡ／ＨＤＭＩベンダー指定インフォフレーム、ＨＤＭＩ／ＣＥＣ（家電エレクトロニクス制御）プロトコルを用いてなされ得る。上記伝送へのＨＤＭＩ色メタデータの使用に関しては、色域境界記述（ＧＢＤ）メタデータコンテナ（container）を用いることができる。上記伝送へのＣＥＡ／ＨＤＭＩベンダー指定インフォフレームの使用に関して、ＧＢＤフロー制御をベンダー指定インフォフレームに適用することができる。上記伝送へのＨＤＭＩ ＣＥＣプロトコルの使用に関して、ＣＥＣの上にネットワーク抽象レイヤを加えてサービス品質（ＱｏＳ）の使用を可能とし、ビデオに対してＣＥＣの時間合わせをすることができる。本方法は次いでステップ４０８に進む。
【００３３】
ステップ４０８において、ビデオコンテンツが受信され、記憶され、ルックデータに従って修正され、該修正されたビデオコンテンツが表示装置において表示される。方法４００は次いで出口処理され得る。
【００３４】
受信、記憶及び修正の前述の順序は実際の実現形態に依存して変更され得ることが認識されるべきである。例えば、記憶とはメタデータが記憶媒体上で提供されていることに相当し得る、及び／又は、次処理のためのコンテンツ解釈側上での同一物の一時的な記憶に相当し得る。
【００３５】
本発明の１つの実施形態において、高精細デジタルビデオディスク（ＨＤ ＤＶＤ）及び／又はブルーレイディスクのためのコンテンツを作成するのに本発明の原理が用いられ、斯かる作成は、国際標準化機構／国際電気標準会議（ＩＳＯ／Ｉ ＥＣ）動画専門家グループ４（ＭＰＥＧ―４）パート１０先端ビデオ符号化（ＡＶＣ）標準／国際電気通信連合、テレコミニケーション部門（ＩＴＵ−Ｔ）Ｈ．２６４勧告（以下、「ＭＰＥＧ―４ＡＶＣ標準」と称する）に従ってコンテンツをコード化すること、コンテンツをディスクに記憶すること、次いで、表示装置における信号処理装置を制御して表示用のビデオデータを修正すること、によってなされる。斯かる適用において、ルックデータがディスクに記憶される。ルックデータは、次いで高精細マルチメディアインタフェース（ＨＤＭＩ）を用いて表示装置に伝送される。ルックデータを送信するのにＨＤＭＩを用いるための様々な例示的な方法が本明細書において説明される。もちろん、本原理が記載された実施形態にだけに限られず、本明細書において提供される本原理の教示が与えられて、本技術及び関連技術における当業者は、本原理の趣旨を維持しつつ、これら及び他の様々な実施形態及びそれらの変形形態を企図するであろうことが認識されるべきである。
【００３６】
様々な実施形態において、本原理が、限定するものではないが動画製造における「デジタル・デイリーズ（digital dailies）」処理を含む専門的及び準専門的環境で用いることができることが認識されるべきである。
【００３７】
シーン結合データ
図５は、本原理の実施形態に従った、ルックデータ５００の例示的な表現を示す。図５のルックデータ５００は、各シーン毎又はシーケンス、すなわちシーン５１５に１つのルックデータパケット５１０を含む。尚、シーン境界の画定は通常、コンテンツ制作者次第である点に留意する必要がある。図５に図示されるように、各ルックデータパケット（ＬＤＰ）５１０は、１つ又はそれよりも多いルックデータエレメンタリメッセージ５２０を含むことができる。各ルックデータエレメンタリメッセージ（ＬＤＥＭ）は、コンテンツ描画及び／又は表示のために、１つの信号処理装置を制御するパラメータ５２５を含むことができる。より具体的には、本発明の実施形態に従って、ルックデータエレメンタリメッセージ５２０及びパラメータ５２５の如きルックデータパケット５１０は、コンテンツ描画装置を含む表示装置に向けてそれぞれのビデオコンテンツと共に配布されるか又は伝達されるべきことが意図されている。表示システムにおいて、コンテンツ描画装置（例えば、ディスプレイ又はセットトップボックスのデコータ）は、ルックデータパケット５１０をそれぞれのビデオコンテンツに適用し、ルックデータが作成されたシーン又はシーケンス状のシーンの表示属性を、ルックデータエレメンタリメッセージ５２０におけるパラメータに従って作用するか又はこれを変更する。
【００３８】
１つの実施形態において、もしシーン５１５間でルックデータ５００が同一であると判定される場合、シーン変更においてルックデータを更新することによらずして、ルックデータ５００がシーン５１５中で共有され得る。このように、ルックデータ５００は、ルックデータ５００が無効にされるか又は更新される迄、有効なままである。斯かる無効は、「ルックデータエレメンタリメッセージ」における「データ有効」タグを「無効」に設定することよってＬＤＥＭメタデータの適用を停止することを伴う。その変形例は、同一のタグＩＤを備える新たなＬＤＥＭを送信することである。
【００３９】
ルックデータパケット
本発明の１つの実施形態において、ルックデータパケット伝送のために、「ＫＬＶ」（鍵、長さ、値）メタデータ概念が実装されるが、他の周知のルックデータパケット伝送概念が実装され得る。すなわち、本明細書において１つ又はそれよりも多い実施形態がＫＬＶメタデータ概念に関して説明される一方で、本原理がＫＬＶメタデータ概念を単に実現するだけであるとは限定されず、ルックデータパケットを実現する他の方法も本原理の趣旨を維持しつつ本発明の様々な実施形態に従って実現され得ることが認識されるべきである。
【００４０】
ＫＬＶ概念は、コンテンツを解釈せずともパケット通信が完結される場合を認識する伝送装置に対して有用である。これは、図６及び図７で例示される。例えば、図６は、本発明の実施形態に従った、ルックデータエレメンタリメッセージの使用のためのメタデータ６００の例示的なＫＬＶ表記を示している。図７は、本発明の実施形態に従った、図６のメタデータ６００のＫＬＶ表記を更に詳細に示す。
【００４１】
図６及び図７を参照してより具体的には、各パケットは、例えばメッセージが「ルックデータ」に関係している旨の如きメッセージの性質を指示する「鍵」フィールド６１０を含む。この鍵は、時間スタンプ６１７、又は変形例として「シーンＩＤ」を含むことによって、受信装置はそのデータがどのシーンに適用されるべきかを直ちに知ることができる。時間スタンプ６１７及び／又はシーンＩＤの使用はオプションであり、例えば、時間コード追跡が生じるシステムに対して用いられ得ることが認識されるべきである。更に、各パケットは、そのパケットのペイロード部分におけるワード数を示す長さフィールド６２０を含むことができる。長さフィールド６２０もオプションであり、その使用は例えばメタデータタグに依存することが認識されるべきである。
【００４２】
更に、各パケットは、そのパケットのペイロード部分を担う値フィールド６３０を含むことができる。１つの実施形態において、ペイロードコンテンツのワードサイズはメタデータタグによって決定することができる。本発明の１つの実施形態において、ペイロードは例えば個々の「ルックデータエレメンタリメッセージ」を含むことができ、ＫＬＶの他のレイヤが用いられるか、又は変形例としてＫＶ（鍵及び値）だけが用いられ得る。
【００４３】
ルックデータエレメンタリメッセージ
１．色操作
本発明の１つの実施形態において、色操作はルックデータエレメンタリメッセージで定義することができる。すなわち、色操作は、例えば１つ又はそれよりも多い３Ｄ−ＬＵＴ、１つ又はそれよりも多い１Ｄ−ＬＵＴ、及び／又は１つ又はそれよりも多い３×３ＬＵＴによって実現することができる。例えば、斯かるルックデータエレメンタリメッセージの例示的な定義が図８〜図１４で提供される。
【００４４】
より具体的には、図８は、本発明の実施形態に従って８ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ８００を示す。図８に図示されるように、ルックデータエレメンタリメッセージ８００は、タグＩＤ部８１０、及び、値部８２０を含む。値部８２０は、例示として、有効性部、カラー空間定義部、長さ定義部、及び、値部を含む。図８のルックデータエレメンタリメッセージ８００の各部はそれぞれの記述部及び名称部を含む。図８のタグＩＤ部８１０は、３Ｄ−ＬＵＴの８ビットＩＤを定義し、これは例示として０×１１である。値部８２０において、有効性部はデータが有効であるか否かを定義し、図８では例示としてブール代数で定義されている。値部８２０において、カラー空間部はカラー空間を定義し、図８では例示として［００］＝ＲＧＢ、［０１］＝ＸＹＺ、［１０］＝ＹＣｒＣｂ、及び［１１］予備と定義されている。
【００４５】
図８の値部８２０における長さ定義部は、ペイロードの長さをバイトで定義し、これは例示として８ビットノードデータであると仮定されている。加えて、値部は様々な値を定義し、例えば、ＬＵＴノードデータ、例示的には規則的と仮定される入力データの間隔、ワード（word）定義及び順番を定義し、例示的には、「第１ワードＲＥＤ、ＣＩＥ＿Ｘ、又はＹ」、「第２ワードＧＲＥＥＮ、ＣＩＥ＿Ｙ、又はＣｒ」及び「第３ワードＢＬＵＥ、ＣＩＥ＿Ｚ、又はＣｂ」と定義する。図８のルックデータエレメンタリメッセージ８００において、値部は、また、例示的には「ＢＬＵＥが最初に変化し、次いで緑色、次いでＲＥＤ」とする格子走査を定義する。
【００４６】
図９は、本発明の実施形態に従って１０ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ９００を示す。図９のルックデータエレメンタリメッセージ９００は、図９の３Ｄ−ＬＵＴのＩＤが１０ビットのビット深度を有し且つ０×１２の値を有すること以外、図８のルックデータエレメンタリメッセージ８００と実質的に同様である。加えて、図９のルックデータエレメンタリメッセージ９００において、長さ定義部は、１つの３２ビットワードにパケット化される１０ビットのノードデータであると例示的に仮定されるペイロードの長さを定義する。更に、図９の実施形態において、値部は更にワード「ＲＥＤ」、「ＧＲＥＥＮ」及び「ＢＬＵＥ」を以下のように定義する。
Ｗｏｒｄ＝ＲＥＤ＜＜２０＋ＧＲＥＥＮ＜＜１０＋ＢＬＵＥ
【００４７】
図１０は、本発明の実施形態に従って８ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１０００を示す。図１０のルックデータエレメンタリメッセージ１０００において、１Ｄ−ＬＵＴのＩＤは８ビットのビット深度を有し且つ０×１３の値を有する。図８及び図９の上記のルックデータエレメンタリメッセージとは異なり、図１０のルックデータエレメンタリメッセージ１０００において、カラー定義部は、ＬＵＴがＲＥＤチャネル、ＧＲＥＥＮチャネル若しくはＢＬＵＥチャネルのためのＬＵＴであるか否か、又はＬＵＴが全てのチャネルに適用されるかについて定義する。図１０において、カラー値が例示的には、［００］＝ＲＥＤ又はＣＩＥ＿Ｘ又はＹ１、［０１］＝ＧＲＥＥＮ又はＣＩＥ＿Ｙ又はＣｒ、［１０］＝ＢＬＵＥ又はＣＩＥ＿Ｚ又はＣｂ、及び［Ｈ］＝全チャネルと定義される。加えて、ルックデータエレメンタリメッセージ１０００において、値部は、ＬＵＴの出力データが最小入力値に対して出力値２５６で始める８ビットの値であると想定されることを定義する。
【００４８】
図１１は、本発明の実施形態に従って１０ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１１００を示す。図１１のルックデータエレメンタリメッセージ１１００は、図１１の実施形態において、ルックデータエレメンタリメッセージ１１００が１０ビットのビット深度を有し且つ０×１４の値を有するＩＤを含むこと以外、図１０のルックデータエレメンタリメッセージ１０００と実質的に同様である。加えて、ルックデータエレメンタリメッセージ１１００において、値部は、ＬＵＴ出力データが最小入力値に対して出力値１０２４で始まる１０ビットの値であること、３つの１０ビットの値が１つの３２ビットワードに以下のようにパケット化されることを定義する。
Ｗｏｒｄ＝ＬＵＴ［０］＜＜２０＋ＬＵＴ［１］＜＜１０＋ＬＵＴ［２］
【００４９】
図１２は、本発明の実施形態に従って１０ビットのビット深度を有する３×３マトリックスとして実現された例示的なルックデータエレメンタリメッセージ１２００を示す。ルックデータエレメンタリメッセージ１２００において、カラー定義部は、［００］＝ＲＧＢからＲＧＢ（γ）、［０１］＝ＲＧＢからＲＧＢ（線形）、及び［Ｈ］＝ＸＹＺからＸＹＺ、とするマトリックス適用を定義する。加えて、図１２のルックデータエレメンタリメッセージ１２００において、値部は、以下のような形の９つの１０ビットとして想定される係数を定義する。
【００５０】
［ Ｂ１［ Ｃ１ Ｃ２ Ｃ３［ Ａ１
Ｂ２ ＝ Ｃ４ Ｃ５ Ｃ６ × Ａ２
Ｂ３ ］Ｃ７ Ｃ８ Ｃ９ ］Ａ３ ］
ここにおいて、Ａ１及びＢ１はＲＥＤ又はＣＩＥ＿Ｘであり、Ａ２及びＢ２はＧＲＥＥＮ又はＣＩＥ＿Ｙであり、並びに、Ａ３及びＢ３はＢＬＵＥ又はＣＩＥ＿Ｚであり、そしてシーケンスの順序はＣ１−Ｃ２−Ｃ３である。図１２のルックデータエレメンタリメッセージ１２００において、値部は、３つの係数が１つの３２ビットワードにパケット化されることによって、総ペイロードが３×３２ビット＝９６であり、以下のような値を有することを定義する。
Ｗｏｒｄ＝Ｃ１＜＜２０＋Ｃ２＜＜１０＋Ｃ３
【００５１】
図１３は、本発明の実施形態に従って８ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１３００を示す。図１３のルックデータエレメンタリメッセージ１３００は、図１３の実施形態においてルックデータエレメンタリメッセージ１３００が８ビットのビット深度を有し且つ０×１６の値であるＩＤを含むこと以外、図１２のルックデータエレメンタリメッセージ１２００と実質的に同様である。加えて、図１３のルックデータエレメンタリメッセージ１３００において、総ペイロードは９×８ビット＝７２ビットである。
【００５２】
図１４は、本原理の実施形態に従って１６ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１４００を示す。図１４のルックデータエレメンタリメッセージ１４００は、図１４の実施形態においてルックデータエレメンタリメッセージ１４００が１６ビットのビット深度を有し且つ０×１７の値を有するＩＤを含むこと以外、図１２のルックデータエレメンタリメッセージ１２００及び図１３のルックデータエレメンタリメッセージ１３００と実質的に同様である。加えて、図１４のルックデータエレメンタリメッセージ１４００において、総ペイロードは９×１６ビット＝１４４ビットである。
【００５３】
２．空間フィルタ
本発明の実施形態において、空間フィルタ制御はルックデータエレメンタリメッセージで指定することができる。例えば、空間応答又は周波数応答は空間領域フィルタリング処理を用いて修正することができる。空間周波数応答を修正する１つの例示的な方法は、複数の有限応答（ＦＩＲ）フィルタからなり各々のフィルタが特定の中心周波数に合わせられるパンクを用いることである。図１５は、本発明の実施形態に従った、周波数応答修正のため例示的なフィルタバンク１５００を示す。図１５のフィルタバンク１５００は、例示的には、複数のフィルタ１５１０、少なくとも１つの乗算器１５２０、及び、少なくとも１つの合成器１５３０を含む。
【００５４】
１つの実施形態において、画像の周波数応答はフィルタ係数（ＣＯ．．ＣＮ）を変えることよって操作されて、周波数のディテールを増強又は減衰させる。例えば、図１６は、本発明の実施形態に従った、周波数イコライゼイションのための例示的な離散的周波数１６００を示す。図１６に図示されるように、フィルタ係数（Ｃ０．．ＣＮ）は周波数応答についてルックデータエレメンタリメッセージで指定することができる。
【００５５】
例えば、図１７は、本発明の実施形態に従った、８ビット周波数イコライゼイションのための例示的なルックデータエレメンタリメッセージ１７００を示す。図１７の実施形態に図示されるように、ルックデータエレメンタリメッセージ１７００は、周波数イコライザのために、例えば最高１６個且つ４ビットの幾つかの係数を定義し、各係数が１つの周波数帯域乗数器を制御することを定義する。
【００５６】
３．モーション挙動
１つの実施形態において、モーション挙動制御は、表示がモーション挙動を所望モーション挙動に整合させることを可能とする情報を含むメッセージを利用して、ルックデータエレメンタリメッセージで指定することができる。この情報は所望のモーション挙動の仕様を担い、加えて表示における処理を単純化するコンテンツ前処理装置からのヘルパーデータを担うことができる。例えば、本発明の実施形態に従った、図１８はモーション挙動のための例示的なルックデータエレメンタリメッセージ１８００を示す。図１８の実施形態のルックデータエレメンタリメッセージ１８００は、例示的には、ＨZでの入力フレームレート（Ｕ８）、フィールド繰り返し度（Ｕ８）、所望ディスプレイ挙動（Ｕ１６）、及び、ｘ／ｙでのアイモーション挙動（２×Ｕ３２）を定義する。加えて、図１８の実施形態のルックデータエレメンタリメッセージ１８００において、前処理又はモーション推定があるか否かが定義される。
【００５７】
４．フィルム粒子
１つの実施形態において、フィルム粒子制御がルックデータエレメンタリメッセージで指定され得る。本発明の１つの実施形態において、フィルム粒子メッセージは、ＭＰＥＧ−４ＡＶＣ標準のペイロードタイプ＝１９から採用することができる。図１９は、本発明の実施形態に従った、フィルム粒子のための例示的なルックデータエレメンタリメッセージ１９００を示す。
【００５８】
５．ノイズ
１つの実施形態において、ノイズ制御は、ルックデータエレメンタリメッセージで指定することができる。すなわち、白色ノイズの決定されたレベルを全ての色チャネルに対して同一に印加することが可能であり、又はノイズについてのルックデータエレメンタリメッセージ内でチャネル当たりに１つの特定レベル／挙動を印加することが可能である。更に、ある実施形態においてノイズが１つ又はそれよりも多い色チャネルから除去され得る。１つの実施形態において、ノイズ特性は、上記に説明されたように、空間応答と同様に周波数応答を修正することよって変更され得る。図２０は、本発明の実施形態に従った、ノイズのための例示的なルックデータエレメンタリメッセージ２０００を示す。
【００５９】
６．編集
ある実施形態において、１つ又はそれよりも多いシーンの編集がルックデータエレメンタリメッセージで指定され得る。例えば、本発明のルックデータエレメンタリメッセージに従って、シーン又は一群のシーンから１つ又はそれよりも多いセグメントを切り出すことが可能である。このように、その切り出されたシーンは編集データの更新による後の時刻で表示することができる。このように実施形態において、特定のシーン内の入り及び出の時刻コードの「カットリスト」が伝送され得る。１つの実施形態において、あるシーンの最初のフレームは時刻符号００：００：００：００（ＨＨ：ＭＭ：ＳＳ：ＦＦ）を有することになる。図２１は、本発明の実施形態に従った、編集制御のために用いられ得る時間編集のための例示的なルックデータエレメンタリメッセージ２１００を示す。
【００６０】
７．トーンマッピング
１つの実施形態において、トーンマッピングは、ルックデータエレメンタリメッセージで指定される。例えば高ダイナミックレンジ画像を低ダイナミックレンジ画像に変換する場合に、トーンマッピングが用いられ得る。例えば、典型的適用は、１０ビットコード化された画像から８ビット又は７ビット画像への転換があり得るであろう。本原理は何らかの特定のトーンマッピングアルゴリズムに限定されないことが認識されるべきであり、従って、何らかのトーンマッピングへのアプローチも本原理の趣旨を維持しつつ本発明に従って用いられ得る。１つの実施形態として、トーンマッピングがＭＰＥＧ−４のＡＶＣ標準における補足的強化情報（ＳＥＩ）メッセージにて指定され得る。例えば、図２２は、本発明の実施形態に従った、トーンマッピングのための例示的なルックデータエレメンタリメッセージ２２００を示す。図２２のルックデータエレメンタリメッセージ２２００はまたＳＥＩメッセージで指定され得るパラメータを指定し得る。
【００６１】
ルックデータ伝送
ＨＤＭＩにおいて、ルックデータを送信することのための異なる方法がある。ルックデータを送信することのための例示的な幾つかの方法は、色域メタデータ以外のデータ、「ベンダー仕様インフォフレーム」の使用及び具体的にベンダーが命令する家電エレクトロニクス制御（ＣＥＣ）の使用のための「色域メタデータパッケージ(Gamut Metadata Package)」の使用を含むが、これに限定されない。
【００６２】
１．ＨＤＭＩ色メタデータ
ＨＤＭＩ仕様の現在バージョンが１．３Ａバージョンである点に留意すると、ＨＤＭＩ仕様のバージョン１．３以降、ＨＤＭＩを介して比色メタデータを転送する新たな方法があった。本発明の１つの実施形態において、その伝送可能性が、比色メタデータのみの伝送に代えて「ルックデータパケット」を送信するのに用いられる。従って、現在のＨＤＭＩ仕様のバージョン１．３Ａで例えばＧＢＤ＿ｐｒｏｆｉｌｅ＝７とすることによって用いられる色域プロファイルの使用が提案される。ＨＤＭＩ仕様バージョン１．３は、最高８００個のＨＤＭＩパケットの単一伝送を可能とするが、その仕様の将来バージョンでは異なるパケット総数が提供され得る。しかし、このための時間は１０ビデオフィールドにまで続くはずであるが、これはインタフェース仕様の将来バージョンによって変わり得る。ＨＤＭＩパケット当たり２８バイトとすると、これは合計で最高２１．８Ｋバイトになるであろう。
【００６３】
従って、斯かるルックデータ伝送に関する本発明の実施形態において、ルックデータパケットがＨＤＭＩ色域メタデータパケットの最大サイズよりも大きくないことが保証されるべきである。加えて、ルックデータパケットがシーンからシーンに適応されなければならない場合があり、その場合、シーンはルックデータパケットデータを共有するビデオフィールドの範囲になければならないように定義され、更新の斯かる瞬間に先行するシーンは、現在シーンの「ルックデータパケット」（ＬＤＰ）伝送に要する時間よりも短くてはならない。
【００６４】
仕様バージョン１．３に従ったＨＤＭＩ比色メタデータを用いる場合、パケットの長さが算出されるべきであり、図２３に示されるように、ＧＢＤ＿Ｌｅｎｇｔｈ＿Ｈ（高バイト）及びＧＢＤ＿Ｌｅｎｇｔｈ＿Ｌ（低バイト）が色域メタデータパケットの最初の２バイト中に充填される。つまり、図２３は、本発明の実施形態に従った本発明の実施形態が適用され得る例示的なＨＤＭＩ色域メタデータパケット２３００を示す。
【００６５】
１つの実施形態において、オプションのチェックサムは、ＧＢＤヘッダ及びルックデータパケット、並びに、もし適用可能なら何らかの充填データを含むパケット全体について実行することができる。図２４は、本発明の実施形態に従った、本発明が適用され得る例示的なＨＤＭＩ色域メタデータヘッダ２４００を示す。表１は、本発明の実施形態に従った、図２４に示された構文要素の意味を説明している。図２４及び表１の複数部分は、「ＨＤＭＩ規格バージョン１．３ａ」における表５−３０「色域メタデータパケットヘッダ」と称される部分から抽出されている。
【００６６】
【表１】
【００６７】
示されように、データは伝送のために、最初のＧＢＤパケットについて２２バイト、残りの全てのパケットについて２８バイトである個々のＨＤＭＩインタフェースパケットに分割され得る。もし最後のパケットが「ルックデータパケット」データで完全に充填されない場合、パケットは前述の「フィルデータ」で充填され、これは本発明の１つの実施形態において１つ又はそれよりも多い「０」を含むことができる。データフローについては、ＨＤＭＩ ＧＢＤデータフロー機構が、「Next_Field」、「Affected_Gamut_Seq_Num」、「Current_Garnut_Seq_Num」及び「Packet_Seq」によって用いられる（図２４参照）。適用されるべきルックデータがない場合に、「GBD_Profile」＝７（図２４参照）に従った「No_Current_GBD」の１つの伝送がこの要求の信号化にとって十分である。そして、全てのルックデータ映像信号修正は、新たなルックデータパケットが送信されるまでディスエーブル状態にある。
【００６８】
変形例として、「ＨＤＭＩ ＣＥＣプロトコル」に関して以降で説明されるような通信方法が用いられ得るが、ＧＢＤ通信方法は組込みのフレーム同期化方式を特徴とすることから好ましい。
【００６９】
図２５は、本発明の実施形態に従って、本発明が適用され得るＨＤＭＩバージョン１．３における例示的な色域メタデータパッケージ２５００を示す。色域メタデータパッケージ２５００は、実際のビデオ部分２５１０、発生源におけるＧＢＤインフォ部分２５２０、ＶＳＹＮＣ部分２５３０、色域メタデータパケット部分２５４０、及び、シンク（sink）装置の会話テーブル部分２５５０を含む。図２５の部分は、「ＨＤＭＩバージョン１．３ａ」から抽出され、図５〜図６における「ＰＯ伝送シーケンス例」が参照される。
【００７０】
２．ＣＥＡ／ＨＤＭＩベンダー指定インフォフレーム
上記のようなＨＤＭＩ ＧＢＤメタデータを実現する代わりに、本発明の変形例において、「ベンダー指定インフォフレーム」が本発明に従って用いられ得る。ベンダー指定のインフォフレームは、例えば、ＣＥＡ−８６１−Ｄ仕様６．１章に記載されている。ＨＤＭＩ仕様は、その５．３．５章に記載されるように、ＣＥＡ−８６１−Ｄインフォフレームの使用を可能とする。実際、インフォフレームパケットは長さ２８バイトである。色域メタデータパケットと比した唯一の差異は、パケットサイズが１つのインフォフレームだけに制限されていることである。本発明の１つの実施形態において、ベンダー指定インフォフレームについてＧＢＤメタデータフロー制御を用いることが提案される。すなわち、１つの実施形態において、１つのパケットだけとするベンダー指定インフォフレームの上述した制限に依存して、長さフィールドがサイズについてだけ５ビットであるとする修正が用いられ得る。これは、長さ情報及び巡回冗長符号（ＣＲＣ）情報が、「ＧＢＤ様式」ヘッダ、ルックデータパケットヘッダ（図２６参照）に置かれるべきであることを意味し、これは従って３バイトから６バイトに増大する。つまり、図２６は、本発明の実施形態に従った、ＨＤＭＩバージョン１．３と共に用いられるベンダー指定インフォフレームのための例示的なルックデータパケットヘッダ２６００を示す。
【００７１】
表２は、以下のように、本発明の実施形態に従った図２６で示された構文要素の意味を説明している。
【００７２】
【表２】
【００７３】
図２７は、本発明の実施形態に従った、例えば、本発明が適用され得るＣＥＡ８６１Ｄにおける例示的なベンダー指定インフォフレーム２７００を示す。図２７のベンダー指定インフォフレーム２７００は、例示的には、バイト番号、フィールド名、及び、コンテンツを定義する。図２７に図示されるように、ベンダー指定インフォフレーム２７００は、例示的には、０１16の値を有するベンダー指定インフォフレームタイプコードとして「ｎ」バイトを定義する。ベンダー指定インフォフレーム２７００は、０１16の値を有するベンダー指定インフォフレームバージョンとしてのｎ＋１フレーム、ＩＥＥＥ登録ＩＤを含むインフォフレームペイロードにおける総バイトに等しい値を有するＬｖインフォフレームとしてのｎ＋２フレーム、２４ビットのＩＥＥＥ登録識別子（ＬＳＢが先）としてのｎ＋３，４，５番のフレーム、及び、ベンダー仕様ペイロードとしてのｎ＋Ｌｖ−１1フレームを更に定義する。
【００７４】
したがって、図２８は本発明の実施形態に従った、ルックデータを伝送するための例示的なベンダー指定ＣＥＣ命令２８００を示す。図２８のベンダー指定ＣＥＣ命令２８００は、例示的には、名称、記述及び様々なＣＥＣ命令のための値を定義する。より具体的には、図２８の実施形態において、特別なスタートビットが定義される。更に、ベンダーＩＤ、すなわち例示的にはＩＥＥＥベンダーアドレスがＩＥＥＥ ＯＵＩ割り当てに等しい３バイトとして定義される。図２８のベンダー指定ＣＥＣ命令２８００は、また、タグ番号の１バイト値を有するオプトコード（optcode）として第１のデータブロックを定義する。第２のデータブロックで始めるベンダー指定ＣＥＣ命令２８００において、長さ、パケットシーケンス及びオペランドを定義しているオペランドブロックが定義される。より具体的には、引き続くデータの長さがバイトで定義される。パケットシーケンスは、図２８の実施形態において例示的には、色域メタデータパケットシーケンスにおいて、あるパケットが唯一であるか、最初又は最後のパケットであるかを指示する２ビットを用いて定義される。斯かるパケットシーケンスは例示的には図２８で以下のように定義される。
【００７５】
＝０（０ｂ００） シーケンス内の中途のパケット
＝１（０ｂ０１） シーケンス内の最初のパケット
＝２（０ｂ１０） シーケンス内の最後のパケット
＝３（０ｂ１１） シーケンス内の唯一のパケット
【００７６】
３．ＨＤＭＩ ＣＥＣプロトコル
家電エレクトロニクス制御（ＣＥＣ）はＨＤＭＩにおける双方向コントロールバスである。このバスはこれ自体に接続される幾つかのオーディオ／ピジュアル（ＡＶ）装置によって用いられるべき共有媒体である。
【００７７】
このバスは性質上１００〜２００ビット／秒の範囲の生データ伝送速度を有しており非常に遅い。単一のベンダー指定ＣＥＣメッセージは、ＨＤＭＩ仕様バージョン１．３ａに従った最大１６×１０ビットの生サイズと、最高１１×８ビットの生ペイロードを有する。プロトコル及びデータフローについて１００％乃至２００％のオーバヘッドを考慮すると、１つのＣＥＣメッセージの伝送に数秒を要することになる。これは、もし先の２つの方法によって最大限可能であるような同一のデータ量、すなわち２１．８Ｋバイトである場合、伝送に数分を要することを意味する。この伝送の間にもし他の何らかの装置がバスを用いない場合には、これは正に真実であり、場合によっては伝送時間が更に増加することになる。
【００７８】
従って、ルックデータパケットがサイズ上制限されることが賢明である。この速度を考慮すると、一定のルックデータエレメンタリメッセージが日々の使用に用いられることは非実用的である（特にＬＵＴダウンロード、図８〜図１１を参照）。
【００７９】
それにもかかわらず、ＣＥＣフレームのペイロードサイズを考慮すると、ルックデータパケットが１つのＣＥＣフレームよりも長くなることは殆ど不可避である。ＣＥＣが単純な応用のために設計されたという事実に起因して、本発明の実施形態に従った通信をより堅牢にするために、抽象レイヤがＣＥＣの上に実装され得る。
【００８０】
より具体的に且つ国際電気標準会議オープンシステム相互接続（ＩＳＯ／ＯＳＩ）参照モデルに関して、ＣＥＣ機能には、物理レイヤ、データリンク及びネットワークレイヤの一部が実装される。サービス品質（ＱｏＳ）はネットワークレイヤによっては提供されない。
【００８１】
従って、本発明の１つの実施形態において、ＱｏＳはＣＥＣプロトコル上で実装されるべきレイヤにおいて提供される。
【００８２】
図２９は、本発明の実施形態に従った、家電エレクトロニクス制御（ＣＥＣ）バスの用途のための例示的なネットワークレイヤモデル２９００を示す。ネットワークレイヤモデル２９００は、アプリケーションレイヤ２９０５、ＴＬ＿ＣＥＣレイヤ２９１０、ＣＥＣレイヤ２９１５、及び、ＣＥＣ−物理レイヤ（ＣＥＣ−物理）２９２０を含み、第１の装置（装置１）２９８１と第２の装置（装置２）２９８２の間の通信はＣＥＣ−物理レイヤ（ＣＥＣ−物理）２９２０で実行される。
【００８３】
図３０は、本発明の実施形態に従った、ＣＥＣベンダー指定コマンドによってアプリケーションからアプリケーションへの通信を提供するための例示的なＣＥＣ処理３０００の上位のブロック図を示す。すなわち、ＣＥＣ処理３０００に関して、ルックデータエレメンタリメッセージは、コンテンツ作成／オーサリングにおいて生成アプリケーション３００５によって生成される。ルックデータエレメンタリメッセージは、次いで１つのルックデータパケットになるようにパケット組立ブロック３０１０によって組み立てられる。巡回冗長符号（ＣＲＣ）はこのパケットからＣＲＣブロック３０１５によってＨＤＭＩに定義される方法で算出される。ここでのＣＲＣはチェックサムとして実装され、それはヘッダと更にチェックサムデータとを含む全パケットデータのバイト総合計が零に等しいように定義される。
【００８４】
続いて、ＣＲＣ及びルックデータパケットは、パケットからフレームへのブロック３０２０によって、通信のために適当なサイズのフレームに分離される。本発明の実施形態において、８８バイトのパケットサイズが例として用いられ得る。斯かる実施形態において、最初のＣＥＣメッセージは８ビットのＣＲＣデータを運び、ＣＲＣデータがルックデータパケット当たり一度だけ伝達される必要があることから、引き続くメッセージは次いで８ビットのもっと多くのペイロードデータを運ぶ。
【００８５】
変形例として図３１に図示されるように、ＣＲＣデータは伝送の終わり、すなわちフレームＮで伝送することができる。つまり、図３１はＨＤＭｌを用いた伝送のためにルックデータパケットのフレームへの例示的な変換３１００を例示する上位のブロック図を示している。再び戻って図３０を参照すると、データはＣＥＣ３０３０を介した伝送の準備ができている。
【００８６】
本発明の１つの実施形態において、受信側においては正に反対のことがなされる。つまり、フレームがルックデータパケットになるように分解され、チェックサムが算出され、次いで、ルックデータエレメンタリメッセージが受信側の適用に供するためにルックデータパケットから分解され、斯かる適用は典型的にはコンテンツクリエーターよって指定される意図に従った眺め（look）をここで変更する表示である。
【００８７】
ＣＲＣブロック３０１５はネットワークレイヤ２９００の一部である点に留意する必要がある。ＣＲＣエラーの場合、以下の２つの例示的なアプローチの何れかが実行され得るが、但し、本発明の原理が単に以下に説明される方法だけに限定されない点に留意する必要がある。第１の方法においてルックデータパケットは破棄することができる。第２の方法において再送要求を発効することができる。第１の方法の場合、以前に送信されたパケットは有効なままとなる。
【００８８】
図３１を再度参照すると、図３１は本発明の実施形態に従った、ＨＤＭＩを用いた伝送のためのフレームへのルックデータパケットの例示的な変換３１００を例示する上位のブロック図を示す。変換３１００は、与えられたルックデータパケット３１１０と、ＣＲＣ算出適用３１２０と、パケットからフレームへの変換３１３０とを伴い、結果としてのフレーム３１４０が、ＣＲＣ情報３１４５を有する最初のフレームと共に得られる。
【００８９】
以前に言及された方法の幾つかとは異なり、ＣＥＣは映像信号と共通する時刻基盤を有しない。従って、ルックデータパケットを同期させる本発明の実施形態において、伝送されたＬＤＰのパラメータ及びデータのローディングをシンク装置のビデオ処理ブロックと時間合わせするために、ＬＤＰ伝送の終わりに検証信号が用いられる。斯かるように、あるルックデータパケットがＣＥＣを介して伝送されても、特別な「検証(Validate)」ＣＥＣコマンドが伝送される迄無効なままである。
【００９０】
しかし、検証は実際には時間合わせされ得ない。斯かるように、本発明の１つの実施形態において、１つの可能性は適用時間の不確実性を推定し、ビデオ処理における変更が乱されないことを保証することである。シーン変更ブランキングが用いられ得る。「検証」信号は１バイト程度に短くできるが、ＣＥＣビットオーバヘッドによって図３２に示されるように、信号は最低６０ビットに足すところのスタートビットにまで増えることになる。つまり、図３２は、本発明の実施形態に従った、ルックデータ検証のための例示的なルックデータエレメンタリメッセージ３２００を示している。
【００９１】
従って、送信時間は、ＣＥＣ開始時間＋２０×ＣＥＣの公称データビット周期時間によって計算することができる。ＨＤＭＩ仕様バージョン１．３ａは、４．５ミリ秒の公称ＣＥＣ開始時間及び２．４ミリ秒の公称ＣＥＣデータ周期時間を提案している。これは４．５ミリ秒＋６０×２．４ミリ秒＝１４８．５ミリ秒の結果を与える。従って、「検証」信号は、６０Ｈｚの場合に９フィールドの遅延、５０Ｈｚの場合に８フィールドの遅延、又は２４Ｈｚの場合に４フィールドの遅延を有することになる。しかし、これはＨＤＭＩ仕様におけるＣＥＣ仕様のより新しいバージョンによっては変わり得る。
【００９２】
斯かるように、６０Ｈｚのフィールド周波数の場合、「検証」コマンドは適用に先立って少なくとも９フィールド前にＣＥＣ発生器から要求されなければならない。ＨＤＭＩシンク制御はビデオ及びＣＥＣ両方を介していることから、所与の画像コンテンツに間違ったＬＤＰデータを適用するのを回避するために、移行フェーズ中に画像コンテンツが消されるか又はＬＤＰ変更に対して脆弱にならないようにすることが提案される。移行フェーズは、ＨＤＭＩ仕様の手段で可能な最速のＣＥＣ移行時間と、最も遅いＣＥＣ伝送と、足すところのシンク装置におけるあり得る処理遅延とを仮定した伝送時間の間の期間であると判定される。
【００９３】
シーンベースのルックデータパケット変更の同期問題を解決するために、以下の例示的な方法が本発明の実施形態に従って提案される。すなわち、ＣＥＣをビデオに同期させるために、物理レベルのＣＥＣ動作が実行される。これは例えば図３３に示される装置によって達成することができる。
【００９４】
より具体的には、図３３は本発明の実施形態に従った、ＣＥＣ検証信号を生成するための例示的な装置３３００を示す。図３３の装置３３００は、例示的には、ＣＥＣ発生器３３１０、送信機側３３２０、受信器側３３３０、及び、ＣＥＣデコータ３３４０を含む。物理レベルのＣＥＣ動作は装置３３００よって実行され、装置３３００は送信機側３３２０においてＣＥＣの物理レイヤ動作を、ビデオ部のＶＳＹＮＣ（垂直同期信号）に同期させる。受信器側３３３０において、装置は、そのルックデータパケットデータ適用をＣＥＣ物理レイヤ動作に同期させることよるフレーム同期方式で、そのルックデータパケットデータの適用を画像処理に同期させる。これを装置３３００は、ＣＥＣ検証コマンド命令をＶＳＹＮＣに時間合わせし且つルックデータパケットデータ検証のために最後のバイトのＥＯＭ命令を待つことによって達成する。
【００９５】
図３４は、本発明の実施形態に従った、ＣＥＣによる検証信号伝送のための方法のフローチャートを示す。方法３４００はステップ３４１０で始まり、ＬＤＰがシンク装置に伝送される。方法３４００は次いでステップ３４２０に進む。
【００９６】
ステップ３４２０において、「検証」信号伝送はブロック３４２０におけるシンク装置のＣＥＣ発生器から要求される。方法３４００は次いでステップ３４３０に進む。
【００９７】
ステップ３４３０において、ＣＥＣジェネレータは、次のＶＳＹＮＣイベントで始まるＣＥＣ「検証」コマンドの伝送を開始する。
【００９８】
方法３４００は次いでステップ３４４０に進む。
【００９９】
ステップ３４４０において、シンク装置は「検証」信号を受信する。方法３４００は次いでステップ３４５０に進む。
【０１００】
ステップ３４５０において、シンク装置は伝送が完了される迄待ち、シンク装置での次の引き続くＶＳＹＮＣ信号イベントでＬＤＰデータを検証する。方法３４００は次いでステップ３４６０に進む。
【０１０１】
ステップ３４６０において、シンク装置はＬＤＰデータコンテンツをビデオ処理ブロックに適用する。方法３４００は次いで出口処理される。
【０１０２】
上記したように、「検証」信号の伝送時間は略５２．５ミリ秒であることになる。従って、「検証」信号は、６０Ｈｚの場合に４フィールドの遅延、５０Ｈｚ及び２４Ｈｚの場合に３フィールドの遅延を有することになる。従って、その適用に先立って略４フレーム前に、ＬＤＰ伝送が完了され且つ「検証」信号伝送が始動されることが必要である。その場合ＬＤＰ適用の不確実性は何ら存在しない。
【０１０３】
本発明の変形例において、他の伝送方法としては、ＬＤＰ伝送のための新しい将来ネットワーク化の可能性を含むことができる。例えば、将来、ＨＤＭＩは頂上レイヤ／レベル上に新しいネットワーク化チャネルを採用してもよく、或いは既存のＨＤＭＩ特有のデータ伝送可能性の幾つかを代替してもよい。この新しい伝送方法は、周知のネットワーク化技術に基づいてもよいし、ビデオ非同期であってもよい。このネットワーク技術は、ＬＤＰパケットを同一経路で送信するのに用いることかでき、ビデオ同期並びに本明細書で説明された本発明の様々な実施形態と共に説明されたパケット制御の如きＣＥＣ伝送の方法の利用に用いることができる。
【０１０４】
ルックデータ定義及びＨＤＭＩ（例示であり制限することが意図されない）上の伝送のための方法及びシステムについて好ましい実施形態が説明されたが、当業者によって上記教示を考慮した修正及び変様がなされ得る。従って、添付の特許請求の範囲よって画定される如き本発明の範囲及び趣旨内にある、本発明の特定の実施形態における変更がなされてもよいことを理解できよう。以上の記載は本発明の様々な実施形態を志向するものである一方、本発明の他の及び更なる実施形態が本発明の範囲から逸脱することなく考案されてもよい。
【技術分野】
【０００１】
本出願は、非仮出願である「ルックデータ定義及び伝送のための方法及びシステム」と題する代理人文書番号ＰＵ０７０３０７号に関連し、該出願は共通に譲渡されその内容が引用によって本明細書に完全に組み入れられて共にここで出願される。
【０００２】
本原理は概略マルチメディアインタフェースに関する。特に、本原理は、特に詳細にはルックデータ定義及び高精細マルチメディアインタフェース（ＨＤＭＩ）上の伝送のための方法及びシステムに関する。
【背景技術】
【０００３】
現在、家庭使用又は専門家使用の何れかのためにビデオコンテンツ製品を配布する際には、そのビデオ配布製品についてなされた単一の色決定が存在し、これは通常、ビデオコンテンツクリエーターの意図の顕れである。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかし、コンテンツの色決定が改変されなければならないような、コンテンツに異なる使用実態が発生している。斯かる異なった使用実態は、例えば、フロントプロジェクションディスプレイ、直接視ディスプレイ又は携帯ディスプレイの如き異なるディスプレイタイプで発生し、これら各々は斯かるビデオコンテンツの最適表示を提供するために色決定に対して幾らかの変更を必要としている。
【課題を解決するための手段】
【０００５】
本原理の様々な実施形態に従った方法及びシステムは、ルックデータ定義及び高精細マルチメディアインタフェース（ＨＤＭＩ）上の伝送を提供することによって上記従来技術の欠点を解決する。
【０００６】
本原理のある態様による方法が提供される。本発明方法は、ビデオコンテンツのためのメタデータを生成するステップを含む。上記メタデータは、異なる表示装置間の多様性(variations)及びコンテンツクリエーターよる異なる創作意図間の多様性を説明する(account for)ことよって、その表示前に上記ビデオコンテンツを修正(alter)するためのデータである。上記方法は、高精細マルチメディアインタフェース上の伝送のために上記ビデオコンテンツ及び上記メタデータを準備するステップを含む。
【０００７】
本原理の別の態様によるシステムが提供される。本発明システムは、メタデータ生成器及びメタデータ伝送準備装置を含む。上記メタデータ生成器はビデオコンテンツのためのメタデータを生成するための装置である。上記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターよる異なる創作意図間の多様性を説明することよって、その表示前に上記ビデオコンテンツを修正するためのデータである。上記メタデータ伝送準備装置は高精細マルチメディアインタフェース上の伝送のために上記ビデオコンテンツ及び上記メタデータを準備する装置である。
【０００８】
本原理の教示は添付の図面と共に以降の発明の詳細な説明を考慮することよって容易に理解され得る。
【図面の簡単な説明】
【０００９】
【図１】本発明の実施形態に従って高精細マルチメディアインタフェース接続上でルックデータを送信するシステム１００の上位のブロック図である。
【図２】本発明の実施形態に従って連続したルックデータ伝送を実現している図１のシステム１００のより詳細な上位のブロック図である。
【図３】本発明の変形例に従って並行したルックデータ伝送を実現している図１のシステム１００のより詳細な上位のブロック図である。
【図４】本発明の実施形態に従ってルックデータ定義及び伝送のための方法を示すフローチャートである。
【図５】本原理の実施形態に従ってルックデータ５００の例示的な表現を示す図である。
【図６】本発明の実施形態に従ってルックデータエレメンタリメッセージにおける使用のためのメタデータ６００の例示的なＫＬＶ表記を示す図である。
【図７】本発明の実施形態に従って図６のメタデータ６００のＫＬＶ表記を更に詳細に示す図である。
【図８】本発明の実施形態に従って、８ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ８００を示す図である。
【図９】本発明の実施形態に従って、１０ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ９００を示す図である。
【図１０】本発明の実施形態に従って、８ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１０００を示す図である。
【図１１】本発明の実施形態に従って、１０ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１１００を示す図である。
【図１２】本発明の実施形態に従って、８ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１２００を示す図である。
【図１３】本発明の実施形態に従って、１０ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１３００を示す図である。
【図１４】本発明の実施形態に従って、１６ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１４００を示す図である。
【図１５】本発明の実施形態に従った、周波数レスポンス変更のための例示的なフィルタバンク１５００を示す図である。
【図１６】本発明の実施形態に従った、周波数イコライゼイションのための離散的な周波数１６００を示す図である。
【図１７】本発明の実施形態に従った、８ビット周波数イコライゼイションのための例示的なルックデータエレメンタリメッセージ１７００を示す図である。
【図１８】本発明の実施形態に従った、モーション挙動のための例示的なルックデータエレメンタリメッセージ１８００を示す図である。
【図１９】本発明の実施形態に従った、フィルム粒子のための例示的なルックデータエレメンタリメッセージ１９００を示す図である。
【図２０】本発明の実施形態に従った、ノイズのための例示的なルックデータエレメンタリメッセージ２０００を示す図である。
【図２１】本発明の実施形態に従った、編集上の制御に用いられ得る時間編集のための例示的なルックデータエレメンタリメッセージ２１００を示す図である。
【図２２】本発明の実施形態に従った、トーンマッピングのための例示的なルックデータエレメンタリメッセージ２２００を示す図である。
【図２３】本発明の実施形態に従った、本発明の実施形態が適用され得る例示的なＨＤＭＩ色域メタデータパケット２３００を示す図である。
【図２４】本発明の実施形態に従った、本発明が適用され得る例示的なＨＤＭＩ色域メタデータヘッダ２４００を示す図である。
【図２５】本発明が本発明の実施形態に従って適用され得るＨＤＭＩバージョン１．３における例示的な色域メタデータパッケージ２５００を示す図である。
【図２６】本発明の実施形態に従った、ベンダー指定のインフォ（info）フレームのための例示的なルックデータパケットヘッダ２６００を示す図である。
【図２７】本発明の実施形態に従った、本原理が適用され得るＣＥＡ８６１Ｄにおける例示的なベンダー指定のインフォフレーム２７００を示す図である。
【図２８】本発明の実施形態に従ってルックデータを送信するための例示的なベンダー指定のＣＥＣ命令２８００を示す図である。
【図２９】本発明の実施形態に従った、家電エレクトロニクスコントロールバスの用途のための例示的なネットワークレイヤモデル２９００を示す図である。
【図３０】本発明の実施形態に従った、ＣＥＣベンダー指定コマンドによるアプリケーション通信への適用を提供する例示的なＣＥＣプロセッシング３０００の上位のブロック図である。
【図３１】本発明の実施形態に従った、ＨＤＭＩを用いた伝送のためのフレームへのルックデータパケットの例示的な変換３１００を例示している上位のブロック図である。
【図３２】本発明の実施形態に従った、ルックデータ検証のための例示的なルックデータエレメンタリメッセージ３２００を示す図である。
【図３３】本発明の実施形態に従った、ＣＥＣ検証信号を生成する例示的な装置３３００を示す図である。
【図３４】本発明の実施形態に従った、ＣＥＣにおける検証信号伝送のための方法を示すフローチャートである。
【発明を実施するための形態】
【００１０】
図面は、本発明の概念を例示する目的のためにあり、本発明を例示する必ずしも唯一の可能な構成ではないことが理解されるべきである。理解を容易にするために、図面に共通である同一の要素には可能な場合同一の参照番号が付されている。
【００１１】
本原理は、ルックデータ定義及び高精細マルチメディアインタフェース（ＨＤＭＩ）上の伝送のための方法及びシステムを有利に提供する。本原理が発生源装置及び表示装置に関係する伝送システムの文脈内で主に説明されるにも関わらず、本発明の特定の実施形態は本発明の範囲を制限するものとして扱われるべきではない。
【００１２】
図に示される様々な要素の機能は、適切なソフトウェアと協働するソフトウェアを実行し得るハードウェアのみならず、専用ハードウェアの使用を介して提供され得る。プロセッサによって提供される場合、単一の専用プロセッサによって、単一の共有プロセッサよって、又は幾つかが共有され得る複数の個々のプロセッサによって、上記機能が提供され得る。更に、用語「プロセッサ」又は「コントローラ」の明示的な使用は、ソフトウェアを実行し得るハードウェアを排他的に意味するものとして解釈されるべきでなく、制限するものではないが、デジタル信号プロセッサ（「ＤＳＰ」）ハードウェア、ソフトウェア記憶のためのリードオンリーメモリ（「ＲＯＭ」）、ランダムアクセスメモリ（「ＲＡＭ」）、及び不揮発性記憶装置の使用を黙示的に含み得る。更に、本明細書において本発明の原理、態様及び実施形態、同様にそれらの特定の例を詳述している全ての文言は、それらの構造上及び機能上の均等物を含むことが意図されている。その上、斯かる均等物とは、将来開発される均等物（すなわち、構造に関わりなく同一の機能を実施するように開発された何らかの要素）と同様に現在周知の均等物の双方を含むことが意図される。
【００１３】
このように、例えば、本明細書で提示されているブロック図は、例示のシステムコンポーネントの概念及び／又は本発明の原理を実現している回路を表すことが当業者によって認識されるであろう。同様に、何らかのフローチャート、フローダイヤグラム、状態遷移図、疑似コード、及び同様物は様々なプロセスを表し、斯かるプロセスがコンピュータ読取可能媒体で実質的に表現され、コンピュータ若しくはプロセッサが明示的に示されているか否かに関わらず、斯かるコンピュータ若しくはプロセッサよって実行されてもよいことが認識されるであろう。
【００１４】
本原理の「１つの実施形態」及び「ある実施形態」に対する本明細書における参照は、特定の特徴、構造、特性、並びに、実施形態に関連して説明されたものが本原理の少なくとも１つの実施形態に含まれることを意味する。このように、本明細書の全体にわたって様々な所で現れる語句「１つの実施形態において」又は「ある実施形態において」とは必ずしも同一の実施形態全てを意味しない。
【００１５】
更に、本明細書で用いられるように、メタデータの伝送及び受信に関して、語句「帯動（in-band）」とは、斯かるメタデータと共に、消費者装置よって表示されるべき色修正された画像コンテンツを送信すること及び／又は受信することを意味する。対照的に、語句「非帯動（out-of-band）」とは、消費者装置よって表示されるべき色修正された画像コンテンツとは別に、斯かるメタデータを送信すること及び／又は受信することを意味する。
【００１６】
更に、本明細書で用いられるように、用語「シーン」とは、単一の「ショット」を元にして通常発生する動画像におけるある範囲の画像フレームを意味し、シーン変化間の一連の連続撮影を意味する。
【００１７】
また、本明細書で用いられるように、語句「ルックデータ管理」とはルックデータの編集、伝送及び適用を意味する。
【００１８】
その上、本明細書で用いられるように、語句「コンパクトディスクプレーヤ」とは、標準規格のコンパクトディスクプレーヤ、ブルーレイデジタルビデオディスクプレーヤ、高精細デジタルビデオディスクプレーヤ、その他を意味する。
【００１９】
更に、本明細書で用いられるように、「未使用色域プロファイル(unused gamut profile)」とは、ＨＤＭＩ標準のバージョン１．３（又は何らかの先行バージョン）において現在使われない色域プロファイルを意味する。
【００２０】
更に、本明細書で用いられるように、語句「ルックデータ」、及び斯かるルックデータに関連する用語「メタデータ」とは、色操作、空間フィルタリング処理、モーション挙動、フィルム粒子、ノイズ、編集及びトーンマッピング等について及び／又は関連する、例えば、整数、非整数値、及び／又はブール値の如き形式のデータを意味する。斯かるルックデータ及び／又はメタデータは、斯かる機能を実現するのに関連する機構を制御、ターンオン、ターンオフするのに用いられ、そしてそれらを修正するのに用いられてもよい。更に、ルックデータ及び／又はメタデータは、マッピングテーブルの仕様を含む。
【００２１】
例えば、色操作を志向する実施形態において、色マッピングテーブルは、１ＤＬＵＴ（１次元のルックアップテーブル）、３次元ＬＵＴ（３次元ルックアップテーブル）及び／又は３×３ＬＵＴによって実現されてもよい。例えば、３次元ＬＵＴの場合、斯かるＬＵＴは３つ入力値を受信するのに用いられ、各値が１つの色成分、例えば赤色、緑色若しくは青色を表し、個々の赤色、緑色及び青色の入力３連値毎に、例えば赤色、緑色及び青色である所定の出力３連値を生成する。この場合、コンテンツ発生源からコンテンツ消費装置（例えば表示装置）へのメタデータはＬＵＴ仕様を含む。
【００２２】
他の実施形態は、マッピング機能の仕様を含んでもよく、例えば、以下の式で定義される「ＧＯＧ」（利得、オフセット、ガンマ）を実行する回路及び／又は機能を含んでもよい。
【００２３】
カラー成分毎に、Ｖｏｕｔ＝Ｇａｉｎ＊（Ｏｆｆｓｅｔ＋Ｖｉｎ）∧ガンマ
斯かる場合、ルックデータ及び／又はメタデータは、９つの値、すなわち３つのカラー成分の各成分毎に利得、オフセット及びガンマからなる１組を含むことになる。
【００２４】
本明細書で用いられるように、ルックデータはこれらメカニズムに作用を与えるように用いられ、１つのだけでなく幾つかのルックデータの伝送／記憶を実現するために、幾つかの組のルックデータがあり得る。
【００２５】
もちろん、本原理は前述の実施形態に限られず、本明細書で提供される本原理の教示が与えられることで、ルックデータ及び／又はメタデータの他の実現を含む他の実施形態が、本原理の趣旨を維持しつつ、当業者によって容易に企図され得る。ルックデータは、本明細書において少なくとも図５に関して更に説明される。
【００２６】
例えば、図１は、本発明の実施形態に従った、ルックデータを高精細マルチメディアインタフェース接続上で送信するためのシステム１００の上位のブロック図を示す。図１のシステム１００は、例示として、コンテンツ発生源装置１１０、高精細マルチメディアインタフェース（ＨＤＭＩ）接続装置１２０、及び、表示装置１３０を含む、及び／又は、伴う。コンテンツ発生源装置１１０は、限定されないが、高精細デジタルビデオディスクプレーヤ、ブルーレイプレーヤ、及びネットワークアクセスユニット（例えば、セットトップボックス（ＳＴＢ））であって良いことが認識されるべきである。コンテンツ発生源装置１１０は、高精細マルチメディアインタフェース接続装置１２０を介してその表示のために表示装置１３０に向けて送信されるべきコンテンツを提供する。例えばルックデータを含んでいるメタデータは、コンテンツ発生源装置１１０から表示装置１３０へ提供され、且つ表示装置１３０からコンテンツ発生源装置１１０へ提供され得る。高精細マルチメディアインタフェース（ＨＤＭＩ）接続装置１２０が、限定するものではないが、高精細マルチメディアインタフェース（ＨＤＭＩ）ケーブルを含むことが認識されるべきである。
【００２７】
表示装置１３０（及び／又は伝送媒体１２０と表示装置１３０との間に配置され且つこれら装置に接続されている装置）は、受信器１６１、記憶装置１６２、及び／又は、メタデータをそれぞれ受信、記憶及び適用するためのメタデータ適用器１６２を含む。
【００２８】
例えば、図２は、本発明の実施形態に従った、連続したルックデータ伝送を用いている図１のシステム１００のより詳細な上位のブロック図を示す。図２の実施形態において、コンテンツ２０２及びルックデータデータベース２０４は、システム１００のコンテンツオーサリング部２１０に配置される。図２の実施形態において、ルックデータベース２０４はルックデータを記憶する。１つの実施形態において、システム１００のコンテンツオーサリング部２１０は、更に以降で説明されるように、ルックデータ２０６を生成するためのルックデータ発生器２８８、及び、ＨＤＭＩ上の伝送のためのルックデータを準備するためのルックデータ伝送準備装置２９９を含む。コンテンツ２０２及びルックデータ２０６は、コンテンツオーサリング部２１０で結合される（２０７）。１つ又はそれよりも多い伝送及び／又は記憶媒体２２０を用いることよって、コンテンツ２０２及びこれに対応するルックデータ２０６は、システム１００のコンテンツ表示部２３０に順番に送られ、ここでコンテンツ２０２及びルックデータ２０６は切り離されて処理される。システム１００のコンテンツ表示部２３０は、例えば図１に示される表示装置１３０を含むことができる。ルックデータ２０６は、システム１００のコンテンツ表示部２３０に配置されるルックデータデータベース２３２に次いで記憶される。図２に示されて伝送及び／又は記憶媒体２２０は、コンテンツ２０２及び／又はルックデータ２０６の連続した伝送及び／又は記憶をまとめていることが認識されるべきである。
【００２９】
図３は、本発明の変形例に従って並行ルックデータ伝送を実現している図１のシステム１００のより詳細な上位のブロック図を示す。図３の実施形態において、コンテンツ３０２及びルックデータデータベース３０４は、システム３００のコンテンツオーサリング部３１０に配置される。図３の実施形態において、ルックデータベース３０４はルックデータ３０６を記憶する。１つの実施形態において、システム３００のコンテンツオーサリング部３１０は、以降で更に説明されるように、ルックデータ３０６を生成するためのルックデータ発生器３８８、及び、ＨＤＭＩ上で伝送するためにルックデータ３０６を準備するルックデータ伝送準備装置３９９を含む。コンテンツ３０２及びルックデータ３０６はコンテンツオーサリング部３１０で結合される（３０７）。１つ又はそれよりも多い伝送及び／又は記憶媒体３２０を用いることよって、コンテンツ３０２及びこれに対応するルックデータ３０６はシステム３００のコンテンツ表示部３３０に並行して送信され、ここでコンテンツ３０２及びルックデータ３０６は切り離されて処理される。システム３００のコンテンツ表示部３３０は、例えば図１に示された表示装置１３０を含むことができる。ルックデータ３０６は、システム３００のコンテンツ表示部３３０に配置されるルックデータデータベース３３２で次いで記憶される。図３に示された伝送及び／又は記憶媒体３２０は、コンテンツ３０２及び／又はルックデータ３０６の並列伝送及び／又は記憶をまとめていることが認識されるべきである。
【００３０】
図４は、本発明の実施形態に従ったルックデータ定義及び伝送のための方法のフローチャートを示す。方法４００はステップ４０２で始まり、ここでルックデータがビデオコンテンツのために生成される。斯かるルックデータは、制限されないが、操作、空間フィルタリング処理、モーション挙動、フィルム粒子、ノイズ、編集、トーンマッピング、その他に関連し得る。斯かるルックデータは、前述の斯かる機能を実現し且つ修正する機構に関連するターンオン及びターンオフを制御するのに用いることができる。本方法は次いでステップ４０４に進む。
【００３１】
ステップ４０４において、ルックデータが伝送のために準備され、限定されないが、ルックデータ（ステップ４０２で以前に生成された）のための１つ又はそれよりも多いルックデータエレメンタリメッセージを生成すること、１つ又はそれよりも多いルックデータエレメンタリメッセージを含む１つ又はそれよりも多いルックデータパケットを生成すること、ルックデータをディスク等に記憶すること、及びその他を含む。本方法は次いでステップ４０６に進む。
【００３２】
ステップ４０６において、ルックデータ及びビデオコンテンツはＨＤＭＩを用いて表示装置に伝送される。斯かる伝送は、限定されないが例として、ＨＤＭＩ色メタデータ、ＣＥＡ／ＨＤＭＩベンダー指定インフォフレーム、ＨＤＭＩ／ＣＥＣ（家電エレクトロニクス制御）プロトコルを用いてなされ得る。上記伝送へのＨＤＭＩ色メタデータの使用に関しては、色域境界記述（ＧＢＤ）メタデータコンテナ（container）を用いることができる。上記伝送へのＣＥＡ／ＨＤＭＩベンダー指定インフォフレームの使用に関して、ＧＢＤフロー制御をベンダー指定インフォフレームに適用することができる。上記伝送へのＨＤＭＩ ＣＥＣプロトコルの使用に関して、ＣＥＣの上にネットワーク抽象レイヤを加えてサービス品質（ＱｏＳ）の使用を可能とし、ビデオに対してＣＥＣの時間合わせをすることができる。本方法は次いでステップ４０８に進む。
【００３３】
ステップ４０８において、ビデオコンテンツが受信され、記憶され、ルックデータに従って修正され、該修正されたビデオコンテンツが表示装置において表示される。方法４００は次いで出口処理され得る。
【００３４】
受信、記憶及び修正の前述の順序は実際の実現形態に依存して変更され得ることが認識されるべきである。例えば、記憶とはメタデータが記憶媒体上で提供されていることに相当し得る、及び／又は、次処理のためのコンテンツ解釈側上での同一物の一時的な記憶に相当し得る。
【００３５】
本発明の１つの実施形態において、高精細デジタルビデオディスク（ＨＤ ＤＶＤ）及び／又はブルーレイディスクのためのコンテンツを作成するのに本発明の原理が用いられ、斯かる作成は、国際標準化機構／国際電気標準会議（ＩＳＯ／Ｉ ＥＣ）動画専門家グループ４（ＭＰＥＧ―４）パート１０先端ビデオ符号化（ＡＶＣ）標準／国際電気通信連合、テレコミニケーション部門（ＩＴＵ−Ｔ）Ｈ．２６４勧告（以下、「ＭＰＥＧ―４ＡＶＣ標準」と称する）に従ってコンテンツをコード化すること、コンテンツをディスクに記憶すること、次いで、表示装置における信号処理装置を制御して表示用のビデオデータを修正すること、によってなされる。斯かる適用において、ルックデータがディスクに記憶される。ルックデータは、次いで高精細マルチメディアインタフェース（ＨＤＭＩ）を用いて表示装置に伝送される。ルックデータを送信するのにＨＤＭＩを用いるための様々な例示的な方法が本明細書において説明される。もちろん、本原理が記載された実施形態にだけに限られず、本明細書において提供される本原理の教示が与えられて、本技術及び関連技術における当業者は、本原理の趣旨を維持しつつ、これら及び他の様々な実施形態及びそれらの変形形態を企図するであろうことが認識されるべきである。
【００３６】
様々な実施形態において、本原理が、限定するものではないが動画製造における「デジタル・デイリーズ（digital dailies）」処理を含む専門的及び準専門的環境で用いることができることが認識されるべきである。
【００３７】
シーン結合データ
図５は、本原理の実施形態に従った、ルックデータ５００の例示的な表現を示す。図５のルックデータ５００は、各シーン毎又はシーケンス、すなわちシーン５１５に１つのルックデータパケット５１０を含む。尚、シーン境界の画定は通常、コンテンツ制作者次第である点に留意する必要がある。図５に図示されるように、各ルックデータパケット（ＬＤＰ）５１０は、１つ又はそれよりも多いルックデータエレメンタリメッセージ５２０を含むことができる。各ルックデータエレメンタリメッセージ（ＬＤＥＭ）は、コンテンツ描画及び／又は表示のために、１つの信号処理装置を制御するパラメータ５２５を含むことができる。より具体的には、本発明の実施形態に従って、ルックデータエレメンタリメッセージ５２０及びパラメータ５２５の如きルックデータパケット５１０は、コンテンツ描画装置を含む表示装置に向けてそれぞれのビデオコンテンツと共に配布されるか又は伝達されるべきことが意図されている。表示システムにおいて、コンテンツ描画装置（例えば、ディスプレイ又はセットトップボックスのデコータ）は、ルックデータパケット５１０をそれぞれのビデオコンテンツに適用し、ルックデータが作成されたシーン又はシーケンス状のシーンの表示属性を、ルックデータエレメンタリメッセージ５２０におけるパラメータに従って作用するか又はこれを変更する。
【００３８】
１つの実施形態において、もしシーン５１５間でルックデータ５００が同一であると判定される場合、シーン変更においてルックデータを更新することによらずして、ルックデータ５００がシーン５１５中で共有され得る。このように、ルックデータ５００は、ルックデータ５００が無効にされるか又は更新される迄、有効なままである。斯かる無効は、「ルックデータエレメンタリメッセージ」における「データ有効」タグを「無効」に設定することよってＬＤＥＭメタデータの適用を停止することを伴う。その変形例は、同一のタグＩＤを備える新たなＬＤＥＭを送信することである。
【００３９】
ルックデータパケット
本発明の１つの実施形態において、ルックデータパケット伝送のために、「ＫＬＶ」（鍵、長さ、値）メタデータ概念が実装されるが、他の周知のルックデータパケット伝送概念が実装され得る。すなわち、本明細書において１つ又はそれよりも多い実施形態がＫＬＶメタデータ概念に関して説明される一方で、本原理がＫＬＶメタデータ概念を単に実現するだけであるとは限定されず、ルックデータパケットを実現する他の方法も本原理の趣旨を維持しつつ本発明の様々な実施形態に従って実現され得ることが認識されるべきである。
【００４０】
ＫＬＶ概念は、コンテンツを解釈せずともパケット通信が完結される場合を認識する伝送装置に対して有用である。これは、図６及び図７で例示される。例えば、図６は、本発明の実施形態に従った、ルックデータエレメンタリメッセージの使用のためのメタデータ６００の例示的なＫＬＶ表記を示している。図７は、本発明の実施形態に従った、図６のメタデータ６００のＫＬＶ表記を更に詳細に示す。
【００４１】
図６及び図７を参照してより具体的には、各パケットは、例えばメッセージが「ルックデータ」に関係している旨の如きメッセージの性質を指示する「鍵」フィールド６１０を含む。この鍵は、時間スタンプ６１７、又は変形例として「シーンＩＤ」を含むことによって、受信装置はそのデータがどのシーンに適用されるべきかを直ちに知ることができる。時間スタンプ６１７及び／又はシーンＩＤの使用はオプションであり、例えば、時間コード追跡が生じるシステムに対して用いられ得ることが認識されるべきである。更に、各パケットは、そのパケットのペイロード部分におけるワード数を示す長さフィールド６２０を含むことができる。長さフィールド６２０もオプションであり、その使用は例えばメタデータタグに依存することが認識されるべきである。
【００４２】
更に、各パケットは、そのパケットのペイロード部分を担う値フィールド６３０を含むことができる。１つの実施形態において、ペイロードコンテンツのワードサイズはメタデータタグによって決定することができる。本発明の１つの実施形態において、ペイロードは例えば個々の「ルックデータエレメンタリメッセージ」を含むことができ、ＫＬＶの他のレイヤが用いられるか、又は変形例としてＫＶ（鍵及び値）だけが用いられ得る。
【００４３】
ルックデータエレメンタリメッセージ
１．色操作
本発明の１つの実施形態において、色操作はルックデータエレメンタリメッセージで定義することができる。すなわち、色操作は、例えば１つ又はそれよりも多い３Ｄ−ＬＵＴ、１つ又はそれよりも多い１Ｄ−ＬＵＴ、及び／又は１つ又はそれよりも多い３×３ＬＵＴによって実現することができる。例えば、斯かるルックデータエレメンタリメッセージの例示的な定義が図８〜図１４で提供される。
【００４４】
より具体的には、図８は、本発明の実施形態に従って８ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ８００を示す。図８に図示されるように、ルックデータエレメンタリメッセージ８００は、タグＩＤ部８１０、及び、値部８２０を含む。値部８２０は、例示として、有効性部、カラー空間定義部、長さ定義部、及び、値部を含む。図８のルックデータエレメンタリメッセージ８００の各部はそれぞれの記述部及び名称部を含む。図８のタグＩＤ部８１０は、３Ｄ−ＬＵＴの８ビットＩＤを定義し、これは例示として０×１１である。値部８２０において、有効性部はデータが有効であるか否かを定義し、図８では例示としてブール代数で定義されている。値部８２０において、カラー空間部はカラー空間を定義し、図８では例示として［００］＝ＲＧＢ、［０１］＝ＸＹＺ、［１０］＝ＹＣｒＣｂ、及び［１１］予備と定義されている。
【００４５】
図８の値部８２０における長さ定義部は、ペイロードの長さをバイトで定義し、これは例示として８ビットノードデータであると仮定されている。加えて、値部は様々な値を定義し、例えば、ＬＵＴノードデータ、例示的には規則的と仮定される入力データの間隔、ワード（word）定義及び順番を定義し、例示的には、「第１ワードＲＥＤ、ＣＩＥ＿Ｘ、又はＹ」、「第２ワードＧＲＥＥＮ、ＣＩＥ＿Ｙ、又はＣｒ」及び「第３ワードＢＬＵＥ、ＣＩＥ＿Ｚ、又はＣｂ」と定義する。図８のルックデータエレメンタリメッセージ８００において、値部は、また、例示的には「ＢＬＵＥが最初に変化し、次いで緑色、次いでＲＥＤ」とする格子走査を定義する。
【００４６】
図９は、本発明の実施形態に従って１０ビットのビット深度を有する３Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ９００を示す。図９のルックデータエレメンタリメッセージ９００は、図９の３Ｄ−ＬＵＴのＩＤが１０ビットのビット深度を有し且つ０×１２の値を有すること以外、図８のルックデータエレメンタリメッセージ８００と実質的に同様である。加えて、図９のルックデータエレメンタリメッセージ９００において、長さ定義部は、１つの３２ビットワードにパケット化される１０ビットのノードデータであると例示的に仮定されるペイロードの長さを定義する。更に、図９の実施形態において、値部は更にワード「ＲＥＤ」、「ＧＲＥＥＮ」及び「ＢＬＵＥ」を以下のように定義する。
Ｗｏｒｄ＝ＲＥＤ＜＜２０＋ＧＲＥＥＮ＜＜１０＋ＢＬＵＥ
【００４７】
図１０は、本発明の実施形態に従って８ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１０００を示す。図１０のルックデータエレメンタリメッセージ１０００において、１Ｄ−ＬＵＴのＩＤは８ビットのビット深度を有し且つ０×１３の値を有する。図８及び図９の上記のルックデータエレメンタリメッセージとは異なり、図１０のルックデータエレメンタリメッセージ１０００において、カラー定義部は、ＬＵＴがＲＥＤチャネル、ＧＲＥＥＮチャネル若しくはＢＬＵＥチャネルのためのＬＵＴであるか否か、又はＬＵＴが全てのチャネルに適用されるかについて定義する。図１０において、カラー値が例示的には、［００］＝ＲＥＤ又はＣＩＥ＿Ｘ又はＹ１、［０１］＝ＧＲＥＥＮ又はＣＩＥ＿Ｙ又はＣｒ、［１０］＝ＢＬＵＥ又はＣＩＥ＿Ｚ又はＣｂ、及び［Ｈ］＝全チャネルと定義される。加えて、ルックデータエレメンタリメッセージ１０００において、値部は、ＬＵＴの出力データが最小入力値に対して出力値２５６で始める８ビットの値であると想定されることを定義する。
【００４８】
図１１は、本発明の実施形態に従って１０ビットのビット深度を有する１Ｄ−ＬＵＴとして実現される例示的なルックデータエレメンタリメッセージ１１００を示す。図１１のルックデータエレメンタリメッセージ１１００は、図１１の実施形態において、ルックデータエレメンタリメッセージ１１００が１０ビットのビット深度を有し且つ０×１４の値を有するＩＤを含むこと以外、図１０のルックデータエレメンタリメッセージ１０００と実質的に同様である。加えて、ルックデータエレメンタリメッセージ１１００において、値部は、ＬＵＴ出力データが最小入力値に対して出力値１０２４で始まる１０ビットの値であること、３つの１０ビットの値が１つの３２ビットワードに以下のようにパケット化されることを定義する。
Ｗｏｒｄ＝ＬＵＴ［０］＜＜２０＋ＬＵＴ［１］＜＜１０＋ＬＵＴ［２］
【００４９】
図１２は、本発明の実施形態に従って１０ビットのビット深度を有する３×３マトリックスとして実現された例示的なルックデータエレメンタリメッセージ１２００を示す。ルックデータエレメンタリメッセージ１２００において、カラー定義部は、［００］＝ＲＧＢからＲＧＢ（γ）、［０１］＝ＲＧＢからＲＧＢ（線形）、及び［Ｈ］＝ＸＹＺからＸＹＺ、とするマトリックス適用を定義する。加えて、図１２のルックデータエレメンタリメッセージ１２００において、値部は、以下のような形の９つの１０ビットとして想定される係数を定義する。
【００５０】
［ Ｂ１［ Ｃ１ Ｃ２ Ｃ３［ Ａ１
Ｂ２ ＝ Ｃ４ Ｃ５ Ｃ６ × Ａ２
Ｂ３ ］Ｃ７ Ｃ８ Ｃ９ ］Ａ３ ］
ここにおいて、Ａ１及びＢ１はＲＥＤ又はＣＩＥ＿Ｘであり、Ａ２及びＢ２はＧＲＥＥＮ又はＣＩＥ＿Ｙであり、並びに、Ａ３及びＢ３はＢＬＵＥ又はＣＩＥ＿Ｚであり、そしてシーケンスの順序はＣ１−Ｃ２−Ｃ３である。図１２のルックデータエレメンタリメッセージ１２００において、値部は、３つの係数が１つの３２ビットワードにパケット化されることによって、総ペイロードが３×３２ビット＝９６であり、以下のような値を有することを定義する。
Ｗｏｒｄ＝Ｃ１＜＜２０＋Ｃ２＜＜１０＋Ｃ３
【００５１】
図１３は、本発明の実施形態に従って８ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１３００を示す。図１３のルックデータエレメンタリメッセージ１３００は、図１３の実施形態においてルックデータエレメンタリメッセージ１３００が８ビットのビット深度を有し且つ０×１６の値であるＩＤを含むこと以外、図１２のルックデータエレメンタリメッセージ１２００と実質的に同様である。加えて、図１３のルックデータエレメンタリメッセージ１３００において、総ペイロードは９×８ビット＝７２ビットである。
【００５２】
図１４は、本原理の実施形態に従って１６ビットのビット深度を有する３×３マトリックスとして実現される例示的なルックデータエレメンタリメッセージ１４００を示す。図１４のルックデータエレメンタリメッセージ１４００は、図１４の実施形態においてルックデータエレメンタリメッセージ１４００が１６ビットのビット深度を有し且つ０×１７の値を有するＩＤを含むこと以外、図１２のルックデータエレメンタリメッセージ１２００及び図１３のルックデータエレメンタリメッセージ１３００と実質的に同様である。加えて、図１４のルックデータエレメンタリメッセージ１４００において、総ペイロードは９×１６ビット＝１４４ビットである。
【００５３】
２．空間フィルタ
本発明の実施形態において、空間フィルタ制御はルックデータエレメンタリメッセージで指定することができる。例えば、空間応答又は周波数応答は空間領域フィルタリング処理を用いて修正することができる。空間周波数応答を修正する１つの例示的な方法は、複数の有限応答（ＦＩＲ）フィルタからなり各々のフィルタが特定の中心周波数に合わせられるパンクを用いることである。図１５は、本発明の実施形態に従った、周波数応答修正のため例示的なフィルタバンク１５００を示す。図１５のフィルタバンク１５００は、例示的には、複数のフィルタ１５１０、少なくとも１つの乗算器１５２０、及び、少なくとも１つの合成器１５３０を含む。
【００５４】
１つの実施形態において、画像の周波数応答はフィルタ係数（ＣＯ．．ＣＮ）を変えることよって操作されて、周波数のディテールを増強又は減衰させる。例えば、図１６は、本発明の実施形態に従った、周波数イコライゼイションのための例示的な離散的周波数１６００を示す。図１６に図示されるように、フィルタ係数（Ｃ０．．ＣＮ）は周波数応答についてルックデータエレメンタリメッセージで指定することができる。
【００５５】
例えば、図１７は、本発明の実施形態に従った、８ビット周波数イコライゼイションのための例示的なルックデータエレメンタリメッセージ１７００を示す。図１７の実施形態に図示されるように、ルックデータエレメンタリメッセージ１７００は、周波数イコライザのために、例えば最高１６個且つ４ビットの幾つかの係数を定義し、各係数が１つの周波数帯域乗数器を制御することを定義する。
【００５６】
３．モーション挙動
１つの実施形態において、モーション挙動制御は、表示がモーション挙動を所望モーション挙動に整合させることを可能とする情報を含むメッセージを利用して、ルックデータエレメンタリメッセージで指定することができる。この情報は所望のモーション挙動の仕様を担い、加えて表示における処理を単純化するコンテンツ前処理装置からのヘルパーデータを担うことができる。例えば、本発明の実施形態に従った、図１８はモーション挙動のための例示的なルックデータエレメンタリメッセージ１８００を示す。図１８の実施形態のルックデータエレメンタリメッセージ１８００は、例示的には、ＨZでの入力フレームレート（Ｕ８）、フィールド繰り返し度（Ｕ８）、所望ディスプレイ挙動（Ｕ１６）、及び、ｘ／ｙでのアイモーション挙動（２×Ｕ３２）を定義する。加えて、図１８の実施形態のルックデータエレメンタリメッセージ１８００において、前処理又はモーション推定があるか否かが定義される。
【００５７】
４．フィルム粒子
１つの実施形態において、フィルム粒子制御がルックデータエレメンタリメッセージで指定され得る。本発明の１つの実施形態において、フィルム粒子メッセージは、ＭＰＥＧ−４ＡＶＣ標準のペイロードタイプ＝１９から採用することができる。図１９は、本発明の実施形態に従った、フィルム粒子のための例示的なルックデータエレメンタリメッセージ１９００を示す。
【００５８】
５．ノイズ
１つの実施形態において、ノイズ制御は、ルックデータエレメンタリメッセージで指定することができる。すなわち、白色ノイズの決定されたレベルを全ての色チャネルに対して同一に印加することが可能であり、又はノイズについてのルックデータエレメンタリメッセージ内でチャネル当たりに１つの特定レベル／挙動を印加することが可能である。更に、ある実施形態においてノイズが１つ又はそれよりも多い色チャネルから除去され得る。１つの実施形態において、ノイズ特性は、上記に説明されたように、空間応答と同様に周波数応答を修正することよって変更され得る。図２０は、本発明の実施形態に従った、ノイズのための例示的なルックデータエレメンタリメッセージ２０００を示す。
【００５９】
６．編集
ある実施形態において、１つ又はそれよりも多いシーンの編集がルックデータエレメンタリメッセージで指定され得る。例えば、本発明のルックデータエレメンタリメッセージに従って、シーン又は一群のシーンから１つ又はそれよりも多いセグメントを切り出すことが可能である。このように、その切り出されたシーンは編集データの更新による後の時刻で表示することができる。このように実施形態において、特定のシーン内の入り及び出の時刻コードの「カットリスト」が伝送され得る。１つの実施形態において、あるシーンの最初のフレームは時刻符号００：００：００：００（ＨＨ：ＭＭ：ＳＳ：ＦＦ）を有することになる。図２１は、本発明の実施形態に従った、編集制御のために用いられ得る時間編集のための例示的なルックデータエレメンタリメッセージ２１００を示す。
【００６０】
７．トーンマッピング
１つの実施形態において、トーンマッピングは、ルックデータエレメンタリメッセージで指定される。例えば高ダイナミックレンジ画像を低ダイナミックレンジ画像に変換する場合に、トーンマッピングが用いられ得る。例えば、典型的適用は、１０ビットコード化された画像から８ビット又は７ビット画像への転換があり得るであろう。本原理は何らかの特定のトーンマッピングアルゴリズムに限定されないことが認識されるべきであり、従って、何らかのトーンマッピングへのアプローチも本原理の趣旨を維持しつつ本発明に従って用いられ得る。１つの実施形態として、トーンマッピングがＭＰＥＧ−４のＡＶＣ標準における補足的強化情報（ＳＥＩ）メッセージにて指定され得る。例えば、図２２は、本発明の実施形態に従った、トーンマッピングのための例示的なルックデータエレメンタリメッセージ２２００を示す。図２２のルックデータエレメンタリメッセージ２２００はまたＳＥＩメッセージで指定され得るパラメータを指定し得る。
【００６１】
ルックデータ伝送
ＨＤＭＩにおいて、ルックデータを送信することのための異なる方法がある。ルックデータを送信することのための例示的な幾つかの方法は、色域メタデータ以外のデータ、「ベンダー仕様インフォフレーム」の使用及び具体的にベンダーが命令する家電エレクトロニクス制御（ＣＥＣ）の使用のための「色域メタデータパッケージ(Gamut Metadata Package)」の使用を含むが、これに限定されない。
【００６２】
１．ＨＤＭＩ色メタデータ
ＨＤＭＩ仕様の現在バージョンが１．３Ａバージョンである点に留意すると、ＨＤＭＩ仕様のバージョン１．３以降、ＨＤＭＩを介して比色メタデータを転送する新たな方法があった。本発明の１つの実施形態において、その伝送可能性が、比色メタデータのみの伝送に代えて「ルックデータパケット」を送信するのに用いられる。従って、現在のＨＤＭＩ仕様のバージョン１．３Ａで例えばＧＢＤ＿ｐｒｏｆｉｌｅ＝７とすることによって用いられる色域プロファイルの使用が提案される。ＨＤＭＩ仕様バージョン１．３は、最高８００個のＨＤＭＩパケットの単一伝送を可能とするが、その仕様の将来バージョンでは異なるパケット総数が提供され得る。しかし、このための時間は１０ビデオフィールドにまで続くはずであるが、これはインタフェース仕様の将来バージョンによって変わり得る。ＨＤＭＩパケット当たり２８バイトとすると、これは合計で最高２１．８Ｋバイトになるであろう。
【００６３】
従って、斯かるルックデータ伝送に関する本発明の実施形態において、ルックデータパケットがＨＤＭＩ色域メタデータパケットの最大サイズよりも大きくないことが保証されるべきである。加えて、ルックデータパケットがシーンからシーンに適応されなければならない場合があり、その場合、シーンはルックデータパケットデータを共有するビデオフィールドの範囲になければならないように定義され、更新の斯かる瞬間に先行するシーンは、現在シーンの「ルックデータパケット」（ＬＤＰ）伝送に要する時間よりも短くてはならない。
【００６４】
仕様バージョン１．３に従ったＨＤＭＩ比色メタデータを用いる場合、パケットの長さが算出されるべきであり、図２３に示されるように、ＧＢＤ＿Ｌｅｎｇｔｈ＿Ｈ（高バイト）及びＧＢＤ＿Ｌｅｎｇｔｈ＿Ｌ（低バイト）が色域メタデータパケットの最初の２バイト中に充填される。つまり、図２３は、本発明の実施形態に従った本発明の実施形態が適用され得る例示的なＨＤＭＩ色域メタデータパケット２３００を示す。
【００６５】
１つの実施形態において、オプションのチェックサムは、ＧＢＤヘッダ及びルックデータパケット、並びに、もし適用可能なら何らかの充填データを含むパケット全体について実行することができる。図２４は、本発明の実施形態に従った、本発明が適用され得る例示的なＨＤＭＩ色域メタデータヘッダ２４００を示す。表１は、本発明の実施形態に従った、図２４に示された構文要素の意味を説明している。図２４及び表１の複数部分は、「ＨＤＭＩ規格バージョン１．３ａ」における表５−３０「色域メタデータパケットヘッダ」と称される部分から抽出されている。
【００６６】
【表１】
【００６７】
示されように、データは伝送のために、最初のＧＢＤパケットについて２２バイト、残りの全てのパケットについて２８バイトである個々のＨＤＭＩインタフェースパケットに分割され得る。もし最後のパケットが「ルックデータパケット」データで完全に充填されない場合、パケットは前述の「フィルデータ」で充填され、これは本発明の１つの実施形態において１つ又はそれよりも多い「０」を含むことができる。データフローについては、ＨＤＭＩ ＧＢＤデータフロー機構が、「Next_Field」、「Affected_Gamut_Seq_Num」、「Current_Garnut_Seq_Num」及び「Packet_Seq」によって用いられる（図２４参照）。適用されるべきルックデータがない場合に、「GBD_Profile」＝７（図２４参照）に従った「No_Current_GBD」の１つの伝送がこの要求の信号化にとって十分である。そして、全てのルックデータ映像信号修正は、新たなルックデータパケットが送信されるまでディスエーブル状態にある。
【００６８】
変形例として、「ＨＤＭＩ ＣＥＣプロトコル」に関して以降で説明されるような通信方法が用いられ得るが、ＧＢＤ通信方法は組込みのフレーム同期化方式を特徴とすることから好ましい。
【００６９】
図２５は、本発明の実施形態に従って、本発明が適用され得るＨＤＭＩバージョン１．３における例示的な色域メタデータパッケージ２５００を示す。色域メタデータパッケージ２５００は、実際のビデオ部分２５１０、発生源におけるＧＢＤインフォ部分２５２０、ＶＳＹＮＣ部分２５３０、色域メタデータパケット部分２５４０、及び、シンク（sink）装置の会話テーブル部分２５５０を含む。図２５の部分は、「ＨＤＭＩバージョン１．３ａ」から抽出され、図５〜図６における「ＰＯ伝送シーケンス例」が参照される。
【００７０】
２．ＣＥＡ／ＨＤＭＩベンダー指定インフォフレーム
上記のようなＨＤＭＩ ＧＢＤメタデータを実現する代わりに、本発明の変形例において、「ベンダー指定インフォフレーム」が本発明に従って用いられ得る。ベンダー指定のインフォフレームは、例えば、ＣＥＡ−８６１−Ｄ仕様６．１章に記載されている。ＨＤＭＩ仕様は、その５．３．５章に記載されるように、ＣＥＡ−８６１−Ｄインフォフレームの使用を可能とする。実際、インフォフレームパケットは長さ２８バイトである。色域メタデータパケットと比した唯一の差異は、パケットサイズが１つのインフォフレームだけに制限されていることである。本発明の１つの実施形態において、ベンダー指定インフォフレームについてＧＢＤメタデータフロー制御を用いることが提案される。すなわち、１つの実施形態において、１つのパケットだけとするベンダー指定インフォフレームの上述した制限に依存して、長さフィールドがサイズについてだけ５ビットであるとする修正が用いられ得る。これは、長さ情報及び巡回冗長符号（ＣＲＣ）情報が、「ＧＢＤ様式」ヘッダ、ルックデータパケットヘッダ（図２６参照）に置かれるべきであることを意味し、これは従って３バイトから６バイトに増大する。つまり、図２６は、本発明の実施形態に従った、ＨＤＭＩバージョン１．３と共に用いられるベンダー指定インフォフレームのための例示的なルックデータパケットヘッダ２６００を示す。
【００７１】
表２は、以下のように、本発明の実施形態に従った図２６で示された構文要素の意味を説明している。
【００７２】
【表２】
【００７３】
図２７は、本発明の実施形態に従った、例えば、本発明が適用され得るＣＥＡ８６１Ｄにおける例示的なベンダー指定インフォフレーム２７００を示す。図２７のベンダー指定インフォフレーム２７００は、例示的には、バイト番号、フィールド名、及び、コンテンツを定義する。図２７に図示されるように、ベンダー指定インフォフレーム２７００は、例示的には、０１16の値を有するベンダー指定インフォフレームタイプコードとして「ｎ」バイトを定義する。ベンダー指定インフォフレーム２７００は、０１16の値を有するベンダー指定インフォフレームバージョンとしてのｎ＋１フレーム、ＩＥＥＥ登録ＩＤを含むインフォフレームペイロードにおける総バイトに等しい値を有するＬｖインフォフレームとしてのｎ＋２フレーム、２４ビットのＩＥＥＥ登録識別子（ＬＳＢが先）としてのｎ＋３，４，５番のフレーム、及び、ベンダー仕様ペイロードとしてのｎ＋Ｌｖ−１1フレームを更に定義する。
【００７４】
したがって、図２８は本発明の実施形態に従った、ルックデータを伝送するための例示的なベンダー指定ＣＥＣ命令２８００を示す。図２８のベンダー指定ＣＥＣ命令２８００は、例示的には、名称、記述及び様々なＣＥＣ命令のための値を定義する。より具体的には、図２８の実施形態において、特別なスタートビットが定義される。更に、ベンダーＩＤ、すなわち例示的にはＩＥＥＥベンダーアドレスがＩＥＥＥ ＯＵＩ割り当てに等しい３バイトとして定義される。図２８のベンダー指定ＣＥＣ命令２８００は、また、タグ番号の１バイト値を有するオプトコード（optcode）として第１のデータブロックを定義する。第２のデータブロックで始めるベンダー指定ＣＥＣ命令２８００において、長さ、パケットシーケンス及びオペランドを定義しているオペランドブロックが定義される。より具体的には、引き続くデータの長さがバイトで定義される。パケットシーケンスは、図２８の実施形態において例示的には、色域メタデータパケットシーケンスにおいて、あるパケットが唯一であるか、最初又は最後のパケットであるかを指示する２ビットを用いて定義される。斯かるパケットシーケンスは例示的には図２８で以下のように定義される。
【００７５】
＝０（０ｂ００） シーケンス内の中途のパケット
＝１（０ｂ０１） シーケンス内の最初のパケット
＝２（０ｂ１０） シーケンス内の最後のパケット
＝３（０ｂ１１） シーケンス内の唯一のパケット
【００７６】
３．ＨＤＭＩ ＣＥＣプロトコル
家電エレクトロニクス制御（ＣＥＣ）はＨＤＭＩにおける双方向コントロールバスである。このバスはこれ自体に接続される幾つかのオーディオ／ピジュアル（ＡＶ）装置によって用いられるべき共有媒体である。
【００７７】
このバスは性質上１００〜２００ビット／秒の範囲の生データ伝送速度を有しており非常に遅い。単一のベンダー指定ＣＥＣメッセージは、ＨＤＭＩ仕様バージョン１．３ａに従った最大１６×１０ビットの生サイズと、最高１１×８ビットの生ペイロードを有する。プロトコル及びデータフローについて１００％乃至２００％のオーバヘッドを考慮すると、１つのＣＥＣメッセージの伝送に数秒を要することになる。これは、もし先の２つの方法によって最大限可能であるような同一のデータ量、すなわち２１．８Ｋバイトである場合、伝送に数分を要することを意味する。この伝送の間にもし他の何らかの装置がバスを用いない場合には、これは正に真実であり、場合によっては伝送時間が更に増加することになる。
【００７８】
従って、ルックデータパケットがサイズ上制限されることが賢明である。この速度を考慮すると、一定のルックデータエレメンタリメッセージが日々の使用に用いられることは非実用的である（特にＬＵＴダウンロード、図８〜図１１を参照）。
【００７９】
それにもかかわらず、ＣＥＣフレームのペイロードサイズを考慮すると、ルックデータパケットが１つのＣＥＣフレームよりも長くなることは殆ど不可避である。ＣＥＣが単純な応用のために設計されたという事実に起因して、本発明の実施形態に従った通信をより堅牢にするために、抽象レイヤがＣＥＣの上に実装され得る。
【００８０】
より具体的に且つ国際電気標準会議オープンシステム相互接続（ＩＳＯ／ＯＳＩ）参照モデルに関して、ＣＥＣ機能には、物理レイヤ、データリンク及びネットワークレイヤの一部が実装される。サービス品質（ＱｏＳ）はネットワークレイヤによっては提供されない。
【００８１】
従って、本発明の１つの実施形態において、ＱｏＳはＣＥＣプロトコル上で実装されるべきレイヤにおいて提供される。
【００８２】
図２９は、本発明の実施形態に従った、家電エレクトロニクス制御（ＣＥＣ）バスの用途のための例示的なネットワークレイヤモデル２９００を示す。ネットワークレイヤモデル２９００は、アプリケーションレイヤ２９０５、ＴＬ＿ＣＥＣレイヤ２９１０、ＣＥＣレイヤ２９１５、及び、ＣＥＣ−物理レイヤ（ＣＥＣ−物理）２９２０を含み、第１の装置（装置１）２９８１と第２の装置（装置２）２９８２の間の通信はＣＥＣ−物理レイヤ（ＣＥＣ−物理）２９２０で実行される。
【００８３】
図３０は、本発明の実施形態に従った、ＣＥＣベンダー指定コマンドによってアプリケーションからアプリケーションへの通信を提供するための例示的なＣＥＣ処理３０００の上位のブロック図を示す。すなわち、ＣＥＣ処理３０００に関して、ルックデータエレメンタリメッセージは、コンテンツ作成／オーサリングにおいて生成アプリケーション３００５によって生成される。ルックデータエレメンタリメッセージは、次いで１つのルックデータパケットになるようにパケット組立ブロック３０１０によって組み立てられる。巡回冗長符号（ＣＲＣ）はこのパケットからＣＲＣブロック３０１５によってＨＤＭＩに定義される方法で算出される。ここでのＣＲＣはチェックサムとして実装され、それはヘッダと更にチェックサムデータとを含む全パケットデータのバイト総合計が零に等しいように定義される。
【００８４】
続いて、ＣＲＣ及びルックデータパケットは、パケットからフレームへのブロック３０２０によって、通信のために適当なサイズのフレームに分離される。本発明の実施形態において、８８バイトのパケットサイズが例として用いられ得る。斯かる実施形態において、最初のＣＥＣメッセージは８ビットのＣＲＣデータを運び、ＣＲＣデータがルックデータパケット当たり一度だけ伝達される必要があることから、引き続くメッセージは次いで８ビットのもっと多くのペイロードデータを運ぶ。
【００８５】
変形例として図３１に図示されるように、ＣＲＣデータは伝送の終わり、すなわちフレームＮで伝送することができる。つまり、図３１はＨＤＭｌを用いた伝送のためにルックデータパケットのフレームへの例示的な変換３１００を例示する上位のブロック図を示している。再び戻って図３０を参照すると、データはＣＥＣ３０３０を介した伝送の準備ができている。
【００８６】
本発明の１つの実施形態において、受信側においては正に反対のことがなされる。つまり、フレームがルックデータパケットになるように分解され、チェックサムが算出され、次いで、ルックデータエレメンタリメッセージが受信側の適用に供するためにルックデータパケットから分解され、斯かる適用は典型的にはコンテンツクリエーターよって指定される意図に従った眺め（look）をここで変更する表示である。
【００８７】
ＣＲＣブロック３０１５はネットワークレイヤ２９００の一部である点に留意する必要がある。ＣＲＣエラーの場合、以下の２つの例示的なアプローチの何れかが実行され得るが、但し、本発明の原理が単に以下に説明される方法だけに限定されない点に留意する必要がある。第１の方法においてルックデータパケットは破棄することができる。第２の方法において再送要求を発効することができる。第１の方法の場合、以前に送信されたパケットは有効なままとなる。
【００８８】
図３１を再度参照すると、図３１は本発明の実施形態に従った、ＨＤＭＩを用いた伝送のためのフレームへのルックデータパケットの例示的な変換３１００を例示する上位のブロック図を示す。変換３１００は、与えられたルックデータパケット３１１０と、ＣＲＣ算出適用３１２０と、パケットからフレームへの変換３１３０とを伴い、結果としてのフレーム３１４０が、ＣＲＣ情報３１４５を有する最初のフレームと共に得られる。
【００８９】
以前に言及された方法の幾つかとは異なり、ＣＥＣは映像信号と共通する時刻基盤を有しない。従って、ルックデータパケットを同期させる本発明の実施形態において、伝送されたＬＤＰのパラメータ及びデータのローディングをシンク装置のビデオ処理ブロックと時間合わせするために、ＬＤＰ伝送の終わりに検証信号が用いられる。斯かるように、あるルックデータパケットがＣＥＣを介して伝送されても、特別な「検証(Validate)」ＣＥＣコマンドが伝送される迄無効なままである。
【００９０】
しかし、検証は実際には時間合わせされ得ない。斯かるように、本発明の１つの実施形態において、１つの可能性は適用時間の不確実性を推定し、ビデオ処理における変更が乱されないことを保証することである。シーン変更ブランキングが用いられ得る。「検証」信号は１バイト程度に短くできるが、ＣＥＣビットオーバヘッドによって図３２に示されるように、信号は最低６０ビットに足すところのスタートビットにまで増えることになる。つまり、図３２は、本発明の実施形態に従った、ルックデータ検証のための例示的なルックデータエレメンタリメッセージ３２００を示している。
【００９１】
従って、送信時間は、ＣＥＣ開始時間＋２０×ＣＥＣの公称データビット周期時間によって計算することができる。ＨＤＭＩ仕様バージョン１．３ａは、４．５ミリ秒の公称ＣＥＣ開始時間及び２．４ミリ秒の公称ＣＥＣデータ周期時間を提案している。これは４．５ミリ秒＋６０×２．４ミリ秒＝１４８．５ミリ秒の結果を与える。従って、「検証」信号は、６０Ｈｚの場合に９フィールドの遅延、５０Ｈｚの場合に８フィールドの遅延、又は２４Ｈｚの場合に４フィールドの遅延を有することになる。しかし、これはＨＤＭＩ仕様におけるＣＥＣ仕様のより新しいバージョンによっては変わり得る。
【００９２】
斯かるように、６０Ｈｚのフィールド周波数の場合、「検証」コマンドは適用に先立って少なくとも９フィールド前にＣＥＣ発生器から要求されなければならない。ＨＤＭＩシンク制御はビデオ及びＣＥＣ両方を介していることから、所与の画像コンテンツに間違ったＬＤＰデータを適用するのを回避するために、移行フェーズ中に画像コンテンツが消されるか又はＬＤＰ変更に対して脆弱にならないようにすることが提案される。移行フェーズは、ＨＤＭＩ仕様の手段で可能な最速のＣＥＣ移行時間と、最も遅いＣＥＣ伝送と、足すところのシンク装置におけるあり得る処理遅延とを仮定した伝送時間の間の期間であると判定される。
【００９３】
シーンベースのルックデータパケット変更の同期問題を解決するために、以下の例示的な方法が本発明の実施形態に従って提案される。すなわち、ＣＥＣをビデオに同期させるために、物理レベルのＣＥＣ動作が実行される。これは例えば図３３に示される装置によって達成することができる。
【００９４】
より具体的には、図３３は本発明の実施形態に従った、ＣＥＣ検証信号を生成するための例示的な装置３３００を示す。図３３の装置３３００は、例示的には、ＣＥＣ発生器３３１０、送信機側３３２０、受信器側３３３０、及び、ＣＥＣデコータ３３４０を含む。物理レベルのＣＥＣ動作は装置３３００よって実行され、装置３３００は送信機側３３２０においてＣＥＣの物理レイヤ動作を、ビデオ部のＶＳＹＮＣ（垂直同期信号）に同期させる。受信器側３３３０において、装置は、そのルックデータパケットデータ適用をＣＥＣ物理レイヤ動作に同期させることよるフレーム同期方式で、そのルックデータパケットデータの適用を画像処理に同期させる。これを装置３３００は、ＣＥＣ検証コマンド命令をＶＳＹＮＣに時間合わせし且つルックデータパケットデータ検証のために最後のバイトのＥＯＭ命令を待つことによって達成する。
【００９５】
図３４は、本発明の実施形態に従った、ＣＥＣによる検証信号伝送のための方法のフローチャートを示す。方法３４００はステップ３４１０で始まり、ＬＤＰがシンク装置に伝送される。方法３４００は次いでステップ３４２０に進む。
【００９６】
ステップ３４２０において、「検証」信号伝送はブロック３４２０におけるシンク装置のＣＥＣ発生器から要求される。方法３４００は次いでステップ３４３０に進む。
【００９７】
ステップ３４３０において、ＣＥＣジェネレータは、次のＶＳＹＮＣイベントで始まるＣＥＣ「検証」コマンドの伝送を開始する。
【００９８】
方法３４００は次いでステップ３４４０に進む。
【００９９】
ステップ３４４０において、シンク装置は「検証」信号を受信する。方法３４００は次いでステップ３４５０に進む。
【０１００】
ステップ３４５０において、シンク装置は伝送が完了される迄待ち、シンク装置での次の引き続くＶＳＹＮＣ信号イベントでＬＤＰデータを検証する。方法３４００は次いでステップ３４６０に進む。
【０１０１】
ステップ３４６０において、シンク装置はＬＤＰデータコンテンツをビデオ処理ブロックに適用する。方法３４００は次いで出口処理される。
【０１０２】
上記したように、「検証」信号の伝送時間は略５２．５ミリ秒であることになる。従って、「検証」信号は、６０Ｈｚの場合に４フィールドの遅延、５０Ｈｚ及び２４Ｈｚの場合に３フィールドの遅延を有することになる。従って、その適用に先立って略４フレーム前に、ＬＤＰ伝送が完了され且つ「検証」信号伝送が始動されることが必要である。その場合ＬＤＰ適用の不確実性は何ら存在しない。
【０１０３】
本発明の変形例において、他の伝送方法としては、ＬＤＰ伝送のための新しい将来ネットワーク化の可能性を含むことができる。例えば、将来、ＨＤＭＩは頂上レイヤ／レベル上に新しいネットワーク化チャネルを採用してもよく、或いは既存のＨＤＭＩ特有のデータ伝送可能性の幾つかを代替してもよい。この新しい伝送方法は、周知のネットワーク化技術に基づいてもよいし、ビデオ非同期であってもよい。このネットワーク技術は、ＬＤＰパケットを同一経路で送信するのに用いることかでき、ビデオ同期並びに本明細書で説明された本発明の様々な実施形態と共に説明されたパケット制御の如きＣＥＣ伝送の方法の利用に用いることができる。
【０１０４】
ルックデータ定義及びＨＤＭＩ（例示であり制限することが意図されない）上の伝送のための方法及びシステムについて好ましい実施形態が説明されたが、当業者によって上記教示を考慮した修正及び変様がなされ得る。従って、添付の特許請求の範囲よって画定される如き本発明の範囲及び趣旨内にある、本発明の特定の実施形態における変更がなされてもよいことを理解できよう。以上の記載は本発明の様々な実施形態を志向するものである一方、本発明の他の及び更なる実施形態が本発明の範囲から逸脱することなく考案されてもよい。
【特許請求の範囲】
【請求項１】
異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を説明することでビデオコンテンツをその表示前に修正するためのメタデータを、該ビデオコンテンツについて生成するステップ、及び、
前記メタデータ及び前記ビデオコンテンツを高精細マルチメディアインタフェース上の伝送のために準備するステップ
を含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で伝送するステップを含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能であることを特徴とする方法。
【請求項３】
請求項１に記載の方法において、
前記メタデータは、前記ビデオコンテンツに対して帯動及び非帯動のうちの少なくとも１つで伝送をなすために準備されることを特徴とする方法。
【請求項４】
請求項１に記載の方法において、
ＨＤＭＩ仕様の１．３Ａバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも１つを用いて、前記伝送のために前記メタデータが準備されることを特徴とする方法。
【請求項５】
請求項１に記載の方法において、
ベンダー指定されたインフォフレームを用いて、前記伝送のために前記メタデータが準備されることを特徴とする方法。
【請求項６】
請求項５に記載の方法において、
前記準備するステップは、色域境界記述フロー制御を前記ベンダー指定されたインフォフレームに適用することを含むことを特徴とする方法。
【請求項７】
請求項１に記載の方法において、
高精細マルチメディアインタフェース家電エレクトロニクス制御プロトコルを用いて、前記伝送のために前記メタデータが準備されることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、
前記準備するステップは、前記家電エレクトロニクス制御プロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも１つを含むことを特徴とする方法。
【請求項９】
請求項７に記載の方法において、
前記準備するステップは、前記家電エレクトロニクス制御プロトコルを前記ビデオコンテンツに時間合わせすること及び前記家電エレクトロニクス制御プロトコルを垂直同期信号に結合すること含むことを特徴とする方法。
【請求項１０】
請求項１に記載の方法において、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つのために、前記メタデータがあることを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、
前記メタデータは、１つ又はそれよりも多いルックアップテーブル及び１つ又はそれよりも多い色変換マトリックスのうちの少なくとも１つに対応することを特徴とする方法。
【請求項１２】
請求項１に記載の方法において、
前記準備するステップは、前記メタデータをパケット化することを含むことを特徴とする方法。
【請求項１３】
請求項１２に記載の方法において、更に、
前記パケットに挿入するための少なくとも１つのメッセージを生成するステップを含み、
該少なくとも１つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つに関係することを特徴とする方法。
【請求項１４】
請求項１に記載の方法において、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶するステップを含むことを特徴とする方法。
【請求項１５】
異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を説明することでビデオコンテンツをその表示前に修正するためのメタデータを該ビデオコンテンツについて生成するメタデータ生成器、及び、
高精細マルチメディアインタフェース上の伝送のために前記ビデオコンテンツ及び前記メタデータを準備するメタデータ伝送準備装置
を含むことを特徴とするシステム。
【請求項１６】
請求項１５に記載のシステムにおいて、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で送信する高精細マルチメディアインタフェース伝送装置を含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能であることを特徴とするシステム。
【請求項１７】
請求項１５に記載のシステムにおいて、
前記メタデータは、前記ビデオコンテンツに対して帯動及び非帯動のうちの少なくとも１つで伝送をなすために準備されることを特徴とするシステム。
【請求項１８】
請求項１５に記載のシステムにおいて、
前記ＨＤＭＩ規格の１．３Ａバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも１つ用いて、前記伝送のために前記メタデータが準備されることを特徴とするシステム。
【請求項１９】
請求項１５に記載のシステムにおいて、
前記メタデータは、ベンダー指定されたインフォフレームを用いて前記伝送のために準備されることを特徴とするシステム。
【請求項２０】
請求項１９に記載のシステムにおいて、
色域境界記述フロー制御が前記ベンダー指定されたインフォフレームに適用されることを特徴とするシステム。
【請求項２１】
請求項１５に記載のシステムにおいて、
前記メタデータは、高精細マルチメディアインタフェース家電エレクトロニクス制御プロトコルを用いて前記伝送のために準備されることを特徴とするシステム。
【請求項２２】
請求項２２に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記家電エレクトロニクス制御プロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも１つをなすことを特徴とするシステム。
【請求項２３】
請求項２２に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記家電エレクトロニクス制御プロトコルを垂直同期信号に結合することを含んで、前記家電エレクトロニクス制御プロトコルを前記ビデオコンテンツに時間合わせすることを特徴とするシステム。
【請求項２４】
請求項１５に記載のシステムにおいて、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つのために、前記メタデータがあることを特徴とするシステム。
【請求項２５】
請求項２４に記載のシステムにおいて、
前記メタデータは、１つ又はそれよりも多いルックアップテーブル及び１つ又はそれよりも多い色変換マトリックスのうちの少なくとも１つに対応することを特徴とするシステム。
【請求項２６】
請求項１５に記載のシステムにおいて、
前記メタデータはパケット化されることを特徴とするシステム。
【請求項２７】
請求項２６に記載のシステムにおいて、
前記パケットは少なくとも１つのメッセージを含み、
該少なくとも１つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つに関係することを特徴とするシステム。
【請求項２８】
請求項１５に記載のシステムにおいて、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶する記憶装置を含むことを特徴とするシステム。
【請求項１】
異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を説明することでビデオコンテンツをその表示前に修正するためのメタデータを、該ビデオコンテンツについて生成するステップ、及び、
前記メタデータ及び前記ビデオコンテンツを高精細マルチメディアインタフェース上の伝送のために準備するステップ
を含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で伝送するステップを含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能であることを特徴とする方法。
【請求項３】
請求項１に記載の方法において、
前記メタデータは、前記ビデオコンテンツに対して帯動及び非帯動のうちの少なくとも１つで伝送をなすために準備されることを特徴とする方法。
【請求項４】
請求項１に記載の方法において、
ＨＤＭＩ仕様の１．３Ａバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも１つを用いて、前記伝送のために前記メタデータが準備されることを特徴とする方法。
【請求項５】
請求項１に記載の方法において、
ベンダー指定されたインフォフレームを用いて、前記伝送のために前記メタデータが準備されることを特徴とする方法。
【請求項６】
請求項５に記載の方法において、
前記準備するステップは、色域境界記述フロー制御を前記ベンダー指定されたインフォフレームに適用することを含むことを特徴とする方法。
【請求項７】
請求項１に記載の方法において、
高精細マルチメディアインタフェース家電エレクトロニクス制御プロトコルを用いて、前記伝送のために前記メタデータが準備されることを特徴とする方法。
【請求項８】
請求項７に記載の方法において、
前記準備するステップは、前記家電エレクトロニクス制御プロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも１つを含むことを特徴とする方法。
【請求項９】
請求項７に記載の方法において、
前記準備するステップは、前記家電エレクトロニクス制御プロトコルを前記ビデオコンテンツに時間合わせすること及び前記家電エレクトロニクス制御プロトコルを垂直同期信号に結合すること含むことを特徴とする方法。
【請求項１０】
請求項１に記載の方法において、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つのために、前記メタデータがあることを特徴とする方法。
【請求項１１】
請求項１０に記載の方法において、
前記メタデータは、１つ又はそれよりも多いルックアップテーブル及び１つ又はそれよりも多い色変換マトリックスのうちの少なくとも１つに対応することを特徴とする方法。
【請求項１２】
請求項１に記載の方法において、
前記準備するステップは、前記メタデータをパケット化することを含むことを特徴とする方法。
【請求項１３】
請求項１２に記載の方法において、更に、
前記パケットに挿入するための少なくとも１つのメッセージを生成するステップを含み、
該少なくとも１つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つに関係することを特徴とする方法。
【請求項１４】
請求項１に記載の方法において、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶するステップを含むことを特徴とする方法。
【請求項１５】
異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を説明することでビデオコンテンツをその表示前に修正するためのメタデータを該ビデオコンテンツについて生成するメタデータ生成器、及び、
高精細マルチメディアインタフェース上の伝送のために前記ビデオコンテンツ及び前記メタデータを準備するメタデータ伝送準備装置
を含むことを特徴とするシステム。
【請求項１６】
請求項１５に記載のシステムにおいて、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で送信する高精細マルチメディアインタフェース伝送装置を含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能であることを特徴とするシステム。
【請求項１７】
請求項１５に記載のシステムにおいて、
前記メタデータは、前記ビデオコンテンツに対して帯動及び非帯動のうちの少なくとも１つで伝送をなすために準備されることを特徴とするシステム。
【請求項１８】
請求項１５に記載のシステムにおいて、
前記ＨＤＭＩ規格の１．３Ａバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも１つ用いて、前記伝送のために前記メタデータが準備されることを特徴とするシステム。
【請求項１９】
請求項１５に記載のシステムにおいて、
前記メタデータは、ベンダー指定されたインフォフレームを用いて前記伝送のために準備されることを特徴とするシステム。
【請求項２０】
請求項１９に記載のシステムにおいて、
色域境界記述フロー制御が前記ベンダー指定されたインフォフレームに適用されることを特徴とするシステム。
【請求項２１】
請求項１５に記載のシステムにおいて、
前記メタデータは、高精細マルチメディアインタフェース家電エレクトロニクス制御プロトコルを用いて前記伝送のために準備されることを特徴とするシステム。
【請求項２２】
請求項２２に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記家電エレクトロニクス制御プロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも１つをなすことを特徴とするシステム。
【請求項２３】
請求項２２に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記家電エレクトロニクス制御プロトコルを垂直同期信号に結合することを含んで、前記家電エレクトロニクス制御プロトコルを前記ビデオコンテンツに時間合わせすることを特徴とするシステム。
【請求項２４】
請求項１５に記載のシステムにおいて、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つのために、前記メタデータがあることを特徴とするシステム。
【請求項２５】
請求項２４に記載のシステムにおいて、
前記メタデータは、１つ又はそれよりも多いルックアップテーブル及び１つ又はそれよりも多い色変換マトリックスのうちの少なくとも１つに対応することを特徴とするシステム。
【請求項２６】
請求項１５に記載のシステムにおいて、
前記メタデータはパケット化されることを特徴とするシステム。
【請求項２７】
請求項２６に記載のシステムにおいて、
前記パケットは少なくとも１つのメッセージを含み、
該少なくとも１つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも１つに関係することを特徴とするシステム。
【請求項２８】
請求項１５に記載のシステムにおいて、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶する記憶装置を含むことを特徴とするシステム。
【図４】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２６】
【図２７】
【図２８】
【図２９】
【図３１】
【図３３】
【図３４】
【図２】
【図３】
【図５】
【図６】
【図７】
【図２３】
【図２４】
【図２５】
【図３０】
【図３２】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２６】
【図２７】
【図２８】
【図２９】
【図３１】
【図３３】
【図３４】
【図２】
【図３】
【図５】
【図６】
【図７】
【図２３】
【図２４】
【図２５】
【図３０】
【図３２】
【公表番号】特表２０１１−５１１５４５（Ｐ２０１１−５１１５４５Ａ）
【公表日】平成２３年４月７日（２０１１．４．７）
【国際特許分類】
【出願番号】特願２０１０−５４４７９５（Ｐ２０１０−５４４７９５）
【出願日】平成２０年１月３１日（２００８．１．３１）
【国際出願番号】ＰＣＴ／ＩＢ２００８／０００２２３
【国際公開番号】ＷＯ２００９／０９５７３２
【国際公開日】平成２１年８月６日（２００９．８．６）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公表日】平成２３年４月７日（２０１１．４．７）
【国際特許分類】
【出願日】平成２０年１月３１日（２００８．１．３１）
【国際出願番号】ＰＣＴ／ＩＢ２００８／０００２２３
【国際公開番号】ＷＯ２００９／０９５７３２
【国際公開日】平成２１年８月６日（２００９．８．６）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]