JP2008244539A - クライアント・サーバシステム - Google Patents

クライアント・サーバシステム Download PDF

Info

Publication number
JP2008244539A
JP2008244539A JP2007078139A JP2007078139A JP2008244539A JP 2008244539 A JP2008244539 A JP 2008244539A JP 2007078139 A JP2007078139 A JP 2007078139A JP 2007078139 A JP2007078139 A JP 2007078139A JP 2008244539 A JP2008244539 A JP 2008244539A
Authority
JP
Japan
Prior art keywords
client
data
code data
server
image
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.)
Granted
Application number
JP2007078139A
Other languages
English (en)
Other versions
JP4898513B2 (ja
Inventor
Takanori Yano
隆則 矢野
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.)
Ricoh Co Ltd
Original Assignee
Ricoh Co 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 Ricoh Co Ltd filed Critical Ricoh Co Ltd
Priority to JP2007078139A priority Critical patent/JP4898513B2/ja
Priority to US12/055,994 priority patent/US7949725B2/en
Publication of JP2008244539A publication Critical patent/JP2008244539A/ja
Application granted granted Critical
Publication of JP4898513B2 publication Critical patent/JP4898513B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/162—User input
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/164—Feedback from the receiver or from the transmission channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods 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/17—Methods 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods 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/186—Methods 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/63—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding using sub-band based transform, e.g. wavelets
    • H04N19/64—Methods 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/4728—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for selecting a Region Of Interest [ROI], e.g. for requesting a higher resolution version of a selected region
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Compression Of Band Width Or Redundancy In Fax (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

【課題】本発明はＪＰＭの符号データをオブジェクト単位でプログレッシブ再生することで早い段階で画像データの全体的な概要を知ることができ、あるオブジェクトの処理を省略して高速な再生を実現できる。
【解決手段】本発明は画像データを符号化した符号データをクライアントへ転送する機能を有するサーバと、符号データを受信して復号化した画像を表示する機能を有するクライアントとを有する。クライアントはサーバへ符号データを受信する要求をする要求送信手段と、サーバから転送された符号データを受信する受信手段と、受信した符号データを復号する復号手段と、復号化の画像データを再生する再生手段とを具備する。サーバはクライアントからの要求を受信する要求受信手段と、サーバから転送要求されたＪＰＭファイルの全部又は一部の符号データを選択する選択手段と、選択された符号データをクライアントへ送信する符号データ送信手段とを具備する。
【選択図】 図２９

Description

本発明はクライアント・サーバシステムに関し、詳細にはマルチオブジェクトの中から１つのオブジェクトだけを選択して復号再生するための技術に関する。
ＪＰＩＰ（JPEG2000 Interactive Protocol）は、ＪＰＥＧ２０００の圧縮画像データを対象としたサーバ・クライアント環境における圧縮画像データの転送プロトコルである。このＪＰＩＰでは、ＪＰＭ符号データをアクセスすることもできる。なお、ＪＰＭ符号データは、複数個のオブジェクトデータにより構成され、例えば、前景画像データ、背景画像とマスクを持ち、マスク画像によって前景背景といった複数個のオブジェクトよりなるマルチオブジェクト構成をもつ符号データである。
ＪＰＩＰでは、ユーザからの要求に従って、最初に画像全体の概要がわかるように出力する。例えば、解像度の高くないデータを再生する。そして、使用者は、その画像を見て、要求を切り替えて、ある特定領域の部分符号データを再ロードして復号再生する。そのため、最初の画像出力（表示）は試験的なものであり、最初に概要の画像を出力するための処理時間を短くできることが望ましい。そこで、従来例としての特許文献１では、マルチオブジェクトで構成される符号化されたデータ（ＪＰＭファイ）から部分符号データを抽出してＪＰＭファイルを部分的に送信する提案がなされている。
特開２００５−０３３８０１号公報
しかしながら、上記特許文献１によれば、ＪＰＭ符号データはマルチオブジェクトにより構成されているが故に、仮に解像度の低い画像を再生する場合であっても、複数個のオブジェクトの復号処理を必要とするため、データ転送や復号再生処理に時間がかかることが問題であった。
本発明はこれらの問題点を解決するためのものであり、マルチオブジェクトの中からシングルオブジェクトを選択して復号再生し、時間経過後にユーザからの必要とされる画像あるいは部分画像の指示に基づいて、残りのオブジェクトを合わせて出力すると共に、ＪＰＭの符号データをオブジェクト単位でプログレッシブ再生することで、早い段階で画像データの全体的な概要を知ることができ、あるオブジェクトの処理を省略することでさらに高速な再生を実現することができるクライアント・サーバシステムを提供することを目的とする。
前記問題点を解決するために、本発明のクライアント・サーバシステムは、画像データを符号化した符号データをクライアントへ転送する機能を有するサーバと、符号データを受信して復号化した画像を表示する機能を有するクライアントとを有して構築している。そして、本発明のクライアント・サーバシステムにおけるクライアントは、サーバへ符号データを受信する要求をする要求送信手段と、サーバから転送された符号データを受信する受信手段と、受信した符号データを復号する復号手段と、復号された画像データを再生する再生手段とを具備している。また、サーバは、クライアントからの要求を受信する要求受信手段と、サーバから転送要求されたＪＰＭファイルの全部又は一部の符号データを選択する選択手段と、選択された符号データをクライアントへ送信する符号データ送信手段とを具備している。本発明のクライアント・サーバシステムで送受信される符号データは、ＪＰＭファイルの全部又は一部の符号データであって、ＪＰＭファイルの全部又は一部の符号データは、ＪＰＭファイルを構成する一部のオブジェクトの符号データである。よって、ＪＰＭをマルチオブジェクトではなく、シングルオブジェクトとして処理することで処理量を軽減することで高速化が実現できる。
また、サーバは、クライアントから要求された符号データを構成する１つのオブジェクトを送信した後クライアントから要求された符号データの残りのオブジェクトを送信することにより、最初の画像提示段階では概要がわかるだけでよいのでシングルオブジェクトの再生だけで済ますことができる。
更に、クライアントから要求された符号データを構成する全てのオブジェクトをオブジェクト単位で順次送信し、クライアントはオブジェクト単位で順次復号再生する。よって、オブジェクト単位でプログレシブに再生することで、早い段階で全体的な概要がわかる。
また、クライアントはサーバに送信停止要求信号を送り、サーバは送信停止要求信号を受信したときクライアントへオブジェクトの送信を停止することにより、例えば時間がなくなった場合にクライアント側からサーバ側へユーザが割り込みをかけ、オブジェクト単位でプログレシブに処理している途中で中断することができる。
更に、サーバがクライアントへ転送するオブジェクトの順番は、オブジェクトの優先順位に基づいて決められることにより、情報が意味のないオブジェクトの再生をしないで済ますことで高速化を図ることができる。
また、サーバは元画像の文字領域と絵柄領域の割合を算出する手段を有し、オブジェクトの優先順位は元画像の文字領域と絵柄領域の割合によって決める。よって、早い段階で画像全体の概要がわかるオブジェクトを選択でき、高速化が図れる。
更に、ＪＰＭファイルは複数ページの画像データより構成され、サーバはＪＰＭファイルに含まれる複数ページの画像データの全部又は一部の符号データを選択する選択手段を有し、かつクライアントは複数ページの画像データを復号再生する手段を有し、ＪＰＭファイルの全部又は一部の符号データはＪＰＭファイルを構成する一部のオブジェクトの符号データである。よって、一部のオブジェクトだけが先に復号再生されるため、早い段階で画像データの全体的な概要を知ることができる。
また、ＪＰＩＰ（JPEG2000 image coding system-Part9:Interactivity tools, APIs and protocols）のプロトコル規格に基づき、符号データが送受信されることにより、標準化され汎用性を図れる。
本発明のクライアント・サーバシステムで送受信される符号データは、ＪＰＭファイルの全部又は一部の符号データであって、ＪＰＭファイルの全部又は一部の符号データは、ＪＰＭファイルを構成する一部のオブジェクトの符号データである。よって、ＪＰＭをマルチオブジェクトではなく、シングルオブジェクトとして処理することで処理量を軽減することで高速化が実現できる。
はじめに、ＪＰＥＧ２０００による符号化について以下に説明する。
ＪＰＥＧ２０００の標準仕様においては、画像領域をタイル領域単位あるいは、プレシンクト領域単位に符号データが区別できるような形式で符号データが形成される。ＪＰＥＧ２０００(ISO/IEC 15444-1)規格の符号化は、おおよそ以下の手順でなされる。
先ず、インターレース画像のフレームデータを、Ｙ，Ｃｒ，Ｃｂの色成分毎のデータに変換する。そして、各色成分の色データに対しては、２次元離散ウェーブレット変換を施す。次に、得られるウェーブレット係数に、ＪＰＥＧ２０００に規定のスカラ量子化処理を施し、スカラ量子化されたデータに対しＪＰＥＧ２０００に規定のエントロピー符号化処理（いわゆる係数モデリングによる算術符号化処理）を施す。また、全ての色データに対しては、２次元離散ウェーブレット変換を施す。次に、得られるウェーブレット係数に、ＪＰＥＧ２０００に規定のスカラ量子化処理を施して、スカラ量子化されたデータに対しＪＰＥＧ２０００に規定のエントロピー符号化処理を施す。その後、ＪＰＥＧ２０００で規定する符号列を生成する。なお、復号化処理はこの逆の手順である。もちろん、これらの処理は、ハードウェア回路により実現しても良い。処理の高速化が図られる。また、ＪＰＥＧ２０００に準拠する符号化処理を全てハードウェア回路で実現する画像処理装置は、既に存在する。
図１はＪＰＥＧ２０００の基本となる階層符号化アルゴリズムを説明するためのブロック図である。同図に示すように、階層符号化・復号化部は、色空間変換・逆変換部１１、２次元ウェーブレット変換・逆変換部１２、量子化・逆量子化部１３、エントロピー符号化・復号化部１４、タグ処理部１５で構成されている。ＪＰＥＧアルゴリズムと比較して、最も大きく異なる点の一つは変換方法である。ＪＰＥＧでは離散コサイン変換(ＤＣＴ:Discrete Cosine Transform)を、階層符号化圧縮伸長アルゴリズムでは離散ウェーブレット変換(ＤＷＴ:Discrete Wavelet Transform)を、各々用いている。ＤＷＴはＤＣＴに比べて、高圧縮領域における画質が良いという長所が、ＪＰＥＧの後継アルゴリズムであるＪＰＥＧ２０００で採用された大きな理由の一つとなっている。また、他の大きな相違点は、後者では最終段に符号形成を行うために、タグ処理部１５と呼ばれる機能ブロックが追加されていることである。この部分で、圧縮動作時には圧縮データがコード・ストリームとして生成され、伸長動作時には伸長に必要なコード・ストリームの解釈が行われる。そして、コード・ストリームによって、ＪＰＥＧ２０００は様々な便利な機能を実現できるようになった。例えば、後述する図３に示すように、ブロック・ベースでのＤＷＴにおけるオクターブ分割に対応した任意の階層(デコンポジション・レベル)で、静止画像の圧縮伸長動作を自由に停止させることができるようになる。
なお、原画像の入出力部分には、色空間変換部が接続されることが多い。例えば、原色系のＲ(赤)／Ｇ(緑)／Ｂ(青)の各コンポーネントからなるＲＧＢ表色系や、補色系のＹ(黄)／Ｍ(マゼンタ)／Ｃ(シアン)の各コンポーネントからなるＹＭＣ表色系から、ＹＵＶあるいはＹＣｂＣｒ表色系への変換又は逆の変換を行う部分がこれに相当する。
以下、ＪＰＥＧ２０００アルゴリズムについて説明する。
カラー画像は、一般に、図２に示すように、原画像の各コンポーネント(ここではＲＧＢ原色系)が、矩形をした領域(タイル)によって分割される。そして、個々のタイル、例えば、R00,R01,・・・R15／G00,G01,・・・,G15／B00,B01,・・・,B15が、圧縮伸長プロセスを実行する際の基本単位となる。従って、圧縮伸長動作は、コンポーネント毎、そしてタイル毎に、独立に行なわれる。
符号化時には、各コンポーネントの各タイルのデータが、図１の色空間変換・逆変換部１１に入力され、色空間変換を施された後、２次元ウェーブレット変換・逆変換部１２で２次元ウェーブレット変換(順変換)が適用されて周波数帯に空間分割される。
図３はデコンポジション・レベル数が３の場合の各デコンポジション・レベルにおけるサブ・バンドを示す図である。すなわち、原画像のタイル分割によって得られたタイル原画像(0LL)(デコンポジション・レベル0)に対して、２次元ウェーブレット変換を施し、デコンポジション・レベル１に示すサブ・バンド(1LL,1HL,1LH,1HH)を分離する。そして、引き続き、この階層における低周波成分１LLに対して、２次元ウェーブレット変換を施し、デコンポジション・レベル２に示すサブ・バンド(2LL,2HL,2LH,2HH)を分離する。順次同様に、低周波成分２LLに対しても、２次元ウェーブレット変換を施し、デコンポジション・レベル３に示すサブ・バンド(3LL,3HL,3LH,3HH)を分離する。更に、図３では、各デコンポジション・レベルにおいて符号化の対象となるサブ・バンドを、グレーで表してある。例えば、デコンポジション・レベル数を３とした時、グレーで示したサブ・バンド(3HL,3LH,3HH,2HL,2LH,2HH,1HL,1LH,1HH)が符号化対象となり、サブ・バンド（3LL）は符号化されない。
次いで、指定した符号化の順番で符号化の対象となるビットが定められ、図１の量子化・逆量子化部１３で対象ビット周辺のビットからコンテキストが生成される。量子化の処理が終わったウェーブレット係数は、個々のサブ・バンド毎に、「プレシンクト」と呼ばれる重複しない矩形に分割される。これは、インプリメンテーションでメモリを効率的に使うために導入されたものである。図４に示すように、一つのプレシンクトは、空間的に一致した３つの矩形領域からなっている。更に、個々のプレシンクトは、重複しない矩形の「コード・ブロック」に分けられる。これは、エントロピー・コーディングを行う際の基本単位となる。
図１のエントロピー符号化・復号化部１４では、コンテキストと対象ビットから確率推定によって、各コンポーネントのタイルに対する符号化を行う。このようにして、原画像の全てのコンポーネントについて、タイル単位で符号化処理が行われる。エントロピー符号化・復号化部１４で形成される符号データの最小単位は、パケットと呼ばれる。パケットは、図５に示すように、プログレッシブ順にシーケンス化され、これが画像ヘッダセグメントの中の１つで示される。全てのプレシンクトのパケットを集めると画像全域の符号の一部（例えば、画像全域のウェーブレット係数のＭＳＢから３枚目までのビットプレーンの符号）ができるが、それをレイヤと呼ぶ。レイヤは画像全体のビットプレーン符号の一部であり、復号されるレイヤ数が増えると画質が向上する。全てのレイヤを集めると、画像全域の全てのビットプレーンの符号となる。
図６は画像全域のビットプレーン符号化例についてサブ・バンドをプレシンクトとした時のレイヤとパケットとの関係を示す図である。この例では、ウェーブレット変数の階層数（デコンポジション・レベル）が２でありデコンポジション・レベル２のサブ・バンドは４つのコードブロックに、デコンポジション・レベル１のサブ・バンドは９個のコードブロックにそれぞれ分割されている。パケットはプレシンクトを単位としていくつかのプレシンクトにより構成され、図６の例では、プレシンクトはサブ・バンドであるので、パケットはいくつかのサブ・バンドＨＬからＨＨサブ・バンドまでをまたいだものとなっている。
パケットは、あるプログレッシブ順データといえば、それぞれ、領域、解像度、レイヤ、および色成分によって配列される。即ち、ＪＰＥＧ２０００規格では、画質(レイヤ(L))、解像度(R)、コンポーネント(C)、位置(プレシンクト(P))という４つの画像の要素の優先順位を変更することによって、以下に示す５通りのプログレッションが定義されている。
・LRCP プログレッション：プレシンクト、コンポーネント、解像度レベル、レイヤの順序に復号されるため、レイヤのインデックスが進む毎に画像全面の画質が改善されることになり、画質のプログレッションが実現できる。レイヤプログレッションとも呼ばれる。
・RLCP プログレッション：プレシンクト、コンポーネント、レイヤ、解像度レベルの順序に復号されるため、解像度のプログレッションが実現できる。
・RPCL プログレッション：レイヤ、コンポーネント、プレシンクト、解像度レベルの順序に復号されるため、RLCP同様、解像度のプログレッションであるが、特定位置の優先度を高くすることができる。
・PCRL プログレッション：レイヤ、解像度レベル、コンポーネント、プレシンクトの順序に復号されるため、特定部分の復号が優先されるようになり空間位置のプログレッションが実現できる。
・CPRL プログレッション：レイヤ、解像度レベル、プレシンクト、コンポーネントの順序に復号されるため、例えばカラー画像のプログレッシブ復号の際に最初にグレーの画像を再現するようなコンポーネントのプログレッションが実現できる。
このようにＪＰＥＧ２０００規格では、画像は領域（タイルまたはプレシンクトといった画像構成要素）、解像度、階層（レイヤ）、色成分に分割され、それぞれが独立してパケットとして符号化される。これらのパケットはデコードすることなしに、コード・ストリームから識別され抽出され得るところに特徴がある。
図７の（ａ）は、ＬＲプログレッション（レイヤプログレッション）のプログレッシブ順序を模式的に表した図である。図７の（ｂ）は、ＲＬプログレッション（解像度プログレッション）のプログレッシブ順序を模式的に表した図である。
最後に、図１のタグ処理部１５は、エントロピー符号化・復号化部１４からの全符号化データを１本のコード・ストリームに結合するとともに、それにタグを付加する処理を行う。図８には、コード・ストリームの構造を示す。コード・ストリームの先頭と各タイルを構成する部分タイルの先頭にはヘッダと呼ばれるタグ情報が付加され、その後に、各タイルの符号化データが続く。そして、コード・ストリームの終端には、再びタグが置かれる。
一方、復号化時には、符号化時とは逆に、各コンポーネントの各タイルのコード・ストリームから画像データを生成する。図１を用いて簡単に説明する。この場合、タグ処理部１５は、外部より入力したコード・ストリームに付加されたタグ情報を解釈し、コード・ストリームを各コンポーネントの各タイルのコード・ストリームに分解し、その各コンポーネントの各タイルのコード・ストリーム毎にエントロピー符号化・復号化部１４で復号化処理が行われる。コード・ストリーム内のタグ情報に基づく順番で復号化の対象となるビットの位置が定められるとともに、量子化・逆量子化部１３で、その対象ビット位置の周辺ビット(既に復号化を終えている)の並びからコンテキストが生成される。エントロピー符号化・復号化部１４で、このコンテキストとコード・ストリームから確率推定によって復号化を行い、対象ビットを生成し、それを対象ビットの位置に書き込む。このようにして復号化されたデータは各周波数帯域毎に空間分割されているため、これを２次元ウェーブレット変換・逆変換部１２で２次元ウェーブレット逆変換を行うことにより、画像データの各コンポーネントの各タイルが復元される。復元されたデータは色空間変換・逆変換部１１によって元の表色系のデータに変換される。
次に、ＪＰＩＰにおける符号データのやり取りについて説明する。
本発明の実施の形態における別の特徴として、遠隔地に表示された部分画像データをアクセスして、遠隔地から遠隔操作対象である複写機（画像処理装置）に保存された階層符号データの一部または全部をアップロードして再表示する機能がある。典型的には、最初は転送効率を高めるために符号データを一部削減した部分符号データを受信し再生し、その後、さらに詳しく調べるために、残りの符号データを受信（アップロード）して再表示する。そのような機能を実現するために、画像符号化データのプロトコルとしてＪＰＩＰ（ＪＰＥＧ２０００ image coding system-Part9:Interactivity tools, APIs and protocols）がある。
ここで、サーバにあるＪＰＥＧ２０００符号から、必要な符号だけを受信するためのプロトコルとして国際規格ＪＰＩＰ（ＪＰＥＧ２０００ ｉｍａｇｅ ｃｏｄｉｎｇ ｓｙｓｔｅｍ − Ｐａｒｔ ９： Ｉｎｔｅｒａｃｔｉｖｉｔｙ ｔｏｏｌｓ， ＡＰＩｓ ａｎｄ ｐｒｏｔｏｃｏｌｓ）がある。このような、階層的な画像を部分的にアクセスするためのプロトコルは、古くは、画像の多重解像度表現であるFlash Pixと、それにアクセスするためのプロトコルであるIIP（Internet Imaging Protocol）に見ることができる。
図９はＪＰＩＰにおける典型的なクライアント・サーバ間のプロトコル概要を示す図である。先ず、クライアントからサーバへ画像符号データの送信要求が出され、サーバはその応答としてクライアントへ対応する画像符号化データを転送する。クライアントは送られてきた画像符号化データを再生した後、当該画像の部分画像を指示し、指示された部分画像に対応する符号データの転送要求をサーバに送る。サーバはそれに応答し、要求に対応する部分符号データをクライアントに送り、クライアントは送られてきた画像符号化データを再生するというものである。このように、ＪＰＩＰにおけるプロトコルでは、クライアントからサーバへ要求を出し、サーバがクライアントに要求に対応する応答をするというプロトコルを形成する。すなわち、ＪＰＩＰにおいては、クライアントからの要求（リクエスト）に応じて、サーバは完全な画像ファイル、タイルパートストリーム（ＪＰＴ−ストリーム）またはプレシンクトストリーム（ＪＰＰ−ストリーム）の形式をもつ符号データを戻す（応答する）。ＪＰＴ−ストリームは、ＪＰＥＧ２０００パート１規格で規定されるタイルパートの組としてサブ画像の符号データを戻す方法である。一方、ＪＰＰ−ストリームは、ＪＰＥＧ２０００パート１規格で規定されるプレシンクトの組としてサブ画像の符号データを戻す方法である。ＪＰＴ−ストリームにより順次アクセスした符号データを再生する場合は、タイル分割されたタイル領域毎に順次完全に再生するのに対して、ＪＰＰ−ストリームにより順次アクセスした符号データを再生する場合は、タイル領域に跨った広い領域で、小さい領域（プレシンクト）単位に徐々に再生することができる。すなわち、ＪＰＴ−ストリームのアクセスによる再生では、一時に再生する範囲が画像全体の中であるタイル領域に限定されているのに対し、ＪＰＰ−ストリームのアクセスによる再生では、一時に再生する範囲はタイル領域に限定されず画像全体での再生が可能なのである。
このように、ＪＰＩＰのクライアントは、受信された符号データの部分を識別でき、それらの部分を復号し、かつ画像を生成することのできるように、タイルパートストリーム又はプレシンクトストリームの形式で、ＪＰＥＧ２０００コード・ストリームのサブセットを戻す機能を提供する。すなわち、ＪＰＰ−ストリームはＪＰＥＧ２０００コード・ストリームへ変換されＪＰＥＧ２０００デコーダで復号することができる。前記変換は、復号されるデータと共に、メインヘッダの全てとタイルヘッダの全てを受信すれば十分である。図１０はＪＰＥＧ２０００ファイルとデータビンとの関係を例示している。ＪＰＰ−ストリームは、図１１に示すように、メッセージのシーケンスより構成される。各メッセージは、含まれるデータビン情報の形式を示す（メインヘッダ、メタデータ、プレシンクト、又はタイルヘッダ）。各メッセージは、データビン内の開始位置とメッセージの長さも示す。各メッセージは、その形式、その形式内のインデックス、その形式とインデックスを有する“データビン”へのメッセージのオフセット、及びメッセージ長を識別するヘッダを有する。メッセージは、典型的には、データビン全てを含まず、データビンの一部を含む。メッセージには、データビンがどのタイル、コンポーネント、位置及び解像度データビンに対してであるかを示す識別子を含む。
本発明では、タイル、コンポーネント、位置及び解像度を階層としており、データビンに含まれる符号列（パケット）は、各階層のどのレベル（階層レベル）のデータであるかという情報が対応している。例えば、データビンに含まれるある符号列がタイルＡでコンポーネントが、Ｃｂでかつ位置４で、解像度１レベルであることが示されている。
プレシンクト・データビンは、図１２に示すように、一連のパケットヘッダ（ＰＨ）とパケットデータ（ＰＤ）より構成される。パケットヘッダは、どのコードブロックがパケットのパケットデータ部分内のデータを有するかに関する情報、各符号ブロックに格納されたバイト数に関する情報、及び各符号ブロックについての符号化パスの数を含む。JPIPの標準仕様では、パケットヘッダには、どのコンポーネント、位置、解像度、タイル、あるいは、それが属するレイヤを識別する情報（階層レベル情）はもってない。本発明の一実施の形態として、先に示したメッセージデータを解析して、パケット単位の階層レベル情報をパケットヘッダに記録してもかまわない。クライアント側でＪＰＰ−ストリーム受信後、これらの情報を記録することもできる。
同様に、JPIPの標準仕様では、パケットヘッダの長さに関する明確な情報も持たない。パケットデータの長さは、パケット内の全てのコードブロックにデータの長さを加算することにより決定できる。本発明の一実施例として、パケットヘッダにこれらのデータ長を計算した結果を保存する構成にすることができる。ＪＰＰ−ストリームに規定された構成によりパケットを抽出することができる。
また、ＪＰＩＰのプロトコルは、二つの異なるタイプの要求をもっている。サーバがキャッシュモデルを維持する必要がないという意味におけるステートレスリクエストとそれ以外のリクエストがある。サーバのキャッシュモデルには、それまでにサーバに送信したことについての情報の記録がなされている。クライアントのキャッシュには、サーバから受信した符号データが保存され、サーバはキャッシュモデルを用いることによって、既に転送した符号データをクライントに転送することなく、再利用できる。典型的には、クライアントは、断片的に受信したＪＰＥＧ２０００の符号データを、受信した順番にデータをアペンドしキャッシュに保存する。続いて、前述したようにキャッシュしたデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、そのビットストリームをデコードする。
次に、ＪＰＩＰにおけるクライアント、サーバ及びネットワークについて説明する。ここで、図１３はＪＰＩＰにおけるキャッシュを持ったクライアントサーバモデル構成例であり、図１４はＪＰＩＰにおけるクライアントサーバネットワークモデルの構成例である。
図１３の（ａ）に示すように、サーバ２２は、ある種のネットワークを介してクライアント２１のような少なくとも１つのクライアントに接続されている。クライアント２１は、しばしば、人間のユーザにより制御される“プログラム”であるが、完全に自動化されたシステムでも良い。クライアント２１は、ある画像のサブセットに対する要求のような、要求（リクエスト）を発行し、この要求に示された方法で対応する符号データを含む、応答のような応答を受信する。ネットワークの帯域幅又はサーバ２２の資源又はファイル要求の構造のために、クライアント２１は要求された画像の部分符号データ以外のおおよその符号データを受信し得る。クライアント２１は、典型的には、キャッシュを用いて、画像の異なる部分の出力に対する要求を発行し、前に受信された符号データに対する追加分の符号データを受信する。
ここで、ＪＰＩＰの基本的特徴の一つは、クライアントが既に受信した符号データを繰返すことを避ける能力である。この符号データの再送信を避ける２つの方法がある。第１の方法としては、図１３の（ａ）に示すように、クライアント２１が、サーバ２２へ送信されクライアント２１で既に受信された符号データについての情報を持つことで、クライント２１は冗長なデータの配信をサーバ２２に要求しないで済ませ、それにより、サーバ２２は冗長な符号データを送信しないで済ます方法がある。サーバ２２が、“ステートレス”で動作する場合にあっては、それまでの相互動作を記憶することなく動作する。サーバが、それまでの相互動作を記憶する特別なキャッシュモデルを維持する必要がないことから、一般的には、ステートレスで動作しているということが多い。
また、第２の方法としては、図１３の（ａ）に示すように、クライアント２１とサーバ２２は、“セッション”を確立し、サーバ２２は、クライアント２１へ送られた符号データを記憶しておくキャッシュモデル２６をもっている。すなわち、サーバ２２のキャッシュモデル２６には、それまでにサーバ２２に送信したことについての情報の記録がなされている。クライアント２１のキャッシュ２３には、サーバ２２から受信した符号データが保存され、サーバ２２は、キャッシュモデル２６を用いることによって、既に転送した符号データをクライント２１に転送することなく、再利用できる。典型的には、クライアント２１は、断片的に受信したＪＰＥＧ２０００の符号データを、受信した順番にデータをアペンドしキャッシュ２３に保存する。続いて、前述したようにキャッシュしたデータからＪＰＥＧ２０００のシンタックスに準拠したビットストリームを作成し、そのビットストリームをデコードする。
また、本発明は、主に、図１３の（ｂ）に示すようなステートレスな要求を処理するに係り、キャッシュ管理部２８を有することで、キャッシュ２３のキャッシュデータを管理するところに特徴がある。クライアント２１は、それまでに要求した符号データの全てを受信する前にさえも、興味のある画像の部分に対応する符号データを変更し得る。あるサーバは、これらの変更を扱うために、前の要求に対する応答を割り込みすることができる。
図１４は典型的なネットワークを示す図である。同図に示すように、ネットワークは、複数のクライアント、例えばクライアント３１〜３５と複数のサーバ、例えばサーバ３６，３７を含んで構成されている。単一のサーバは、数１００万の異なるクライアントへ同じ画像の異なる部分を扱い得る。単一のクライアントは、画像と他のデータ（例えば、ＨＴＭＬページ）を、幾つかのサーバから受信する。プロキシサーバは、オリジナルサーバと通信すること無しにいくつかの要求への素早い応答を可能とするために、ネットワーク内に存在しうる。有効な帯域幅と帯域幅のコストは、異なるクライアントと同じサーバの間で又は、異なるサーバの間で広く変わる。
最も一般的に使用されるネットワークは、インターネット又はワールドワイドウェブである。しかし、ＪＰＩＰは、ローカルエリアネットワーク又は、どのような一般的な相互接続システムに適用できる。同様に、ＪＰＩＰは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）の上で”最も一般的に転送されるが、ＴＣＰ／ＩＰ及びＵＤＰを含む他の転送プロトコルと共に使用されると予想される。
以上のことから、ＪＰＩＰストリームの符号フォーマット（メッセージ）を分析することで、コンポーネント数、レイヤ数、プレシンクトサイズ、デコンポジション分割数などの階層符号データを構成する各階層のレベル数がわかる。また、プログレッション順序についても知ることができる。
図１５はＪＰＩＰを使用した場合の出力表示画面例を示す図である。最上位画面では、２つのタイルからなるデータが表示されていて、例えば、図１５の（ａ）に示すようにそれぞれのタイルをクリックすることによって画像データが表示され、図１５の（ｂ）のような画質の劣ったタイル４枚からなる画像となる。更に、右下の画像をクリックすることによって、図１５の（ｃ）に示すようにクリックしたタイルの部分画像の解像度が変倍され、部分画質レベルが向上する。このように、部分画像データを参照する場合に使用される。部分画像データを参照する都度、表示クライント側からサーバ側へ符号データを転送要求し再生する。
このようにＪＰＩＰにおいては、クライアント（出力側）では、全ての（階層）符号データではなく、部分符号データを必要としていることを前提としている。そのため、部分符号データからオリジナルの符号データの階層構造を知ることができないという問題があった。
なお、ＪＰＩＰの“主な使用事例”は、２００２年７月１５日に発行されたＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ１Ｎ２６５６に詳細に記載されている。ＪＰＩＰの主要な応用例としては、大きな画像のブラウジングである。ＪＰＩＰは、航空画像、医療画像及び、プリプレス画像を代表とする大きな画像の低解像度版又は部分を小さな携帯表示装置（例えば、携帯電話、携帯情報端末等）で見る方法を提供する。
次に、ＪＰＥＧ２０００のコード・ストリームのフォーマットについて説明する。
ＪＰＥＧ２０００のコード・ストリームは、画像についての全てのエントロピー符号化されたデータと、その符号化されたデータを復号するために使用されるべき方法を記述するデータを含む。コード・ストリームは、使用されるウェーブレット変換に関する情報、タイルのサイズ、プレシンクトのサイズ、解像度に関する情報、ファイル内のパケットの順序等を含む。コード・ストリームは、エントロピー符号化されたデータを画像サンプルに復号するのに必要な全てのパラメータを含まなければならない。コード・ストリームは、例えばパケットの長さのような、符号化されたデータの部分への高速アクセスを提供する情報も含み得る。
図１６の（ａ）はＪＰＥＧ２０００のコード・ストリームのフォーマットの概略構成を示す図である。ＪＰＥＧ２０００の“コード・ストリーム”には、いくつかのマーカセグメントをもっている。マーカセグメントとは、一つの２バイト長よりなるマーカとそれに付随するパラメータ群から構成されている。各マーカセグメントには機能、用途、データ長が表されている。コード・ストリームのフォーマットは符号データの始まりを示すＳＯＣ（Ｓｔａｒｔ ｏｆ Ｃｏｄｅｓｔｒｅａｍ）マーカで始まる。ＳＯＣマーカの後には、符号化のパラメータや量子化のパラメータ等を記述したメインヘッダが続き、その後に実際の符号データが続く。
図１６の（ｂ）はメインヘッダの概略構成を示す図である。メインヘッダはＣＯＤ，ＱＣＤの必須マーカセグメントとＣＯＣ，ＱＣＣ，ＲＧＮ，ＰＯＣ，ＰＰＭ，ＴＬＭ，ＰＬＭ，ＣＲＧ，ＣＯＭのオプションマーカセグメントで構成される。ここで、ＳＩＺマーカセグメントには、コンポーネント数とかタイルサイズなどの非圧縮時の画像の情報が記述され画像コンポーネントの幅と高さについての情報を含む。ＣＯＤとＣＯＣマーカセグメントは、圧縮されたデータはどの様に復号されるべきかを示すパラメータを含む。ＣＯＤマーカにはプログレッション順序、レイヤ数、プレシンクトサイズ、デコンポジション分割数が記述されている。ＱＣＤマーカは量子化に係る情報が記載されている。また、ＣＯＭマーカはコメント等の情報を付加したいときに利用するマーカで、メインヘッダ、タイルヘッダの双方で使用することが可能である。メインヘッダの後に、一連の“タイルパート”がある。各タイルパートは、特定のタイルと部分を識別する“ＳＯＴ”マーカセグメントで始まる。各タイルパートについて符号化されたデータには、“ＳＯＴ”マーカセグメントが先行する。“ＳＯＴ”マーカセグメントには、タイルパート数に係る情報を含んでいる。
図１７に示すような実際の符号データは、ＳＯＴ（Ｓｔａｒｔ ｏｆ Ｔｉｌｅ−ｐａｒｔ）マーカで始まり、タイルヘッダ、ＳＯＤ（Ｓｔａｒｔｏｆ ｄａｔａ）マーカ、タイルデータ（符号）で構成される。これら画像全体に相当する符号データの後に、符号の終了を示すＥＯＣ（Ｅｎｄ ｏｆ Ｃｏｄｅｓｔｒｅａｍ）マーカが付加される。メインヘッダはＣＯＤ，ＱＣＤの必須マーカセグメントとＣＯＣ，ＱＣＣ，ＲＧＮ，ＰＯＣ，ＰＰＭ，ＴＬＭ，ＰＬＭ，ＣＲＧ，ＣＯＭのオプションマーカセグメントで構成される。
図１６の（ｃ）に示すタイルヘッダ構成は、タイルデータの先頭に付加されるマーカセグメント列であり、ＣＯＤ，ＣＯＣ，ＱＣＤ，ＱＣＣ，ＲＧＮ，ＰＯＣ，ＰＰＴ，ＰＬＴ，ＣＯＭのマーカセグメントが使用可能である。一方、図１６の（ｄ）は、タイル内が複数に分割されている場合における分割されたタイルパートの先頭に付加されるマーカセグメント列であり、ＰＯＣ，ＰＰＴ，ＰＬＴ，ＣＯＭのマーカセグメントが使用可能である。タイルヘッダでは必須マーカセグメントはなく、全てオプションである。タイルデータ（符号）は、連続したパケットで構成される。コード・ストリーム中のパケットの順番をプログレッション順序と呼んでいる。
以上のことから、ＪＰＥＧ２０００コードフォーマットを分析することで、コンポーネント数、レイヤ数、プレシンクトサイズ、デコンポジション分割数などの階層符号データを構成する各階層のレベル数がわかる。また、プログレッション順序についても知ることができる。
図１８は本発明における文書画像データが３つのオブジェクトの画像データで構成されている例を示す概略図である。同図に示すように、文書画像データは独立した複数個のオブジェクトの画像データに分割され、それぞれを独立に符号化しマルチオブジェクト構成をもつ符号データが生成される。マルチオブジェクト構成をもつ符号データは互いに独立したそれぞれのオブジェクトの符号データにより構成され、各オブジェクト単位で独立に復号することができる。最終的に、複数オブジェクトを合成して１つの文書データが再生される。本発明は、この観点に着目し、オブジェクトを選択して単独のオブジェクトであっても独立に復号再生することができる構成とした。なお、本発明では１つのオブジェクトのことをシングルオブジェクトと記し、複数個のオブジェクトのことをマルチオブジェクトという。
図１９は本発明の典型的なシステム処理を示すフローチャートである。同図に示すように、本発明にあるようなＪＰＭのようなマルチオブジェクト構成をもつ符号データをオブジェクト単位の部分符号データを選択的に転送し復号再生するときに、オブジェクト単位でプログレッシブに処理する。同図において、最初にクライアント側から、サーバ側に、サーバにある符号データを指定し（ステップＳ１０１）、その符号データの全部または一部のオブジェクトを再生することをサーバ側に要求する（ステップＳ１０２）。ユーザが符号データを指定する場合には、プログレシブに再生するか、プログレシブではなく一度に再生するかを指定することもできる。サーバ側は指定された符号データのオブジェクトを選択し（ステップＳ１０３，Ｓ１０４）、そのオブジェクトの符号データから復号可能な符号ストリームを生成する。符号データはマルチオブジェクト構成をもつ符号データであり、この図の例では、１つのオブジェクト（図１９ではシングルオブジェクトと記している）を自動的に選択している。自動的に選択する処理については後述する。サーバ側は生成した符号ストリームをクライアント側へ転送する（ステップＳ１０５）。クライアント側は、サーバ側から転送された符号ストリームに基づいてシングルオブジェクトを復号再生する（ステップＳ１０６）。
図２０はＪＰＩＰにおけるＪＰＭオブジェクト選択処理を示すフローチャートである。同図において、サーバ側はクライアント側から符号データを受信する要求を受けると（ステップＳ２０１；ＹＥＳ）、当該要求を解析する（ステップＳ２０２）。そして、当該要求に基づいて指定された符号データのマルチ・シングルオブジェクトを選択し（ステップＳ２０３）、そのオブジェクトの符号データから復号可能な符号ストリームを生成する（ステップＳ２０４）。サーバ側は生成した符号ストリームをクライアント側へ転送する（ステップＳ２０５）。クライアント側は、サーバ側から転送された要求を解析し（ステップＳ２０６）、符号ストリームを入力する（ステップＳ２０７）。そして、受信した符号ストリームに基づいてマルチオブジェクトを復号再生する（ステップＳ２０８）。
図２１は本発明の別な構成をもつシステム処理を示すフローチャートである。シングルオブジェクトの画像データが復号再生された後、画像の全領域あるいは部分領域のマルチオブジェクトの符号データが再生される構成になっている。同図において、最初にクライアント側から、サーバ側に、サーバにある符号データを指定し（ステップＳ３０１）、その符号データの全部または一部のオブジェクトを再生することをサーバ側に要求する（ステップＳ３０２）。ユーザが符号データを指定する場合には、プログレシブに再生するか、プログレシブではなく一度に再生するかを指定することもできる。サーバ側は指定された符号データのオブジェクトを選択し（ステップＳ３０３，Ｓ３０４）、そのオブジェクトの符号データから復号可能な符号ストリームを生成する。サーバ側は生成した符号ストリームをクライアント側へ転送する（ステップＳ３０５）。クライアント側は、サーバ側から転送された符号ストリームに基づいてシングルオブジェクトを復号再生する（ステップＳ３０６）。その後、クライアント側から部分画像アクセスの要求をサーバ側に送信すると（ステップＳ３０７）、サーバ側は指定された符号データのオブジェクトを選択し（ステップＳ３０８，Ｓ３０９）、そのオブジェクトの符号データから復号可能な符号ストリームを生成する。サーバ側は生成した符号ストリームをクライアント側へ転送する（ステップＳ３１０）。クライアント側は、サーバ側から転送された符号ストリームに基づいてマルチオブジェクトを復号再生する（ステップＳ３１１）。すなわち、最初に全てのオブジェクトを転送し処理するのではなく、シングルオブジェクトだけ転送され再生されることから、早く処理をすることができることから、早い段階で再生画像の概要を把握することができる。
図２２は本発明の別な構成のＪＰＩＰにおけるＪＰＭオブジェクト選択処理を示すフローチャートである。同図において、サーバ側はクライアント側から符号データを受信する要求を受けると（ステップＳ４０１；ＹＥＳ）、当該要求を解析する（ステップＳ４０２）。そして、当該要求に基づいて指定された符号データのオブジェクトを選択し（ステップＳ４０３）、そのオブジェクトの符号データから復号可能な符号ストリームを生成する（ステップＳ４０４）。サーバ側は生成した符号ストリームをクライアント側へ転送する（ステップＳ４０５）。クライアント側は、サーバ側から転送された要求を解析し（ステップＳ４０６）、符号ストリームを入力する（ステップＳ４０７）。そして、受信した符号ストリームに基づいてマルチオブジェクトを復号再生する（ステップＳ４０８）。
次に、ＪＰＭ仕様に基づく画像再生について説明する。
マルチオブジェクトで構成される符号化では、入力画像（文字画像混在文書画像）は複数の画像データに分離され、それぞれに適した符号化が施される。分離されたそれぞれを本発明ではオブジェクトと記し、複数のオブジェクトにより構成されていることをマルチオブジェクトと記している。例えば、マルチオブジェクト構成をもつ符号データ生成についての概念図である図２３の例では、入力画像は、前景画像、背景画像、マスクデータに分離される。通常、マスク画像は、前景か背景かのいずれかを表す２値データで表され、マスクの値が１の画素領域では、前景画像が再生され、マスクの値が０の画素領域では、背景画像が再生される。マスク画像が０か１かで前景画像と背景画像のいずれかを選択するように分離されている。一方、前景あるいは背景画像は一般に多値データで表される。図２３の例では、それぞれのオブジェクトである前景画像、背景画像、マスクデータが互いに独立に符号化され、マルチオブジェクトで構成される符号化された符号データが形成される。
図２４はマスクデータとその前景データを抽出する方法の概念を説明するための図である。同図からわかるように、元画像データの文字は、色とか模様（グラデーション）をもっていて、それが２値データのマスクデータと色とか模様（グラデーション）の前景画像データとに分離している。よって、画像情報（文字画像混在文書画像）の公知の領域属性判別手段を用いて抽出した文字領域情報を使用することで、マスクデータが算出できる。
図２５は本発明の分離画像データ生成に係る処理を示すフローチャートである。同図において、画像データを読み込み（ステップＳ５０１）、例えば領域属性判別手段により画像の属性領域を識別する（ステップＳ５０２）。そして、文字だけの二値画像データをマスクデータとして生成し（ステップＳ５０３）、更には文字領域を除いた文字なしの画像データを作成する（ステップＳ５０４）。最後に、文字の色を表す画像データを作成する（ステップＳ５０５）。このように、典型的な実施例では、入力画像に対する文字領域の領域判別結果を使用して、マスクデータと前景画像データだけでなく、背景画像データも同時に生成する。よって、オブジェクト毎に独立なイメージデータとして分離し符号化され、図２３に示すように、マルチオブジェクトで構成される符号化がなされる。
一方、画像データの再生では、図２６に示すように、それぞれの符号化されたオブジェクトは復号され、オブジェクト毎のイメージデータが再生された後、合成処理が施されて元の画像が再生される。この合成処理はオブジェクトごとに分離の方法に対応している。このマルチオブジェクトで構成される符号化の一つとして、JPEG2000 Part6に係るJPM(ISO/IEC FDIS 15444-6)がある。
ここで、JPMによる実現方式について説明するための式を下記に示す。この式は画像再現の方法を示している。式中のPage Imageが再現画像を表している。JPMでの画像データの分解は、背景画像に相当するBase Imageデータと、Mmと記載されているマスクデータと、前景画像に相当するImと記載されている（マスク上の）イメージデータに分解する。
Figure 2008244539
但し、Mm：ｍ番目のLayout ObjectにおけるMask Objectの画素値、Im：ｍ番目のLayout ObjectにおけるImage Objectの画素値、c：コンポーネント、x,y：画像の座標、Sm：Mm（マスク）の最大値（２のべき乗）、n：当該ページに含まれるLayout Objectの数である。
また、下記にJPMの適応例を示す。
Figure 2008244539
JPMの規定によれば、マスクデータ（Mm）は、イメージデータ（Im）の不透明度を表しているが、図２３を用いて説明した本発明の典型的な実施例では、先に説明したようにマスクデータの値は１又は０に限定する。なお、この例においては、Base Imageデータを背景画像データとして、マスクデータ（Mm）と、イメージデータ（Im）は１組のデータしかもたない構成に分解している。別の元画像データの分解として、Base Imageデータを透明データとして、背景画像データである。これらの式に基づいて、合成処理がなされ画像データが再生される。
ＰＤＦも、マルチオブジェクト構造をもつ符号データに符号化されるファイルフォーマットであり、ＰＤＦであってもかまわない。ＰＤＦはＪＰＥＧ２０００コード・ストリームを許容するように最近更新され、ＰＤＦファイルフォーマットを構成するオブジェクトはＪＰＥＧ２０００で符号化することもできる。
次に、ＪＰＭオブジェクトをプログレッシブに処理する場合について以下に説明する。
図２７は本発明のＪＰＭのオブジェクト単位でプログレシブに処理される考え方を示す図である。同図において、タイプ１は、図１８で示した、プログレシブ処理をしない場合の再生について示している。最初に、シングルオブジェクトの画像が再生される。典型的な再生は、画像の全体像を把握できるように、シングルオブジェクトの全領域の画像が再生される。その後、部分領域あるいは全領域のマルチオブジェクトの符号データが再生される。図１８を用いて説明したように、クライアント側からサーバ側への再生要求により、サーバ側からクライアント側へ部分符号データが転送され復号再生される。この例では、画像データはブロック単位で符号化されていることを想定している。全てのオブジェクトで同じようにブロック単位で符号化することで、ＪＰＭなどのマルチオブジェクト構成の符号データをブロック単位で符号化することができる。
また、タイプ２は、アクセスされた部分符号データがプログレシブ処理される場合を示している。タイプ２では、最初に、シングルオブジェクトの画像が再生され、続いて、部分領域あるいは全領域の野マルチオブジェクトを構成するそれぞれのオブジェクトの部分符号データが順次プログレシブに処理している。オブジェクト単位でプログレシブに処理している。
更に、タイプ３は、時間がなくなった場合に、図２８に示す処理フローのステップＳ５０７にあるように、クライアント側からサーバ側へユーザが割り込みをかけ、オブジェクト単位でプログレシブに処理している途中で処理を中断する。図２８に示されるように、サーバ側は、プログレシブ処理中に送信停止要求を受けることができて、途中で再生を中断することができる。このことによりプログレシブ表示中に必要がなくなったと使用者が判断したとき、処理を中断することができる。
また、ＪＰＭ符号データの再生について、図２３及び図２６で説明したように、複数オブジェクトを再生するには、各オブジェクトを合成することにより再生される。
図２９はプログレッション処理システムの構成を示すブロック図である。同図に示すプログレッション処理システムは、図１３でＪ２Ｋファイル２７と表されているところが、ＪＰＭファイルになった構成をとっている。最も通常使用されるネットワークは、インターネット又はワールドワイドウェブ（ＷＷＷ）であるが、ここに説明される技法は、ローカルエリアネットワーク（ＬＡＮ）又は任意の一般的な相互接続システムに適用可能である。同図に示すように、ネットワーク４０には、クライアント４１、サーバ４２以外に、画像データを入力する入力装置４３、符号データを生成する符号処理装置４４が接続されている。入力装置４３で入力された文書画像データがネットワーク４０を通して、符号処理装置４４に転送され、符号処理装置４４では、文書画像データを符号化して符号データを生成する。生成された符号データがネットワーク４０を通してサーバ４２に転送される。なお、クライアント４１は、データ送受信部４６、符号データ保存部４７、符号データ編集部４８及び復号処理部４９を含んで構成されている。サーバ４２は、データ送受信部５０、符号データ保存部５１及び符号データ編集部５２を含んで構成されている。また、同図に示すように、ネットワーク４０には、表示装置あるいはプリンタなどの出力装置４５が接続されている。クライアント４１で生成された画像データはネットワーク４０を介して出力装置４５へ転送され文書画像が出力される。また、クライアントシステムには、表示をするための表示装置とキーボードなどからデータを入力するための入力装置が直接接続されている。先に示した画像データの表示は、この表示装置になされる。また、ユーザの指示も入力装置からなされ、信号データに変換されデータ送受信部を通してサーバ側へ送信される。ここで、クライアントシステムにおける復号処理部は、図３０に示すような構成を有している。
次に、プログレッション処理について説明する。
図３１はJPEG2000コード・ストリームを示す図である。同図に示すように、通常符号データは、このように、先頭に先頭記号があり、終端に終端符号が付いていて、符号データ間の区別をしている。また、符号データにはヘッダが付加されていて、ヘッダに続いて符号データの本体である符号列により構成されている。
図３２はパケットとよばれる符号列により構成される符号データの構成例を示す図である。JPEG2000の仕様による符号データもこのようなパケット構成をしている。この例では、符号データを構成するパケットは、４つのレイヤと３つの画像領域（プレシンクト単位）に対応した計１２個のパケットにより構成されている。
図３３、図３４で示すような符号ストリームを、部分符号データ毎に順次プログレッシブ復号する。符号ストリームは、図３３、図３４で示すような領域毎の要素符号データ単位に並べた符号ストリームである場合もあれば、層毎の要素符号データ単位に並べた符号ストリームである場合もある。例えば、出力種別情報がプリンタの場合は、領域毎の要素符号データ単位に並べた符号ストリームを生成し、復号再生する。一方、出力種別情報が表示装置の場合は、層毎の要素符号データ単位に並べた符号ストリームを生成し、復号再生する。
以下、プログレッシブ復号する処理について図３０を用いて説明する。図３０に示す復号処理部４９は、符号ストリーム保存部４９−１、部分符号データ選択部４９−２、算術符号復号化部４９−３、符号データ一部保存部４９−４、逆WT変換部４９−５によって構成されている。ＪＰＥＧ２０００の符号ストリームの復号処理を行うことができる。図３５はプログレシブな復号処理の概略を示すブロック図である。図３０の符号ストリーム保存部４９−１には、処理対象としている符号ストリームを保存する。部分符号データ選択部４９−２は、符号データを、先頭の要素符号データから順に選択して抽出する。算術符号復号化部４９−３は、抽出された要素符号データを取り出して、該要素符号データを算術符号復号しＷＴ係数データを算出する。符号データ一部保存部４９−４は、部分符号データ単位で復号する場合に使用される。符号データ一部保存部４９−４には、抽出したＷＴ係数データが書き込まれる。このＷＴ係数データを保存する符号データ一部保存部４９−４は、ＷＴ係数データが順次書き込み追加される。逆WT変換部４９−５は、ＷＴ係数符号データを逆ウェーブレット変換し再生する。層単位の要素符号データを復号する場合には、既に符号データ一部保存部４９−４に保存されていたＷＴ係数データを使用して逆WT変換する。
次に、プログレシブ復号処理について当該処理フローを示す図３６に従って説明する。同図において、先ず保存部のデータはクリアする（ステップＳ６０１）。そして、符号ストリームを読み込み（ステップＳ６０２）、符号ストリームの部分符号データを順次選択する（ステップＳ６０３）。全ての部分符号データがあるか否かを判断し、ない場合は処理を終了する（ステップＳ６０４；ＮＯ）。全ての部分符号データがあれば、部分符号データを算術符号復号しＷＴ係数データを算出する（ステップＳ６０５）。そして、ＷＴ係数データを算出する（ステップＳ６０６）。層単位の符号データストリームの場合は、該ＷＴ係数データと、一部保存されたＷＴ係数データを用いて、ＷＴ係数データを算出する。最後に、逆ウェーブレット変換し画像を再生する（ステップＳ６０７）。なお、ここでは、カラーである場合や、ＪＰＥＧ２０００のＤＣ変換については省略し簡略に説明したが、カラーである場合や、ＪＰＥＧ２０００のＤＣ変換についても同様に処理される。
図３７及び図３８は、プログレシブ処理される符号データの流れを説明するための図である。図３７は画像領域に対応する部分符号データ単位でプログレシブ処理する場合の処理の過程における符号データの流れに示し、図３８は層に対応する部分符号データ単位でプログレシブ処理する場合の処理の過程における符号データの流れに示している。なお、プログレシブ処理は、部分符号データの構成によって再生の態様が異なってくる。図３７では、領域区分容易な領域単位で符号ストリームは生成され、一方、図３８である場合は、層区分容易な層単位で符号ストリームが生成されている。ＪＰＥＧ２０００は、スケーラブルな構成を持つ階層符号であるので、どちらの符号ストリームをも生成することができるし、どちらか一方の区分をもつ部分符号データ単位を、もう一方の区分をもつ部分符号データ単位に変換することができる。符号ストリームを構成する要素符号データはプログレシブに順次復号される。図３６に示すように、画像領域に対応する部分符号データ単位でプログレシブ処理する場合には、領域単位に順次復号され、領域単位に順次再生される。プリンタでは、プリンタの処理の順番であるラスタ順に再生し、処理効率を高めることができる。一方、図３８に示すように、層に対応する部分符号データ単位でプログレシブ処理する場合は、層単位に順次復号され、層単位に順次再生される。表示装置では、全体的に徐々に詳しく再生するような場合で、画像の全体像を早く知ることができる。
次に、ＪＰＩＰにおけるＪＰＭオブジェクトの選択について説明する。
プログレシブ再生においては、より重要度の高い画像から徐々に再生されることが望ましく、オブジェクト単位の優先順位の設定が課題となる。図３９〜図４２は、オブジェクト単位の優先順位の設定処理を示すフローチャートである。オブジェクト単位の優先順位情報は、先に示した符号処理装置で設定され、符号データのヘッダに書きこまれ保持される。サーバはクライアントから、指定された符号データのヘッダを参照することで、係るオブジェクト単位の優先順位情報を知ることができる。
図３９において、ＪＰＭ符号データの各オブジェクトのヘッダの先頭アドレスを取り出す（ステップＳ７０１）。そして、オブジェクト単位の部分符号データの絵柄文字領域の割合を算出し（ステップＳ７０２）、文字絵柄領域の割合によってマルチオブジェクトのオブジェクト単位の優先順位を設定する（ステップＳ７０３）。ここで、領域属性判別手段における、文字領域の抽出は、画像データ全体の二値化処理（二値画像生成処理）を行った後、二値化処理結果を分析して文字領域を抽出（文字領域抽出処理）する。二値画像生成処理では、まず、ブロック単位に入力されたＲＧＢ信号に対して輝度信号であるＹ信号に変換する。ＲＧＢ信号からＹ信号への変換は、種々の方法があり特に限定されないが、最も簡単な変換式の一例としてJPEG2000に採用されている変換式を以下に示す。
Ｙ＝（Ｒ＋２×Ｇ＋Ｂ＋２）／４
変換されたＹ信号は、ブロック単位に決定されたしきい値に応じて、二値化が行われる。ここでのしきい値決定処理方法としては、例えば、特開２００２−７７６３号公報にて開示されているようなヒストグラムをとって平均、分散等の統計的性質を利用した方法や、簡易な方法としてはブロック内全画素の輝度(Y)値の平均値を用いたり、平均値に所定の重みを演算することによって決定する方法等が考えられる。
なお、二値化処理は以上の計算方法に特定されず、Ｙ信号変換処理をすることなくＲＧＢ信号各々でしきい値を決定し二値化処理を行っても良い。
次に、文字領域抽出処理では、二値画像生成処理によって得られた二値画像データから文字領域の抽出を行う。ＯＣＲ処理などでは良く行われる技術であり、例えば、特開２００２−７７６３１号公報にて開示されているように二値画像データの黒画素の輪郭線追跡を行い、全てをラベリングして縦、横の幅がしきい値以下の黒画素の集まりのみ文字として文字領域を抽出する。また、前述のように画像データを解析するという方法によらず使用者が直接領域を指定することにより設定してもかまわない。別の一例として、例えば、各々文書画像データが入力されるエッジ領域検出回路及び白地領域検出回路と、これらの検出回路の検出結果に応じて文書画像データの処理対象領域が文字領域であるか絵柄領域であるかを判定して画像判別（像域分離）するという構成にすることができる。テキスト絵柄割合は、領域属性判別手段を用いて、元文書画像データに含まれるテキスト及び絵柄の割合を調べることで算出することができる。典型的には、画像データをスキャンしながら、画像の小領域ごとに領域属性判別しながら、テキストおよび絵柄である領域の数を集計し、合計値により割合を算出する。例えば、図４３の（ａ）に示すような文字領域６０と絵柄領域６１とが混在する単純な原稿６２による文書画像データを処理対象とする場合では、文書画像データを図４３の（ｂ）に示すように複数のラスタラインｙ０、ｙ１、・・・に分割し、そのラスタライン単位でテキスト絵柄領域の数をカウントしていく。なお、これ以外にも、オブジェクトの優先順位を設定するいくつかの方式がある。
次に、図４０において、ＪＰＭ符号データの各オブジェクトのヘッダの先頭アドレスを取り出す（ステップＳ８０１）。そして、オブジェクト単位の部分符号データの符号量を算出し（ステップＳ８０２）、符号量によってマルチオブジェクトのオブジェクト単位の優先順位を設定する（ステップＳ８０３）。また、図４１においては、ＪＰＭ符号データの各オブジェクトのヘッダの先頭アドレスを取り出す（ステップＳ９０１）。そして、オブジェクト単位の優先順位情報を算出し（ステップＳ９０２）、当該優先順位情報によってマルチオブジェクトのオブジェクト単位の優先順位を設定する（ステップＳ９０３）。このように、図４１に示すオブジェクト単位の優先順位の設定処理は、優先順位オブジェクト単位の優先順位が使用者により設定される場合である。更に、図４２においては、ＪＰＭ符号データの各オブジェクトのヘッダの先頭アドレスを取り出す（ステップＳ１００１）。そして、マスク画像が全て０又は１であることの識別データを抽出する（ステップＳ１００２）。抽出した識別データからマスク画像が全て０であれば（ステップＳ１００３；ＹＥＳ）背景画像のシングルオブジェクト符号データを選択する（ステップＳ１００４）。このように、図４２に示すオブジェクト単位の優先順位の設定処理は、マルチオブジェクトを構成するマスク画像によって判別する場合である。
次に、本発明におけるマルチページの場合のプログレシブ復号再生処理について当該処理フローを示す図４４に従って説明する。
図４４において、符号データが入力された場合（ステップＳ１１０１；ＹＥＳ）、符号データを読み込む（ステップＳ１１０２）。第１の符号ストリームを復号し（ステップＳ１１０３）、第１の符号ストリームの再生画像を保存する（ステップＳ１１０４）。第１の符号ストリームの画像を再生する（ステップＳ１１０５）。そして、第２の符号ストリームの入力があれば（ステップＳ１１０６；ＹＥＳ）、残りの符号ストリームを再生せずに、第２の符号ストリームを読み込む（ステップＳ１１０７，Ｓ１１０８）。読み込んだ第２の符号ストリームを復号する（ステップＳ１１０９）。次に、第１、第２の符号ストリームの再生画像をＪＰＭ合成して再生する（ステップＳ１１１０，Ｓ１１１１）。
以上の実施の形態では、ＪＰＭファイルには１画像データ分含まれている構成について説明した。ところで、ＪＰＭあるいはＰＤＦファイルフォーマットは複数ページを有するドキュメントにも多く使用されている。上述した１画像データ分に適応される技法は、複数ページにも適応されることは言うまでもない。しかし、複数ページ処理では、処理量の負担が大きいため、処理量を軽減し高速化を図ることが重要な課題となる。
図４５は複数ページ処理する典型的な処理を示すフローチャートである。同図において、最初にクライアント側から、サーバ側に、サーバにある符号データを指定し（ステップＳ１２０１）、その符号データの全部または一部のオブジェクトを再生することをサーバ側に要求する（ステップＳ１２０２）。ユーザが符号データを指定する場合には、プログレシブに再生するか、プログレシブではなく一度に再生するかを指定することもできる。サーバ側はマルチページの指定された符号データのオブジェクトを選択し（ステップＳ１２０３，Ｓ１２０４）、そのオブジェクトの符号データから復号可能な符号ストリームを生成する。サーバ側は生成した符号ストリームをクライアント側へ転送する（ステップＳ１２０５）。クライアント側は、サーバ側から転送された符号ストリームに基づいてシングルオブジェクトを復号再生する（ステップＳ１２０６）。その後、クライアント側から部分画像アクセスの要求をサーバ側に送信すると（ステップＳ１２０７）、サーバ側はあるページの指定された符号データのオブジェクトを選択し（ステップＳ１２０８，Ｓ１２０９）、そのオブジェクトの符号データから復号可能な符号ストリームを生成する。サーバ側は生成した符号ストリームをクライアント側へ転送する（ステップＳ１２１０）。クライアント側は、サーバ側から転送された符号ストリームに基づいてマルチオブジェクトを復号再生する（ステップＳ１２１１）。このように、最初に複数個の画像データを復号し、各ページの画像データ毎にオブジェクトを選択し表示する。時間経過後、使用者は複数ページの再生画像を見て、１つの符号データを指定して、クライアント側からサーバ側へ、指定されて符号データを構成する残りのオブジェクトの部分符号データの転送を促し、部分符号データを再生する。指定されたページの画像を詳しく再生することができる。各ページの画像データ毎にオブジェクトを選択して処理する。図示はしないが、指定されたページの画像を詳しく再生する場合に、前述したような仕組みで、オブジェクト単位でプログレシブに再生することもできる。
なお、本発明は上記実施の形態に限定されるものではなく、特許請求の範囲内の記載であれば多種の変形や置換可能であることは言うまでもない。
ＪＰＥＧ２０００の基本となる階層符号化アルゴリズムを説明するためのブロック図である。 タイル分割の基本を示す図である。 デコンポジション・レベルとサブ・バンドを示す図である。 プレシンクトとコード・フロックを示す図である。 ＪＰＥＧ２０００のパケットを示す図である。 画像全域のビットプレーン符号化例についてサブ・バンドをプレシンクトとした時のレイヤとパケットとの関係を示す図である。 本発明のプログレッシブ順を制御する処理を示す図である。 コード・ストリームの構造を示す図である。 ＪＰＩＰにおける典型的なクライアント・サーバ間のプロトコル概要を示す図である。 ＪＰＥＧ２０００ファイルとデータビンとの関係を示す図である。 プレシンクト・データビンとメッセージとの関係を示す図である。 プレシンクト・データビンの一例を示す図である。 ＪＰＩＰにおけるキャッシュを持ったクライアントサーバモデル構成例を示す図である。 ＪＰＩＰにおけるクライアントサーバネットワークモデルの構成例を示す例である。 ＪＰＩＰを使用した場合の出力表示画面例を示す図である。 ＪＰＥＧ２０００のコード・ストリームのフォーマットの概略構成とメインヘッダの概略構成を示す図である。 ＪＰＥＧ２０００のコード・ストリーム例を示す図である。 本発明における文書画像データが３つのオブジェクトの画像データで構成されている例を示す概略図である。 本発明の典型的なシステム処理を示すフローチャートである。 ＪＰＩＰにおけるＪＰＭオブジェクト選択処理を示すフローチャートである。 本発明の別な構成をもつシステム処理を示すフローチャートである。 本発明の別な構成のＪＰＩＰにおけるＪＰＭオブジェクト選択処理を示すフローチャートである。 マルチオブジェクト構成をもつ符号データ生成についての概念図である。 マスクデータとその前景データを抽出する方法の概念を説明するための図である。 本発明の分離画像データ生成に係る処理を示すフローチャートである。 マルチオブジェクト構成をもつ符号データの合成処理についての概念図である。 本発明のＪＰＭのオブジェクト単位でプログレシブに処理される考え方を示す図である。 プログレシブ処理を中断する場合のシステム処理を示すフローチャートである。 プログレッション処理システムの構成を示すブロック図である。 図２９の復号処理部の構成を示すブロック図である。 JPEG2000コード・ストリームを示す図である。 パケットの符号データの構成例を示す図である。 プログレッションの一例を示す図である。 プログレッションの他の例を示す図である。 プログレシブな復号処理の概略を示すブロック図である。 プログレシブ復号処理を示すフローチャートである。 画像領域に対応する部分符号データ単位でプログレシブ処理する場合の処理の過程における符号データの流れを示す図である。 層に対応する部分符号データ単位でプログレシブ処理する場合の処理の過程における符号データの流れを示す図である。 オブジェクト単位の優先順位の設定処理を示すフローチャートである。 オブジェクト単位の優先順位の設定処理を示すフローチャートである。 オブジェクト単位の優先順位の設定処理を示すフローチャートである。 オブジェクト単位の優先順位の設定処理を示すフローチャートである。 テキスト絵柄割合の算出について説明するための図である。 本発明におけるマルチページの場合のプログレシブ復号再生処理を示すフローチャートである。 複数ページ処理する典型的な処理を示すフローチャートである。
符号の説明
４０；ネットワーク、４１；クライアント、４２；サーバ、
４３；入力装置、４４；符号処理装置、４５；出力装置、
４６，５０；データ送受信部、４７，５１；符号データ保存部、
４８，５２；符号データ編集部、４９；復号処理部、
６０；文字領域、６１；絵柄領域、６２；原稿。

Claims (8)

  1. 画像データを符号化した符号データをクライアントへ転送する機能を有するサーバと、前記符号データを受信して復号化した画像を表示する機能を有するクライアントとを有して構築するクライアント・サーバシステムにおいて、
    前記クライアントは、前記サーバへ符号データを受信する要求をする要求送信手段と、前記サーバから転送された符号データを受信する受信手段と、受信した符号データを復号する復号手段と、復号された画像データを再生する再生手段とを具備し、
    前記サーバは、前記クライアントからの要求を受信する要求受信手段と、前記サーバから転送要求されたＪＰＭファイルの全部又は一部の符号データを選択する選択手段と、選択された符号データを前記クライアントへ送信する符号データ送信手段とを具備し、
    クライアント・サーバシステムで送受信される前記符号データは、ＪＰＭファイルの全部又は一部の符号データであって、ＪＰＭファイルの全部又は一部の符号データは、ＪＰＭファイルを構成する一部のオブジェクトの符号データであることを特徴とするクライアント・サーバシステム。
  2. 前記サーバは、前記クライアントから要求された符号データを構成する１つのオブジェクトを送信した後前記クライアントから要求された前記符号データの残りのオブジェクトを送信することを特徴とする請求項１記載のクライアント・サーバシステム。
  3. 前記クライアントから要求された符号データを構成する全てのオブジェクトをオブジェクト単位で順次送信し、前記クライアントは前記オブジェクト単位で順次復号再生することを特徴とする請求項１記載のクライアント・サーバシステム。
  4. 前記クライアントは前記サーバに送信停止要求信号を送り、前記サーバは送信停止要求信号を受信したとき前記クライアントへ前記オブジェクトの送信を停止することを特徴とする請求項１〜３のいずれか１項に記載のクライアント・サーバシステム。
  5. 前記サーバが前記クライアントへ転送するオブジェクトの順番は、オブジェクトの優先順位に基づいて決められることを特徴とする請求項２〜４のいずれか１項に記載のクライアント・サーバシステム。
  6. 前記サーバは元画像の文字領域と絵柄領域の割合を算出する手段を有し、前記オブジェクトの優先順位は元画像の文字領域と絵柄領域の割合によって決められることを特徴とする請求項５記載のクライアント・サーバシステム。
  7. ＪＰＭファイルは複数ページの画像データより構成され、前記サーバはＪＰＭファイルに含まれる複数ページの画像データの全部又は一部の符号データを選択する選択手段を有し、かつ前記クライアントは前記複数ページの画像データを復号再生する手段を有し、ＪＰＭファイルの全部又は一部の符号データはＪＰＭファイルを構成する一部のオブジェクトの符号データであることを特徴とする請求項１〜６のいずれか１項に記載のクライアント・サーバシステム。
  8. ＪＰＩＰ（JPEG2000 image coding system-Part9:Interactivity tools, APIs and protocols）のプロトコル規格に基づき、前記符号データが送受信されることを特徴とする請求項１〜７のいずれか１項に記載のクライアント・サーバシステム。
JP2007078139A 2007-03-26 2007-03-26 クライアント・サーバシステム Expired - Fee Related JP4898513B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007078139A JP4898513B2 (ja) 2007-03-26 2007-03-26 クライアント・サーバシステム
US12/055,994 US7949725B2 (en) 2007-03-26 2008-03-26 System including a server and at least a client

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007078139A JP4898513B2 (ja) 2007-03-26 2007-03-26 クライアント・サーバシステム

Publications (2)

Publication Number Publication Date
JP2008244539A true JP2008244539A (ja) 2008-10-09
JP4898513B2 JP4898513B2 (ja) 2012-03-14

Family

ID=39796184

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007078139A Expired - Fee Related JP4898513B2 (ja) 2007-03-26 2007-03-26 クライアント・サーバシステム

Country Status (2)

Country Link
US (1) US7949725B2 (ja)
JP (1) JP4898513B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012138851A (ja) * 2010-12-27 2012-07-19 Toshiba Corp 画像送信装置および方法、画像受信装置および方法
JP2013013085A (ja) * 2011-06-29 2013-01-17 Canon Inc 高ビット深度画像の圧縮
JP2018501693A (ja) * 2014-11-05 2018-01-18 コリン，ジャン−クロード 動画像を作成するための方法

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7852353B1 (en) * 2005-03-31 2010-12-14 Apple Inc. Encoding a transparency (alpha) channel in a video bitstream
KR100886337B1 (ko) * 2006-11-23 2009-03-02 삼성전자주식회사 이미지 내 선택 영역을 일괄 저장하는 장치 및 이미지정보의 문서화 장치
US8731315B2 (en) * 2011-09-12 2014-05-20 Canon Kabushiki Kaisha Image compression and decompression for image matting
WO2014062934A1 (en) 2012-10-19 2014-04-24 Visa International Service Association Digital broadcast methods using secure meshes and wavelets
US9195782B2 (en) 2013-06-26 2015-11-24 Siemens Product Lifecycle Management Software Inc. System and method for combining input tools into a composite layout
CN104463593B (zh) * 2013-09-18 2018-06-19 曲立东 标签数据应用方法和装置

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005033801A (ja) * 2003-07-07 2005-02-03 Ricoh Co Ltd 部分的な書類画像へのネットワークアクセスを行なう方法、製造品及び装置
JP2005260319A (ja) * 2004-03-09 2005-09-22 Ricoh Co Ltd 画像処理装置、プログラム、記憶媒体及び画像送信方法
JP2006253995A (ja) * 2005-03-10 2006-09-21 Fuji Xerox Co Ltd 画像処理装置
JP2007019744A (ja) * 2005-07-06 2007-01-25 Canon Inc サーバ装置及びその制御方法、クライアント装置及びその制御方法、コンピュータプログラム、記憶媒体

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4250316B2 (ja) 2000-08-25 2009-04-08 キヤノン株式会社 画像圧縮装置、画像伸長装置、及びその方法並びに記憶媒体
US6870961B2 (en) * 2000-11-10 2005-03-22 Ricoh Company, Ltd. Image decompression from transform coefficients
US7646927B2 (en) * 2002-09-19 2010-01-12 Ricoh Company, Ltd. Image processing and display scheme for rendering an image at high speed
US8036475B2 (en) * 2002-12-13 2011-10-11 Ricoh Co., Ltd. Compression for segmented images and other types of sideband information
US8769395B2 (en) 2002-12-13 2014-07-01 Ricoh Co., Ltd. Layout objects as image layers
US7447369B2 (en) * 2003-03-07 2008-11-04 Ricoh Co., Ltd. Communication of compressed digital images
US7460724B2 (en) * 2003-03-07 2008-12-02 Ricoh Co., Ltd. JPP-stream to JPEG 2000 codestream conversion
JP4618676B2 (ja) * 2005-04-28 2011-01-26 株式会社リコー 構造化文書符号の転送方法、画像処理システム、サーバ装置、プログラム及び情報記録媒体
US20060269151A1 (en) * 2005-05-25 2006-11-30 Hiroyuki Sakuyama Encoding method and encoding apparatus
US7502501B2 (en) * 2005-12-22 2009-03-10 Carestream Health, Inc. System and method for rendering an oblique slice through volumetric data accessed via a client-server architecture

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005033801A (ja) * 2003-07-07 2005-02-03 Ricoh Co Ltd 部分的な書類画像へのネットワークアクセスを行なう方法、製造品及び装置
JP2005260319A (ja) * 2004-03-09 2005-09-22 Ricoh Co Ltd 画像処理装置、プログラム、記憶媒体及び画像送信方法
JP2006253995A (ja) * 2005-03-10 2006-09-21 Fuji Xerox Co Ltd 画像処理装置
JP2007019744A (ja) * 2005-07-06 2007-01-25 Canon Inc サーバ装置及びその制御方法、クライアント装置及びその制御方法、コンピュータプログラム、記憶媒体

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012138851A (ja) * 2010-12-27 2012-07-19 Toshiba Corp 画像送信装置および方法、画像受信装置および方法
JP2013013085A (ja) * 2011-06-29 2013-01-17 Canon Inc 高ビット深度画像の圧縮
JP2018501693A (ja) * 2014-11-05 2018-01-18 コリン，ジャン−クロード 動画像を作成するための方法

Also Published As

Publication number Publication date
US20080244002A1 (en) 2008-10-02
US7949725B2 (en) 2011-05-24
JP4898513B2 (ja) 2012-03-14

Similar Documents

Publication Publication Date Title
JP4898513B2 (ja) クライアント・サーバシステム
JP4538430B2 (ja) サーバクライアント環境におけるシステム及び方法
JP4064196B2 (ja) クライアントコンピュータ、サーバコンピュータ、プログラム、記憶媒体、画像データ処理システム及び画像データ処理方法
JP4612782B2 (ja) 画像処理装置、及びその方法、並びにプログラム、記憶媒体
JP4716949B2 (ja) 画像処理装置および画像処理方法
JP2008258994A (ja) 画像処理装置
US7302105B2 (en) Moving image coding apparatus, moving image decoding apparatus, and methods therefor
US20060269151A1 (en) Encoding method and encoding apparatus
JP4349816B2 (ja) 画像処理装置、画像圧縮装置、画像処理方法、画像圧縮方法、プログラム、及び記録媒体
JP2004248152A (ja) 画像圧縮装置、画像伸張装置、画像圧縮方法、画像伸張方法、プログラム、及び記録媒体
EP1296287A2 (en) Image information code processing system
JP4151963B2 (ja) 画像サーバ装置、クライアント装置、動画像配信方法、プログラム、及び、情報記録媒体
JP2009017527A (ja) サーバにより駆動されるプログレッシブ画像伝送方法およびシステム
US7721971B2 (en) Image processing system, image processing method and computer readable information recording medium
JP2007028439A (ja) 画像処理装置、画像処理方法
JP2005123856A (ja) 画像処理システム、画像処理方法、プログラム及び情報記録媒体
JP4637672B2 (ja) 符号化処理装置及び方法
JP4073333B2 (ja) 画像圧縮装置及び画像圧縮方法
JP2005092007A (ja) 画像処理システム、画像処理方法、プログラム及び情報記録媒体
JP2007166013A (ja) 画像処理方式、画像処理方法、画像処理プログラム及び画像処理プログラムを記録した記録媒体
JP4208122B2 (ja) データ処理装置及びデータ処理方法
JP4792250B2 (ja) 動画像処理装置、及び動画像処理方法
JP2007053593A (ja) 画像処理システム、画像処理方法、プログラムおよび記録媒体
JP2008147893A (ja) クライアントサーバシステム及び遠隔操作システム
JP2004274710A (ja) 情報処理装置、情報処理方法、プログラム及びコンピュータ読取り可能な記録媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20091019

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20091207

RD04 Notification of resignation of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7424

Effective date: 20100115

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110325

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110524

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110610

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110808

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20111216

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20111226

R150 Certificate of patent or registration of utility model

Ref document number: 4898513

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150106

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees