特許 6985452 デジタル画像の無損失圧縮を達成するためのピクセル値のエンコードに関連する方法およびエンコーダ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6985452

(24)【登録日】2021年11月29日

(45)【発行日】2021年12月22日

(54)【発明の名称】デジタル画像の無損失圧縮を達成するためのピクセル値のエンコードに関連する方法およびエンコーダ

(51)【国際特許分類】

   H04N 1/41 20060101AFI20211213BHJP

   H04N 19/91 20140101ALI20211213BHJP

   H04N 19/93 20140101ALI20211213BHJP

   H03M 7/46 20060101ALI20211213BHJP

【ＦＩ】

   H04N1/41

   H04N19/91

   H04N19/93

   H03M7/46

【請求項の数】13

【外国語出願】

【全頁数】28

(21)【出願番号】特願2020-81254(P2020-81254)

(22)【出願日】2020年5月1日

(65)【公開番号】特開2020-184762(P2020-184762A)

(43)【公開日】2020年11月12日

【審査請求日】2020年6月30日

(31)【優先権主張番号】19172426.9

(32)【優先日】2019年5月2日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】504048696

【氏名又は名称】シック アイヴィピー エービー

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】マルティン・ヒンナソン

(72)【発明者】

【氏名】マティアス・ヨハンネソン

【審査官】 西谷 憲人

(56)【参考文献】

【文献】 特開２００６−３１１０５５（ＪＰ，Ａ）

【文献】 特開平０６−０３０２８４（ＪＰ，Ａ）

【文献】 特開２００２−０４４４５７（ＪＰ，Ａ）

【文献】 特表２０１４−５０２８２７（ＪＰ，Ａ）

【文献】 特開２００６−３３９９９０（ＪＰ，Ａ）

【文献】 Tsung-Han Tsai;Yu-Hsuan Lee;Yu-Yu Lee，Design and Analysis of High-Throughput Lossless Image Compression Engine Using VLSI-Oriented FELICS Algorithm，IEEE Transactions on Very Large Scale Integration (VLSI) Systems，IEEE，2009年03月27日，vol18,issue1，39-52，https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4806140

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ １／４１

Ｈ０４Ｎ １９／９１

Ｈ０４Ｎ １９／９３

Ｈ０３Ｍ ７／４６

(57)【特許請求の範囲】

【請求項1】

デジタル画像の無損失圧縮を達成するために、複数のラインのピクセルを含む前記デジタル画像のピクセル値をエンコードするためのエンコーダ(131、800)であって、
前記エンコーダ(131、800)は、前記複数のラインの各々について、
前記ラインのエンコードされていないピクセル値を取得し(701)、
前記ラインの1つまたは複数のピクセルの各々について、前記デジタル画像の前記無損失圧縮における前記ピクセル(x)の前記エンコードされていないピクセル値をエンコードするために、どのエンコードが使用されるかを決定(702)するように構成され、前記決定は、前記エンコードされていないピクセル値が、前記ラインの他の最も近い近隣ピクセル(N1、N2)のエンコードされていないピクセル値とどのように関係しているかに基づき、最も近い近隣ピクセル(N1、N2)は、前記ラインに沿ったある方向における2つの最も近い先行ピクセル(N1、N2)である、エンコーダ(131、800)。

【請求項2】

1つまたは複数の後で発生するピクセルの各々について、前記エンコードされていないピクセル値が、前記最も近い近隣ピクセル(N1、N2)の前記エンコードされていないピクセル値と同じである場合、前記ラインの前記1つまたは複数の後で発生するピクセルのピクセル値をエンコードするために、ランレングス符号化(RLC)を使用することが決定される、請求項1に記載のエンコーダ(131、800)。

【請求項3】

少なくともいくつかのピクセル値は、前記最も近い近隣ピクセル(N1、N2)を使用した予測、および前記予測の計算された残差値(ε)に基づいてエンコードされ、前記計算された残差値(ε)は、前記エンコードされていないピクセル値が、前記最も近い近隣ピクセルのうちの少なくとも1つのエンコードされていないピクセル値とどのように関連しているかに基づく、請求項1または2に記載のエンコーダ(131、800)。

【請求項4】

前記エンコードされていないピクセル値が、前記最も近い近隣ピクセル(N1、N2)の前記エンコードされていないピクセル値の間にある場合、前記エンコードされていないピクセル値のエンコードのために、第1のタイプの符号化を使用すること、および、前記エンコードされていないピクセル値が、前記最も近い近隣ピクセル(N1、N2)の前記エンコードされていないピクセル値のうちのいずれか1つを下回りまたは上回る場合、前記エンコードされていないピクセル値のエンコードのために、別の第2のタイプの符号化を使用することが決定される、請求項1から3のいずれか一項に記載のエンコーダ(131、800)。

【請求項5】

前記第2のタイプの符号化は、コンテキストに依存しないk値および所定の最大符号長を使用するように構成されたゴロム-ライス符号化である、請求項4に記載のエンコーダ(131、800)。

【請求項6】

前記エンコーダ(131、800)は、
前記決定に基づいて、エンコードされたピクセル値を提供する(703)ようにさらに構成され、前記エンコードされたピクセル値は、前記エンコーダ(131、800)によってエンコードされる前記エンコードされていないピクセル値であり、前記デジタル画像の前記無損失圧縮の一部である、
請求項1から5のいずれか一項に記載のエンコーダ(131、800)。

【請求項7】

前記エンコーダ(131、800)は、
複数の等長データワードに含まれる各ラインの前記エンコードされたピクセル値を提供する(704)
ようにさらに構成される、請求項6に記載のエンコーダ(131、800)。

【請求項8】

ラインの異なるピクセルの前記エンコードされたピクセル値は、前記等長データワードの中でデータワードを共有し、異なるラインのエンコードされたピクセル値は、前記等長データワードの中の別々のデータワードにある、請求項7に記載のエンコーダ(131、800)。

【請求項9】

前記エンコーダ(131、800)は、
各ラインに関連して、前記エンコードされたピクセル値を含む前記等長データワード内の前記ラインの開始位置を識別するそれぞれの識別子を提供する(705)
ようにさらに構成される、請求項7または8に記載のエンコーダ(131、800)。

【請求項10】

前記識別子は、前記デジタル画像のラインごとに1つの値を含むデータ構造内の別個の値として提供され、各値は、前記等長データワードの中の参照データワードに関連して、それぞれのラインの開始位置を示す、請求項9に記載のエンコーダ(131、800)。

【請求項11】

デジタル画像の無損失圧縮を達成するために、複数のラインのピクセルを含む前記デジタル画像のピクセル値をエンコードするためのエンコーダ(131、800)によって実行される方法であって、前記方法は、
前記複数のラインの各々について、
前記ラインのエンコードされていないピクセル値を取得するステップ(701)と、
前記ラインの1つまたは複数のピクセルの各々について、前記デジタル画像の前記無損失圧縮における前記ピクセル(x)の前記エンコードされていないピクセル値をエンコードするために、どのエンコードが使用されるかを決定するステップ(702)であって、前記決定は、前記エンコードされていないピクセル値が、前記ラインの他の最も近い近隣ピクセル(N1、N2)のエンコードされていないピクセル値とどのように関係しているかに基づき、最も近い近隣ピクセル(N1、N2)は、前記ラインに沿ったある方向における2つの最も近い先行ピクセル(N1、N2)である、ステップと
を含む、方法。

【請求項12】

命令を含むコンピュータプログラム(803)であって、前記命令は、前記エンコーダ(131、800)によって実行されるとき、前記エンコーダ(131、800)に、請求項11に記載の方法を実行させる、コンピュータプログラム(803)。

【請求項13】

請求項12に記載のコンピュータプログラム(803)を含む、コンピュータ可読記憶媒体(901)。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書の実施形態は、デジタル画像の無損失圧縮を達成するための複数のラインのピクセルを含むデジタル画像のピクセル値のエンコードに関連する方法および構成に関する。

【背景技術】

【0002】

デジタル画像は、一般的に、ピクセルのアレイとして定義される。アレイにおけるピクセル数は、通常、解像度と呼ばれる。各ピクセルは、ピクセルの位置の画像に関する情報を含む1つまたは複数のピクセル値によって表され、すなわち、関連付けられている。グレースケール画像では、ピクセルは、そのピクセルの強度を表す非負整数値で表される。画像のビット深度は、ピクセルが有することができる値の範囲を定義する。グレースケール画像は、一般的に、8〜16ビットのピクセル深度を有し、これは、ピクセル範囲が[0;2N-1]であることを意味し、ここで、Nはピクセル深度である。

【0003】

工場および物流の自動化のための産業用ビジョンカメラおよびシステムは、オブジェクトの3D画像がキャプチャされる、3次元(3D)マシンビジョンに基づき得る。3D画像とは、従来の画像のように2次元(2D)のみのピクセルに関する情報、たとえば、強度および／または色などの情報を含まない、または少なくともそれだけではなく、「高さ」または「奥行き」などの情報も含む画像を指す。次いで、処理は、3D画像からオブジェクトの特性に関する情報、すなわちオブジェクトの3D特性に関する情報を抽出し、たとえば、様々な3D画像形式に変換するために適用されてもよい。高さに関するそのような情報は、範囲のデータと呼ばれることがあり、したがって、範囲のデータは、撮像されるオブジェクトの高さ測定からのデータに対応し、言い換えれば、オブジェクトの範囲または距離測定からのデータに対応し得る。代替的にまたは追加的に、ピクセルは、撮像されたエリアにおける光の散乱、または光の特定の波長の反射など、他の材料特性に対応していてもよい。

【0004】

したがって、ピクセル値は、たとえば、ピクセルの強度および／または範囲のデータおよび／または材料特性に関連し得る。

【0005】

デジタルデータ圧縮とは、元の表現よりも少ないビットを使用して情報をエンコードするタスクである。その目標は、一般的に、ストレージスペースを低減する、またはトランスポート帯域幅を最小限に抑えることである。デジタルファイル内の冗長な情報を最小限に抑えることによって、データを、無損失でまたは損失ありで圧縮することができる。非破壊的圧縮としても知られる無損失圧縮は、圧縮プロセスが完全に可逆的であるときであり、元の情報の正確なコピーを達成するために、圧縮を逆に戻すことができることを意味する。損失のある圧縮とは、一般的に、圧縮アルゴリズムにおける量子化のために、これを達成することができないときである。

【0006】

無損失圧縮技法は、本開示の主な関心事である。

【0007】

画像のために設計された圧縮アルゴリズムは、典型的には、無相関化ステップ、続いてエントロピー符号化からなる。通常の連続した画像は、近隣のピクセル間の高い相関性、すなわち空間的冗長性を有するので、この冗長性を最小限に抑えるために無相関化ステップが使用され、したがって、画像のエントロピーを減少させる。

【0008】

無損失画像圧縮技法は、予測ベース技法および辞書ベース技法という、2つのカテゴリに分けることができる。

【0009】

たとえば、いわゆるLempel-Ziv-Welch(LZW)アルゴリズム、算術符号化アルゴリズム、および、いわゆるハフマン符号化アルゴリズムを含む、多くの十分に開発された辞書ベースの圧縮アルゴリズムがある。これらでは、反復的で頻繁に発生するパターンには、より短い符号語が割り当てられる。符号語のテーブルは、画像の統計に基づいて作成され、次いで、画像のエンコードに使用される。確率テーブルは、通常、画像を2回(またはそれ以上)スキャンして、画像を圧縮することができる統計モデルを構築するいわゆる2パス法によって作成される。別の手法は、エンコーダが扱う画像の仮説に基づいて作成される固定の確率テーブルを使用することである。

【0010】

予測ベースのアルゴリズムは、近隣のピクセル、すなわち隣接するピクセルに基づいて、現在のピクセル値を予測し、次いで、予測誤差、すなわち予測と実際のピクセル値との間の差の残差値をエンコードすることによって、画像の空間的冗長性を利用する。エンコードは、1パスで行うことができる。予測ベースのアルゴリズムは、たとえば、無損失圧縮をサポートするJoint Photographic Experts Group LS(JPEG-LS)、コンテキストベースの適応型無損失画像コーデック(CALIC)、高速効率的および無損失画像圧縮システム(FELICS)、および拡張ライス無損失圧縮の実装であるSZIPにおいて使用される。

【0011】

製造、組立、および品質管理のような高度に自動化された産業では、たとえば、カメラおよび撮像ベースのシステムによって提供されるような、高速かつ正確なセンサーおよび測定が必要である。そのようなシステムは、さらなる処理のために、ギガビットイーサネット(GbE)を介して非圧縮画像データをホストコンピュータに送信し得る。低レイテンシを有する受信機において画像が期待され、または必要とすらされるので、イーサネットリンクの帯域幅によって、カメラの動作速度に制限が設定される。より高速なイーサネット通信を可能にするハードウェアのアップグレードには高コストが伴い、スループットを向上させるコスト効率の高いソリューションが望まれる。

【0012】

従来のデジタルグレースケールおよびRGB画像、ならびに範囲のデータを有する3D画像は、一般的に、高い空間的および時間的冗長性を有しており、これは、圧縮のために利用することができる。JPEG-LS、CALICS、およびランレングスエンコード(RLE)としても知られているランレングス符号化(RLC)のような無損失圧縮方式は、情報密度を高め、画像ファイルのサイズを縮小するために使用することができる。したがって、そのようなソリューション、および十分に高い圧縮および復元速度を利用して、非圧縮画像データのみの場合に可能なものと比較して、たとえばイーサネットリンクなどの通信リンク上のスループットを向上させることができる。

【0013】

したがって、カメラシステムでは、画像データの帯域幅が非常に高くなる可能性があり、時として、ギガビットイーサネットのような物理トランスポート層が性能を制限することがある。したがって、無損失圧縮は、システムの性能を向上させることができる。無損失は、カメラシステムが測定を行うために使用されているときに望ましい、またはしばしば必要とすらされる。

【0014】

米国特許出願公開第2016249064(A1)号は、無損失データ圧縮および復元装置、システム、ならびに方法を開示している。目的は、ギガビットイーサネット接続など、可逆的な方法でトランスポートされる画像データの平均量を増大させ、その帯域幅を増大させることである。圧縮のためのビデオ画像ファイルは、複数のラインセグメントを含み、各ラインセグメントは、Mピクセルの長さ、およびHビットのヘッダを有し、各ピクセルは、tビットで表される。エンコードされていない画像ファイルから、第1のセグメント長Mピクセルを有する第1のラインセグメント内の第1の数のエンコードされていないピクセル値が読み取られる。さらに、エンコードされていない画像ファイルから、第2の長さMを有する第2のラインセグメントの第2の数のエンコードされていないピクセル値が読み取られる。次いで、第1のエンコードされていないピクセル値および第2のエンコードされていないピクセル値の各々の間の差分が決定される。第1および第2のエンコードされていないピクセル値の各々の間の差分のみが、セグメント内の各ピクセル値についての所定のビット数の最小ビット数tを使用してエンコードされ、ここで、tは1からNの間の整数として定義される。

【発明の概要】

【課題を解決するための手段】

【0015】

上記に鑑みて、目的は、無損失圧縮を達成し、帯域幅が制限された通信リンクを介したトランスポートを容易にするためのデジタル画像のピクセル値のエンコードに関するものなど、従来技術に対する1つまたは複数の改良または代替を提供することである。

【0016】

本明細書の実施形態の第1の態様によれば、上記の目的は、デジタル画像の無損失圧縮を達成するために、複数のラインのピクセルを含むデジタル画像のピクセル値をエンコードするためのエンコーダによって達成される。エンコーダは、前記複数のラインの各々について、ラインのエンコードされていないピクセル値を取得するように構成される。エンコーダは、前記複数のラインの各々について、デジタル画像の前記無損失圧縮におけるピクセルのエンコードされていないピクセル値をエンコードするために、どのエンコードが使用されるかを、ラインの1つまたは複数のピクセルの各々について、決定するように構成される。決定は、前記エンコードされていないピクセル値が、前記ラインの他の最も近い近隣ピクセルのエンコードされていないピクセル値とどのように関係しているかに基づく。

【0017】

本明細書の実施形態の第2の態様によれば、上記の目的は、デジタル画像の無損失圧縮を達成するために、複数のラインのピクセルを含むデジタル画像のピクセル値をエンコードするためのエンコーダによって実行される方法によって達成される。エンコーダは、前記複数のラインの各々について、ラインのエンコードされていないピクセル値を取得する。エンコーダはさらに、前記複数のラインの各々について、デジタル画像の前記無損失圧縮におけるピクセルのエンコードされていないピクセル値をエンコードするために、どのエンコードが使用されるかを、ラインの1つまたは複数のピクセルの各々について、決定する。決定は、前記エンコードされていないピクセル値が、前記ラインの他の最も近い近隣ピクセルのエンコードされていないピクセル値とどのように関係しているかに基づく。

【0018】

本明細書の実施形態の第3の態様によれば、上記の目的は、命令を含むコンピュータプログラムであって、命令は、1つまたは複数のプロセッサによって実行されると、エンコーダに、第2の態様による方法を実行させる、コンピュータプログラムによって達成される。

【0019】

本明細書の実施形態の第4の態様によれば、上記の目的は、第3の態様によるコンピュータプログラムを含む担体によって達成される。

【0020】

たとえば同じライン内の予測子に対応する参照ピクセルのものなど、同じライン内の他のピクセル値に基づいて、デジタル画像の前記無損失圧縮におけるピクセルのエンコードされていないピクセル値をエンコードするために、どのエンコードが使用されるかを決定することによって、特にデジタル画像が範囲のデータを有する3D画像であるとき、高速でリソース効率の良いハードウェア実装が可能になる。ピクセル値は、ラインに依存せずにエンコードおよびデコードされることが可能であり、無損失圧縮のための適切なエンコードは、ピクセル値ごとに決定、たとえば選択することができ、決定と同じ参照ピクセルに基づくことができる。

【0021】

本明細書の実施形態の例は、以下に簡単に説明される添付の概略図を参照して、より詳細に説明される。

【図面の簡単な説明】

【0022】

【図1A】本明細書の実施形態が適用され得る、3D画像を提供するための三角測量ベースの測定システムを概略的に示す図である。

【図1B】本明細書のシステムの実施形態が適用され得る、カメラユニット内にエンコーダを有し、デコーダを有する受信ユニットに通信リンクを介してエンコードされたデータを送信するためのシステムを概略的に示す図である。

【図2】2つのケースの予測コンテキストを概略的に示す図である。

【図3】想定される確率分布を概略的に例示する図である。

【図4】ランレングス符号化(RLC)原理の2つの例を概略的に示す図である。

【図5】現在のピクセルに関するアクションを要約する形式でモデリング段階を概略的に示し、例示するフローチャートである。

【図6A】データパッカーに関連する状況を概略的に示す図である。

【図6B】データパッカーに関連する状況を概略的に示す図である。

【図7】本明細書の実施形態による方法の実施形態を概略的に示すフローチャートである。

【図8】図7に関連して説明された方法およびアクションを実行するようにどのように構成できるかを示す、本明細書の実施形態によるエンコーダの実施形態を示すための機能ブロック図である。

【図9】図7に関連して説明された方法およびアクションをエンコーダに実行させるためのコンピュータプログラムおよびその担体に関する実施形態を示す概略図である。

【発明を実施するための形態】

【0023】

本明細書の実施形態は、例示的な実施形態である。これらの実施形態は、必ずしも相互排他的ではないことに留意されたい。ある実施形態からの構成要素は、暗黙のうちに別の実施形態に存在すると想定することができ、それらの構成要素が他の例示的な実施形態でどのように使用できるかは、当業者には明らかであろう。

【0024】

本明細書の実施形態に向けた発展として、既存の無損失圧縮技法の研究、および、いわゆるラインスキャン画像データを用いて、ピクセル値が範囲のデータに関連するときに、これらがどのように実行されるかについての研究が行われてきた。たとえば、一度に1ラインのピクセルで、画像データを検知し、提供するように構成されたセンサーを備えたカメラによってなど、画像の画像データが、一度に1ライン、スキャンされるか提供されると、ラインスキャン画像データが得られる。ラインスキャン画像の特殊なケースは、いわゆる「光のシート」、またはレーザーライン、3D三角測量によって提供される画像データである。3Dマシンビジョンシステムは、多くの場合、アクティブ三角測量に基づく。そのようなシステムでは、特定の光パターンでオブジェクトを照明する光源がある。たとえばレーザー光によって生成された特定の光パターンとして、光のシートを使用するのが一般的である。

【0025】

図1Aは、そのようなシステム、すなわち測定システム100の一例を概略的に示す。システム100は、アクティブ三角測量のために構成されたマシンビジョンシステムに対応し得る。測定システム100は、図には光のシートとして例示され、図示されている、特定の光パターン111で画像化されるオブジェクトを照明するためのたとえばレーザーなどの光源110を含む。光は、レーザー光であってもよいが、レーザー光である必要はない。図示された例では、オブジェクトは、自動車の形態の第1のオブジェクト120、およびギアホイール構造の形態の第2のオブジェクト121によって例示されている。特定の光パターン111がオブジェクトに入射するとき、これは、オブジェクトへの特定の光パターン111の投影に対応し、これは、特定の光パターン111がオブジェクトと交差するときに見られ得る。たとえば、示された例では、光のシートとして例示される特定の光パターン111は、第1のオブジェクト120上への光線112をもたらす。特定の光パターン111は、オブジェクトによって、より具体的には、交差点、すなわち、示された例では光線112におけるオブジェクトの部分によって反射される。測定システム100は、オブジェクトによって反射されると、特定の光パターンが画像センサーへの入射光となるように、光源110および撮像されるべきオブジェクトに対して配置された、画像センサー(図示せず)を含むカメラユニット130をさらに含む。画像センサーは、典型的には、入射光を画像データに変換するためのチップとして実装された構成である。反射によって画像センサー上の前記入射光を生じさせるオブジェクトの前記部分は、それによって、カメラユニット130および画像センサーによってキャプチャされ、対応する画像データが生成され、さらなる使用のために提供され得る。たとえば、示された例では、特定の光パターン111は、第1のオブジェクト120の車の屋根の一部分の上の光線112において、カメラユニット130および画像センサーに向かって反射され、それによって、車の屋根の前記一部分に関する情報を有する画像データを生成し、提供してもよい。測定システム100の形状の知識、たとえば、画像センサーの座標が、世界座標、たとえば、撮像されるオブジェクトおよびそのコンテキストに関連する、たとえばデカルト座
標など、座標系123の座標にどのように関連するかにより、画像データは、3D特性に関する情報、たとえば、適切な形式で撮像されるオブジェクトの3D形状またはプロファイルに変換され得る。

【0026】

たとえば、光源110および／または第1のオブジェクト120もしくは第2のオブジェクト121など、撮像されるオブジェクトを移動させることによって、オブジェクトの複数の部分が照明され、画像センサー上で反射光を引き起こすようにし、実際には、一般的には、オブジェクトをスキャンすることによって、たとえば、第1のオブジェクト120の示されたプロファイル140-1〜140-Kなど、オブジェクトの複数の連続したプロファイルに対応する、オブジェクトのより完全な3D形状を記述する画像データが生成され得る。図に示されるように、各オブジェクトのすべての部分、または少なくとも光源110に面するすべての部分が照明されるように、光源110およびカメラユニット130が一般的に静止している状態で、特定の光パターン111を介してオブジェクトを移動させるために、コンベヤベルト122または同様のものが使用されてもよい。前記3D特性に関する情報、たとえば、前記3D形状またはプロファイルは、任意の適切な形式で3D特性を記述するデータを含み得る。

【0027】

上記から理解されるように、カメラユニット130、およびたとえば第1のオブジェクト120の画像センサーによって提供される画像は、複数のラインのピクセルを含み、各ラインは、図に示され、ピクセル値としての範囲のデータを有するスキャンされたプロファイルに対応し得る。ピクセルのラインは、スキャン中に順次提供されてもよい。

【0028】

図1Aのような構成を使用することの利点は、ラインの歪みが一方向に集中することであり、これによって、計算が簡単になり、校正の複雑さが低減される。欠点は、オブジェクトのカメラビューがある角度をなしていることであり、このことは、カメラはより高い被写界深度を必要とすること、および、オブジェクトの高さが変化すると、レーザーラインの一部がブロックされる可能性があり、それによって、カメラから見えなくなることを意味する。レーザーラインがブロックされた、または強度が設定されたしきい値を下回ったプロファイル内のピクセルは、欠落データと呼ばれ、生成された画像では、一般的に、たとえば0など、欠落データを識別する同じ定義された値を有する連続的に発生するピクセルとして現れる。

【0029】

カメラユニット130および画像センサーによって提供される画像は、一般的に、カメラユニットの外部でさらに処理するために、たとえばホストコンピュータなどに転送、たとえば送信することが望ましく、背景技術で説明したような状況が発生する可能性がある。すなわち、通信リンク、たとえばギガビットイーサネットなどの物理トランスポート層は、性能および圧縮を制限する可能性があり、これは、一般的に、可逆的でなければならず、したがって、これを回避し、性能の向上を可能にするために、送信の前に使用され得る。

【0030】

図1Bは、たとえば無損失圧縮のためなど、デジタル画像のエンコード、および、たとえばギガビットイーサネットリンクなど、通信リンク140を介したエンコードデータの送信のためのシステム200を概略的に示す。ここでは、エンコードは、たとえばエンコードデバイスまたはエンコーダ回路などのエンコーダ131によって実行され、これは、たとえばカメラまたは画像キャプチャ装置などのカメラユニットに含まれ得、ここではカメラユニット130として示され、すなわち、エンコーダ131を有するカメラユニットは、図1Aのカメラユニット130であってもよい。エンコードされた画像データは、カメラユニット130、あるいはむしろその画像センサーによってキャプチャされ、非破壊的に圧縮された、すなわち無損失圧縮された画像データに対応し得る。エンコーダ131によって提供されるエンコードされた画像データは、カメラユニット130にも含まれ、通信リンクを介してエンコードされた画像データを送信するように構成された送信機132、たとえば回路またはモジュールなどによって取得され得る。送信機132は、カメラユニット130の入出力(I/O)回路またはモジュールの一部であってもよく、通信リンクとインターフェースする。受信ユニット150、たとえばホストコンピュータに含まれている、またはホストコンピュータに対応するデバイスまたは装置は、通信リンク140を介してエンコードされた画像データを受信するように構成されていてもよい。受信ユニット150は、通信リンク140とインターフェースする入出力(I/O)回路またはモジュールの一部であってもよく、通信リンク140を介した受信によりエンコードされた画像データを取得するように構成され得る受信機151、たとえば送信回路またはモジュールを含んでいてもよい。示された受信ユニットは、エンコーダ131によってエンコードされた、たとえば圧縮された画像データをデコードする、たとえば復元するように構成されたデコーダ152も含み得る。実際に、カメラユニット130および受信ユニット150はまた、当業者によって理解されるように、さらなる回路および／またはモジュールを含むが、簡略化のためにここでは示されない。たとえば、受信ユニット150は、無損失圧縮の場合に、したがって、エンコード前のもの、すなわち、その画像センサーなど
、カメラユニット130によって提供されるものと同じ画像情報において作用し得る、デコードされた画像データの記憶および／またはさらなる処理のための手段および／またはアクセスを提供することができる。

【0031】

上記の範囲のデータのピクセル値は、通常のグレースケール画像のピクセル値に匹敵する。提供されるビット深度は、たとえば8、12、または16ビットに設定されてもよく、通常の場合は、たとえば12ビット深度であり、これは、ピクセル値は0から2¹²-1の範囲、すなわち、0から4095の範囲にあり、たとえば、0など、欠落データを識別する値も含むことを意味する。画像ラインのピクセル幅は、あるカメラが使用されるとき、たとえば2560ピクセルであり得る。

【0032】

3D画像の範囲のデータのピクセル値と従来のグレースケール画像のピクセル値との間に見られる主な違いは、上述したような欠落データの存在である。

【0033】

上述のようにラインスキャンデータでの使用に適した画像データの圧縮のためのエンコーダによって満たされることが望ましい要件は、リアルタイムの用途、すなわち範囲のデータのリアルタイムエンコードに適していること、少なくとも1.5〜2の圧縮率が有効であること、およびエンコーダのスループットがギガビットイーサネットのものを超えること、すなわち>125MB/sであることを含む。エンコーダは、好ましくはハードウェア内に実装され、次いで、実装に必要なハードウェアリソースの量を抑え、エンコードされたデータの提供におけるレイテンシを抑えることも望ましい。

【0034】

圧縮率は、ここでは上述の典型的な範囲のデータ画像である、典型的な画像のサイズを、エンコーダがどれだけ圧縮、すなわち低減することができるかを示している。圧縮率を記述する別の方法は、圧縮前のデータを表すのに必要なビット数と圧縮後に必要なビット数との間の関係である。ここでのスループットは、エンコードされていない入力画像データが毎秒どれだけ処理され得るか、したがって、エンコードされた圧縮された画像データをどれだけもたらすかに関係する。

【0035】

エンコーダの出力をデコードするためのデコーダとしては、低い計算オーバーヘッドおよび低いレイテンシを有し、少なくともエンコーダと十分に一致するのに十分低いことが望ましい。

【0036】

上記を念頭に置いて、エンコーダ、たとえばエンコーダ131がそれに基づき得る適切な無損失画像圧縮アルゴリズムを評価し、見つけるために、既存の圧縮アルゴリズムの包括的な研究が行われた。

【0037】

たとえば、背景技術に記載されているような2パスアルゴリズムなど、いくつかの既存のアルゴリズムは、あまり適切ではないことが判明した。文脈上のピクセル値、アルゴリズムパラメータ、および統計モデルは、典型的には、圧縮の間に記憶される必要がある。圧縮は、リアルタイムで、典型的には、高頻度で実行されなければならないので、ラスタスキャン順のアルゴリズムが好ましいことが判明した。ラスタスキャン順とは、画像が、ピクセルごとに、ラインごとに処理されることを意味する。いくつかのアルゴリズムは、画像をブロックに分割し、各ブロックは、個々に処理される。しかしながら、これは、処理の前に画像の複数のラインをバッファリングする必要があり、結果として、エンコードされていないラインの画像データを記憶／バッファリングするための大きい必要性、および／または、より大きいレイテンシが生じる。これは、たとえば、背景技術に記載されている従来技術の解決策の場合であり、ここでは2ラインが使用される。

【0038】

さらに、ハードウェアにおける実装は、リアルタイムで望ましい速度で実行可能であるべきであるので、パイプライン段階は比較的単純である。したがって、単純な論理演算および算術演算で実現できるアルゴリズムが、他のアルゴリズムよりも優先されるものとする。さらに、パイプラインにおけるデータ依存性は回避されるべきであり、したがって、圧縮中に更新される動的モデルは、回避した方がよい場合がある。

【0039】

さらに、いくつかの異なる範囲のデータ画像におけるエントロピーの研究が行われ、エントロピーを減少するために異なる無相関化方法が適用された。エントロピーは、圧縮性を評価するために使用することができる。画像のエントロピーは、画像をどれだけ圧縮できるかの下限を示す。ピクセル深度をエントロピーで割ることによって、圧縮率のおおよその限界を獲得することができる。

【0040】

少なくともいくつかの適応および変更の後に有望であることが判明した圧縮方法が、FELICSで使用されているものである。

【0041】

上記の結果、依然として、上記のように範囲のデータ画像の圧縮可能な特性を利用することができる一方で、シンプルで高速でリソース効率が良くなるように設計されたエンコード方法が開発された。本明細書の実施形態は、前記の得られたエンコード方法に基づく。

【0042】

エンコード方法は、既存のFELICSアルゴリズムに基づくものとして最も簡単に説明され得、削減と追加の両方を伴う変更が行われる。FELICSの説明は、たとえば、P. G. Howard and J. S. Vitter, Proceedings DCC `93: Data Compression Conference, March 1993, "Fast and efficient lossless image compression", pages 351-360, 10.1109/DCC.1993.253114、およびT. Tsai and Y. Lee, IEEE Transactions on Very Large Scale Integration (VLSI) Systems, Jan 2010, volume 18, "Design and Analysis of High-Throughput Lossless Image Compression Engine Using VLSI-Oriented FELICS Algorithm", pages 39-52, 10.1109/TVLSI.2008.2007230, ISSN 1063-8210に記載されている。

【0043】

既存のFELICSアルゴリズムは、以下では元のまたは通常のFELICSと呼ばれることもあるが、上記で説明した研究からの洞察の前の自然な出発点ではないことに留意されたい。元のFELICSは、したがって、変更が行われておらず、あまり適切ではない。たとえば、コンテキストが複数のラインのピクセルを含む個々のピクセルに動的予測コンテキストを使用した画像のエンコードにおける元のFELICSである。

【0044】

要するに、本明細書における実施形態が基づくエンコード方法は、2つの主な段階、予測／モデリングおよびエントロピーエンコードを含み、すなわち、予測ベースである。モデリング段階は、エントロピーを減少させようとし、すなわち、情報密度を増加させようとする。モデリング段階では、現在のピクセルを予測するためのコンテキストとして、同じライン上の2つの先行ピクセル値を使用することが好ましい。ピクセルのピクセル値は、従来の画像の場合にはピクセルの強度に、または、上記のように範囲のデータを有する3D画像の場合には範囲、すなわちオブジェクトの高さ測定に関連し得る。次いで、予測誤差は、FELICSで使用されるような調整バイナリ符号化(ABC: Adjusted Binary Coding)の変更された簡略化された変形体を使用して、エンコードステップにおいてエンコードされ、ここでは簡略化された変形体は、簡略化された調整バイナリ符号化(SABC: Simplified Adjusted Binary Coding)、またはFELICSで使用されるゴロム-ライス符号化(GRC)の変形体と呼ばれる。これに加えて、本明細書のエンコード方法は、コンテキストが欠落データを示すときにランレングスモードに適応的に切り替わる。ランレングスモードでは、符号化はランレングス符号化(RLC)であり、ランレングスエンコード(RLE)とも呼ばれ得る。RLCは、したがって、既知の方法であり、以下に別途簡単に説明する。ソース符号化は、典型的に、可変長のビット文字列を出力し、したがって、データ、またはビットのパッカーが望ましい。データパッカーは、着信ビット文字列を、たとえばギガビットイーサネットリンクなど、通信リンク140などの通信リンクを介して送信されるように、最終符号として出力することができる、固定長のデータワードにパックするものとする。画像は、ラインに依存せず、たとえばラインに依存しないスキャン順序で圧縮されるので、各ラインの結果として得られる総符号長は、圧縮された符号と一緒に出力されるものとする。これによって、ライン間のデータ依存がなくなり、デコーダが複数のライン上で並列に動作することが可能になる。

【0045】

したがって、本明細書における実施形態が基づくエンコード方法は、予測ベースであり、このために、エンコードの対象となるピクセルと同じライン内の先行する2つのピクセルのコンテキストを使用する。コンテキストに基づいて異なるエンコード技法が使用される。あるピクセル値のエンコードを提供するために使用されるエンコード技法、たとえば、SABC、GRCの前記変形体、またはRLCのいずれかにおいてどれが使用されるかは、コンテキストに基づいても決定される。これによって、上記で説明したように、画像、特に範囲のデータ画像の無損失圧縮のシンプルで、高速で、リソース効率が良い実装が可能となる。

【0046】

次に、本開示のエンコード方法の前記2つの主な段階、すなわち、予測／モデリングおよびエンコード段階、ならびにデータパッカーについて、さらに詳細に説明する。エンコード段階は、前記3つのエンコード技法、すなわちSABC、GRCおよびRLCの前記変形に分けられて説明される。

【0047】

1.予測／モデリング段階
上述したように、ピクセル値は、ラインに依存しないスキャン順序でエンコードされる。画像は、通常のラスタスキャン順でスキャンされてもよいが、各ラインは、他からは完全に個別にエンコードされる。これは、残差を計算するために2次元が一般的に使用される画像のほとんどの予測画像圧縮技法とは異なる。同じラインのローカル予測子によりラインを個別にエンコードすることによって、ライン間のデータ依存関係が削除される。ラインが個々にエンコードされ、予測モデルはこれを考慮に入れるものとする。たとえば、予測モデルは、FELICSの元の予測モデルと比較してわずかに調整されるものとする。基本的には、FELICSの予測テンプレートからの最初の2つのケース、ケース1およびケース2が、代わりに、画像のすべてのラインに使用される。各ラインの最初の2つのピクセルはエンコードされずに渡され、残りのピクセルは、最も近い2つの先行ピクセルをコンテキストモデルとして使用する。

【0048】

図2は、2つのケースの予測コンテキストを概略的に示す。ケース1は、ラインの最初の2つのピクセル、ここではx1、x2に関連し、予測およびエンコードの対象ではない。ケース2は、ラインの他のすべてのピクセルについてのもので、ここでは、現在のピクセルとしてピクセルx6について示され、ラインの最も近い2つの先行ピクセルは参照ピクセルN1およびN2、すなわち予測子である。

【0049】

元のFELICSは、その予測子に依存する値の確率分布がどのように見えるかの実験的に検証された仮定を使用する。しかしながら、本方法の予測子は、同じライン上の先行する2つの値にのみ依存するので、想定される確率分布関数が調整されるものとする。

【0050】

図3は、調整された想定される確率分布がどのように見え得るかを概略的に例示する。Lは、2つの先行ピクセルN1、N2の最低ピクセル値で、Hは最高値である。デルタΔは、HとLの間の差である。連続画像の場合、xの値はN2よりもN1に近いものと仮定し、図のLとHとの間に点線が表示される。しかしながら、現在のピクセルのピクセル値が範囲内、すなわち、LとHとの間にあり、後述のSABCを使用してエンコードされているときには、これは利用されない。したがって、範囲内の確率分布は、図に実線で示されているように、平坦であると考えることができる。

【0051】

ラインの現在のピクセルのピクセル値がどのように予測されるかは、そのコンテキストに応じて以下で説明される通りであり、すなわち、ここでは、それが同じライン内の最も近い2つの先行ピクセルとどのように関係しているかである。

【0052】

以下の表1は、現在のピクセルのピクセル値xが、すなわち、ここでは、最も近い近隣ピクセルN1およびN2である、その予測子のピクセル値LおよびHにどのように関係するかに応じて、予測誤差に対応する残差値εがどのように計算され得るかを開示する。これは、図2に関連して上記で説明したケース2の状況に関連する。

【0053】

【表1】

【0054】

理解されるように、残差計算は、元のFELICSのケース2に対応し得る。

【0055】

残差計算に加えて、欠落データの場合など、平坦領域を検出する方法、すなわちRLCを使用する、適応ランレングスエンコードが導入される。ランモードが使用されるべきかどうかを決定するために使用されるコンテキストは、上記と同じコンテキストに基づき得る。すなわち、エンコーダがランモードに入るべきかどうかを決定するために、現在のピクセル値とともに、同じライン内の2つの最も近い先行ピクセルが使用される。N1、N2およびxがすべて同じである場合、典型的には、たとえば0など、欠落データを識別する所定の値である場合、エンコーダはランモードに入るものとする。すなわち、少なくとも3つの連続して発生するピクセルが同じ値を有するとき、これは欠落データによるものである可能性が高く、また、ラインに沿ったさらなるピクセルも欠落データである可能性が高い。

【0056】

図4は、上記のランレングスモードおよびRLC符号化の原理を2つの異なる例で概略的に示す。ランレングスモードに入ると、現在のピクセルxがランレングスモードの開始ピクセルrStartになり、このピクセルおよび後続のピクセルは、ピクセルが異なるピクセル値を有するまで(例1)、またはEnd Of Line(EOL)に到達した場合(例2)、RLCを使用してエンコードされることが示されている。異なるピクセル値またはEOLを有する最初のピクセルは、ランモードの終了ピクセルであるrEndとなる。ランモードがいつ停止するかに応じて、いくつかのrCountピクセルがRLCを使用してエンコードされる。これについては、以下でさらに説明する。

【0057】

図5は、同じラインに最も近い先行ピクセルN1、N2を有するピクセル値xを有する現在のピクセルに関するアクションを要約する形式で、モデリング段階を概略的に示し、例示するフローチャートである。表示、x、N1、N2などは、上記で説明した通りである。

【0058】

以下のアクションは、任意の適当な順序で行われてもよく、および／または、これが可能で適当なときは、時間的に完全にまたは部分的に重複して行われてもよい。

【0059】

アクション501では、L、HおよびそのΔ、すなわちHマイナスLは、N1およびN2から計算される。

【0060】

アクション502では、xがLおよびHのコンテキストでどこに存在するかが決定される。

【0061】

アクション503では、残差εが計算される。

【0062】

アクション504では、どのエンコーダ、すなわちエンコード技法が符号化段階で使用されるか、たとえば、以下でさらに説明するSABCまたはGRCの変形体のうちのいずれが使用されるかが決定される。

【0063】

アクション505では、次のピクセルについて、ランモードがアクティブ化されるべきかどうかが決定される。

【0064】

アクション506では、ランモードであるかどうかがチェックされる。

【0065】

ランモードである場合、アクション507では、現在のピクセル値に基づいて、ランモードが終了すべきかどうか、または行末であるかどうかがチェックされる。

【0066】

ランモードが終了すべきである場合、アクション508で、ランモードの終了があり、rCountが提供され、たとえば、ランモードの対象となるピクセル値をエンコードするために使用される出力が提供され、そうでない場合、アクション509で、rCountがインクリメントされる。

【0067】

上記は、たとえば、ラインの最初のピクセルから始めるなど、ラインのすべてのピクセルに対してすべて実行されるまで、ラインのすべてのピクセルに対して実行されてもよい。さらに、画像のすべてのラインに対して、このように実行されてもよい。

【0068】

2.エンコード段階
エンコード段階の目的は、基本的には、モデリング段階からの残差を受け取り、できるだけ少ないビット数でそれをエンコードすることである。その結果、エンコード段階の出力は可変ビット長のものである。

【0069】

すでに述べたように、使用されるエンコード技法は、FELICSおよびRLCと同様に、GRCの変形体であるSABCから決定されてもよい。特定のピクセルに使用されると決定されたソース符号化方式は、たとえば以下の表2に例示されるように、1ビットまたは2ビットのインデックス符号でエンコードされていてもよい。

【0070】

【表2】

【0071】

したがって、ピクセルxが範囲内に存在するとき、インデックス符号は0であり得、SABCが使用され得る。ピクセルが範囲を下回りまたは上回るとき、インデックス符号はそれぞれ、10および11であり得、GRCの変形体が使用されてもよい。2.3 RLCで、以下でさらに説明するようにRLCが使用されるランレングスモードでは、インデックス符号が使用されなくてもよい。

【0072】

2.1 GRC
本エンコード方法に使用されるよう提案されたGRCは、すでに示したように、FELICSで使用されるものと同様である。主な相違点は、代わりに静的なk値を使用すべきであることであり、これは、k値は画像内のすべてのコンテキストについて同じであるべきであることを意味する。しかしながら、画像は様々な用途で異なり、ある用途および／または状況に最適なk値を選択することができるので、k値は、セットアップ段階またはそれに類似した段階で調整することができる。さらに、いくつかの状況での大きい残差は、k値が適切に選択されないとき、非常に大きい符号語になる可能性があり、これは上記のために困難であり得るので、単進符号(unary code)の最大符号長が使用されるべきである。ここでは、単進符号の最大符号長をq_maxと呼ぶ。GRC(上記参照)に使用されるインデックス符号がビット長2であるとき、q_maxはq_max=N-2と定義され得、ここで、Nはビット深度であり、したがって、単進符号が続くインデックス符号は、ビット深度に等しい最大長を有する。q_max符号は、単進符号のように最後にゼロを付ける必要はない。q_maxに達すると、残余を含む単進符号に続く代わりに、正規の二進表現を有する元のピクセル値が代わりにまたは追加で提供されてもよい。たとえば、ビット深度が8であり、現在のピクセル値x=100、ε=25、k=0であり、コンテキストからの結論では現在のピクセルが範囲を下回っている場合、本エンコード方法のGRCの変形体による符号語は、次の通りである。

【0073】

【数1】

【0074】

これは、同じパラメータに対してFELICSで使用される通常のGRCから得られる符号語と比較され得る。

【0075】

【数2】

【0076】

2.2 SABC
FELICSで使用される調整バイナリ符号化(ABC)は、図3に関連して上述した理由、たとえば他の予測子が使用されているので、本エンコード方法に対して有効であるべきではない確率分布を想定している。本エンコード方法では、元のFELICSでの通常のABCは、したがって、さらに単純化され、SABCが得られ得る。SABCでは、FELICSによって使用される通常のABCの回転シフト操作が削除される場合がある。通常のABCでは、パラメータ計算、循環回転、符号語生成の3つの手順が必要である。これらの操作は、ハードウェア実装に適した算術演算に変換することができる。しかしながら、これによって処理速度が著しく制限される可能性がある。SABCでは、バイナリ値は、xがLまたはHに近いエッジの場合のみではなく、常にupper_boundビットを使用して符号化される。これは、いくつかの場合には、元のFELICSと比較して、符号語を表すために1つの追加ビットを使用する準最適な符号が使用され得ることを意味する。

【0077】

SABCが好ましいが、元のFELICSのようにABCも使用することができるが、ハードウェア実装の場合にはいくつかの欠点を伴うことに留意されたい。図3に関連して上述したような想定された確率分布では、当業者によって理解されるように、範囲内のピクセルに、SABCおよび通常のABC以外のバイナリ符号化技法を使用することも可能である。

【0078】

一般に、ピクセル値IDに基づいて決定されたピクセル値の圧縮のためのエンコードのタイプは、「範囲内」領域または「範囲外」領域(上回るまたは下回る)にあり、それぞれの領域における確率分布を考慮し、さらに、たとえば、実装を容易にするため、コストを削減するため、低レイテンシを実現するためなど、実装のためのハードウェア実装に関してなど、他の要件も考慮するものとする。

【0079】

2.3 RLC
図4に関連して上記で説明したように、たとえば0など、欠落データに起因する以外のピクセル値については、同じ値のより長いランの確率が非常に低いので、ランレングスモードおよびRLCは、欠落データをより効率的に処理するために使用される。RLCは、元のFELICSでは使用されない。

【0080】

非常に平坦な表面であっても、高さマップ、すなわち、高さ測定に起因するようなピクセル値に何らかのノイズおよび不整合がある可能性がある。これは、様々なテスト範囲のデータ画像を使用して実験的に証明されている。RLCが通常のGRCよりも有利なより長いランでは、ほとんどのランが欠落データに対応するゼロのランであることがわかった。ゼロ以外の値のランは、しばしば短すぎて、特に、ランの最初の2つのピクセルは、依然として、RLCを使用せずに符号化される可能性があることを考慮すると、RLCは有利ではない。図4に関連してすでに上述したように、ランレングスモードになると、rStartとrEndとの間のピクセル数がカウントされる。図4の例1のようにrEndに達すると、現在のピクセルxはRLCを使用せず、たとえば代わりにSABCまたはGRCを使用してエンコードされ、累積ランカウント、すなわちrCountは、通常のバイナリ値としてエンコードされ得る。図4の例2では、行末に達すると、エンコーダは、ランモードを終了し、累積ランカウント、すなわちrCountは、通常のバイナリ値としてエンコードされ得る。たとえば使用されるカメラ、たとえばその画像センサーによって決定される、2560ピクセルの最大ライン幅の場合、3ピクセルがrStartを決定するために使用されるので、エンコードされたランの最大長は2557である。このため、ランレングスは、常にlog₂(2557)=12ビットを使用してバイナリ値としてエンコードされてもよい。デフォルトではデコーダは、すなわち、あらかじめ決められた順序で、たとえば左から右に、ラインをデコードすることがあらかじめ決められている場合があるので、ランレングスモードがアクティブであることをデコーダに知らせるためのいかなるインデックスビットも必要ない場合があり、むしろRLCが使用される。デコーダは、デコードされた最後の3つのピクセルを見ることによって、これを自動的に把握することができる。

【0081】

RLCが行末の前に終了するとき、たとえば図4に関連して上記で説明したように、N1とN2の両方が0である場合があり、それは、ランレングスモードが入力される前のように、継続し得る。別のオプションは、あたかもラインの最初のピクセルであるかのように開始することであり、すなわち、ランレングスモードの終了後の最初の2つのピクセルは、その後、エンコードの対象とならない、すなわち、ピクセル値はエンコードされないままである。またさらなるオプションは、「欠落データ」に対応していなかったライン内で最も近い直前のN1、N2など、ランレングスモードに入る決定の部分ではなかったランレングスモードの前の最新のN1およびN2に関する情報を「記憶する」、すなわちメモリに記憶することである。

【0082】

3.データパッカー
ソースコーダは、可変長のビット文字列を出力するので、これらのビット文字列を固定サイズのデータワード、すなわち、同じサイズのデータワードに連結するために、データパッカーが使用されるものとする。符号語の最大長は、上述したように、ビット深度の2倍である。エンコーダが最大16ビットまでのビット深度を処理するように設計されている場合、符号語の最大長は、したがって32ビットである。したがって、この場合のデータパッカーは、32ビットワードをパックし、出力するように設計されていなければならない。また、32ビットのワードサイズは、撮像システムで一般的に使用されるものである。データパッカーにおけるバッファオーバーフローを避けるために、使用されるバッファは、少なくとも2倍のサイズ、たとえば64ビット幅であるものとする。32ビットの完全なワードが利用可能であるとき、それは、出力されてもよく、バッファはシフトされ、出力されなかったピクセルのみが残される。このようにして、エンコーダは常に一定のビット幅のワードを出力することができる。画像のラインは個別にエンコードされなければならないので、ラインが終わるとき特殊なケースがある。

【0083】

図6A〜図6Bは、それぞれ、行末に到達したとき、すなわち、上述のようにデータワードに「パックする」、すなわち挿入されるラインのエンコードされたピクセル値がこれ以上ないときに考慮すべき関連する異なるケースを概略的に示す。示されたケースでは、x1は、ビットが1つの同じピクセルx1に属すること、すなわち、この場合、行末に到達したときを示すのに役立つので、ここでは、したがってラインの最後のピクセルであるこのピクセルのエンコードされたピクセル値の一部であることを示している。符号長、すなわち、ピクセルx1のエンコードされたピクセル値の長さは、図でわかるように、9ビットである。ライン内のx1に先立つピクセルに属するビットは、x2およびx3で示される。

【0084】

図6Aは、すなわち、ここではx1である、ラインの最後のピクセルのエンコードされたピクセル値からのビットが、データワード、ここでは32ビットを完全に「満たす」わけではない、完全な32ビットワードが行末では利用できないときを示す。たとえば、バッファがラインの先行ピクセルのビットを含まないとき(後述する図6Bのように)である。この場合、ゼロは、完全な32ビットワードが利用可能であり、出力することができるまで、最後に連結、すなわち、挿入され得、この場合、出力された32ビットワードは、ピクセルx1のエンコードされたピクセル値のみを含む。デコード時、これは、ピクセルx1のエンコードされたピクセル値について有効なビットのみを取得するために、単にデータワードを切り捨てることであり得る。

【0085】

図6Bは、バッファの観点から、行末に正確に1つの32ビットワードが利用可能であるとき、すなわち、行の最後のピクセルのエンコードされたピクセル値からのビット、ここではx1が入力され、それによってデータワード、ここでは前記32ビットワードを完全に「満たす」ときを示している。ラインの先行ピクセルのエンコードされたピクセル値のビット、ここではピクセルx2およびx3は、すでにバッファ内にあり、次いで、前記32ビットのデータワードは、ピクセルx1のエンコードされたピクセル値からのビット、ここでは5ビットで完了になり、データワードを出力し、バッファから対応するビットを削除することができる。この場合、出力は、したがって、「通常通り」、すなわち、単に32ビットワードの出力であり得る。

【0086】

図6Bはまた、バッファの観点から、32ビットワードよりも多くのビットが利用可能なとき、ここでは、バッファが、図6Bの状況の後にx1から残りの(4)ビットをシフトしたときを示している。バッファシフトの原理は、そのようにして示され、理解されるように、状況は、そのとき、図6Aと同様であり、対応する方法で管理することができる。

【0087】

上記から理解されるように、異なるラインのピクセル値はデータワード内で混合されず、これは、ラインの並列デコードの処理を容易にし、エンコード中に回避された一種のライン依存性をこの段階で導入する必要はないので有益である。

【0088】

上述したように、エンコード方法は、ラインに依存しないラスタスキャン順で画像をエンコードしてもよい。この理由は、エンコードされたラインを、たとえば受信ユニット120に対応するホストコンピュータ上で並列にデコードすることができるようにするためであり、これによって総デコード時間が減少する。32ビットワードが出力されるたびに、カウンタがインクリメントされ得る。ラインがエンコードされたとき、特定のラインについて到達した総カウント、たとえば整数値は、すなわちエンコードされたピクセル値である、符号を含むもの以外の別個のベクトル、すなわちデータアレイに記憶されてもよい。ベクトルは、画像のラインごとに別個の値、たとえば、そのラインについてカウンタによって到達した数、すなわち累計カウントに対応する値で形成されてもよく、そのような各値は、したがって、画像のエンコードされたピクセル値を含むデータワードの中で、対応するラインがどこから始まるのかを識別する。

【0089】

カウントは、エンコードされた画像データとともに、通信リンク140、たとえばギガビットイーサネットリンクを介して送信されてもよい。カウントに関する情報は、好ましくは、たとえば、エンコードされたデータに使用されるチャネルとは別の補助チャネル上で送信されてもよい。通信リンクがいわゆるGenlCam/GigE Visionリンクの場合、カウント、たとえばベクトルをいわゆるチャンクデータとして送信してもよい。

【0090】

ラインの独立性を維持することに加えて、カウント、すなわち、各ラインがデータワードのうちのどこから始まるかに関する情報を別々に送信することのさらなる利点は、データが通信リンク内で失われた場合、これらのラインについてはデータが失われるが、画像の残りの部分をデコードすることは依然として可能であるということである。

【0091】

ホストコンピュータのデコーダ、たとえば、ソフトウェアで実装されてもよいデコーダ152は、それによって、圧縮画像をベクトルからの情報とともに取得してもよい。このようにして、デコーダは、たとえば、32ビットワードのビット文字列など、取得された圧縮データ内の個々のラインを見つけ、それらを並列に復元することができる。

【0092】

これまで、エンコーダの観点から説明してきた。しかしながら、了解されるように、これに基づいて、デコーダは、設計および実装がかなり簡単である。エンコーダ、モデリング、エンコード、データパッキングなどの段階および実行されるアクションは、単純に逆にしてもよい。デコーダ、たとえばデコーダ152は、データワードにおける圧縮されたデータの文字列を、たとえば、各ラインの符号サイズを含む前記ベクトルとともに受信してもよい。ラインの開始が見つかった後、それを他のラインから個別にデコードすることができる。デコーダは、「これまでに」どれだけのピクセルがデコードされたかを常に知っており、予想されるライン幅は、典型的には既知であり、実際には、常に既知とすることができるので、符号のサイズを知る必要はない。

【0093】

図7は、上記で説明したエンコード方法に基づく本明細書の実施形態による方法の実施形態を概略的に示すフローチャートである。

【0094】

方法を形成し得る以下のアクションは、複数のラインのピクセルを含むデジタル画像、たとえば、上述したような範囲のデータを含み得るラインスキャンされたデジタル画像のピクセル値をエンコードするためのものである。この方法およびそのアクションは、以下で一例として使用されるエンコーダ131によって実行されてもよい。すなわち、エンコードは、デジタル画像の無損失圧縮を達成するためのものである。

【0095】

したがって、エンコードは、デジタル画像の、すなわちその画像データの圧縮のためのものであるとし、圧縮は、無損失、すなわち非破壊的であるものとする。

【0096】

以下のアクションは、前記複数のラインの各々について、すなわち、それによって画像全体をエンコードすることができ、たとえば圧縮することができるように実行される。さらに、以下のアクションは、任意の適当な順序で行われてもよく、および／または、これが可能で適当であるときは、時間的に完全にまたは部分的に重複して行われてもよい。

【0097】

アクション701
エンコーダ131は、ラインのエンコードされていないピクセル値を取得し、たとえば、図1Bのカメラユニット130などカメラの画像センサーからそれらを受信し、各ラインは、たとえば、図1Aに示されているようにキャプチャされたプロファイルに対応してもよい。ピクセル値は、エンコーダが動作する画像センサーの出力、たとえばカメラユニット130の画像センサーの出力によって決定されるレートでなどのように、たとえば一度に1ラインなど、ラインごとに取得されてもよい。

【0098】

アクション702
エンコーダ131は、ラインの1つまたは複数のピクセルの各々について、デジタル画像の前記無損失圧縮において、たとえばピクセルxなど、ピクセルのエンコードされていないピクセル値をエンコードするためにどのエンコードが使用されるかを決定する。決定は、前記エンコードされていないピクセル値が、前記ラインの他の最も近い近隣ピクセル、たとえばピクセルN1、N2などのエンコードされていないピクセル値とどのように関係しているかに基づく。エンコードは、無損失圧縮のためのエンコードであるものとする。どのエンコードが使用されるかを決定することは、使用されるエンコード技法を決定することであり得る。この決定は、他のラインのピクセル値に依存しない、すなわち、同じラインのピクセル値のみに基づくものとする。また、したがって、エンコードは、前記エンコードされていないピクセル値が、前記最も近い近隣ピクセルのエンコードされていないピクセル値とどのように関連しているかに基づき得る。

【0099】

このアクションは、たとえば上述のアクション501〜505に完全にまたは部分的に対応し得、また、予測／モデリング段階に関連して上記で説明したこと、および「1.予測／モデリング段階」のセクションで説明したことに完全にまたは部分的に対応し得る。

【0100】

前記最も近い近隣ピクセルは、好ましくは先行ピクセルであり、ラインに沿ったある方向における、2つの最も近い先行ピクセル、たとえば、N1、N2などである。したがって、2つの最も近い先行ピクセルは、たとえば、現在のピクセルに対応するピクセルxなど、決定の対象となるピクセルに先行するものとする。

【0101】

ラインは2つの方向を有し、上記のある方向は、それらのいずれであってもよく、典型的には、ラインの最初のピクセルから最後のピクセルまでの所定のものである。この方向は、ピクセル値が読み取られる、または操作される順序に対応する方向であってもよく、ラインに関連付けられた操作方向と呼ばれてもよい。

【0102】

前記複数の後で発生するピクセルの各々についての前記エンコードされていないピクセル値が、たとえばN1、N2など、前記最も近い近隣ピクセルのエンコードされていないピクセル値と同じである場合、たとえば、欠落データを示し得る、または識別し得る、0など、それらが同じ所定の値を有する場合など、たとえば、上記のrStart〜sEndの間など、1つまたは複数の後で発生するピクセルのピクセル値のエンコードのためにRLCを使用することを決定してもよい。

【0103】

これは、RLCがどのように使用され、次いで適用され得るかを決定する方法に関する上記の説明に完全または部分的に対応し得る。

【0104】

ピクセル値、または少なくとも一部は、前記最も近い近隣ピクセルを使用した予測、および予測の計算された残差値に基づいてエンコードされるものとし、計算された残差値は、エンコードされていないピクセル値が、前記最も近い近隣ピクセルの少なくとも1つのエンコードされていないピクセル値にどのように関連しているかに基づく。

【0105】

これは、上述した研究の結果として得られた適切なエンコード方法の結論と一致する。典型的にはRLCは予測に基づくとは考えられないが、SABC、GRC、さらにはRLCのすべては、同じ予測子を使用して、予測に基づき得ることに留意されたい。いずれにしても、RLCに加えて、予測に基づくピクセル値、たとえば欠落データに対応しないすべてのピクセル値のエンコードがあるはずである。

【0106】

前記エンコードされていないピクセル値が、たとえば、N1、N2など、前記最も近い近隣ピクセルの前記エンコードされていないピクセル値の間にある場合、前記エンコードされていないピクセル値のエンコードのために、上述したように、SABCなど、たとえば、第1のタイプの無損失符号化など、第1のタイプの符号化を使用すること、および、前記エンコードされていないピクセル値が、たとえば、N1、N2など、前記最も近い近隣ピクセルの前記エンコードされていないピクセル値のうちのいずれか1つを下回りまたは上回る場合、前記エンコードされていないピクセル値のエンコードのために、たとえば、上述したように修正されたGRCなど、GRCに基づく、たとえば、第2のタイプの無損失符号化など、別の第2のタイプの符号化を使用することが決定されてもよい。したがって、第1および第2のタイプの符号化はいずれも、予測に基づくものであるものとする。

【0107】

これによって、たとえば、上述したように、図4に示したように、予測の確率分布を利用することが可能となる。したがって、異なるタイプの符号化は、問題の符号化が関係する範囲での予測の確率分布を利用するものとする。上述したように、たとえば、FELICSで使用されている従来のABC、または他のバイナリ符号化がSABCの代わりに使用されてもよいことに留意されたい。また、第2のタイプについては、GRC以外の他の符号化が考慮されてもよい。

【0108】

それにもかかわらず、上述したように、前記第2のタイプの符号化は、好ましくは、コンテキストに依存しないk値および所定の最大符号長を使用するように構成されたゴロム-ライス符号化、すなわちGRCである。したがって、k値は、前記最も近い近隣ピクセルに依存せず、たとえば、ラインのすべてのピクセルについて、またはデジタル画像全体について同じであってもよい。上記ですでに示された理由から、後者が好ましい可能性がある。

【0109】

アクション703
次いで、エンコーダ131は、決定に基づいて、エンコードされた値を提供してもよく、エンコードされたピクセル値は、エンコーダ131によってエンコードされた前記エンコードされていないピクセル値であり、デジタル画像の前記無損失圧縮の一部である。これは、エンコーダ131は、決定に基づいて、前記エンコードされていないピクセル値のうちの1つまたは複数をそれぞれエンコードされたピクセル値にエンコードすること、および／または、エンコーダが、決定から完全にまたは部分的に独立して、前記エンコードされていないピクセル値のうちの1つまたは複数を最初にエンコードし、次いで、決定に基づいて、エンコードされた値を選択することを含み得る。各エンコードされていないピクセル値、または少なくともいくつかのエンコードされていないピクセル値を、最初に、たとえば自動的に、複数のタイプのエンコード技法を使用してエンコードし、次いで、決定に基づいて、エンコードされた値を選択することによって、エンコードされたピクセルを提供することは、たとえばハードウェア実装の理由から、有益であり得る。

【0110】

このアクションは、エンコード段階に関連して上述したもの、および「2.エンコード段階」のセクションで説明したものに完全にまたは部分的に対応し得る。

【0111】

アクション704
エンコーダ131は、複数の等長データワードに含まれる各ラインのエンコードされたピクセル値を提供し得る。

【0112】

すなわち、所定の長さのデータワードは、固定された、典型的には等しい長さのデータワードに対応しており、各々、ある長さのビット文字列に対応している。たとえば32ビットなど等長データワードが、たとえば使用されてもよく、長さは、たとえば、実装のために使用されるハードウェアに基づいてあらかじめ定められていてもよい。

【0113】

ラインの異なるピクセルのエンコードされたピクセル値は、前記等長データワードの中でデータワードを共有してもよく、異なるラインのエンコードされたピクセル値は、前記等長データワードの中の別々のデータワードにあってもよい。すなわち、ピクセル値は、固定長データワードに「パックされ」ているが、エンコードとは無関係に維持されたラインを有する。

【0114】

このようにしてデジタル画像の圧縮データを含み得る等長データワードは、次いで、たとえば受信ユニット150の受信機151などの受信機、たとえばホストコンピュータに送信されてもよい。したがって、送信は、帯域幅の制限に関連付けられていてもよい通信リンク、たとえば通信リンク140を介して行われてもよい。

【0115】

データワードのエンコードされたピクセル値は、次いで、デコーダ152によってデコードされてもよく、それによって、圧縮されたデジタル画像の復元が達成され得る。

【0116】

このアクションは、データパッカーに関連して上述したもの、たとえば「3.データパッカー」のセクションで説明したものに完全にまたは部分的に対応し得る。

【0117】

アクション705
エンコーダ131は、各ラインに関連して、前記エンコードされたピクセル値を含む前記等長データワード内のラインの開始位置を識別するそれぞれの識別子を提供してもよい。したがって、ラインごとにそのような識別子が1つあり得る。了解されるように、識別子は、等長データワードとは別個のものであり、すなわち、等長データワードとは別個に提供されるものとし、すなわち、データワードには含まれないものとする。

【0118】

各識別子は、たとえば、デジタル画像の第1のラインのエンコードされたピクセル値を含む、第1のデータワードの開始に関連して、それが関連付けられたラインの開始位置を識別する値であってもよい。ラインごとのピクセル数は、デジタル画像およびたとえば使用される画像センサーによって決定され、したがって、本明細書の実施形態の文脈では、あらかじめ定められたものとみなされ得る。ラインごとのピクセル数は、たとえば、デジタル画像を生成するために使用される画像センサーの解像度および／または設定によって決定されてもよい。

【0119】

識別子は、すべてのライン、すなわち、デジタル画像全体のエンコードされたピクセル値を含むデータワード内で、あるラインのすべてのピクセル値を見つけることを可能にする。したがって、あるラインのエンコードされたピクセル値は、識別子、およびラインごとのピクセル数に関する知識に基づいて見つけられ、取得され得る。次いで、エンコードされたピクセル値は、元のエンコードされていないピクセル値にデコードすることができる。これは、ラインのデコードを並列に実行することができ、ラインのエンコードされたピクセル値を含むデータワードが取得される、たとえば受信されるとすぐに開始することができることを意味する。識別子は、たとえば、上述したように、ラインごとに1つの値を有する、1次元アレイまたはベクトルに含まれる値の形式で提供されてもよく、また、たとえば、前記データワードと関連して提供されてもよく、たとえば、並列に、またはデータワードの転送と一緒に、たとえば、同じもしくは別個のデータチャネルを使用して、デコーダに転送されてもよい。

【0120】

言い換えれば、識別子は、デジタル画像のラインごとに1つの値を含むデータ構造内の別個の値として提供されてもよく、各値は、前記等長データワードのうち、たとえば、第1のデータワードなど、参照データワードに関連して、それぞれのラインの開始位置を示す。第1のデータワードは、典型的には、デジタル画像の第1のピクセルのピクセル値を含むデータワードであってもよい。

【0121】

たとえばベクトル内の識別子は、等長データワードとともに、すなわちそれに関連して、受信機に送信されてもよい。したがって、識別子は、通信リンク140を介してデータワードとともに送信され、受信機151によって受信され、データワードのエンコードされたピクセル値がデコーダ152によってデコードされ、それによって、圧縮されたデジタル画像の復元が達成され得る。

【0122】

また、このアクションは、データパッカーに関連して上述したもの、たとえば「3.データパッカー」のセクションで説明したものに完全にまたは部分的に対応し得る。

【0123】

図8は、エンコーダ131に対応し得るエンコーダ800の実施形態を示すための概略ブロック図である。概略ブロック図はまた、エンコーダ800、たとえばデバイス131が、図7に関連して上述した方法およびアクションを実行するようにどのように構成され得るかの実施形態を示すためのものである。

【0124】

したがって、エンコーダ800は、デジタル画像の無損失圧縮を達成するために、複数のラインのピクセルを含む前記デジタル画像のピクセル値をエンコードするためのものである。

【0125】

エンコーダ800は、処理手段などの処理モジュール801、たとえばプロセッサなどの1つまたは複数の処理回路、回路を含む、1つまたは複数のハードウェアモジュール、ならびに／あるいは、前記方法および／またはアクションを実行するための1つまたは複数のソフトウェアモジュールを含み得る。

【0126】

エンコーダ800は、コンピュータプログラム803を含むまたは記憶するなど、それを含み得るメモリ802をさらに含んでいてもよい。コンピュータプログラム803は、前述の方法および／またはアクションを実行するためにエンコーダ800によって直接または間接的に実行可能な「命令」または「コード」を含む。メモリ802は、1つまたは複数のメモリユニットを含んでいてもよく、本明細書の実施形態の機能およびアクションに関与する、または実行するための、構成、データおよび／または値などのデータを記憶するようにさらに配置されてもよい。

【0127】

さらに、エンコーダ800は、例示的なハードウェアモジュールとして、データの処理およびたとえばエンコードに関与する処理回路804を含んでいてもよく、1つまたは複数のプロセッサまたは処理回路を含み、またはそれらに対応していてもよい。処理モジュール801は、たとえば、処理回路804を含んでいてもよく、たとえば、処理回路804「の形で具現化され」または「によって実現され」てもよい。これらの実施形態では、メモリ802は、処理回路804によって実行可能なコンピュータプログラム803を含んでいてもよく、それによって、エンコーダ800は、前記の方法および／またはそのアクションを実行するように動作可能であるか、または構成される。

【0128】

典型的には、エンコーダ800、たとえば処理モジュール801は、入出力(I/O)モジュール805を含み、たとえば、他のデバイスへの情報の送信および／または他のデバイスからの情報の受信、たとえば、デジタル画像の圧縮された画像データに対応するエンコードされたピクセル値を受信ユニット150に送信することなど、他のユニットおよび／またはデバイスとの間の任意の通信を、たとえば実行することによって、それに関与するように構成されている。I/Oモジュール805は、適用できる場合、モジュールを取得すること、たとえば、モジュールを受信すること、および／またはモジュールを提供すること、たとえば、モジュールを送信することによって例示され得る。

【0129】

さらに、いくつかの実施形態では、エンコーダ800、たとえば処理モジュール801は、本明細書の実施形態のアクションを実行するためのハードウェアおよび／またはソフトウェアモジュールを例示するように、取得モジュール、提供モジュール、エンコードモジュールのうちの1つまたは複数を含む。これらのモジュールは、処理回路804によって完全にまたは部分的に実装されてもよい。

【0130】

エンコーダ800、および／または処理モジュール801、および／または処理回路804、および／またはI/Oモジュール805、および／または取得モジュールは、したがって、図7に関連して上述したように、前記複数のラインの各々について、ラインの前記エンコードされていないピクセル値を取得するように、動作可能であるか、または構成されていてもよい。

【0131】

さらに、エンコーダ800、および／または処理モジュール801、および／または処理回路804、および／または決定モジュールは、前記複数のラインの各々について、前記図7に関連して上述したように、デジタル画像の前記無損失圧縮において、たとえば現在のピクセルxなど、ピクセルのエンコードされていないピクセル値をエンコードするためにどのエンコード使用するかを、ラインの前記1つまたは複数のピクセルについて、決定するように、動作可能であるか、または構成されていてもよい。

【0132】

さらに、エンコーダ800、および／または処理モジュール801、および／または処理回路804、および／またはI/Oモジュール805、および／または提供モジュールは、したがって、図7に関連して上述したように、決定に基づいて、前記エンコードされたピクセル値を提供するように動作可能であるか、または構成されていてもよい。

【0133】

また、エンコーダ800、および／または処理モジュール801、および／または処理回路804、および／またはI/Oモジュール805、および／または提供モジュールは、したがって、図7に関連して上述したように、前記等長データワードの数に含まれる各ラインのエンコードされたピクセル値を提供するように、動作可能であるか、または構成されていてもよい。

【0134】

さらに、エンコーダ800、および／または処理モジュール801、および／または処理回路804、および／またはI/Oモジュール805、および／または提供モジュールは、したがって、図7に関連して上述したように、各ラインに関連して、前記等長データワード内のラインの開始位置を識別する前記それぞれの識別子を提供するように動作可能であるか、または構成されていてもよい。

【0135】

図9は、上述した前記エンコーダ800に前記方法およびアクションを実行させるためのコンピュータプログラムおよびその担体に関するいくつかの実施形態を示す概略図である。コンピュータプログラムは、コンピュータプログラム803であってもよく、処理回路804および／または処理モジュール801によって実行されると、エンコーダ800に上述したように実行させる命令を含む。いくつかの実施形態では、コンピュータプログラムを含む担体、または、より具体的にはデータ担体、たとえばコンピュータプログラム製品が提供される。担体は、電子信号、光信号、無線信号、およびコンピュータ可読記憶媒体、たとえば図に概略的に示されるようなコンピュータ可読記憶媒体901のいずれかであってもよい。したがって、コンピュータプログラム803は、コンピュータ可読記憶媒体901に記憶されていてもよい。担体によって、一時的な伝搬する信号が除外されてもよく、データ担体は、それに対応して、非一時的データ担体と名付けられてもよい。コンピュータ可読記憶媒体であるデータ担体の非限定的な例は、メモリカードまたはメモリスティック、CDもしくはDVDのようなディスク記憶媒体、または典型的にはハードドライブもしくはソリッドステートドライブ(SSD)に基づく大容量記憶デバイスである。コンピュータ可読記憶媒体901は、コンピュータネットワーク902、たとえばインターネットまたはローカルエリアネットワーク(LAN)を介してアクセス可能なデータを記憶するために使用されてもよい。コンピュータプログラム803は、さらに、純粋なコンピュータプログラムとして提供されてもよく、または1つもしくは複数のファイルに含まれてもよい。1つまたは複数のファイルは、コンピュータ可読記憶媒体901に記憶されてもよく、たとえば、サーバを介してなど、図に示されているように、たとえば、コンピュータネットワーク902を介してなど、たとえば、ダウンロードを介して利用可能であり得る。サーバは、たとえば、ウェブまたはファイル転送プロトコル(FTP)サーバであってもよい。1つまたは複数のファイルは、たとえば、処理回路804によって実行されることによって、前記第1のノードを上述したように実行させるために、前記第1のノードへの直接または間接的なダウンロードおよび前記第1のノード上での実行のため
の実行可能なファイルであってもよい。また、1つまたは複数のファイルは、前記エンコーダ800を上述したように実行させるためのさらなるダウンロードおよび実行の前に、それらを実行可能にするために、同じまたは別のプロセッサを含む中間ダウンロードおよびコンパイルのためのものであってもよいし、代替的なものであってもよい。

【0136】

上述の任意の処理モジュールおよび回路は、ソフトウェアおよび／またはハードウェアモジュールとして、たとえば、既存のハードウェアに実装され、および／または特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)などとして実装されてもよいことに留意されたい。また、上述の任意のハードウェアモジュールおよび／または回路は、たとえば、単一のASICまたはFPGAに含まれていてもよく、または個別にパッケージ化されているかシステムオンチップ(SoC)に組み立てられているかに関わらず、複数の別々のハードウェアコンポーネントの間に分散されていてもよいことにも留意されたい。

【0137】

当業者であれば、本明細書で説明したモジュールおよび回路は、ハードウェアモジュール、ソフトウェアモジュール、アナログおよびデジタル回路、ならびに／またはソフトウェアおよび／もしくはファームウェアで構成された1つまたは複数のプロセッサ、たとえばメモリに記憶されたものの組合せを指し得ること、1つまたは複数のプロセッサによって実行されると、ノードおよびデバイスを、上述した方法およびアクションを実行するように構成し、および／またはノードおよびデバイスに上述した方法およびアクションを実行させてもよいことは諒解されよう。

【0138】

本明細書の任意の識別子による識別は、暗黙的であっても明示的であってもよい。識別は、あるコンテキスト、たとえば、あるコンピュータプログラムまたはプログラムプロバイダについて一意であってもよい。

【0139】

本明細書で使用される「メモリ」という用語は、デジタル情報を記憶するためのデータメモリ、典型的には、ハードディスク、磁気ストレージ、媒体、ポータブルコンピュータディスケットまたはディスク、フラッシュメモリ、ランダムアクセスメモリ(RAM)などを指し得る。さらに、メモリは、プロセッサの内部レジスタメモリでもよい。

【0140】

また、第1のノード、第2のノード、第1の基地局、第2の基地局などのような任意の列挙する用語は、したがって、非限定的とみなされるものとし、したがって、用語は、ある階層的な関係を暗示するものではないことにも留意されたい。それに反して明示的な情報がなければ、列挙による命名は、単に異なる名称を達成する方法とみなされるものとする。

【0141】

本明細書で使用される「構成されている」という表現は、処理回路が、ソフトウェアまたはハードウェア構成によって、本明細書に記載されているアクションのうちの1つまたは複数を実行するように構成されている、または適応されていることを意味し得る。

【0142】

本明細書で使用される「数」または「値」という用語は、二進数、実数、虚数または有理数など任意の種類の数字を指し得る。さらに、「数」または「値」は、文字または文字列のような1つまたは複数の文字であってもよい。また、「数」または「値」は、ビット文字列で表されてもよい。

【0143】

本明細書で使用される「得る」および「いくつかの実施形態では」という表現は、典型的には、記載された特徴が、本明細書に開示された任意の他の実施形態と組み合わされてもよいことを示すために使用されている。

【0144】

図面では、いくつかの実施形態のみに存在し得る特徴は、典型的には、点線または破線を使用して描かれている。

【0145】

本明細書で使用される「送信する」および「送る」という表現は、典型的には交換可能である。

【0146】

「含む」または「含んでいる」という語を使用するとき、それは非限定的なものとして解釈され、すなわち「少なくとも〜からなる」を意味すると解釈されるものとする。

【0147】

本明細書の実施形態は、上述した実施形態に限定されない。様々な代替、修正、および均等物が使用されてもよい。したがって、上記の実施形態は、添付の特許請求の範囲によって定義される本開示の範囲を限定するものとみなされないものとする。

【符号の説明】

【0148】

100 測定システム
110 光源
111 特定の光パターン
112 光線
120 第1のオブジェクト
121 第2のオブジェクト
122 コンベヤベルト
123 座標系
130 カメラユニット
131 エンコーダ／デバイス
132 送信機
140 通信リンク
140-1〜140-K プロファイル
150 受信ユニット
151 受信機
152 デコーダ
200 システム
800 エンコーダ
801 処理モジュール
802 メモリ
803 コンピュータプログラム
804 処理回路
805 入出力(I/O)モジュール（I/O回路）
901 コンピュータ可読記憶媒体
902 コンピュータネットワーク

【図1A】

【図1B】

【図2】

【図3】

【図4】

【図5】

【図6A】

【図6B】

【図7】

【図8】

【図9】