JP2010016841A - データを送信する方法及び圧縮する方法 - Google Patents

データを送信する方法及び圧縮する方法 Download PDF

Info

Publication number
JP2010016841A
JP2010016841A JP2009184109A JP2009184109A JP2010016841A JP 2010016841 A JP2010016841 A JP 2010016841A JP 2009184109 A JP2009184109 A JP 2009184109A JP 2009184109 A JP2009184109 A JP 2009184109A JP 2010016841 A JP2010016841 A JP 2010016841A
Authority
JP
Japan
Prior art keywords
data
frame
image
block
conversion
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2009184109A
Other languages
English (en)
Inventor
Peter Lionel Smith
ライオネル. スミス ピーター
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Electrosonic Ltd
Original Assignee
Electrosonic Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Electrosonic Ltd filed Critical Electrosonic Ltd
Publication of JP2010016841A publication Critical patent/JP2010016841A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/65Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience
    • H04N19/68Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience involving the insertion of resynchronisation markers into the bitstream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103Selection of coding mode or of prediction mode
    • H04N19/107Selection of coding mode or of prediction mode between spatial and temporal predictive coding, e.g. picture refresh
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/174Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a slice, e.g. a line of blocks or a group of blocks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/182Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a pixel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a colour or a chrominance component
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/1883Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit relating to sub-band structure, e.g. hierarchical level, directional tree, e.g. low-high [LH], high-low [HL], high-high [HH]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • H04N19/33Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability in the spatial domain
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/507Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction using conditional replenishment
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/63Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/63Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
    • H04N19/635Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets characterised by filter definition or implementation details
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/63Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
    • H04N19/64Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets characterised by ordering of coefficients or of bits for transmission
    • H04N19/645Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets characterised by ordering of coefficients or of bits for transmission by grouping of coefficients into blocks after the transform
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/63Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
    • H04N19/64Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets characterised by ordering of coefficients or of bits for transmission
    • H04N19/647Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets characterised by ordering of coefficients or of bits for transmission using significance based coding, e.g. Embedded Zerotrees of Wavelets [EZW] or Set Partitioning in Hierarchical Trees [SPIHT]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/65Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience
    • H04N19/66Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using error resilience involving data partitioning, i.e. separation of data into packets or partitions according to importance
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/86Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving reduction of coding artifacts, e.g. of blockiness
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91Entropy coding, e.g. variable length coding [VLC] or arithmetic coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96Tree coding, e.g. quad-tree coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/14Picture signal circuitry for video frequency region
    • H04N5/142Edging; Contouring
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/12Systems in which the television signal is transmitted via one channel or a plurality of parallel channels, the bandwidth of each channel being less than the bandwidth of the television signal
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/14Systems for two-way working
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/13Adaptive entropy coding, e.g. adaptive variable length coding [AVLC] or context adaptive binary arithmetic coding [CABAC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Compression Of Band Width Or Redundancy In Fax (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Image Processing (AREA)

Abstract

【課題】データの有効な符号化を可能とし、損失なし、または損失ありのいずれかである空間的および時間的両方の画像データ圧縮の方法を提供。
【解決手段】データを送信する方法は、それぞれのフレームが所定の複数のデータブロックを備えるよう、データを第1のフレームおよび少なくとも1つの後続のフレームを備えるフレームの1つのシーケンスにグループ化する工程、第1のフレームを全て送信する工程、第1のフレーム内の対応するデータブロックと著しく異なる前記またはそれぞれの後続のフレーム内のデータブロックだけを送信する工程であって、それぞれのかかるデータブロックは、フレーム内におけるブロックの位置を定義するそれぞれの指標番号と組み合わせて送信される工程、を包含する。
【選択図】図12

Description

本発明は、データを送信する方法及び圧縮する方法に関する。
[圧縮の問題]
電子画像がすでにデジタル形式であると仮定すると、画像圧縮は、画像を表現するのに必要とされるデータビットの数を大幅に削減する手段である。典型的なパラメータは次の通りである。
色パラメータ 3(例えば、RGBまたはYUV)
色当たりのビット 8(例えば、4、10、12)
水平画素 1400(または、例えば、720、1024、1600、1920)
垂直画素 1050(または、例えば、588、768、1200)
秒当たりのフレーム 60(または、例えば、24、30、85)
従って、60Hzで稼動するSXGA+(1400×1050)画像の場合、非圧縮データ速度は例えば次の通りであり、これは最上位モデル製品の典型的な要件であり得る。
3×8×1400×1050×60=2,116,800,000ビット/秒
元々はアナログ時代に導入されたものであるが、実際には現在にも等しく適用できる帯域幅縮小の「典型的な」方法としては、(a)代替の色空間を使うことによる色の縮小(例えば、縮小された彩度情報)、および(b)フレームごとのデータ縮小(例えば、それぞれが全フレーム解像度の半分である「インターレースされた」画像を使うことによって行うが、それでも動作を行うための高いフレーム速度が可能である)が挙げられる。
従って、(いわゆる1920iフォーマットに基づく)「高品位」画像データ速度は次のようになり得る。
16×1920×1024×30=943,718,400ビット/秒
しかしながら、かかる構成は、せいぜいよくても部分的に問題点を緩和するにすぎない。明らかに、さらにもっと積極的な方法が必要である。映像からUXGAにわたる画像のための目標ビット速度は、動作量が変動する状態で、0.5から100Mb/秒にわたるが、10Mb/秒未満の速度に重点を置く。
[圧縮の基礎]
画像圧縮には、空間的圧縮と時間的圧縮の2つのタイプがある。空間的圧縮は、単一画像フレームを記述するのに必要とされる情報量を削減するものであり、時相的圧縮は、フレームごとに全フレームデータを送る必要を少なくしつつも圧縮されていない画像における動きは維持したままとするものである。
空間圧縮を使って単一画像フレームを圧縮するための望ましい方法は次の通りである。
(a)画像をより効率的または「簡便な」やり方で記述できる方法を見出す。例えば、広い領域が緑色で着色されている場合、ただ単にこの領域を限られた数の座標で定義し、これを画素ごとに記録するのではなく「緑」とコード化する。
(b)必要に応じて、人間の視覚の公知の特徴を利用し、見る人物には見えないかもしれない画像の局面に関するデータを排除するかまたは少なくする、および、
(c)得られた数値データを取りこれを、例えば冗長なゼロを抑制するまたはランレングス符号化のような標準的な損失なしのデータ圧縮技術によって、より効率的に記録する。
時間的圧縮のための主な方法は、連続的な画像を比較し、1つの画像と他の画像との変化に対して送信される情報を制限することである。かかる方法を使用する場合、全フレーム画像またはその等価物を周期的に送って画像の復元が正しいデータから確実に起こるようにする方法がなければならない。
[圧縮システムの必要な属性]
特定の用途向けの圧縮システムを開発する際、数多くの優先すべき事項を次のように特定できる。
(a)システムは最小限の待ち時間でリアルタイムに作動しなければならない。
(b)システムはさまざまな「ビット深さ」に適さなければならない。8ビット画素が典型的に使用されるが、特定の用途ではシステムを10または12ビット画素まで拡張するのが望ましいであろう。
(c)システムは空間的解像度の点でスケーラブルでなくてはならない。最も高い現行の解像度は1600×1200(UXGA)であるが、原則としてシステムはより高い解像度が導入された場合これらにも対応できるべきである。
(d)ハードウェアの点で、システムは「対称的」である必要がある、すなわち、符号器を実現する費用は復号器を実現する費用と大幅に異なるべきではない、(ただし用途によってはソフトウェアベースの復号器の場所もあることが認識される)。
(e)システムは標準的なコンポーネントを使って実現できなければならない(ただし大容量用途向けにはASICバージョンが考えられるであろう)。
(f)高解像度画像データ全体を処理する必要なしに、高解像度画像の低解像度バージョンを抽出できるまたは高解像度画像の一部を抽出できなければならない。かかる特徴は非常に重要である。
[ウェーブレット変換の選択]
実用的な空間的画像圧縮システムは、画像情報中の冗長性を簡単に識別でき排除できる方法を必要とする。理論的には元の画素数値データを分析することは可能であるが、現実にはこれは非効率的であり計算的に集約されてしまう。
現状の手法は、元の画素データを他のフォーマットに「変換」することである。新しいフォーマット自身は画像を表現するのに必要なデータ量を少なくすることはしないが、これが行うのは、冗長な情報を簡単に識別し排除できるようにデータを表示するということである。この新しいフォーマットはまた、効率的に符号化できるやり方でのデータ表示もする。
変換の考え方は、フーリエ法則によって例示される。この法則は、調和して関連し合う振幅の変動する数多くの正弦波を一緒にすることによって、どのような複雑な波形でも再生できることを示している。使用する高調波の数が多いほど、得られる結果は元の波形に近くなる。従って、例えば、「矩形波」は、その振幅が等間隔でゼロから最大値まで変化しそして再び戻るものとして示される「時間」ドメインか、または元の波形の基本周波数のそれぞれの高調波に当てはまる1組の係数が規定される「周波数」ドメインのいずれかで記述できる。
変換の概念は、矩形波の例によりほぼ近い形で図示される。高調波の振幅を周波数に対して描く場合、結果はSinx/x関数である。
図1は、このような「変換対」を示している。左側の波形が時間に対する振幅を表す場合、右側のものは周波数の分布を示しているが、これが逆であっても同じことが当てはまる。すなわち、左側のものが周波数の分布を示す場合、右側のものはその結果得られる、時間に対する振幅である。
図示される変換対の特徴は、左側の関数が狭くなるほど右側の関数が広くなるということである。このことは、もし狭い範囲の周波数だけがある場合、得られる振幅分布は「広く平坦になる」であろうと言うのに等しい。周波数分布がゼロになる場合の限界点では、結果は長さが無限大の平坦な線、すなわち「直流」になる。
この変換対の例について興味深い点は、これがどのように時間/周波数変換を作成することができるかについての手がかりを提供することである。左側の関数がフィルタの帯域幅を表す場合は、右側の関数はフィルタのインパルス応答を表す。
画像圧縮は、実際に、まさに周波数ドメインの考え方を使うものである。通常の構成では、画像を複数のブロックに分割し、ブロックはそれぞれが画素のアレーからなる。そして、周波数分布についてそれぞれのブロックを検討する。画像の「縁」では「高い」周波数が生じるが、均一な「輝度」の領域は「低い」周波数を示す。
画像圧縮のためのもっとも公知の変換は離散コサイン変換(DCT)であり、これはフーリエ変換の空間版である。その原理は、広い範囲の周波数に対して画像データを「試験」し、それぞれについて係数を生成するというものである。このプロセスは、それ自体が原則的に無限の正弦波(ただし実際には必ず上が切り取られた状態になる)である基底関数の使用を必要とする。DCTの特徴は周波数ドメインを等しい増分に分割する点であり、このことの当然の帰結として、基底関数は周波数に従った異なるサイクル数を含む。
DCTに代わるものとしてウェーブレット変換が普及しており、これは入力帯域幅を半分に分割する、カスケード状に配列された一連の補完的な高いおよび低いパスフィルタを使って実行されるものである。それぞれのフィルタの出力は図2に図示されるように2分の1にダウンサンプルされるため、カスケードの出力データは入力データと同じ大きさである。ハイパスフィルタのインパルス応答は「ウェーブレット」である。
ウェーブレットの特徴は、この文脈では、ウェーブレット基底関数が、周波数に関わりなくすべて同じサイクル数を含んでいることであり、このことはこれらが異なる長さであることを意味する。図示されるカスケード構成では、ウェーブレットのセットは、それぞれのステージで2分の1に変倍された1つの単一のウェーブレットから導き出されている。
カスケードの終わりには、厳重に帯域が制限された信号がある。前回の周波数帯域から係数を追加すると利用できる解像度が2倍になり、処理が繰り返されると、解像度が再び2倍になる。このことはウェーブレット変換の3つの属性を表している、すなわち、
(a)当然ながら変倍可能である。
(b)周波数ドメインが等しい増分ではなくオクターブに分割される。
(c)画像処理の状況では、利用可能なデータの一部だけを使うことによって画像の低解像度版を得ることが可能である。
簡単な例を挙げると、もし16個の入力サンプルが4つのステージのカスケードに供給されると、最初のステージでは差分の8つのサンプルを作成することになる。次のステージでは4つの、その次の2つの、そして最終的には差分の1つのサンプルを、単一の値とともに生成することになる。この単一の値はローパスフィルタのシーケンスから由来するもので、16個すべてのサンプルの平均的な「輝度」とみなすことができる(直流成分)。出力サンプルの総数は入力総数と同じである、すなわち、
(8+4+2+1)個の差分+(1)個の平均値=16
画像の高周波数成分は数多くの短いウェーブレットによって記述され、低周波数部分は数少ない長いウェーブレットによって記述される。
ウェーブレット変換は、時期が合う一連の離散的信号とみなすことができ、これらの離散的信号はそれぞれが画像の複数の解像度分析を提供するものである。変換の目的は、画像をより重要性の大きな係数またはより重要性の低い係数に分解することである。そして、あまり重要でない係数は量子化または排除できる。ウェーブレット変換は(他の変換と比べると)有意の係数をもっともよい形でコンパクト化するものである。
電子画像は「1次元的」ではなく、2次元的画素アレーからなる。従って、画像圧縮では、変換プロセスを2次元で行う必要がある。単一段ウェーブレット分解のプロセスを図3に示す。元の画像はろ過されて4つの周波数帯となる、すなわち、LLは、水平および垂直方向の両方にローパスフィルタ化されサブサンプル化された元の画像である。HLは、残りの垂直周波数、すなわち、元の画像とLL画像との間の差の垂直成分からなる。同様に、LHは残りの水平周波数からなり、垂直および水平両方のフィルタリングの高周波数成分からなるHHは、残りの斜め周波数を表している。
実際には、多段分解が生じる。LLは解像度が低くされた全体の画像(または画像の一部)を表しているため、ここでLL画像に対しフィルタリングプロセスを行って第2レベルの分解を行う。損失なしの変換(すなわち、情報内容が失われることのない変換)を行うためには、個々の画素の空間的な等価物までプロセスを繰り返す必要がある。
従って、例えば、プロセスを4×4画素ブロックに適用する場合、「レベル1」変換を想定できる。この場合、水平および垂直方向の両方にフィルタ対を適用することによって4つの係数が導かれる。そして、「レベル2」変換でローパスフィルタの出力を表している情報の4分の1に対し同じプロセスを行う、これは空間的な意味では画素レベルである。(ブロックがより大きかった場合は、損失なしの変換を行うのにより大きな「レベル」が必要になると思われる。)
変換の復号化(「再構築」)は符号化(「分解」または「破壊」)プロセスの逆であり、どのような現実の実行でも高度に対称的であることを指す。簡素なフィルタ対レベルでは、もし2つの入力の流れが2倍にアップサンプル化され、その後、ろ過されそして再度組み合わされると、得られる結果は元の空間的データである。完全な再構築が起こるためには、復号化フィルタは符号化フィルタの応答と正確に一致しなければならず、「レベル」数が同じでなければならない。
好ましい圧縮法の基礎としてウェーブレット変換が選択された。なぜなら、
(a)固有のスケーラビリティを持つ、
(b)有意な変換係数をもっともよい形でコンパクト化する、
(c)イメージデータ全体を処理せずして画像の低解像度バージョンを簡単に導き出せる、
(d)高速平行処理に変更可能である、
(e)効率的な符号化に変更可能である、そして
(f)(変換へのまたは変換からの)符号化および復号化プロセスが対称的であるからである。
ウェーブレット変換に基づいて圧縮システムを実現する際、システムが標準的な機材を使って実現するよう実行可能でありまた市場のニーズを満たすことを確実にするための、多数の重要な実行上の点を考慮に入れるべきである。
設計に多大な影響を及ぼすいくつかの特定の点としては次のものが挙げられる、
(a)システムは損失なしの(典型的な実現される割合は2:1)から視覚的に損失なしの(おそらく30:1と高い)にわたり損失ありの(50:1以上)までに及ぶ広い範囲の空間的圧縮比に対応できなければならない。
(b)符号化および復号化プロセスの作業は、画像の複雑さに関わりなくこれらが定義された時間サイクル内で作動しなければならない意味で決定的でなければならない。明らかに、これらは「リアルタイム」に作動しなければならない。
(c)フルモーション「ビデオ」画像および高解像度「グラフィック」画像の異なるニーズを全面的に考慮しなければならない。
システム全体の説明はセクションに分割でき、次のように要約される。
(a)入力システム、色空間の選択、
(b)ウェーブレット変換エンジン、
(c)得られたデータの符号化
(d)一時的圧縮のための符号化
(e)ネットワーク接続、および
(f)復号化
画像入力からデータストリーム出力までの異なるステージを図5に図示する。
実際のシステムは、実行可能である限り、既存の標準に基づいていなければならない。従って、好ましいシステムへの「入力」は現在のデジタル画像標準、主にコンピュータグラフィック画像のためのDVI標準、およびビデオおよび高品位ビデオ画像のためのSDIおよびHDSDI標準に基づいている。DVIそれ自体は事実上1600×1200(画素当たり24ビット)の画像解像度に制限されているが、複数のDVI信号をいくつかの組に編成してより大きな画像を記述することが可能である。明らかに、いずれの実際のシステムもより高い解像度および新しいトランスポート基準に、それらが利用可能となると同時に適合するように設計されていなければならない。
電子画像は通常、色パラメータRGB(赤、緑、青)によって記述される。従って、原則的にはいずれの圧縮システムも3部構成で作動しなければならない。すなわち、色パラメータそれぞれ対して1つの「チャネル」である。これは、一般にYUVと呼ばれる他の色空間に使うのに都合がよいもので、この場合、Yは「輝度」または「白色明るさ」値であり、UおよびVは一括して「クロミナンス」または「色差」値と呼ばれる2つの「色差」値である。RGBからYUVへの基本的な変換ではデータ量が減ることはないが、実際には、人間の目は輝度空間的解像度に比べるとクロミナンス空間的解像度に対する感度が鈍い。従って、この事実がカラーテレビ帯域軽減の手段としてその発足当初から使用されてきた。
YUVの使用に限られるわけではないが、好ましいシステムはこれに基づいている、なぜならこれを使用することでクロミナンスおよび輝度情報について微分符号化速度が可能となり、その結果、人間の目の応答性を利用して圧縮効率が改善されるからである。RGBとYUVとの間の変換は簡単な演算のように見受けられるが、画像の劣化かデータ量の増加のいずれかを招く可能性のある落とし穴がある。
CCIR601標準は以下のマトリックスによって成分ビデオを定義している。
Figure 2010016841
このマトリックスは、それ自体は損失なしの可逆転換には適さない、なぜなら転換要因として非整数を使用するからである。従って、好ましいシステムは以下の数式を使用する。この数式はCCIRマトリックスの近似を表しており、損失なしの可逆転換を実現するものである。ここで、Y、U、よびVは可逆輝度およびクロミナンス値である。
Figure 2010016841
上述の数式で、記号exuは「床」関数と呼ばれるもので、x以下の最大整数として定義されるものである。上述の数式は以下の属性を持つ。
(a)入力がNビットのRGBであれば、損失なしの変換もまたNビットを持つYrとなるが、UrおよびVr成分はN+1ビットを持つ。
(b)その後、成分が逆転されると、結果はNビットのRGB信号である。
本発明の背後には開発の一部として2つの問題が生じる。すなわち、
(a)ウェーブレット変換に適用した場合、クロミナンス成分における余分なビットの生成を損失なしの性能を失うことなく吸収することは可能であるか。
(b)損失ありの圧縮が必要な場合、数式を改変して性能を最適化すべきか。
1つの重要な発見は、損失なしの動作を行うための色変換およびウェーブレット変換ビット成長は両方とも、組み合わされた結果を精度保存の特性(PPP)と呼ばれる特性に適用することによって省けるであろうということであった。この技術のさらなる詳細は、非特許文献1に見出すことができる。しかしながら、上述の数式およびPPP技術は両方とも、損失なしの変換だけに適用されるものである。
損失ありの変換が必要な場合は、他の技術を使用する。ここで、その目的はただ単に元の範囲を保存し確実にビット成長がないようにするだけである。これは以下の数式を使って実現される。
Figure 2010016841
1997年12月Hongyang Chao, Paul Fisher, Zeyi Hua著「An Approach to the Integer Wavelet Transformations for Lossless Image Compression(損失なしの画像圧縮のための整数ウェーブレット変換の方法)」
データの有効な符号化を可能とし、損失なし、または損失ありのいずれかである得る空間的および時間的両方の画像データ圧縮の方法を提供することにある。
本発明の一の側面によると、それぞれのフレームが所定の複数のデータブロックを備えるよう、データを第1のフレームおよび少なくとも1つの後続のフレームを備えるフレームの1つのシーケンスにグループ化する工程、第1のフレームを全て送信する工程、及び、第1のフレーム内の対応するデータブロックと著しく異なる前記またはそれぞれの後続のフレーム内のデータブロックだけを送信する工程、を包含することを特徴とする、データを送信する方法が提供される。
この方法は画像データを送信する既存のシステム全体にわたって多大な利点を提供するものであり、連続した画像フレーム間の違いに関する情報を送信して所望の画像フレームを再構築するようにする。万が一、送信エラーが生じた場合は、かかるエラーはこのような場合であればさらに別の完全なフレームが送信されるまで続くであろう。これに対し、上述の方法を使うと、連続的なフレーム間の変更を行ったブロックだけが送信され、これらを使ってその後の所望のフレームが作成される。
本発明は、好ましくは、所定のアルゴリズムに従って前記データブロックのそれぞれを処理してそのデータブロックについてパラメータを評価する工程、および前記またはそれぞれの後続のフレーム内のそれぞれのデータブロックについて、関連するパラメータの値がシーケンス内の先行するフレームの対応するデータブロックと著しく異なるかどうかを判断する工程をさらに包含し、著しく異なるデータブロックだけを送信する工程は、肯定的な結果の出た前記またはそれぞれの後続フレーム内にあるデータブロックだけを送信する工程を包含する。この機能は、連続したフレームのブロック間の測定された差異を「しきい値」する方法を効果的に提供し、その結果、有意な差異だけを示すブロックだけが送信されるようにする。
データをグループ化する工程は、それぞれがn個のフレームを備える複数の前記シーケンスにデータをグループ化する工程を包含してよく、nは所定の値であり、それにより少なくとも1つのフレーム全体がデータのn個の連続的なフレームのそれぞれのシーケンス内に送信される。
本方法は、好ましくはさらに別のフレーム全体を等間隔で送信する工程をさらに包含する。
本方法は、好ましくは要求信号を受信すると、さらに別のフレーム全体を送信する工程をさらに包含する。
本発明は、データを圧縮する類似に方法にもおよんでいる。この方法は、それぞれのフレームが所定の複数のデータブロックを含むよう、データを第1のフレームおよび少なくとも1つの後続するフレームを含むフレームのシーケンスにグループ化する工程、第1のフレームを全て圧縮する工程、および、第1のフレーム内の対応するデータブロックと著しく異なる前記またはそれぞれの後続のフレーム内のデータブロックだけを圧縮する工程を包含する。
もし圧縮すべきデータがウェーブレット変換されている場合、パラメータは通常、それぞれのデータブロックのそれぞれのサブ帯域内での最上位の係数だけに基づいて評価され得る。この場合、パラメータは好ましくはその最上位の係数のデータブロック内での位置に基づいて評価される、そしてそれぞれのデータブロックのそれぞれのサブ帯域内での最上位の係数からなるグループから選択されたn個の最上位の係数だけに基づいて評価され得る。ここで、nは所定の数である。この場合、nは8に等しくあり得る。
ウェーブレット変換は、16個のサブ帯域を生じる5レベル変換であり得る。
本方法は、好ましくは圧縮されたデータだけを送信する工程をさらに包含する。
もしデータがカラー画像データを含んでいれば、前記パラメータを評価するためにこのカラー画像データの輝度成分だけを処理するのが好ましい。
好ましくは、所定のしきい値よりも大きな値を持つそれぞれのブロック内のデータの成分だけを処理して、そのデータブロックについてのパラメータを評価する。
本発明によれば、連続的なフレーム間の変更を行ったブロックだけが送信され、これらを使ってその後の所望のフレームが作成されるようにすることができる。
「変換対」の一例を図示している。 カスケードになった1セットのフィルタを使ってどのようにウェーブレット変換が実行されるかを図示している。 単一段のウェーブレット分解を示している。 復号器における単一段のウェーブレット再構築を示している。 好ましい符号器内のプロセスを図示している。 5レベル分解を図示している。 ブロックベースのハール変換を図示している。 変換の動作を図示するための画素アレーの一例を示している。 数式1および2を図8のアレーに適用した結果を図示しており、これら数式はr=0…9およびc=0…4の範囲で解かれている。 数式5、6、9および10を図9示す水平変換データに適用した結果を図示しており、範囲はr=0…4およびc=0…4であり、例示的な画素アレーのためのハール変換を表している。 2/10変換数式をサンプル画素アレーに適用した結果を図示している。 符号化システム全体のアーキテクチャを示すブロック図である。 好ましい変換エンジンを詳細に図示している。 メモリにおける連続的な書き換えを図示している。 どのようにして係数データが分析されるかを示すCKL−ツリーを図示している。 64LタイプからなるLツリーを図示しており、24が図上の「Lボックス」として示されており、残りの40はレベル3LHおよびHHLタイプの子供として暗示されている。 8つすべてのデータ面を複合物として検討することにより符号化損失を省く概念を図示している。 5レベル変換に適用される重み付け要因の概念を図示しており、典型的にはa=2である。 どのようにして1ビット面の係数データの組織がウェーブレット変換に直接関連するかを図示している。 好ましいL符号器を図示している。 好ましいCS符号器を図示している。 LKCSパスを図示している。 好ましい一時的符号化プロセスの図式化である。 標準的なイーサネット(登録商標)で使用されるIEEE802.3フレームフォーマットを図示している。 圧縮された画像ストリームのIPパケットへの変換を図示している。 ビットストリームの一部を示しており、2つの連続的な画像ブロックを、互いに同期言語、および画像内のブロック位置を特定する指標番号が関連し合った状態で示している。
ここで本発明の好ましい実施態様を、添付の図面を参照しながら詳細に説明する。
[ウェーブレット変換エンジン]
好ましい設計の大きな利点は、画像の破壊および再構築に同じ「エンジン」を使用することができる点である。この設計は、リアルタイムに2次元で5レベル変換を実行する単一フィルタバンクからなるアーキテクチャを使用する。
上述から、5レベル変換を使用することにより32×32画素ブロックを記述するデータが得られることがわかる。しかしながら、もしこれが文字通り符号化段階における場合であったなら、最終的な結果は「濃淡のむらのある(blocky)」画像(特に高い圧縮割合では)となるであろう。ブロックの端にある画素に関連するデータが隣接するブロックの画素のエネルギーを完全に考慮することを確実にするには、変換プロセスは画素アレー全体を「掃引」しなければならない。従って、得られるデータは、実際には一連の32×32ブロックを表すものとしてフォーマットされるが、このようにして得られた画像情報それ自体はブロックベースではない。
図6は、5レベル変換プロセスの目的を示している。レベル3には16個の係数があり、レベル4には4つの係数があり、レベル5には1つの係数がある。ウェーブレット変換が信号をさまざまなサブ帯域に分解できる方法はいくつかある。かかる方法としては、均一な分解、オクターブ帯域分解、および適応またはウェーブレットパケット分解が挙げられる。これらのうち、オクターブ帯域分解がもっとも広く使用されている。これは不均一帯域分裂法であり、より周波数の低い部分をより狭い帯域に分解し、それぞれのレベルのハイパス出力にはさらなる分解を全くせずしてそのまま残すものである。
システムをさまざまな供給源材料に最適なものにするために、好ましいシステムは2つの異なるウェーブレット変換を使用するようセットアップされる。ハール変換は鮮明な切れ目または「エッジ」の定義が正確である必要がある場合に材料に使用され、「ツー/テン」またはTT変換は、「円滑な」結果がより喜ばしい場合にビデオ画像を移動するための別の方法として提供されるものである。
ハール変換は、鮮明な切れ目(実際には細い線など)の一体性を維持することが非常に重要なグラフィック画像の圧縮に最良である。移動しているビデオ画像をともなう場合、異なる変換を使用すると恩恵があり、好ましいシステムは、使用されている画像のタイプに従ってハール変換をとるか「ツー/テン」(またはTT、または2/10)変換をとるかの選択が可能である。
過酷な圧縮を行うと、画像を再構築した場合、画像人工物がブロック境界に現れる傾向がある。2/10変換はより多くの画素をハイパスフィルタで処理するがこれには画像を「円滑化する」効果があり、ビデオ内容において視覚的により許容される結果を与える。
ブロックベースのハール変換では、画像は32×32画素ブロックで処理され、1つのブロックがY、UおよびVそれぞれのためのものである。このことを図7に図面によって示す。実際には、画素はそれぞれが2画素×2画素の16×16重複なしブロックとして処理される。実際の処理、およびそれが2/10変換に必要とされる処理に類似する点を以下に説明する。
両方の変換で、2段処理を使用する。第1段では、1次元的変換で画素データから2つの係数LおよびHが導き出され、そして第2段では、2次元的変換によりLL、LH、HLおよびHH値が導き出される。実際のところ、当初のローパスフィルタリングのための数式は両方の変換について同じである。ハイパスフィルタリングも似通ってはいるが、2/10変換の場合、既存の導き出されたローパス値を観察した結果導き出されるさらに別の「予測」値がある。このことは得られる画像を「平滑化」する効果がある。
以下の数式では、Pを使ってもとの画素データを表している。接尾辞r、cは縦および横の座標をそれぞれ表しており、pは予測子を示している。
数式1.ハールおよび2/10変換両方のためのLの誘導
Figure 2010016841
数式2.ハール変換におけるHの誘導
Figure 2010016841
数式3.2/10変換における予測子pHの誘導
Figure 2010016841
数式4.2/10変換におけるHの誘導
Figure 2010016841
数式5.ハール変換および2/10変換の両方のためのLLの誘導
Figure 2010016841
数式6.ハール変換におけるLHの誘導
Figure 2010016841
数式7.2/10変換における予測子pLHの誘導
Figure 2010016841
数式8.2/10変換におけるLHの誘導
Figure 2010016841
数式9.ハール変換および2/10変換の両方のためのHLの誘導
Figure 2010016841
数式10.ハール変換におけるHHの誘導
Figure 2010016841
数式11.2/10変換における予測子pHHの誘導
Figure 2010016841
数式12.2/10変換におけるHHの誘導
Figure 2010016841
[稼働中の変換数式の例]
上述の数式の動作は例によってもっともよく理解される。図8は、Pについていくつかの任意の値を持つ10×10画素の画素アレーを示している。レイアウトは純粋に2/10変換およびハール変換のはたらきに注意を引くための一例である。10×10アレーは2/10を例示するために使用できる最小限度のものでありその他の意味合いはない。
数式1および2を図8のアレーに適用した場合、結果は図9に示すとおりである。ここで、留意すべき点は、
(a)変換プロセスによりコラム数が半減する(数式はr=0....9およびc=0…4について解かれる)。
(b)とはいえ、画像データ全体の量は同じままである(これは2セットの係数LおよびHを持つためである)。
図9の結果は第1パスの「1次元的」水平変換を表している。図9の結果を数式5、6、9、および10に適用すると、第2の「2次元的」垂直変換が完了する。結果全体は完全なハール変換であり、図10のような形態である。ここで、どのようにして縦および横データが半分にされているか、しかしふたたびここでもデータ全体の量は同じままということに留意するべきである。
ハール変換がアレー全体に適用されることがわかるが、2/10変換を使う状況は全く違ったものである。ハール変換は2×2画素ブロックで作用するが、2/10はより数多くのデータ画素を必要とする。そして、実際のところ、例の場合、アレーの4つの中央の画素についてしか有効な結果を提供できない(すなわち、図8の値が80、48、45、110の画素)。
c=4..5およびr=2の範囲の数式1、3、および4を適用すると、LおよびHについて2/10値が得られる。その後、数式5、7、8、9、11、および12を解くと、LL、LH,HLおよびHHについて2/10値が導き出される。
図11は、実施例の場合のこれらの解答を示している。左側にはLおよびHについての解答を示し、右側にはLL、LH、HLおよびHHについての解答を示している。図11の右側の情報が、元の画素データを確実に回復可能とするのに転送されねばならない最小限のものである点に留意するべきである。
[逆方向変換]
ハールおよび2/10変換は両方とも可逆であり、損失なしおよび損失ありの圧縮両方に適している。しかしながら、説明した形態の上述の数式を使う場合、「詳細」出力にはビット成長がある(LLまたは「平滑」出力にはビット成長はない)。かかる理由により、好ましいシステムでは、出力変換データは上ですでに参照した「精度保存の特性」の原則を使って演算され、これにより損失なし性能を維持しつつもビット成長はなくなる。(このようにして適用される精度保存の特性(PPP)はHongyang, FisherおよびZeyiによるものである)
変換数式に関して理解すべき重要な点は、これらがすべて整数ドメインで演算されるがそれでも損失なしの結果を生み出す点である。ここでの洞察はPearlmanによるものであり、またRicohのGormishらにもよるものである。
ウェーブレット変換を実行するために設定される数式は上ですでに提供済みである。ここではプロセスを逆転させ画素データを回復するための対応する数式がその後に引き続く。
図10および図11に示す変換結果が以下に続く数式(適切な範囲にわたって演算される)に供給されると、現れる画素データはまさに図8に示すとおりのものになるであろう。
数式セット13.LおよびHを回復するための垂直逆転ハール変換
Figure 2010016841
数式セット14.画素を回復するための水平逆転ハール変換
Figure 2010016841
数式セット15.LおよびHを回復するための垂直逆転2/10変換
Figure 2010016841
数式セット16.画素を回復するための水平逆転2/10変換
Figure 2010016841
[変換エンジンの動作]
変換エンジンを実際に実現するにあたっての最も基本的かつ重要な点は、タスクを、それぞれ1つずつが完全に決定的な方法で動作する多数の簡素な工程にまで分解することである。解決すべきいくつかの問題点は次のとおりである。
(a)2/10変換が必要とする「ブロック外」画素データを取り扱うこと(ハール変換に関しては、32×32ブロックはそれ自体で処理できるが、2/10は、32×32変換を完成させるのにブロック全体および部分的なブロックからの画素からのデータを必要とする。)
(b)変換エンジン成分には垂直データを取り扱っているのか水平データを取り扱っているのかが「分からなくても」よいようにタスクを簡素化すること。それぞれの素子はただ単に簡素な算術的タスクを実行するだけにとどまるべきである。
(c)処理時間を短縮するための方策を見出すこと。5レベル2次元的変換処理には、続けざまにオペレーションを実行する必要性が内在しているため、単一フレーム分に相当する画素データを処理するのにかかる時間が複数となる。明らかに、1つのフレームを変換し符号化するプロセス全体がすべてもとのフレーム時間より短い時間内で実行できることが確実である必要がある。
図12は、符号化システムアーキテクチャ全体のブロック図であるが、ただしこのステージではアイテム1から7だけを説明することにする。YUV変換処理はすでに上で説明済みである。符号器およびパケタイザを以下に説明する。適正な変換エンジン、これは実際には2つの変換エンジンおよび大型メモリからなるものであるが、における主なプロセスをここで説明する。
1.画像データは変換エンジンの2つの画素に同時に入り、最初のタスクはレベル1水平変換である。これにより数式1、および数式2または数式4のいずれかに従ってLおよびHデータが生成される。H数式は、予測子を除いて同じであるため、ハール変換の場合であればpをゼロに設定した状態で単一セットの数式を使うことが可能なことがわかる。図13は、どのようにして典型的な画素nについてのデータが導き出されるかを示している。s(n)およびd(n)の値を導き出すためのフィルタ数式を以下に示す。図13は、どのようにして2/10変換の場合の予測子pが導き出されるかを示している。変換エンジンそれ自体は座標には関与しないため数式はsまたは「平滑な」成分、および/または「詳細」成分を示す簡素化された形態で表される。このステージでは、これらはLおよびHに対応する。
Figure 2010016841
2.図12は8ビット色を想定しているため、変換エンジンへの入力は48ビット幅で示されている(一度に2つの画素が読み取られる)。これが現れるときは、符号の追加により54ビット幅になっている。「18」から「36」ボックスが4つの変換係数のデータを組み合わせることによってデータを108ビット幅に変換する。これはメモリをローディングするのにかかる時間を短縮するための策略であるため、後続の2次元変換に必要とされるメモリに対する複数のパスアクセスを行うための時間がかせげる。
3.2つの変換エンジン1、5が大型DDR(二重データ速度)メモリ3によって供給される。メモリ3の入力および出力には多重スイッチ(MUX)が備わっている。入力側のスイッチは2つの変換エンジンの出力からのデータのいずれかを選択し、出力側のスイッチは第2の変換エンジンまたはコーダのいずれかにデータを送信する。メモリ3はデータの2つの画像フレームの等価物を含むのに十分な大きさである。連続的な奇数番号のフレームからの変換データはメモリ3の第1のセクションに保存され、偶数番号のフレームからの変換データは第2のセクションに保存される。
4.第1の変換の出力からのデータは32×32フォーマットでメモリ3から読み出される。後続のレベルの変換を実行するにはデータが第2の変換エンジンを通る複数のパスを経ることが必要である。エンジン自体が「ダム」となることができそれが横列のデータを処理しているのか縦列のデータを処理しているのかには無関係であるために、変換エンジンの外部には横列および縦列の制御が設けられている。変換エンジンに到着する前に、データは54ビット幅に並び戻される。
5.外部の横列および縦列制御を使うという概念は、第2の変換エンジン(5)を第1の変換エンジンと同一にするというものである。これ自身は単一次元でのみ機能するが、横列および縦列データを連続して取り扱うことで2次元的変換を生み出す。5レベル変換を生み出すには、YUVブロックデータは変換エンジンを通る複数のパスを持っていなければならない。これがフレーム時間内で可能な理由は、レベル1変換が時間の大部分を占める(約75%)ためである。後続のレベルは、複数のパスを必要とするものの、実際にはあまり時間をとることはない、なぜなら係数の数がずっと少ないからである(図6を参照のこと)。2/10変換を実行するには、再循環されたデータは「ブロック外」係数を含んでいなければならない点に留意する。
6.第2変換エンジンの出力はメモリに戻される前に108ビット幅に並び戻される。図14は、メモリ内における連続的な書き換えの概念を示している。左側はレベル1変換の結果であり、レベル2変換が完了すると、レベル1データのLL部分だけがレベル2データで上書きされる。この図面から、なぜ再循環されたデータの量がそれぞれのレベルの変換が完了するごとに少なくなるのなのかが明らかである。いったんレベル1の2次元的変換が完了すると、係数は図面の左側に従って保存される。その後、LL係数がレベル2についての新しいセットの係数によって上書きされる。これらは右側に描かれるようにメモリ内でまさに同じ空間を占める。このプロセスがレベル5まで繰り返される。
7.完成されたYUVブロック変換データはMUXによって符号器セクションに解放される。
次の点に留意することが重要である。まず第1には、元のYUVデータがRGBオリジナルに関して本質的に損失のないものであることを確認し、このデータすべてが変換プロセスへと進むことを確認する点。このことは専門的なビデオ用語ですべての処理が「4:4:4」である、と言うのに等しく、「縁部」での色漏れが絶対にないようにするものである。そして、第2には、変換ステージではブロック間で2/10係数を保存する概念によりフレームベースの変換の数多くの等価物が実現される点。これにより、最終的に得られる結果はブロックのない画像忠実度である。しかしながら、すべての変換管理およびすべてのその後のコード化はブロックドメイン内で行われる。このことは効率的かつ決定的な動作を得るにあたって鍵である。
[得られたデータの符号化]
上で述べたように、変換の当初の効果はデータの量を少なくすることではなく、圧縮をより効率的にするような形態でデータを提示することにすぎない。
データ圧縮は標準的な数学的方法(用途によって全く左右される)を使って行えるが、下層データの性質を利用するとよりよい結果を得ることができる。ウェーブレット変換データは、データが「ツリー」構造に組織されている場合、効率的な損失のない圧縮および損失のある圧縮に非常に向いている。
「ツリー」の使用の背後にある基本的な概念は、画像内の隣接し合う画素が似る傾向にあることである。変換ドメイン内では、このことは別のやり方で表わされる。分解のより高いサブ帯域におけるウェーブレット係数の大きさが特定のしきい値に対してあまり重要でない場合、同じ空間的位置を持つがより低いサブ帯域に関連しているウェーブレット係数もまたあまり重要ではない見込みがある。さらに、ウェーブレット「ピラミッド」のもっとも高いレベルからもっとも低いレベルへと進む場合、ウェーブレット係数の変動は小さくなる。このことにより、数多くの重要でないウェーブレット係数のコード化を非常に効率的に行えるという概念に結び付く。
公知の方法としては、空間オリエンテーションツリーまたはSOT(Shapiro)、およびヒエラルキーツリーにおけるパーティションニングセットSPIHT(Pearlman)が挙げられる。これら方法の両方が抱える問題点は、1回より多くデータを訪問する必要があることである。好ましい方法はまた、「4分ツリー」形態のツリー原則も使用するが、データを一回だけ訪問するだけでよいやり方でこれを使用する。これにより、正確に定義されたサイクルでタスクを実行するリアルタイムの単一パス圧縮エンジンの生成が可能となる。
システムの目的は、2つの異なるタイプの情報をコード化することである。1つの情報は「制御」またはコード化情報であり、他方は「データ」である。コード化情報はデータに先駆けて送信されるため、復号化システムはその後に続くデータをどのように取り扱うかを前もって知る。基本的な符号化システムは損失なしであるが、正確に定義されたレベルの損失あり圧縮に非常に向いている。
[LKCS符号化]
個々の画像に関するデータは32×32ウェーブレット係数のブロックに分割される。そしてこのブロックデータは9つの面、すなわち8つのデータ面と1つの符号面に分離される。そしてそれぞれの面は、図19に示し以下により詳細に説明するように16ビットの64列に並べ替えられる。
図15は、どのようにしてこのような1つの列が「CKL−ツリー」に符号化されるかを示している。話を簡素化するために16個の係数のデータビットを一列に示しているが、これらは実際には2次元的アレーについて言及していることを心に留めておかねばならない。これら16個の係数は4つのセットに分割され、それぞれのセットが「K型ツリー」に接続される。セット内のすべての係数がゼロであれば、対応するK型もまたゼロであり、K型を保持するだけでよい。もしセットがゼロでなければ、元の係数およびK型を保持する必要がある。(ブール項では、Kツリーは4つの入力を持つORゲートである。出力が0であれば、K=0の情報だけが保持される。出力が1であれば、K=1の情報および4つの個々のデータビットを保持しなければならない。)
4つのK型もまた1つのセットを形成しており、同じ確率法則に従うため、ツリー概念を繰り返すことが可能である。K型セットはツリーをL型に形成する。従って、K型セットがゼロであれば、L型だけを保持する必要がある。
次のステップは、ここのビット面内でL型ツリーを符号化することである。それぞれのL型は64横列ブロック内の横列を表しており、これは64L型のLツリー構造に完全に合う。図16は、これがどのようにして起こるかを示しており、またL型がどのように元に変換データ(HL、LHおよびHH)に関連するかも示している。図面は、レベル1および2における20個のL型、およびレベル3、4、および5における4つの最終的なL型を示している。これらはまた図面に示すようにレベル1および2におけるLHおよびHHそれぞれについての20個のL型でもある。
Lツリーはやはり類似の可能性を利用する。符号化はツリーの底部(レベル1)からレベル4/5へと行われる。ヒエラルキー用語で、レベル4/5は「親」とみなすことができ、レベル3,2および1はそれに対して「子」の関係を持つ。符号化手順は上と同じである。
符号化「ノード」の正確な動作を図16に示す。プロセスはL2_0と印が付けられているノードを考慮することによって図示できる。ここで、ブール演算は入力が5つのORゲートのものであり、入力のうち4つがL1_0からL1_3データであり、5番目の入力がL2_0データである。上で述べたように、ゲートの出力が1であれば、L型および前のデータを保持しなければならないが、もし0であれば、L型だけを保持する。そしてレベル3ノードからレベル4/5までプロセスを繰り返す。
ゼロ係数がある広い領域があると、非常に大型の符号化ゲインが実現されることがわかる。そして極端な場合、1つのビット面にあるすべての係数がゼロであれば、レベル4/5だけが保持される。
ここで、コード化プロセスによりデータを大幅に縮小できるが、LおよびK値を保持しなければならない付帯部分があることがわかる。LおよびKビット自体は元のデータに対する付け加えである、すなわち、ツリープロセスが元のデータを縮小する一方で、制御データの追加もできる。コード化ゲインのいくらかは失われるため、この損失を最小限にすることが望ましい。このことは、8つのデータ面のすべての概要を把握することによって行われる。図17は面の概念を示しており、面7が最上位であり面0が最下位である。ウェーブレット変換のおかげで、面7はゼロのほとんどを含んでいるため、この面では係数のほとんどがゼロであろうにもかかわらずKおよびL構造がコード化ゲインの意味で最も効率的となっている。
KおよびL型を見て調べるやり方の1つは、これらが面における係数の有意性の記録を提供することである。この記録は1つの面から他の面へと手渡され、対応するKまたはL型がいつ有意になったか(すなわち1に等しくなったか)を判断するのに使用できる。いったんこれが検出されると、もはや後続の面のために型を保存する必要はない(なぜならデータはいずれにしろ保持されているからである)。この手順は冗長なL型およびK型を排除するものである。
連続的な面を走査するプロセスも使って符号面(面8)をコード化する。変換プロセスでは8ビット画素データが9ビットとなるが、これは±255の範囲を示している。符号面では、1024個の係数が0によって正に指定されており、1によって負に指定されている。符号データは有意性に基づいてコード化されているため、(冗長なKおよびL型を排除するために)有意性の走査が行われると、有意な係数だけが符号化された符号データを持つ(なぜなら、明らかに、すでに廃棄されているゼロ係数に符号データをコード化することは冗長と思われるからである)。
今や全体の符号化プロセスはLKCSデータの生成として要約でき、この場合、それぞれの面は一連の4つのセクションでコード化される。ここで、
L=L型ツリー
K=K型ツリー
C=係数データ
S=符号
である。
損失のない符号化を行うには、「最悪の場合」、すなわち、元の画像が非常に複雑であるため実際にはコード化ゲインがない場合について符号化データを計画する必要がある。従って、プロセスは次のとおりである。
(a)Lツリーは64個までのビットデータによってコード化され、L型に対応する。これら自体はK型の知識から導き出されるが、このセクションがビットストリームの最初でなければならない。これは、復号器はどの横列が送信されておりどの横列が送信されていないか(有意でないか)を前もって知る必要があるからである。L型ビットは、圧縮プロファイル(以下を参照のこと)とともに、復号器にL型ツリーを再構築させる。
(b)次に、K型が256個のK型に対応する256個までのビットデータによってコード化される。復号器は再構築されたLツリーを使ってK型のマップを復号化する。
(c)次に、もとの係数データCが1024個までのビットによってコード化される。復号器は再構築されたLおよびK型を使ってCデータのマップを復号化する。
(d)最後に、符号データSが1024個までのビットデータによってコード化される。復号器を使ってCデータを再構築してSデータのマップを復号化する。
8つの画像面のそれぞれについてLKCSプロセス全体が繰り返される。
[空間的圧縮のための符号化]
明らかに、上述のプロセスがいったん完了すると、実際の符号化されたデータの長さが可変であるという状況が生じる。符号化損失があるという状況さえもあるということは統計学的にはあり得ない(不可能でさえある)ものの、損失なしのコード化により可変の結果がもたらされ、かかる結果は、意図するリアルタイム用途で管理するのは困難と思われる場合がそうである。
ビット速度の意味で、より予測可能な結果を実現しまた高いコード化ゲインを持つ損失のない圧縮を導くために、LKCSデータは圧縮プロファイルを受ける。原則として、これは解像度およびビット面数に基づくデータの除去にすぎない。このプロファイルはヘッダとしてビットストリームに送付され、その結果、復号器はどれが削除されたかを前もって知る。
連続的なプロファイルの傾向は、ほとんどの積極的な削除を面0およびレベル1に適用し、レベルおよび面の上昇につれて削除を累進的に少なくするというものである。実際には、圧縮プロファイルはCKおよびLツリーのコード化のときに適用されるもので、このことは望ましくない係数データおよび対応するKおよびL型のいずれも削除することを意味する。このことは重要である、なぜならこれにより元のデータおよび圧縮されつつある制御情報の両方が得られるからである、さもなければ高い圧縮レベルでは制御情報が優勢になるという状況が生じたであろう。
[圧縮プロファイル]
圧縮プロファイルは、人間の目の視覚的知覚特徴を活用する重み付け方法を使用する。原則として、人間の目は高周波数の損失にはあまり敏感ではないため、どのような圧縮体系でも、高周波数成分を排除することによってまた量子化ノイズの効果も確実にやはり排除することによって始まる。
重み付け体系はウェーブレット変換のサブ帯域レベルに合わされており、その概念を図18に示す(図6と比較すべきものである)。これを言い換えると、圧縮は元のデータではなくLツリーに適用される。
図18で、簡単な(そして典型的な)例として「a」をa=2とする。すると、いずれのレベルのHHも対応するLHおよびHLの圧縮の2倍を持つことがわかる。さらに、累進的により小さい圧縮を、より重要な情報が存在しているより高いレベルに適用する。
好ましい重み付け方法は、「a」の値を変動させて広い範囲の圧縮比を得ることである。図18は、適用される相対的な重みを運搬する点で概念的であるが、実際には、圧縮の範囲は符号器で適用される1セットの個々のプロファイルの形態である。ユーザーは所定のプロファイルのうちの1つを選択できるかまたはカスタムプロファイルを定義さえもできる。
プロファイルを定義するにあたりその目的は、再構築された画像が最小限の間違いしか持たず、同時に最も高い知覚品質を持つ(すなわち、画像が見る者によって「自然だ」と知覚される)ことを確実にすることである。このことにより必然的にいくつかの妥協が生じ、実際には、知覚的品質はより低いビット速度でより重要である。
重み付け体系は簡素で、効率的で、実際の画像には左右されない。この体系は、L型ツリーの1つのビット面に直接関連する16ビットプロファイルパラメータによって成し遂げられる。このことを表1に示す。もしある1つのビットが0であれば、データは取り除かれ、そのビットが1に等しければ、データは保持される。プロセスは「Lツリーの伐採」と記述でき、L型の単数または複数のビットを使う論理AND演算によって実行される。
例えば、ビット10=0であれば、L_LH2の4つすべてのビットはゼロとされるであろうが、もしビット10=1であれば、L_LH2のうち値が1のビットだけが保持されるであろう。
「スペアビット」の存在を説明する必要がある。元の構造では、L_4/5の個々の成分のために空間が見込まれていた。実際には、これはすべての通常の画像にとって冗長であるが、万が一、後の開発(おそらく非常に大型の画像をともなう)でこれら余分のビットが必要とされる場合に備えて機能が保持されている。チップ設計はこれらを使用するための機能を保持しているが、体系が冗長なデータを送信することはない。
L型ツリーの制御により非常に効率的な圧縮を行うことができる、なぜならより多くのゼロが形成される場合、データおよび制御の両方ともプロファイルパラメータによって取り除かれるからである。
[プロファイルの例]
表2および表3は、圧縮プロファイルの例を示している。表2は、視覚的に損失のない画像を提供する圧縮プロファイルの実際の例である。1または0に設定されるビットを検討することにより、プロファイルの重み付けの概念を得ることが可能であり、有意な面およびレベルには圧縮がかけられていないことが直ちに明らかである。かかるプロファイルは20:1から30:1の範囲の空間的圧縮を提供できる。
表3は、範囲が50:1から100:1の激しい圧縮の一例であり、より多くのデータが廃棄されていることが明白である。すべての面についてL4/5データが保持されており、これは、かかるデータのどのような損失も画像品質に重大な影響を及ぼすと思われるからであるが、かたやビット速度には限界的な削減しか行われていない点に留意する必要がある。
プロファイルを定義する場合、特定の解像度レベルに関するすべてのデータが確実にビット面内で除去されるようなやり方でデータの除去を行うことが重要である。なぜなら、さもなければ得られる画像は不均一的な空間品質を持つことになると思われるからである。目はかかる潜在的な人工物に敏感である、例えば、人間の顔面を見ている場合、目は均一な品質を期待しているが、もし顔面の異なる部分が異なる品質を持っていればとまどう。
[符号化エンジン]
これまで行ってきた符号化プロセスの説明では数多くの離散プロセスを説明してきた。図12および図13には、ウェーブレット変換を実行するための「変換エンジン」の概念をいくらか詳細に示した。しかしながら、図12では、コード化プロセスがただ単にブロック図内の機能として示されていたにすぎず、符号器がどのように作動するかについての詳細はまったくなかった。
[変換データの並べ替え]
変換プロセスの結果は32×32ブロックの画像係数であり(3セットのかかるブロック、すなわちY、U、およびVがある)、ブロック内で、レベル5データから始めに係数データが整列され、レベル1データで終わる。
それぞれのビット面について、データが、最初にそれぞれが16ビットの64横列並び替えられる、なぜならこうするとLツリーを簡単に導き出すことができるからである。係数データに対する組織およびその関係は以下の図面ではっきりとわかる。
[L−符号器]
上で述べたように、Lツリーがまず最初に導き出される、なぜならLツリーはまず最初に復号化プロセスに必要でありまた最も多い量の係数データの廃棄ももたらすからである。「Lツリーコード化エンジン」のタスクは非常に複雑である、なぜならこれは3次元で作動しなければならないからである。
(a)論理AND演算をデータに行って所望の圧縮プロファイルをかけるようにしなければならない。
(b)Lタイプの引き出し自体は非常に簡素である、なぜならこれはデータの単一の横列に対する論理OR演算であり、横列63から横列0まで作用するものである。
(c)もし係数データが有意であることがすでにわかっているのであれば、L型を指定することは冗長であるため、プロセスは最上位の面の下流で作用しなければならない。
(d)所望の最終結果はすべての有意でない係数データの廃棄、および残りの係数データの保持、およびすべてのL型の位置のコンパクトな記述である。
(e)エンジンは、データを「再訪問」してはならないという点で、単一のパスをベースとして機能しなければならない。
図20は、プロセスをブロック図の形態で示している。L FORMATは1つの面の64×16係数ビットから64個のLを構築している。
L TREEは8つの面を生成する。すなわち、最上位の面7から最下位の面0まで機能するL_CUR[63..0]、L_MSK[63..0]およびL_SIG[3..0]である。圧縮ファイルがこのステージでどのように適用されるかに留意すること。これらのアイテムはL符号器の「出力」を表している。ここで、
L_CUR[63..0]は現在の面のLツリー状態である。
L_MSK[63..0]は、どのL_CURビットを送信すべきでないかを決定するマスクである。
L_SIG[3..0]はL SIGNIFICANCEであり、K、CおよびSパスによって使用されるもので、どの横列を送信すべきでないかを示している。
L ACCはL_ACC[63..0]を生成する。これはすべての以前の面の現在のOR化された状態の記録である。
L符号器で使用される数式は次のとおりである。
[L_CURおよびL_SDIGの定義] [圧縮プロファイル]
Figure 2010016841
[L_CUR[63..0]UP Lツリーを算出するための論理数式]
数式 コメント
Figure 2010016841
L_cur[n]は1つの面についてのみ有意である(有意への遷移)。有意になる点を超えるとLコード化は停止する点に留意すること。
[L_SIGを算出するための論理数式]
L_SIGはK、CおよびSパスによって使用されるもので、どの横列を送信しないかを示している。Ln_XX_sig=0の場合、横列は送信されない。Lsig[3..0]は4つの横列をマップする、すなわち、16サイクルK、CおよびSパスを処理するための16セットのシーケンスがあり、ここでsel[0]からsel[15]がそのシーケンスを選択する。
Figure 2010016841
L_sig[3..0]は4つの有意値をそれぞれの(4*16)K、C、S言語に手渡す。それぞれのタイプ(K、C、S)について16の3つのパスがある。
Figure 2010016841
[L_MSKを算出するための論理数式]
これを使ってL_cur[63..0]のどのLビットを送信しないかを決定する。Lビットは、その親が0である場合またはそのC_prof[]が0の場合は送信されない。これは下降(上から下向き)ツリーを組み込んでいる。それぞれのパスは平面であり、最上位から最下位へと実行される(面7から面0)。
コメント
Figure 2010016841
[CS符号器]
図21はCS符号器を示している。この内部では、次のことが行われる。
CS FORMATが元の16ビット横列フォーマット[15..0]をa×4横列フォーマット、すなわち[63..0]に変換する。これを行うことでデータを64ビットに合致させ、その結果、符号化エンジンの最終的な部分が64ビットベースでのみ機能できるようになる。
すべての係数面について符号データが平行して複写される。これは、すべてのC面について符号が利用可能である必要がある次のステージにとって必要である。
C ACCはそれぞれの係数が有意となった点を記録するもので、符号をいつ符号化すべきかを決定するのに次のステージで使用される。
[LKCSパス]
図22は符号化エンジン全体を示している。ここで、L ENCODEおよびCS ENCODEはすでに上で説明したプロセスである。
MX LDPSは符号化エンジンである。その所望の出力は、MX_CUR[63..0]およびMX_MSK[63..0]からなる。図22に示されるその他の出力は中間データで、出力を算出するのに使用されるものであり以下に示す数式に現れる。
リアルタイム符号化エンジンは64サイクルベースで機能するため、最大値にあるL、K、CおよびSのそれぞれの理論上の最悪のケースが実際に「合う」ことが確実なことが重要である。このことは、次のことがらを理解することで試験される。
L_PASS=面あたり1×L_CUR[63..0]
K_PASS=面あたり16×K_CUR[15..0]
C_PASS=面あたり16×C_CUR[63..0]
S_PASS=面あたり16×S_CUR[63..0]
従って、MX_CURおよびMX_MSKを生成するには、L、K、CおよびSパスのすべてのシーケンスが必要である、すなわち、
1+16+16+16=面あたり49サイクル
これは十分に64サイクルの許容範囲内である。
出力MX_MSK[63..0]はL、K、CおよびS_CUR[]のそれぞれのどのビットを符号化すべきかを選択するためのマスクである。
LKCSパスで使用される数式はここで次のとおりである。
[C累算からのK累算の導出]
Figure 2010016841
[C_curからのK型の累算]
Figure 2010016841
[Kパス]
K_curの導出(K_パスおよびC_パスの両方に必要である)
Figure 2010016841
[K_パスマスクの作成]
Figure 2010016841
[Cパス]
C_curの導出
Figure 2010016841
[C_パスマスクの準備および作成]
Figure 2010016841
[Sパス]
Figure 2010016841
[MX LKCS]
Figure 2010016841
[復号化エンジン]
復号化エンジンは、符号化フォーマットを鏡写しにすることによって「1つのパス」符号化解答を提供する1セットの決定的原則に基づいている。このフォーマットは、先駆けて知っておくべき後続のデータのための1セットのポインタを見込んだ累進的な計算を規定している。従属的なフィードバック素子を含むパイプライン化された論理構造では、将来のデータの位置を前もって知ることは必須要件である、さもなければ遅延(パイプライン)によりリアルタイムでない復号器となる。
符号器と同様に、復号器は面あたり64ビット×64サイクルベースで機能する。復号器は埋め込まれた制御およびデータをそれが符号化された順序と同じ順序、すなわちLKCSで累進的に復号する。
[L復号器]
L制御ビット[63..0]の復号は2つのパスで行われる。
Lパス1=レベル4、3,2=L[15..0]
Lパス2=レベル1=L[63..16]
Lパス1は、どの面についてもシリアルデータd[15..0]の最初の16ビットで機能する。次の入力、
L_acc[15..0]
C_prof[15..0]
と一緒になって、次の8つの面を生成する、すなわち、
L_cur[15..0]
L4_sig
L3_LH_sig
L3_HL_sig
L3_HH_sig
L2_LH_sig[3..0]
L2_HL_sig[3..0]
L2_HH_sig[3..0]
これらパラメータの定義は符号化エンジンにおいて定義される。
[L_パス1数式]
Lデータのためのポインタ
Figure 2010016841
[Lデータ]
レベル4および3のためのL_cur[3..0]
Figure 2010016841
レベル2 Lデータの位置範囲([15..4])
Figure 2010016841
レベル2のためのL_cur[15..4]
Figure 2010016841
Figure 2010016841
Figure 2010016841
Figure 2010016841
L_パス2は、L_パスのデータの最後からあらかじめ指定されているデータd[63..16]の範囲で機能する。次の入力、
L_acc[63..16]
L2_LH_sig[3..0]
L2_HL_sig[3..0]
L2_HH_sig[3..0]
C_prof[15..0]
とともに、次の8つの面を生成する、すなわち、
L_cur[63..16]
L_acc[63..16]
L1_LH_sig[15..0]
L1_HL_sig[15..0]
L1_HH_sig[15..0]
これらのパラメータは符号化エンジンにおいて定義される。
Figure 2010016841
[K復号器]
K_パスは、L_パス2のデータの最後からあらかじめ指定されているデータの範囲で機能する。次の入力、
16 x d[15..0]
16 x C_acc[63..0]
16 x L_sig[3..0]
但し、L_sig[3.0]は、(パラメータ)から(パラメータ)への順次的な四重マッピングである。
とともに、
面あたり16×K_cur[15..0]
面あたり16×K_msk[15..0]
を生成する。
[C累算からのK累算]
Figure 2010016841
[C復号器]
C_パスは、L_パスのデータの最後からあらかじめ指定されているデータの範囲で機能する。次の入力、
16 x d[63..0]
16 x C_acc[63..0]
16 x K_msk[15..0]
16 x L_sig[3..0]
とともに、
面あたり16×C_cur[63..0]
面あたり16×S_msk[63..0]
を生成する。
Figure 2010016841
[S復号器]
S_パスは、C_パスのデータの最後からあらかじめ指定されているデータの範囲で機能する。次の入力、
16 x d[63..0]
16 x S_msk[63..0]
とともに、
16 x S_cur[63..0] per plane
S_cur[63..0] = (d[63..0] & S_msk[63..0]) & S_pass_en ;
を生成する。
[一時的な圧縮のための符号化]
一時的な圧縮は、高い圧縮比を実現するための鍵である。しかしながら、方法によっては計算上集約的なものがあり、処理時間が画像内容に大きく左右される。好ましい体系では、次の2つの優先度に対応している。
(a)どのような方法を使おうとも、変換の決定性およびコード化エンジンを保持しなければならない。このようにすると、プロセス全体が簡素化され、内容を符号化するのにかかる時間が正確に定義される。
(b)ストリーム化すべきデータは「絶対的」でなければならない。言い換えると、画像は受け取ったデータだけを使って再構築され、画像の履歴または将来の予測には依存しない。絶対的なデータの概念によりネットワークエラーに対する高い免疫が提供され、特に、画像待ち時間を延長することがない。(延長された画像待ち時間、すなわち、符号化および復号化の間における複数のフレーム遅延は画像のグループ全体にわたって複雑な計算を必要とするシステムではどのようなものにおいても不可避である。)
好ましい一時的圧縮体系の基礎は、変更のあった映像情報だけをコード化することである。この体系は、映像内容の領域は、その体系が検出しコード化しないいくつかのフレームにわたって静止したままにできるという事実を活用する。このようにすると、大きなコード化ゲインが実現される。この体系が実行可能なものとなるには、変更を正確かつ確実に検出することは最も重要な点である、なぜなら変更をどのように誤って検出しても明らかなエラーにつながり、これは復号化された画像の「凍結した」領域としてはっきりと示されるものである。
動きを確実に検出することは体系の核心である。しかしながら、絶対的データの送信の基づいた体系を考案することは、変化の間の違いを送信することだけに頼る体系(例えば、MPEGを使って行われているように)を使うことに比べるとはるかに困難である。画像にノイズがあるため困難が生じるため、その結果、真の映像内容とノイズとを区別する問題がある。ノイズは2つの主な理由により生じる。すなわち、カメラセンサノイズ(特に、証明レベルの低い場面)およびアナログからデジタル信号変換から生じる量子化ノイズである。
ノイズと画像内容とを区別する好ましい方法の基礎は、ウェーブレットドメインにおいて、すなわち、コード化の前に、変換出力において動き検出を処理することである。ウェーブレットドメインにおける「脱ノイズ」は、ウェーブレット変換は信号ドメインにおけるノイズを変換におけるノイズにマップするということに気づいた人物であるDonohoによって最初に提案された概念に基づいている。
どのような所定の画像でも、信号エネルギーは変換ドメインの係数にはほとんど集中しないが、ノイズエネルギーはそうではない。ノイズから信号の分離を可能とするのはこの重要な原則であり、ウェーブレット係数を「しきい値処理」することによって実現される。ノイズは有意の係数よりもレベルが非常に低いため、インテリジェントな低レベルしきい値処理を適用することで、ノイズと思われる低レベルの係数だけを取り除くことができる。しきい値処理は、最適なノイズ抑制を実現するために変換レベル全体にわたって動的である。好ましい体系は新規である、なぜなら信号は非線形手段によってノイズから分離されるからである。そしていくつかのやり方においては、プロセスは、上で説明した圧縮プロファイルに使用され適用される方法に類似である。
好ましい一時的な圧縮体系では、最上位の係数の貧弱なセットだけをノイズ除去のための基礎として使用する。かかる積極的なやり方は、動きを検出するための非常にきれいな「ウェーブレット署名」を得るように設計されている。この「署名」は認識可能な映像に似る必要はなく、ただ単に有効な変更検出の手段であればよい。
[一時的な圧縮の定義]
一時的な圧縮アルゴリズムの目的は、必要な計算を最小限とすることである。好ましいシステムでは、当初の色空間変換の性質を利用する。
動きを定義するための境界は、32×32係数のYUV変換されたブロックである。それぞれのブロックは画像フレーム内で自身の位置を定義するようなやり方で番号付けされている。フレーム間で対応し合うブロックを比較し、これらが異なる場合だけ、コード化し送信される。Y自体はUおよびVから導き出されると考えることができるため、動きを査定するにはY係数だけを使えば十分である。このことは動きの計算およびフレーム保存の要件を、もし計算がYUV(またはRGB)画像全部について行われた場合に比べたった3分の1にまで少なくする効果がある。
一時的な符号化のプロセスを図19に図示しており、これはプロセスにおける次のステップを示している。
1.Y変換情報を32×32ブロックで抽出する。それぞれのブロックについて位置情報を割り当てる。
2.ノイズしきい値をデータに適用する。これによりプログラムされた値未満のすべての係数を排除する。この「しきい値」は非常に低く、ノイズレベルにある有意でない係数を排除することだけを目的としている。
3.最上位の係数の大きさおよび位置を検出する。このプロセスでは、5レベル変換を形成している16個のサブ帯域をそれぞれろ過して最上位の係数およびその関連する位置を選択する。
4.16個の得られた係数から、最上位なものを選択する。選択される個数はプログラム可能で、実際には最大8つで十分であることがわかっている。この体系の背後にある概念は、信頼性のある動き検出を保証するのに十分な情報を得るが、それと同時に、最上位の係数のグループの大きさに上限を設けることにより最大のノイズ免疫を実現するというものである。有意な係数および対応する位置データを要約するこの情報は「ウェーブレット署名」と呼ばれる。
5.得られた「署名」を以前の画像フレーム内の対応するブロックのものと比較する。このステージでは、別のプログラム可能なしきい値が適用される。この「異なるしきい値」によりある一定の比較が可能となり得るが、この比較が正しいと思われるかどうかはまだ定かでない。このしきい値は、係数間の小さなピーク変調差を見込んでおり、大きさ情報だけに適用され、位置情報には適用されない。
6.比較の結果、もし署名が同じであれば送信はない。もし署名が異なれば、コード化のためのデータ送信がある点に留意すること。コード化のために前進するデータは下のYUV変換データである。これは重要な原則である、なぜならこれにより(圧縮プロファイルの制約内で)最も高いと思われる画像品質が保持されること、およびコード化/復号化プロセスが静止している画像データと移動している画像データとを区別しなくてよいことが保証されるからである。
[参照フレームデータ]
一時的な圧縮体系はまた、(単数または複数の)復号器を符合器の現状に同期させるための参照フレームデータを出力するためにも組織される。このプロセスは「背景」画像リフレッシュ機能を提供するものと考えられる。
この機能は、ステップ6(上記を参照のこと)で取られた決定に関わりなく、確実にブロックの全YUV変換データが間隔をあけて送信されるようにするものである。この間隔はプログラム可能で、確実に参照フレームデータの送信が出力ネットワークにおいてデータフローに対し最小限の影響を持つようになっている。パラメータは「x個の通常のブロックごとに送信される1つの参照ブロック」によって定義される。xは典型的には100以上である。
このリフレッシュ機構は画像解像度とは無関係であり、画像における一時的な変更とは非対称であるため、画像内容とは無関係である。この機構はただ単に、1つのブロックについて最新の更新を送信するに過ぎず、このブロックは現在のフレーム内のブロックの指標によって支配されている。高い解像度の画像全体をリフレッシュするのにこのやり方では数秒間かかる場合があることがわかる。しかし、かかるシステムは静止画像に悪影響を及ぼすエラー(例えばネットワークの問題から生じるエラー)に効果的に対処し、例えば、新しいユーザーがログオンする場合に複数のユーザーをサポートする、さもなければこれら複数のユーザーは元の画像が変更されるまで静止画像データを受信することはないであろう。
[ネットワーク接続]
ここでのタスクは、圧縮データをイーサネットネットワーク全体にわたって渡すことのできる形態へと変換することである。画像データはコード化された「画像ブロック」の形態であり、これらはそれぞれが画素の32×32アレーを記述している。かかるブロックは必ずしもイーサネットのペイロード仕様に一致するわけではない。加えて、デジタルオーディオデータを最終的なデータストリームに多重化するための規定がなくてはならない。
それぞれのYUVブロックは最上位のデータを先頭とし最下位のデータを追跡することをベースに符号化される。ブロックフォーマットを表4に示す。
Figure 2010016841
[ユーザーデータグラムプロトコル(UDP)の選択]
本発明の背後にある開発プログラムの初期には、デジタルリンク全体にわたって画像データを多重化し送信する数多くの異なる方法が考慮された。しかし、その後、インターネットプロトコルを使う汎用のイーサネットネットワークに乗じることにするという決定が下された。そして、システムが確実に「現実世界」で機能しまた実行する上でどのような困難も絶対に引き起こさないことが重要であった。
その結果、ネットワーク全体にわたってデータを送信する方法を定義する際の手引きとなる原則は次のとおりである。
(a)目的は、同期画像送達の要件と食い違ってネットワークは事実上、非同期であるという事実にもかかわらず、リアルタイム画像の信頼性があり効率的なトランスポートである。
(b)システムは既存のネットワークトランスポート基準およびプロトコルに基づいていなければならない。
(c)ネットワーク全体にわたってシステムの複雑性が低くなければならない。
(d)システムはマルチノードシステムとして機能しなければならない(すなわち、典型的には1つの画像供給源が複数の「ユーザー」または「視聴者」に分配されている)。
(e)上述したことの当然の帰結として、(単数または複数の)ディスプレイノードをいかなるやり方でも管理するのに(単数または複数の)捕獲ノードは不必要でなければならない。これによりノードの計算上の複雑性が最小となり、(この実行において)スケーラビリティが提供される。
技術上の要件は、図24に示すように、データを、IEEE802.3メディアアクセスコントロール(MAC)フレームに一致するフォーマットに取り入れることである。上述の最後の要件は、「マルチキャスト」法を指しており、これを実現するのに利用可能な方法は、MAC「ペイロード」を、ユーザーデータグラムプロトコル(UDP)に準拠する「データグラム」の形態にあるインターネットプロトコル(IP)に従わせることである。マルチキャストメッセージは特別なマルチキャスト「目的地アドレス」を持っている。最大データパケットサイズは1500バイトであり、これはなんらかのプロトコルオーバーヘッドを備えていなければならない点に留意すること。より大きなパケットはギガバイトイーサネットで可能である。
UDPは、簡素さおよび最小のデータオーバヘッドという最大の長所をもっている。しかしながら、IPと同じく、これはコネクションレス型プロトコルでありそれ自体は信頼性のある通信をなんら保証もせず、どのような形態のエラー訂正または回復、またはどのような種類のメッセージフロー制御も行わない。通信は「最大努力」であり、欠点を克服する何らかの手段がアプリケーションに存在しなければならない。
双方向通信(信頼性のあるポイント間通信を提供する、接続重視のプロトコルトランスポートコントロールプロトコル(TCP)で使用されているような)の必要を完全に省くために、好ましいシステムはパケット損失に対して頑丈なように設計されている。表4は、特有のやり方でコード化された同期ワードによってそれぞれのデータブロックが分離されていることを示している。万が一、1つのブロックまたは一連のブロックからのデータが破損された場合に備えて、同期ワードがエラーの伝播を捕獲するように設計されている。同期ワードを使ってエラーを「くるみ」、これにより復号化されたビットストリームが不要情報を表示するのを防止する。(単数または複数の)エラーが生じた場合は、最新の手付かずの1つのブロックまたは複数のブロックが表示され続ける。
[IPパケットへの変換]
画像データのIP/UDPへの準拠は2ステージプロセスである。最初のステージは元のコード化YUVブロックデータを一連の標準化データパケットに変換することである。あらゆる付随のオーディオが画像データで多重化されるのはこの時点である。オーディオはAES/SPDIF標準に従い非圧縮デジタルオーディオとして搬送される(ドルビーAC3もまた搬送できる)。表5はパケットフォーマットを示している。
Figure 2010016841
得られたビットストリームをバッファメモリに入れられ、そして必要なヘッダをつけた状態でイーサネットペイロードに変換される。プロセス全体を図25に示す。
図25にはっきりと示されていないアイテムは、さらに別のリアルタイムプロトコル(RTP)ヘッダで、これはトランスポート層ヘッダとトランスポート層ペイロードとの間で搬送されるものである。
「ビデオのためのデータ開始」はフレーム開始を示し、1つのフレームに必要な可変の数のパケットにおける最初のパケットを示している。(1つのフレームに必要なパケットの数は、画像の性質、圧縮プロファイルおよび一時的な圧縮の影響により変わる。)もとの画像ブロックとパケット境界との間では位置合わせがなされていないため、最後のパケットは部分的にしか満たされていない場合がある。このような場合、パケットにはゼロをつめこんでパケットサイズを作り上げる。
[ネットワークローディング]
上述のことから、圧縮画像を保持しているネットワークに提示されている「ローディング」は画像の性質によって可変であることが明らかである。事実上、どのような所定の画像解像度および圧縮プロファイルの場合でも、平均ビット速度はまったく一定のままであることがわかっている。これは、どのような現実のアプリケーションにおいても画像のために十分なネットワーク容量が確実にあるようにすることは簡単であることを意味しており、このことは特に複数の画像が保持されている場合に言えることである、なぜなら統計学的に全体のビット速度は非常に狭い制限内で一定のままとなるであろうからである。
全体のシステムの「プログラム可能な」側面は個々のフレームベースで適用できる点に留意すべきである。これは、圧縮パフォーマンスが変更できるため平均ビット速度も「進行中に」変更できることを意味する。その結果、システムが一定のビット速度を提供することはないが、予測可能なパフォーマンス、および必要が生じると直ちにビット速度を変更する能力は提供する。
[復号化オプション]
好ましいシステムの目的とする原則は、符号化および復号化プロセスが対称的であるということである。従って、復号化プロセスを普通に実行すると図12に示すものの逆になることになり、類似のハードウェハ構造に基づかせることができる。要するに、
(a)入ってくるデータの流れは「脱パケット化」、すなわち、UDPフォーマットとエラー訂正とに関連しているすべてのオーバーヘッドデータが取り除かれ、コード化されたYUVブロックデータが回復される。
(b)圧縮プロファイル情報をまず最初に受信することにより、その後この情報を圧縮化ブロックデータに適用することが可能であり、そしてこれにより完全なLKCS情報を回復することが可能となる。多くの場合、完全な「ツリー」はコード化された状態の単一のビットだけによって表される場合があるが、復号化を行う場合、すべての「かくれた」値が復元される点に留意すること。
(c)LKCS情報を使って完全なセットのウェーブレット係数を作成する。
(d)このデータは逆変換され、数式13および15を使ってLおよびH値を回復する。符号化プロセスと同じく、これを行う場合には、レベル1の「垂直」に到達するまで何度も逆変換エンジンを経る必要がある。符号化プロセスの場合のように、「横列および縦列」制御を使えば簡素な1次元逆変換エンジンを使える。
(e)回復されたデータはその後、水平なレベル1次元でのみ作用する第2の逆変換エンジンにかけられ、個々の画素データを回復する。
(f)画素データ(個々では2つの画素ごとに16ビットに戻っている)がYUVから8ビットRGBに変換し戻される。
[パケット損失の対処]
現実のネットワークでは、データパケットが無くなる重大な機会がある。例えば、ITUが推奨するY.1541(IPベースのサービスのためのネットワークパフォーマンス目標)はIPネットワークにおける1×10−3のIPLR(IPパケット損失比)を想定している。明らかに、これは受信した画像に対して壊滅的な影響を持ち得る場合がある。しかしながら、複雑な前向きエラー訂正(帯域および待ち時間の両方を増加させると思われる)により生じるであろうさらなるオーバーヘッドを回避するために、好ましいシステムはそれ自身の画像ブロックフォーマット(表4)を使うことで、パケット損失の結果生じる汚染されたデータを破棄する方法を提供する。
データストリームは連続的であるが、同期ワードは一連の16ビット値の1として簡単に区別できる。図26は、YUVデータの2つの連続的なブロックを示しており、すべて良好であれば、それぞれのブロックはそれ自身の同期ワードを持つが、ブロックの末端には次のブロックの同期ワードがあることがわかる。
IPネットワークでは、それぞれのIPパケットはCRCチェックサムを使って検証される。IPパケットは、無効であれば廃棄される。図面に示される画像ビットストリームの影響は、ある1つのセクションが切り離され、典型的には、無関係のブロックデータの2つのロットが1つにされる可能性があるというものである。
ブロックの長さは可変であるが、画像データの「ツリー」の性質は、復号器には画像再構築を完成させるのに十分なデータをいつ受信したか「わかって」おり、従って、いつ次の同期ワードに出会うかを予測するというものである。かかる機能を利用してブロックデータを、ディスプレイメモリに送られる前に検証する。
そのメカニズムは、YUB BLOCKmの形態のブロックデータはそれ自身のSYNC WORDmおよびそのすぐ隣のSYNC WORDn’によって検証されるというものである。復号器内の「YUVブロック送付モジュール」は、復号化されているYUVブロックを保存しており、もし復号化されているYUVブロックの末端に後続のSYNCワードが存在していれば、モジュールはYUVブロックをディスプレイメモリへと通過させる。もし存在していなければ、復号化されているYUVブロックは破棄される。
画像フレーム内の最後のブロックの特別なケースは、通常は次の同期ワードに出会うことはないのであるが、フレームの最後にさらに別の同期ワードを挿入することによって対処される。これにより、有効なYUVブロックだけをディスプレイへと確実に通過させることができる。この方法が機能するのは、YUVブロックが絶対的画像データを含んでおり、履歴または順方向データのいずれにも依存しないからである。万が一、ある1つのブロックが破棄される場合は、ディスプレイシステムは以前の「良好な」YUV画像ブロックを示し続ける。典型的なディスプレイフレーム速度(24−60Hz)で作動するシステムでは、パケットの損失により生じるランダムエラーは、実際には注目に値するものではない。
[ソフトウェア復号]
好ましいシステムの目的とするアプリケーションは、ほとんどの場合、ハードウェア復号を使って決定的なパフォーマンスを確実なものにするというものであろう。しかしながら、これまでの説明から、符号化プロセスの「出力」は1つの画像またはセットになった画像のビットストリームであることは明らかである。従って、理論上は、ビットストリーム構文を知っていれば誰でもソフトウェア方法だけを使ってそれを復号化する手段を考案できるであろうと思われる。
特定の市場ニーズを満たすように「ソフトウェア復号」生成物を開発できると思われる。かかるニーズは(例えば、低い解像度で画像を受信するまたは部分的な画像を検討するために)より低レベルのパフォーマンスが受け入れられやすい場合に見込まれるものである。
[圧縮された画像フォーマットの利点]
これまでの説明ではcodec(コード器−復号器)を説明してきた。これは、符号化および復号化プロセスで対称的にディスプレイを行う、すなわち決定的であり、(ただし一時的な圧縮プロセスにおけるビット速度は除く)また最小限の待ち時間しか招かないというものであった。明らかに、特に復号ステージにおいてさらに別の画像処理機能を導入する可能性もある。コード化されたデータは基礎をなす画像の非常に経済的な「短縮化された」記述を表し、これは画素ドメイン内で計算上集約的であると思われる動作は、コード化されたブロックドメイン内の最小の資源で実行できることを意味する。このことは特に、単一のcodecユニットを使って複数の画像を同時に処理する場合にいえることである(例えば、業界で標準的なFPGAを使って実現されたcodecは同時に8つの標準的なビデオ画像を処理できる)。
いくつかの可能性として次のものが挙げられる。
(a)異なる画像ストリームから必要なブロックだけを選択することによって複数の画像表示を組み立て、並べ替えて必要なディスプレイフォーマットを生成する。
(b)(変換のすべてのレベルを復号するわけではないと選択することで)異なる画像忠実度を選択する。
(c)ディスプレイノードの能力に合致するように画像ブロックを選択する(例えば、画像ストリームは1600×1200の等価物を持ち得るが、ディスプレイは800×600だけしか表示できない)。このことはサイズ変更を意味するのではない点に注意すること。それはまた別の主題である。
重要な理論上のポイントは、コード化ブロックレベルで行われるどのような処理または並べ替えもリアルタイムよりも高速で行われるものとして考えることができるということである。例えば、もし画像が20:1で圧縮されていれば、どのような処理でも、対応する処理が画素レベルで生じた場合の20分の1で起こることになる。
[要約]
ウェーブレット変換に基づく画像圧縮の好ましい実施の有利な特徴のいくつかの要約は以下のとおりである。
(a)RGBからYUVへの変換とウェーブレット変換との組み合わせにより得られる結果に精度維持の特性を使うことで、ビット成長のない全体的に可逆な損失なしの変換が提供される。
(b)平行パイプラインアーキテクチャに基づく高速スケーラブル変換エンジン。変換の選択がプログラム可能なことからグラフィックおよび移動画像用途のどちらについても最適な結果が得られる。変換処理は決定的である、すなわち正確なサイクル時間で実行され画像内容から全く独立している。待ち時間を最小限にできる。
(c)全フレーム変換の結果を実現して画像を移動させつつ実際にはブロックドメイン内ですべての処理を実行する方法(「ブロック外」変換データの使用)。
(d)効率的な圧縮を導くことができるウェーブレット変換の特徴を利用できるように設計された新規の「LKCS」コード化アレンジメント。
(e)損失のない、視覚的に損失のない、また、高い空間的圧縮効率で高い圧縮を提供できるプログラム可能な圧縮プロファイル。たとえば最も遅いビットストリーム速度に対する最も速いビットストリーム速度の割合は1000:1である。
(f)ウェーブレット署名のアプリケーションに基づく新規のプログラム可能な一時的圧縮体系。絶対的なコード化で、画像履歴または順方向予測を必要としない。画像待ち時間の延長がない。参照フレームを使って送信エラーの影響を排除する。
(g)ビットストリームを自己記述することで、コード化画像ブロックデータを保持する。
(h)システム出力はコネクションレスネットワークオペレーションのために構成されており、スケーラブルな複数の画像ネットワークの構成を規定している。ネットワーク送信エラーに対する高い免疫性。
(i)符号化ビットストリームの性質を利用した、IPパケット損失を検出する新規の方法。

Claims (18)

  1. それぞれのフレームが所定の複数のデータブロックを備えるよう、データを第1のフレームおよび少なくとも1つの後続のフレームを備えるフレームの1つのシーケンスにグループ化する工程、
    第1のフレームを全て送信する工程、
    第1のフレーム内の対応するデータブロックと著しく異なる前記またはそれぞれの後続のフレーム内のデータブロックだけを送信する工程であって、それぞれのかかるデータブロックは、フレーム内におけるブロックの位置を定義するそれぞれの指標番号と組み合わせて送信される工程、
    を包含することを特徴とする、データを送信する方法。
  2. 所定のアルゴリズムに従って前記データブロックのそれぞれを処理してそのデータブロックについてパラメータを評価する工程、
    前記またはそれぞれの後続のフレーム内のそれぞれのデータブロックについて、関連するパラメータの値がシーケンス内の先行するフレームの対応するデータブロックと著しく異なるかどうかを判断する工程、
    をさらに包含し、
    著しく異なるデータブロックだけを送信する工程は、肯定的な結果の出た前記またはそれぞれの後続フレーム内にあるデータブロックだけを送信する工程を包含することを特徴とする、請求項1に記載の方法。
  3. データをグループ化する工程は、それぞれがn個のフレームを備える複数の前記シーケンスにデータをグループ化する工程を包含しており、nは所定の値であり、それにより少なくとも1つのフレーム全体がデータのn個の連続的なフレームのそれぞれのシーケンス内に送信されることを特徴とする、請求項1または2に記載の方法。
  4. さらに別のフレーム全体を等間隔で送信する工程をさらに包含することを特徴とする、請求項3に記載の方法。
  5. 要求信号を受信すると、さらに別のフレーム全体を送信する工程をさらに包含することを特徴とする、請求項3または4に記載の方法。
  6. それぞれのフレームが所定の複数のデータブロックを含むよう、データを第1のフレームおよび少なくとも1つの後続するフレームを含むフレームのシーケンスにグループ化する工程、
    第1のフレームを全て圧縮する工程、および
    第1のフレーム内の対応するデータブロックと著しく異なる前記またはそれぞれの後続のフレーム内のデータブロックだけを圧縮する工程であって、それぞれのかかるデータブロックは、フレーム内におけるブロックの位置を定義するそれぞれの指標番号と組み合わせて圧縮される工程、
    を包含することを特徴とする、データを圧縮する方法。
  7. 所定のアルゴリズムに従って前記データブロックのそれぞれを処理してそのデータブロックについてパラメータを評価する工程、
    前記またはそれぞれの後続のフレーム内のそれぞれのデータブロックについて、関連するパラメータの値がシーケンス内の先行するフレームの対応するデータブロックと著しく異なるかどうかを判断する工程、
    をさらに包含し、
    著しく異なるデータブロックだけを圧縮する工程は、肯定的な結果の出た前記またはそれぞれの後続フレーム内にあるデータブロックだけを圧縮する工程を包含することを特徴とする、請求項6に記載の方法。
  8. データをグループ化する工程は、それぞれがn個のフレームを備える複数の前記シーケンスにデータをグループ化する工程を包含しており、nは所定の値であり、それにより少なくとも1つのフレーム全体がデータのn個の連続的なフレームのそれぞれのシーケンス内に圧縮されることを特徴とする、請求項6または7に記載の方法。
  9. さらに別のフレーム全体を等間隔で圧縮する工程をさらに包含することを特徴とする、請求項8に記載の方法。
  10. 要求信号を受信すると、さらに別のフレーム全体を圧縮する工程をさらに包含することを特徴とする、請求項8または9に記載の方法。
  11. 圧縮すべきデータはウェーブレット変換されており、
    前記パラメータは、それぞれのデータブロック内のそれぞれのサブ帯域内で最上位の係数だけに基づいて評価されることを特徴とする、請求項6から10のいずれかに記載の方法。
  12. 前記パラメータは、最上位の係数のデータブロック内の位置に基づいて評価されることを特徴とする、請求項11に記載の方法。
  13. 前記パラメータは、それぞれのデータブロック内のそれぞれのサブ帯域内にある最上位の係数からなるグループから選択されるn個の最上位の係数だけに基づいて評価され、nは所定の数字であることを特徴とする、請求項11または12に記載の方法。
  14. nは8に等しいことを特徴とする、請求項13に記載の方法。
  15. ウェーブレット変換は5レベル変換であり16個のサブ帯域をもたらすことを特徴とする、請求項11から14のいずれかに記載の方法。
  16. 圧縮されたデータだけを送信する工程をさらに包含することを特徴とする、請求項6から15のいずれかに記載の方法。
  17. データはカラー画像データを含み、前記パラメータを評価するためにカラー画像データの輝度成分だけが処理されることを特徴とする、請求項6から16のいずれかに記載の方法。
  18. 所定のしきい値よりも大きい値を持つそれぞれのデータブロック内のデータ成分だけが処理されて、そのデータブロックについてのパラメータが評価されることを特徴とする、請求項6から17のいずれかに記載の方法。
JP2009184109A 2005-08-26 2009-08-07 データを送信する方法及び圧縮する方法 Pending JP2010016841A (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
GB0517501A GB2429593A (en) 2005-08-26 2005-08-26 Data compressing using a wavelet compression scheme

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2008527499A Division JP2009506606A (ja) 2005-08-26 2006-08-11 画像データ処理方法

Publications (1)

Publication Number Publication Date
JP2010016841A true JP2010016841A (ja) 2010-01-21

Family

ID=35198472

Family Applications (5)

Application Number Title Priority Date Filing Date
JP2008527499A Pending JP2009506606A (ja) 2005-08-26 2006-08-11 画像データ処理方法
JP2009184110A Pending JP2010035175A (ja) 2005-08-26 2009-08-07 画像データ処理方法
JP2009184108A Expired - Fee Related JP4972131B2 (ja) 2005-08-26 2009-08-07 画像データ変換装置および逆変換装置
JP2009184107A Pending JP2010022006A (ja) 2005-08-26 2009-08-07 画像データ処理方法
JP2009184109A Pending JP2010016841A (ja) 2005-08-26 2009-08-07 データを送信する方法及び圧縮する方法

Family Applications Before (4)

Application Number Title Priority Date Filing Date
JP2008527499A Pending JP2009506606A (ja) 2005-08-26 2006-08-11 画像データ処理方法
JP2009184110A Pending JP2010035175A (ja) 2005-08-26 2009-08-07 画像データ処理方法
JP2009184108A Expired - Fee Related JP4972131B2 (ja) 2005-08-26 2009-08-07 画像データ変換装置および逆変換装置
JP2009184107A Pending JP2010022006A (ja) 2005-08-26 2009-08-07 画像データ処理方法

Country Status (5)

Country Link
US (5) US9204170B2 (ja)
EP (5) EP1917813B1 (ja)
JP (5) JP2009506606A (ja)
GB (1) GB2429593A (ja)
WO (1) WO2007023254A2 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8401084B2 (en) * 2002-04-01 2013-03-19 Broadcom Corporation System and method for multi-row decoding of video with dependent rows
AU2008240144A1 (en) 2007-04-11 2008-10-23 Red.Com, Inc. Video camera
US8237830B2 (en) 2007-04-11 2012-08-07 Red.Com, Inc. Video camera
WO2010027324A1 (en) * 2008-09-08 2010-03-11 Scalado Ab Method for indexing images and for reading an index of an image
US8384740B1 (en) * 2009-02-24 2013-02-26 A9.Com, Inc. Method and system for virtually placing a tangible item on an appendage
US20110078536A1 (en) * 2009-09-28 2011-03-31 Kyungtae Han Using Motion Change Detection to Reduce Power Consumption of Display Systems
US9473792B2 (en) 2009-11-06 2016-10-18 Texas Instruments Incorporated Method and system to improve the performance of a video encoder
KR20120038764A (ko) * 2010-10-14 2012-04-24 한국전자통신연구원 영상 인식 방법 및 영상 인식 장치
EP2613552A3 (en) * 2011-11-17 2016-11-09 Axell Corporation Method for moving image reproduction processing and mobile information terminal using the method
KR101981267B1 (ko) 2012-04-13 2019-05-23 지이 비디오 컴프레션, 엘엘씨 저지연 화상 코딩
RU2720534C2 (ru) 2012-06-29 2020-04-30 ДжиИ Видео Компрешн, ЭлЭлСи Концепция потока видеоданных
WO2014127153A1 (en) 2013-02-14 2014-08-21 Red. Com, Inc. Video camera
MX371127B (es) * 2014-07-16 2020-01-17 Yamzz Ip Bv Compresion, descompresion y despliegue de video de nivel múltiple para aplicaciones de 4k y 8k.
KR102257379B1 (ko) * 2014-07-22 2021-06-01 삼성전자주식회사 비디오 인코딩 회로 및 그것을 이용하는 비디오 인코딩 방법
WO2016127298A1 (en) * 2015-02-09 2016-08-18 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for reducing processing delay
US9992252B2 (en) 2015-09-29 2018-06-05 Rgb Systems, Inc. Method and apparatus for adaptively compressing streaming video
US10003821B2 (en) * 2015-10-27 2018-06-19 Canon Kabushiki Kaisha Image encoding apparatus and method of controlling same
US10897635B2 (en) * 2016-09-06 2021-01-19 Apple Inc. Memory compression systems and methods
CN116886907A (zh) * 2016-10-14 2023-10-13 世宗大学校产学协力团 影像编码方法、影像解码方法以及传送比特流的方法
KR102416804B1 (ko) * 2016-10-14 2022-07-05 세종대학교산학협력단 영상 부호화 방법/장치, 영상 복호화 방법/장치 및 비트스트림을 저장한 기록 매체
KR102620350B1 (ko) 2017-07-05 2024-01-02 레드.컴, 엘엘씨 전자 디바이스에서의 비디오 이미지 데이터 처리
WO2020092137A1 (en) * 2018-11-01 2020-05-07 Interdigital Vc Holdings, Inc. Video encoding and decoding using multiple transform selection
CN111242974B (zh) * 2020-01-07 2023-04-11 重庆邮电大学 一种基于孪生网络和反向传播的车辆实时跟踪方法
CN111698503B (zh) * 2020-06-22 2022-09-09 深圳市迪威码半导体有限公司 一种基于预处理的视频高倍压缩方法
US11425423B1 (en) 2022-03-10 2022-08-23 Yendo Hu Memory storage for motion estimation and visual artifact redcution
US11388445B1 (en) 2022-03-10 2022-07-12 Yendo Hu Mosquito noise smoothing between different video subsections encoded with different compression methods within a video frame

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10229558A (ja) * 1997-02-14 1998-08-25 Denso Corp 動画像情報の符号化装置
JPH11136685A (ja) * 1997-10-31 1999-05-21 Matsushita Electric Ind Co Ltd 画像データ処理装置および画像データ処理方法
JP2003023641A (ja) * 2002-05-08 2003-01-24 Toshiba Corp 動画像符号化装置
JP2004166183A (ja) * 2002-09-26 2004-06-10 Toshiba Corp 動画像符号化装置及び方法、動画像符号化方式変換装置及び方法

Family Cites Families (88)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4442454A (en) * 1982-11-15 1984-04-10 Eastman Kodak Company Image processing method using a block overlap transformation procedure
JPS62145988A (ja) * 1985-12-20 1987-06-30 Fujitsu Ltd 適応的走査線変換画像伝送方式
JP2505578B2 (ja) * 1989-05-31 1996-06-12 日立精工株式会社 プリント基板の取り出し装置
NL9000338A (nl) 1989-06-02 1991-01-02 Koninkl Philips Electronics Nv Digitaal transmissiesysteem, zender en ontvanger te gebruiken in het transmissiesysteem en registratiedrager verkregen met de zender in de vorm van een optekeninrichting.
GB2247132A (en) * 1990-08-17 1992-02-19 Sony Broadcast & Communication Digital video data compression
EP0497545B1 (en) * 1991-01-29 1997-01-08 Canon Kabushiki Kaisha Image signal coding device
JPH05115007A (ja) * 1991-10-21 1993-05-07 Canon Inc 画像伝送方法
JPH05300494A (ja) * 1992-01-30 1993-11-12 Nec Corp 動画像符号化器とその制御方式
US6435737B1 (en) 1992-06-30 2002-08-20 Discovision Associates Data pipeline system and data encoding method
JPH06113287A (ja) * 1992-09-30 1994-04-22 Matsushita Electric Ind Co Ltd 画像符号化装置と画像復号化装置
US5502571A (en) 1992-11-18 1996-03-26 U.S. Philips Corporation Device for processing digital signals first coded by means of variable length coding and device for inversely processing signals thus processed
US5726711A (en) * 1993-01-13 1998-03-10 Hitachi America, Ltd. Intra-coded video frame data processing methods and apparatus
US5412741A (en) * 1993-01-22 1995-05-02 David Sarnoff Research Center, Inc. Apparatus and method for compressing information
KR950008637B1 (ko) * 1993-04-08 1995-08-03 삼성전자주식회사 부밴드 코딩시스템의 신호처리장치
JPH07170521A (ja) * 1993-12-15 1995-07-04 Canon Inc 画像処理装置
US5748786A (en) 1994-09-21 1998-05-05 Ricoh Company, Ltd. Apparatus for compression using reversible embedded wavelets
US5881176A (en) 1994-09-21 1999-03-09 Ricoh Corporation Compression and decompression with wavelet style and binary style including quantization by device-dependent parser
US6141446A (en) * 1994-09-21 2000-10-31 Ricoh Company, Ltd. Compression and decompression system with reversible wavelets and lossy reconstruction
US5621772A (en) 1995-01-20 1997-04-15 Lsi Logic Corporation Hysteretic synchronization system for MPEG audio frame decoder
JPH08205151A (ja) 1995-01-26 1996-08-09 Matsushita Graphic Commun Syst Inc 画像圧縮符号化装置及び画像伸長復号化装置
US5887110A (en) * 1995-03-28 1999-03-23 Nippon Telegraph & Telephone Corp. Video data playback system using effective scheme for producing coded video data for fast playback mode
US6965724B1 (en) * 1995-03-30 2005-11-15 Thomson Licensing S.A. Trick-play modes for pre-encoded video
US6674911B1 (en) 1995-09-14 2004-01-06 William A. Pearlman N-dimensional data compression using set partitioning in hierarchical trees
US5737451A (en) * 1996-04-10 1998-04-07 Eastman Kodak Company Method and apparatus for suppressing blocking artifacts in block-transform coded images
JP3989999B2 (ja) 1996-05-03 2007-10-10 株式会社リコー データ圧縮システム
EP1469680B1 (en) * 1996-05-14 2008-06-18 Daewoo Electronics Corporation Method and apparatus for removing blocking effects in a motion picture decoder
AUPO329496A0 (en) * 1996-10-28 1996-11-21 Commonwealth Scientific And Industrial Research Organisation Image encoding
CA2218626C (en) * 1996-11-15 2002-11-19 Ntt Mobile Communications Network Inc. Data communication scheme for variable length blocks of data
US5999656A (en) * 1997-01-17 1999-12-07 Ricoh Co., Ltd. Overlapped reversible transforms for unified lossless/lossy compression
EP0892557A1 (en) 1997-07-18 1999-01-20 Texas Instruments Inc. Image compression
JPH1155668A (ja) 1997-07-31 1999-02-26 Nec Corp 画像符号化装置
JPH1198128A (ja) * 1997-09-22 1999-04-09 Sharp Corp データ伝送装置
EP0905978A3 (en) * 1997-09-29 2000-04-12 Canon Kabushiki Kaisha An encoding method and apparatus
US6272180B1 (en) * 1997-11-21 2001-08-07 Sharp Laboratories Of America, Inc. Compression and decompression of reference frames in a video decoder
JPH11306166A (ja) * 1998-04-20 1999-11-05 Ricoh Co Ltd ウェーブレット変換装置
KR100556450B1 (ko) 1998-05-28 2006-05-25 엘지전자 주식회사 움직임 벡터 추정에 의한 오류 복원 방법
US6310976B1 (en) 1998-10-01 2001-10-30 Sharewave, Inc. Method and apparatus for digital data compression
US6356665B1 (en) 1998-12-09 2002-03-12 Sharp Laboratories Of America, Inc. Quad-tree embedded image compression and decompression method and apparatus
JP4486755B2 (ja) * 1998-12-23 2010-06-23 ゾラン コーポレイション Mpegビデオ復号・表示システムのためのビデオメモリ管理
US6081163A (en) * 1999-01-22 2000-06-27 Advantest Corp. Standard frequency and timing generator and generation method thereof
US6339658B1 (en) 1999-03-09 2002-01-15 Rockwell Science Center, Llc Error resilient still image packetization method and packet structure
CN100394692C (zh) * 1999-04-15 2008-06-11 株式会社理光 数据高速压缩伸展方法及其装置
EP1249002B1 (en) 2000-01-13 2011-03-16 Digimarc Corporation Authenticating metadata and embedding metadata in watermarks of media signals
US6813387B1 (en) * 2000-02-29 2004-11-02 Ricoh Co., Ltd. Tile boundary artifact removal for arbitrary wavelet filters
JP3660558B2 (ja) * 2000-04-14 2005-06-15 日本電信電話株式会社 画像符号化方法、画像符号化装置及び画像符号化プログラムを記憶した媒体
US7023922B1 (en) 2000-06-21 2006-04-04 Microsoft Corporation Video coding system and method using 3-D discrete wavelet transform and entropy coding with motion information
WO2002009438A2 (en) * 2000-07-25 2002-01-31 Koninklijke Philips Electronics N.V. Video encoding method using a wavelet decomposition
US7266613B1 (en) 2000-08-09 2007-09-04 Microsoft Corporation Fast dynamic measurement of bandwidth in a TCP network environment
US6738523B1 (en) * 2000-09-14 2004-05-18 Eastman Kodak Company Parallel inverse discrete wavelet transform
JP2002135721A (ja) 2000-10-19 2002-05-10 Susumu Tsunoda ビデオ信号記録用監視装置
JP2002171412A (ja) * 2000-11-29 2002-06-14 Canon Inc X分木命令を備えるsimd型情報処理装置
US7558322B2 (en) 2001-03-13 2009-07-07 Vidunas Joseph P Method and apparatus for temporal wavelet compression
EP1246469A3 (fr) * 2001-03-27 2005-04-13 Koninklijke Philips Electronics N.V. Procédé de réduction de format et de décodage similtanés de signaux vidéo codés
KR100389807B1 (ko) * 2001-05-30 2003-07-02 한국과학기술원 Spiht에 기반한 관심영역의 코딩방법
JP4667656B2 (ja) 2001-06-26 2011-04-13 Ntn株式会社 ドアオープナー
JP3920849B2 (ja) 2001-06-29 2007-05-30 株式会社エヌ・ティ・ティ・ドコモ 画像符号化装置、画像復号装置、画像符号化方法、及び画像復号方法
US7426315B2 (en) * 2001-09-05 2008-09-16 Zoran Microelectronics Ltd. Method for reducing blocking artifacts
US6956600B1 (en) 2001-09-19 2005-10-18 Bellsouth Intellectual Property Corporation Minimal decoding method for spatially multiplexing digital video pictures
JP2003132346A (ja) 2001-10-24 2003-05-09 Fuji Film Microdevices Co Ltd 画像データ処理用集積回路および画像データ処理方法
KR20040068302A (ko) * 2001-12-20 2004-07-30 코닌클리케 필립스 일렉트로닉스 엔.브이. 비디오 시퀀스 압축용 인코딩 방법
US7630569B2 (en) 2002-02-26 2009-12-08 Decegama Angel Real-time software video/audio transmission and display with content protection against camcorder piracy
EP1345451A1 (en) 2002-03-15 2003-09-17 BRITISH TELECOMMUNICATIONS public limited company Video processing
JP2003274185A (ja) * 2002-03-19 2003-09-26 Sanyo Electric Co Ltd 画像処理方法とその方法を利用可能な画像符号化装置
JP4350342B2 (ja) * 2002-04-26 2009-10-21 株式会社リコー 画像処理装置、画像記録装置、カメラシステム、プログラム、記憶媒体及び画像処理方法
US7302006B2 (en) * 2002-04-30 2007-11-27 Hewlett-Packard Development Company, L.P. Compression of images and image sequences through adaptive partitioning
US20030235338A1 (en) 2002-06-19 2003-12-25 Meetrix Corporation Transmission of independently compressed video objects over internet protocol
JP4111761B2 (ja) * 2002-07-02 2008-07-02 株式会社リコー 画像処理装置
US20040022322A1 (en) 2002-07-19 2004-02-05 Meetrix Corporation Assigning prioritization during encode of independently compressed objects
JP3783956B2 (ja) * 2002-07-23 2006-06-07 株式会社リコー 画像記録装置及び画像データ選択方法
US7308146B2 (en) 2002-09-30 2007-12-11 Canon Kabushiki Kaisha Digital video compression
PL204747B1 (pl) 2002-10-31 2010-02-26 Politechnika & Lstrok Odzka Sposób nawęglania wyrobów stalowych w podciśnieniu
US7706583B2 (en) * 2002-11-11 2010-04-27 Canon Kabushiki Kaisha Image processing apparatus and method
US7330597B2 (en) * 2002-11-22 2008-02-12 Texas Instruments Incorporated Image compression
JP2004254298A (ja) * 2003-01-30 2004-09-09 Ricoh Co Ltd 画像処理装置、プログラム及び記憶媒体
JP4064279B2 (ja) 2003-03-28 2008-03-19 株式会社リコー 画像圧縮装置
JP4017112B2 (ja) * 2003-04-30 2007-12-05 株式会社リコー 符号化データ生成装置及び方法、プログラム並びに情報記録媒体
JP4229323B2 (ja) * 2003-09-05 2009-02-25 株式会社リコー 符号化装置、符号化方法及びプログラム
JP4135617B2 (ja) * 2003-09-08 2008-08-20 ソニー株式会社 画像符号化装置及び方法
WO2005043919A1 (en) 2003-10-30 2005-05-12 Nec Electronics Corporation Image decoding apparatus and image decoding method
KR20050077874A (ko) 2004-01-28 2005-08-04 삼성전자주식회사 스케일러블 비디오 스트림 송신 방법 및 이를 이용한 장치
US7697608B2 (en) 2004-02-03 2010-04-13 Sony Corporation Scalable MPEG video/macro block rate control
US7522774B2 (en) * 2004-03-10 2009-04-21 Sindhara Supermedia, Inc. Methods and apparatuses for compressing digital image data
JP4322920B2 (ja) * 2004-05-17 2009-09-02 三菱電機株式会社 画像符号化装置
WO2006001384A1 (ja) * 2004-06-25 2006-01-05 Matsushita Electric Industrial Co., Ltd. 画像符号化方法および画像復号化方法
US7590589B2 (en) * 2004-09-10 2009-09-15 Hoffberg Steven M Game theoretic prioritization scheme for mobile ad hoc networks permitting hierarchal deference
US7885339B2 (en) 2004-11-17 2011-02-08 Microsoft Corporation Bi-directional temporal error concealment
US20120230390A1 (en) 2011-03-08 2012-09-13 Gun Akkor Adaptive Control of Encoders for Continuous Data Streaming
US8305899B2 (en) 2008-05-28 2012-11-06 Microsoft Corporation Pull-based data transmission approach

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10229558A (ja) * 1997-02-14 1998-08-25 Denso Corp 動画像情報の符号化装置
JPH11136685A (ja) * 1997-10-31 1999-05-21 Matsushita Electric Ind Co Ltd 画像データ処理装置および画像データ処理方法
JP2003023641A (ja) * 2002-05-08 2003-01-24 Toshiba Corp 動画像符号化装置
JP2004166183A (ja) * 2002-09-26 2004-06-10 Toshiba Corp 動画像符号化装置及び方法、動画像符号化方式変換装置及び方法

Also Published As

Publication number Publication date
US20160142737A1 (en) 2016-05-19
US9204170B2 (en) 2015-12-01
US20160100194A1 (en) 2016-04-07
US10051288B2 (en) 2018-08-14
EP2928190A1 (en) 2015-10-07
US20160100195A1 (en) 2016-04-07
EP1917813A2 (en) 2008-05-07
JP2010004548A (ja) 2010-01-07
EP1917813B1 (en) 2015-07-01
EP2930930A1 (en) 2015-10-14
EP2928191A1 (en) 2015-10-07
WO2007023254A3 (en) 2007-09-20
GB0517501D0 (en) 2005-10-05
US9930364B2 (en) 2018-03-27
JP2010035175A (ja) 2010-02-12
GB2429593A (en) 2007-02-28
EP2928190B1 (en) 2021-04-07
JP2009506606A (ja) 2009-02-12
JP4972131B2 (ja) 2012-07-11
EP2928189A1 (en) 2015-10-07
US9924199B2 (en) 2018-03-20
US20160105686A1 (en) 2016-04-14
WO2007023254A2 (en) 2007-03-01
JP2010022006A (ja) 2010-01-28
US20100014590A1 (en) 2010-01-21
US10244263B2 (en) 2019-03-26
EP2930930B1 (en) 2020-07-29
EP2928191B1 (en) 2021-07-21

Similar Documents

Publication Publication Date Title
JP4972131B2 (ja) 画像データ変換装置および逆変換装置
KR20150068402A (ko) 동영상 압축 방법
US11074673B2 (en) Multi-level temporal resolution increase of video
JP2007514359A (ja) デッドゾーンによる空間スケーラブル圧縮スキーム
US7068845B2 (en) Information processing apparatus using class-classification adaptive processing
WO2010024907A1 (en) Systems and methods for compression transmission and decompression of video codecs
JP2014521273A (ja) 画像を符号化する方法および装置
JP2013026952A (ja) 画像処理方法、エンコード装置、デコード装置および画像処理装置
CN106954074B (zh) 一种视频数据处理方法和装置
CN1396769A (zh) 运动图像信息的压缩方法及其系统
JP4743604B2 (ja) 画像処理装置、画像処理方法、プログラム及び情報記録媒体
WO2023187388A1 (en) Frame buffer usage during a decoding process
WO2006106356A1 (en) Encoding and decoding a signal
JP2002209220A (ja) 動画像情報の圧縮方法およびそのシステム
JPH0923426A (ja) 画像復号方法および装置

Legal Events

Date Code Title Description
A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20090929

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20100122

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20100723

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110412

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110708

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110713

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110726

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110729

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110830

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110902

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20111206