JP5231529B2 - ビデオカメラ - Google Patents

Description

本発明は、デジタルカメラ（たとえば、静止画あるいは動画をキャプチャするためのもの）に関し、より具体的には、画像データを圧縮するデジタルカメラに関する。

デジタルビデオカメラの有用性にも関わらず、映画（ｍａｊｏｒ ｍｏｔｉｏｎ ｐｉｃｔｕｒｅ）および一部のテレビ放送の製作者は、フィルムカメラを信頼し続けている。これらにおいて使用されているフィルムは、ビデオの編集者に対し、従来の手段によって編集することの可能な、非常に高い解像度の画像を提供する。しかしながら、最近では、多くの場合、このようなフィルムは、スキャンされ、デジタル化されて、デジタル的に編集される。

現在の市販されているデジタルビデオカメラは、高解像度の画像センサを有しており、したがって、高解像度のビデオを出力するが、このようなカメラに搭載され使用されている画像の処理および圧縮の技術は、劣化が大きすぎるとともに、あまりにも多くの生（未加工）画像データを削除しているので、上述した市場のハイエンド部門においては受け入れられないものである。ここに開示されている少なくとも１つの実施形態における態様は、上述した市場におけるよりハイエンドの部門（たとえば映画市場）に受け入れられるビデオ品質を、１秒ごとに少なくとも約２３フレームのフレームレートで、少なくとも約２ｋの解像度を有する生の（あるいは実質的に生の）ビデオデータをキャプチャして保存するカメラによって、満足することが可能である、という事実の実現を含んでいる。

したがって、実施形態にしたがうと、ビデオカメラは、携帯可能な筐体と、この筐体によって保持されているとともに、光の焦点を合わせるように構成されているレンズアセンブリと、を備えることが可能である。感光デバイスについては、焦点光を、１秒ごとに少なくとも約２３フレームのフレームレートで、少なくとも２ｋの解像度を有する生画像データに変換するように、構成することが可能である。このカメラは、また、メモリ素子、および画像処理システムを含むことが可能である。この画像処理システムは、少なくとも６対１の圧縮比で、かつ、視覚的にほぼ劣化のない状態を保ちながら、１秒ごとに少なくとも約２３フレームのレートで、生画像データを圧縮してメモリ素子に保存するように構成されている。

他の実施形態にしたがうと、カメラによって動画ビデオを記録する方法は、感光デバイスに光を案内するステップを含むことが可能である。この方法は、さらに、感光デバイスによって受光された光を、１秒ごとに少なくとも２３フレームよりも大きいレートで、生のデジタル画像データに変換するステップと、この生のデジタル画像データを圧縮するステップと、この生画像データを、１秒ごとに少なくとも約２３フレームのレートで、保存デバイスに記録するステップと、を含むことも可能である。

さらに他の実施形態にしたがうと、ビデオカメラは、筐体によって保持されているとともに、光の焦点を合わせるように構成されているレンズアセンブリと、焦点光を、この焦点光を示す生画像データの信号に変換するように構成されている感光デバイスと、を備えることが可能である。このカメラは、さらに、メモリ素子と、１秒ごとに少なくとも約２３フレームのフレームレートで、生画像データを圧縮して記録するための手段と、を備えることも可能である。

さらに他の実施形態にしたがうと、ビデオカメラは、このカメラのビデオ記録動作の際における、筐体の動きにおける少なくとも１度に関する方向を、ユーザが操作することを可能とするように構成された、少なくとも１つのハンドルを有する、携帯可能な筐体を備えることが可能である。レンズアセンブリは、この筐体によって保持されているとともに、この筐体の内部に配置された平面において光の焦点を合わせるように構成されている、少なくとも１つのレンズを備えることが可能である。感光デバイスは、１秒ごとに少なくとも約２３フレームのフレームレートで、焦点光を、少なくとも２ｋの水平解像度を有する生画像データに変換するように、構成されることが可能である。メモリ素子は、ビデオ画像データを保存するように、構成されることが可能である。画像処理システムは、少なくとも６対１の圧縮比で、かつ、視覚的にほぼ劣化のない状態を保ちながら、１秒ごとに少なくとも約２３フレームのレートで、生画像データを圧縮してメモリ素子に保存するように、構成されることが可能である。

ここに開示されている本発明における少なくとも１つの他の態様は、以下の事実の実現を含んでいる。すなわち、人間の目は、他のいずれの色に比べても、緑色の波長に対してより敏感であり、そのため、画像センサから出力された画像データに対する、緑色画像データに基づいた修正を、データの圧縮率を高めるため、なおかつ、より高い品質のビデオ画像を与えるために、使用することが可能である。という事実である。このような技術の１つは、データを圧縮する前に、検出された赤色および／または青色の光の大きさから、検出された緑色光の大きさを差し引くステップを含むことが可能である。これにより、赤色および／または青色画像データを、より圧縮しやすい形態に変換することができる。たとえば、ガンマ補正されたＲＧＢデータを、Ｙ’ＣｂＣｒに変換するための既知の処理においては、画像は「相関性を失う（ｄｅｃｏｒｒｅｌａｔｅｄ）」。この場合、Ｙ’（「ｌｕｍａ」としても知られている）の画像データのほとんどが放置され、さらに、残りの彩度成分は、より圧縮しやすくなっている。しかしながら、Ｙ’ＣｂＣｒフォーマットに変換するための、この既知の技術については、ベイヤ（Ｂａｙｅｒ）パターンデータに対して直接的に適用することはできない。なぜならば、個々の色データが、空間的な相関性を有していないとともに、ベイヤパターンデータが、青色あるいは赤色の画像データに比べて、２倍の数の緑色画像データを含んでいるからである。ここに開示されている実施形態のいくつかにしたがう、緑色画像データを差し引く処理については、緑色画像データにおけるほとんどの画像データを放置し、残りのデータをより圧縮しやすい形態のままとするという点において、上述したＹ’ＣｂＣｒ変換に類似したものとすることが可能である。

さらに、緑色画像データを差し引く処理を逆進することが可能であり、したがって、全てのオリジナルの生データが維持されている。このため、上記のような技術を組み込んでいる、得られたシステムおよび方法は、上述のようなビデオ画像データにおける、劣化のない（あるいは視覚的に劣化のない）状態、および、強化された圧縮率を与えることが可能である。

したがって、実施形態にしたがうと、ビデオカメラは、筐体によって保持されているとともに、光の焦点を合わせるように構成されているレンズアセンブリと、焦点光を、この焦点光における少なくとも第１、第２および第３の色を示す画像データの生信号に変換するように構成されている感光デバイスと、を有することが可能である。画像処理モジュールは、第３の色の画像データに基づいて、第１および第２の色における少なくとも１つの画像データを修正するように構成されることが可能である。さらに、ビデオカメラは、メモリ素子と、第１、第２および第３の色の画像データを圧縮するように構成されているとともに、圧縮された画像データをメモリ素子に保存するように構成されている圧縮デバイスと、を備えることが可能である。

他の実施形態にしたがうと、画像を処理する方法を与えることが可能である。この方法は、画像を、第１の色を示す第１の画像データ、第２の色を示す第２の画像データ、および、第３の色を示す第３の画像データに変換するステップと、少なくとも第１の画像データおよび第２の画像データを、第３の画像データに基づいて修正するステップと、第３の画像データ、および、修正された第１および第２の画像データを圧縮するステップと、圧縮されたデータを保存するステップと、を含むことが可能である。

さらに他の実施形態にしたがうと、ビデオカメラは、筐体によって保持されているとともに、光の焦点を合わせるように構成されているレンズアセンブリを備えることが可能である。感光デバイスは、焦点光を、この焦点光における少なくとも第１、第２および第３の色を示す画像データの生信号に変換するように構成されることが可能である。このカメラは、さらに、第３の色の画像データに基づいて、第１および第２の色における少なくとも１つの画像データを修正するための手段、メモリ素子、および、圧縮デバイスを備えることも可能である。この圧縮デバイスは、第１、第２および第３の色の画像データを圧縮するように構成されているとともに、圧縮された画像データをメモリ素子に保存するように構成されている。

実施形態にしたがうビデオ画像データを処理するためのハードウェアを備えることの可能な、および／または、この処理のための方法を実行するように構成されることの可能な、システムを示すブロック図である。

図１において概略的に示されているカメラのための筐体における、任意的な実施形態を示す図である。

図１に示されているシステムによって用いられることの可能なベイヤパターンフィルタを有する、画像センサの配置図である。

図１に示されているシステムによって用いられることの可能な画像処理モジュールにおける、概略的なブロック図である。

図３に示した画像センサにおける緑色センサセルからの、緑色画像データの配置図である。

オリジナルの緑色画像データの一部を消去するという任意的な処理を経た後の、残存している緑色画像データ（図５）の配置図である。

図１に示した画像処理モジュールにおける処理のために整理された、赤色、青色および緑色の画像データ（図５）の配置図である。

図１に示したシステムによって使用することの可能な画像データ変換技術を示す、フローチャートである。

同様に図１に示したシステムによって使用することの可能な、図８の画像データ変換技術の修正形を示すフローチャートである。

図８の画像変換処理から得られる、青色画像データの配置図である。

図８の画像変換処理から得られる、赤色画像データの配置図である。

ガンマ補正のために画像データに適用することの可能な、任意的な変換の典型例を示す図である。

画像データを解凍およびモザイク復元するために、図１のシステムによって使用することの可能な、制御ルーチンのフローチャートである。

同様に図１に示したシステムによって使用することの可能な、図１２の制御ルーチンの修正形を示すフローチャートである。

図１２のフローチャートにしたがって解凍されモザイク復元された、緑色画像データの配置図である。

図１２のフローチャートにしたがって解凍されモザイク復元された、図１３からのオリジナルの緑色画像データにおける半分の配置図である。

図１２のフローチャートにしたがって解凍された、青色画像データの配置図である。

図１２のフローチャートにしたがってモザイク復元された、図１５の青色画像データの配置図である。

〔実施形態の詳細な説明〕
図１は、画像を検知、処理および圧縮するモジュールを有するカメラの概略図であり、これは、動画用のビデオカメラを前提として示されている。ここに開示されている実施形態は、ベイヤパターンフィルタを備えた単一のセンサデバイスを有するビデオカメラを前提として、示されている。これは、これらの実施形態が、この場合に格別の有用性を有するからである。しかしながら、ここに示されている実施形態および発明については、他のタイプの画像センサ（例えば、ＣＭＹベイヤ、および、他の非ベイヤパターン）、他の数の画像センサを有するカメラ、異なる画像フォーマットタイプに作用するカメラ、および、静止画および／または動画用に構成されているカメラにも、適用することが可能である。したがって、ここに開示されている実施形態は、典型例であるが非限定的な実施形態であり、また、ここに開示されている本発明は、開示されている典型的な実施形態に限定されるものではない、ということが理解されるべきである。

引き続き図１を参照すると、カメラ１０は、システム１４を保持するように構成された、本体すなわち筐体１２を備えることが可能である。システム１４は、ビデオ画像データを検出、処理、および、選択的に、保存および／または再生するように構成されている。例えば、システム１４は、光学ハードウェア１６、画像センサ１８、画像処理モジュール２０、圧縮モジュール２２、および保存デバイス２４を備えることが可能である。任意的に、カメラ１０は、さらに、モニタモジュール２６、再生モジュール２８、およびディスプレイ３０を備えることも可能である。

図２は、カメラ１０における、非限定的で典型的な実施形態を示している。図２に示されているように、光学ハードウェア１６は、その外表面をむき出しにしたままの状態で、筐体１２によって保持されることが可能である。実施形態によっては、システム１４は、筐体１２内に保持されている。たとえば、画像センサ１８、画像処理モジュール２０および圧縮モジュール２２を、筐体１２内に収納することが可能である。保存デバイス２４については、筐体１２内に取り付けることが可能である。さらに、実施形態によっては、保存デバイス２４を、筐体１２の外面に取り付けて、さらに、システム１４における残存部分に対して、任意のタイプのコネクタあるいはケーブルによって接続することが可能である。さらに、フレキシブルケーブルによって、保存デバイス２４を筐体１２に接続することが可能である。このため、保存デバイス２４を、筐体１２から独立した状態で、いくらか動かすことが可能である。たとえば、このようなフレキシブルケーブルによる接続によって、保存デバイス２４を、ユーザのベルトに装着することが可能である。これにより、筐体１２の全体的な重量を減少することが可能となる。また、実施形態によっては、筐体は、内蔵される、および外面に取り付けられる、１つあるいは複数の保存デバイス２４を備えることが可能である。さらに、筐体１２は、モニタモジュール２６およびモジュール２８を保持することも可能である。さらに、実施形態によっては、ディスプレイ３０を、筐体１２の外面に取り付けられるように構成することも可能である。

光学ハードウェア１６については、入射してくる画像の焦点を画像センサ１８に合わせるように構成された少なくとも１つのレンズを有する、レンズシステムの形状とすることが可能である。任意的に、光学ハードウェア１６を、可変のズーム、開口および焦点を与えるマルチレンズシステムの形状とすることが可能である。さらに、光学ハードウェア１６を、筐体１２によって保持され、複数の異なるタイプのレンズシステムを受け入れるように構成された、レンズソケットの形状とすることも可能である。たとえば、光学ハードウェア１６は、さまざまなサイズのレンズシステムを受け入れるように構成されており、その例としては（これらに限定されるわけではないが）、５０−１００ミリメートル（Ｆ２．８）ズームレンズ、１８−５０ミリメートル（Ｆ２．８）ズームレンズ、３００ミリメートル（Ｆ２．８）レンズ、１５ミリメートル（Ｆ２．８）レンズ、２５ミリメートル（Ｆ１．９）レンズ、３５ミリメートル（Ｆ１．９）レンズ、５０ミリメートル（Ｆ１．９）レンズ、８５ミリメートル（Ｆ１．９）レンズ、および／または他の任意のレンズ、を挙げられる。上述したように、光学ハードウェア１６を、それに取り付けられるレンズがどれであるかに関わらず、画像センサ１８の感光面上に画像の焦点を合わせるように、構成することが可能である。

画像センサ１８については、任意のタイプのビデオ検知デバイスとすることが可能であり、その例としては、たとえば（これらに限定されるわけではないが）、フェビオン（Ｆｏｖｅｏｎ；登録商標）センサなどの垂直積層型のＣＭＯＳ、ＣＣＤ、ＣＭＯＳ、あるいは、センサ間で光を分割するためのプリズムを使用しているマルチセンサアレイ、を挙げられる。実施形態によっては、画像センサ１８は、約１２００万個の光電セルを有するＣＭＯＳを備えることが可能である。しかしながら、他のサイズのセンサを使用することも可能である。構成によっては、カメラ１０を、「２ｋ（たとえば、２０４８×１１５２画素）」、「４ｋ（たとえば、４０９６×２５４０画素）」、「４．５ｋ」の水平解像度（すなわち大きい方の解像度）によってビデオを出力するように構成することも可能である。ここで使用されている、ｘｋ（たとえば、上述した２ｋおよび４ｋなど）というフォーマットにおいて表現されている用語における、数値「ｘ」は、概算の水平解像度に言及している。したがって、解像度「４ｋ」は、約４０００以上の水平画素に対応している一方、「２ｋ」は、約２０００以上の画素に対応している。現在において市販されているハードウェアを用いることによって、このセンサを、約０．５インチ（８ｍｍ）ほどに小さくすることが可能であるが、それを、約１．０インチあるいはそれ以上の大きさとすることも可能である。さらに、画像センサ１８を、このセンサ１８における所定の部分だけを選択的に出力することによって、変更可能な解像度を与えるように構成することも可能である。たとえば、画像データ出力の解像度をユーザによって特定することが可能となるように、センサ１８および／または画像処理モジュールを構成することも可能である。

カメラ１０については、２Ｋ、１０８０ｐ、７２０ｐ、あるいは他の任意の解像度でビデオ出力を生成するために、センサ１８の出力をダウンサンプルし、その後に処理するように構成することも可能である。たとえば、センサ１８からの画像データを、「ウィンドウ表示（ｗｉｎｄｏｗｅｄ）」とすることが可能であり、これにより、出力画像のサイズを減少することが可能となるとともに、より高い読み出し速度が可能となる。しかしながら、他のサイズのセンサを使用することも可能である。さらに、より高い解像度でビデオ出力を生成するために、カメラ１０を、センサ１８の出力をアップサンプルするように構成することも可能である。

図１および図３を参照すると、実施形態によっては、センサ１８は、ベイヤパターンフィルタを備えることが可能である。この場合、センサ１８は、そのチップセット（図示せず）を介して、画像センサ１８における個別の光電セルによって検出された赤色光、緑色光あるいは青色光の大きさを示すデータを出力する。図３は、センサ１８のベイヤパターンを概略的に示している。実施形態によっては、たとえば、図３に示されているように、ベイヤパターンフィルタは、赤色素子の数および青色素子の数における２倍の数の緑色素子を有している。画像センサ１８のチップセットについては、画像センサの各素子における電荷を読み取り、そして、よく知られているＲＧＢフォーマットの出力における一連の値を出力するために、使用することが可能である。

引き続き図４を参照すると、画像処理モジュール２０については、画像センサ１８からのデータ流を、任意の既知の方法によってフォーマットするように、任意的に構成することが可能である。実施形態によっては、緑色、赤色および青色の画像データを、３つあるいは４つに分離されたデータ編集に分離するように、画像処理モジュール２０を構成することが可能である。たとえば、画像処理モジュール２０を、赤色データを１つのデータ素子に、青色データを１つの青色データ素子に、さらに、緑色データを１つの緑色データ素子に分離するように、構成することも可能である。たとえば、図４を参照すると、画像処理モジュール２０は、赤色データ処理モジュール３２、青色データ画像処理モジュール３４、および、第１緑色画像データ処理モジュール３６を備えることが可能である。

しかしながら、上述したように、図３に示したベイヤパターンデータは、他の２色に比して２倍の数の緑色画素を有している。図５は、青色および赤色データを除去し、オリジナルの緑色画像データだけを残したデータ成分を示している。

実施形態によっては、カメラ１０を、緑色画像データの一部を消去あるいは省略するように構成することが可能である。たとえば、実施形態によっては、画像処理モジュール２０を、緑色画像データの全体量が青色および赤色の画像データの量と同様となるように、緑色画像データの１／２を消去するように構成することが可能である。たとえば、図６は、画像処理モジュール２０が緑色画像データの１／２を消去した後における、残存しているデータを示している。図６の実施形態に示されているように、行ｎ−３、ｎ−１、ｎ＋１、およびｎ＋３が消去されている。これは、消去することの可能な緑色画像データのパターンにおける、単なる一例にすぎない。緑色画像データにおける他のパターンおよび他の量を、消去することも可能である。

代替的な構成によっては、赤色および青色の画像データが緑色画像データに基づいて変換された後に、緑色画像データの１／２を消去するように、カメラ１０を構成することも可能である。この任意的な技術については、他の色の画像データから緑色画像データの値を差し引くことに関する記述の後に、説明される。

任意的に、画像処理モジュール２０を、緑色画像データを選択的に消去するように、構成することも可能である。たとえば、画像処理モジュール２０は、消去すべき緑色画像データを選択的に決定するように構成された、消去分析（ｄｅｌｅｔｉｏｎ ａｎａｌｙｓｉｓ）モジュール（図示せず）を備えることが可能である。たとえば、このような消去モジュールを、緑色画像データから行パターンを消去することが、エイリアシングアーチファクト（たとえば、モアレ線、あるいは他の視覚的に認識できるアーチファクト）を招来することになるか否か、を判断するように、構成することが可能である。さらに、この消去モジュールを、消去すべき緑色画像データのパターン（上述のようなアーチファクトを形成するリスクを、より小さくすることになるパターン）を選択するように、構成することも可能である。たとえば、この消去モジュールを、画像センサ１８によってキャプチャされた画像が、複数の平行な水平ラインによって特徴づけられている画像形状（ｉｍａｇｅ ｆｅａｔｕｒｅ）を有している、と判断した場合に、１つおきの縦列からなる緑色画像データ消去パターンを選択するように構成することも可能である。この消去パターンは、モアレ線などのアーチファクト（画像において検出される水平ラインと平行な画像データのラインを１つおきに消去するパターンによって、招来される可能性があるもの）を減少あるいは除去することが可能である。

しかしながら、これは、消去モジュールによって使用することの可能な消去パターンおよび画像形状のタイプにおける、１つの典型的で非限定的な例にすぎない。消去モジュールについては、他の画像形状を検出するように、および、他の画像データ消去パターンを使用するように、構成することも可能である。他の画像データ消去パターンとしては、たとえば（これらに限定されるわけではないが）、１つおきの列、１つおきの対角線、あるいは他のパターンの消去を挙げられる。さらに、消去モジュールを、他の画像データ（たとえば、赤色および青色の画像データ、あるいは、使用されているセンサのタイプに応じた他の画像データ）の一部を消去するように、構成することも可能である。

さらに、カメラ１０を、どの画像データが消去されたのかを示すデータフィールドを画像データに挿入するように、構成することも可能である。たとえば（これに限定されるわけではないが）、カメラ１０を、保存デバイス２４に保存されている任意のビデオクリップの冒頭にデータフィールド（ビデオクリップにおける「フレーム」のそれぞれにおいて、どのデータが消去されたのか、を示すもの）を挿入するように、構成することが可能である。実施形態によっては、画像センサ１８によってキャプチャされた各フレームに、どの画像データが消去されたのかを示すデータフィールドを挿入するように、カメラを構成することも可能である。たとえば、実施形態によっては、画像処理モジュール２０が、ある消去パターンにおいて緑色画像データの１／２を消去するように構成されている場合、データフィールドを、シングルビットのデータフィールドと同程度に小さくすることが可能である。この場合、データフィールドは、画像データが消去されたか否かを示す。画像処理モジュール２０が、１つだけのパターンにおいてデータを消去するように構成されているため、シングルビットは、どのデータが消去されたのかを示すのに十分である。

実施形態によっては、上述したように、画像処理モジュール２０を、１つより多いパターンによって、画像データを選択的に消去するように構成することが可能である。このため、画像データ消去フィールドを、より大きくすることが可能であり、これは、複数の異なる画像データ消去パターンのどれが使用されたのかについての表示を与えるために十分な数の値を含んでいる。このデータフィールドについては、あるいは、残存している画像データに対応するのは、どの空間位置であるのかを判断するための下流の部材およびまたはプロセスによって、使用することが可能である。

実施形態によっては、画像処理モジュールを、全ての生の緑色画像データ（たとえば、図５に示されているデータ）を保持するように構成することが可能である。このような実施形態では、画像処理モジュールは、１つあるいは複数の緑色画像データ処理モジュールを備えることが可能である。

上述したように、既知のベイヤパターンフィルタには、赤色素子の数および青色素子の数における２倍の数の緑色素子が存在する。すなわち、赤色素子は、全ベイヤパターンアレイにおける２５％を含んでおり、青色素子は、ベイヤパターンアレイにおける２５％に対応しており、さらに、緑色素子は、ベイヤパターンアレイの素子における５０％を含んでいる。したがって、実施形態によっては、全ての緑色画像データが保持されている場合に、画像処理モジュール２０は、第２の緑色データ画像処理モジュール３８を備えることが可能である。したがって、第１の緑色データ画像処理モジュール３６は、緑色素子の半分を処理することが可能であり、第２の緑色データ画像処理モジュール３８は、残りの緑色素子を処理することが可能である。しかしながら、本発明を、他のタイプのパターン（たとえば（これに限定されるわけではないが）、ＣＭＹおよびＲＧＢＷ）とともに使用することも可能である。

図７は、モジュール３２、３４、３６および３８（図４）によって処理される、赤色データ成分、青色データ成分および２つの緑色データ成分の概略図を含んでいる。これは、さらなる利点を与えることが可能である。なぜならば、これらのモジュールがほぼ同じ量のデータを取り扱っているために、それぞれのモジュールのサイズおよび構成を、ほぼ同様にすることが可能であるからである。さらに、画像処理モジュール２０を、（モジュール３６および３８の双方を利用することによって、）全ての緑色画像データを処理するモードと、緑色画像データの１／２が消去されるモード（このモードでは、モジュール３６および３８の一方のみを利用する）との間において、選択的に切り替えることが可能である。しかしながら、他の構成を使用することも可能である。

さらに、実施形態によっては、画像処理モジュール２０は、他のモジュールを備えることが可能であり、および／または、他の処理（たとえば（これらに限定されるわけではないが）、ガンマ補正処理やノイズ除去処理など）を実行するように構成されることが可能である。

さらに、実施形態によっては、画像処理モジュール２０を、青色素子および／または赤色素子の値から緑色素子の値を差し引くように構成することが可能である。この場合、実施形態によっては、画像センサ１８によって特定の色が消去されたときに、対応する赤色あるいは青色素子をゼロに減らすことが可能である。たとえば、多くの写真においては、黒色、白色あるいは灰色、あるいは、灰色から赤色あるいは青色にシフトした色からなる、大きなエリアが存在する可能性がある。このため、画像センサ１８における対応する画素が灰色のエリアを検知した場合には、緑色、赤色および青色の大きさは、ほぼ等しいはずである。したがって、赤色値および青色値から緑色値が差し引かれた場合には、赤色値および青色値は、ゼロあるいはゼロに近い値にまで落ち込むことになる。このため、その後の圧縮処理において、黒色、白色あるいは灰色のエリアを検知した複数の画素には、複数のゼロが生成されることになり、したがって、得られたデータは、より圧縮しやすくなるはずである。さらに、他の色の一方あるいは双方から緑色を差し引くことにより、得られた画像データを、他の理由によってより圧縮しやすくすることが可能である。

上述したような技術は、より高い有効圧縮比を獲得すること、なおかつ、視覚的に劣化のない状態を保つことを助けることが可能であり、これは、オリジナルの画像データにおけるエントロピーとの関係に起因する。たとえば、画像のエントロピーは、画像における乱雑さの量に関連している。ある色の画像データを、たとえば他の色の画像データから差し引くことは、乱雑さを減少し、したがって、それらの色の画像データにおけるエントロピーを減少する。これにより、劣化の少ない状態で、より高い圧縮比によってデータを圧縮することが可能となる。一般的に、画像は、ランダムな色値の集合ではない。むしろ、多くの場合、周囲の画像素子の間には、ある程度の相互関係がある。このため、上述したような差し引き技術は、よりよい圧縮を得るために、画像素子の相互関係を利用することが可能である。圧縮の量は、少なくとも部分的には、画像におけるオリジナルの情報のエントロピーに依存するはずである。

実施形態によっては、赤色あるいは青色の画素から差し引かれる大きさを、これらの赤色あるいは青色の画素に隣接する緑色画素から出力される値の大きさとすることが可能である。さらに、実施形態によっては、赤色あるいは青色の素子から差し引かれる緑色の大きさを、周囲の緑色素子の平均値から得ることも可能である。このような技術は、以下により詳細に説明されている。しかしながら、他の技術を利用することも可能である。

任意的に、画像処理モジュール２０を、緑色画像データを他の色から選択的に差し引くように構成することも可能である。たとえば、画像処理モジュール２０を、緑色画像データを、他の一方の色における画像データの一部から差し引くことが、よりよい圧縮率を与えることになるか否か、を判断するように構成することが可能である。このモードでは、画像処理モジュール２０を、画像データにフラグを挿入するように構成することが可能である。このフラグは、（たとえば、緑色画像データを差し引くことによって、）画像データにおけるどの部分が修正されているのか、およびどの部分があまり修正されていないのかを示すものである。このようなフラグを用いることによって、下流のモザイク復元（ｄｅｍｏｓａｉｃｉｎｇ）／再構築部材が、選択的に、このデータフラグのステータスに基づいて、緑色画像の値を他の色の画像データに戻すことが可能となる。

任意的に、画像処理モジュール２０は、赤色および青色のデータの値を丸めるように構成された、追加的なデータ整理モジュール（図示せず）を備えることが可能である。たとえば、緑色の大きさを差し引いた後、赤色あるいは青色のデータがゼロに近くなった場合（たとえば、８ビットスケール（０〜２５５の範囲）における、１あるいは２以内、あるいは、より高い解像度のシステムであれば、より大きい値）である。たとえば、センサ１８を、０〜４０９５のスケールの赤色、青色および緑色のデータを出力する、１２ビットのセンサとすることが可能である。データに対するいずれかの丸め処理（ｒｏｕｎｄｉｎｇ）あるいはフィルタリングが実行される場合、丸め処理モジュールを、望ましい効果を得られるように調整することが可能である。たとえば、劣化のない出力を得ることが望まれる場合には、より狭い範囲に対して、また、ある程度の劣化のある出力（あるいは劣化の多い出力）を許容できる場合には、より広い範囲に対して、丸め処理を実行することが可能である。丸め処理には、実行されることが可能であって、かつ、依然として視覚的に劣化のない出力を得ることの可能なものもある。たとえば、８ビットスケールにおいて、２あるいは３以下の絶対値を有する赤色あるいは青色のデータは、０に丸められることが可能であって、かつ、依然として視覚的に劣化のない出力を与えることが可能である。さらに、１２ビットスケールにおいては、１０〜２０以下の絶対値を有する赤色あるいは青色のデータは、０に丸められることが可能であって、かつ、依然として視覚的に劣化のない出力を与えることが可能である。

さらに、ゼロに丸める（あるいは他の値に丸める）ことが可能であって、依然として視覚的に劣化のない出力を与えることの可能な値の大きさは、システムの構成に依存しており、これは、光学ハードウェア１６、画像センサ１８、画像センサの解像度、画像センサ１８の色解像度（ビット）、フィルタリングのタイプ、画像処理モジュール２０によって実行されるアンチエイリアシング技術あるいは他の技術、圧縮モジュール２２によって実行される圧縮技術、および／または、カメラ１０における他のパラメータあるいは特性を含んでいる。

上述したように、実施形態によっては、カメラ１０を、緑色画像データに基づいて赤色および青色の画像データを変換した後に、緑色画像データの１／２を消去するように、構成することが可能である。たとえば（これに限定されるわけではないが）、周囲の緑色データ値の大きさの平均値が赤色および青色のデータ値から差し引かれた後に、緑色画像データの１／２を消去するように、処理モジュール２０を構成することが可能である。この緑色データにおける減少は、関連するハードウェアに対するスループット要求を減らすことが可能である。さらに、残存している緑色画像データを、赤色および青色の画像データを再構築するために使用することが可能である（これについては、図１４および図１６を参照して、後により詳細に説明する）。

上述したように、カメラ１０は、圧縮モジュール２２を備えることも可能である。圧縮モジュール２２は、別体のチップの形状にされることが可能であり、あるいは、ソフトウェアおよび他のプロセッサによって実施されることも可能である。たとえば、圧縮モジュール２２を、ＪＰＥＧ２０００標準あるいは他の圧縮技術にしたがう圧縮技術を実行する、市販の圧縮チップの形状とすることが可能である。

この圧縮モジュールについては、画像処理モジュール２０からのデータに対して、任意のタイプの圧縮処理を実行するように構成することが可能である。実施形態によっては、圧縮モジュール２２は、画像処理モジュール２０によって実行される技術をうまく活用した圧縮技術を実行する。たとえば、上述したように、緑色画像データの大きさを差し引くことによって、赤色および青色のデータの値の大きさを減少するように、画像処理モジュール２０を構成することが可能であり、これにより、他の効果とともに、非常に多くのゼロ値が得られる。さらに、画像処理モジュール２０は、画像データのエントロピーを利用した、生データの操作を実行することが可能である。したがって、圧縮モジュール２２によって実行される圧縮技術を、そこから出力される圧縮データのサイズを減少するために、より多くの一連のゼロの存在によって利益を得るタイプのものとすることが可能である。

さらに、圧縮モジュール２２を、視覚的に劣化のない出力が得られるように、画像処理モジュール２０からの画像データを圧縮するように構成することが可能である。たとえば、第１に、圧縮モジュールを、任意の既知の圧縮技術を利用するように構成することが可能である。この圧縮技術としては、たとえば（これらに限定されるわけではないが）、ＪＰＥＧ２０００、ＭｏｔｉｏｎＪＰＥＧ、ＤＣＴに基づいた任意のコーデック、ＲＧＢ画像データを圧縮するように設計された任意のコーデック、Ｈ．２６４、ＭＰＥＧ４、ハフマン、あるいは他の技術、を挙げられる。

使用されている圧縮技術のタイプに応じて、視覚的に劣化のない出力を与えるために、圧縮技術におけるさまざまなパラメータを設定することが可能である。たとえば、上述した多くの圧縮技術を、異なる圧縮率に調整することが可能である。ここで、解凍時においては、得られる画像は、より低い圧縮率の場合にはより高品質になる一方、より高い圧縮率の場合にはより低品質になる。したがって、圧縮モジュールを、視覚的に劣化のない出力を与える方法によって、画像データを圧縮するように構成することが可能であり、あるいは、視覚的に劣化のない出力を得るためのさまざまなパラメータをユーザが調整することができるように、構成することが可能である。たとえば、圧縮モジュール２２を、約６：１、７：１、８：１、あるいはより大きい圧縮率で画像データを圧縮するように構成することが可能である。実施形態によっては、圧縮モジュール２２を、１２：１、あるいはより高い比率に画像データを圧縮するように構成することが可能である。

さらに、圧縮モジュール２２を、この圧縮モジュール２２によって得られる圧縮比をユーザが調整することができるように、構成することが可能である。たとえば、カメラ１０は、圧縮モジュール２２に圧縮比を変更させるコマンドをユーザが入力することを可能とする、ユーザインターフェイスを備えることが可能である。したがって、実施形態によっては、カメラ１０は、可変圧縮を提供することが可能である。

ここで使用されている「視覚的に劣化のない」という用語は、同じディスプレイ装置においてオリジナルの（圧縮されていない）画像データと並べて比較したときに、目視による画像の検査のみに基づく場合には、当業者が、どちらの画像がオリジナルであるのかを、妥当なレベルの正確性をもって判断することができないような出力を含むことを意図されている。

引き続き図１を参照すると、カメラ１０は、さらに、保存デバイス２４を備えることが可能である。この保存デバイスについては、任意のタイプのデジタル保存装置（たとえば（これらに限定されるわけではないが）、ハードディスク、フラッシュメモリ、あるいは他の任意のタイプのメモリ素子）の形状とすることが可能である。実施形態によっては、保存デバイス２４のサイズを、少なくとも約３０分のビデオ（１２メガの画素解像度、１２ビットの色解像度、および、１秒ごとに６０フレーム）に対応する、圧縮モジュール２２からの画像データを保存するために十分なほどの大きさとすることが可能である。しかしながら、保存デバイス２４は、任意のサイズを有することが可能である。

実施形態によっては、保存デバイス２４を、筐体１２の外面に取り付けることが可能である。さらに、実施形態によっては、保存デバイス２４を、標準的な通信ポートを介して、システム１４における他の部材に接続することが可能である。この通信ポートとしては、たとえば（これに限定されるわけではないが）、ＩＥＥＥ１３９４、ＵＳＢ２．０、ＩＤＥ、ＳＡＴＡなどを挙げられる。さらに、実施形態によっては、保存デバイス２４は、ＲＡＩＤプロトコルの下で動作する、複数のハードドライブを備えることが可能である。しかしながら、任意のタイプの保存デバイスを使用することが可能である。

引き続き図１を参照すると、上述したように、実施形態によっては、システムは、モニタモジュール２６およびディスプレイ装置３０を備えることが可能である。これらは、ユーザが、動作中に画像センサ１８によってキャプチャされたビデオ画像を観ることを可能とするように構成されている。実施形態によっては、画像処理モジュール２０は、モニタモジュール２６に対して解像度の減少された画像データを出力するように構成された、サブサンプリングシステムを備えることが可能である。たとえば、このようなサブサンプリングシステムを、２Ｋ、１０８０ｐ、７２０ｐ、あるいは他の任意の解像度をサポートするビデオ画像データを出力するように、構成することが可能である。実施形態によっては、モザイク復元のために使用されるフィルタを、ダウンサンプリングフィルタリングをも実行するように適合させることも可能である。これにより、ダウンサンプリングおよびフィルタリングを、同時に実行することが可能となる。モニタモジュール２６については、画像処理モジュール２０からのデータに対する任意のタイプのモザイク復元処理を実行するように、構成することが可能である。これにより、モニタモジュール２６は、モザイクの復元された画像データを、ディスプレイ３０に出力することが可能である。

ディスプレイ３０については、任意のタイプのモニタリング装置とすることが可能である。たとえば（これに限定されるわけではないが）、ディスプレイ３０を、筐体１２によって保持された、４インチのＬＣＤパネルとすることが可能である。たとえば、実施形態によっては、ディスプレイ３０を、大幅に調整することの可能なマウントに接続することが可能である。これにより、ディスプレイ３０を、筐体１２に対して任意の位置に調整することが可能となる。その結果、ユーザは、筐体１２に対して任意の角度から、ディスプレイ３０を観ることが可能となる。実施形態によっては、ディスプレイ３０を、任意のタイプのビデオケーブル（たとえば、ＲＧＢあるいはＹＣＣフォーマットのビデオケーブルなど）を介して、モニタモジュールに接続することが可能である。

任意的に、再生モジュール２８を、保存デバイス２４からのデータを受信し、画像データを解凍してモザイクを復元し、さらに、画像データをディスプレイ３０に出力するように構成することも可能である。実施形態によっては、モニタモジュール２６および再生モジュール２８を、中間的なディスプレイコントローラ（図示せず）を介して、ディスプレイに接続することが可能である。この場合、ディスプレイ３０を、ディスプレイコントローラに対して、１つのコネクタによって接続することが可能である。このディスプレイコントローラを、モニタモジュール２６あるいは再生モジュール２８のいずれか一方からディスプレイ３０に対して、データを転送するように構成することが可能である。

図８は、カメラ１０による画像データの処理を示す、フローチャート５０を含んでいる。実施形態によっては、フローチャート５０は、カメラ１０内の保存デバイス２４あるいは他の保存デバイス（図示せず）などのメモリ素子内に保存されている、制御ルーチンを示すことが可能である。さらに、中央処理装置（ＣＰＵ；図示せず）を、この制御ルーチンを実行するように構成することが可能である。以下に示すフローチャート５０に対応する方法の説明は、ビデオ画像データにおける単一のフレームに対する処理を前提として記述されている。したがって、この技術を、単一の静止画像に対する処理に応用することが可能である。これらの処理については、また、連続的なビデオに対する処理にも応用することが可能である。このようなビデオとしては、たとえば、１２よりも大きいフレームレート、および、２０、２３．９７６、２４、３０、６０および１２０のフレームレート、あるいは、これらのフレームレートの間にある（あるいは、これらよりも大きい）他のフレームレートのものを挙げられる。

引き続き図８を参照すると、制御ルーチンは、動作ブロック５２においてスタートすることが可能である。この動作ブロック５２では、カメラ１０は、センサデータを得ることが可能である。たとえば、図１を参照すると、ベイヤセンサおよびチップセットを備えることの可能な画像センサ１８が、画像データを出力することが可能である。

たとえば（これに限定されるわけではないが）、図３を参照すると、画像センサは、ベイヤパターンフィルタをその受光面に有する、ＣＭＯＳを備えることが可能である。したがって、光学ハードウェア１６からの焦点画像は、画像センサ１８におけるＣＭＯＳ上のベイヤパターンフィルタ上に、焦点を合わせられる。図３は、ＣＭＯＳ上のベイヤパターンフィルタの配列によって生成される、ベイヤパターンの例を示している。

図３では、列ｍが、ベイヤパターンの左端から４番目の列であり、また、行ｎが、このパターンの上端から４番目の行である。残りの列および行は、行ｍおよび列ｎに関連するラベルが付されている。しかしながら、この配置は、例示の目的のために適宜に選択されているにすぎず、ここに記載されている実施形態あるいは発明を何ら限定するものではない。

上述したように、既知のベイヤパターンフィルタは、多くの場合、青色および赤色の素子に比べて２倍の数の緑色素子を備えている。図５に示したパターンでは、青色素子は、行ｎ−３、ｎ−１、ｎ＋１、およびｎ＋３だけに出現している。赤色素子は、行ｎ−２、ｎ、ｎ＋２、およびｎ＋４だけに出現している。しかしながら、緑色素子は、全ての行および列に出現しており、そこに赤色および青色の素子が組み入れられている。

したがって、動作ブロック５２では、画像センサ１８から出力された赤色、青色および緑色の画像データを、画像処理モジュール２０によって受信することが可能であるとともに、図７に示されているように、個別の色データ成分に整理することが可能である。図７に示されているように、および、図４に関連して上述したように、画像処理モジュール２０は、赤色、青色および緑色の画像データを、４つの個別の成分に分離することが可能である。図７は、２つの緑色成分（緑色１および緑色２）、１つの青色成分、および、１つの赤色成分を示している。しかしながら、これは、画像センサ１８からの画像データの処理における、１つの典型的な方法にすぎない。さらに、上述したように、任意的に、画像処理モジュール２０は、緑色画像データの１／２を、適宜的あるいは選択的に消去することが可能である。

動作ブロック５２の後、フローチャート５０は、動作ブロック５４に進むことが可能となる。動作ブロック５６では、画像データを、さらに処理することが可能である。たとえば、任意的に、得られたデータのいずれか１つあるいは全て（たとえば、緑色１、緑色２、図９からの青色画像データ、および、図１０からの赤色画像データ）を、さらに処理することが可能である。

たとえば、画像データを、プリエンファシス（予め強調処理）する、あるいは他の方法で処理することが可能である。実施形態によっては、画像データを、より（数学的に）非線形となるように処理することが可能である。圧縮アルゴリズムのなかには、圧縮の前に、画像素子に対するこのような線形近似を実行することが有益となるものもある。しかしながら、他の技術を使用することも可能である。たとえば、本質的に強調を与えない線形曲線によって、画像データを処理することも可能である。

実施形態によっては、動作ブロック５４は、ｙ＝ｘ＾０．５という関数によって規定される曲線を利用して、画像データを処理することも可能である。実施形態によっては、画像データが、たとえば（これに限定されるわけではないが）、規格化された０〜１の範囲にある浮動小数点データであった場合に、上記の曲線を使用することが可能である。他の実施形態では、たとえば、画像データが１２ビットのデータである場合、ｙ＝（ｘ／４０９５）＾０．５という曲線を用いて、画像を処理することが可能である。さらに、たとえばｙ＝（ｘ＋ｃ）＾ｇなどの他の曲線を用いて、画像データを処理することが可能である。なお、上記の式において、０．０１＜ｇ＜１であり、また、ｃは、オフセットであって、実施形態によっては０とすることが可能である。さらに、対数曲線を使用することも可能である。たとえば、ｙ＝Ａ^＊ｌｏｇ（Ｂ^＊ｘ＋Ｃ）という形の曲線などであり、Ａ、ＢおよびＣは、所望の結果を与えるために選ばれた定数である。さらに、上述した曲線および処理を、より線形のエリアを黒色の近くに与えるように修正することが可能であり、これは、よく知られているＲｅｃ７０９ガンマ曲線において利用されている技術と同様のものである。これらの処理を画像データに適用する際には、全ての画像データに同じ処理を適用することも可能であり、また、画像データにおける異なる色に対して異なる処理を適用することも可能である。しかしながら、これらは、画像データを処理するために使用することの可能な典型的な曲線にすぎず、あるいは、曲線あるいは変換を使用することも可能である。さらに、これらの処理技術を、上述したような数学的な関数、あるいは、ルックアップテーブル（ＬＵＴ）を利用することによって、適用することも可能である。さらに、異なるタイプの画像データ、画像データの記録中に使用される異なるＩＳＯ設定、温度（ノイズレベルに影響する可能性がある）などに関して、異なる処理、技術あるいは変換を使用することも可能である。

動作ブロック５４の後、フローチャート５０は、動作ブロック５６に移動することが可能となる。この動作ブロック５６では、赤色および青色の画像素子を変換することが可能である。たとえば、上述したように、青色および赤色の画像データ成分のそれぞれから、緑色画像データを差し引くことが可能である。実施形態によっては、赤色あるいは青色の画像素子に隣接する少なくとも１つの緑色画像素子における緑色画像データ値を差し引くことによって、赤色あるいは青色の画像データ値を変換することが可能である。実施形態によっては、赤色あるいは青色の画像データ値から、複数の隣接する緑色画像素子のデータ値における平均値を差し引くことが可能である。たとえば（これらに限定されるわけではないが）、２個、３個、４個、あるいはそれより多くの緑色画像データ値の平均値を算出し、その緑色画像素子の近傍にある赤色あるいは青色の画像素子から差し引くことが可能である。

たとえば（これに限定されるわけではないが）、図３を参照すると、赤色素子Ｒ_{ｍ−２，ｎ−２}に関する生出力は、４つの緑色画像素子Ｇ_{ｍ−２，ｎ−３}、Ｇ_{ｍ−１，ｎ−２}、Ｇ_{ｍ−３，ｎ−２}、および、Ｇ_{ｍ−２，ｎ−１}に囲まれている。したがって、この赤色素子Ｒ_{ｍ−２，ｎ−２}については、それを取り囲んでいる緑色素子の値の平均値を差し引くことによって、以下のように変換することが可能である。
（１）Ｒ_ｍ，ｎ＝Ｒ_ｍ，ｎ−（Ｇ_{ｍ，ｎ−１}＋Ｇ_{ｍ＋１，ｎ}＋Ｇ_{ｍ，ｎ＋１}＋Ｇ_{ｍ−１，ｎ}）／４

同様に、青色素子についても、それを取り囲んでいる緑色素子の平均値を差し引くことによって、同様の方法で以下のように変換することが可能である。
（２）Ｂ_{ｍ＋１，ｎ＋１}＝Ｂ_{ｍ＋１，ｎ＋１}−（Ｇ_{ｍ＋１，ｎ}＋Ｇ_{ｍ＋２，ｎ＋１}＋Ｇ_{ｍ＋１，ｎ＋２}＋Ｇ_{ｍ，ｎ＋１}）／４

図９は、得られた青色データ成分を示している。この図では、オリジナルの青色生データＢ_{ｍ−１，ｎ−１}が変換されており、新しい値にＢ’_{ｍ−１，ｎ−１}がラベリングされている（成分における１つの値だけが書き込まれており、全ての青色素子に関して、同じ技術を使用することが可能である）。同様に、図１０は、変換された赤色データ成分を示している。この図では、変換された赤色素子Ｒ_{ｍ−２，ｎ−２}が、Ｒ’_{ｍ−２，ｎ−２}として特定されている。この状態では、画像データを、まだ「生」データであると考えることが可能である。たとえば、このデータに対して実行される数学的な処理は、完全に可逆的であり、このため、これらの処理を逆進することによって、オリジナルの値の全てを得ることが可能である。

引き続き図８を参照すると、動作ブロック５６の後、フローチャート５０は、動作ブロック５８に進むことが可能である。動作ブロック５８では、得られたデータ（生データ、あるいは実質的に生といえるデータ）を、任意の既知の圧縮アルゴリズムを使用することによって、さらに圧縮することが可能である。たとえば、圧縮モジュール２２（図１）を、このような圧縮アルゴリズムを実行するように構成することが可能である。圧縮の後、圧縮された生データを、保存デバイス２４（図１）に保存することが可能である。

図８Ａは、フローチャート５０の修正形（参照番号５０’によって特定されている）を示している。フローチャート５０に関連して上述したステップのいくつかは、フローチャート５０’における対応するステップと類似あるいは同一であり、このため、これらは、同じ参照番号によって特定されている。

図８Ａに示すように、フローチャート５０’は、実施形態によっては、任意的に、動作ブロック５４を省略することが可能である。実施形態によっては、フローチャート５０’は、また、動作ブロック５７を含むことが可能である。このブロックでは、画像データにルックアップテーブルを適用することが可能である。たとえば、任意的なルックアップテーブル（図１１の曲線によって示されている）を、圧縮をさらに強化するために使用することが可能である。実施形態によっては、図１１のルックアップテーブルは、緑色画像素子のためだけに使用される。他の実施形態では、ルックアップテーブルを、赤色および青色の画像素子のために使用することが可能である。３つの異なる色のために、同一のルックアップテーブルを使用することも可能であるし、また、各色が、それ自身のルックアップテーブルを有することも可能である。さらに、図１１の曲線によって示されているもの以外の処理を、適用することも可能である。

図８および図８Ａを参照しながら上述した方法を用いて画像データを処理することによって、画像センサ１８からの画像データを、６対１あるいはそれより大きい圧縮比によって圧縮し、かつ、視覚的に劣化の状態に保つことが可能である、ということがわかっている。さらに、画像データが（たとえば、緑色画像データを差し引くことによって）変換されていても、全ての生の画像データは、エンドユーザにとって利用可能なままとなっている。たとえば、一定の処理を逆進することによって、全ての（あるいは、ほぼ全ての）オリジナルの生データを抽出し、さらに処理し、フィルタリングし、および／または、ユーザの望む任意の処理を利用することによって、モザイクを復元することが可能である。

たとえば、図１２を参照すると、保存デバイス２４に保存されているデータを解凍し、そのモザイクを復元することが可能である。任意的に、カメラ１０を、フローチャート６０によって示されている方法を実行するように構成することが可能である。たとえば（これに限定されるわけではないが）、再生モジュール２８を、フローチャート６０によって示されている方法を実行するように構成することが可能である。しかしながら、ユーザは、また、保存デバイス２４から別体のワークステーションにデータを転送し、フローチャート６０における任意の（あるいは全ての）ステップおよび／または動作を適用することも可能である。

引き続き図１２を参照すると、フローチャート６０は、動作ブロック６２においてスタートする。この動作ブロックでは、保存デバイス２４からのデータが解凍される。たとえば、動作ブロック６２におけるデータの解凍を、動作ブロック５８（図８）において実行されている圧縮アルゴリズムの逆進とすることが可能である。動作ブロック６２の後、フローチャート６０は、動作ブロック６４に進むことが可能である。

動作ブロック６４では、動作ブロック５６（図８）において実行される処理を逆進することが可能である。たとえば、図１１の曲線の逆のもの、あるいは、図８および図８Ａの動作ブロック５６に関連して上述した他の任意の関数の逆のものを、画像データに適用することが可能である。動作ブロック６４の後、フローチャート６０は、ステップ６６に進むことが可能である。

動作ブロック６６では、緑色画像素子のモザイクを復元することが可能である。たとえば、上述したように、緑色１および／または緑色２（図７）のデータ成分からの全ての値を、保存デバイス２４に保存することが可能である。たとえば、図５に関連して、緑色１、緑色２のデータ成分からの緑色画像データを、画像センサ１８によって適用されるオリジナルのベイヤパターンにしたがって、配置することが可能である。そして、既知の任意の技術（たとえば、線形補間、双曲線など）を用いて、緑色データのモザイクをさらに復元することが可能である。

図１３は、全ての生の緑色画像データからモザイク復元された緑色画像データにおける、典型的な配置を示している。文字Ｇ_ｘによって特定されている緑色画像素子は、オリジナルの生の（解凍された）画像データを示しており、「ＤＧ_ｘ」によって特定されている素子は、モザイク復元処理を経たオリジナルデータから得られた素子を示している。この用語は、以下に示す他の色に関するモザイク復元処理の説明に関して使用される。図１４は、オリジナルの緑色画像データの１／２からモザイク復元された緑色画像データにおける、典型的な画像データの配置を示している。

引き続き図１２を参照すると、動作ブロック６６の後、フローチャート６０は、動作ブロック６８に進むことが可能である。この動作ブロック６８では、モザイクを復元された緑色画像データを、さらに処理することが可能である。たとえば（これに限定されるわけではないが）、緑色画像データに対し、ノイズ低減技術を適用することが可能である。しかしながら、他の任意の画像処理技術（たとえば、アンチエイリアシング技術など）を、緑色画像データに適用することも可能である。動作ブロック６８の後、フローチャート６０は、動作ブロック７０に進むことが可能である。

動作ブロック７０では、赤色および青色画像データのモザイクを復元することが可能である。たとえば、第１に、図９の青色画像データを、ベイヤパターン（図１５）にしたがって再配列することが可能である。図１６に示すように、周囲の素子を、任意の既知のモザイク復元技術（線形補間、双曲線などを含む）を利用して、それらの青色画像データからモザイク復元することが可能である。モザイク復元ステップの結果、図１６に示すように、全ての画素に関する青色画像データが現れることになる。しかしながら、この青色画像データは、修正された図９の青色画像データ（すなわち、緑色画像データ値を差し引かれた青色画像データ値）に基づいて、モザイク復元された。

動作ブロック７０は、また、赤色画像データに対するモザイク復元ステップを含むことが可能である。たとえば、図１０からの赤色画像データを、オリジナルのベイヤパターンにしたがって再配列することが可能であり、さらに、任意の既知のモザイク復元処理（たとえば、線形補間、双曲線など）を用いて、モザイク復元することが可能である。

動作ブロック７０の後、フローチャートは、動作ブロック７２に進むことが可能である。この動作ブロック７２では、モザイクを復元された赤色および青色画像データを、モザイクを復元された緑色画像データから、再構築することが可能である。

実施形態によっては、赤色および青色画像データ素子のそれぞれを、同じ場所にある緑色画像素子（同じ列「ｍ」および行「ｎ」の位置にある緑色画像素子）の緑色値に加えることによって、再構築することが可能である。たとえば、モザイクの復元後では、青色画像データは、青色素子値ＤＢ_{ｍ−２，ｎ−２}を含んでいる。図３に示したオリジナルのベイヤパターンが、この位置において青色素子を含んでいないため、この青色値ＤＢ_{ｍ−２，ｎ−２}は、たとえば、ＤＢ_{ｍ−３，ｎ−３}、ＤＢ_{ｍ−１，ｎ−３}、ＤＢ_{ｍ−３，ｎ−１}、ＤＢ_{ｍ−１，ｎ−１}のいずれか１つから得られた青色値に基づいて、上述したモザイク復元処理を経て（あるいは、他の任意の技術あるいは他の青色画像素子によって）、得られたものである。上述したように、これらの値は、動作ブロック５４（図８）において修正されており、したがって、画像センサ１８によって検出されたオリジナルの青色画像データとは一致しない。むしろ、平均の緑色値が、これらの値のそれぞれから差し引かれている。したがって、得られた青色画像データＤＢ_{ｍ−２，ｎ−２}も、緑色画像データの差し引かれた青色データを示している。このため、一実施形態では、素子ＤＧ_{ｍ−２，ｎ−２}に関するモザイクの復元された緑色画像データを、青色画像値ＤＢ_{ｍ−２，ｎ−２}に加えることが可能であり、これにより、再構築された青色画像データ値を得ることが可能となる。

実施形態によっては、任意的に、青色および／または赤色の画像データを、モザイク復元の前に、先に再構築することが可能である。たとえば、変換された青色画像データＢ’_{ｍ−１，ｎ−１}を、周囲の緑色素子における平均値を加えることによって、先に再構築することが可能である。これは、オリジナルの青色画像データＢ_{ｍ−１，ｎ−１}の取得および再計算をもたらすことになる。この処理を、全ての青色画像データに対して実行することが可能である。その後、さらに、青色画像データを、任意の既知のモザイク復元技術によって、モザイク復元することが可能である。赤色画像データについても、同じあるいは類似の方法によって処理することが可能である。

図１２Ａは、フローチャート６０の修正形（参照番号６０’によって特定されている）を示している。フローチャート６０に関連して上述したステップのいくつかは、フローチャート６０’における対応するステップと類似あるいは同一であり、このため、これらは、同じ参照番号によって特定されている。

図１２Ａに示すように、フローチャート６０’は、動作ブロック６２の後に、動作ブロック６８’を含むことが可能である。この動作ブロック６８’では、画像データに対し、ノイズ低減技術を実行することが可能である。たとえば（これに限定されるわけではないが）、ノイズ低減技術を、緑色画像データに適用することが可能である。しかしながら、他の任意の画像処理技術（たとえば、アンチエイリアシング技術など）を、緑色画像データに適用することも可能である。動作ブロック６８’の後、フローチャートは、動作ブロック７０’に進むことが可能である。

動作ブロック７０’では、画像データのモザイクを復元することが可能である。動作ブロック６６および７０に関連して上述した説明においては、緑色、赤色および青色の画像データを、２つのステップにおいてモザイク復元することが可能である。しかしながら、このフローチャート６０’においては、ここでのモザイク復元処理に関しても、上述したものと同じモザイク復元技術を利用することが可能であるが、全３色の画像データに対するモザイク復元を、１つのステップにおいて表現している。動作ブロック７０’の後、フローチャートは、赤色および青色画像データを再構築することの可能な動作ブロック７２、および、逆ルックアップテーブルを適用することの可能な動作ブロック６４に進むことが可能である。

画像データが、フローチャート７０あるいは７０’のいずれか一方（あるいは他の任意の好適な処理）にしたがって解凍され、処理された後、この画像データを、モザイク復元された画像データとして、さらに処理することが可能である。

赤色および青色の画像データを再構築する前に、緑色画像データをモザイク復元することによって、一定の追加的な利点を得ることが可能である。たとえば、上述したように、人間の目は、緑色光に対してより敏感である。緑色画像データの解凍および処理は、人間の目がより敏感になる緑色画像値を最適化する。したがって、それに続く赤色および青色画像データの再構築は、緑色画像データの処理によって影響されるはずである。

さらに、ベイヤパターンは、赤色および青色の素子に比べて、２倍の数の緑色素子を有している。したがって、全ての緑色データが保持されている実施形態では、赤色あるいは青色の画像データ素子のいずれか一方に比べて、緑色素子に関する画像データが２倍ある。したがって、モザイク復元技術、フィルタおよび他の画像処理技術は、よりよくモザイク復元され、シャープ化され、あるいはフィルタリングされた画像をもたらす。赤色および青色の画像データに対する再構築およびモザイク復元のために、これらのモザイク処理された値を利用することは、オリジナルの緑色データにおけるより高い解像度に関連する利点を、赤色および青色の素子における処理、再構築およびモザイク復元に遷移する。したがって、得られる画像は、さらにエンハンスされる。

Claims (22)

1. 携帯可能な筐体と、
   この筐体によって保持されているとともに、光の焦点を合わせるように構成されているレンズアセンブリと、
   焦点光を、１秒ごとに少なくとも約２３フレームのフレームレートで、少なくとも２ｋの解像度を有する生画像データに変換するように構成されている感光デバイスと、
   前記筺体に保持されているメモリ素子と、
   予め強調処理しかつ圧縮した前記生画像データを復元した際に、視覚的にほぼ劣化のない状態を保つように、前記生画像データを予め強調処理しかつ圧縮し、および、１秒ごとに少なくとも約２３フレームのフレームレートで、前記予め強調処理しかつ圧縮した前記生画像データを前記メモリ素子に保存するように構成されている画像処理システムと、を有し、
   前記生画像データは、モザイク状画像データを有しかつ第１、第２および第３の色を示し、
   前記画像処理システムは、圧縮を改善するために画像素子の相互関係を利用すべく、前記圧縮前に、前記第３の色における選択された画像データの値から導かれた計算画像値に基づいて、前記第１および第２の色における少なくとも１つを示す画像データを修正するように構成されている画像処理モジュールを有しているビデオカメラ。
2. 前記画像処理モジュールは、前記第３の色における選択された画像データの値の平均値に基づいて、前記第１および第２の色における少なくとも１つを示す前記画像データを修正するように構成されている請求項１に記載のビデオカメラ。
3. 前記画像処理モジュールが、第１の色のセンサセルに隣接する少なくとも２つのセンサセルから得られる、第３の色における画像データの値の平均値を算出するとともに、この平均値を、第１の色のセンサセルからの画像データの値から差し引くように構成されている、請求項２に記載のビデオカメラ。
4. 前記平均値が、第１の色のセンサセルに隣接する少なくとも４つのセンサセルから得られる、第３の色の画像データの値の平均値からなる、請求項３に記載のビデオカメラ。
5. 筐体によって保持されているとともに、光の焦点を合わせるように構成されているレンズアセンブリと、
   焦点光を、この焦点光を示す生画像データの信号に変換するように構成されている感光デバイスと、
   前記筺体に保持されているメモリ素子と、
   予め強調処理しかつ圧縮した前記生画像データを復元した際に、視覚的にほぼ劣化のない状態を保つように、１秒ごとに少なくとも約２３フレームのフレームレートで前記予め強調処理された前記生画像データを圧縮して記録するための手段と、を有し、
   前記生画像データは、モザイク状画像データを有しかつ第１、第２および第３の色を示し、
   前記画像処理システムは、圧縮を改善するために画像素子の相互関係を利用すべく、前記圧縮前に、前記第３の色における選択された画像データの値から導かれた計算画像値に基づいて、前記第１および第２の色における少なくとも１つを示す画像データを修正するように構成されている画像処理モジュールを有しているビデオカメラ。
6. 前記画像処理システムは、下記式で規定される曲線を含む関数に従って、前記画像データを予め強調処理する、請求項１から４のいずれか１項に記載のビデオカメラ。
   ｙ＝（ｘ＋ｃ）＾ｇ ・・・（１）
   ただし、０．０１＜ｇ＜１であり、ｃはオフセットである。
7. 前記画像処理システムは、下記式で規定される曲線を含む関数に従って、前記画像データを予め強調処理する、請求項６に記載のビデオカメラ。
   ｙ＝（ｘ）＾０．５ ・・・（２）
8. 前記画像データは１２ビットデータであり、
   前記画像処理システムは、下記式で規定される曲線を含む関数に従って、前記画像データを予め強調処理する、請求項６に記載のビデオカメラ。
   ｙ＝（ｘ／４０９５）＾０．５ ・・・（３）
9. 前記画像処理システムは、以下式の対数曲線により、画像データを強調処理する、請求項１から４のいずれか１項に記載のビデオカメラ。
   ｙ＝Ａ×ｌｏｇ（Ｂ×ｘ＋Ｃ）＾０．５ ・・・（４）
   ただし、Ａ、Ｂ、Ｃは定数である。
10. 前記画像処理システムは、ガンマ曲線に従って、前記画像データを予め強調処理する、請求項１から４のいずれか１項に記載のビデオカメラ。
11. 前記画像データを予め強調処理することは、より線形のエリアを黒色の近くに与える、請求項１〜４のいずれか１項に記載のビデオカメラ。
12. 前記画像処理システムは、Ｒｅｃ７０９ガンマ曲線に従って、前記画像データを予め強調処理する、請求項１〜４、１０および１１のいずれか１項に記載のビデオカメラ。
13. 前記画像処理システムは、ルックアップテーブルを用いて、前記画像データを予め強調処理する、請求項１〜４、６〜１２のいずれか１項に記載のビデオカメラ。
14. 前記画像データは、前記第１の色を示しかつ前記感光デバイス上の第１位置に対応する画像データと、前記第３の色を示しかつ前記感光デバイス上の第２位置に対応する画像データの第１の値と、前記第３の色を示しかつ前記感光デバイス上の第３位置に対応する画像データの第２の値とを含み、
    前記画像処理モジュールは、第３の色を示す画像データの前記第１の値および前記第２の値から前記計算画像値を導き、
    前記計算画像値は、前記第１位置と空間的に相互に関連していることを特徴とする、請求項１、６〜１３のいずれか１項に記載のビデオカメラ。
15. 前記第２位置および前記第３位置は、前記感光デバイス上の第１位置と、実質的に対向している、請求項１４に記載のビデオカメラ。
16. 前記画像処理モジュールは、前記第１の値および前記第２の値の平均値を計算し、前記感光デバイス上の前記第１位置に対応する前記第１の色を示す画像データの値から前記計算された平均値を差し引く構成である、請求項１４または１５に記載のビデオカメラ。
17. 前記画像処理システムは、前記画像データを修正する前に、前記画像データを予め強調処理する構成である、請求項２〜４、６〜１６のいずれか１項に記載のビデオカメラ。
18. 前記画像処理システムは、前記画像データを修正した後に、前記画像データを予め強調処理する構成である、請求項２〜４、６〜１６のいずれか１項に記載のビデオカメラ。
19. 前記圧縮は、少なくとも６：１の圧縮率である、請求項１〜４、６〜１８のいずれか１項に記載のビデオカメラ。
20. 前記感光デバイスは、画像センサチップを備え、
    前記画像処理システムは、画像処理モジュールと、圧縮チップを備え、
    前記圧縮チップは、前記ビデオカメラ内で前記画像データの圧縮を実行する構成であって前記圧縮チップは、前記画像センサチップおよび前記画像処理モジュールから分離している構成である、請求項１〜４、６〜１９のいずれか１項に記載のビデオカメラ。
21. 前記画像処理システムは、ＪＰＥＧ２０００標準の圧縮技術に従う、請求項１〜４、６〜２０のいずれか１項に記載のビデオカメラ。
22. 前記請求項１〜４、６〜２１のいずれか１項に記載のビデオカメラを使用する方法であって、画像データを予め強調処理し、圧縮し、記録するように、画像処理システムを作動することを含む方法。
    

Images