(57)【要約】【課題】  ＨＤＲ画像を符号化する際の、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを作成する際に利用するＬＤＲ画像として、ローカルデコードで得たものを利用するか否かを適応的に切り換える。【解決手段】ＨＤＲ画像を符号化し、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する画像符号化装置であって、符号化対象のＨＤＲ画像からＬＤＲ画像を生成するＬＤＲ画像生成部と、生成したＬＤＲ画像を非可逆符号化する符号化部と、符号化したＬＤＲ画像を復号する復号部と、ＨＤＲ画像とＬＤＲ画像に基づき、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する補助データ生成部と、補助データ生成部が利用するＬＤＲ画像として、ＬＤＲ画像生成部が生成したＬＤＲ画像、復号部による復号で得たＬＤＲ画像のいずれを用いるかを判定する判定部とを有する。【選択図】  図２
2018067758.tif 000002
【特許請求の範囲】
【請求項１】
ＨＤＲ画像を符号化し、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する画像符号化装置であって、
符号化対象のＨＤＲ画像からＬＤＲ画像を生成するＬＤＲ画像生成手段と、
生成したＬＤＲ画像を非可逆符号化する符号化手段と、
符号化したＬＤＲ画像を復号する復号手段と、
ＨＤＲ画像とＬＤＲ画像に基づき、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する補助データ生成手段と、
前記補助データ生成手段が利用するＬＤＲ画像として、前記ＬＤＲ画像生成手段が生成したＬＤＲ画像、前記復号手段による復号で得たＬＤＲ画像のいずれを用いるかを判定する判定手段と
を有することを特徴とする画像符号化装置。
【請求項２】
前記符号化手段は、マクロブロックを単位として、色変換、ＤＣＴ変換、量子化、及び、エントロピー符号化を行うＪＰＥＧコーデック手段であって、
前記復号手段は、前記エントロピー符号化を行う前の係数に対して逆量子化、逆ＤＣＴ、逆色変換を行う手段である
ことを特徴とする請求項１に記載の画像符号化装置。
【請求項３】
前記ＬＤＲ画像生成手段はマクロブロックを単位にＬＤＲ画像を生成し、
前記復号手段はマクロブロックを単位に復号し、
前記判定手段はマクロブロックが示す画像を単位に判定する
ことを特徴とする請求項２に記載の画像符号化装置。
【請求項４】
前記判定手段は、
ＨＤＲ画像における画素のうち、予め設定された輝度値より低い輝度を持つ画素が占める割合を求め、
当該割合が予め設定された閾値を超える場合、前記復号手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定し、
前記割合が予め設定された閾値以下の場合、前記ＬＤＲ画像生成手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定する
ことを特徴とする請求項１乃至３のいずれか１項に記載の画像符号化装置。
【請求項５】
前記ＬＤＲ画像生成手段が生成する際に利用するトーンカーブとして、予め設定された固定のトーンカーブを用いるか、符号化対象のＨＤＲ画像内の最大輝度、最小輝度に依存したトーンカーブを用いるのかを設定する設定手段を更に有し、
前記判定手段は、
前記設定手段により符号化対象のＨＤＲ画像内の最大輝度、最小輝度に依存したトーンカーブを用いると設定された場合、前記復号手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定し、
前記設定手段により前記固定のトーンカーブを用いると設定された場合、前記ＬＤＲ画像生成手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定する
ことを特徴とする請求項１乃至３のいずれか１項に記載の画像符号化装置。
【請求項６】
前記ＬＤＲ画像生成手段が生成する際のトーンマッピングとして、グローバルトーンマッピング、ローカルトーンマッピングのいずれを利用するかを設定する設定手段を更に有し、
前記判定手段は、
前記設定手段によりローカルトーンマッピングを利用すると設定された場合、前記復号手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定し、
前記設定手段によりグローバルトーンマッピングを利用すると設定された場合、前記ＬＤＲ画像生成手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定する
ことを特徴とする請求項１乃至３のいずれか１項に記載の画像符号化装置。
【請求項７】
前記判定手段は、
前記符号化手段における量子化で用いる量子化ステップが予め設定された値を超える場合、前記復号手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定し、
前記符号化手段における量子化で用いる量子化ステップが前記予め設定された値以下である場合、前記ＬＤＲ画像生成手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定する
ことを特徴とする請求項２又は３に記載の画像符号化装置。
【請求項８】
前記判定手段は、
前記符号化手段における色変換による色差成分について間引きが存在する場合、前記復号手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定し、
前記符号化手段における色変換による色差成分について間引きが存在しない場合、前記ＬＤＲ画像生成手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定する
ことを特徴とする請求項２又は３に記載の画像符号化装置。
【請求項９】
前記判定手段は、
前記ＤＣＴを行って得た係数と、前記復号手段による逆量子化後の係数との差分を求め、当該差分の絶対値が予め設定した値を超える個数の占める割合と、予め設定された閾値とを比較し、
前記割合が前記閾値より大きい場合、前記復号手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定し、
前記割合が前記閾値以下の場合、前記ＬＤＲ画像生成手段で得たＬＤＲ画像を前記補助データ生成手段により利用するものとして決定する
ことを特徴とする請求項２又は３に記載の画像符号化装置。
【請求項１０】
前記量子化で用いる量子化ステップに基づいて、前記ＤＣＴが行うマクロブロックにおける、前記割合を求める範囲を決定する手段を更に有する
ことを特徴とする請求項９に記載の画像符号化装置。
【請求項１１】
ＨＤＲ画像を符号化し、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する画像符号化装置の制御方法であって、
符号化対象のＨＤＲ画像からＬＤＲ画像を生成するＬＤＲ画像生成工程と、
生成したＬＤＲ画像を非可逆符号化する符号化工程と、
符号化したＬＤＲ画像を復号する復号工程と、
ＨＤＲ画像とＬＤＲ画像に基づき、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する補助データ生成工程と、
前記補助データ生成工程が利用するＬＤＲ画像として、前記ＬＤＲ画像生成手段が生成したＬＤＲ画像、前記復号工程による復号で得たＬＤＲ画像のいずれを用いるかを判定する判定工程と
を有することを特徴とする画像符号化装置の制御方法。
【請求項１２】
コンピュータが読み込み実行することで、前記コンピュータを、請求項１乃至１０のいずれか１項に記載の各手段として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は画像符号化技術、特に、高ダイナミックレンジ（High Dynamic Range;ＨＤＲ）を持つデジタル画像(以下、ＨＤＲ画像)の符号化技術に関するものである。
【背景技術】
【０００２】
静止画像の流通のためのデータ形式の代表的なものにＪＰＥＧがある。ＪＰＥＧは、デジタルカメラの出力ファイルのデータ形式として利用されていることもあって、それを利用したソフトウェアは、ウェブブラウザを始め、多数存在する。ＪＰＥＧ圧縮の対象となる静止画像は、１コンポーネント当り８ビット（２５６階調）の画像データである。
【０００３】
一方、人間の視覚は１：１００００までのコントラスト比を認識できるため、従来のＪＰＥＧ画像の階調表現では実際の見た目と大きな差ができる。そこで、１コンポーネント当り８ビットを超えるビット数（例えば３２ビット）で表されるＨＤＲ画像が注目されている。最近のデジタルカメラやスマートフォンでもＨＤＲモードを搭載したものが一般的になっている。また、簡単にコンポーネント当り３２ビットのデータを持つＨＤＲ画像を作成できるソフトウェアアプリケーションも増えてきている。
【０００４】
１コンポーネント当り３２ビットのデータを持つＨＤＲ画像を、従来のＪＰＥＧビューアで見ることができる技術が、ＩＳＯ／ＩＥＣ  １８４７７−２（JPEG XT Part 2）で規定されている。また、特許文献１にも同様の技術が開示されている。ＨＤＲ画像を８［ビット／コンポーネント］の、より小さいダイナミックレンジ画像（Low Dynamic Range:ＬＤＲ画像）にトーンマッピングし、ＪＰＥＧ圧縮する。そして、原画であるＨＤＲ画像とＬＤＲ画像の比率を別途ＨＤＲ補助データとして作成し、ＨＤＲ補助データとＬＤＲ画像のＪＰＥＧ符号データを、１つのファイルに保存するという方法である。ＨＤＲ補助データを保存する場所は、ＪＰＥＧのアプリケーションマーカ（ＡＰＰ１１）内である。一般的なＪＰＥＧビューアは、サポートしないＡＰＰマーカを無視してデコードする。そのため、たとえば、ＡＰＰ１１を、ＨＤＲ補助データを保存しているマーカとして認識できないＪＰＥＧビューアがＨＤＲ補助データをもつＪＰＥＧファイルを受け取ると、ＬＤＲ画像のみをデコードし表示する。一方、ＡＰＰ１１にＨＤＲ補助データが保存されていることを認識できるＨＤＲ画像ビューアは、ＬＤＲ画像とＡＰＰ１１マーカ内のＨＤＲ補助データを組み合わせて、元のＨＤＲ画像をデコードし表示できる、という仕組みである。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特許第０５０８６０６７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ここで、ＨＤＲ補助データの作成方法について考察する。まず、ＩＳＯ／ＩＥＣ  １８４７７−２に準拠したＨＤＲ画像の符号化処理について、図１Ａを参照して説明する。なお、それぞれの処理については、ＩＳＯ／ＩＥＣ  １８４７７−２に記載されているため、詳細な説明は割愛し、ここでは簡単な説明にとどめる。
【０００７】
まず、ＬＤＲ画像のＪＰＥＧ符号データの作成までを説明する。入力としてＨＤＲ画像１０１が与えられると、ＨＤＲ画像１０１はトーンマッピング部１０２により、１コンポーネントあたり０−２５５の２５６階調の線形色空間のＬＤＲ画像に変換される。色変換部１１２は、線形色空間の線形ＬＤＲ画像を、ｓＲＧＢ色空間に変換する。そして、ｓＲＧＢ空間の画像データは、ＲＧＢ／ＹＣＣ変換部１１３およびサブサンプリング部１１４による処理を経て、ＪＰＥＧ圧縮部１１５に供給され、ＪＰＥＧ符号化される。
【０００８】
次に、ＨＤＲ補助データの作成の手順を説明する。Ｙ算出部１０３は、ＨＤＲ画像１０１から輝度成分（Ｙ成分）を算出する。一方、Ｙ算出部１０５も、トーンマッピング１０２で作成された線形ＬＤＲ画像からも輝度成分（Ｙ成分）が算出する。ノイズ付加部１０６は、Ｙ算出部１０５で算出された各輝度成分にノイズを加算する。そして、Ｙratio算出部１０７は、ＨＤＲのＹ成分をノイズが付加されたＬＤＲのＹ成分で割る（除算）ことで、輝度成分の比率（Ｙratio）を算出する。Ｙratioマッピング部１０８は、算出されたＹratioを、０−２５５の範囲にマッピングし、ＨＤＲ補助データのＹ成分として、ＪＰＥＧ圧縮部１０９に供給する。さらに、Ｙratio算出部１０７は、算出したＹratioをＲＧＢスケール変換部１０４に供給する。ＲＧＢスケール変換部１０４は、ＨＤＲ画像のＲＧＢの各色成分を、Ｙratioを用いてスケール変換する。差分取得部１１０は、スケール変換されたＨＤＲ画像のＲＧＢ値と、トーンマッピング１０２から出力される線形ＬＤＲ画像のＲＧＢ値との差分値を取得する。色差算出１１１は、この差分値によってＨＤＲ補助データの色差成分を算出し、ＪＰＥＧ圧縮部１０９に供給する。ＪＰＥＧ圧縮部１０９は、Ｙratioマッピング部１０８から入力された輝度成分と、色差算出１１１から入力される色差成分とを使って、ＨＤＲ補助データのＪＰＥＧ符号データを作成する。
【０００９】
以上より、ＬＤＲのＪＰＥＧ符号データと、ＨＤＲ補助データのＪＰＥＧ符号データが生成される。出力部１１６は、両符号データとＬＤＲ画像からＨＤＲ画像へ伸長するための必要な情報と共に、１つのＪＰＥＧファイルを作成し、ＪＰＥＧ  ＸＴデータ１１７として出力する。
【００１０】
以上がＩＳＯ／ＩＥＣ  １８４７７−２の方法によるＨＤＲ画像を符号化処理である。ＨＤＲ補助データ作成時に使用されるＬＤＲ画像は、トーンマッピング部１０２から得られたデータである。しかし、最終的に、ＪＰＥＧ  ＸＴデータ１１７として出力されるＬＤＲ画像は、非可逆圧縮であるＪＰＥＧ圧縮部１１５から出力されるものであって、劣化後のデータである。従って、ＪＰＥＧ  ＸＴデータ１１７を受信して、復号して得られるＨＤＲ画像に対しては、高い精度が期待できない。
【００１１】
このような問題に対して、特許文献１は、ＪＰＥＧ圧縮部１１５で符号化されたＬＤＲ画像を一度復号して得られるＬＤＲ画像を、ＨＤＲ補助データ作成のために使用する方法を開示している。図１Ｂが、特許文献１に開示された構成である。図１Ａと同様の構成については同符号を付し、その説明は省略する。図１Ａとの違いは、ＬＤＲ画像のＪＰＥＧ圧縮部１１５の結果を、ＪＰＥＧ復号部１１９によって復号する。そして、復号されたＬＤＲ画像が色変換部１１８により線形色空間のＬＤＲ画像に変換され、その結果がＹ算出部１０５と差分取得部１１０へ供給されている。
【００１２】
このように、ＨＤＲ画像の符号化側で、ＪＰＥＧ圧縮されたＬＤＲ画像をＪＰＥＧ復号部１１９によってローカルデコードすることで、ＨＤＲ補助データ作成時のＬＤＲ画像と、ＨＤＲ復号時に使用するＬＤＲ画像の差異が解消される。したがって、ＪＰＥＧ  ＸＴデータの受信側（符号化ＨＤＲ画像の復号装置）では、より正確なＨＤＲ画像を復号することができる。
【００１３】
しかし、このように毎回ローカルデコードすることは、ＨＤＲ画像ファイル作成時の処理負荷を増大させるという問題が生じる。特に、デジタルカメラやスマートフォンなどのモバイル機器においてＨＤＲ画像を合成・圧縮するようなユースケースを考えた場合、処理負荷の軽減と高画質なＨＤＲ画像ファイルの生成の両立が大きな問題となる。
【００１４】
本発明は上記に鑑みてなされたものであり、符号化処理の負荷と、復号されるＨＤＲ画像の画質とのバランスを考慮し、より効率的にＨＤＲ画像を符号化する技術を提供しようとするものである。
【課題を解決するための手段】
【００１５】
この課題を解決するため、例えば本発明の画像符号化装置は以下の構成を備える。すなわち、
ＨＤＲ画像を符号化し、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する画像符号化装置であって、
符号化対象のＨＤＲ画像からＬＤＲ画像を生成するＬＤＲ画像生成手段と、
生成したＬＤＲ画像を非可逆符号化する符号化手段と、
符号化したＬＤＲ画像を復号する復号手段と、
ＨＤＲ画像とＬＤＲ画像に基づき、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを生成する補助データ生成手段と、
前記補助データ生成手段が利用するＬＤＲ画像として、前記ＬＤＲ画像生成手段が生成したＬＤＲ画像、前記復号手段による復号で得たＬＤＲ画像のいずれを用いるかを判定する判定手段とを有する。
【発明の効果】
【００１６】
本発明によれば、ＨＤＲ画像を符号化する際の、ＬＤＲ画像をＨＤＲ画像の精度に戻すための補助データを作成する際に利用するＬＤＲ画像として、ローカルデコードで得たものを利用するか否かを適応的に切り換える。この結果、符号化にかかる処理負荷と画質のいずれにも対応させることが可能となる。
【図面の簡単な説明】
【００１７】
【図１Ａ】ＨＤＲ画像符号化処理のブロック図。
【図１Ｂ】ＨＤＲ画像符号化処理のブロック図。
【図２】第１の実施形態におけるＨＤＲ画像符号化装置のブロック図。
【図３】第１の実施形態におけるＨＤＲ画像の圧縮フローを示す図。
【図４】第１の実施形態における線形ＬＤＲ画像の作成フローを示す図。
【図５】第１の実施形態におけるＨＤＲ補助データの作成フローを示す図。
【図６】第１の実施形態におけるトーンカーブを示す図。
【図７】第１の実施形態の変形例におけるＨＤＲ画像の圧縮フローを示す図。
【図８】第１の実施形態の変形例におけるマクロブロック単位のＬＤＲ画像圧縮フローを示す図。
【図９】第１の実施形態の変形例におけるマクロブロック単位の線形ＬＤＲ画像の作成フローを示す図。
【図１０】第２の実施形態におけるＨＤＲ画像の圧縮フローを示す図。
【図１１】第３の実施形態におけるＨＤＲ画像の圧縮フローを示す図。
【図１２】第３の実施形態の変形例におけるＨＤＲ画像の圧縮フローを示す図。
【図１３】第３の実施形態の変形例におけるマクロブロック単位のＬＤＲ画像圧縮フローを示す図。
【図１４】第４の実施形態におけるＨＤＲ画像の圧縮フローを示す図。
【図１５】第４の実施形態の変形例におけるＨＤＲ画像の圧縮フローを示す図。
【図１６】第５の実施形態におけるマクロブロック単位のＬＤＲ画像圧縮フローを示す図。
【図１７】第５の実施形態の変形例におけるＤＣＴ係数の比較範囲を示す図。
【図１８】第５の実施形態の変形例におけるマクロブロック単位のＬＤＲ画像圧縮フローを示す図。
【発明を実施するための形態】
【００１８】
以下、添付図面に従って本発明に係る実施形態を詳細に説明する。なお、実施形態では、説明を容易にするため、符号化対象のＨＤＲ画像データは１９２０×１０８０画素のＲＧＢカラーデータとし、各コンポーネント（色）は１６ビットの整数値で表されるものとして説明する。但し、ＲＧＢ以外のコンポーネントの構成（例えばグレー単色やＹＭＣ等）でも構わず、色空間の種類，コンポーネントの個数は問わない。また、１成分のビット数も１６ビットに限らず、１２ビットや３２ビットなど、８ビットを超えるビット数であれば、ビット数に特に制限はない。また、整数値だけに限定されず、３２ビットの実数値などでもよい。つまり、ＨＤＲのコントラスト比を表現できれば、入力画像の形式はどのようなものでもよい。上記の数値は、あくまで、理解を容易にする具体例を示すものと理解されたい。
【００１９】
［第１の実施形態］
図２は、本実施形態におけるＨＤＲ画像の画像符号化装置のブロック図である。同図で、２０１はＣＰＵであり、各構成の処理の全てに関わる。２０２は入力部であり、ユーザからの指示や、符号化対象のＨＤＲ画像データなどを入力する部分である。これは、キーボードやマウスなどのポインティングシステムを含む。符号化対象のＨＤＲ画像データの発生源は撮像装置とするが、入力部２０２にその撮像装置が接続されても良いし、符号化対象のＨＤＲ画像データを格納した記憶媒体が入力部２０２に接続されても構わない。場合によっては、ＨＤＲ画像データを保持するサーバがネットワーク上に存在し、入力部２０２はそのサーバからダウンロードしても構わない。２０３はＨＤＲ補助データ生成部、２０４はＬＤＲ画像生成部である。２０５はＪＰＥＧコーデック部（非可逆符号化部）であり、１コンポーネント当り８ｂｉｔの非圧縮画像データをＪＰＥＧ符号データに変換したり、ＪＰＥＧ符号データを復号し非圧縮画像データに変換する。２０６はメモリであり、ＲＯＭやＲＡＭを含み、処理に必要なプログラム、データ、作業領域などをＣＰＵ２０１に提供する。２０７は表示部であり、通常は液晶ディスプレイなどが用いられる。２０８は蓄積部であり、画像データ、プログラムなどを蓄積する部分で、通常はハードディスクなどが用いられる。また、以降のフローチャートの処理に必要な制御プログラムは、蓄積部２０８に格納されているか、メモリ２０６のＲＯＭに格納されているものとする。蓄積部２０８に格納されている場合は、一旦メモリ２０６内のＲＡＭに読み込まれてから実行される。なお、システム構成については、上記以外にも様々な構成要素が存在するが、本実施形態の主眼ではないので、その説明は省略する。
【００２０】
本実施形態におけるＨＤＲ補助データの生成方法は、ＩＳＯ／ＩＥＣ  １８４７７−２で規定されている方法を基本とする。すなわち、ＨＤＲ画像データとＬＤＲ画像データの輝度成分比（Ｙレシオ；Ｙratio）を利用する方法である。Ｙレシオを使って、ＬＤＲ画像データをＨＤＲのレンジに戻して、オリジナルのＨＤＲ画像データとの色差成分の差分を生成する。そして、Ｙレシオと色差成分を８ビット化してＪＰＥＧ符号化する方法である。
【００２１】
符号化装置に入力されたＨＤＲ画像データをＬＤＲ画像とＨＤＲ補助データに分けて、圧縮する方法について図３を用いて説明する。なお、ＩＳＯ／ＩＥＣ  １８４７７−２で規定されている処理と同様の部分については、ここでの詳しい説明は割愛する。
【００２２】
ステップＳ３０１にて、ＣＰＵ２０１は、入力部２０２を介して符号化対象のＨＤＲ画像データを入力し、メモリ２０６に格納する。ステップＳ３０２にて、ＣＰＵ２０１は、ＬＤＲ画像生成部２０４を制御し、入力したＨＤＲ画像データに対してトーンマッピング処理を行わせる。ＬＤＲ画像生成部２０４は生成した線形ＬＤＲ画像データを、メモリ２０６に保存する。また、ＬＤＲ画像生成部２０４は、線形ＬＤＲ画像を作成する際に、低輝度の画素数をカウントし、保持するものとする。この低輝度画素数のカウント処理の詳細は後述する。
【００２３】
ステップＳ３０３にて、ＣＰＵ２０１は、上記で得た低輝度画素数から、低輝度画素数の割合ＲＬＰを算出する。すなわち、画像全体の低輝度画素数をＣ、入力されたＨＤＲ画像の幅がｗ画素、高さがｈ画素とすると、ＲＬＰ＝Ｃ／（ｗ×ｈ）として算出できる（実施形態では、ｗ＝１９２０、ｈ＝１０８０）。
【００２４】
ステップＳ３０４にて、ＣＰＵ２０１は、算出して得られたＲＬＰと、予め決められた閾値Ｔｈ＿ＲＬＰを比較する。ＲＬＰが閾値Ｔｈ＿ＲＬＰより大きければステップＳ３０５へ処理を進め、そうでなければステップＳ３１３へ処理を進める。実施形態では、閾値Ｔｈ＿ＲＬＰは“０．５”とする。すなわち、低輝度画素が画像全体の半分以上を占める場合には、符号化対象のＨＤＲ画像は低輝度画素の割合が大きい画像として判断し、ステップＳ３０５へ進む。ステップＳ３０５およびステップＳ３１３では、ＨＤＲ補助データ作成時にローカルデコードしたＬＤＲ画像を使用するかどうかを示す情報を、メモリ２０６に予め確保したフラグＦｌａｇに設定する。具体的には、ステップＳ３０５にて、ＣＰＵ２０１は、ＨＤＲ補助データ作成時にローカルデコードしたＬＤＲ画像を使用することを示す値“１”をフラグＦｌａｇに設定する。ステップＳ３１３にて、ＣＰＵ２０１は、ステップＳ３０２で作成した線形ＬＤＲ画像を用いてＨＤＲ補助データを作成することを示す値“０”をフラグＦｌａｇに設定する。従って、Ｓ３１３に進んだ場合、ＬＤＲ画像のローカルデコードは行わないことになる。
【００２５】
次に、ＬＤＲ画像をローカルデコードする場合のステップＳ３０５以降の処理を説明する。ステップＳ３０５にて、ＣＰＵ２０１はフラグＦｌａｇを“１”に設定すると、処理をステップＳ３０６に進める。ステップＳ３０６にて、ＣＰＵ２０１は、ＬＤＲ画像の符号化条件として、サブサンプリング情報および量子化ステップに関する情報を取得する。次に、ステップＳ３０７にて、ＣＰＵ２０１は線形ＬＤＲ画像の色変換を行う。すなわち、ＣＰＵ２０１は、線形色空間のＬＤＲ画像にガンマ処理を施し、ｓＲＧＢ色空間の画像データに変換し、その後、ＲＧＢ／ＹＣＣ変換を行う。また、ＣＰＵ２０１は、ステップＳ３０６において取得した情報によって、サブサンプリングが必要な場合は、色差成分Ｃｂ，Ｃｒのサブサンプリングを行う。これらの処理については、一般的な処理であり、ＩＳＯ／ＩＥＣ  １８４７７−２にも記載されているので、ここでの詳細な説明は割愛する。ステップＳ３０８にて、ＣＰＵ２０１は、ＪＰＥＧコーデック部２０５を制御し、ステップＳ３０７で得られたＬＤＲ画像のＹＣＣデータをマクロブロックに分割させ、ＤＣＴ変換及び量子化処理を行わせる。これらの処理についても一般的な処理であるため、ここでの詳細な説明を割愛する。ステップＳ３０９にて、ＣＰＵ２０１は、ＪＰＥＧコーデック部２０５を制御し、量子化されたＤＣＴ係数を、ＪＰＥＧ（ＩＳＯ／ＩＥＣ１０９１８）に規定された方法でエントロピー符号化する。ＪＰＥＧコーデック部２０５は、生成した符号化データを、一旦、メモリ２０６に格納する。
【００２６】
次に、ステップＳ３１０にて、ＣＰＵ２０１は、フラグＦｌａｇの値が“１”であるかどうかを判定する。すなわち、ステップＳ３０４でローカルデコードしたＬＤＲ画像を使用すると判定された場合、Ｆｌａｇの値が１であるので、ＣＰＵ２０１は処理をステップＳ３１１に進める。また、Ｆｌａｇの値が０である場合には、ＣＰＵ２０１はステップＳ３１７に処理を進める。ここでの説明では、ステップＳ３０５を経ているので、ステップＳ３１１に処理が進むものとして説明する。
【００２７】
ステップＳ３１１にて、ＣＰＵ２０１は、ＪＰＥＧコーデック部２０６を制御し、ステップＳ３０８で得られた量子化後のＤＣＴ係数を逆量子化、逆ＤＣＴすることで、ローカルデコード後のＬＤＲ画像のＹＣＣデータを取得する。なお、ローカルデコードでは、符号化データから開始してしても良いが、ＪＰＥＧでのエントロピー（ハフマン符号化）そのものは可逆であるので、途中の量子化後の係数からローカルデコードを行っている。本処理についても、ＤＣＴ／量子化と同様に詳細な説明は割愛する。ステップＳ３１２にて、ＣＰＵ２０１は、ステップＳ３１１で取得したＹＣＣデータに逆色変換をし、線形ＬＤＲ画像を生成し、メモリ２０６に保存し、処理をステップＳ３１４に進める。すなわち、ＣＰＵ２０１は、ＹＣＣ／ＲＧＢ変換によってローカルデコードしたＲＧＢ画像データを取得し、さらに、逆ガンマ処理を行うことで、ローカルデコードした線形ＲＧＢ画像データを取得する。なお、メモリ２０６には、既にステップＳ３０２で作成した線形ＬＤＲ画像が保存されているが、そのデータをローカルデコードした結果で上書きすることになる。ステップＳ３１４にて、ＣＰＵ２０１は、ＨＤＲ補助データ生成部２０３を制御し、ステップＳ３１２で得られたローカルデコードの線形ＲＧＢ画像を入力として、ＬＤＲからＨＤＲの精度（８ビットから１６ビット）に戻すためのＨＤＲ補助データを作成させる。この処理の詳細は、図５を用いて後述する。次に、ステップＳ３１５にて、ＣＰＵ２０１は、ステップＳ３１４で作成したＨＤＲ補助データを、ＩＳＯ／ＩＥＣ  １８４７７−２記載の方法で出力する。そして、ステップＳ３１６にて、フラグＦｌａｇが“１”（ローカルデコードを行うことを示している）であるかどうかを判定する。フラグＦｌａｇの値が“１”であれば、既にＬＤＲ画像のＪＰＥＧ符号データがメモリ２０６に作成されているものと判断し、ＣＰＵ２０１は処理をステップＳ３１７に進める。また、フラグＦｌａｇの値が“０”であれば、処理をステップＳ３０６に進め、ＬＤＲ画像のＪＰＥＧ符号データの作成処理に進む。ステップＳ３１７にて、ＣＰＵ２０１は、ＬＤＲ画像の符号化データを、ＩＳＯ／ＩＥＣ  １８４７７−１記載の方法で出力し、このフローを終了する。
【００２８】
次に、ステップＳ３０４にて、符号化対象のＨＤＲ画像が、低輝度画素の割合が小さい画像として判断された場合を説明する。
【００２９】
ステップＳ３１３にて、ＣＰＵ２０１は、フラグＦｌａｇに“０”を設定、すなわち、ローカルデコードしないとして設定する。そして、ステップＳ３１４、３１５にて、ＣＰＵ２０１は、ＨＤＲ補助データ生成部２０３を制御し、ステップＳ３０２で得られた線形ＬＤＲ画像を入力として、ＨＤＲ補助データを作成、出力させる。次にステップＳ３１６にて、ＣＰＵ２０１は、フラグＦｌａｇの値が“１”であるか否かを判定し、“１”であればステップＳ３１７、“０”であればステップＳ３０６に処理を進める。ここでの説明では、ステップＳ３１３からの説明であるので、処理はステップＳ３０６へ進み、ＣＰＵ２０１は、ＬＤＲ画像の符号化処理を行う。ステップＳ３０６からステップＳ３０９までは、上述の説明と同じである。ステップＳ３１０では、再びフラグＦｌａｇを参照する。今回は、ステップＳ３１３の処理を経ているため、フラグＦｌａｇは“０”である。したがって、ローカルデコードをする必要がないため、ステップＳ３１７へ進み、ＬＤＲ画像の符号化データを出力し、このフローを終了する。
【００３０】
次に、ステップＳ３０２におけるＬＤＲ画像生成部２０４による線形ＬＤＲ画像の作成処理を、図４を参照して説明する。
【００３１】
ステップＳ４０１にて、ＬＤＲ画像生成部２０４は、符号化対象のＨＤＲ画像データからＬＤＲ画像データを生成するためのトーンカーブを取得する。トーンカーブとは、ＨＤＲ画像を所定のダイナミックレンジに圧縮するトーンマッピング処理に利用する計算式やテーブルである。トーンマッピング処理は、人間の視覚特性や表示デバイス特性を考慮した手法など様々な手法が提案されている。本実施形態では、各色に対して、図６（ａ）のようなトーンカーブを描く数式を取得するものとする。他にもルックアップテーブルや、図６（ａ）のトーンカーブ上のサンプリングされた数点の値など、トーンカーブを特定できる情報であれば、どのようなものでも構わない。
【００３２】
ステップＳ４０２にて、ＬＤＲ画像生成部２０４は、画像の幅ｗと高さｈを取得する。本実施形態の場合、幅ｗ＝１９２０［画素］、高さｈ＝１０８０［画素］である。ステップＳ４０３にて、ＬＤＲ画像生成部２０４は、低輝度の画素値を数えるためのカウンタＣに、ゼロを代入して初期化する。そして、ステップＳ４０４にて、ＬＤＲ画像生成部２０４は、画像の高さ方向をカウントするための変数ｙに、ゼロを代入して初期化する。また、ステップＳ４０５にて、ＬＤＲ画像生成部２０４は、画像の幅方向をカウントするための変数ｘにゼロを代入して初期化する。なお、本実施形態では、画像の左上隅（０，０）からラスタ順に以下の処理を行う。
【００３３】
ステップＳ４０６では、ＬＤＲ画像生成部２０４は、ＨＤＲ画像内の（ｘ，ｙ）で表わされる画素位置の画素値ＰＨを取得する。本実施形態では、画素値ＰＨはそれぞれ１６ビットのＲ，Ｇ，Ｂの値で構成される。ステップＳ４０７では、ステップＳ４０１で取得したトーンカーブを使って、画素値ＰＨをＬＤＲ画像の画素値ＰＬ（８ビット）にマッピングする。そして、ＬＤＲ画像生成部２０４は、メモリ２０６に確保した、線形ＬＤＲ画像用の領域内の画素位置（ｘ，ｙ）に、画素値ＰＬを保存する。次に、ステップＳ４０８にて、ＬＤＲ画像生成部２０４は、画素値ＰＨの値から、画素位置（ｘ，ｙ）の輝度値Ｙ＿ｈｄｒを算出する。本実施形態では、輝度Ｙ＿ｈｄｒは８ビットのＪＰＥＧ圧縮と同様に、ＩＳＯ／ＩＥＣ  １８４７７−１で規定された変換式で算出される。ステップＳ４０９にて、ＬＤＲ画像生成部２０４は、ステップＳ４０７で算出したＹ＿ｈｄｒと予め決められた輝度の閾値Ｔｈ＿Yとを比較する。輝度値Ｙ＿ｈｄｒがしきい値Ｔｈ＿Ｙより小さければステップＳ４１０へ、そうでなければステップＳ４１１へ進む。本実施形態では、図６に示すように、マッピングしたＬＤＲの画素値が“９６”となる値“４５５０”を閾値Ｔｈ＿Ｙとする。したがって、輝度値Ｙ＿ｈｄｒが“４５５０”よりも小さい値であれば、処理はステップＳ４１０に進み、ＬＤＲ画像生成部２０４は低輝度画素を数えるカウンタＣに“１”を加算する。また、輝度値Ｙ＿ｈｄｒが４５５０以上であれば、処理はステップＳ４１０の処理は行わず、ステップＳ４１１に処理が進む。このステップＳ４１１にて、ＬＤＲ画像生成部２０４は、画素位置（ｘ，ｙ）に対してトーンマップ処理および低輝度画素の判定が終了したので、画像の水平方向のカウンタｘに“１”を加算する。そして、ステップＳ４１２にて、画像の横方向のカウンタｘが画像幅ｗと同じ値であるか判定する。同じ値であれば、この画像の右端まで処理したものと判定し、ステップＳ４１３へ進む。そうでなければ、まだ右端に到達していないものと判定し、ステップＳ４０６へ処理を戻す。ステップＳ４１３にて、ＬＤＲ画像生成部２０４は、画像の高さ方向の変数ｙに“１”を加算する。そして、ステップＳ４１４にて、ＬＤＲ画像生成部２０４は、変数ｙと画像の高さｈを比較し、同じであれば、この画像のすべての画素の処理を終えたものとして、このフローを終了する。異なる場合には、ステップＳ４０５に処理を戻して、残りの画素の処理を続ける。
【００３４】
以上の処理により、ＨＤＲ画像と同じ大きさの線形色空間のＬＤＲ画像(線形ＬＤＲ画像)と、ＨＤＲ画像の輝度成分Ｙ＿ｈｄｒ、および低輝度画素数Ｃを得ることができる。なお、線形ＬＤＲ画像は１コンポーネント当り８ビットの整数値（０〜２５５）の画像データである。
【００３５】
次に、図５を参照して、ステップＳ３１４における、ＨＤＲ補助データ生成部２０３によるＨＤＲ補助データ作成処理を説明する。ＨＤＲ補助データの作成方法については、ＩＳＯ／ＩＥＣ  １８４７７−２で記載されている方法をそのまま使用すれば良いので、詳細な説明は割愛する。
【００３６】
まず、ステップＳ５０１にて、ＨＤＲ補助データ生成部２０３は、ステップＳ３０１で取得したＨＤＲ画像の輝度値Ｙ＿ｈｄｒを取得する。輝度値Ｙ＿ｈｄｒは、ステップＳ３０２の線形ＬＤＲ画像作成時に既に計算されているので、その値を保存していれば、ここで計算する必要はない。ステップＳ５０２にて、ＨＤＲ補助データ生成部２０３は、メモリ２０６の線形ＬＤＲ画像用の領域から線形ＬＤＲ画像データを取得する。フラグＦｌａｇに“０”が設定されている場合は、メモリ２０３にはステップＳ３０２で作成された線形ＬＤＲ画像が保存されている。一方、フラグＦｌａｇが“１”に設定されている場合は、メモリ２０３には、ステップＳ３０２で作成された線形ＬＤＲ画像が、ステップＳ３１２の処理によってローカルデコード結果の線形ＬＤＲ画像によって上書きされた画像が保存されている。ステップＳ５０３にて、ＨＤＲ補助データ生成部２０３は、ステップＳ５０２で取得した線形ＬＤＲ画像の各画素について輝度値Ｙ＿ｌｄｒを算出する。輝度値の計算方法は、ＩＳＯ／ＩＥＣ  １８４７７−２で規定された変換式を用いる。ステップＳ５０４にて、ＨＤＲ補助データ生成部２０３は、ＩＳＯ／ＩＥＣ  １８４７７−２で規定されている方法に従って、ステップＳ５０１で取得したＹ＿ｈｄｒとステップＳ５０３で取得したＹ＿ｌｄｒを用いて、次式に従い全画素のＹレシオ（Ｙ＿ｒａｔｉｏ）を計算する。
Y_ratio(x,y)=Y_hdr(x,y)/(Y_ldr(x,y)+nf)
ここで、ｎｆは、ノイズ付加部１０６により付加されるノイズである。これにより、ゼロ割を防ぐことができる。
【００３７】
ステップＳ５０５にて、ＨＤＲ補助データ生成部２０３は、ＩＳＯ／ＩＥＣ  １８４７７−２で規定されている方法にしたがって、ＨＤＲ画像と線形ＬＤＲ画像の各画素位置毎にＲＧＢ値の差分ＤｉｆＲＧＢを算出する。ステップＳ５０６にて、ＨＤＲ補助データ生成部２０３は、ステップＳ５０５で算出した画素位置毎のＤｉｆＲＧＢを、ステップＳ５０４で算出した同一画素位置のＹ＿ｒａｔｉｏで割ることでスケール変換する。そして、ＨＤＲ補助データ生成部２０３は、ＩＳＯ／ＩＥＣ  １８４７７−２で規定されている方法に従って、各画素位置に対応するＨＤＲ補助データの色差成分ＣＣ＿ｈｄｒを算出する。ステップＳ５０７にて、ＨＤＲ補助データ生成部２０３は、ＣＣ＿ｈｄｒをステップＳ５０３で算出したＹ＿ｌｄｒで正規化し、ＣＣ＿ｎｏｒｍを取得する。ステップＳ５０８にて、ＨＤＲ補助データ生成部２０３は、ステップＳ５０４で取得したＹ＿ｒａｔｉｏの対数をとり、Ｙ＿ｌｏｇを算出する。ステップＳ５０９にて、ＨＤＲ補助データ生成部２０３は、すべての画素のＣＣ＿ｎｏｒｍの値から、最大値Ｍａｘ＿ＣＣ（Ｍａｘ＿ＣｂとＭａｘ＿Ｃｒ）と最小値Ｍｉｎ_ＣＣ（Ｍｉｎ＿ＣｂとＭｉｎ＿Ｃｒ）を取得する。そして、ＨＤＲ補助データ生成部２０３は、Ｍａｘ＿ＣＣとＭｉｎ＿ＣＣの範囲でＣＣ＿ｎｏｒｍを量子化し、ＣＣ＿ｎｏｒｍを８ビット化したＣＣ＿ｘｔを取得する。ステップＳ５１１にて、ＨＤＲ補助データ生成部２０３は、ステップＳ５０８で取得したＹ＿ｌｏｇについて、全ての画素の最大値Ｍａｘ＿ｌｏｇと最小値Ｍｉｎ＿ｌｏｇを取得する。そして、ＨＤＲ補助データ生成部２０３は、Ｍａｘ＿ｌｏｇとＭｉｎ＿ｌｏｇの範囲でＹ＿ｌｏｇを量子化し、８ビット化したＹ＿ｘｔを取得する。そして、ステップＳ５１３において、Ｙ＿ｘtとＣＣ＿ｘｔをＪＰＥＧ方式で符号化し、このフローを終了する。
【００３８】
本実施形態では、ＬＤＲ画像において輝度値が９６以下となる画素数が、画像全体の半数を超える場合に、ＬＤＲ画像をローカルデコードした結果を使ってＨＤＲ補助データを作成する。つまり、低輝度画素数が非常に多い場合のみ処理負荷が高いローカルデコード処理を実施し、復号時のＨＤＲ画像の画質向上を図る。これは人間の視覚特性上、低輝度に対する感度が大きいためである。そのため、処理負荷が高くても、復号時のＨＤＲ画像の画質を向上する効果が大きい。一方、低輝度画素の割合が多くない画像の場合には、復号時のＨＤＲ画像の画質を向上させる効果が少ないため、ローカルデコード処理を行わず、符号化にかかる処理負荷を低減させることができる。したがって、本実施形態によれば、復号時の画質向上の効果が大きい時のみ、符号化時の処理負荷が大きくなるローカルデコード処理を実行することが容易になる。
【００３９】
［第１の実施形態の変形例］
上記の第１の実施形態では、符号化対象のＨＤＲ画像全体に対する低輝度画素値が占める割合を用いて、ローカルデコード処理の有無を決定した。図３のステップＳ３０２で、画像全面分、すなわち１９２０×１０８０画素の線形ＬＤＲ画像を作成すると共に、低輝度画素値をカウントした。そのため、線形ＬＤＲ画像作成後に、ローカルデコードの有無を判定できた。しかし、画像全体の情報が必要になるため、並列化処理ができず、メモリ使用量も大きくなってしまう。
【００４０】
たとえば、マクロブロック（８×８画素）の高さと同じ８ラインずつに画像を分割し、ＨＤＲ画像の圧縮フローを実行し、並列処理で高速化することを考える。ＬＤＲ画像の作成を終えた８ライン分の符号化を行うと同時に、次の８ラインのＬＤＲ画像の作成を並列して実行する。しかし、画像全体における低輝度画素の割合が分からないと、ローカルデコードの有無が決まらない。そのため、ＨＤＲ補助データの作成は、ステップＳ３０２の処理が終わるまで始めることができず、並列処理できない。さらに、ローカルデコードの有無が決定するまで、ステップＳ３０８で得られるＬＤＲ画像の量子化値をすべて保存しておく必要がある。そのため、ＬＤＲ画像のすべての量子化値を保持しなければならない。あるいは、ＬＤＲ画像の符号データだけを保持しておき、ローカルデコードが必要になった時点で復号し、線形ＬＤＲ画像を作成することもできる。この場合、ＬＤＲ画像のメモリ使用量は符号データ分と、８ライン分のメモリのみで良いが、エントロピー符号化を復号する時間が必要になり、処理全体が遅くなる。
【００４１】
上述の問題を解決する方法として、本変形例では、マクロブロック単位でローカルデコードの有無を切り替えるものである。以下、本変形例の具体的な処理を、図７のフローを使って説明する。なお、本変形例において、第１の実施形態と同じ動作の処理には、同符号を付与し、その詳細な説明は割愛する。また、以下の説明では、ＨＤＲ補助データ生成部２０３、ＬＤＲ画像生成部２０４、ＪＰＥＧコーデック部２０５等の各種処理部が、ＣＰＵ２０１によって実行される例を説明する。
【００４２】
ＣＰＵ２０１は、ステップＳ３０６にて、ＬＤＲ画像の符号化条件を取得する。次に、ステップＳ７０１にて、ＣＰＵ２０１は、ＨＤＲ画像のサイズ、すなわち幅ｗと高さｈを取得する。本実施形態の場合、幅ｗ＝１９２０画素、高さｈ＝１０８０画素である。ステップＳ７０２にて、ＣＰＵ２０１は、処理すべきマクロブロック数Ｎを算出する。本実施形態では、画像の幅ｗが１９２０画素であるので、Ｎ＝１９２０÷８＝２４０と計算できる。続くステップＳ７０３にて、ＣＰＵ２０１は、ＨＤＲ画像データを先頭から順に８ライン取得する。８ラインとは、マクロブロックの高さと一致するライン数である。ステップＳ７０４にて、ＣＰＵ２０１は、処理済みのマクロブロックをカウントするためのカウンタＭにゼロを代入し初期化する。ステップＳ７０５にて、ＣＰＵ２０１は、マクロブロック単位でＬＤＲ画像の圧縮処理を行う。この処理については、後に図８を使って説明する。ステップＳ７０６にて、ＣＰＵ２０１は、ＨＤＲ補助データ作成に必要なマクロブロックのＣＣ＿ｎｏｒｍとＹ＿ｌｏｇを作成する。この処理は、第１の実施形態で説明した図５のステップＳ５０１からステップＳ５０８を、マクロブロックに対して適用した処理である。第１の実施形態で説明済みのため、本変形例における処理フローとその説明は割愛する。次にステップＳ７０７にて、ＣＰＵ２０１は、マクロブロックのカウンタＭに“１”を加算する。ステップＳ７０８にて、ＣＰＵ２０１は、カウンタＭとステップＳ７０３で算出した処理すべきマクロブロック数Ｎを比較する。Ｍ＝Ｎであれば、現時点で入力された８ライン分のＨＤＲ画像の処理が終了したと判断し、ＣＰＵ２０１は処理をステップＳ７０９へ進める。そうでなければ、ＣＰＵ２０１はステップＳ７０５へ処理を戻す。ステップＳ７０９にて、ＣＰＵ２０１は、ＨＤＲ画像の最後のラインまで処理が終わったかどうかを判定する。本実施形態では、ステップＳ７０３で入力されたライン数を加算しておき、ステップＳ７０１で取得したＨＤＲ画像の高さと同じになった場合、最後のラインまで終了したと判定する。最後のラインまで終了した場合、ＣＰＵ２０１は処理をステップＳ７１０へ進める。そうでなければ、ＣＰＵ２０１は、ステップＳ７０３へ処理を戻し、次の８ラインを取得する。
【００４３】
ステップＳ７１０にて、ＣＰＵ２０１は、ステップＳ７０６で得られたＣＣ＿ｎｏｒｍとＹ＿ｌｏｇを使って、ＨＤＲ補助データの圧縮処理を行う。この処理は、第１の実施形態で説明した図５のフローチャートにおけるステップＳ５０９からステップＳ５１３までの処理と同じであるので、その説明は割愛する。なお、図５のフローのステップＳ５０９以降の処理において、画像全体における最大値および最小値を取得する必要がある。そのため、ＬＤＲ画像の作成を８ラインずつ実施する本変形例においては、ステップＳ５０８までと、それ以降で処理を分割する必要がある。次にステップＳ３１５にて、ＣＰＵ２０１は、ステップＳ７１０で作成されたＨＤＲ補助データを出力する。そして、ステップＳ３１７において、ＣＰＵ２０１は、ステップＳ７０５で作成されたＬＤＲの圧縮データをＬＤＲ情報として出力する。ステップＳ３１５とステップＳ３１７の処理は第１の実施形態と同じであるので、ここでの説明は省略する。
【００４４】
次に、ステップＳ７０５のマクロブロック単位のＬＤＲ画像圧縮処理を図８のフローチャートに従って説明する。
【００４５】
ステップＳ８０１にて、ＣＰＵ２０１は、マクロブロック単位で線形ＬＤＲ画像を作成する。この方法については、後に図９を用いて説明する。ステップＳ８０２にて、ＣＰＵ２０１は、ステップＳ８０１で線形ＬＤＲ画像を作成する際にカウントした低輝度画素の数から、着目マクロブロックの低輝度画素の割合ＲＬＰ＿ｍを算出する。マクロブロックのサイズは８×８画素である。故に、ステップＳ８０１で得られる低輝度画素数をＣとすると、ＲＬＰ＿ｍ＝Ｃ／６４となる。ステップＳ８０３にて、ＣＰＵ２０１は、ＲＬＰ＿ｍと、あらかじめ決められた閾値Ｔｈ＿ＲＬＰを比較する。ＲＬＰ＿ｍが閾値Ｔｈ＿ＲＬＰより大きければ、ＣＰＵ２０１は処理をステップＳ３０５へ進める。本変形例では、閾値Ｔｈ＿ＲＬＰは０．５とする。したがって、本変形例の場合、１つのマクロブロックに低輝度の画素が３３以上あれば、処理はステップＳ３０５へ進むことになる。ステップＳ３０５にて、ＣＰＵ２０１は、ローカルデコードを行うことを示すためフラグＦｌａｇに“１”を代入する。一方、ＲＬＰ＿ｍが閾値以下となって、Ｓ３１３に処理が進んだ場合、ＣＰＵ２０１は、ローカルデコードを行わないことを示すためフラグＦｌａｇに“０”を代入する。ステップＳ３０７からステップＳ３１０までは第１の実施形態と同様の動作をする。ステップＳ３１０にて、ＣＰＵ２０１は、フラグＦｌａｇが“１”であるか否かを判定する。フラグＦｌａｇが“１”の場合、ＣＰＵ２０１は処理をステップＳ３１１へ進め、そうでなければ、本フローを終了する。ステップＳ３１１およびステップＳ３１２は第１の実施形態と同様の動作をする。ただし、Ｓ３１１、３１２における処理対象は、着目マクロブロックとなる。ステップＳ８０４では、ステップＳ３１２で得られたローカルデコード後の画像データで、ステップＳ８０１で作成した着目マクロブロックの線形ＬＤＲ画像を上書きし、このフローを終了する。
【００４６】
次に、ステップＳ８０１のマクロブロック単位の線形ＬＤＲ画像の作成処理を図９のフローを参照して説明する。
【００４７】
基本的には、第１の実施形態の図４で画像全体に対して行った処理を、本変形例に合わせて１つのマクロブロックに対して行うことになる。
【００４８】
ステップＳ４０１にて、ＣＰＵ２０１は、トーンマッピング処理に用いるトーンカーブを取得し、ステップＳ４０３に処理を進める。ステップＳ４０３からステップＳ４１１までは、第１の実施形態と同様の処理である。ステップＳ９０１にて、ＣＰＵ２０１は、変数ｘとマクロブロックの幅＝８を比較する。変数ｘ＝８であれば、ＣＰＵ２０１は、このマクロブロックの右端まで処理を終えたものと判断し、処理をステップＳ４１３へ進める。また、変数ｘがマクロブロック幅に達していない場合、ＣＰＵ２０１は着目画素の右隣の画素を処理するためにステップＳ４０６へ処理を戻す。ステップＳ４１３にて、ＣＰＵ２０１は、マクロブロックの高さ方向の変数ｙに“１”を加算する。ステップＳ９０２にて、ＣＰＵ２０１は、変数ｙとマクロブロックの高さ＝８と比較する。ｙが８であればこの処理を終了し、そうでなければ次のラインの先頭から処理を進めるために、ステップＳ４０５へ処理を戻す。
【００４９】
本変形例の処理によれば、マクロブロック単位でローカルデコードの有無を切り替えることができる。そのため、マクロブロック境界にアーチファクトが発生するリスクは高くなる。しかし、ＬＤＲの符号化に要するメモリ使用量を削減でき、並列処理による高速化も行いやすいという効果が期待できる。
【００５０】
なお、本実施形態では、マクロブロックと同じ高さである８ラインずつデータを読み込み処理したが、マクロブロックの高さ（＝８）の倍数であれば、何ラインであっても構わない。
【００５１】
［第２の実施形態］
第１の実施形態では、図６（ａ）のようにＨＤＲ画像のデータがとり得る範囲すべてをカバーするトーンカーブを使用した。このように画像によらず一意に決まるトーンカーブを適用するトーンマッピング処理は、計算コストが小さく、リアルタイム性が要求される場合には好まれる。しかし、入力されるＨＤＲ画像がこの範囲をすべて使用していないことがある。実際、個々のＨＤＲ画像のダイナミックレンジは様々であり、取り得るデータ範囲の一部しか使っていない画像がほとんどである。たとえば、第１の実施形態では、入力されたＨＤＲ画像の画素値が“４５５０”より小さい値であれば低輝度画素としてカウントしたが、入力ＨＤＲ画像の最小画素値が“４５５０”であると、ローカルデコードが必要と判断されることが全くない。
【００５２】
一方、符号化対処のＨＤＲ画像のダイナミックレンジに依存したトーンカーブを用いてトーンマッピングを行うことも考えられる。たとえば、入力ＨＤＲ画像の画素値の最小値が“４５５０”で、最大値が“５０５３０”である場合、図６（ｂ）のようなトーンカーブを生成し、ＬＤＲ画像を作成する。このように個々の符号化対象のＨＤＲ画像のダイナミックレンジに合わせたトーンカーブを使用する方が、計算コストはかかるが、より綺麗（高品位）なＬＤＲ画像を復号できる符号データを作成することができる。つまり、計算コストよりも画質を重視していると判断できる。
【００５３】
本第２の実施形態では、ＨＤＲ画像の画素値の取り得る全範囲に対応する固定トーンカーブ（図６（ａ））を用いて符号化するのか、符号化対象のＨＤＲ画像に依存したトーンカーブを生成した上で符号化するのかを、ユーザが入力部２０２を介して設定する例を説明する。そして、その設定に応じてローカルデコードの有無を切り換える。
【００５４】
なお、本第２の実施形態におけるＬＤＲ画像生成部２０４は、固定トーンカーブを用いることが設定された場合には、図６（ａ）に示すトーンカーブを用いてＬＤＲ画像を生成する。一方、符号化対象のＨＤＲ画像に依存するトーンカーブを用いることが設定された場合、ＬＤＲ画像生成部２０４は、符号化対象のＨＤＲ画像の画素の最大値と最小値とを求め、その範囲の出力値を０乃至２５５とする曲線を設定した上で、ＬＤＲ画像を生成するものとする。
【００５５】
以下、本第２の実施形態の処理を図１０のフローチャートに従って説明する。なお、本第２の実施形態において、第１の実施形態と同様の処理には、同じ番号を付与し、その説明は省略する。
【００５６】
ステップＳ３０１にて、ＣＰＵ２０１はＨＤＲ画像のデータを取得し、メモリ２０６に格納する。次に、ステップＳ３０２にて、ＣＰＵ２０１はＬＤＲ画像生成部２０４を制御し、線形ＬＤＲ画像を作成させる。生成された線形ＬＤＲ画像はメモリ２０６に格納される。なお、ＬＤＲ画像の生成手順は先に説明した通りである。次に、ステップＳ１００１にて、ＣＰＵ２０１は、ステップＳ３０２で使用したトーンカーブが、符号化対象のＨＤＲ画像に依存したトーンカーブであったかを判定する。この判定は、ユーザの設定から判定しても良い。
【００５７】
符号化対象のＨＤＲ画像に依存したトーンカーブを用いたと判定された場合、ＣＰＵ２０１は画質重視であると判断し、処理をステップＳ３０５へ進める。ステップＳ３０５にて、ＣＰＵ２０１は、ローカルデコードしたＬＤＲ画像をＨＤＲ補助データ作成時に使用するようにするため、フラグＦｌａｇに“１”を設定する。一方、ステップＳ３０２で使用したトーンカーブが、符号化対象のＨＤＲ画像に依存しない、固定トーンカーブであった場合、ＣＰＵ２０１は、ステップＳ１００１からステップＳ３１３に処理を進める。ステップＳ３１３にて、ＣＰＵ２０１は、ＬＤＲ画像のローカルデコードをしないことを示すため、フラグＦｌａｇに“０”を設定する。ステップＳ３０６以降は、第１の実施形態と同様の動作であるので、ここでの説明は割愛する。
【００５８】
以上の本第２の実施形態によれば、画質優先か否かに応じて、適用するトーンカーブを決定し、ＬＤＲ画像のローカルデコードをするか、しないかを切り分けることができる。
【００５９】
［第２の実施形態の変形例］
上記第２の実施形態では、符号化対象のＨＤＲ画像に依存したトーンカーブを使用するか、固定トーンカーブを使用するかによって、ローカルデコードをする／しないを切り替えた。しかし、符号化対象のＨＤＲ画像の輝度値の最小値と最大値から、ローカルデコードをする／しないを切り替えてもよい。つまり、入力ＨＤＲ画像の最大輝度値が予め設定された閾値より小さい場合には、低輝度の画像であると判定し、ローカルデコードを行う。逆に、入力ＨＤＲ画像の最小輝度値が予め設定された閾値以上の場合には、ローカルデコードを行わない。本変形例の場合、第１の実施形態のように低輝度画素の割合を計算するわけではない。そのため、ほとんどの画素の輝度が低いにも関わらず、ノイズなどで１画素でも最大輝度値が大きくなると、ローカルデコードされない。しかし、ローカルデコードの有無をより簡易に判定できる。さらに、入力ＨＤＲ画像のダイナミックレンジに応じたトーンカーブを使用しながらも、ＨＤＲ補助データ作成にかかる計算コストを小さく抑えることができる。
【００６０】
［第３の実施形態］
トーンマッピング手法としては、大きく２つの手法がある。１つは、第１、第２の実施形態で示したように、画像全体に一様な輝度変換を行うグローバルトーンマッピングである。もうひとつは、画像の局所領域毎に、異なった輝度変換を行うローカルトーンマッピングである。
【００６１】
グローバルトーンマッピングは、画像全体で一様な変換関数を用いるため、画像中のテクスチャ情報の視認性が低下する。一方、ローカルトーンマッピングは、グローバルトーンマッピングに比べて計算コストが高い。しかし、局所領域におけるコントラストを維持することが可能になり、テクスチャ情報の視認性低下を防ぐことができる。
【００６２】
この２つのトーンマッピング手法を使い分ける場合に、ローカルデコードをする／しないを切り替える方法について、図１１を用いて説明する。なお、トーンマッピングを行う場合のグローバルトーンマッピング、ローカルトーンマッピングのいずれを用いるのかは、入力部２０２によりユーザが設定するものとする。
【００６３】
図１１において、図１０と同じ処理には同じ番号を付与し、その部分の説明は省略する。
【００６４】
ステップＳ３０１にて、ＣＰＵ２０１は、符号化対象のＨＤＲ画像のデータを取得し、メモリ２０６に格納する。次に、ステップＳ３０２にて、ＣＰＵ２０１は、ＬＤＲ画像生成部２０４を制御し、メモリ２０６に格納されたＨＤＲ画像から線形ＬＤＲ画像を作成させ、作成した線形ＬＤＲ画像をメモリ２０６に格納させる。次に、ステップＳ１１０１にて、ステップＳ３０２で使用したトーンマッピングの手法が、ローカルトーンマッピングだったかどうかを判定する。この判定は、ユーザからの設定から行うものとするが、例えば、１つのＨＤＲ画像に対して、複数のトーンカーブを使用した場合に、ローカルトーンマッピングであったと判定しても良い。ローカルトーンマッピングである場合は、ＣＰＵ２０１は、画質重視であると判断し、処理をステップＳ３０５へ進める。また、ローカルトーンマッピングではない場合には、ＣＰＵ２０１は計算コスト重視と判断し、処理をステップＳ３１３に進める。以下の処理は第２の実施形態と同様である。
【００６５】
本第３の実施形態よれば、トーンマッピングの手法により画質重視か、計算コスト重視かを容易に判断でき、ＬＤＲ画像のローカルデコードをするか、しないかを簡単に切り分けることができる。
【００６６】
［第３の実施形態の変形例］
上記第３の実施形態では、ローカルトーンマッピングが選択された場合に、ＬＤＲ画像の全領域についてローカルデコードした結果を用いた。
【００６７】
本変形例では、すべてのマクロブロックに対してローカルトーンマッピングを実施するが、マクロブロック毎にローカルデコードをする／しないを切り替える場合について考える。この場合、人間の視覚特性は、低輝度に対する感度が大きいことを考慮すると、暗い領域として分類されたマクロブロックのみ、ローカルデコードすることで、計算コストを軽減することができる。このような処理について、図１２を用いて説明する。なお、第１乃至第３の実施形態と同じ処理には同じ番号を付与し、詳細な説明は割愛する。
【００６８】
ステップＳ３０１にて、ＣＰＵ２０１は、符号化対象のＨＤＲ画像データを取得し、メモリ２０６に格納する。次いで、ステップＳ１２０１にて、ＣＰＵ２０１は、ＨＤＲ画像を、暗い領域と明るい領域の２つに分類し、領域分割する。領域分割の方法は、明るい領域と暗い領域に２分できるのであれば、どのような方法を用いても構わない。
【００６９】
本変形例では、各画素の輝度値を見て、１６ビットで取り得る輝度範囲（０〜６５５３５）の真ん中（４３６７８）未満であれば暗い領域の画素として分類する。それ以外であれば明るい領域の画素として分類する。その後、例えば１２８画素×１２８画素未満の領域は隣接領域と統合し、領域分割を終了するものとする。
【００７０】
ステップＳ７０２にて、ＣＰＵ２０１は、画像全体に含まれるマクロブロック数Ｎを算出する。実施形態では、画像サイズが１９２０×１０８０画素であるので、Ｎ＝（１９２０／８）×（１０８０／８）＝３２４００と算出できる。ステップＳ７０４にて、ＣＰＵ２０１は、マクロブロック用のカウンタＭにゼロを代入して初期化する。ステップＳ１２０２にて、ＣＰＵ２０１は、マクロブロック単位のＬＤＲ画像圧縮を行う。この処理については、後に図１３を用いて説明する。
【００７１】
ステップＳ７０７にて、ＣＰＵ２０１は、マクロブロック用カウンタＭに“１”を加算する。ステップＳ７０８にて、ＣＰＵ２０１は、マクロブロック用カウンタＭの値と、マクロブロック数Ｎとを比較する。同じであれば、ＣＰＵ２０１は、すべてのマクロブロックについてＬＤＲ画像圧縮を終えたものと判断し、処理をステップＳ３１４へ進める。そうでなければ、ＣＰＵ２０１は処理をステップＳ１２０２へ戻す。ステップＳ３１４、ステップＳ３１５、ステップＳ３１７は第１の実施形態と同様の動作を行い、このフローを終了する。
【００７２】
次に、ステップＳ１２０２の処理を、図１３を参照して説明する。なお、図１３において、図９と同様の動作には同じ番号を付与し、その説明は省略する。
【００７３】
ステップＳ８０１にて、ＣＰＵ２０１は、マクロブロック単位の線形ＬＤＲ画像を作成する。ステップＳ１３０１にて、ＣＰＵ２０１は、現在処理中のマクロブロック内に、ステップＳ１２０２の結果、暗い領域として判定された画素が３２画素以上（半数以上）含まれているかどうか判定する。３２画素以上が暗い領域であれば、ＣＰＵ２０１はステップＳ３０５へ処理を進め、このマクロブロックはローカルデコードするものとして、フラグＦｌａｇに“１”を代入する。一方、ステップＳ３１３に処理が進んだ場合、ＣＰＵ２０１は、ローカルデコードしないものとするため、フラグＦｌａｇに“０”を代入する。ステップＳ３０７からステップＳ８０４は、第１の実施形態およびその変形例で説明したのと同様の処理を行い、このフローを終了する。
【００７４】
本変形例によれば、低輝度領域に分類されるマクロブロックのみローカルデコードを実施する。そのため、ＨＤＲ画像デコード時に処理が切り替わったマクロブロックの境界部分にアーチファクトが出る可能性はある。しかし、ローカルトーンマッピングを行う場合であっても、ローカルデコードするマクロブロックを限定することで、ＨＤＲ補助データ作成にかかる計算コストを削減することができる。
【００７５】
なお、本変形例では、すべてのマクロブロックに対してローカルトーンマッピングする方法について説明したが、第３の実施形態のように、グローバルトーンマッピングとローカルトーンマッピングのどちらかを選択する場合に適用してもよい。
【００７６】
［第４の実施形態］
ローカルデコードした方が良い場合は、符号化対象のＨＤＲ画像をトーンマッピングして得られるＬＤＲ画像と、最終的にＪＰＥＧ  ＸＴファイルに書き込まれた符号化データを復号して得られる復号後ＬＤＲ画像の差異が大きい場合である。ＬＤＲ画像の量子化ステップが大きいほど、量子化による誤差が大きくなるので、上記の差異が大きくなると考えてよい。したがって、本第４の実施形態では、ＬＤＲ画像の量子化ステップを基準にローカルデコードをする／しないを切り替える方法について説明する。
【００７７】
以下、本第４の実施形態における処理を、図１４を参照して説明する。
【００７８】
ステップＳ３０１、３０２では、ＣＰＵ２０１は、第１の実施形態と同様に、符号化対象のＨＤＲ画像データを取得し、線形ＬＤＲ画像を作成する。ステップＳ３０６にて、ＣＰＵ２０１は、ＬＤＲ画像の符号化条件を取得する。符号化条件には、ＬＤＲ画像のＱパラメータの情報も含まれる。Ｑパラメータは、１から１００までの整数値を取り、１００を指定すると量子化ステップがもっとも細かくなり、１を指定すると、量子化ステップが最も粗くなる。ステップＳ１４０１にて、ＣＰＵ２０１は、ステップＳ３０６で取得したＬＤＲ画像の符号化条件からＱパラメータの値を参照する。そして、ＣＰＵ２０１は、Ｑパラメータと、あらかじめ決められた値Ｔｈ＿ｑを比較する。そしてＱパラメータがＴｈ＿q未満であれば、ＣＰＵ２０１は処理をステップＳ３０５、そうでなければステップＳ３１３に進める。本実施形態の場合、Ｔｈ＿ｑは６０とする。したがって、ＬＤＲ画像のＱパラメータが６０未満であれば、ステップＳ３０５に進み、そうでなければステップＳ３１３へ進む。ステップＳ３０５以降の処理は、第１の実施形態と同様の処理であるので、ここでの詳細な説明は割愛する。
【００７９】
上記の結果、ＬＤＲ画像を符号化する際のＱパラメータから、ＬＤＲ画像の劣化具合を予測し、劣化の程度が大きいと判断した場合にはローカルデコードを行い、劣化の程度が許容できる場合にはローカルデコードは行わないとする処理が実現できる。
【００８０】
［第４の実施形態の変形例］
ＪＰＥＧ ＸＴでは、ＪＰＥＧ圧縮する際に、輝度のサブサンプリングは行わず、色差成分のみサブサンプリングを定義している。Ｃｂ、Ｃｒのｘ軸方向およびｙ軸方向のサンプリング比をそれぞれＳｂｘ，Ｓｂｙ，Ｓｒｘ，Ｓｒｙとすると、ＪＰＥＧ  ＸＴでは以下の４つのサブサンプリング比が定義されている。
（１）（Ｓｂｘ，Ｓｂｙ，Ｓｒｘ，Ｓｒｙ）＝（１，１，１，１）
（２）（Ｓｂｘ，Ｓｂｙ，Ｓｒｘ，Ｓｒｙ）＝（１，２，１，２）
（３）（Ｓｂｘ，Ｓｂｙ，Ｓｒｘ，Ｓｒｙ）＝（２，１，２，１）
（４）（Ｓｂｘ，Ｓｂｙ，Ｓｒｘ，Ｓｒｙ）＝（２，２，２，２）
上記の（１）の場合、間引きされる色差成分はないので、画質の劣化は少ないと考えて良い。そこで、本第４の変形例では、成分Ｃｂ、Ｃｒのサブサンプリングが上記の（２）〜（４）のいずれかの場合、ローカルデコードをする。本変形例のＨＤＲ画像の圧縮処理を、図１５のフローチャートに従って説明する。
【００８１】
図１５と図１４との違いは、図１４におけるステップＳ１４０１がステップＳ１５０１で置き換わった点である。図１５のステップＳ１５０１にて、ＣＰＵ２０１は、ステップＳ３０６で取得したＬＤＲ画像の符号化条件から、サブサンプリング情報を参照する。そして、ＣＰＵ２０１は、サブサンプリングが上記（２）〜（４）のいずれかであったと判断した場合、処理をステップＳ３０５に、そうでなければ、処理をステップＳ３１３に進める。このようにすることで、サブサンプリングされる場合には、ＬＤＲ画像をローカルデコードした結果を用いてＨＤＲ補助データが作成されることになる。
【００８２】
［第５の実施形態］
上記第１乃至第３の実施形態、並びにその変形例では、ＨＤＲ画像の情報やＬＤＲ画像の符号化条件などで、ローカルデコードをする／しないを切り替えた。しかし、ＬＤＲ画像の劣化を直接評価することでローカルデコードを切り替えても良い。そこで本第５の実施形態では、量子化前後の値を直接比較することで、その劣化の程度を評価し、ローカルデコードする／しないをマクロブロック単位で決定する例を説明する。
【００８３】
本第５の実施形態の場合、第１の実施形態の変形例とほぼ同じ動作をするが、図７におけるステップＳ７０５のマクロブロック単位のＬＤＲ画像圧縮の方法が異なる。そこで、本第５の実施形態におけるマクロブロック単位のＬＤＲ画像圧縮の方法について図１６を用いて説明する。なお、図１６において図８と同じ動作の処理には、同じ番号を付与し、その説明は省略する。
【００８４】
ステップＳ８０１にて、ＣＰＵ２０１は、マクロブロック単位の線形ＬＤＲ画像の作成を行う。この処理については、第１の実施形態の変形例と同じである。次にステップＳ３０７にて、ＣＰＵ２０１は、ステップＳ８０１で作成した線形ＬＤＲ画像に、第１の実施形態と同様に、色変換を行う。ステップＳ１６０１にて、ＣＰＵ２０１は、ステップＳ３０７で得られたＬＤＲ画像のマクロブロックにＤＣＴを実行し、その時の輝度のＤＣＴ係数を例えばメモリ２０６に保存する。ステップＳ１６０２にて、ＣＰＵ２０１は、ステップＳ１６０１で得られたＹ，Ｃｂ，ＣｒのＤＣＴ係数の量子化処理を行う。ステップＳ１６０３にて、ＣＰＵ２０１は、輝度Ｙの成分だけ逆量子化する。ステップＳ３０９にて、ＣＰＵ２０１は、ステップＳ１６０２で得られた量子化後のＤＣＴ係数をエントロピー符号化する。ステップＳ１６０４にて、ＣＰＵ２０１は、ステップＳ１６０１で保存した量子化前の輝度のＤＣＴ係数と、ステップＳ１６０３で得られた逆量子化後の輝度のＤＣＴ係数を、マクロブロックの６４個の係数についてそれぞれ差分値を算出する。そして、ステップＳ１６０５にて、ＣＰＵ２０１は、ステップＳ１６０４で得られた６４個の差分値のうち、その絶対値があらかじめ決められたＴｈ＿ｄｃ以上の係数の数Ｋをカウントする。本実施形態では、Ｔｈ＿ｄｃ＝６４とする。ステップＳ１６０６にて、ＣＰＵ２０１は、ステップＳ１６０５で得られたＫと、あらかじめ決められた値Ｔｈ＿ｄｉｆｆを比較する。本実施形態では、Ｔｈ＿ｄｉｆｆ＝３２とする。ＫがＴｈ＿ｄｉｆｆより大きければ、ＣＰＵ２０１は、このマクロブロックにおける量子化前後のＤＣＴ係数の差異が大きいと判断し、処理をステップＳ１６０７に進め、ローカルデコードする。そうでなければ、ローカルデコードをせずにこのフローを終了する。すなわち、１マクロブロックの半数以上のＤＣＴ係数が量子化により、Ｔｈ＿ｄｃ＝６４以上の差が出る場合には、ローカルデコードすることになる。
【００８５】
ステップＳ１６０７にて、ＣＰＵ２０１は、ステップＳ１６０２で得られた量子化後のＤＣＴ係数を逆量子化する。輝度Ｙに関してはステップＳ１６０３で逆量子化されているので、ここでは色差のＣｂ、Ｃｒだけ逆量子化すれば良い。ステップＳ３１２にて、ＣＰＵ２０１は、逆色変換をして、線形ＬＤＲ画像を得る。ステップＳ８０４にて、ＣＰＵ２０１は、マクロブロックの線形ＬＤＲ画像を、ローカルデコードして得られたＬＤＲ画像で上書きして、このフローを終了する。
【００８６】
本第５の実施形態によれば、すべてのＤＣＴ係数に対して量子化前後の値を比較することから、計算コストが大きくなる。しかし、ＬＤＲ画像の符号化による劣化の度合いを見ることができるため、劣化が大きいところは確実にローカルデコードした画像を使ってＨＤＲ補助データを作成することができることになる。
【００８７】
［第５の実施形態の変形例］
上記第５の実施形態では、一律にすべてのＤＣＴ係数を比較し、ローカルデコードをする／しないを切り替えたが、ＬＤＲ画像の符号化条件であるＱパラメータによって、比較するＤＣＴ係数の数およびＴｈ＿ｄｉｆｆを切り替えてもよい。たとえば、Ｔｈ＿ｄｉｆｆは比較するＤＣＴ係数の半数とすればよい。図１７にＤＣＴ係数を模式的に示す。左上隅がＤＣ成分であり、右下がＡＣ成分であるとする。ＬＤＲ画像のＱパラメータが大きい場合は、図１７の符号１７０１で示す、高周波側のＤＣＴ係数６個のみを比較する。逆にＬＤＲ画像のＱパラメータが小さい場合は、図１７の符号１７０１〜１７０４を合わせた４３個のＤＣＴ係数を比較対象とする。
【００８８】
本変形例の処理フローを図１８に示す。なお、図１６と同じ処理をするステップには、図１６と同じ番号を付与し、その説明は省略する。
【００８９】
ステップＳ８０１にて、ＣＰＵ２０１は、マクロブロック単位の線形ＬＤＲ画像を作成する。ステップＳ３０７にて、ＣＰＵ２０１は、ステップＳ８０１で作成した線形ＬＤＲ画像の色変換を行う。ステップＳ１６０１にて、ＣＰＵ２０１は、色変換後のＬＤＲ画像にＤＣＴをかけ、その輝度の係数をメモリ２０６に保存する。ステップＳ１６０２にて、ＣＰＵ２０１は、ＬＤＲ画像のＱパラメータに応じて、ＤＣＴ係数の量子化を行う。ステップＳ３０９にて、ＣＰＵ２０１はエントロピー符号化を行う。ステップＳ１８０１にて、ＣＰＵ２０１は、ＬＤＲ画像のＱパラメータが１０以上であるか判定する。１０以上であれば、ステップＳ１８０２へ進む。１０未満であれば、ＣＰＵ２０１は、量子化による差異が大きい（量子化ステップが大きい）と判断し、ステップＳ１６０７へ処理を進め、ローカルデコード処理を実行する。ステップＳ１７０２にて、ＣＰＵ２０１は、ＬＤＲ画像のＱパラメータが９０未満であるか判定する。９０未満であれば、ＣＰＵ２０１はステップＳ１８０３へ処理を進める。また、９０以上であれば、ＣＰＵ２０１は、量子化による差異は小さいと判断し、ローカルデコードは行わず、この処理フローを終了する。ステップＳ１８０３にて、ＣＰＵ２０１は、Ｑパラメータに応じた比較対象となるＤＣＴ係数の数と、しきい値Ｔｈ＿ｄｉｆｆを取得する。本実施形態では以下のような値を取得するものとする。
（１） Ｑが７０以上９０未満の場合
比較対象のＤＣＴ係数は、図１７の１７０１で示す６係数
Ｔｈ＿ｄｉｆｆ＝３
（２） Ｑが５０以上７０未満の場合
比較対象のＤＣＴ係数は、図１７の１７０１および１７０２で示す１５係数
Ｔｈ＿ｄｉｆｆ＝８
（３） Ｑが３０以上５０未満の場合
比較対象のＤＣＴ係数は、図１７の１７０１〜１７０３で示す２８係数
Ｔｈ＿ｄｉｆｆ＝１４
（４） Ｑが１０以上３０未満の場合
比較対象のＤＣＴ係数は、図１７の１７０１〜１７０４で示す４３係数
Ｔｈ＿ｄｉｆｆ＝２２
次に、ＣＰＵ２０１は、処理をステップＳ１６０３に進める。このステップＳ１６０３以降は第５の実施形態と同様の処理であるので、ここでの説明は省略する。
【００９０】
（その他の実施例）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００９１】
２０１…ＣＰＵ、２０２…入力部、２０３…ＨＤＲ補助データ生成部、２０４…ＬＤＲ画像生成部、２０５…ＪＰＥＧコーデック部、２０６…メモリ、２０７…表示部、２０８…蓄積部
【図１Ａ】
2018067758.tif 000003
【図１Ｂ】
2018067758.tif 000004
【図２】
2018067758.tif 000005
【図３】
2018067758.tif 000006
【図４】
2018067758.tif 000007
【図５】
2018067758.tif 000008
【図６】
2018067758.tif 000009
【図７】
2018067758.tif 000010
【図８】
2018067758.tif 000011
【図９】
2018067758.tif 000012
【図１０】
2018067758.tif 000013
【図１１】
2018067758.tif 000014
【図１２】
2018067758.tif 000015
【図１３】
2018067758.tif 000016
【図１４】
2018067758.tif 000017
【図１５】
2018067758.tif 000018
【図１６】
2018067758.tif 000019
【図１７】
2018067758.tif 000020
【図１８】
2018067758.tif 000021