• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 訂正 ただし書き3号明りょうでない記載の釈明 訂正する H04N
管理番号 1299599
審判番号 訂正2015-390010  
総通号数 186 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2015-06-26 
種別 訂正の審決 
審判請求日 2015-01-23 
確定日 2015-03-05 
訂正明細書 有 
事件の表示 特許第5567498号に関する訂正審判事件について、次のとおり審決する。 
結論 特許第5567498号に係る特許請求の範囲を本件審判請求書に添付された訂正特許請求の範囲のとおり一群の請求項ごとに訂正することを認める。 
理由 第1 経緯
本件特許第5567498号に係る発明は、2008年(平成20年)1月31日を国際出願日とする出願であって、平成26年6月27日に特許権の設定登録がなされ、その後、平成27年1月23日付けで本件審判が請求されたものである。

第2 請求
1.請求の趣旨
本件審判の請求の趣旨は、特許第5567498号の特許請求の範囲を本件審判請求書に添付した特許請求の範囲のとおり請求項15?28からなる一群の請求項ごとに訂正することを認める、との審決を求めるものである。

2.訂正事項
(1)請求項15ないし請求項28からなる一群の請求項に係る訂正
ア.訂正事項1
特許請求の範囲の請求項15に
「ビデオコンテンツの視覚特性を特定するためのメタデータを生成するメタデータ生成器であって、前記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられるメタデータであって、、」
とあるのを、
「ビデオコンテンツの視覚特性を特定するためのメタデータを生成するメタデータ生成器であって、前記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられる、前記メタデータ生成器、」
に訂正する。

第3 当審の判断
1.一群の請求項について
上記訂正事項1に係る本件訂正後の請求項15ないし請求項28は、上記訂正事項1を含む請求項15の記載を請求項16ないし請求項28が直接又は間接的に引用するものであるから、本件訂正後の請求項15ないし請求項28は、特許法第126条第3項に規定する特許法施行規則第46条の2第1号ないし第4号の関係を有する一群の請求項である。

よって、本件訂正審判の請求は、特許法第126条第3項の規定に適合するものである。

2.訂正の目的
請求人は、請求項15ないし請求項28からなる一群の請求項に係る訂正の理由を「不明瞭な記載の釈明」としていることから、訂正事項1が明瞭でない記載の釈明を目的としたものであるか否かを検討する。

請求項15は、請求項1の方法の発明に対応するシステムの発明であると認められるところ、請求項1の発明においては、メタデータはメタデータを生成するステップにおいて生成され、そのメタデータを生成するステップは、
「ビデオコンテンツの視覚特性を特定するためのメタデータを生成するステップであって、前記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられる、前記生成するステップ、」
と記載されている。それに対し、訂正前の請求項15は、
「ビデオコンテンツの視覚特性を特定するためのメタデータを生成するメタデータ生成器であって、前記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられるメタデータであって、、」
と記載されている。
両者の記載を検討すると、請求項1の「ビデオコンテンツの視覚特性を特定するためのメタデータを生成するステップ」の記載が、訂正前の請求項15の「ビデオコンテンツの視覚特性を特定するためのメタデータを生成するメタデータ生成器」の記載に対応し、請求項1の「メタデータを生成するステップ」に対して、訂正前の請求項15の「メタデータを生成するメタデータ生成器」が対応するものと解される。
ところが、請求項1の「前記ビデオコンテンツをその表示前に修正するために用いられる、前記生成するステップ」の記載に対して、訂正前の請求項15の「前記ビデオコンテンツをその表示前に修正するために用いられるメタデータであって、」の記載は整合しておらず、不明瞭な記載となっている。

そして、訂正事項1は、上記訂正前の請求項15の整合していない記載部分である「前記ビデオコンテンツをその表示前に修正するために用いられるメタデータであって、」を、請求項1の「前記生成ステップ」対応した「前記メタデータ生成器」という記載を用いて、「前記ビデオコンテンツをその表示前に修正するために用いられる、前記メタデータ生成器、」と訂正して請求項1の記載と整合させるものであるから、この訂正は、請求項15の記載を明瞭にするものであるということができる。
よって、訂正事項1は、明瞭でない記載の釈明を目的とするものである。

したがって、訂正事項1は、特許法第126条第1項ただし書第3号の規定に適合する。

3.訂正の適合性
(1)訂正の範囲
訂正事項1により訂正される請求項15は、「メタデータ生成器」、及び「メタデータ伝送準備装置」を含む「システム」という発明となるが、願書に添付した明細書の段落【0007】には、
「本発明システムは、メタデータ生成器及びメタデータ伝送準備装置を含む。」
とあり、本発明の「システム」が「メタデータ生成器」、及び「メタデータ伝送準備装置」を含むことが記載されている。

また、訂正後の請求項15における
「ビデオコンテンツの視覚特性を特定するためのメタデータを生成するメタデータ生成器であって、前記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられる、前記メタデータ生成器、」
という記載に関し、
願書に添付した明細書には、
「上記メタデータ生成器はビデオコンテンツのためのメタデータを生成するための装置である。上記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターよる異なる創作意図間の多様性を説明することよって、その表示前に上記ビデオコンテンツを修正するためのデータである。」(段落【0007】)、
「語句「ルックデータ」、及び斯かるルックデータに関連する用語「メタデータ」とは、色操作、空間フィルタリング処理、モーション挙動、フィルム粒子、ノイズ、編集及びトーンマッピング等について及び/又は関連する、例えば、整数、非整数値、及び/又はブール値の如き形式のデータを意味する。斯かるルックデータ及び/又はメタデータは、斯かる機能を実現するのに関連する機構を制御、ターンオン、ターンオフするのに用いられ、そしてそれらを修正するのに用いられてもよい。」(段落【0020】)、
「例えばルックデータを含んでいるメタデータは、コンテンツ発生源装置110から表示装置130へ提供され、且つ表示装置130からコンテンツ発生源装置110へ提供され得る。」(段落【0026】)、
「1つの実施形態において、システム100のコンテンツオーサリング部210は、更に以降で説明されるように、ルックデータ206を生成するためのルックデータ発生器288、(中略)を含む。」(段落【0028】)、
「1つの実施形態において、システム300のコンテンツオーサリング部310は、以降で更に説明されるように、ルックデータ306を生成するためのルックデータ発生器388、(中略)を含む。」(段落【0029】)
との記載がある。

これらの記載によれば、メタデータ生成器はビデオコンテンツのためのメタデータを生成するものであり(段落【0007】,【0026】,【0028】,【0029】)、ルックデータを含むメタデータは、ビデオコンテンツに対して色操作等を行うものであって(段落【0020】,【0026】)、これはビデオコンテンツの視覚特性を特定することといえる。
よって、「メタデータ生成器」が「ビデオコンテンツの視覚特性を特定するためのメタデータを生成する」ことが記載されている。

また、メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を反映させるためにビデオコンテンツをその表示前に修正するためのデータである(段落【0007】)。
そして、ルックデータを含むメタデータは、ビデオコンテンツに対する色操作等を、その色操作等の機能を実現するのに関連する機構を制御するのに用いられるのであって(段落【0020】,【0026】)、色操作等の機能を実現するのに関連する機構とは表示装置の表示メカニズムといえるから、メタデータは、表示装置の表示メカニズムを制御することにより前記ビデオコンテンツを修正するものである。
よって、「メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられる」ことが記載されている。

したがって、訂正事項1により訂正された事項は、願書に添付した明細書、特許請求の範囲、又は図面に記載した事項の範囲内においてするものである。

(2)特許請求の範囲の拡張、変更
上記2.において検討したように、訂正事項1は、訂正前の請求項15の明瞭でない記載について本来の意を明らかにするものであり、訂正の前後で特許請求の範囲は変わらないものであるといえるから、実質上特許請求の範囲を拡張し、又は変更するものではない。

(3)まとめ
以上によれば、訂正事項1は、特許法第126条第5項及び第6項の規定に適合する。

第4 むすび
以上のとおり、本件訂正は、特許法第126条第1項ただし書第3号に掲げる事項を目的とするものあり、また、同条第3項、第5項及び第6項に規定する要件に適合する。
よって、結論のとおり審決する。
 
発明の名称 (54)【発明の名称】
ルックデータ定義及び高精細マルチメディアインタフェース上の伝送のための方法及びシステム
【技術分野】
【0001】
本出願は、非仮出願である「ルックデータ定義及び伝送のための方法及びシステム」と題する代理人文書番号PU070307号に関連し、該出願は共通に譲渡されその内容が引用によって本明細書に完全に組み入れられて共にここで出願される。
【0002】
本原理は概略マルチメディアインタフェースに関する。特に、本原理は、特に詳細にはルックデータ定義及び高精細マルチメディアインタフェース(HDMI)上の伝送のための方法及びシステムに関する。
【背景技術】
【0003】
現在、家庭使用又は専門家使用の何れかのためにビデオコンテンツ製品を配布する際には、そのビデオ配布製品についてなされた単一の色決定が存在し、これは通常、ビデオコンテンツクリエーターの意図の顕れである。
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかし、コンテンツの色決定が改変されなければならないような、コンテンツに異なる使用実態が発生している。斯かる異なった使用実態は、例えば、フロントプロジェクションディスプレイ、直接視ディスプレイ又は携帯ディスプレイの如き異なるディスプレイタイプで発生し、これら各々は斯かるビデオコンテンツの最適表示を提供するために色決定に対して幾らかの変更を必要としている。
【課題を解決するための手段】
【0005】
本原理の様々な実施形態に従った方法及びシステムは、ルックデータ定義及び高精細マルチメディアインタフェース(HDMI)上の伝送を提供することによって上記従来技術の欠点を解決する。
【0006】
本原理のある態様による方法が提供される。本発明方法は、ビデオコンテンツのためのメタデータを生成するステップを含む。上記メタデータは、異なる表示装置間の多様性(variations)及びコンテンツクリエーターよる異なる創作意図間の多様性を説明する(account for)ことよって、その表示前に上記ビデオコンテンツを修正(alter)するためのデータである。上記方法は、高精細マルチメディアインタフェース上の伝送のために上記ビデオコンテンツ及び上記メタデータを準備するステップを含む。
【0007】
本原理の別の態様によるシステムが提供される。本発明システムは、メタデータ生成器及びメタデータ伝送準備装置を含む。上記メタデータ生成器はビデオコンテンツのためのメタデータを生成するための装置である。上記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターよる異なる創作意図間の多様性を説明することよって、その表示前に上記ビデオコンテンツを修正するためのデータである。上記メタデータ伝送準備装置は高精細マルチメディアインタフェース上の伝送のために上記ビデオコンテンツ及び上記メタデータを準備する装置である。
【0008】
本原理の教示は添付の図面と共に以降の発明の詳細な説明を考慮することよって容易に理解され得る。
【図面の簡単な説明】
【0009】
【図1】本発明の実施形態に従って高精細マルチメディアインタフェース接続上でルックデータを送信するシステム100の上位のブロック図である。
【図2】本発明の実施形態に従って連続したルックデータ伝送を実現している図1のシステム100のより詳細な上位のブロック図である。
【図3】本発明の変形例に従って並行したルックデータ伝送を実現している図1のシステム100のより詳細な上位のブロック図である。
【図4】本発明の実施形態に従ってルックデータ定義及び伝送のための方法を示すフローチャートである。
【図5】本原理の実施形態に従ってルックデータ500の例示的な表現を示す図である。
【図6】本発明の実施形態に従ってルックデータエレメンタリメッセージにおける使用のためのメタデータ600の例示的なKLV表記を示す図である。
【図7】本発明の実施形態に従って図6のメタデータ600のKLV表記を更に詳細に示す図である。
【図8】本発明の実施形態に従って、8ビットのビット深度を有する3D-LUTとして実現される例示的なルックデータエレメンタリメッセージ800を示す図である。
【図9】本発明の実施形態に従って、10ビットのビット深度を有する3D-LUTとして実現される例示的なルックデータエレメンタリメッセージ900を示す図である。
【図10】本発明の実施形態に従って、8ビットのビット深度を有する1D-LUTとして実現される例示的なルックデータエレメンタリメッセージ1000を示す図である。
【図11】本発明の実施形態に従って、10ビットのビット深度を有する1D-LUTとして実現される例示的なルックデータエレメンタリメッセージ1100を示す図である。
【図12】本発明の実施形態に従って、8ビットのビット深度を有する3×3マトリックスとして実現される例示的なルックデータエレメンタリメッセージ1200を示す図である。
【図13】本発明の実施形態に従って、10ビットのビット深度を有する3×3マトリックスとして実現される例示的なルックデータエレメンタリメッセージ1300を示す図である。
【図14】本発明の実施形態に従って、16ビットのビット深度を有する3×3マトリックスとして実現される例示的なルックデータエレメンタリメッセージ1400を示す図である。
【図15】本発明の実施形態に従った、周波数レスポンス変更のための例示的なフィルタバンク1500を示す図である。
【図16】本発明の実施形態に従った、周波数イコライゼイションのための離散的な周波数1600を示す図である。
【図17】本発明の実施形態に従った、8ビット周波数イコライゼイションのための例示的なルックデータエレメンタリメッセージ1700を示す図である。
【図18】本発明の実施形態に従った、モーション挙動のための例示的なルックデータエレメンタリメッセージ1800を示す図である。
【図19】本発明の実施形態に従った、フィルム粒子のための例示的なルックデータエレメンタリメッセージ1900を示す図である。
【図20】本発明の実施形態に従った、ノイズのための例示的なルックデータエレメンタリメッセージ2000を示す図である。
【図21】本発明の実施形態に従った、編集上の制御に用いられ得る時間編集のための例示的なルックデータエレメンタリメッセージ2100を示す図である。
【図22】本発明の実施形態に従った、トーンマッピングのための例示的なルックデータエレメンタリメッセージ2200を示す図である。
【図23】本発明の実施形態に従った、本発明の実施形態が適用され得る例示的なHDMI色域メタデータパケット2300を示す図である。
【図24】本発明の実施形態に従った、本発明が適用され得る例示的なHDMI色域メタデータヘッダ2400を示す図である。
【図25】本発明が本発明の実施形態に従って適用され得るHDMIバージョン1.3における例示的な色域メタデータパッケージ2500を示す図である。
【図26】本発明の実施形態に従った、ベンダー指定のインフォ(info)フレームのための例示的なルックデータパケットヘッダ2600を示す図である。
【図27】本発明の実施形態に従った、本原理が適用され得るCEA861Dにおける例示的なベンダー指定のインフォフレーム2700を示す図である。
【図28】本発明の実施形態に従ってルックデータを送信するための例示的なベンダー指定のCEC命令2800を示す図である。
【図29】本発明の実施形態に従った、コンシューマーエレクトロニクスコントロールバスの用途のための例示的なネットワークレイヤモデル2900を示す図である。
【図30】本発明の実施形態に従った、CECベンダー指定コマンドによるアプリケーション通信への適用を提供する例示的なCECプロセッシング3000の上位のブロック図である。
【図31】本発明の実施形態に従った、HDMIを用いた伝送のためのフレームへのルックデータパケットの例示的な変換3100を例示している上位のブロック図である。
【図32】本発明の実施形態に従った、ルックデータ検証のための例示的なルックデータエレメンタリメッセージ3200を示す図である。
【図33】本発明の実施形態に従った、CEC検証信号を生成する例示的な装置3300を示す図である。
【図34】本発明の実施形態に従った、CECにおける検証信号伝送のための方法を示すフローチャートである。
【発明を実施するための形態】
【0010】
図面は、本発明の概念を例示する目的のためにあり、本発明を例示する必ずしも唯一の可能な構成ではないことが理解されるべきである。理解を容易にするために、図面に共通である同一の要素には可能な場合同一の参照番号が付されている。
【0011】
本原理は、ルックデータ定義及び高精細マルチメディアインタフェース(HDMI)上の伝送のための方法及びシステムを有利に提供する。本原理が発生源装置及び表示装置に関係する伝送システムの文脈内で主に説明されるにも関わらず、本発明の特定の実施形態は本発明の範囲を制限するものとして扱われるべきではない。
【0012】
図に示される様々な要素の機能は、適切なソフトウェアと協働するソフトウェアを実行し得るハードウェアのみならず、専用ハードウェアの使用を介して提供され得る。プロセッサによって提供される場合、単一の専用プロセッサによって、単一の共有プロセッサよって、又は幾つかが共有され得る複数の個々のプロセッサによって、上記機能が提供され得る。更に、用語「プロセッサ」又は「コントローラ」の明示的な使用は、ソフトウェアを実行し得るハードウェアを排他的に意味するものとして解釈されるべきでなく、制限するものではないが、デジタル信号プロセッサ(「DSP」)ハードウェア、ソフトウェア記憶のためのリードオンリーメモリ(「ROM」)、ランダムアクセスメモリ(「RAM」)、及び不揮発性記憶装置の使用を黙示的に含み得る。更に、本明細書において本発明の原理、態様及び実施形態、同様にそれらの特定の例を詳述している全ての文言は、それらの構造上及び機能上の均等物を含むことが意図されている。その上、斯かる均等物とは、将来開発される均等物(すなわち、構造に関わりなく同一の機能を実施するように開発された何らかの要素)と同様に現在周知の均等物の双方を含むことが意図される。
【0013】
このように、例えば、本明細書で提示されているブロック図は、例示のシステムコンポーネントの概念及び/又は本発明の原理を実現している回路を表すことが当業者によって認識されるであろう。同様に、何らかのフローチャート、フローダイヤグラム、状態遷移図、疑似コード、及び同様物は様々なプロセスを表し、斯かるプロセスがコンピュータ読取可能媒体で実質的に表現され、コンピュータ若しくはプロセッサが明示的に示されているか否かに関わらず、斯かるコンピュータ若しくはプロセッサよって実行されてもよいことが認識されるであろう。
【0014】
本原理の「1つの実施形態」及び「ある実施形態」に対する本明細書における参照は、特定の特徴、構造、特性、並びに、実施形態に関連して説明されたものが本原理の少なくとも1つの実施形態に含まれることを意味する。このように、本明細書の全体にわたって様々な所で現れる語句「1つの実施形態において」又は「ある実施形態において」とは必ずしも同一の実施形態全てを意味しない。
【0015】
更に、本明細書で用いられるように、メタデータの伝送及び受信に関して、語句「帯域内(in-band)」とは、斯かるメタデータと共に、消費者装置よって表示されるべき色修正された画像コンテンツを送信すること及び/又は受信することを意味する。対照的に、語句「帯域外(out-of-band)」とは、消費者装置よって表示されるべき色修正された画像コンテンツとは別に、斯かるメタデータを送信すること及び/又は受信することを意味する。
【0016】
更に、本明細書で用いられるように、用語「シーン」とは、単一の「ショット」を元にして通常発生する動画像におけるある範囲の画像フレームを意味し、シーン変化間の一連の連続撮影を意味する。
【0017】
また、本明細書で用いられるように、語句「ルックデータ管理」とはルックデータの編集、伝送及び適用を意味する。
【0018】
その上、本明細書で用いられるように、語句「コンパクトディスクプレーヤ」とは、標準規格のコンパクトディスクプレーヤ、ブルーレイデジタルビデオディスクプレーヤ、高精細デジタルビデオディスクプレーヤ、その他を意味する。
【0019】
更に、本明細書で用いられるように、「未使用色域プロファイル(unused gamut profile)」とは、HDMI標準のバージョン1.3(又は何らかの先行バージョン)において現在使われない色域プロファイルを意味する。
【0020】
更に、本明細書で用いられるように、語句「ルックデータ」、及び斯かるルックデータに関連する用語「メタデータ」とは、色操作、空間フィルタリング処理、モーション挙動、フィルム粒子、ノイズ、編集及びトーンマッピング等について及び/又は関連する、例えば、整数、非整数値、及び/又はブール値の如き形式のデータを意味する。斯かるルックデータ及び/又はメタデータは、斯かる機能を実現するのに関連する機構を制御、ターンオン、ターンオフするのに用いられ、そしてそれらを修正するのに用いられてもよい。更に、ルックデータ及び/又はメタデータは、マッピングテーブルの仕様を含む。
【0021】
例えば、色操作を志向する実施形態において、色マッピングテーブルは、1DLUT(1次元のルックアップテーブル)、3次元LUT(3次元ルックアップテーブル)及び/又は3×3LUTによって実現されてもよい。例えば、3次元LUTの場合、斯かるLUTは3つ入力値を受信するのに用いられ、各値が1つの色成分、例えば赤色、緑色若しくは青色を表し、個々の赤色、緑色及び青色の入力3連値毎に、例えば赤色、緑色及び青色である所定の出力3連値を生成する。この場合、コンテンツ発生源からコンテンツ消費装置(例えば表示装置)へのメタデータはLUT仕様を含む。
【0022】
他の実施形態は、マッピング機能の仕様を含んでもよく、例えば、以下の式で定義される「GOG」(利得、オフセット、ガンマ)を実行する回路及び/又は機能を含んでもよい。
【0023】
カラー成分毎に、Vout=Gain*(Offset+Vin)∧ガンマ
斯かる場合、ルックデータ及び/又はメタデータは、9つの値、すなわち3つのカラー成分の各成分毎に利得、オフセット及びガンマからなる1組を含むことになる。
【0024】
本明細書で用いられるように、ルックデータはこれらメカニズムに作用を与えるように用いられ、1つのだけでなく幾つかのルックデータの伝送/記憶を実現するために、幾つかの組のルックデータがあり得る。
【0025】
もちろん、本原理は前述の実施形態に限られず、本明細書で提供される本原理の教示が与えられることで、ルックデータ及び/又はメタデータの他の実現を含む他の実施形態が、本原理の趣旨を維持しつつ、当業者によって容易に企図され得る。ルックデータは、本明細書において少なくとも図5に関して更に説明される。
【0026】
例えば、図1は、本発明の実施形態に従った、ルックデータを高精細マルチメディアインタフェース接続上で送信するためのシステム100の上位のブロック図を示す。図1のシステム100は、例示として、コンテンツ発生源装置110、高精細マルチメディアインタフェース(HDMI)接続装置120、及び、表示装置130を含む、及び/又は、伴う。コンテンツ発生源装置110は、限定されないが、高精細デジタルビデオディスクプレーヤ、ブルーレイプレーヤ、及びネットワークアクセスユニット(例えば、セットトップボックス(STB))であって良いことが認識されるべきである。コンテンツ発生源装置110は、高精細マルチメディアインタフェース接続装置120を介してその表示のために表示装置130に向けて送信されるべきコンテンツを提供する。例えばルックデータを含んでいるメタデータは、コンテンツ発生源装置110から表示装置130へ提供され、且つ表示装置130からコンテンツ発生源装置110へ提供され得る。高精細マルチメディアインタフェース(HDMI)接続装置120が、限定するものではないが、高精細マルチメディアインタフェース(HDMI)ケーブルを含むことが認識されるべきである。
【0027】
表示装置130(及び/又は伝送媒体120と表示装置130との間に配置され且つこれら装置に接続されている装置)は、受信器161、記憶装置162、及び/又は、メタデータをそれぞれ受信、記憶及び適用するためのメタデータ適用器162を含む。
【0028】
例えば、図2は、本発明の実施形態に従った、連続したルックデータ伝送を用いている図1のシステム100のより詳細な上位のブロック図を示す。図2の実施形態において、コンテンツ202及びルックデータデータベース204は、システム100のコンテンツオーサリング部210に配置される。図2の実施形態において、ルックデータベース204はルックデータを記憶する。1つの実施形態において、システム100のコンテンツオーサリング部210は、更に以降で説明されるように、ルックデータ206を生成するためのルックデータ発生器288、及び、HDMI上の伝送のためのルックデータを準備するためのルックデータ伝送準備装置299を含む。コンテンツ202及びルックデータ206は、コンテンツオーサリング部210で結合される(207)。1つ又はそれよりも多い伝送及び/又は記憶媒体220を用いることよって、コンテンツ202及びこれに対応するルックデータ206は、システム100のコンテンツ表示部230に順番に送られ、ここでコンテンツ202及びルックデータ206は切り離されて処理される。システム100のコンテンツ表示部230は、例えば図1に示される表示装置130を含むことができる。ルックデータ206は、システム100のコンテンツ表示部230に配置されるルックデータデータベース232に次いで記憶される。図2に示されて伝送及び/又は記憶媒体220は、コンテンツ202及び/又はルックデータ206の連続した伝送及び/又は記憶をまとめていることが認識されるべきである。
【0029】
図3は、本発明の変形例に従って並行ルックデータ伝送を実現している図1のシステム100のより詳細な上位のブロック図を示す。図3の実施形態において、コンテンツ302及びルックデータデータベース304は、システム300のコンテンツオーサリング部310に配置される。図3の実施形態において、ルックデータベース304はルックデータ306を記憶する。1つの実施形態において、システム300のコンテンツオーサリング部310は、以降で更に説明されるように、ルックデータ306を生成するためのルックデータ発生器388、及び、HDMI上で伝送するためにルックデータ306を準備するルックデータ伝送準備装置399を含む。コンテンツ302及びルックデータ306はコンテンツオーサリング部310で結合される(307)。1つ又はそれよりも多い伝送及び/又は記憶媒体320を用いることよって、コンテンツ302及びこれに対応するルックデータ306はシステム300のコンテンツ表示部330に並行して送信され、ここでコンテンツ302及びルックデータ306は切り離されて処理される。システム300のコンテンツ表示部330は、例えば図1に示された表示装置130を含むことができる。ルックデータ306は、システム300のコンテンツ表示部330に配置されるルックデータデータベース332で次いで記憶される。図3に示された伝送及び/又は記憶媒体320は、コンテンツ302及び/又はルックデータ306の並列伝送及び/又は記憶をまとめていることが認識されるべきである。
【0030】
図4は、本発明の実施形態に従ったルックデータ定義及び伝送のための方法のフローチャートを示す。方法400はステップ402で始まり、ここでルックデータがビデオコンテンツのために生成される。斯かるルックデータは、制限されないが、操作、空間フィルタリング処理、モーション挙動、フィルム粒子、ノイズ、編集、トーンマッピング、その他に関連し得る。斯かるルックデータは、前述の斯かる機能を実現し且つ修正する機構に関連するターンオン及びターンオフを制御するのに用いることができる。本方法は次いでステップ404に進む。
【0031】
ステップ404において、ルックデータが伝送のために準備され、限定されないが、ルックデータ(ステップ402で以前に生成された)のための1つ又はそれよりも多いルックデータエレメンタリメッセージを生成すること、1つ又はそれよりも多いルックデータエレメンタリメッセージを含む1つ又はそれよりも多いルックデータパケットを生成すること、ルックデータをディスク等に記憶すること、及びその他を含む。本方法は次いでステップ406に進む。
【0032】
ステップ406において、ルックデータ及びビデオコンテンツはHDMIを用いて表示装置に伝送される。斯かる伝送は、限定されないが例として、HDMI色メタデータ、CEA/HDMIベンダー指定インフォフレーム、HDMI/CEC(コンシューマーエレクトロニクスコントロール)プロトコルを用いてなされ得る。上記伝送へのHDMI色メタデータの使用に関しては、色域境界記述(GBD)メタデータコンテナ(container)を用いることができる。上記伝送へのCEA/HDMIベンダー指定インフォフレームの使用に関して、GBDフロー制御をベンダー指定インフォフレームに適用することができる。上記伝送へのHDMI CECプロトコルの使用に関して、CECの上にネットワーク抽象レイヤを加えてサービス品質(QoS)の使用を可能とし、ビデオに対してCECの時間合わせをすることができる。本方法は次いでステップ408に進む。
【0033】
ステップ408において、ビデオコンテンツが受信され、記憶され、ルックデータに従って修正され、該修正されたビデオコンテンツが表示装置において表示される。方法400は次いで出口処理され得る。
【0034】
受信、記憶及び修正の前述の順序は実際の実現形態に依存して変更され得ることが認識されるべきである。例えば、記憶とはメタデータが記憶媒体上で提供されていることに相当し得る、及び/又は、次処理のためのコンテンツ解釈側上での同一物の一時的な記憶に相当し得る。
【0035】
本発明の1つの実施形態において、高精細デジタルビデオディスク(HD DVD)及び/又はブルーレイディスクのためのコンテンツを作成するのに本発明の原理が用いられ、斯かる作成は、国際標準化機構/国際電気標準会議(ISO/I EC)動画専門家グループ4(MPEG?4)パート10先端ビデオ符号化(AVC)標準/国際電気通信連合、テレコミニケーション部門(ITU-T)H.264勧告(以下、「MPEG?4AVC標準」と称する)に従ってコンテンツをコード化すること、コンテンツをディスクに記憶すること、次いで、表示装置における信号処理装置を制御して表示用のビデオデータを修正すること、によってなされる。斯かる適用において、ルックデータがディスクに記憶される。ルックデータは、次いで高精細マルチメディアインタフェース(HDMI)を用いて表示装置に伝送される。ルックデータを送信するのにHDMIを用いるための様々な例示的な方法が本明細書において説明される。もちろん、本原理が記載された実施形態にだけに限られず、本明細書において提供される本原理の教示が与えられて、本技術及び関連技術における当業者は、本原理の趣旨を維持しつつ、これら及び他の様々な実施形態及びそれらの変形形態を企図するであろうことが認識されるべきである。
【0036】
様々な実施形態において、本原理が、限定するものではないが動画製造における「デジタル・デイリーズ(digital dailies)」処理を含む専門的及び準専門的環境で用いることができることが認識されるべきである。
【0037】
シーン結合データ
図5は、本原理の実施形態に従った、ルックデータ500の例示的な表現を示す。図5のルックデータ500は、各シーン毎又はシーケンス、すなわちシーン515に1つのルックデータパケット510を含む。尚、シーン境界の画定は通常、コンテンツ制作者次第である点に留意する必要がある。図5に図示されるように、各ルックデータパケット(LDP)510は、1つ又はそれよりも多いルックデータエレメンタリメッセージ520を含むことができる。各ルックデータエレメンタリメッセージ(LDEM)は、コンテンツ描画及び/又は表示のために、1つの信号処理装置を制御するパラメータ525を含むことができる。より具体的には、本発明の実施形態に従って、ルックデータエレメンタリメッセージ520及びパラメータ525の如きルックデータパケット510は、コンテンツ描画装置を含む表示装置に向けてそれぞれのビデオコンテンツと共に配布されるか又は伝達されるべきことが意図されている。表示システムにおいて、コンテンツ描画装置(例えば、ディスプレイ又はセットトップボックスのデコータ)は、ルックデータパケット510をそれぞれのビデオコンテンツに適用し、ルックデータが作成されたシーン又はシーケンス状のシーンの表示属性を、ルックデータエレメンタリメッセージ520におけるパラメータに従って作用するか又はこれを変更する。
【0038】
1つの実施形態において、もしシーン515間でルックデータ500が同一であると判定される場合、シーン変更においてルックデータを更新することによらずして、ルックデータ500がシーン515中で共有され得る。このように、ルックデータ500は、ルックデータ500が無効にされるか又は更新される迄、有効なままである。斯かる無効は、「ルックデータエレメンタリメッセージ」における「データ有効」タグを「無効」に設定することよってLDEMメタデータの適用を停止することを伴う。その変形例は、同一のタグIDを備える新たなLDEMを送信することである。
【0039】
ルックデータパケット
本発明の1つの実施形態において、ルックデータパケット伝送のために、「KLV」(鍵、長さ、値)メタデータ概念が実装されるが、他の周知のルックデータパケット伝送概念が実装され得る。すなわち、本明細書において1つ又はそれよりも多い実施形態がKLVメタデータ概念に関して説明される一方で、本原理がKLVメタデータ概念を単に実現するだけであるとは限定されず、ルックデータパケットを実現する他の方法も本原理の趣旨を維持しつつ本発明の様々な実施形態に従って実現され得ることが認識されるべきである。
【0040】
KLV概念は、コンテンツを解釈せずともパケット通信が完結される場合を認識する伝送装置に対して有用である。これは、図6及び図7で例示される。例えば、図6は、本発明の実施形態に従った、ルックデータエレメンタリメッセージの使用のためのメタデータ600の例示的なKLV表記を示している。図7は、本発明の実施形態に従った、図6のメタデータ600のKLV表記を更に詳細に示す。
【0041】
図6及び図7を参照してより具体的には、各パケットは、例えばメッセージが「ルックデータ」に関係している旨の如きメッセージの性質を指示する「鍵」フィールド610を含む。この鍵は、時間スタンプ617、又は変形例として「シーンID」を含むことによって、受信装置はそのデータがどのシーンに適用されるべきかを直ちに知ることができる。時間スタンプ617及び/又はシーンIDの使用はオプションであり、例えば、時間コード追跡が生じるシステムに対して用いられ得ることが認識されるべきである。更に、各パケットは、そのパケットのペイロード部分におけるワード数を示す長さフィールド620を含むことができる。長さフィールド620もオプションであり、その使用は例えばメタデータタグに依存することが認識されるべきである。
【0042】
更に、各パケットは、そのパケットのペイロード部分を担う値フィールド630を含むことができる。1つの実施形態において、ペイロードコンテンツのワードサイズはメタデータタグによって決定することができる。本発明の1つの実施形態において、ペイロードは例えば個々の「ルックデータエレメンタリメッセージ」を含むことができ、KLVの他のレイヤが用いられるか、又は変形例としてKV(鍵及び値)だけが用いられ得る。
【0043】
ルックデータエレメンタリメッセージ
1.色操作
本発明の1つの実施形態において、色操作はルックデータエレメンタリメッセージで定義することができる。すなわち、色操作は、例えば1つ又はそれよりも多い3D-LUT、1つ又はそれよりも多い1D-LUT、及び/又は1つ又はそれよりも多い3×3LUTによって実現することができる。例えば、斯かるルックデータエレメンタリメッセージの例示的な定義が図8?図14で提供される。
【0044】
より具体的には、図8は、本発明の実施形態に従って8ビットのビット深度を有する3D-LUTとして実現される例示的なルックデータエレメンタリメッセージ800を示す。図8に図示されるように、ルックデータエレメンタリメッセージ800は、タグID部810、及び、値部820を含む。値部820は、例示として、有効性部、カラー空間定義部、長さ定義部、及び、値部を含む。図8のルックデータエレメンタリメッセージ800の各部はそれぞれの記述部及び名称部を含む。図8のタグID部810は、3D-LUTの8ビットIDを定義し、これは例示として0×11である。値部820において、有効性部はデータが有効であるか否かを定義し、図8では例示としてブール代数で定義されている。値部820において、カラー空間部はカラー空間を定義し、図8では例示として[00]=RGB、[01]=XYZ、[10]=YCrCb、及び[11]予備と定義されている。
【0045】
図8の値部820における長さ定義部は、ペイロードの長さをバイトで定義し、これは例示として8ビットノードデータであると仮定されている。加えて、値部は様々な値を定義し、例えば、LUTノードデータ、例示的には規則的と仮定される入力データの間隔、ワード(word)定義及び順番を定義し、例示的には、「第1ワードRED、CIE_X、又はY」、「第2ワードGREEN、CIE_Y、又はCr」及び「第3ワードBLUE、CIE_Z、又はCb」と定義する。図8のルックデータエレメンタリメッセージ800において、値部は、また、例示的には「BLUEが最初に変化し、次いで緑色、次いでRED」とする格子走査を定義する。
【0046】
図9は、本発明の実施形態に従って10ビットのビット深度を有する3D-LUTとして実現される例示的なルックデータエレメンタリメッセージ900を示す。図9のルックデータエレメンタリメッセージ900は、図9の3D-LUTのIDが10ビットのビット深度を有し且つ0×12の値を有すること以外、図8のルックデータエレメンタリメッセージ800と実質的に同様である。加えて、図9のルックデータエレメンタリメッセージ900において、長さ定義部は、1つの32ビットワードにパケット化される10ビットのノードデータであると例示的に仮定されるペイロードの長さを定義する。更に、図9の実施形態において、値部は更にワード「RED」、「GREEN」及び「BLUE」を以下のように定義する。
Word=RED<<20+GREEN<<10+BLUE
【0047】
図10は、本発明の実施形態に従って8ビットのビット深度を有する1D-LUTとして実現される例示的なルックデータエレメンタリメッセージ1000を示す。図10のルックデータエレメンタリメッセージ1000において、1D-LUTのIDは8ビットのビット深度を有し且つ0×13の値を有する。図8及び図9の上記のルックデータエレメンタリメッセージとは異なり、図10のルックデータエレメンタリメッセージ1000において、カラー定義部は、LUTがREDチャネル、GREENチャネル若しくはBLUEチャネルのためのLUTであるか否か、又はLUTが全てのチャネルに適用されるかについて定義する。図10において、カラー値が例示的には、[00]=RED又はCIE_X又はY1、[01]=GREEN又はCIE_Y又はCr、[10]=BLUE又はCIE_Z又はCb、及び[H]=全チャネルと定義される。加えて、ルックデータエレメンタリメッセージ1000において、値部は、LUTの出力データが最小入力値に対して出力値256で始める8ビットの値であると想定されることを定義する。
【0048】
図11は、本発明の実施形態に従って10ビットのビット深度を有する1D-LUTとして実現される例示的なルックデータエレメンタリメッセージ1100を示す。図11のルックデータエレメンタリメッセージ1100は、図11の実施形態において、ルックデータエレメンタリメッセージ1100が10ビットのビット深度を有し且つ0×14の値を有するIDを含むこと以外、図10のルックデータエレメンタリメッセージ1000と実質的に同様である。加えて、ルックデータエレメンタリメッセージ1100において、値部は、LUT出力データが最小入力値に対して出力値1024で始まる10ビットの値であること、3つの10ビットの値が1つの32ビットワードに以下のようにパケット化されることを定義する。
Word=LUT[0]<<20+LUT[1]<<10+LUT[2]
【0049】
図12は、本発明の実施形態に従って10ビットのビット深度を有する3×3マトリックスとして実現された例示的なルックデータエレメンタリメッセージ1200を示す。ルックデータエレメンタリメッセージ1200において、カラー定義部は、[00]=RGBからRGB(γ)、[01]=RGBからRGB(線形)、及び[H]=XYZからXYZ、とするマトリックス適用を定義する。加えて、図12のルックデータエレメンタリメッセージ1200において、値部は、以下のような形の9つの10ビットとして想定される係数を定義する。
【0050】
[B1[C1 C2 C3[A1
B2=C4 C5 C6×A2
B3]C7 C8 C9]A3]
ここにおいて、A1及びB1はRED又はCIE_Xであり、A2及びB2はGREEN又はCIE_Yであり、並びに、A3及びB3はBLUE又はCIE_Zであり、そしてシーケンスの順序はC1-C2-C3である。図12のルックデータエレメンタリメッセージ1200において、値部は、3つの係数が1つの32ビットワードにパケット化されることによって、総ペイロードが3×32ビット=96であり、以下のような値を有することを定義する。
Word=C1<<20+C2<<10+C3
【0051】
図13は、本発明の実施形態に従って8ビットのビット深度を有する3×3マトリックスとして実現される例示的なルックデータエレメンタリメッセージ1300を示す。図13のルックデータエレメンタリメッセージ1300は、図13の実施形態においてルックデータエレメンタリメッセージ1300が8ビットのビット深度を有し且つ0×16の値であるIDを含むこと以外、図12のルックデータエレメンタリメッセージ1200と実質的に同様である。加えて、図13のルックデータエレメンタリメッセージ1300において、総ペイロードは9×8ビット=72ビットである。
【0052】
図14は、本原理の実施形態に従って16ビットのビット深度を有する3×3マトリックスとして実現される例示的なルックデータエレメンタリメッセージ1400を示す。図14のルックデータエレメンタリメッセージ1400は、図14の実施形態においてルックデータエレメンタリメッセージ1400が16ビットのビット深度を有し且つ0×17の値を有するIDを含むこと以外、図12のルックデータエレメンタリメッセージ1200及び図13のルックデータエレメンタリメッセージ1300と実質的に同様である。加えて、図14のルックデータエレメンタリメッセージ1400において、総ペイロードは9×16ビット=144ビットである。
【0053】
2.空間フィルタ
本発明の実施形態において、空間フィルタ制御はルックデータエレメンタリメッセージで指定することができる。例えば、空間応答又は周波数応答は空間領域フィルタリング処理を用いて修正することができる。空間周波数応答を修正する1つの例示的な方法は、複数の有限応答(FIR)フィルタからなり各々のフィルタが特定の中心周波数に合わせられるパンクを用いることである。図15は、本発明の実施形態に従った、周波数応答修正のため例示的なフィルタバンク1500を示す。図15のフィルタバンク1500は、例示的には、複数のフィルタ1510、少なくとも1つの乗算器1520、及び、少なくとも1つの合成器1530を含む。
【0054】
1つの実施形態において、画像の周波数応答はフィルタ係数(CO..CN)を変えることよって操作されて、周波数のディテールを増強又は減衰させる。例えば、図16は、本発明の実施形態に従った、周波数イコライゼイションのための例示的な離散的周波数1600を示す。図16に図示されるように、フィルタ係数(C0..CN)は周波数応答についてルックデータエレメンタリメッセージで指定することができる。
【0055】
例えば、図17は、本発明の実施形態に従った、8ビット周波数イコライゼイションのための例示的なルックデータエレメンタリメッセージ1700を示す。図17の実施形態に図示されるように、ルックデータエレメンタリメッセージ1700は、周波数イコライザのために、例えば最高16個且つ4ビットの幾つかの係数を定義し、各係数が1つの周波数帯域乗数器を制御することを定義する。
【0056】
3.モーション挙動
1つの実施形態において、モーション挙動制御は、表示がモーション挙動を所望モーション挙動に整合させることを可能とする情報を含むメッセージを利用して、ルックデータエレメンタリメッセージで指定することができる。この情報は所望のモーション挙動の仕様を担い、加えて表示における処理を単純化するコンテンツ前処理装置からのヘルパーデータを担うことができる。例えば、本発明の実施形態に従った、図18はモーション挙動のための例示的なルックデータエレメンタリメッセージ1800を示す。図18の実施形態のルックデータエレメンタリメッセージ1800は、例示的には、H_(Z)での入力フレームレート(U8)、フィールド繰り返し度(U8)、所望ディスプレイ挙動(U16)、及び、x/yでのアイモーション挙動(2×U32)を定義する。加えて、図18の実施形態のルックデータエレメンタリメッセージ1800において、前処理又はモーション推定があるか否かが定義される。
【0057】
4.フィルム粒子
1つの実施形態において、フィルム粒子制御がルックデータエレメンタリメッセージで指定され得る。本発明の1つの実施形態において、フィルム粒子メッセージは、MPEG-4AVC標準のペイロードタイプ=19から採用することができる。図19は、本発明の実施形態に従った、フィルム粒子のための例示的なルックデータエレメンタリメッセージ1900を示す。
【0058】
5.ノイズ
1つの実施形態において、ノイズ制御は、ルックデータエレメンタリメッセージで指定することができる。すなわち、白色ノイズの決定されたレベルを全ての色チャネルに対して同一に印加することが可能であり、又はノイズについてのルックデータエレメンタリメッセージ内でチャネル当たりに1つの特定レベル/挙動を印加することが可能である。更に、ある実施形態においてノイズが1つ又はそれよりも多い色チャネルから除去され得る。1つの実施形態において、ノイズ特性は、上記に説明されたように、空間応答と同様に周波数応答を修正することよって変更され得る。図20は、本発明の実施形態に従った、ノイズのための例示的なルックデータエレメンタリメッセージ2000を示す。
【0059】
6.編集
ある実施形態において、1つ又はそれよりも多いシーンの編集がルックデータエレメンタリメッセージで指定され得る。例えば、本発明のルックデータエレメンタリメッセージに従って、シーン又は一群のシーンから1つ又はそれよりも多いセグメントを切り出すことが可能である。このように、その切り出されたシーンは編集データの更新による後の時刻で表示することができる。このように実施形態において、特定のシーン内の入り及び出の時刻コードの「カットリスト」が伝送され得る。1つの実施形態において、あるシーンの最初のフレームは時刻符号00:00:00:00(HH:MM:SS:FF)を有することになる。図21は、本発明の実施形態に従った、編集制御のために用いられ得る時間編集のための例示的なルックデータエレメンタリメッセージ2100を示す。
【0060】
7.トーンマッピング
1つの実施形態において、トーンマッピングは、ルックデータエレメンタリメッセージで指定される。例えば高ダイナミックレンジ画像を低ダイナミックレンジ画像に変換する場合に、トーンマッピングが用いられ得る。例えば、典型的適用は、10ビットコード化された画像から8ビット又は7ビット画像への転換があり得るであろう。本原理は何らかの特定のトーンマッピングアルゴリズムに限定されないことが認識されるべきであり、従って、何らかのトーンマッピングへのアプローチも本原理の趣旨を維持しつつ本発明に従って用いられ得る。1つの実施形態として、トーンマッピングがMPEG-4のAVC標準における補足的強化情報(SEI)メッセージにて指定され得る。例えば、図22は、本発明の実施形態に従った、トーンマッピングのための例示的なルックデータエレメンタリメッセージ2200を示す。図22のルックデータエレメンタリメッセージ2200はまたSEIメッセージで指定され得るパラメータを指定し得る。
【0061】
ルックデータ伝送
HDMIにおいて、ルックデータを送信することのための異なる方法がある。ルックデータを送信することのための例示的な幾つかの方法は、色域メタデータ以外のデータ、「ベンダー仕様インフォフレーム」の使用及び具体的にベンダーが命令するコンシューマーエレクトロニクスコントロール(CEC)の使用のための「色域メタデータパッケージ(Gamut Metadata Package)」の使用を含むが、これに限定されない。
【0062】
1.HDMI色メタデータ
HDMI仕様の現在バージョンが1.3Aバージョンである点に留意すると、HDMI仕様のバージョン1.3以降、HDMIを介して比色メタデータを転送する新たな方法があった。本発明の1つの実施形態において、その伝送可能性が、比色メタデータのみの伝送に代えて「ルックデータパケット」を送信するのに用いられる。従って、現在のHDMI仕様のバージョン1.3Aで例えばGBD_profile=7とすることによって用いられる色域プロファイルの使用が提案される。HDMI仕様バージョン1.3は、最高800個のHDMIパケットの単一伝送を可能とするが、その仕様の将来バージョンでは異なるパケット総数が提供され得る。しかし、このための時間は10ビデオフィールドにまで続くはずであるが、これはインタフェース仕様の将来バージョンによって変わり得る。HDMIパケット当たり28バイトとすると、これは合計で最高21.8Kバイトになるであろう。
【0063】
従って、斯かるルックデータ伝送に関する本発明の実施形態において、ルックデータパケットがHDMI色域メタデータパケットの最大サイズよりも大きくないことが保証されるべきである。加えて、ルックデータパケットがシーンからシーンに適応されなければならない場合があり、その場合、シーンはルックデータパケットデータを共有するビデオフィールドの範囲になければならないように定義され、更新の斯かる瞬間に先行するシーンは、現在シーンの「ルックデータパケット」(LDP)伝送に要する時間よりも短くてはならない。
【0064】
仕様バージョン1.3に従ったHDMI比色メタデータを用いる場合、パケットの長さが算出されるべきであり、図23に示されるように、GBD_Length_H(高バイト)及びGBD_Length_L(低バイト)が色域メタデータパケットの最初の2バイト中に充填される。つまり、図23は、本発明の実施形態に従った本発明の実施形態が適用され得る例示的なHDMI色域メタデータパケット2300を示す。
【0065】
1つの実施形態において、オプションのチェックサムは、GBDヘッダ及びルックデータパケット、並びに、もし適用可能なら何らかの充填データを含むパケット全体について実行することができる。図24は、本発明の実施形態に従った、本発明が適用され得る例示的なHDMI色域メタデータヘッダ2400を示す。表1は、本発明の実施形態に従った、図24に示された構文要素の意味を説明している。図24及び表1の複数部分は、「HDMI規格バージョン1.3a」における表5-30「色域メタデータパケットヘッダ」と称される部分から抽出されている。
【0066】
【表1】

【0067】
示されように、データは伝送のために、最初のGBDパケットについて22バイト、残りの全てのパケットについて28バイトである個々のHDMIインタフェースパケットに分割され得る。もし最後のパケットが「ルックデータパケット」データで完全に充填されない場合、パケットは前述の「フィルデータ」で充填され、これは本発明の1つの実施形態において1つ又はそれよりも多い「0」を含むことができる。データフローについては、HDMI GBDデータフロー機構が、「Next_Field」、「Affected_Gamut_Seq_Num」、「Current_Garnut_Seq_Num」及び「Packet_Seq」によって用いられる(図24参照)。適用されるべきルックデータがない場合に、「GBD_Profile」=7(図24参照)に従った「No_Current_GBD」の1つの伝送がこの要求の信号化にとって十分である。そして、全てのルックデータ映像信号修正は、新たなルックデータパケットが送信されるまでディスエーブル状態にある。
【0068】
変形例として、「HDMI CECプロトコル」に関して以降で説明されるような通信方法が用いられ得るが、GBD通信方法は組込みのフレーム同期化方式を特徴とすることから好ましい。
【0069】
図25は、本発明の実施形態に従って、本発明が適用され得るHDMIバージョン1.3における例示的な色域メタデータパッケージ2500を示す。色域メタデータパッケージ2500は、実際のビデオ部分2510、発生源におけるGBDインフォ部分2520、VSYNC部分2530、色域メタデータパケット部分2540、及び、シンク(sink)装置の会話テーブル部分2550を含む。図25の部分は、「HDMIバージョン1.3a」から抽出され、図5?図6における「PO伝送シーケンス例」が参照される。
【0070】
2.CEA/HDMIベンダー指定インフォフレーム
上記のようなHDMI GBDメタデータを実現する代わりに、本発明の変形例において、「ベンダー指定インフォフレーム」が本発明に従って用いられ得る。ベンダー指定のインフォフレームは、例えば、CEA-861-D仕様6.1章に記載されている。HDMI仕様は、その5.3.5章に記載されるように、CEA-861-Dインフォフレームの使用を可能とする。実際、インフォフレームパケットは長さ28バイトである。色域メタデータパケットと比した唯一の差異は、パケットサイズが1つのインフォフレームだけに制限されていることである。本発明の1つの実施形態において、ベンダー指定インフォフレームについてGBDメタデータフロー制御を用いることが提案される。すなわち、1つの実施形態において、1つのパケットだけとするベンダー指定インフォフレームの上述した制限に依存して、長さフィールドがサイズについてだけ5ビットであるとする修正が用いられ得る。これは、長さ情報及び巡回冗長符号(CRC)情報が、「GBD様式」ヘッダ、ルックデータパケットヘッダ(図26参照)に置かれるべきであることを意味し、これは従って3バイトから6バイトに増大する。つまり、図26は、本発明の実施形態に従った、HDMIバージョン1.3と共に用いられるベンダー指定インフォフレームのための例示的なルックデータパケットヘッダ2600を示す。
【0071】
表2は、以下のように、本発明の実施形態に従った図26で示された構文要素の意味を説明している。
【0072】
【表2】

【0073】
図27は、本発明の実施形態に従った、例えば、本発明が適用され得るCEA861Dにおける例示的なベンダー指定インフォフレーム2700を示す。図27のベンダー指定インフォフレーム2700は、例示的には、バイト番号、フィールド名、及び、コンテンツを定義する。図27に図示されるように、ベンダー指定インフォフレーム2700は、例示的には、01_(16)の値を有するベンダー指定インフォフレームタイプコードとして「n」バイトを定義する。ベンダー指定インフォフレーム2700は、01_(16)の値を有するベンダー指定インフォフレームバージョンとしてのn+1フレーム、IEEE登録IDを含むインフォフレームペイロードにおける総バイトに等しい値を有するLvインフォフレームとしてのn+2フレーム、24ビットのIEEE登録識別子(LSBが先)としてのn+3,4,5番のフレーム、及び、ベンダー仕様ペイロードとしてのn+Lv-1^(1)フレームを更に定義する。
【0074】
したがって、図28は本発明の実施形態に従った、ルックデータを伝送するための例示的なベンダー指定CEC命令2800を示す。図28のベンダー指定CEC命令2800は、例示的には、名称、記述及び様々なCEC命令のための値を定義する。より具体的には、図28の実施形態において、特別なスタートビットが定義される。更に、ベンダーID、すなわち例示的にはIEEEベンダーアドレスがIEEE OUI割り当てに等しい3バイトとして定義される。図28のベンダー指定CEC命令2800は、また、タグ番号の1バイト値を有するオプトコード(optcode)として第1のデータブロックを定義する。第2のデータブロックで始めるベンダー指定CEC命令2800において、長さ、パケットシーケンス及びオペランドを定義しているオペランドブロックが定義される。より具体的には、引き続くデータの長さがバイトで定義される。パケットシーケンスは、図28の実施形態において例示的には、色域メタデータパケットシーケンスにおいて、あるパケットが唯一であるか、最初又は最後のパケットであるかを指示する2ビットを用いて定義される。斯かるパケットシーケンスは例示的には図28で以下のように定義される。
【0075】
=0(0b00) シーケンス内の中途のパケット
=1(0b01) シーケンス内の最初のパケット
=2(0b10) シーケンス内の最後のパケット
=3(0b11) シーケンス内の唯一のパケット
【0076】
3.HDMI CECプロトコル
コンシューマーエレクトロニクスコントロール(CEC)はHDMIにおける双方向コントロールバスである。このバスはこれ自体に接続される幾つかのオーディオ/ピジュアル(AV)装置によって用いられるべき共有媒体である。
【0077】
このバスは性質上100?200ビット/秒の範囲の生データ伝送速度を有しており非常に遅い。単一のベンダー指定CECメッセージは、HDMI仕様バージョン1.3aに従った最大16×10ビットの生サイズと、最高11×8ビットの生ペイロードを有する。プロトコル及びデータフローについて100%乃至200%のオーバヘッドを考慮すると、1つのCECメッセージの伝送に数秒を要することになる。これは、もし先の2つの方法によって最大限可能であるような同一のデータ量、すなわち21.8Kバイトである場合、伝送に数分を要することを意味する。この伝送の間にもし他の何らかの装置がバスを用いない場合には、これは正に真実であり、場合によっては伝送時間が更に増加することになる。
【0078】
従って、ルックデータパケットがサイズ上制限されることが賢明である。この速度を考慮すると、一定のルックデータエレメンタリメッセージが日々の使用に用いられることは非実用的である(特にLUTダウンロード、図8?図11を参照)。
【0079】
それにもかかわらず、CECフレームのペイロードサイズを考慮すると、ルックデータパケットが1つのCECフレームよりも長くなることは殆ど不可避である。CECが単純な応用のために設計されたという事実に起因して、本発明の実施形態に従った通信をより堅牢にするために、抽象レイヤがCECの上に実装され得る。
【0080】
より具体的に且つ国際電気標準会議オープンシステム相互接続(ISO/OSI)参照モデルに関して、CEC機能には、物理レイヤ、データリンク及びネットワークレイヤの一部が実装される。サービス品質(QoS)はネットワークレイヤによっては提供されない。
【0081】
従って、本発明の1つの実施形態において、QoSはCECプロトコル上で実装されるべきレイヤにおいて提供される。
【0082】
図29は、本発明の実施形態に従った、コンシューマーエレクトロニクスコントロール(CEC)バスの用途のための例示的なネットワークレイヤモデル2900を示す。ネットワークレイヤモデル2900は、アプリケーションレイヤ2905、TL_CECレイヤ2910、CECレイヤ2915、及び、CEC-物理レイヤ(CEC-物理)2920を含み、第1の装置(装置1)2981と第2の装置(装置2)2982の間の通信はCEC-物理レイヤ(CEC-物理)2920で実行される。
【0083】
図30は、本発明の実施形態に従った、CECベンダー指定コマンドによってアプリケーションからアプリケーションへの通信を提供するための例示的なCEC処理3000の上位のブロック図を示す。すなわち、CEC処理3000に関して、ルックデータエレメンタリメッセージは、コンテンツ作成/オーサリングにおいて生成アプリケーション3005によって生成される。ルックデータエレメンタリメッセージは、次いで1つのルックデータパケットになるようにパケット組立ブロック3010によって組み立てられる。巡回冗長符号(CRC)はこのパケットからCRCブロック3015によってHDMIに定義される方法で算出される。ここでのCRCはチェックサムとして実装され、それはヘッダと更にチェックサムデータとを含む全パケットデータのバイト総合計が零に等しいように定義される。
【0084】
続いて、CRC及びルックデータパケットは、パケットからフレームへのブロック3020によって、通信のために適当なサイズのフレームに分離される。本発明の実施形態において、88バイトのパケットサイズが例として用いられ得る。斯かる実施形態において、最初のCECメッセージは8ビットのCRCデータを運び、CRCデータがルックデータパケット当たり一度だけ伝達される必要があることから、引き続くメッセージは次いで8ビットのもっと多くのペイロードデータを運ぶ。
【0085】
変形例として図31に図示されるように、CRCデータは伝送の終わり、すなわちフレームNで伝送することができる。つまり、図31はHDMlを用いた伝送のためにルックデータパケットのフレームへの例示的な変換3100を例示する上位のブロック図を示している。再び戻って図30を参照すると、データはCEC3030を介した伝送の準備ができている。
【0086】
本発明の1つの実施形態において、受信側においては正に反対のことがなされる。つまり、フレームがルックデータパケットになるように分解され、チェックサムが算出され、次いで、ルックデータエレメンタリメッセージが受信側の適用に供するためにルックデータパケットから分解され、斯かる適用は典型的にはコンテンツクリエーターよって指定される意図に従った眺め(look)をここで変更する表示である。
【0087】
CRCブロック3015はネットワークレイヤ2900の一部である点に留意する必要がある。CRCエラーの場合、以下の2つの例示的なアプローチの何れかが実行され得るが、但し、本発明の原理が単に以下に説明される方法だけに限定されない点に留意する必要がある。第1の方法においてルックデータパケットは破棄することができる。第2の方法において再送要求を発効することができる。第1の方法の場合、以前に送信されたパケットは有効なままとなる。
【0088】
図31を再度参照すると、図31は本発明の実施形態に従った、HDMIを用いた伝送のためのフレームへのルックデータパケットの例示的な変換3100を例示する上位のブロック図を示す。変換3100は、与えられたルックデータパケット3110と、CRC算出適用3120と、パケットからフレームへの変換3130とを伴い、結果としてのフレーム3140が、CRC情報3145を有する最初のフレームと共に得られる。
【0089】
以前に言及された方法の幾つかとは異なり、CECは映像信号と共通する時刻基盤を有しない。従って、ルックデータパケットを同期させる本発明の実施形態において、伝送されたLDPのパラメータ及びデータのローディングをシンク装置のビデオ処理ブロックと時間合わせするために、LDP伝送の終わりに検証信号が用いられる。斯かるように、あるルックデータパケットがCECを介して伝送されても、特別な「検証(Validate)」CECコマンドが伝送される迄無効なままである。
【0090】
しかし、検証は実際には時間合わせされ得ない。斯かるように、本発明の1つの実施形態において、1つの可能性は適用時間の不確実性を推定し、ビデオ処理における変更が乱されないことを保証することである。シーン変更ブランキングが用いられ得る。「検証」信号は1バイト程度に短くできるが、CECビットオーバヘッドによって図32に示されるように、信号は最低60ビットに足すところのスタートビットにまで増えることになる。つまり、図32は、本発明の実施形態に従った、ルックデータ検証のための例示的なルックデータエレメンタリメッセージ3200を示している。
【0091】
従って、送信時間は、CEC開始時間+20×CECの公称データビット周期時間によって計算することができる。HDMI仕様バージョン1.3aは、4.5ミリ秒の公称CEC開始時間及び2.4ミリ秒の公称CECデータ周期時間を提案している。これは4.5ミリ秒+60×2.4ミリ秒=148.5ミリ秒の結果を与える。従って、「検証」信号は、60Hzの場合に9フィールドの遅延、50Hzの場合に8フィールドの遅延、又は24Hzの場合に4フィールドの遅延を有することになる。しかし、これはHDMI仕様におけるCEC仕様のより新しいバージョンによっては変わり得る。
【0092】
斯かるように、60Hzのフィールド周波数の場合、「検証」コマンドは適用に先立って少なくとも9フィールド前にCEC発生器から要求されなければならない。HDMIシンク制御はビデオ及びCEC両方を介していることから、所与の画像コンテンツに間違ったLDPデータを適用するのを回避するために、移行フェーズ中に画像コンテンツが消されるか又はLDP変更に対して脆弱にならないようにすることが提案される。移行フェーズは、HDMI仕様の手段で可能な最速のCEC移行時間と、最も遅いCEC伝送と、足すところのシンク装置におけるあり得る処理遅延とを仮定した伝送時間の間の期間であると判定される。
【0093】
シーンベースのルックデータパケット変更の同期問題を解決するために、以下の例示的な方法が本発明の実施形態に従って提案される。すなわち、CECをビデオに同期させるために、物理レベルのCEC動作が実行される。これは例えば図33に示される装置によって達成することができる。
【0094】
より具体的には、図33は本発明の実施形態に従った、CEC検証信号を生成するための例示的な装置3300を示す。図33の装置3300は、例示的には、CEC発生器3310、送信機側3320、受信器側3330、及び、CECデコータ3340を含む。物理レベルのCEC動作は装置3300よって実行され、装置3300は送信機側3320においてCECの物理レイヤ動作を、ビデオ部のVSYNC(垂直同期信号)に同期させる。受信器側3330において、装置は、そのルックデータパケットデータ適用をCEC物理レイヤ動作に同期させることよるフレーム同期方式で、そのルックデータパケットデータの適用を画像処理に同期させる。これを装置3300は、CEC検証コマンド命令をVSYNCに時間合わせし且つルックデータパケットデータ検証のために最後のバイトのEOM命令を待つことによって達成する。
【0095】
図34は、本発明の実施形態に従った、CECによる検証信号伝送のための方法のフローチャートを示す。方法3400はステップ3410で始まり、LDPがシンク装置に伝送される。方法3400は次いでステップ3420に進む。
【0096】
ステップ3420において、「検証」信号伝送はブロック3420におけるシンク装置のCEC発生器から要求される。方法3400は次いでステップ3430に進む。
【0097】
ステップ3430において、CECジェネレータは、次のVSYNCイベントで始まるCEC「検証」コマンドの伝送を開始する。
【0098】
方法3400は次いでステップ3440に進む。
【0099】
ステップ3440において、シンク装置は「検証」信号を受信する。方法3400は次いでステップ3450に進む。
【0100】
ステップ3450において、シンク装置は伝送が完了される迄待ち、シンク装置での次の引き続くVSYNC信号イベントでLDPデータを検証する。方法3400は次いでステップ3460に進む。
【0101】
ステップ3460において、シンク装置はLDPデータコンテンツをビデオ処理ブロックに適用する。方法3400は次いで出口処理される。
【0102】
上記したように、「検証」信号の伝送時間は略52.5ミリ秒であることになる。従って、「検証」信号は、60Hzの場合に4フィールドの遅延、50Hz及び24Hzの場合に3フィールドの遅延を有することになる。従って、その適用に先立って略4フレーム前に、LDP伝送が完了され且つ「検証」信号伝送が始動されることが必要である。その場合LDP適用の不確実性は何ら存在しない。
【0103】
本発明の変形例において、他の伝送方法としては、LDP伝送のための新しい将来ネットワーク化の可能性を含むことができる。例えば、将来、HDMIは頂上レイヤ/レベル上に新しいネットワーク化チャネルを採用してもよく、或いは既存のHDMI特有のデータ伝送可能性の幾つかを代替してもよい。この新しい伝送方法は、周知のネットワーク化技術に基づいてもよいし、ビデオ非同期であってもよい。このネットワーク技術は、LDPパケットを同一経路で送信するのに用いることかでき、ビデオ同期並びに本明細書で説明された本発明の様々な実施形態と共に説明されたパケット制御の如きCEC伝送の方法の利用に用いることができる。
【0104】
ルックデータ定義及びHDMI(例示であり制限することが意図されない)上の伝送のための方法及びシステムについて好ましい実施形態が説明されたが、当業者によって上記教示を考慮した修正及び変様がなされ得る。従って、添付の特許請求の範囲よって画定される如き本発明の範囲及び趣旨内にある、本発明の特定の実施形態における変更がなされてもよいことを理解できよう。以上の記載は本発明の様々な実施形態を志向するものである一方、本発明の他の及び更なる実施形態が本発明の範囲から逸脱することなく考案されてもよい。
(付記1)
異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を説明することでビデオコンテンツをその表示前に修正するためのメタデータを、該ビデオコンテンツについて生成するステップ、及び、
前記メタデータ及び前記ビデオコンテンツを高精細マルチメディアインタフェース上の伝送のために準備するステップ
を含む、方法。
(付記2)
付記1に記載の方法において、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で伝送するステップを含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能である、前記方法。
(付記3)
付記1に記載の方法において、
前記メタデータは、前記ビデオコンテンツに対して帯動及び非帯動のうちの少なくとも1つで伝送をなすために準備される、前記方法。
(付記4)
付記1に記載の方法において、
HDMI仕様の1.3Aバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも1つを用いて、前記伝送のために前記メタデータが準備される、前記方法。
(付記5)
付記1に記載の方法において、
ベンダー指定されたインフォフレームを用いて、前記伝送のために前記メタデータが準備される、前記方法。
(付記6)
付記5に記載の方法において、
前記準備するステップは、色域境界記述フロー制御を前記ベンダー指定されたインフォフレームに適用することを含む、前記方法。
(付記7)
付記1に記載の方法において、
高精細マルチメディアインタフェース・コンシューマーエレクトロニクスコントロールプロトコルを用いて、前記伝送のために前記メタデータが準備される、前記方法。
(付記8)
付記7に記載の方法において、
前記準備するステップは、前記コンシューマーエレクトロニクスコントロールプロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも1つを含む、前記方法。
(付記9)
付記7に記載の方法において、
前記準備するステップは、前記コンシューマーエレクトロニクスコントロールプロトコルを前記ビデオコンテンツに時間合わせすること及び前記コンシューマーエレクトロニクスコントロールプロトコルを垂直同期信号に結合すること含む、前記方法。
(付記10)
付記1に記載の方法において、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つのために、前記メタデータがある、前記方法。
(付記11)
付記10に記載の方法において、
前記メタデータは、1つ又はそれよりも多いルックアップテーブル及び1つ又はそれよりも多い色変換マトリックスのうちの少なくとも1つに対応する、前記方法。
(付記12)
付記1に記載の方法において、
前記準備するステップは、前記メタデータをパケット化することを含む、前記方法。
(付記13)
付記12に記載の方法において、更に、
前記パケットに挿入するための少なくとも1つのメッセージを生成するステップを含み、
該少なくとも1つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つに関係する、前記方法。
(付記14)
付記1に記載の方法において、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶するステップを含む、前記方法。
(付記15)
異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性を説明することでビデオコンテンツをその表示前に修正するためのメタデータを該ビデオコンテンツについて生成するメタデータ生成器、及び、
高精細マルチメディアインタフェース上の伝送のために前記ビデオコンテンツ及び前記メタデータを準備するメタデータ伝送準備装置
を含む、システム。
(付記16)
付記15に記載のシステムにおいて、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で送信する高精細マルチメディアインタフェース伝送装置を含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能である、前記システム。
(付記17)
付記15に記載のシステムにおいて、
前記メタデータは、前記ビデオコンテンツに対して帯動及び非帯動のうちの少なくとも1つで伝送をなすために準備される、前記システム。
(付記18)
付記15に記載のシステムにおいて、
前記HDMI規格の1.3Aバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも1つ用いて、前記伝送のために前記メタデータが準備される、前記システム。
(付記19)
付記15に記載のシステムにおいて、
前記メタデータは、ベンダー指定されたインフォフレームを用いて前記伝送のために準備される、前記システム。
(付記20)
付記19に記載のシステムにおいて、
色域境界記述フロー制御が前記ベンダー指定されたインフォフレームに適用される、前記システム。
(付記21)
付記15に記載のシステムにおいて、
前記メタデータは、高精細マルチメディアインタフェース・コンシューマーエレクトロニクスコントロールプロトコルを用いて前記伝送のために準備される、前記システム。
(付記22)
付記22に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記コンシューマーエレクトロニクスコントロールプロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも1つをなす、前記システム。
(付記23)
付記22に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記コンシューマーエレクトロニクスコントロールプロトコルを垂直同期信号に結合することを含んで、前記コンシューマーエレクトロニクスコントロールプロトコルを前記ビデオコンテンツに時間合わせする、前記システム。
(付記24)
付記15に記載のシステムにおいて、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つのために、前記メタデータがある、前記システム。
(付記25)
付記24に記載のシステムにおいて、
前記メタデータは、1つ又はそれよりも多いルックアップテーブル及び1つ又はそれよりも多い色変換マトリックスのうちの少なくとも1つに対応する、前記システム。
(付記26)
付記15に記載のシステムにおいて、
前記メタデータはパケット化される、前記システム。
(付記27)
付記26に記載のシステムにおいて、
前記パケットは少なくとも1つのメッセージを含み、
該少なくとも1つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つに関係する、前記システム。
(付記28)
付記15に記載のシステムにおいて、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶する記憶装置を含む、前記システム。
(57)【特許請求の範囲】
【請求項1】
ビデオコンテンツの視覚特性を特定するためのメタデータを生成するステップであって、前記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられる、前記生成するステップ、及び、
前記ビデオコンテンツのどの部分にメタデータが関連しているかを特定することにより高精細マルチメディアインタフェース上の伝送に対する前記メタデータ及び前記ビデオコンテンツを準備するステップ
を含む、方法。
【請求項2】
請求項1に記載の方法において、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で伝送するステップを含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能である、前記方法。
【請求項3】
請求項1に記載の方法において、
前記メタデータは、前記ビデオコンテンツに対して帯域内及び帯域外のうちの少なくとも1つで伝送するために準備される、前記方法。
【請求項4】
請求項1に記載の方法において、
HDMI仕様の1.3Aバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも1つを用いて、前記伝送のために前記メタデータが準備される、前記方法。
【請求項5】
請求項1に記載の方法において、
ベンダー指定されたインフォフレームを用いて、前記伝送のために前記メタデータが準備される、前記方法。
【請求項6】
請求項5に記載の方法において、
前記準備するステップは、色域境界記述フロー制御を前記ベンダー指定されたインフォフレームに適用することを含む、前記方法。
【請求項7】
請求項1に記載の方法において、
高精細マルチメディアインタフェース・コンシューマーエレクトロニクスコントロールプロトコルを用いて、前記伝送のために前記メタデータが準備される、前記方法。
【請求項8】
請求項7に記載の方法において、
前記準備するステップは、前記コンシューマーエレクトロニクスコントロールプロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも1つを含む、前記方法。
【請求項9】
請求項7に記載の方法において、
前記準備するステップは、前記コンシューマーエレクトロニクスコントロールプロトコルを前記ビデオコンテンツに時間合わせをすることを含み、該時間合わせをすることは、前記コンシューマーエレクトロニクスコントロールプロトコルを垂直同期信号に結合することを含む、前記方法。
【請求項10】
請求項1に記載の方法において、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つのために、前記メタデータがある、前記方法。
【請求項11】
請求項10に記載の方法において、
前記メタデータは、1つ又はそれよりも多いルックアップテーブル及び1つ又はそれよりも多い色変換マトリックスのうちの少なくとも1つに対応する、前記方法。
【請求項12】
請求項1に記載の方法において、
前記準備するステップは、前記メタデータをパケット化することを含む、前記方法。
【請求項13】
請求項12に記載の方法において、更に、
前記パケットに挿入するための少なくとも1つのメッセージを生成するステップを含み、
該少なくとも1つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つに関係する、前記方法。
【請求項14】
請求項1に記載の方法において、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶するステップを含む、前記方法。
【請求項15】
ビデオコンテンツの視覚特性を特定するためのメタデータを生成するメタデータ生成器であって、前記メタデータは、異なる表示装置間の多様性及びコンテンツクリエーターによる異なる創作意図間の多様性に対して調整するために表示装置の表示メカニズムを制御することにより前記ビデオコンテンツをその表示前に修正するために用いられる、前記メタデータ生成器、及び、
前記ビデオコンテンツのどの部分にメタデータが関連しているかを特定することにより高精細マルチメディアインタフェース上の伝送に対する前記ビデオコンテンツ及び前記メタデータを準備するメタデータ伝送準備装置
を含む、システム。
【請求項16】
請求項15に記載のシステムにおいて、更に、
前記メタデータ及び前記ビデオコンテンツを前記高精細マルチメディアインタフェース上で送信する高精細マルチメディアインタフェース伝送装置を含むことによって、前記ビデオコンテンツをその表示前に修正するのに前記メタデータを利用可能である、前記システム。
【請求項17】
請求項15に記載のシステムにおいて、
前記メタデータは、前記ビデオコンテンツに対して帯域内及び帯域外のうちの少なくとも1つで伝送するために準備される、前記システム。
【請求項18】
請求項15に記載のシステムにおいて、
HDMI仕様の1.3Aバージョン及び何れかの先行バージョンに関して、新たな色域プロファイル及び色域境界記述メタデータコンテナの未使用色域プロファイルのうち少なくとも1つを用いて、前記伝送のために前記メタデータが準備される、前記システム。
【請求項19】
請求項15に記載のシステムにおいて、
前記メタデータは、ベンダー指定されたインフォフレームを用いて前記伝送のために準備される、前記システム。
【請求項20】
請求項19に記載のシステムにおいて、
色域境界記述フロー制御が前記ベンダー指定されたインフォフレームに適用される、前記システム。
【請求項21】
請求項15に記載のシステムにおいて、
前記メタデータは、高精細マルチメディアインタフェース・コンシューマーエレクトロニクスコントロールプロトコルを用いて前記伝送のために準備される、前記システム。
【請求項22】
請求項21に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記コンシューマーエレクトロニクスコントロールプロトコルの上にネットワーク抽象レイヤを加えること及びサービス品質を有効化することのうち少なくとも1つをなす、前記システム。
【請求項23】
請求項22に記載のシステムにおいて、
前記メタデータ伝送準備装置は、前記コンシューマーエレクトロニクスコントロールプロトコルを前記ビデオコンテンツに時間合わせをし、該時間合わせをすることは、前記コンシューマーエレクトロニクスコントロールプロトコルを垂直同期信号に結合することを含む、前記システム。
【請求項24】
請求項15に記載のシステムにおいて、
前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれらに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つのために、前記メタデータがある、前記システム。
【請求項25】
請求項24に記載のシステムにおいて、
前記メタデータは、1つ又はそれよりも多いルックアップテーブル及び1つ又はそれよりも多い色変換マトリックスのうちの少なくとも1つに対応する、前記システム。
【請求項26】
請求項15に記載のシステムにおいて、
前記メタデータはパケット化される、前記システム。
【請求項27】
請求項26に記載のシステムにおいて、
前記パケットは少なくとも1つのメッセージを含み、
該少なくとも1つのメッセージは、前記ビデオコンテンツの色操作、前記ビデオコンテンツの空間フィルタリング処理を制御してそれに関連する変調伝達関数を変更すること、前記ビデオコンテンツのモーション挙動を制御すること、前記ビデオコンテンツのフィルム粒子態様を制御すること、前記ビデオコンテンツにノイズを印加すること、前記ビデオコンテンツにおけるシーン編集上の制御をすること、及び、前記ビデオコンテンツに関してトーンマッピングすることのうち少なくとも1つに関係する、前記システム。
【請求項28】
請求項15に記載のシステムにおいて、更に、
前記メタデータに従って修正された前記ビデオコンテンツの次回の表示のために、前記ビデオコンテンツ及び前記メタデータをディスクに記憶する記憶装置を含む、前記システム。
 
訂正の要旨 審決(決定)の【理由】欄参照。
審決日 2015-02-23 
出願番号 特願2010-544795(P2010-544795)
審決分類 P 1 41・ 853- Y (H04N)
最終処分 成立  
前審関与審査官 矢野 光治  
特許庁審判長 藤井 浩
特許庁審判官 清水 正一
渡辺 努
登録日 2014-06-27 
登録番号 特許第5567498号(P5567498)
発明の名称 ルックデータ定義及び高精細マルチメディアインタフェース上の伝送のための方法及びシステム  
代理人 特許業務法人 谷・阿部特許事務所  
代理人 特許業務法人谷・阿部特許事務所  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ