JP4371982B2 - 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体 - Google Patents

画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体 Download PDF

Info

Publication number
JP4371982B2
JP4371982B2 JP2004324076A JP2004324076A JP4371982B2 JP 4371982 B2 JP4371982 B2 JP 4371982B2 JP 2004324076 A JP2004324076 A JP 2004324076A JP 2004324076 A JP2004324076 A JP 2004324076A JP 4371982 B2 JP4371982 B2 JP 4371982B2
Authority
JP
Japan
Prior art keywords
image
data
resolution
decoding
output
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.)
Expired - Fee Related
Application number
JP2004324076A
Other languages
English (en)
Other versions
JP2006135792A5 (ja
JP2006135792A (ja
Inventor
幸 榎田
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.)
Canon Inc
Original Assignee
Canon Inc
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 Canon Inc filed Critical Canon Inc
Priority to JP2004324076A priority Critical patent/JP4371982B2/ja
Priority to US11/266,298 priority patent/US7558430B2/en
Publication of JP2006135792A publication Critical patent/JP2006135792A/ja
Publication of JP2006135792A5 publication Critical patent/JP2006135792A5/ja
Application granted granted Critical
Publication of JP4371982B2 publication Critical patent/JP4371982B2/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
    • 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/188—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 video data packet, e.g. a network abstraction layer [NAL] unit
    • 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/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • 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/44—Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • 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
    • 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

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)
  • Editing Of Facsimile Originals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Image Processing (AREA)

Description

本発明は圧縮符号化された画像データを処理する技術に関するものである。
近年、コンピュータの表示装置として用いられているディスプレイも技術の進化と共に、解像度が向上している。例えば従来であれば、VGA(640x480画素)、SVGA(800x600画素)程度であった解像度が、現在ではノートＰＣでさえ、XGA(1024x768画素)以上になり、ディスクトップＰＣにいたっては、SXGA(1280x1024画素), UXGA(1600x1200画素)が普及しており、更に今後はQXGA, QUXGAなどの高解像度をサポートすることは容易に推察できる。
更に、デジタルカメラなどで撮影した多数の画像データを同時に表示し、その中から選択的に１枚表示に切り替えて、ズームやスクロールなどの表示技術により、より詳細な画像データを表示するようなアプリケーションがある。この場合、同時に多数の画像データを一度に表示する場合には、高速性が重要視されるため、主画像データとは異なる予め作成されているサムネイル画像データを用いることが多い。一方そのサムネイル表示から選択された画像データの一枚表示は、主画像データを用いて、アプリケーションのウィンドウサイズあるいは、ディスプレイ装置に表示できるまでは、画像全体を表示し、それ以上の拡大表示になると、画像の一部分を表示する。
このような、１枚の画像データを表示する際に、元々の画像データの画像サイズとは異なる元々の画像データの画像サイズより小さい画像サイズを複数種類使用するようなアプリケーションの場合、必要に応じてデコード処理を行い、一旦元々の画像データの画像サイズを再現し、その後目的の画像サイズになるように、画像データを縮小することを行っていた。この場合画像データは、非圧縮かあるいはJPEG baselineのようなシーケンシャルの符号化方式で圧縮されている。
あるいは、画像データを階層符号化方式で画像圧縮しておき、表示に必要な画像サイズまでをデコードし、表示するように実装していた。階層符号化方式としては、ＪＰＥＧ２０００が知られている。このＪＰＥＧ２０００は、１枚の画像データを１つ以上のタイルに分割し、その分割されたタイル毎に、１つ以上の解像度を持つ階層符号化方式として、２００１年にＩＳＯ／ＩＴＣで標準化された画像符号化方式である。またネットワーク上でこのＪＰＥＧ２０００で符号化された符号データファイルに対して断片的に必要な部分のみをアクセスする時のプロトコルとして、JEG2000 image coding system - Part 9: Interactivity tools, APIs and protocols(以下、JPIPと記す)があり、現在策定中である。
例えば、特許文献１として、サーバにＪＰＥＧ２０００で符号化された圧縮画像ファイルを置き、クライアントからコードストリームを部分的に要求し、バッファして格納する。格納されていない部分のみを新規にサーバに対して要求を発行し、受信した符号データと既にバッファリングしている符号データとを接合し、デコードすることを繰り返す。この時の部分的な要求の単位は、ＪＰＥＧ２０００の符号内のパケット、タイル、コードブロックから選択される。また、バイト単位での要求も可能となっている。一方サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。
また、特許文献２には、ＪＰＥＧ２０００符号データのうち、サブバンド単位でサーバにデータを要求するもので且つ、デコード時で使用した係数を保持し、次に上位のサブバンドの符号データを要求した場合は、その係数に今回のデータを付加することでデコードし、デコードで使用した係数を保持することを繰り返すことにより、クライアント側で受信した符号データをバッファして格納する必要がないシステムである。これにより解像度方向のプログレッシブ表示を可能にするものである。
特開２００３−０２３６３０公報 特開２００４−０４０６７４公報
例えば、この特許文献２によると、画像サイズが２０４８×２０４８画素の画像データをdecomposition level =５で符号化したＪＰＥＧ２０００の符号化データファイル“A.jk2”があるとする。この場合、ファイル“A.j2k”は、６４×６４,１２８×１２８,２５６×２５６,５１２×５１２,１０２４×１０２４,２０４８×２０４８の６種類の異なる解像度の画像データを再現できる。また画像をデコード/表示するアプリケーションプログラムファイル“APP_1.exe”でサムネイル画像から選択された時に表示する画像サイズは、２５６×２５６画素相当の画像サイズを表示するとする。
このような条件では、“APP_1.exe”で選択された１枚の画像データを表示する時の処理は、６４×６４→ １２８×１２８→２５６×２５６の３つの解像度の符号データをデコードして、デコードされた画像を表示することになる。すなわち、このアプリケーション“APP_1.exe”では、２５６×２５６画素以下の解像度の画像データは扱わないので、２５６×２５６画素サイズ以下の解像度の符号データがある場合は、必ず２５６×２５６画素以上の画像データをデコードするまで、デコーダをループさせなければならない。そのため、デコードに時間がかかるという問題がある。またそのアプリケーションで使用しない解像度の符号データをバッファなどで格納しなければならず、格納のための領域を余計に使用してしまうという問題点もある。さらには、JPIPでサーバに符号データを要求する場合は、通信のための時間も余計にかかるという問題もある。
更にこの特許文献２においては、デコード処理を途中で止めて、デコード処理で使用した係数を保持するため、符号データを保持する場合に比べて、保持のためのメモリを多く使用することになる。またデコーダも途中で止めたり、更には、サブバンドのデータを追加したりと、特殊なデコーダが必要になる。
また、これら特許文献１、２では、サーバに保持されているＪＰＥＧ２０００符号データの圧縮パラメータは変更なしで、断片的に符号データの一部分をクライアントに送信し、クライアントで受信した符号データを変換などしないでそのままデコードするため、クライアント側のアプリケーションで使わない部分の解像度の符号データまでをも処理しなければならないという問題がある。さらには解像度の階層数が、デコーダ側でサポートしている階層数を越している場合は、受信した符号データを最後までデコードできないということが生じる場合があるという問題点もある。
本発明はかかる問題点に鑑みなされたものであり、低解像度から高解像度に向けて段階的に復号するための階層符号化データ構造を有する符号化画像データを、復号する装置の表示解像度もしくは表示サイズに合わせて再構成することで、次回の復号処理に要する処理を簡略化させる技術を提供しようとするものである。
この課題を解決するため、本発明の画像処理装置は以下の構成を備える。すなわち、
画像を構成する各タイルについて低解像度から高解像度の画像を段階的に生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置であって、
出力しようとする画像の出力解像度を判定する判定手段と、
該判定手段で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定された位置までの符号化データを用いて復号し、出力用画像データを生成する復号手段と、
該復号手段で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号手段で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化手段とを備える。
本発明によれば、低解像度から高解像度に向けて段階的に復号するための階層符号化データ構造を有する符号化画像データを、復号する装置の表示解像度もしくは表示サイズに合わせて再構成することになり、次回の復号処理に要する処理を簡略化させることが可能になる。
以下、添付図面に従って、本発明にかかる実施形態を詳細に説明する。
図１は、インターネットに代表されるネットワーク上に複数のコンピュータが接続されている様子を示した図である。同図において、１００はインターネットに代表されるネットワーク、１０１はサーバ・コンピュータであり、例えば画像データを送信するためのＪＰＥＧ２０００用の通信プロトコルであるＪＰＩＰサーバをはじめ、ＷＷＷサーバ機能に必要なソフトウエアが実行される。また１０４は大容量の画像データを格納するストレージ装置（実施形態ではＨＤ）であり、ＪＰＥＧ２０００符号化方式で符号化された圧縮画像データが多数保存されている。１０２及び１０３はクライアント・コンピュータ（以下、クライアントＰＣ）であり、ＷｅｂブラウザをはじめＷｅｂの各ページを表示するために必要なクライアント・ソフトウエアと、ＪＰＥＧ２０００符号化データをデコード/表示するためのクライアント・ソフトウエアならびに、ＪＰＩＰのクライアント機能を実装したソフトウエアなどが実行される。
図２は、図１においてクライアントＰＣのブロック構成図である。図中、２０１は、システム全体の制御などを行っているＣＰＵである。２０２はキーボードで、２０２ａはマウス（登録商標）等のポインティングデバイスと共にシステムに情報などを入力するために使用される。２０３は表示部で、ＣＲＴTや液晶ディスプレイなどで構成されている。２０４はＲＯＭ、２０５はＲＡＭで、システムの記憶装置を構成し、システムが実行するプログラムやシステムが利用するデータを記憶する。２０６はハードディスク装置であり、ＯＳ、各クライアントソフトウェアを格納しており、各種データファイルを記憶するものである。２０７はフロッピー（登録商標）・ディスク装置で、システムのファイルシステムに使用される外部記憶装置を構成している。２０８はプリンタインタフェースである。２０９はネットワークインタフェースであり、ここからインターネットなどのネットワーク上に接続されているサーバ・コンピュータなどのネットワーク上の資源にアクセスする。また、図１におけるサーバ・コンピュータ１０１も基本的には図２で示した構成を持つものであるが、ハードディスクに格納されているＯＳ、アプリケーションはサーバとして機能するものとなる点で異なる。
次に図３を用いて一般的なＪＰＥＧ２０００符号化データの構造を説明する。図示は、Resolution level-Layer-Component-Position progression(以下Resolution Progressionと記す)の符号化オプションで符号化されたＪＰＥＧ２０００符号データの例である。
Resolution Progressionに準じた場合、resolution/layer/component/positionの順に符号データが記録される。その他にもSNR Progressionなどの符号順が選択可能であるが、これら符号データの並び順をprogression orderと呼ぶ。本実施形態では、説明を簡単にするため、Resolution Progressionとして説明する。
次に図４を用いてウェーブレット変換による解像度とサブバンドの関係を説明する。同図では、decomposition level = 4の場合を説明している。まずはLL(NL=１)のみでresolution level = ０の解像度の画像となる。そして、ＬＬの画像とHL(NL=1), LH(NL=1), HH(NL=1)の３つのサブバンドをデコードすることでlevel=１の解像度の画像が生成可能になる。そして、NL=１の解像度の画像とNL=２のサブバンドでlevel=２の解像度の画像が生成可能になる。NL=２の解像度の画像とNL=３のサブバンドでlevel=３の解像度の画像が生成可能になる。そして、NL=３の解像度の画像とNL=４のサブバンドでlevel =４の解像度の画像が生成可能、というように計５種類の解像度の画像データを再現できる。このようにresolution level番号が１つずつ増加する毎に再現される画像データの画像サイズ（水平、垂直方向の画素数）は、幅、高さ共に２倍になっていく。図３で示したResolution Progressionの場合は、１つのresolution levelの符号データは、layer番号が小さい順で、component番号が小さい順に、position番号が小さい順になるように並べられている。ここでのlayer番号は復元しる画像の原画に対するS/N比に対応し、layer番号が小さいほどS/N比が悪い画像データを再現することになる。
さらにＪＰＥＧ２０００符号データファイル内でのresolution番号、layer番号、component番号の各最大値は、エンコード時のエンコード・パラメータによって予め設定され、そのパラメータにしたがってエンコード処理されており、その各パラメタが符号化データの中にヘッダ情報として格納されている。また符号データにおける論理的な最小単位であるパケットは、各パケットに格納されている全code-blockの情報を管理しているpacket header部と、そのpacketを構成する全code-blockの符号データであるpacket dataから構成されている。
本第１の実施形態では、ローカル、つまり、クライアントＰＣのハードディスク等に格納されたＪＰＥＧ２０００形式のファイルのデコード方法について説明する。本実施形態におけるサンプル・アプリケーションは、ローカルに格納されているファイル一覧をそれぞれのサムネイル画像（先頭フレーム）を表示ウィンドウに表示し、その所望とするファイルを１枚の表示ウィンドウに表示することを想定する。
ここでサムネイル表示ウィンドウ内に表示する１枚の画像サイズは６４×６４画素固定で、１枚表示ウィンドウのウィンドウサイズは２５６×２５６画素の画像データが表示できるサイズとし、この１枚表示ウィンドウは、この最初に表示される画像サイズを最低解像度サイズとして、それ以上の解像度の画像データをユーザの指示に従って、拡大、縮小、スクロールなどの処理を行うことを想定する。
またローカルにある画像ファイルは、全て画像サイズが１０２４×１０２４画素サイズであり、それらの画像データを”decomposition level = 4”, “Resolution Progression”でＪＰＥＧ２０００符号化方式を用いて符号化しているとする。すなわち最低解像度が６４×６４画素サイズであり、次が１２８×１２８画素サイズ、その次が２５６×２５６画素サイズ、５１２×５１２画素サイズと続き、最後の最大解像度の画像サイズが１０２４×１０２４画素サイズの５種類の解像度を持つ階層符号化で符号化されている。
よって本実施形態の場合、１枚表示用ウィンドウは、２５６×２５６画素サイズ、５１２×５１２画素サイズ、１０２４×１０２４画素サイズの３種類の画像サイズの画像データを表示するものである。ただし、５１２×５１２、１０２４×１０２４の画素サイズは、表示可能サイズ２５６×２５６画素サイズを超えるので、その一部を表示することになる。
図５では、上記サンプル・アプリケーションでの画像表示の例を示している。図中、５００は、サムネイル表示用ウィンドウであり、６４×６４画素サイズの画像データファイル“Ａ”, ”Ｂ”, “Ｃ”, “Ｄ”, “Ｅ”, “Ｆ”の６枚を表示しているところを表している。なお、表示している画像ファイルが６個を超える場合には、スクロールバーを表示して、それ以外のファイルを表示する。ユーザは、ポインティングデバイス２０２ａなどで、例えば画像“Ｄ”が選択すると、該当する画像ファイル“Ｄ”を選択し、一枚表示の画像表示ウィンドウ５０１に２５６×２５６画素サイズの画像データをデフォルトとして図示のように表示する。
図６は、ＪＰＥＧ２０００で符号化された６枚の画像それぞれの符号データを示している。図示において、６００は、“Start of codestream”であり、符号データの始まりを示すマーカ・コードである。６０１は、エンコード・パラメータを格納しているメインヘッダである。例えば画像サイズが１０２４×１０２４画素サイズであり、”decomposition level = 4”とか, “Resolution Progression”で符号データが格納されていることをしめす。６０２から６０６までは、“Resolution Progression”で格納された各resolutionの符号データである。６０７は“End of codestream”であり、符号データの終りを示すマーカ・コードである。
画像サイズが１０２４×１０２４である場合、resolution level = ０で示される領域６０２には、６４×６４画素サイズの画像データをデコードするための符号データが格納されている。すなわち、図４で示すＬＬ(NL=0)部分の符号化データである。
resolution level =１で示される領域６０３には、１２８×１２８画素サイズの画像データをデコードするための符号データが格納される。つまり、図４のＨＬ(NL=1),ＬＨ(NL=1),ＨＨ(NL=1)で示す部分の符号データである。
resolution level =２で示される領域６０４には、２５６×２５６画素サイズの画像データをデコードするための符号データであり、図４のHL(NL=2), LH(NL=2), HH(NL=2)の部分に相当する符号データである。
resolution level =３で示される領域６０５には、５１２×５１２画素サイズの画像データをデコードするための符号データが格納される。図４のＨＬ(NL=3),ＬＨ(NL=3),ＨＨ(NL=3)の部分の符号データでもある。
最後の、esolution level =４で示される領域には、１０２４×１０２４画素の画像データをデコードするための符号データが格納される。図４のＨＬ(NL=4),ＬＨ(NL=4),ＨＨ(NL=4)で示すサブバンド部分の符号データである。
よって本実施形態の場合、図５のたサムネイル表示用ウィンドウ５００には、各画像データファイルにおける、図６で示したＪＰＥＧ２０００の符号データの内のresolution level = ０の領域までの符号データをデコードして得られた画像データを表示していることになる。このＪＰＥＧ２０００のデータのデコード処理そのものは本発明の主眼ではないので説明を割愛する。
では次に図５で示すサムネイル表示５００内の“Ｄ”で示している画像をユーザが指定し、その画像を画像表示ウインドウ５０１に表示する処理について説明する。
実施形態の場合、画像表示ウインドウ５０１は２５６×２５６画素の画像を表示可能なので、画像ファイルが選択されたデフォルト状態では、図６で示すＪＰＥＧ２０００の符号データのうち、符号６０４で示すresolution level = 2の領域までの符号データをデコードし、表示することになる。このデコード処理も前記サムネイル表示用のウィンドウで表示するためのデコード処理と同様であるので説明は要しないであろう。
ここで、この画像表示ウインドウ５０１に表示する画像データは、この２５６×２５６画素の画像サイズの画像データを最低解像度の画像データとして、これ以下の画像サイズの画像を表示する時は、２５６×２５６画素の画像データを縮小して表示するものとし、さらには、拡大表示する場合は、上の解像度の符号データをデコードして表示する。この時、高解像度の画像データは、画像表示ウインドウ５０１のサイズを超えてしまうため、画像の一部を表示して、残りの部分はスクロールなどの処理により、表示するものとする。
あるいは、表示ウィンドウサイズよりデコードして得られる画像データの画像サイズが大きい場合に、符号データがタイルに分割されている場合は、表示される部分のみのタイルをデコードし、スクロールなどで新規に必要になった部分のタイルをデコードしても良い。
では、decomposition levelを下げる処理を図７（ａ）、（ｂ）、図８（ａ），（ｂ）を用いて説明する。
説明を簡単にするため、画像“Ｄ”の符号データがタイル分割されていない場合（つまり、画像全体が１タイルの場合）で説明する。
まずステップＳ７０１で符号データのタイル数を取得する。今回の場合は、１である。次にステップＳ７０２ではデコードする階層数を計算する。今回の場合は、取得したい画像データの画像サイズが２５６×２５６画素であるので、階層数「２」の符号データまでをデコードすれば目的の画像サイズの画像を得ることができる。そのため、ステップＳ７０２で取得する階層数は「２」となる。
ステップＳ７０３では、実際の各タイルの１階層分のデコードを行う部分である。このデコード処理は、必ず最低解像度からデコードを行うことを想定しているので、ステップＳ７０３では、１回目のコールのときに、階層番号として「０」を設定する。この階層番号は、ステップＳ７０３を処理する毎に、１インクリメントされる。ステップＳ７０４では、目的の階層数デコードしたかを判断する部分であり、ステップＳ７０３で設定する階層番号と、ステップＳ７０２で設定した階層数の値を比較する。目的の階層までデコードまでステップＳ７０３を繰り返す。今回の場合は、ステップＳ７０３を３回ループすることにより目的の階層までをデコードしたことになる。
ステップＳ７０５では、デコードして得られた画像データを表示用の画像データに変換する部分である。
このステップＳ７０５の詳細は、図７（ｂ）に示す通りで、ステップＳ７０５−１で、今回デコードしたタイルのタイル番号から、表示画像データの空間的な位置を特定する。ステップＳ７０５−２で、ステップＳ７０５−１で特定された位置に対して、画像データをコピーするなどの処理を行い、表示用の画像データの形式に変換して、ステップＳ７０５の処理を終了する。
次にステップＳ７０６で、階層数を削減するための、最低解像度用のＬＬサブバンドデータに変換する。ステップＳ７０７では、全てのタイルに対して上記の処理を行ったの判断であり、全タイルを処理するまで、ステップＳ７０２からステップＳ７０７までを繰り返す。実施形態では、タイルが１つの例を説明しているので、ステップＳ７０７からステップＳ７０２に戻ることはなく、次のステップＳ７０８に進む。勿論、原画像が複数のタイルに分割されている場合には、ステップＳ７０２に戻ることになる。ステップＳ７０８では、ステップＳ７０６で変換された符号データを１つの符号データに変換し、新しい符号データを生成する部分である。
次に、上記ステップＳ７０６及びステップＳ７０８の詳細を図８（ａ），（ｂ）のフローチャートに従って説明する。まずステップＳ７０６の符号変換を図８（ａ）のフローチャートに従って説明する。
ますステップＳ８０１において、今回デコードしたタイルの符号化オプションを取得する。具体的には、符号データのMainHeaderとTilePartHeaderの中に入っているCOD,COC、QCD,QCCなどのマーカ・コードを検索し、エンコード時の符号化オプションを取得する。
次いで、ステップＳ８０２では、ステップＳ８０１で取得した符号化オプションの特にＬＬサブバンド部分の符号化オプションにしたがって、先に説明したステップＳ７０３、７０４でデコードした画像データをＥＢＣＯＴ（Embedded Bitplane COding by Truncation）を用いてＬＬ成分として再符号化する。ステップＳ８０３では、ステップＳ８０２で符号化して出力された符号データを取得し、ステップＳ８０４において、旧符号データの階層番号０から階層番号２までの符号データをステップＳ８０３で取得した符号データで置き変える。
次にステップＳ７０８の新符号データ作成の処理を図８（ｂ）のフローチャートにしたがい説明する。
まずステップＳ８０５において、旧符号データのMainHeaderを取得し、ステップＳ８０６で階層数を減らしたことを符号データに反映させるため、旧符号データでは、ＣＯＤマーカ・コード内の“Number of decomposition level”フィールド が「４」となっているところを、「２」に変える。これにより、最低解像度の画像サイズを６４×６４画素から２５６×２５６画素に変更したことになる。次にステップＳ８０７において、新MainHeaderとステップＳ８０４で作成した各タイルの新しい符号データ接合し、新しい１つの符号データを生成する。
サブバンドの具体例は、図４に示すサブバンドのＬＬ(NL=0),ＨＬ(NL=1),ＬＨ(NL=1),ＨＨ(NL=1),ＨＬ(NL=2),ＬＨ(NL=2),ＨＨ(NL=2)で示す７つのサブバンドの符号データをデコードし、それを図１４に示すようにＬＬ(NL=0)’に変換し、その他のHL(NL=3)〜HH(NL=4)は無変換で、符号データを接合し、ハードディスク等に保存することになる（階層数が削減されることになる）
なお、保存する際には、変換前のファイルに上書きしても良いが、予め設定されたフォルダ（ディレクトリ）に保存するようにしても構わない。
これらの処理を行うことにより、図６内の符号データ６０８を符号データ６０９に変換したことになる。すなわち６０２，６０３，６０４の３つの階層の符号データを６０４−１という１つの階層の符号データにまとめ、符号データ内の階層数を削減すると同時に、最低解像度の画像データの画像サイズを上げることができる。
このように階層数を削減することにより、アプリケーションが必要とする最低解像度の画像データに符号データを合わせることにより、次回、ＪＰＥＧ２０００で符号化されている符号データのデコードの時間を短縮することができる。例えば、本実施形態の場合、５１２×５１２画素の画像データをデコードする場合、旧符号データであれば、４種類の階層（６４×６４、１２８×１２８、２５６×２５６、５１２×５１２）をデコードする必要があるが、新符号データの場合は、２種類（２５６×２５６、５１２×５１２）で済むため、デコードのループ回数を削減することができる。
また新しい最低解像度の画像データをデコードするという処理は、アプリケーションで表示する最低解像度の画像データを表示する時に行う処理であるため、特別なデコード処理ではない。よってこの最低解像度の画像データをＬＬサブバンドで再符号化することだけが追加される処理であるが、ＬＬサブバンドでの再符号は、実際のＤＷＴのフィルタリング処理を伴わず、ＥＢＣＯＴによる符号化処理のみであるため、大変高速に処理することができる。
ここまでの実施形態では元々の符号データがタイルに分割されていない場合を説明してきたが、タイル分割されている場合でも処理は同じである。さらにタイル分割されている方が、本実施形態の効果は多きい。すなわち高解像度の画像データを表示する再には、１つのウィンドウ内にその解像度で全体像を１度に表示できないため、画像の一部分のみを表示し、その後、ユーザの操作などで画像をスクロールさせて画像全体を表示することが多い。この場合、タイルに分割されている符号データの場合は、タイル毎にスクロール表示に従ってデコードを繰り返す必要がある。この時、解像度の階層数が少ない方がデコード処理を高速に行える。
なお、上記実施形態では、オリジナルの符号化画像データを再構成する最低解像度（ＬＬ成分）を、画像表示ウインドウのサイズに合わせる例を説明したが、利用者がどの解像度にするかをキーボードから入力したり、或いは、可能なサイズ（解像度）一覧を表示してポインティングデバイスでその中の所望とするものを選択することで決定しても構わない。
＜第２の実施形態＞
上記第１の実施形態では、符号データが自分のコンピュータから直接参照できる位置にある場合を説明したが、本実施例では、サーバ/クライアントシステムの場合でかつ、通信プロトコルにはJPIPを使用し、サーバ側で符号データを変換する場合を説明する。
ＪＰＩＰ／ＪＰＥＧ２０００の符号化データを使えば、ユーザはサーバにある全ての画像データを取得せず、必要な部分のデータのみをサーバから受信することが可能である。ユーザの受信データの単位としては、ＪＰＥＧ２０００のpacket、あるいはpacketよりも大きい符号化単位であるタイル単位が考えられる。ここでは、ユーザがサーバから受信するデータ単位としてpacket単位を想定する。
Packet単位のリクエストおよびレスポンスの概念図を図９に示す。クライアントＰＣ９０１はサーバ９０２に画像のタイル番号とresolution levelとlayer、component、position番号を指定して、データを要求する。サーバ９０２は、画像９０３のコードストリームを解析して、指定されたタイル番号、resolution levelとlayer、component、position番号に相当するpacketデータを抜き出し、クライアントＰＣ９０１に送り返す。
次に、ＪＰＩＰを使ってpacketデータを送信単位として、データを送受信する場合のレスポンスデータの構成を図１０および図１１を使って説明する。
ＪＰＩＰでは、図１０の符号１００１に示すように、precinct data-binと呼ばれるＪＰＥＧ２０００のpacketデータの塊を基本としてレスポンスデータを作成する。precinct data-binとは、Tile tnの中のprecinct pnのresolution level rn、 component番号cnを構成する全てのlayerのpacketを、layer番号が昇順になるように並べてつなげたデータの塊である。
図１０に示すprecinct data-binから抜き出したPacket(tn, rn, cn, pn, 1)を使って、作成されたJPIP response dataの例を図１１に示す。
JPIP response dataは、message header１１０１と message body １１０３から構成される。message body １１０３には、precinct data-bin １００１から切り出されたＪＰＥＧ２０００の符号化データが入る。つまり、図１０のPacket(tn, rn, cn, pn, 1) １００３を抜き出してJPIP response dataを作成すると、Packet(tn, rn, cn, pn, 1) １００３がmessage body １１０３に入る。message header １１０１は、４つのパラメータからできている。１番最初のパラメータは、message body １１０３に入っているデータがprecinct data-binであることを示す識別子である。２番目のパラメータには、precinct data-bin ID(PrID)が入る。これは、タイル番号tn, resolution level番号rn, component番号cn, precinct番号 pnから一意に決まり、次式で求めることができる。
PrID(tn, rn, cn, pn)=tn+(cn+s×(component数))×tile数
ただし、
s = pn + tn×(resolution level rnにおける1 tileあたりのprecinct数)
+(resolution level 0から(rn-1)までのタイル trのprecinct数の総和)
である。
3番目のパラメータは、レスポンスデータのprecinct data-binにおけるオフセット値PrOffset １００２である。つまり、message body １１０３に入っているデータは、PrID(tn, rn, cn, pn)のprecinct data-bin １００１において何Byte目からのデータであるのかを示す値であり、図１０の符号１００２の値と同じである。message header １１０１の最後のパラメータは、response dataつまり、message body １１０３のバイト長である。つまり、ResLen １１０２には、ResLen[byte] １１０４の値が入る。
本第２の実施形態では、第１の実施形態と同様の符号データがサーバに格納されているものとする。
以下図１２などを用いて、本第２の実施形態の詳細な説明をする。またクライアントは、図５で示す画像表示ウインドウ５０１に画像を表示するための要求を出したところから説明を行う。
すなわちクライアントから、例えば、
http://www.image.com/jpip.cgi?target=d.jp2&fsiz=256,256&type=jpp-stream
いうリクエストをサーバ９０２に発行したとする。ここで、サーバ９０２のアドレスは、「www.image.com」となる。
この場合のサーバでの処理を図１２を用いて説明する。まずステップＳ１２０１で上記のリクエストを受信する。なおこのリクエスト文字列は、“target”によりサーバに格納されているファイル名を指定し、“fsiz”により画像全体の大きさを指定し、“type”により送信データ形式を指定している。
ステップＳ１２０２では前記ステップＳ１２０１で受信したリクエスト文字列を解析する。これにより要求されているファイル名、返送データの形式、返信する画像データのサイズなどの条件を取得することができる。すなわち本第２の実施形態の場合は、ファイル名“d.jp2”という画像ファイルを、画像全体が２５６×２５６画素に収まるサイズになるように要求しており、またその返送形式は、ＪＰＩＰのprecinct data-binである。ステップＳ１２０３では、この条件に当てはまるようにレスポンスデータを生成する部分である。ステップＳ１２０４は、ステップＳ１２０３で生成したレスポンスデータをクライアントに返送する。
上記ステップＳ１２０３の詳細を図１３のフローチャートに従って説明する。このフローは、第１の実施形態で説明した部分と大半が同じあるため、同一の処理には同一の番号を付けている。
まずステップＳ１３０１で今回の要求が、要求するファイルに対して１回目の要求かどうかを判断する。この判断方法は、ＪＰＩＰの通信をステートフルで行う場合は、１回目か否かはその要求のフローの中で簡単に判断できる。一方ステートレスの場合は、サーバのログ情報などを利用することで判断することができる。このような方法を用いて判断する。
このステップ１３０１で２回目以降の要求の場合はステップＳ１３０３へ、１回目の要求の場合は、ステップＳ７０１に進み、返信する画像データを構成するタイル数を計算する。この計算結果からステップＳ１３０２で今回要求されている画像データが画像全域を要求しているかどうかを判断する。ここで画像の一部分の要求であれば、ステップＳ１３０３に進む。
一方、画像全域の場合は、ステップＳ７０２に進む。ここからは、第１の実施形態と同じであり、違いは第１の実施形態であったステップＳ７０５が無くなっていることである。そのため詳細な説明は割愛する。一方ステップＳ１３０３は、通常の返信データの作成であり、要求された画像の符号データを返信するために作成すればよい。
以上説明したように、本第２の実施形態によると、クライアントから１回目の要求で、図１４のＬＬ(NL=0)’に示す部分の符号データをクライアントに返送する。これ以降の階層の符号データの要求に対するサーバの処理に関しては、通常の場合と同じであるため、説明は割愛する。またクライアント側で受信した符号データをキャッシュする必要があるが、この場合は、この１回目の要求でサーバから返送される符号データを元にキャッシュすれば、これまでどおりのキャッシュ方法で実現できる。
これにより、クライアントから１回目の要求で、画像全域を要求するリクエストが来た場合、そのコマンドから、要求を発行したクライアント側のアプリケーションで必要な最低解像度の画像サイズを判断し、その画像サイズを返信する符号データの最低解像度になるように符号データを変換してクライアントに返信することで、返信する符号データのバイト数を削減することができ、ネットワーク上でのトラフィックを下げることができる。更には、受信したクライアントでも第１の実施形態で説明したように、このリクエスト以降のデコード時間を短縮することが可能となる。またＪＰＩＰを利用する場合は、クライアント側で受信した符号データをキャッシュしなければならないが、階層数が削減されるために、キャッシュしなければならないデータ量も削減することができる。
＜第３の実施形態＞
上記第２の実施形態では、クライアントから発行されるリクエスト文字列からサーバ側で、クライアント側のアプリケーションが必要とする最低解像度の画像サイズを推測する場合を説明したが、これにこれに限るものではなく、例えば、サーバとクライアントで画像データを通信する前に、ネゴシエーションする仕組みを付加して、双方で取り決めを行い、その後その結果を基にリクエスト発行、データの返送を行ってもよい。このネゴシエーションは、ＪＰＩＰの“vendor capability”として定義して行うことが可能である。
また、これまでの実施形態では、アプリケーションが必要とする最低解像度の画像サイズと符号データの最低解像度の画像サイズが一致していたが、これに限るものではなく、一致しない場合は、アプリケーションが必要とする最低解像度の画像サイズの画像データを作成するために必要な画像サイズを符号データの最低解像度の画像サイズにすればよいことは容易に推察できる。たとえば、アプリケーションが必要とする最低解像度の画像サイズより大きく、符号データ内の解像度の画像サイズで最低解像度の画像サイズにすればよい。
以上説明したように、本実施形態によれば、アプリケーションが使用する最低解像度の画像サイズに符号データの最低解像度を合わせることができ、デコードにかかる時間を短縮することができる。またアプリケーションは、最初に画像を表示する画像サイズから拡大表示する場合など、符号データ内のどの階層符号データをデコードすればよいかも簡単に判断することができる。
またこの符号変換処理は、画像サイズの小さい画像データを対象に行うため、高速に変換できる。さらにはこの変換処理には、ＤＷＴ（Discrete Wavelet Transform）のＬＬサブバンドデータへの変換であるため、再エンコード時においても、ＤＷＴ処理を行うことなく、符号化処理だけを行えばよい。
更には、符号データをサーバに要求するような場合は、JPIPの仕組みを利用し、サーバがリクエスト文字列を判断することにより、サーバで自動的に判断することも可能である。このためクライアントはサーバで管理されている符号データのエンコード・オプションを意識することなく、アプリケーションが設定する最低解像度の画像データを簡単に入手することができ、さらには階層数を削減することで、サーバから返送する符号の通信量まで削減できる。
あるいは、サーバとクライアント間で画像データの通信の前に、ネゴシエーションすることも可能であり、これを行うことでより正確に双方の状態などを知らせることが可能となる。さらにはこのネゴシエーションには、JPIPの“vendor capability”として実装も可能であり、JPIPの仕組みの範囲内での実装が可能である。
なお、上記実施形態から明らかなように本発明は、コンピュータで実行するコンピュータプログラムがその主要部にあるわけであるから、当然、そのようなコンピュータプログラムは本発明の範疇に入る。また、通常、コンピュータプログラムはＣＤ−ＲＯＭ等のコンピュータ可読記憶媒体に格納されていて、それをコンピュータにセットしてシステムにコピーもしくはインストールすることで実行可能になるわけであるから、当然そのようなコンピュータ可読記憶媒体も本発明の範疇に入る。
実施形態におけるネットワーク構成を示す図である。 実施形態におけるクライアントＰＣのブロック構成図である。 ＪＰＥＧ２０００の符号化データの構造を示す図である。 ウェーブレット変換によるタイルとサブバンドの概念図である。 実施形態におけるアプリケーションプログラムを実行した際の表示ウインドウを示す図である。 実施形態におけるオリジナル符号化データと符号変換後の符号化データの関係を示す図である。 実施形態における符号変換の処理手順を示すフローチャートである。 符号変換の詳細を示すフローチャートである。 ＪＰＩＰPのプロトコルの概念図である。 Precinct data-binの概念図である。 JPIPレスポンスデータの概念図である。 第２の実施形態における符号変換の処理手順を示すフローチャートである。 第２の実施形態における符号変換の詳細フローチャートである。 符号変換処理におけるサブバンドの概念図である。

Claims (8)

  1. 画像を構成する各タイルについて低解像度から高解像度の画像を段階的に生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置であって、
    出力しようとする画像の出力解像度を判定する判定手段と、
    該判定手段で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定された位置までの符号化データを用いて復号し、出力用画像データを生成する復号手段と、
    該復号手段で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号手段で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化手段と
    を備えることを特徴とする画像処理装置。
  2. 前記再符号化手段は、変換対象の画像符号化データの符号化条件が記述されているヘッダ部を、変換後の符号化条件で書換える手段を含むことを特徴とする請求項１に記載の画像処理装置。
  3. 前記判定手段は、所定の通信手段を介してネットワーク上のクライアント端末から受ける要求情報に含まれる出力解像度を判定し、
    更に、前記再符号化手段で再符号化された画像符号化データを前記通信手段を介して要求元のクライアントＰＣに送信する手段を備えることを特徴とする請求項１に記載の画像処理装置。
  4. 前記クライアント端末との通信は、ＪＰＩＰを用いることを特徴とする請求項３に記載の画像処理装置。
  5. 更に、変換対象となる画像符号化データのファイル一覧を表示する一覧ウインドウと、選択された画像符号化データの復号した画像を表示する画像表示ウインドウとを表示する表示制御手段を備え、
    前記判定手段は、前記画像表示ウインドウのサイズに基づいて出力解像度を判定することを特徴とする請求項１に記載の画像処理装置。
  6. 画像を構成する各タイルについて低解像度から高解像度の画像を段階的に生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置の制御方法であって、
    出力しようとする画像の出力解像度を判定する判定工程と、
    該判定工程で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定された位置までの符号化データを用いて復号し、出力用画像データを生成する復号工程と、
    該復号工程で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号工程で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化工程と
    を備えることを特徴とする画像処理装置の制御方法。
  7. コンピュータが読込み実行することで、前記コンピュータを、画像を構成する各タイルについて低解像度から高解像度の画像を段階的に生成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置として機能させるコンピュータプログラムであって、
    出力しようとする画像の出力解像度を判定する判定手段と、
    該判定手段で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定された位置までの符号化データを用いて復号し、出力用画像データを生成する復号手段と、
    該復号手段で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号手段で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化手段
    として機能させることを特徴とするコンピュータプログラム。
  8. 請求項７に記載のコンピュータプログラムを格納したことを特徴とするコンピュータ可読記憶媒体。
JP2004324076A 2004-11-08 2004-11-08 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体 Expired - Fee Related JP4371982B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004324076A JP4371982B2 (ja) 2004-11-08 2004-11-08 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体
US11/266,298 US7558430B2 (en) 2004-11-08 2005-11-04 Apparatus method and computer-readable medium for processing hierarchical encoded image data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004324076A JP4371982B2 (ja) 2004-11-08 2004-11-08 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体

Publications (3)

Publication Number Publication Date
JP2006135792A JP2006135792A (ja) 2006-05-25
JP2006135792A5 JP2006135792A5 (ja) 2009-09-10
JP4371982B2 true JP4371982B2 (ja) 2009-11-25

Family

ID=36315965

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004324076A Expired - Fee Related JP4371982B2 (ja) 2004-11-08 2004-11-08 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体

Country Status (2)

Country Link
US (1) US7558430B2 (ja)
JP (1) JP4371982B2 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4371982B2 (ja) * 2004-11-08 2009-11-25 キヤノン株式会社 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体
JP4716949B2 (ja) * 2005-09-02 2011-07-06 株式会社リコー 画像処理装置および画像処理方法
JP5162103B2 (ja) 2006-05-15 2013-03-13 トヨタ自動車株式会社 支援制御装置
JP5326234B2 (ja) * 2007-07-13 2013-10-30 ソニー株式会社 画像送信装置、画像送信方法および画像送信システム
JP5141886B2 (ja) * 2008-02-28 2013-02-13 株式会社リコー 画像処理装置、画像処理方法、プログラム及び記録媒体
JP2011139276A (ja) * 2009-12-28 2011-07-14 Sony Computer Entertainment Inc 画像処理装置および画像処理方法
JP4848462B2 (ja) * 2010-03-04 2011-12-28 株式会社モルフォ 圧縮画像の部分伸長方法および画像処理装置
EP3334161B1 (en) * 2010-09-13 2019-08-21 Sony Interactive Entertainment Inc. Image processing device, image processing method, and data structure of moving image file
US9647835B2 (en) * 2011-12-16 2017-05-09 Akamai Technologies, Inc. Terminating SSL connections without locally-accessible private keys
CN111859210B (zh) * 2019-04-29 2024-04-26 百度在线网络技术（北京）有限公司 图像处理方法、装置、设备及存储介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3139831B2 (ja) * 1992-05-27 2001-03-05 キヤノン株式会社 画像編集方法及び装置
JPH08275170A (ja) * 1995-03-30 1996-10-18 Canon Inc 画像処理装置
JP3210862B2 (ja) * 1996-06-27 2001-09-25 シャープ株式会社 画像符号化装置及び画像復号装置
JP3301340B2 (ja) * 1996-09-04 2002-07-15 ソニー株式会社 符号化装置および符号化方法、復号装置、並びに復号方法
US5838830A (en) * 1996-09-18 1998-11-17 Sharp Laboratories Of America, Inc. Vertex-based hierarchical shape representation and coding method and apparatus
JPH10257502A (ja) * 1997-03-17 1998-09-25 Matsushita Electric Ind Co Ltd 階層画像符号化方法、階層画像多重化方法、階層画像復号方法及び装置
AUPO600897A0 (en) * 1997-04-04 1997-05-01 Canon Information Systems Research Australia Pty Ltd An efficient method of image compression comprising a low resolution image in the bit stream
JP3213582B2 (ja) * 1997-05-29 2001-10-02 シャープ株式会社 画像符号化装置及び画像復号装置
JPH11155144A (ja) * 1997-08-20 1999-06-08 Canon Inc 画像処理システム及びその制御方法、画像処理装置及びその制御方法、コンピュータ可読メモリ
JPH11331618A (ja) * 1998-05-19 1999-11-30 Canon Inc 画像処理装置、画像データ配布装置、画像データ配布システム、画像データ配布方法、及び記憶媒体
JP4124910B2 (ja) * 1999-05-18 2008-07-23 キヤノン株式会社 画像データの復号化方法及びその装置
JP2002176359A (ja) * 2000-12-06 2002-06-21 Canon Inc 情報処理装置及びその制御方法、情報処理システム、コンピュータ可読メモリ
US6647149B2 (en) * 2001-01-03 2003-11-11 Electronics For Imaging, Inc. Methods and apparatus for securely transmitting and processing digital image data
US7581027B2 (en) 2001-06-27 2009-08-25 Ricoh Co., Ltd. JPEG 2000 for efficent imaging in a client/server environment
US20030067627A1 (en) * 2001-08-30 2003-04-10 Tomoe Ishikawa Image processing method and its data cache method
US7006699B2 (en) * 2002-03-27 2006-02-28 Microsoft Corporation System and method for progressively transforming and coding digital data
JP2004040674A (ja) 2002-07-08 2004-02-05 Nec Engineering Ltd Ｊｐｅｇ２０００符号データの復元方法及びｊｐｅｇ２０００符号データの復元システム
US7580577B2 (en) * 2002-12-09 2009-08-25 Canon Kabushiki Kaisha Methods, apparatus and computer products for generating JPEG2000 encoded data in a client
JP4371982B2 (ja) * 2004-11-08 2009-11-25 キヤノン株式会社 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体

Also Published As

Publication number Publication date
US20060098215A1 (en) 2006-05-11
US7558430B2 (en) 2009-07-07
JP2006135792A (ja) 2006-05-25

Similar Documents

Publication Publication Date Title
JP4709493B2 (ja) 圧縮されたディジタル画像を通信する方法及び製造物
US7558430B2 (en) Apparatus method and computer-readable medium for processing hierarchical encoded image data
JP4377103B2 (ja) サーバクライアント環境におけるｊｐｅｇ２０００のための画像処理
JP4716645B2 (ja) ドキュメントビューイング方法
JP4603947B2 (ja) 画像通信システム、サーバ装置およびその制御方法、並びにコンピュータプログラム
US7460724B2 (en) JPP-stream to JPEG 2000 codestream conversion
JP4934462B2 (ja) 部分的な書類画像にアクセスするための方法、サーバー及びコンピュータプログラム
US8209375B2 (en) Communication of compressed digital images with restricted access and server/client hand-offs
JP2007043673A (ja) アプリケーション・メタデータを用いるグラフィカル・ユーザ・インターフェースの適応ビデオ圧縮法
JP2006191159A (ja) 画像処理方法及び画像処理装置
US7721971B2 (en) Image processing system, image processing method and computer readable information recording medium
JP2004297508A (ja) Ｊｐｅｇ２０００符号化装置及び復号化装置
JP3897691B2 (ja) スクロール表示方法及び装置
KR20200106161A (ko) 이미지 프로세싱
JP2007142581A (ja) 画像処理方法、画像処理装置
JP3958198B2 (ja) 画像処理方法
JP2006339972A (ja) 画像処理装置及びその制御方法、コンピュータプログラム、記憶媒体
JP2007053444A (ja) サーバ装置及びその制御方法、コンピュータプログラム、記憶媒体
JP2007053445A (ja) サーバ装置及びその制御方法、コンピュータプログラム、記憶媒体
JP2006319482A (ja) 画像処理装置及びその制御方法、並びに、コンピュータプログラム及びコンピュータ可読記憶媒体
JP2006345452A (ja) 情報処理装置及びその制御方法、コンピュータプログラム、記憶媒体

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070718

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070718

RD03 Notification of appointment of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7423

Effective date: 20070718

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090727

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090819

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: 20090824

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: 20090901

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

Free format text: PAYMENT UNTIL: 20120911

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4371982

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: 20120911

Year of fee payment: 3

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

Free format text: PAYMENT UNTIL: 20130911

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees