JP2002271208A - ハフマン符号化・復号化法 - Google Patents

Abstract

(57)【要約】 【課題】 少ない処理資源とハードウェアを使い極めて
短時間で達成できるハフマン符号化と復号化の方法を提
供する。 【解決手段】 特にパックしたデータ形式から行なうハ
フマン符号化は、符号長によって異なる２つのテーブル
形式を使うと簡単化することができる。これにより、ハ
フマン・テーブルのサイズを小さくすることもできる。
ハフマン復号化法は、圧縮したデータ・ストリーム中の
有効なハフマン符号の長さに対して試験を行なうと共
に、試験基準に対応するオフセットを使うことにより、
実行時間を短縮することができる。これにより、ハフマ
ン・テーブルの記号値への直接索引を生成する特定の試
験結果が得られる一方、このような目的に使う参照テー
ブルのサイズを大幅に小さくすることができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に様々な用途
用の画像圧縮に関し、特に、パックした形式で離散コサ
イン変換（Discrete Cosine Transform:ＤＣＴ) ブロッ
クを格納するための構造と組み合わせた、ＪＰＥＧ（Jo
int Photographic Experts Group）標準に従うハフマン
（Huffman)エントロピー符号化と復号化に関する。

【０００２】

【従来の技術】写実画像やグラフィックス画像には、極
めて大量のデータが含まれている。したがって、ディジ
タル・データ・プロセッサで伝送したり処理したりする
ことができるようにディジタル化する場合、これらの画
像を構成している画素を忠実度良く表現するには、数メ
ガ・バイトを必要とする場合が多い。画像圧縮の目的
は、記憶のコストや伝送の時間とコストを節約するため
に、より少ないデータで画像を表現することである。最
も効率的な圧縮は、元の画像を正確に再現するのではな
く、それを近似することにより達成される。ＪＰＥＧ標
準を使うと、様々な用途の間で画像を交換するのが可能
になると共に、マルチメディア用途においてディジタル
連続色調カラー画像を提供する機能を実現することがで
きる。ＪＰＥＧ標準については、ペネベーカーとミッチ
ェル著『ＪＰＥＧ静止画像データ圧縮標準』（"JPEG St
ill Image Data Compression Standard" by Pennebaker
and Mitchell, published by Van Nostrand, 1993.)に
詳細に説明されている。

【０００３】ＪＰＥＧは、２つの空間次元を有し、グレ
ー・スケール（白黒の階調）または色情報を備え、時間
に依存しない画像を主として扱う。この点で、ＭＰＥＧ
（Moving Picture Experts Group）と区別される。ＪＰ
ＥＧ圧縮を使うと、必要な記憶容量を１／１０以下にす
ることができると共に、プロセスにおけるシステムの応
答時間を改善することができる。ＪＰＥＧ標準の主目的
は、所定量のデータ、および／または、利用可能な伝送
時間もしくは処理時間、に対して最大の画像忠実度を実
現することである（「Ａおよび／またはＢ」は「Ａおよ
びＢ、Ａ、またはＢ」を表わす）。そして、これらデー
タ圧縮の尺度は、すべて達成されている。データを１／
２０以下に圧縮しても（したがって伝送時間または処理
時間を１／２０以下に減らしても）平均的な視聴者は気
付かない、ということは多くの場合に正しい。

【０００４】ＪＰＥＧ用の基本構成要素の１つに、離散
コサイン変換（ＤＣＴ) がある。この離散コサイン変換
の重要な側面として、非相関係数を生成する点が挙げら
れる。係数が相関しないということは、圧縮にとって極
めて重要である。なぜなら、各係数を独立に扱うことが
できるので、圧縮効率を損なうことがないからでる。Ｄ
ＣＴの別の重要な側面は、視覚的に重み付けられた量子
化値を使ってＤＣＴ係数を量子化できる点である。人間
の視覚系の応答は空間周波数に強く依存しているので、
画像を、各々が特定の空間周波数を有する１組の波形に
分解することにより、目で見える画像構造と認識できな
い画像構造とを分離することが可能になる。したがっ
て、ＤＣＴを使うと、この分解にとって良好な近似を実
現することができる。この結果、視聴者が認識する画像
の忠実度に重大な影響を与えることなく、データを切り
捨てるすなわち省略することが可能になる。

【０００５】ＪＰＥＧ標準によると、元の白黒画像は、
まず、目に見えるエイリアシング（曲線や斜線に生じる
ギザギザ）が生じないと思われる程度に高い任意の解像
度で、８×８の格子中の６４画素から成るブロック群に
分解する。（カラー画像は、まず各色素を８×８画素の
ブロックに別々に分解することにより、圧縮する）。こ
の量子化した画像データに極めて迅速にＤＣＴを施し
て、６４個のＤＣＴ係数を得ることのできる手法とハー
ドウェアは、公知である。これらのＤＣＴ係数の多く
は、零またはほぼ零である。零のＤＣＴ係数は、画像に
全く影響しない。ほぼ零のＤＣＴ係数は、比較的目に感
じない空間周波数に対応させる場合、無視すなわち省略
することができる。人間の目は極めて高い空間周波数と
極めて低い空間周波数に対して感度が低いから、ＪＰＥ
Ｇ標準の一部として、水平方向と垂直方向の空間周波数
の累積値にほぼ対応するいわゆるジグザグ・パターンで
ＤＣＴ係数を提供すると、重要度の低い空間周波数に対
応するＤＣＴ係数をＤＣＴ係数のデータ・ストリームの
最後にグループ化するようになる。これにより、多くの
場合、これら重要度の低い空間周波数に対応するＤＣＴ
係数を１つのグループとして効率的に圧縮することがで
きる。

【０００６】上述した離散コサイン変換（ＤＣＴ) と符
号化は実務で扱う大部分の画像に対して意味のあるデー
タ圧縮を実現しているけれども、実際のデータ削減量は
保証されておらず、圧縮の程度は最適化されていない。
これは、特に各ＤＣＴ係数の表現の精度が等しい場合に
は、同数のビットを伝送する必要があるからである（た
だし、ＪＰＥＧ標準は、１つのテーブルで符号化されて
いる複数の範囲によってＤＣＴ値を量子化するのを許し
ている）。すなわち、ＤＣＴ符号化によって得られる圧
縮利得は、主に、ＤＣＴ係数の零値とほぼ零値を処理す
ることにより効率が増大することに由来する。ただし、
精度を落とす量子化によっても圧縮を達成することがで
きる。以上の点から、ＪＰＥＧ標準は、エントロピー符
号化と呼ばれている第２段階の圧縮と符号化を規定して
いる。

【０００７】一般に、エントロピー符号化の概念は、な
じみのある熱力学の分野におけるエントロピーの概念に
類似している。熱力学では、エントロピーとは、物理系
における「無秩序」の程度を数量化したものである。情
報理論の分野では、エントロピーとは、任意の大きさの
１団のデータから成る環境における任意の所定の情報量
子（例えば記号）の内容の予測可能性の尺度のことであ
る。この場合、エントロピーは、任意の所定の情報量子
（例えば記号）の意味とは無関係である。この概念によ
って、所定のアルファベット記号に対して行ないうる圧
縮の程度の達成可能な下限を決めることができる。より
基礎的には、この概念によって、「予測可能の程度が比
較的高いデータ（あるいは記号）は、予測可能の程度が
低いデータ（あるいは記号）よりも情報量が少ない」と
いう前提と、「予測可能の程度が比較的低いデータ（あ
るいは記号）は、予測可能の程度が高いデータ（あるい
は記号）よりも情報量が多い」という換位命題とに基づ
いた圧縮手法が得られる（換位命題とは、ある命題の主
部と述部の中の語を入れ替えた命題のことである）。し
たがって、説明のために適切な符号を１つ仮定すると、
予測可能の程度が高い（すなわちデータ本体における出
現頻度が高いが、情報量は少ない）記号（あるいは値）
にはより少ないビット数を割り当てる一方、予測可能の
程度が比較的低い記号（あるいは値）にはより長い符号
（すなわちより多いビット数）を割り当てることによ
り、最適化された効率的な圧縮を行なうことができる。

【０００８】実際問題として、ハフマン符号化と算術符
号化は、エントロピー符号化に適している。そして、Ｊ
ＰＥＧ標準は、両者に適合している。ＪＰＥＧ標準にお
ける対象の操作に関する相違点の１つは、両符号化手法
にとって符号に対応する値のテーブルが必要であるにも
かかわらず、デフォルトのテーブルが算術符号化には用
意されているが、ハフマン符号化には用意されていな
い、という点である。しかし、特定のハフマン・テーブ
ルの中には、最大の符号化効率と再構成時における最大
の画像忠実度とが得られるようにＪＰＥＧ標準の下で自
由に指定できるものがある。けれども、それらは、特製
のハフマン・テーブルを計算・作成する計算上のオーバ
ーヘッドを避けようとして画像忠実度が過度に劣化しな
い限り、デフォルトのテーブルであるかのように見境な
く使われる場合が多い。

【０００９】ここで、次の点を認識する必要がある。す
なわち、符号化テーブルあるいは条件付けテーブルが画
像に合理的に良好に適している場合、特にハフマン符号
化を使うエントロピー符号化がデータ圧縮を保証する程
度は極めて大きい。けれども、符号化それ自体は、統計
に基づいていると共に多数の画像値あるいは画像値を表
わす多数の値に関する一団の統計情報を必要とするの
で、極めて多くの計算を必要とする、という点である。
逆に、テーブルを作成する元になった画像において出現
するのが比較的稀（まれ）である多くの値を符号化する
ことを符号化中の画像が必要としている場合（たとえこ
のような環境が出現するのが稀であっても）、当該符号
化中の画像を表していない確率を搭載したテーブルを使
うと、圧縮ではなく展開が行なわれる可能性がある。

【００１０】使用した圧縮の程度に対して、たとえ最適
圧縮および／または最適忠実度が達成されなくとも、あ
る種のハフマン・テーブルが事実上標準的に使用される
ようになったのは、この理由による。逆に、ハフマン符
号化の圧縮効率は、通常、顕著に向上しうる。そして、
問題の画像に対応する特製のハフマン・テーブルによっ
て、所定ビット数のデータに対して画像忠実度を最適に
維持しうる。しかし、これは、符号化するのに多大な計
算負荷を負担しないかぎり達成できない。

【００１１】符号化した各値にハフマン符号割り当てる
手法の階層的性質と、最も出現頻度が高く最も予測可能
性の高い値（たとえそこに含まれている情報が理想的に
は余り意味がないとしても）を表わすのに少なくとも１
ビットを使う必要があるという事実とに起因して、符号
化すべき特定の値すべての発生頻度が５０％に上昇する
と、ハフマン符号化らしく別の非効率が発生する。例え
ば、ある単一の値の発生頻度が７５％に上昇すると、ハ
フマン符号化の効率は８６％に低下する。実際問題とし
て、大多数のＤＣＴ係数は零である（あるいは零に量子
化されている）。したがって、ＤＣＴ係数あるいはＤＣ
Ｔ係数の差分をハフマン符号化する際に、多大な非効率
がしばしば発生する。ＡＣ係数の場合、ＪＰＥＧ委員会
は、零値の係数群を１つにまとめて個々の零値の係数を
符号化しないことにより、この問題を解決した。したが
って、ハフマン記号が５０％以上発生する可能性は、著
しく低い。

【００１２】圧縮効率は、各値（あるいは記号）の終点
を検出するのに余分の処理が必要な可変長符号によって
主として決まる。したがって、ハフマン復号化も、多大
な計算負荷を必要とする。さらに、このハフマン復号化
処理は、エントロピー符号化した画像データと一緒に伝
送する必要があると共に画像ごとに変化しうる符号化テ
ーブルを使って行なう。テーブル中のデータにアクセス
する複雑さは、ハフマン符号が可変長であるという事実
によって累増する。ハフマン符号化では、特定の記号
（あるいは値）に含まれている単一のデータあるいはあ
る量のデータの予測可能性に従って異なった数のビット
を割り当てる。したがって、ハフマン符号は可変長であ
る。応答速度を速めるために、復号化時に使用可能なハ
フマン・テーブルから参照用テーブルを計算してそれを
格納しておくのが実務になっいる。したがって、１つの
符号語当り少なくとも２バイトのテーブル・データにア
クセスする必要のあの場合が多い。

【００１３】さらに、ハフマン符号長として１６ビット
が許されているから、従来の復号化方法では、記号値ご
とに２¹⁶個のエントリと符号長ごとに２¹⁶個のエントリ
を備えたハフマン・テーブルにアクセスすることにな
る。これらのエントリは、ハフマン・テーブルを指定す
るあるいは変更するごとに計算する必要がある。復号化
のためには、最大４つのＤＣテーブルおよび４つのＡＣ
テーブルと交互に配置した最低限４要素の画像とが必要
になる可能性がある。小さなオンチップのキャッシュ
（あるいはＲＡＭ）を備えたハードウェアの場合、この
ようなテーブルを使うと、キャッシュ・ミスあるいはＲ
ＡＭアクセスごとに余分の処理サイクルを必要とするの
で、性能が劣化することになる。

【００１４】

【発明が解決しようとする課題】本発明の目的は、少な
い処理資源とハードウェアを使い極めて短時間で達成で
きるハフマン符号化と復号化の方法を提供することであ
る。

【００１５】本発明の別の目的は、パックした中間デー
タ形式を使って増強したハフマン符号化と復号化の方法
を提供することである。

【００１６】

【課題を解決するための手段】本発明に係るハフマン符
号化法は、次のように構成する。記号をハフマン符号化
するハフマン符号化法であって、１つのテーブルにおけ
る所定長の符号の最初の出現に対するシード値を定義す
るステップと、１つの符号語の長さを格納するステップ
と、前記数および前記符号語のビット数が所定ビット数
以下の場合、前記長さおよび前記符号語を第１の形式で
格納するステップと、前記数および前記画像データが前
記所定ビット数を超えるビット数から成る場合、前記シ
ード値への索引、オフセット、および前記符号語を第２
の形式で格納するステップとを備える。

【００１７】本発明に係るハフマン復号化法は、次のよ
うに構成する。圧縮データをハフマン復号化するハフマ
ン復号化法であって、有効なハフマン符号の長さを判断
する複数の試験基準の各々を使ってデータ・ストリーム
のビットを試験するステップと、前記長さに対応する複
数のオフセットのうちの１つと前記有効なハフマン符号
とを組み合わせて、索引を生成するステップと、前記索
引を使って、ハフマン・テーブル中の記号値にアクセス
するステップとを備える。

【００１８】

【発明の実施の形態】次に、図面を参照して本発明の一
実施形態を説明する。図１は、ペネベーカーらの上掲書
の３９３頁に記載されているＪＰＥＧ標準に従う、ハフ
マン・テーブル仕様の構文を示す図である。図１に示す
構文は、マーカー・セグメントと呼ばれており、以下で
ハフマン・エントロピー符号化または復号化を実行する
のに使用する少なくとも１つのハフマン符号化テーブル
を定義するのに使う。新たなパラメータすなわちテーブ
ル値を変更すべきときはいつでも、これと同じ構文を使
う。マーカー・セグメントは、常に、累積バイト数を含
んでいる（これは、セグメントの終わりに所定の論理値
のビットを付加することにより行なう場合がある）。そ
して、符号のフレーム開始（start of frame: ＳＯＦ）
ブロックと走査開始（start of scan:ＳＯＳ）ブロック
に適用されたマーカー・セグメントは、ヘッダと呼ばれ
ている。

【００１９】ＪＰＥＧ標準に従うマーカー・セグメント
は、図１に示すように常に、２バイト符号で始まる。こ
の２バイト符号は、１６進数の「ＦＦ」バイトで始ま
り、当該マーカー・セグメントの機能を指定する非零の
１バイトが続く。例えば、「ＦＦＤＢ」は「量子化テー
ブルを定義する（define quantization table:ＤＱ
Ｔ）」を表し、「ＦＦＣ４」は「ハフマン・テーブルを
定義する（define Huffman table: ＤＨＴ）」を表わ
す。特に、「ハフマン・テーブルを定義する（ＤＨ
Ｔ）」機能に適用する場合、続く２バイトは、マーカー
・セグメントに設けられたパラメータ・フィールドの長
さＬ_h を指定している。続く１バイトのうちの第１のニ
ブル中の１ビットＴｃは、ＤＣまたはＡＣ（「０」また
は「１」）として直ぐに続くテーブルを指定している。
（１ニブル＝１バイトの半分＝４ビット）。次に続くニ
ブル中のビット群Ｔｈは、当該テーブルの名前を指定し
ている。ＤＣテーブルとＡＣテーブルの各々に対して最
大４つのテーブルが許される。そして、これらのテーブ
ルのうちの任意のものあるいは全部を定義または再定義
するのに、マーカー・セグメントを使うことができる。

【００２０】次の１６バイトは、各ビット長がＬｉの符
号の個数を指定している。これらの符号は、ＪＰＥＧ標
準下で許される最大ビット長（あるいは任意のビット
長）に対応する引き続くテーブル中に含まれることにな
る。表記規則によると、１ビット符号の個数はＬ１であ
り、１６ビット符号の個数はＬ１６である。画像の精度
が８ビットであると、量子化後に得られる係数は高々１
１ビットである。したがって、特に画像の精度が８ビッ
トである場合には、すべてのビット長が表現されるわけ
ではない。画像データ中で表現されない符号長は、すべ
て、１６進数の「００」として符号化することになる。
続くバイト群Ｖ_1,1 〜Ｖ_1,L16 は、出現頻度（例えば所
定の長さの符号が提示される回数など）の順に並べた各
ハフマン符号に対応する実際の値である。

【００２１】ここで、次の点を思い出す必要がある。す
なわち、ハフマン符号化などのエントロピー符号化で
は、出現頻度すなわち出現可能性の高い値にはより少な
いビットを割り当てる。そして、ＤＣＴ係数の多くは、
零である可能性がある、という点である。したがって、
ＪＰＥＧ標準は、各々が２５６ものエントリを有する８
つものハフマン・テーブルを用意している（そして、特
定のハフマン符号の特定のＤＣＴ係数へのマッピングは
常に定義されている、ということを保証している）。こ
のプロセスを速めるために、参照テーブルを用意して、
ハフマン・テーブルのＶ_i,j フィールドを検索すること
もできる。これにより、特定のＶ_i,j 値を捜し出す操作
の回数を減らすことができる。しかし、余分のメモリ資
源を必要とする。そして、上述したように、より多数の
テーブル・エントリを展開するのに余分の計算負荷をも
たらす。

【００２２】次に、図３の典型的なハフマン・テーブル
を用いて、マーカー・セグメントの応用を説明する。導
入として、次の点を理解する必要がある。すなわち、圧
縮プロセスにおける量子化と離散コサイン変換（ＤＣ
Ｔ）の結果は、ラスター走査順に並べた一連のＤＣＴ係
数になっている（ラスター走査とは、ＣＲＴディスプレ
イの水平方向に左から右に走査しながら順次下方へ移動
する走査方式のことである）。零値の係数は、それらに
ジクザク順にアクセスすることにより大雑把にグループ
化されている。そして、さらなる圧縮（およびエントロ
ピー符号化など他の変換プロセスから成る強化）は、本
願の関連出願に開示されているラン・アンド・サイズ
（Ｒ／Ｓ）データに従ってデータをパックすることによ
り得られる。ランとは、零値のＡＣ ＤＣＴ係数から成
る連続列の長さのことである。サイズとは、非零のＤＣ
Ｔ係数を指定するのに必要なビット数のことである。ラ
ンすなわちＲ値は、Ｒ／Ｓバイトの上位ニブル（＝４ビ
ット）として符号化される。サイズすなわちＳ値は、Ｒ
／Ｓバイトの下位ニブルとして符号化される。

【００２３】ここで、ＤＣ ＤＣＴ係数差分とＡＣ Ｄ
ＣＴ係数値は、Ｒ／Ｓ値によって完全には指定できな
い、という点を認識すべきである。しかし、ＪＰＥＧ標
準に従ってＲ／Ｓ値だけを符号化し、かつ、図２に示す
ように、各符号に、正のＡＣＤＣＴ係数またはＤＣ Ｄ
ＣＴ係数差分値から成る実際のビット、および負のＡＣ
ＤＣＴ係数またはＤＣ ＤＣＴ係数差分値から成る実
際のビットを付加すれば、後述するように極めて膨大な
データ圧縮をしながら、かつ、すべての細部にわたって
ＪＰＥＧ標準に準拠しながら、元のＤＣＴ係数の情報を
すべて含めるのに十分である。

【００２４】説明を明瞭にするために、図３は、２バイ
トのマーカーが左方に伸びるように、ちょうど１６列に
示してある。各バイトは、当該各バイトの２ニブルを表
わす２つの１６進数化ディジットによって表されてい
る。

【００２５】図３の第１のマーカーは、画像の開始（st
art of image: ＳＯＩ）を表わす「ＦＦＤ８」である。
第２のマーカーは、量子化テーブルの仕様を表わす「Ｆ
ＦＤＢ」である。ここで、次の点を理解すべきである。
すなわち、量子化したＤＣＴ係数の値は、大きさが固定
された範囲の値を表わす必要はない。正確には、量子化
したＤＣＴ係数の値は、各々、大きさが他のもの異なる
範囲の値を表わすことができる、という点である。この
テーブルは、元の画像に対応するＤＣＴ係数を、本発明
を理解するのに重要でない方法で分析することにより得
られる。そして、このテーブルは、後で画像を再構成す
る間にＤＣＴ係数を「逆量子化（dequantize）」するの
に使う。

【００２６】第３のマーカーは、少なくとも１つのハフ
マン・テーブルを指定しているマーカー・セグメントの
開始を表わす「ＦＦＣ４」である。次の２バイト「０１
Ａ２」は１０進数「４１８」の１６進符号である。１０
進数「４１８」は、走査開始（ＳＯＳ）を表わす次のマ
ーカー「ＦＦＤＡ」までのバイト数である。「ＦＦＤ
Ａ」では、構成要素（例えばＲ、Ｇ、Ｂ、グレースケー
ル〔白黒の階調〕、輝度／クロミナンス〔参照色との色
質の違い〕など）の個数で始まるパラメータ・リストの
長さが指定されている。そして、模式的に「・・・」で
表してある圧縮データが続く。

【００２７】上記「ＦＦＣ４」の次のバイトは、Ｔｃと
Ｔｈを表わす２ニブルから成る。両ニブルとも零である
から、このテーブルをＤＣテーブル０として定義してい
る。これらはＤＣテーブルであり、かつ、ブロック当り
１つのＤＣ ＤＣＴ係数しか用意されていないから、ラ
ン長は存在しない。そして、各バイトの第１のニブルが
零である一方、第２のニブルは各サイズの余分のビット
数（圧縮データ・ストリーム中で次に続く余分のビット
数）を指定している。符号中の特定の数は、図４に示す
ハフマン符号に対応している。これらのものは、３ビッ
ト長の符号５個を含めて１２個しかない。これら１２個
の値は、次の１２バイトで指定されている。これで、Ｄ
Ｃテーブル０は完了する。

【００２８】この時点で、２９バイトしか使っていな
い。すなわち、Ｔｃ、Ｔｈに１バイト、Ｌｉに１６バイ
ト、Ｖ_i,j に１２バイトである。この２９バイトという
値は、マーカーの直後に指定されているパラメータ長の
４１８バイトよりもはるかに小さい。したがって、次の
１バイトの２ニブルは、このマーカー・セグメントで指
定される第２のハフマン・テーブルのクラスと名前を定
義している。この場合、Ｔｃ値とＴｈ値がそれぞれ
「１」と「０」であるから、第２のハフマン・テーブル
は、ＡＣテーブル０である。次の１６バイトは、各長さ
の符号数を示すＬ_i 値である。そして、次のバイト群
（その数はＬ_i 中で列挙されている符号の合計数〔最大
６４〕に等しい）は、出現頻度の降順のハフマン符号の
各々に対するＶ_{i, j} 記号値である。これで、ＡＣテーブ
ル０は完了する。

【００２９】「４１８」の残りは、上述したのと同じ形
式で記載すると共に符号化したさらに２つのテーブル、
ＤＣテーブル１とＡＣテーブル１から成る。ＤＣテーブ
ル１用のハフマン符号を、図５に表として示す。

【００３０】図４と図５とを比較すると、ハフマン符号
の特徴がいくつか分かる。第１に、上述したように、ハ
フマン符号は可変長である。そして、その「カテゴリ」
は、ビット数すなわちサイズすなわちＳ値である。この
Ｓ値は、上述したＲ／Ｓバイトに含まれていると共に、
図３などのハフマン・テーブルにＶ_i,j として記録され
ている。第２に、すべて「１」値のビットから成る符号
は、許されない。第３に、所定長の複数の符号は、許さ
れる。上記「複数」は、当該所定長の符号によって表し
うる値の個数よりも小さい。第４に、そして本発明を理
解するのに最も重要なものとして、ＪＰＥＧハフマン符
号を構築して、階層的に区別した値を表わしている。こ
の制約すなわち特質は、より長い他の符号と接頭辞が同
じになる符号は許されない、という特徴に現れている。

【００３１】ここで、上述した事項から、ハフマン・テ
ーブルの構造を使うことにより、特定のハフマン符号群
と、それらにそれぞれ割り当てたＲ／Ｓ値との間の対応
関係を再構築することができる、ということが想起され
る。しかし、上述したように、このような再構築は、複
雑であると共に時間をくう。したがって、参照テーブル
を使ってハフマン・テーブルの検索する方がずっと普通
である。このプロセスは、ハフマン符号は可変長である
ので、有効なハフマン符号に対応する連続ビット数（１
６以下）をも認識している必要がある、という事実によ
って複雑になっている。

【００３２】有効なハフマン符号を認識してハフマン・
テーブルを検索する公知の方法は、圧縮データ中で（次
に）続く１６ビットを取り上げ、（２¹⁶個のエントリを
有するテーブルで）検索対象符号のビット数を見つけ、
（同様のサイズの）別のテーブルで検索対象符号に対応
するＲ／Ｓバイトを捜し出すものであろう。しかし、こ
の方法は、記憶空間の観点から無駄が多いと共に、メモ
リに多大な負荷をかける。例えば、検索対象符号が調べ
るべき１６ビットのうちの始めの１ビット符号であると
すると、各テーブルの半分は、同数ビット（１６ビッ
ト）が「１」であり、検索対象記号に対するＲ／Ｓ値バ
イトが同一になるであろう。公知の別の方法では、複数
のテーブルを使うが、それに対応して多数の検索操作を
必要とする。

【００３３】本発明では、各符号は任意の所定数の２進
ビットに対応する数値を有するものと考えることができ
ると共に、所定数の２進ビットに対応する数値が大きす
ぎてもそれを算出できる、というハフマン符号の特徴を
利用している。圧縮データのうちのｎビットが論理的に
この最大値（以下、ｍａｘ（ｎ）、ただしｎ＝ビット
数）以上である場合、追加のビットを調べ、ｍａｘ（ｎ
＋１）と比較する必要がある。また、本発明は、ハード
ウェア・アーキテクチャの観点から、正しいビット数を
考察し、それより多いビット数に対する残りの試験が失
敗するまで、すべての試験が合格するから（例えば論理
値が有効なハフマン符号に対して大きすぎる）、これら
の試験は並行して実行できる、という事実も利用してい
る。

【００３４】例えば、図６に示すように、この試験は、
１６個の比較器を使って並行に実行することができる。
図６では、１６個の比較器は、Ｃ［０・・・ｎ］≧ｍａ
ｘ（ｎ）なる数式で表されている。各比較器は、バレル
・シフタなどのＣレジスタの連続するステージに接続さ
れた１個から１６個の入力端子を備えている。これらの
比較器は、ディジタルであり、論理ゲートアレイとして
構成することができる。

【００３５】すなわち、第１の試験では、Ｃレジスタの
現在の最上位ビットＭＳＢ（Ｃ［０］）と１ビット値で
あるｍａｘ（１）とを比較する。１ビット符号がない場
合、ｍａｘ（１）＝０である。１ビット符号がある場
合、ｍａｘ（１）＝１である。（すべて「１」から成る
符号は不許可であるから、１ビット符号がある場合、そ
の１ビット符号は「０」である）。ｍａｘ（ｎ）の値
は、ｍａｘ（ｎ）がｎビットのうちの第１の符号であ
り、より長い符号語の接頭辞であるように構築されてい
るから、いくつかの符号を有する第１のＬ_n に対する非
零のｍａｘ（ｎ）が存在することになる。（例えば、ｍ
ａｘ（２）＝“１０”であり、これは、図４のカテゴリ
５の接頭辞である）。

【００３６】図７は、別の実施形態を示す図である。図
７では、圧縮データのだんだん多くなるビットとｍａｘ
（ｎ）の値とを比較している。ｎの値は、比較が失敗す
る（すなわち「０」を生成する）最初の値に成るように
決めてある。

【００３７】図８は、ＡＬＵ（arithmetic logic unit:
算術演算装置）への入力の１つとしてＣレジスタのｎ個
のＭＳＢに付加した先行する「０」を示す図である。残
りの入力は、事前算出したｏｆｆｓｅｔ（ｎ）である。
加算後に得られる低位の結果は、参照テーブル（ＬＵ
Ｔ）／ハフマン・テーブルへの索引である（この索引
は、ＡＣ符号化用の８ビットのうちのＤＣ差分用の４ビ
ットから成っている）。参照テーブル（ＬＵＴ）／ハフ
マン・テーブルは、「ハフマン・テーブルを定義（Defi
ne Huffman Table: ＤＨＴ）」マーカー・セグメントで
渡されたＶ_i,j 記号値を含んでいる。このテーブルの出
力は、Ｒ／Ｓバイトである。

【００３８】図９は、ｍａｘ（ｎ）値を構築するための
フローチャートを示す図である。この方法論は、図３の
ＤＨＴマーカー・セグメントで指定されているＲ／Ｓバ
イトへのオフセット（ｏｆｆｓｅｔ）も構築する。ただ
し、ｏｆｆｓｅｔ（０）は、Ｒ／ＳリストまたはＲ／Ｓ
リストへのポインタの第１バイトから成る索引（例えば
「０」）である。ステップ７１におけるｍａｘ（ｎ）と
ｏｆｆｓｅｔ（ｎ）の初期化は、ｉ、ｍａｘ（０）、ｏ
ｆｆｓｅｔ（０）を「０」に設定することにより開始す
る（ステップ７２）。次いで、ステップ７３で、ｉをイ
ンクリメントし、ｏｆｆｓｅｔをｍａｘ（ｉ−１）未満
の最後のｏｆｆｓｅｔに設定する。ｍａｘ（ｉ）の値
は、Ｌ_i ＋ｍａｘ（ｉ−１）として計算する。したがっ
て、Ｌ_i が非零になるまで、ｏｆｆｓｅｔ（ｎ）とｍａ
ｘ（ｎ）は「０」のままである。それゆえ、図６または
図７の最初の比較Ｃ［０・・・ｎ］は、常に合格する。
なぜなら、（当該長さの少なくとも１つの符号が存在す
ることを示す）非零のＬ_i が出現するまで、第１ビット
の論理値／数値は、常に「０」以上であるからである。
ステップ７３に示すように、非零（すなわち「１」）の
Ｌ_i が出現した場合、それを「０」に付加すると、ｍａ
ｘ（ｉ）は、より大きな符号の接頭辞をなす第１の符号
に設定されることになる。このプロセスをｉ＜１６の間
繰り返して、すべてのＬ_n に対するすべてのｍａｘ
（ｎ）を生成する。したがって、例えば、５個の３ビッ
ト符号（例えば０、１、２、３、４）が存在する場合、
ｍａｘ（３）は５に設定される。この値５（２進数で
「１０１」）は、より長い符号の一部である。ただし、
これ以上符号が存在しなければ、この特定の符号は必ず
しも使用されない。それゆえ、ｍａｘ（ｉ）は、大きす
ぎるｉビットの第１の符号（すなわちｉビットの最大符
号よりも１つの値だけ大きい符号）を指し示している。
Ｌ（ｉ＋１）がヌルでない（例えば１ビットだけ大きい
符号が存在する）場合、当該符号の値は、ｍａｘ（ｉ）
の２倍である。（ｉ＋１）符号は、２＊ｍａｘ（ｉ）で
始まり、順番に番号付けされる。そして、ｍａｘ（ｉ＋
１）は、この順番のの後の次の数（すなわち２＊ｍａｘ
（ｉ）＋Ｌ（ｉ＋１））である。Ｌ（ｉ＋１）＝０の場
合、ｍａｘ（ｉ＋１）は２＊ｍａｘ（ｉ）に等しい。そ
して、次の非零のＬ_i が出現する前に、このような２倍
項がいくつか存在しうる。

【００３９】より一般に、ｍａｘ（ｉ）とｏｆｆｓｅｔ
（ｉ）は、次に示すように、Ｌ_i の項で計算する。 （ｉ＝０ （ｍａｘ（０）＝０ （ｏｆｆｓｅｔ（０）＝０ （ｉ＝１ （ｍａｘ（１）＝Ｌ₁ ＋２＊０ （ｏｆｆｓｅｔ（１）＝０−０＝０ （ｉ＝２ （ｍａｘ（２）＝Ｌ₂ ＋２＊Ｌ₁ （ｏｆｆｓｅｔ（２）＝０−Ｌ₁ ・ ・ ・

【００４０】ｏｆｆｓｅｔ（ｉ）は、検索対象符号に対
応する復号化した値がＲ／Ｓ値のリスト中のどこに位置
しているかを判断するのに使う。すなわち、ｏｆｆｓｅ
ｔ（ｉ）にハフマン符号のｉビットを付加して得られる
値は、対応するＲ／Ｓバイトが存在する、ハフマン・テ
ーブル中のアドレスになる。これにより、本発明の文脈
において極めて重要な利点がいくつか得られる。特に、
各々が２¹⁶個のエントリを有する複数の参照テーブルか
ら成る関数群は、１６個のエントリに限られているｍａ
ｘ（ｎ）値とｏｆｆｓｅｔ（ｎ）から成るテーブル群で
置き換えることができる。このテーブルは、極めて迅速
に計算して効率的に格納することができる。このテーブ
ルは特異であると共に小さいから、その中のデータを極
めて迅速に取り出して、ＪＰＥＧ標準構文によるデータ
・ストリーム中にハフマン符号と共に含まれているＤＣ
Ｔ係数データとＤＣＴ係数差分データを評価するのに使
うＲ／Ｓデータを取得するための、ハフマン・テーブル
への直接索引を作成することができる（これは、他の処
理手法と一緒に利用できると共に、他の型のデータに対
しても利用できる）。

【００４１】まとめとして、圧縮データの復号化を図１
０を用いて説明し、その好適で完全な機能を図１１〜図
１３と共に後述する。プロセスがステップ８１で開始す
ると、復号化するＡＣ係数の個数ｋを零に初期化した
後、ループに入って非零のＡＣ係数を各々順番に処理す
る。上述すると共にステップ８３に示すように、圧縮デ
ータの１６ビットの列を（例えば図６または図７の）Ｃ
レジスタにロードし、並列比較または逐次比較によっ
て、有効なハフマン符号のビット数ｎを判断する。いっ
たんｎが判明すると、ステップ８４に示すように、対応
するｏｆｆｓｅｔ（ｎ）も判明し、ハフマン・テーブル
・アドレスへのポインタＣ［０・・・ｎ−１］＋ｏｆｆ
ｓｅｔ（ｎ）を計算した後（例えば図８）、Ｒ／Ｓ値を
４ビット右にシフトすることにより、ハフマン・テーブ
ルのＲ／ＳバイトからＳ値を抽出する。次いで、ステッ
プ８５に示すように、圧縮データを（ハフマン符号の長
さに対応する）ｎビットだけ（左に）シフトしてデータ
・ストリーム中にＡＣ係数値を供給する。

【００４２】次いで、ステップ８６に示すように、この
データを図１４の形式で供給するために、Ｒ／Ｓ値群の
ビット群と１６進の「０Ｆ」バイトとをＡＮＤしてＲ／
Ｓ値からＲを取り除き、２つの追加のバイトにＲ／Ｓバ
イトを格納すると共に余分なＳビット群を格納する。そ
して、圧縮データを（左に）Ｓビットだけシフトして、
Ｃレジスタの先頭に次のハフマン符号を供給する。次い
で、次の非零のＡＣ係数を復号化するために、ｋ値をＲ
＋１だけインクリメントする（ステップ８７）。パック
したデータ形式を完了させるために、ステップ８８でＲ
／Ｓ値を試験する。Ｒ／Ｓ値が０である場合、ステップ
９０に示すように、ブロックの終わり（end-of-block:
ＥＯＢ）を示した後、当該長さバイトを格納する。Ｒ／
Ｓ値が０でない場合、インクリメントしたｋ値を試験す
る（ステップ８９）。ｋ値が１つのブロック中のＡＣ係
数の最大数である６３である場合、０のＲ／Ｓ値を格納
してＥＯＢを示した後、当該長さバイトを格納する。ｋ
値が６３未満の場合、プロセスはステップ８３にループ
して、ＡＣ係数をさらに処理する。

【００４３】図１０のプロセスの完全な機能を図１１〜
図１３に示す。本発明のこの機能は、ｍａｘ（ｎ）値群
を５個のｘＣ＿ｍａｘ＜０・・・４＞なる３２ビット語
にパックするものである。これらは、レジスタに格納し
て操作することができる。これにより、例えば図６また
は図７のハードウェア構成に従う比較のために、頻繁に
メモリ・アクセスして値を取得する必要がなくなる。

【００４４】ｍａｘ（ｎ）値は、次に示すように、語中
に密にパックされている。 xC＿max<0>=max(1),max(2),max(3),max(4),max(5),max
(6),max(7),0000=32ビット; xC＿max<1>=max(8),max(9),max(10),00000=32 ビット; xC＿max<2>=max(11),max(12),000000000=32 ビット; xC＿max<3>=max(13),max(14),00000=32 ビット; xC＿max<4>=max(15),max(16),0=32 ビット. これらの値は、図１０のステップ８３を実行する際に、
図１１〜図１３に示すように操作する。特に、ハフマン
符号中のビット数ｎを判断するために、ｎの値を１に初
期化した後、圧縮データの次の３２ビットと共にレジス
タすなわち変数ｃｏｍｐをロードする。ｃｏｍｐは、xC
＿max<0>の最上位ビットと論理比較する。ｃｏｍｐが論
理的にxC＿max<0>の最上位ビット以上の場合、ハフマン
符号は１ビットではないので、ｎを２にインクリメント
する。次のｍａｘ（ｎ）値をレジスタの最上位ビットに
シフトした後、もう１ビットとｃｏｍｐ値とを比較する
手順を繰り返す。この際、アクセスするごとにｎをイン
クリメントする。ｃｏｍｐの比較が失敗したとき、求め
るビット数が見つかっているので、比較の手順を完了す
る。ＲＩＳＣアーキテクチャの中には、レジスタへの複
写、マスク、およびシフト命令を１サイクルで行なうも
のがある。この場合、ｎ値、ｃｏｍｐ値、ｘＣ＿ｍａｘ
値がレジスタ中に存在するものと仮定すると、ｎ値がも
っと大きい必要があるか否か、そして、記憶装置（メモ
リ）アクセスは必要ないか否かを判断するのに３サイク
ルしかかからない。したがって、特に、短いハフマン符
号は長いものよりも出現頻度が高いから、上記比較試験
は、極めて迅速に実行することができる。

【００４５】本発明による復号化器と復号化方法に関す
る以上の説明から、ＪＰＥＧ標準に従って圧縮した画像
データの再構成において、速度と応答性が顕著に向上し
ているのが分かる。その上、データ処理用のハードウェ
アおよび／またはソフトウェアに対する要件が顕著に低
減していることも分かる。また、上掲した本願の関連出
願に開示したパックしたデータの形式と組み合わせる
と、符号化プロセスにおいても顕著な利点が得られる。
ここに開示した中間データ形式を、図１４に示す。

【００４６】図１５は、パックしたＤＣＴブロックをエ
ントロピー符号化したデータに符号化するフローチャー
トを示す図である。まず、ステップ１００１でＤＣＴ係
数を符号化する。次いで、ループ１００２に入る。ルー
プ１００２では、次のように各々実行する。すなわち、
ステップ１００３でＲ／Ｓバイトの符号化を実行し、ス
テップ１００４でＳ値に従って余分のビットの符号化を
実行し、ステップ１００５で両者の格納を実行する。次
いで、ステップ１００６でＥＯＢ符号があるか否かを判
断する。ＮＯならば、ステップ１００３に戻ってループ
１００２を繰り返す。ＹＥＳならば、ステップ１００７
に進む。ステップ１００７でｋ＝６３であるか否かを試
験する。ＹＥＳならば、プロセスは完了する。なぜな
ら、ｋ＝６３は供給されうる値の最大数を表わしている
と共に、ＥＯＢ記号は、これだけを取り出して符号化す
る必要がないからである。ＮＯすなわちｋ＜６３なら
ば、ステップ１００８でＥＯＢを符号化し、ステップ１
００９で格納した後、プロセスを完了する。ここで、次
の点に留意する必要がある。すなわち、各エントリはハ
フマン符号化したデータに必要な粗い形で既に存在して
いるので、プロセスは、ＥＯＢマーカーが出現するま
で、最高速で各Ｒ／Ｓビットと余分のビットとの対を順
番に符号化することができる。

【００４７】符号化の間に、Ｒ／Ｓバイトをハフマン符
号に変換する必要がある。Ｒ／Ｓ値にハフマン符号を割
り当てる際に依拠する統計データを集めるのに、図１４
のパックしたデータ形式は特に都合がよい。すなわち、
データ・ブロックを走査する１回のパスで、各Ｒ／Ｓ値
とハフマン符号の割り当てと伝送すべきＬ_i 値とが出現
する回数を計数することができる。データ・ブロックを
走査する２回目のパスの前に、伝送に使用する実際のＲ
／Ｓ値は、図１の形式の一部としての伝送用のＶ_i,j 記
号値として組み立てる。各ハフマン符号長ｎ内のカテゴ
リは任意に割り当てることができるから、ｍａｘ（ｎ）
を格納する代わりに、長さｎの第１のハフマン符号用に
ｓｅｅｄ（ｎ）なる値を定義する。ｓｅｅｄ（ｎ）は、
数値的に２＊ｍａｘ（ｎ−１）に等しい。

【００４８】図１６は、Ｈ＿ｃｏｄｅテーブル、Ｈ＿ｏ
ｆｆｓｅｔテーブル、Ｈ＿ｓｅｅｄテーブルを初期化す
るフローチャートを示す図である。まず、開始シード
（ｓｅｅｄ）（すなわち所定のビット数に対応する数値
が最小である最初の符号語）を零（０）に初期化する。
当該符号語のビット数（すなわち符号語長）を零に初期
化する。

【００４９】次いで、ｉが１６未満である限り、ｉを１
だけインクリメントした後、ｓｅｅｄを２倍にしてＨ＿
ｓｅｅｄ（ｉ）に格納する。次いで、ｃｏｄｅをｓｅｅ
ｄに設定した後、ｓｅｅｄをｉビット符号の数だけイン
クリメントする。次いで、ｊを零に初期化する。

【００５０】ｊが符号Ｌ_i の個数未満である限り、「ハ
フマン・テーブルを定義（ＤＨＴ）」マーカー・セグメ
ントにおいて、Ｒ／Ｓを次のＶ_i,j 記号値に設定する。
当該符号のビット数（ｉ）が６未満の場合、当該ビット
数と当該符号をＨ＿ｃｏｄｅ（ＲＳ）にパックする。こ
のとき、当該バイトの上位３ビットを当該符号の当該ビ
ット数を設定し、下位５ビットに当該符号を設定する。
ｉが５よりも大きい場合、Ｈ＿ｃｏｄｅ（ＲＳ）を当該
ビット数に設定する。次いで、Ｈ＿ｏｆｆｓｅｔ（Ｒ
Ｓ）をｊに設定する。なぜなら、これはｉビット符号の
うちのｊ＋１番目の符号だからである。次いで、両経路
について、ｊとｃｏｄｅの双方をインクリメントする。

【００５１】ソフトウェアで実現する場合、最長のｓｅ
ｅｄが１６ビットだから、Ｈ＿ｓｅｅｄテーブルは、お
そらく少なくとも１６ビットの整数として実現される。
ハードウェアの場合、ｎ番目のエントリがｎビットの符
号用のｓｅｅｄだから、ｎ番目のエントリしかｎビット
である必要がない。説明を簡明にするために、図１６で
は、Ｈ＿ｓｅｅｄテーブルを１７エントリ（０〜１６）
用に初期化している。図１７に示すフローチャートで
は、６番目から１６番目のエントリしか使うことができ
ない。ここでも、ハードウェアによる実施形態では、こ
れを利用してロード可能なレジスタの数を減らしてい
る。

【００５２】ＤＣハフマン・テーブルとＡＣハフマン・
テーブルは、各々、Ｈ＿ｓｅｅｄテーブル、Ｈ＿ｃｏｄ
ｅテーブル、およびＨ＿ｏｆｆｓｅｔテーブルを１組必
要とする。幸い、最低限の実現方法の場合、Ｒ＝０であ
り、Ｓの最大値が１１だから、ＤＣ Ｈ＿ｃｏｄｅテー
ブルとＤＣ Ｈ＿ｏｆｆｓｅｔテーブルは、１２エント
リしか必要としない。一般的な実現方法の場合、Ｓの最
大値が１６であるから、これらのテーブル用に最大１７
エントリ作成する。

【００５３】説明を簡明にすると、大部分のＲ／Ｓバイ
トを使うことができるから、Ｈ＿ｃｏｄｅテーブルとＨ
＿ｏｆｆｓｅｔテーブルは、各々、おそらく２５６エン
トリ備えることになる。これらのテーブルのエントリ
は、高々１バイトである。したがって、１６ビット符号
語のビット数を表わすのに当該符号語のエントリに加え
余分のビットを必要とする代わりに、より長い符号語用
に小さなＨ＿ｓｅｅｄテーブルを使う。それゆえ、当該
サイズの最後の符号語を算出するのに、余分バイトは１
バイトしか必要としない。短い符号（すなわち５ビット
未満）は、すべて、Ｈ＿ｃｏｄｅバイトに含める。出現
頻度の高い記号ほど符号が短いから、記憶装置に対する
１バイト分のアクセスで、最も普通に符号化した記号に
必要なものをすべて取得することができる。

【００５４】図１７は、図１５のＲ／Ｓバイトの符号化
を実行するステップ１００３をより詳細に示す図であ
る。まず、一時変数または一時レジスタｔｅｍをＨ＿ｃ
ｏｄｅ（ＲＳ）の内容に設定する。ｎの値を当該バイト
の上位３ビットに設定する。ｎが零の場合、ｎをｔｅｍ
に設定する。そして、Ｈ＿ｓｅｅｄ（ｎ）にＨ＿ｏｆｆ
ｓｅｔ（ＲＳ）を加算して当該符号を生成する。ｎが零
でない場合、ｃｏｄｅをｔｅｍの下位５ビットに設定す
る。次いで、圧縮データを左にｎビットシフトさせた
後、その下位ｎビットに当該符号を入れる。ｃｏｍｐ
は、連続バレル・シフタのように取り扱う。そして、３
２ビット語を出力するプロセスは、当業者にとって周知
である。

【００５５】従来技術では、最大２５６個のＲ／Ｓ記号
用に、ｎと最大１６ビットのビット・パターンを格納し
ている。しかし、本発明によると、ｎと当該符号語は、
合計８ビット以下の中に両者を格納できるときには、１
バイトの中に格納する。これにより、ハフマン・テーブ
ルを顕著に短くすることができる。そして、出現する符
号の大部分はこの形式を使うのに十分なほどに短いか
ら、このことは特に好都合である。この形式を使ってい
ることは、当該バイトの上位３ビットの位置を非零値に
することにより示す。

【００５６】すべての長いビット・パターンに対して
は、長さの表示だけをＳとして格納する。そして、上位
ニブルを「００００」に設定して異なった形式であるこ
とを表示する。これら長い符号の場合、ｓｅｅｄ（すな
わち特定ビット長の最初の符号値）への索引として当該
長さを使う。次いで、参照テーブルから対応するオフセ
ットを決定し、それを当該ｓｅｅｄに付加して当該符号
値を生成することができる（最大オフセットが２５５で
あるから、上記オフセットは１バイトの中に納まる）。
Ｒ／Ｓバイトを符号化して格納した後、余分のＳビット
を符号化する。この符号化は、図１４の中間データ形式
の各ＡＣ係数値の２バイトから可変長を展開するように
シフトして行なうのが望ましい。

【００５７】上述した点から、本発明によれば、符号化
用のデータ処理の効率が向上すると共に、ハフマン・テ
ーブルを検索ためのテーブルを計算して格納する効率が
顕著に向上する。これらの利点は、ＪＰＥＧ標準に完全
に準拠した方法でもたらされると共に、ハフマン符号化
のすべての用途に適用可能である。

【００５８】ＪＰＥＧ標準に関する好適な一実施形態の
観点から本発明を説明したけれども、本発明は特許請求
の範囲の本旨と範囲の内で変更して実施することができ
る、ということを当業者は認識できる。例えば、これら
高速符号化法と高速復号化法は、昇順に並んだ各長さの
多くの符号から構築されるすべてのハフマン・テーブル
に適用できる。さらに、当業者は、本発明の上の説明か
ら、上述した手法を降順に並べて構築したハフマン・テ
ーブルに適用することができる。

【００５９】まとめとして以下の事項を開示する。 （１）記号をハフマン符号化するハフマン符号化法であ
って、１つのテーブルにおける所定長の符号の最初の出
現に対するシード値を定義するステップと、１つの符号
語の長さを格納するステップと、前記数および前記符号
語のビット数が所定ビット数以下の場合、前記長さおよ
び前記符号語を第１の形式で格納するステップと、前記
数および前記画像データが前記所定ビット数を超えるビ
ット数から成る場合、前記シード値への索引、オフセッ
ト、および前記符号語を第２の形式で格納するステップ
とを備えたハフマン符号化法。 （２）前記記号がＪＰＥＧ Ｒ／Ｓバイトである、上記
（１）に記載のハフマン符号化法。 （３）前記符号語が画像データである、上記（１）に記
載のハフマン符号化法。 （４）前記画像データがＪＰＥＧ画像データである、上
記（３）に記載のハフマン符号化法。 （５）圧縮データをハフマン復号化するハフマン復号化
法であって、複数の試験基準の各々を使ってデータ・ス
トリームのビットを試験して有効なハフマン符号の長さ
を判断するステップと、前記長さに対応する複数のオフ
セットのうちの１つと前記有効なハフマン符号とを組み
合わせて、索引を生成するステップと、前記索引を使っ
て、ハフマン・テーブル中の記号値にアクセスするステ
ップとを備えたハフマン復号化法。 （６）さらに、前記試験基準および前記複数のオフセッ
トを、ハフマン・テーブルのデータから計算するステッ
プを備えた、上記（５）に記載のハフマン復号化法。 （７）前記圧縮データが画像データである、上記（５）
に記載のハフマン復号化法。 （８）前記画像データがＪＰＥＧ画像データである、上
記（７）に記載のハフマン復号化法。

【図面の簡単な説明】

【図１】 ＪＰＥＧ標準によるハフマン・テーブル仕様
の構文を示す図である。

【図２】 ＡＣ ＤＣＴ係数またはＤＣ ＤＣＴ係数差
分のハフマン符号化を示す図である。

【図３】 ＪＰＥＧ標準による典型的なハフマン・テー
ブル仕様とエントロピー符号化した画像データを示す図
である。

【図４】 輝度ＤＣ ＤＣＴ係数差分値に適したハフマ
ン符号の典型的なテーブルを示す図である。

【図５】 クロミナンスＤＣ ＤＣＴ係数差分値に適し
たハフマン符号の典型的なテーブルを示す図である。

【図６】 本発明の実施に使用可能な別のハードウェア
の実施形態の概念図である。

【図７】 本発明の実施に使用可能な別のハードウェア
の実施形態の概念図である。

【図８】 本発明の実施に使用可能なハードウェアの実
施形態を幾分詳細に示す概念図である。

【図９】 本発明による比較値とハフマン・テーブル・
ポインタ・データの計算の好適な形態を示すフローチャ
ートを示す図である。

【図１０】 ハフマン符号化したＲ／Ｓ値を含む圧縮デ
ータの復号化における本発明の方法論を示すフローチャ
ートを示す図である。

【図１１】 図１０のプロセスの好適な機能を示すフロ
ーチャートを示す図である。

【図１２】 図１０のプロセスの好適な機能を示すフロ
ーチャートを示す図である。

【図１３】 図１０のプロセスの好適な機能を示すフロ
ーチャートを示す図である。

【図１４】 ハフマン符号化を迅速に実行しうる元にな
るパックした中間データ形式を示す図である。

【図１５】 本発明による符号化のフローチャートを示
す図である。

【図１６】 符号化テーブルの初期化を行なうフローチ
ャートを示す図である。

【図１７】 図１５の一部の好適な実現方法を示す図で
ある。

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ジョアン・エル・ミッチェル アメリカ合衆国 コロラド州 80503、ロ ングモント、17番 アベニュー 2400、ユ ニット 103ディー (72)発明者 アルバート・エヌ・カゼス アメリカ合衆国 ニューヨーク州 10549、 マウント キスコ、ウエスト ウエイ ９ (72)発明者 ニール・エム・リーダー アメリカ合衆国 ノース・カロライナ州 27502、エイペックス、セイモア クリー ク ドライブ 109 Ｆターム(参考） 5C059 KK06 KK15 MA00 MA23 MC33 MC34 MC38 ME02 ME17 PP01 SS06 SS11 UA02 UA05 UA38 5C078 AA04 BA57 CA25 DA01 DA06 5J064 AA03 AA04 BA09 BA16 BB05 BC01 BC02 BC04 BC08 BC14 BC29 BD01

Claims (8)

【特許請求の範囲】
1. 【請求項１】記号をハフマン符号化するハフマン符号化
   法であって、 １つのテーブルにおける所定長の符号の最初の出現に対
   するシード値を定義するステップと、 １つの符号語の長さを格納するステップと、 前記数および前記符号語のビット数が所定ビット数以下
   の場合、前記長さおよび前記符号語を第１の形式で格納
   するステップと、 前記数および前記画像データが前記所定ビット数を超え
   るビット数から成る場合、前記シード値への索引、オフ
   セット、および前記符号語を第２の形式で格納するステ
   ップとを備えたハフマン符号化法。
2. 【請求項２】前記記号がＪＰＥＧ Ｒ／Ｓバイトであ
   る、請求項１に記載のハフマン符号化法。
3. 【請求項３】前記符号語が画像データである、請求項１
   に記載のハフマン符号化法。
4. 【請求項４】前記画像データがＪＰＥＧ画像データであ
   る、請求項３に記載のハフマン符号化法。
5. 【請求項５】圧縮データをハフマン復号化するハフマン
   復号化法であって、 複数の試験基準の各々を使ってデータ・ストリームのビ
   ットを試験して有効なハフマン符号の長さを判断するス
   テップと、 前記長さに対応する複数のオフセットのうちの１つと前
   記有効なハフマン符号とを組み合わせて、索引を生成す
   るステップと、 前記索引を使って、ハフマン・テーブル中の記号値にア
   クセスするステップとを備えたハフマン復号化法。
6. 【請求項６】 さらに、 前記試験基準および前記複数のオフセットを、ハフマン
   ・テーブルのデータから計算するステップを備えた、請
   求項５に記載のハフマン復号化法。
7. 【請求項７】前記圧縮データが画像データである、請求
   項５に記載のハフマン復号化法。
8. 【請求項８】前記画像データがＪＰＥＧ画像データであ
   る、請求項７に記載のハフマン復号化法。