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

    • 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/188Methods 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
    • 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/134Methods 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/162User input
    • 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/134Methods 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/164Feedback from the receiver or from the transmission channel
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • 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/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

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画素)程度であった解像度が、現在ではノートPCでさえ、XGA(1024x768画素)以上になり、ディスクトップPCにいたっては、SXGA(1280x1024画素), UXGA(1600x1200画素)が普及しており、更に今後はQXGA, QUXGAなどの高解像度をサポートすることは容易に推察できる。
更に、デジタルカメラなどで撮影した多数の画像データを同時に表示し、その中から選択的に1枚表示に切り替えて、ズームやスクロールなどの表示技術により、より詳細な画像データを表示するようなアプリケーションがある。この場合、同時に多数の画像データを一度に表示する場合には、高速性が重要視されるため、主画像データとは異なる予め作成されているサムネイル画像データを用いることが多い。一方そのサムネイル表示から選択された画像データの一枚表示は、主画像データを用いて、アプリケーションのウィンドウサイズあるいは、ディスプレイ装置に表示できるまでは、画像全体を表示し、それ以上の拡大表示になると、画像の一部分を表示する。
このような、1枚の画像データを表示する際に、元々の画像データの画像サイズとは異なる元々の画像データの画像サイズより小さい画像サイズを複数種類使用するようなアプリケーションの場合、必要に応じてデコード処理を行い、一旦元々の画像データの画像サイズを再現し、その後目的の画像サイズになるように、画像データを縮小することを行っていた。この場合画像データは、非圧縮かあるいはJPEG baselineのようなシーケンシャルの符号化方式で圧縮されている。
あるいは、画像データを階層符号化方式で画像圧縮しておき、表示に必要な画像サイズまでをデコードし、表示するように実装していた。階層符号化方式としては、JPEG2000が知られている。このJPEG2000は、1枚の画像データを1つ以上のタイルに分割し、その分割されたタイル毎に、1つ以上の解像度を持つ階層符号化方式として、2001年にISO/ITCで標準化された画像符号化方式である。またネットワーク上でこのJPEG2000で符号化された符号データファイルに対して断片的に必要な部分のみをアクセスする時のプロトコルとして、JEG2000 image coding system - Part 9: Interactivity tools, APIs and protocols(以下、JPIPと記す)があり、現在策定中である。
例えば、特許文献1として、サーバにJPEG2000で符号化された圧縮画像ファイルを置き、クライアントからコードストリームを部分的に要求し、バッファして格納する。格納されていない部分のみを新規にサーバに対して要求を発行し、受信した符号データと既にバッファリングしている符号データとを接合し、デコードすることを繰り返す。この時の部分的な要求の単位は、JPEG2000の符号内のパケット、タイル、コードブロックから選択される。また、バイト単位での要求も可能となっている。一方サーバは、要求された圧縮データの部分データを抜き出してクライアントに返送する。
また、特許文献2には、JPEG2000符号データのうち、サブバンド単位でサーバにデータを要求するもので且つ、デコード時で使用した係数を保持し、次に上位のサブバンドの符号データを要求した場合は、その係数に今回のデータを付加することでデコードし、デコードで使用した係数を保持することを繰り返すことにより、クライアント側で受信した符号データをバッファして格納する必要がないシステムである。これにより解像度方向のプログレッシブ表示を可能にするものである。
特開2003−023630公報 特開2004−040674公報
例えば、この特許文献2によると、画像サイズが2048×2048画素の画像データをdecomposition level =5で符号化したJPEG2000の符号化データファイル“A.jk2”があるとする。この場合、ファイル“A.j2k”は、64×64,128×128,256×256,512×512,1024×1024,2048×2048の6種類の異なる解像度の画像データを再現できる。また画像をデコード/表示するアプリケーションプログラムファイル“APP_1.exe”でサムネイル画像から選択された時に表示する画像サイズは、256×256画素相当の画像サイズを表示するとする。
このような条件では、“APP_1.exe”で選択された1枚の画像データを表示する時の処理は、64×64→ 128×128→256×256の3つの解像度の符号データをデコードして、デコードされた画像を表示することになる。すなわち、このアプリケーション“APP_1.exe”では、256×256画素以下の解像度の画像データは扱わないので、256×256画素サイズ以下の解像度の符号データがある場合は、必ず256×256画素以上の画像データをデコードするまで、デコーダをループさせなければならない。そのため、デコードに時間がかかるという問題がある。またそのアプリケーションで使用しない解像度の符号データをバッファなどで格納しなければならず、格納のための領域を余計に使用してしまうという問題点もある。さらには、JPIPでサーバに符号データを要求する場合は、通信のための時間も余計にかかるという問題もある。
更にこの特許文献2においては、デコード処理を途中で止めて、デコード処理で使用した係数を保持するため、符号データを保持する場合に比べて、保持のためのメモリを多く使用することになる。またデコーダも途中で止めたり、更には、サブバンドのデータを追加したりと、特殊なデコーダが必要になる。
また、これら特許文献1、2では、サーバに保持されているJPEG2000符号データの圧縮パラメータは変更なしで、断片的に符号データの一部分をクライアントに送信し、クライアントで受信した符号データを変換などしないでそのままデコードするため、クライアント側のアプリケーションで使わない部分の解像度の符号データまでをも処理しなければならないという問題がある。さらには解像度の階層数が、デコーダ側でサポートしている階層数を越している場合は、受信した符号データを最後までデコードできないということが生じる場合があるという問題点もある。
本発明はかかる問題点に鑑みなされたものであり、低解像度から高解像度に向けて段階的に復号するための階層符号化データ構造を有する符号化画像データを、復号する装置の表示解像度もしくは表示サイズに合わせて再構成することで、次回の復号処理に要する処理を簡略化させる技術を提供しようとするものである。
この課題を解決するため、本発明の画像処理装置は以下の構成を備える。すなわち、
画像を構成する各タイルについて低解像度から高解像度の画像を段階的に成するため、解像度別の符号化データで構成される画像符号化データを処理する画像処理装置であって、
出力しようとする画像の出力解像度を判定する判定手段と、
該判定手段で判定された出力解像度に基づき、変換対象の画像符号化データ中の復号すべき符号化データの位置を判定し、当該判定された位置までの符号化データを用いて復号し、出力用画像データを生成する復号手段と、
該復号手段で復号して得られた解像度の画像データを最低解像度として再符号化し、前記復号手段で判定された位置以降の符号化データと接合し、符号化データとして出力する再符号化手段とを備える。
本発明によれば、低解像度から高解像度に向けて段階的に復号するための階層符号化データ構造を有する符号化画像データを、復号する装置の表示解像度もしくは表示サイズに合わせて再構成することになり、次回の復号処理に要する処理を簡略化させることが可能になる。
以下、添付図面に従って、本発明にかかる実施形態を詳細に説明する。
図1は、インターネットに代表されるネットワーク上に複数のコンピュータが接続されている様子を示した図である。同図において、100はインターネットに代表されるネットワーク、101はサーバ・コンピュータであり、例えば画像データを送信するためのJPEG2000用の通信プロトコルであるJPIPサーバをはじめ、WWWサーバ機能に必要なソフトウエアが実行される。また104は大容量の画像データを格納するストレージ装置(実施形態ではHD)であり、JPEG2000符号化方式で符号化された圧縮画像データが多数保存されている。102及び103はクライアント・コンピュータ(以下、クライアントPC)であり、WebブラウザをはじめWebの各ページを表示するために必要なクライアント・ソフトウエアと、JPEG2000符号化データをデコード/表示するためのクライアント・ソフトウエアならびに、JPIPのクライアント機能を実装したソフトウエアなどが実行される。
図2は、図1においてクライアントPCのブロック構成図である。図中、201は、システム全体の制御などを行っているCPUである。202はキーボードで、202aはマウス(登録商標)等のポインティングデバイスと共にシステムに情報などを入力するために使用される。203は表示部で、CRTTや液晶ディスプレイなどで構成されている。204はROM、205はRAMで、システムの記憶装置を構成し、システムが実行するプログラムやシステムが利用するデータを記憶する。206はハードディスク装置であり、OS、各クライアントソフトウェアを格納しており、各種データファイルを記憶するものである。207はフロッピー(登録商標)・ディスク装置で、システムのファイルシステムに使用される外部記憶装置を構成している。208はプリンタインタフェースである。209はネットワークインタフェースであり、ここからインターネットなどのネットワーク上に接続されているサーバ・コンピュータなどのネットワーク上の資源にアクセスする。また、図1におけるサーバ・コンピュータ101も基本的には図2で示した構成を持つものであるが、ハードディスクに格納されているOS、アプリケーションはサーバとして機能するものとなる点で異なる。
次に図3を用いて一般的なJPEG2000符号化データの構造を説明する。図示は、Resolution level-Layer-Component-Position progression(以下Resolution Progressionと記す)の符号化オプションで符号化されたJPEG2000符号データの例である。
Resolution Progressionに準じた場合、resolution/layer/component/positionの順に符号データが記録される。その他にもSNR Progressionなどの符号順が選択可能であるが、これら符号データの並び順をprogression orderと呼ぶ。本実施形態では、説明を簡単にするため、Resolution Progressionとして説明する。
次に図4を用いてウェーブレット変換による解像度とサブバンドの関係を説明する。同図では、decomposition level = 4の場合を説明している。まずはLL(NL=1)のみでresolution level = 0の解像度の画像となる。そして、LLの画像とHL(NL=1), LH(NL=1), HH(NL=1)の3つのサブバンドをデコードすることでlevel=1の解像度の画像が生成可能になる。そして、NL=1の解像度の画像とNL=2のサブバンドでlevel=2の解像度の画像が生成可能になる。NL=2の解像度の画像とNL=3のサブバンドでlevel=3の解像度の画像が生成可能になる。そして、NL=3の解像度の画像とNL=4のサブバンドでlevel =4の解像度の画像が生成可能、というように計5種類の解像度の画像データを再現できる。このようにresolution level番号が1つずつ増加する毎に再現される画像データの画像サイズ(水平、垂直方向の画素数)は、幅、高さ共に2倍になっていく。図3で示したResolution Progressionの場合は、1つのresolution levelの符号データは、layer番号が小さい順で、component番号が小さい順に、position番号が小さい順になるように並べられている。ここでのlayer番号は復元しる画像の原画に対するS/N比に対応し、layer番号が小さいほどS/N比が悪い画像データを再現することになる。
さらにJPEG2000符号データファイル内でのresolution番号、layer番号、component番号の各最大値は、エンコード時のエンコード・パラメータによって予め設定され、そのパラメータにしたがってエンコード処理されており、その各パラメタが符号化データの中にヘッダ情報として格納されている。また符号データにおける論理的な最小単位であるパケットは、各パケットに格納されている全code-blockの情報を管理しているpacket header部と、そのpacketを構成する全code-blockの符号データであるpacket dataから構成されている。
本第1の実施形態では、ローカル、つまり、クライアントPCのハードディスク等に格納されたJPEG2000形式のファイルのデコード方法について説明する。本実施形態におけるサンプル・アプリケーションは、ローカルに格納されているファイル一覧をそれぞれのサムネイル画像(先頭フレーム)を表示ウィンドウに表示し、その所望とするファイルを1枚の表示ウィンドウに表示することを想定する。
ここでサムネイル表示ウィンドウ内に表示する1枚の画像サイズは64×64画素固定で、1枚表示ウィンドウのウィンドウサイズは256×256画素の画像データが表示できるサイズとし、この1枚表示ウィンドウは、この最初に表示される画像サイズを最低解像度サイズとして、それ以上の解像度の画像データをユーザの指示に従って、拡大、縮小、スクロールなどの処理を行うことを想定する。
またローカルにある画像ファイルは、全て画像サイズが1024×1024画素サイズであり、それらの画像データを”decomposition level = 4”, “Resolution Progression”でJPEG2000符号化方式を用いて符号化しているとする。すなわち最低解像度が64×64画素サイズであり、次が128×128画素サイズ、その次が256×256画素サイズ、512×512画素サイズと続き、最後の最大解像度の画像サイズが1024×1024画素サイズの5種類の解像度を持つ階層符号化で符号化されている。
よって本実施形態の場合、1枚表示用ウィンドウは、256×256画素サイズ、512×512画素サイズ、1024×1024画素サイズの3種類の画像サイズの画像データを表示するものである。ただし、512×512、1024×1024の画素サイズは、表示可能サイズ256×256画素サイズを超えるので、その一部を表示することになる。
図5では、上記サンプル・アプリケーションでの画像表示の例を示している。図中、500は、サムネイル表示用ウィンドウであり、64×64画素サイズの画像データファイル“A”, ”B”, “C”, “D”, “E”, “F”の6枚を表示しているところを表している。なお、表示している画像ファイルが6個を超える場合には、スクロールバーを表示して、それ以外のファイルを表示する。ユーザは、ポインティングデバイス202aなどで、例えば画像“D”が選択すると、該当する画像ファイル“D”を選択し、一枚表示の画像表示ウィンドウ501に256×256画素サイズの画像データをデフォルトとして図示のように表示する。
図6は、JPEG2000で符号化された6枚の画像それぞれの符号データを示している。図示において、600は、“Start of codestream”であり、符号データの始まりを示すマーカ・コードである。601は、エンコード・パラメータを格納しているメインヘッダである。例えば画像サイズが1024×1024画素サイズであり、”decomposition level = 4”とか, “Resolution Progression”で符号データが格納されていることをしめす。602から606までは、“Resolution Progression”で格納された各resolutionの符号データである。607は“End of codestream”であり、符号データの終りを示すマーカ・コードである。
画像サイズが1024×1024である場合、resolution level = 0で示される領域602には、64×64画素サイズの画像データをデコードするための符号データが格納されている。すなわち、図4で示すLL(NL=0)部分の符号化データである。
resolution level =1で示される領域603には、128×128画素サイズの画像データをデコードするための符号データが格納される。つまり、図4のHL(NL=1),LH(NL=1),HH(NL=1)で示す部分の符号データである。
resolution level =2で示される領域604には、256×256画素サイズの画像データをデコードするための符号データであり、図4のHL(NL=2), LH(NL=2), HH(NL=2)の部分に相当する符号データである。
resolution level =3で示される領域605には、512×512画素サイズの画像データをデコードするための符号データが格納される。図4のHL(NL=3),LH(NL=3),HH(NL=3)の部分の符号データでもある。
最後の、esolution level =4で示される領域には、1024×1024画素の画像データをデコードするための符号データが格納される。図4のHL(NL=4),LH(NL=4),HH(NL=4)で示すサブバンド部分の符号データである。
よって本実施形態の場合、図5のたサムネイル表示用ウィンドウ500には、各画像データファイルにおける、図6で示したJPEG2000の符号データの内のresolution level = 0の領域までの符号データをデコードして得られた画像データを表示していることになる。このJPEG2000のデータのデコード処理そのものは本発明の主眼ではないので説明を割愛する。
では次に図5で示すサムネイル表示500内の“D”で示している画像をユーザが指定し、その画像を画像表示ウインドウ501に表示する処理について説明する。
実施形態の場合、画像表示ウインドウ501は256×256画素の画像を表示可能なので、画像ファイルが選択されたデフォルト状態では、図6で示すJPEG2000の符号データのうち、符号604で示すresolution level = 2の領域までの符号データをデコードし、表示することになる。このデコード処理も前記サムネイル表示用のウィンドウで表示するためのデコード処理と同様であるので説明は要しないであろう。
ここで、この画像表示ウインドウ501に表示する画像データは、この256×256画素の画像サイズの画像データを最低解像度の画像データとして、これ以下の画像サイズの画像を表示する時は、256×256画素の画像データを縮小して表示するものとし、さらには、拡大表示する場合は、上の解像度の符号データをデコードして表示する。この時、高解像度の画像データは、画像表示ウインドウ501のサイズを超えてしまうため、画像の一部を表示して、残りの部分はスクロールなどの処理により、表示するものとする。
あるいは、表示ウィンドウサイズよりデコードして得られる画像データの画像サイズが大きい場合に、符号データがタイルに分割されている場合は、表示される部分のみのタイルをデコードし、スクロールなどで新規に必要になった部分のタイルをデコードしても良い。
では、decomposition levelを下げる処理を図7(a)、(b)、図8(a),(b)を用いて説明する。
説明を簡単にするため、画像“D”の符号データがタイル分割されていない場合(つまり、画像全体が1タイルの場合)で説明する。
まずステップS701で符号データのタイル数を取得する。今回の場合は、1である。次にステップS702ではデコードする階層数を計算する。今回の場合は、取得したい画像データの画像サイズが256×256画素であるので、階層数「2」の符号データまでをデコードすれば目的の画像サイズの画像を得ることができる。そのため、ステップS702で取得する階層数は「2」となる。
ステップS703では、実際の各タイルの1階層分のデコードを行う部分である。このデコード処理は、必ず最低解像度からデコードを行うことを想定しているので、ステップS703では、1回目のコールのときに、階層番号として「0」を設定する。この階層番号は、ステップS703を処理する毎に、1インクリメントされる。ステップS704では、目的の階層数デコードしたかを判断する部分であり、ステップS703で設定する階層番号と、ステップS702で設定した階層数の値を比較する。目的の階層までデコードまでステップS703を繰り返す。今回の場合は、ステップS703を3回ループすることにより目的の階層までをデコードしたことになる。
ステップS705では、デコードして得られた画像データを表示用の画像データに変換する部分である。
このステップS705の詳細は、図7(b)に示す通りで、ステップS705−1で、今回デコードしたタイルのタイル番号から、表示画像データの空間的な位置を特定する。ステップS705−2で、ステップS705−1で特定された位置に対して、画像データをコピーするなどの処理を行い、表示用の画像データの形式に変換して、ステップS705の処理を終了する。
次にステップS706で、階層数を削減するための、最低解像度用のLLサブバンドデータに変換する。ステップS707では、全てのタイルに対して上記の処理を行ったの判断であり、全タイルを処理するまで、ステップS702からステップS707までを繰り返す。実施形態では、タイルが1つの例を説明しているので、ステップS707からステップS702に戻ることはなく、次のステップS708に進む。勿論、原画像が複数のタイルに分割されている場合には、ステップS702に戻ることになる。ステップS708では、ステップS706で変換された符号データを1つの符号データに変換し、新しい符号データを生成する部分である。
次に、上記ステップS706及びステップS708の詳細を図8(a),(b)のフローチャートに従って説明する。まずステップS706の符号変換を図8(a)のフローチャートに従って説明する。
ますステップS801において、今回デコードしたタイルの符号化オプションを取得する。具体的には、符号データのMainHeaderとTilePartHeaderの中に入っているCOD,COC、QCD,QCCなどのマーカ・コードを検索し、エンコード時の符号化オプションを取得する。
次いで、ステップS802では、ステップS801で取得した符号化オプションの特にLLサブバンド部分の符号化オプションにしたがって、先に説明したステップS703、704でデコードした画像データをEBCOT(Embedded Bitplane COding by Truncation)を用いてLL成分として再符号化する。ステップS803では、ステップS802で符号化して出力された符号データを取得し、ステップS804において、旧符号データの階層番号0から階層番号2までの符号データをステップS803で取得した符号データで置き変える。
次にステップS708の新符号データ作成の処理を図8(b)のフローチャートにしたがい説明する。
まずステップS805において、旧符号データのMainHeaderを取得し、ステップS806で階層数を減らしたことを符号データに反映させるため、旧符号データでは、CODマーカ・コード内の“Number of decomposition level”フィールド が「4」となっているところを、「2」に変える。これにより、最低解像度の画像サイズを64×64画素から256×256画素に変更したことになる。次にステップS807において、新MainHeaderとステップS804で作成した各タイルの新しい符号データ接合し、新しい1つの符号データを生成する。
サブバンドの具体例は、図4に示すサブバンドのLL(NL=0),HL(NL=1),LH(NL=1),HH(NL=1),HL(NL=2),LH(NL=2),HH(NL=2)で示す7つのサブバンドの符号データをデコードし、それを図14に示すようにLL(NL=0)’に変換し、その他のHL(NL=3)〜HH(NL=4)は無変換で、符号データを接合し、ハードディスク等に保存することになる(階層数が削減されることになる)
なお、保存する際には、変換前のファイルに上書きしても良いが、予め設定されたフォルダ(ディレクトリ)に保存するようにしても構わない。
これらの処理を行うことにより、図6内の符号データ608を符号データ609に変換したことになる。すなわち602,603,604の3つの階層の符号データを604−1という1つの階層の符号データにまとめ、符号データ内の階層数を削減すると同時に、最低解像度の画像データの画像サイズを上げることができる。
このように階層数を削減することにより、アプリケーションが必要とする最低解像度の画像データに符号データを合わせることにより、次回、JPEG2000で符号化されている符号データのデコードの時間を短縮することができる。例えば、本実施形態の場合、512×512画素の画像データをデコードする場合、旧符号データであれば、4種類の階層(64×64、128×128、256×256、512×512)をデコードする必要があるが、新符号データの場合は、2種類(256×256、512×512)で済むため、デコードのループ回数を削減することができる。
また新しい最低解像度の画像データをデコードするという処理は、アプリケーションで表示する最低解像度の画像データを表示する時に行う処理であるため、特別なデコード処理ではない。よってこの最低解像度の画像データをLLサブバンドで再符号化することだけが追加される処理であるが、LLサブバンドでの再符号は、実際のDWTのフィルタリング処理を伴わず、EBCOTによる符号化処理のみであるため、大変高速に処理することができる。
ここまでの実施形態では元々の符号データがタイルに分割されていない場合を説明してきたが、タイル分割されている場合でも処理は同じである。さらにタイル分割されている方が、本実施形態の効果は多きい。すなわち高解像度の画像データを表示する再には、1つのウィンドウ内にその解像度で全体像を1度に表示できないため、画像の一部分のみを表示し、その後、ユーザの操作などで画像をスクロールさせて画像全体を表示することが多い。この場合、タイルに分割されている符号データの場合は、タイル毎にスクロール表示に従ってデコードを繰り返す必要がある。この時、解像度の階層数が少ない方がデコード処理を高速に行える。
なお、上記実施形態では、オリジナルの符号化画像データを再構成する最低解像度(LL成分)を、画像表示ウインドウのサイズに合わせる例を説明したが、利用者がどの解像度にするかをキーボードから入力したり、或いは、可能なサイズ(解像度)一覧を表示してポインティングデバイスでその中の所望とするものを選択することで決定しても構わない。
<第2の実施形態>
上記第1の実施形態では、符号データが自分のコンピュータから直接参照できる位置にある場合を説明したが、本実施例では、サーバ/クライアントシステムの場合でかつ、通信プロトコルにはJPIPを使用し、サーバ側で符号データを変換する場合を説明する。
JPIP/JPEG2000の符号化データを使えば、ユーザはサーバにある全ての画像データを取得せず、必要な部分のデータのみをサーバから受信することが可能である。ユーザの受信データの単位としては、JPEG2000のpacket、あるいはpacketよりも大きい符号化単位であるタイル単位が考えられる。ここでは、ユーザがサーバから受信するデータ単位としてpacket単位を想定する。
Packet単位のリクエストおよびレスポンスの概念図を図9に示す。クライアントPC901はサーバ902に画像のタイル番号とresolution levelとlayer、component、position番号を指定して、データを要求する。サーバ902は、画像903のコードストリームを解析して、指定されたタイル番号、resolution levelとlayer、component、position番号に相当するpacketデータを抜き出し、クライアントPC901に送り返す。
次に、JPIPを使ってpacketデータを送信単位として、データを送受信する場合のレスポンスデータの構成を図10および図11を使って説明する。
JPIPでは、図10の符号1001に示すように、precinct data-binと呼ばれるJPEG2000のpacketデータの塊を基本としてレスポンスデータを作成する。precinct data-binとは、Tile tnの中のprecinct pnのresolution level rn、 component番号cnを構成する全てのlayerのpacketを、layer番号が昇順になるように並べてつなげたデータの塊である。
図10に示すprecinct data-binから抜き出したPacket(tn, rn, cn, pn, 1)を使って、作成されたJPIP response dataの例を図11に示す。
JPIP response dataは、message header1101と message body 1103から構成される。message body 1103には、precinct data-bin 1001から切り出されたJPEG2000の符号化データが入る。つまり、図10のPacket(tn, rn, cn, pn, 1) 1003を抜き出してJPIP response dataを作成すると、Packet(tn, rn, cn, pn, 1) 1003がmessage body 1103に入る。message header 1101は、4つのパラメータからできている。1番最初のパラメータは、message body 1103に入っているデータがprecinct data-binであることを示す識別子である。2番目のパラメータには、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 1002である。つまり、message body 1103に入っているデータは、PrID(tn, rn, cn, pn)のprecinct data-bin 1001において何Byte目からのデータであるのかを示す値であり、図10の符号1002の値と同じである。message header 1101の最後のパラメータは、response dataつまり、message body 1103のバイト長である。つまり、ResLen 1102には、ResLen[byte] 1104の値が入る。
本第2の実施形態では、第1の実施形態と同様の符号データがサーバに格納されているものとする。
以下図12などを用いて、本第2の実施形態の詳細な説明をする。またクライアントは、図5で示す画像表示ウインドウ501に画像を表示するための要求を出したところから説明を行う。
すなわちクライアントから、例えば、
http://www.image.com/jpip.cgi?target=d.jp2&fsiz=256,256&type=jpp-stream
いうリクエストをサーバ902に発行したとする。ここで、サーバ902のアドレスは、「www.image.com」となる。
この場合のサーバでの処理を図12を用いて説明する。まずステップS1201で上記のリクエストを受信する。なおこのリクエスト文字列は、“target”によりサーバに格納されているファイル名を指定し、“fsiz”により画像全体の大きさを指定し、“type”により送信データ形式を指定している。
ステップS1202では前記ステップS1201で受信したリクエスト文字列を解析する。これにより要求されているファイル名、返送データの形式、返信する画像データのサイズなどの条件を取得することができる。すなわち本第2の実施形態の場合は、ファイル名“d.jp2”という画像ファイルを、画像全体が256×256画素に収まるサイズになるように要求しており、またその返送形式は、JPIPのprecinct data-binである。ステップS1203では、この条件に当てはまるようにレスポンスデータを生成する部分である。ステップS1204は、ステップS1203で生成したレスポンスデータをクライアントに返送する。
上記ステップS1203の詳細を図13のフローチャートに従って説明する。このフローは、第1の実施形態で説明した部分と大半が同じあるため、同一の処理には同一の番号を付けている。
まずステップS1301で今回の要求が、要求するファイルに対して1回目の要求かどうかを判断する。この判断方法は、JPIPの通信をステートフルで行う場合は、1回目か否かはその要求のフローの中で簡単に判断できる。一方ステートレスの場合は、サーバのログ情報などを利用することで判断することができる。このような方法を用いて判断する。
このステップ1301で2回目以降の要求の場合はステップS1303へ、1回目の要求の場合は、ステップS701に進み、返信する画像データを構成するタイル数を計算する。この計算結果からステップS1302で今回要求されている画像データが画像全域を要求しているかどうかを判断する。ここで画像の一部分の要求であれば、ステップS1303に進む。
一方、画像全域の場合は、ステップS702に進む。ここからは、第1の実施形態と同じであり、違いは第1の実施形態であったステップS705が無くなっていることである。そのため詳細な説明は割愛する。一方ステップS1303は、通常の返信データの作成であり、要求された画像の符号データを返信するために作成すればよい。
以上説明したように、本第2の実施形態によると、クライアントから1回目の要求で、図14のLL(NL=0)’に示す部分の符号データをクライアントに返送する。これ以降の階層の符号データの要求に対するサーバの処理に関しては、通常の場合と同じであるため、説明は割愛する。またクライアント側で受信した符号データをキャッシュする必要があるが、この場合は、この1回目の要求でサーバから返送される符号データを元にキャッシュすれば、これまでどおりのキャッシュ方法で実現できる。
これにより、クライアントから1回目の要求で、画像全域を要求するリクエストが来た場合、そのコマンドから、要求を発行したクライアント側のアプリケーションで必要な最低解像度の画像サイズを判断し、その画像サイズを返信する符号データの最低解像度になるように符号データを変換してクライアントに返信することで、返信する符号データのバイト数を削減することができ、ネットワーク上でのトラフィックを下げることができる。更には、受信したクライアントでも第1の実施形態で説明したように、このリクエスト以降のデコード時間を短縮することが可能となる。またJPIPを利用する場合は、クライアント側で受信した符号データをキャッシュしなければならないが、階層数が削減されるために、キャッシュしなければならないデータ量も削減することができる。
<第3の実施形態>
上記第2の実施形態では、クライアントから発行されるリクエスト文字列からサーバ側で、クライアント側のアプリケーションが必要とする最低解像度の画像サイズを推測する場合を説明したが、これにこれに限るものではなく、例えば、サーバとクライアントで画像データを通信する前に、ネゴシエーションする仕組みを付加して、双方で取り決めを行い、その後その結果を基にリクエスト発行、データの返送を行ってもよい。このネゴシエーションは、JPIPの“vendor capability”として定義して行うことが可能である。
また、これまでの実施形態では、アプリケーションが必要とする最低解像度の画像サイズと符号データの最低解像度の画像サイズが一致していたが、これに限るものではなく、一致しない場合は、アプリケーションが必要とする最低解像度の画像サイズの画像データを作成するために必要な画像サイズを符号データの最低解像度の画像サイズにすればよいことは容易に推察できる。たとえば、アプリケーションが必要とする最低解像度の画像サイズより大きく、符号データ内の解像度の画像サイズで最低解像度の画像サイズにすればよい。
以上説明したように、本実施形態によれば、アプリケーションが使用する最低解像度の画像サイズに符号データの最低解像度を合わせることができ、デコードにかかる時間を短縮することができる。またアプリケーションは、最初に画像を表示する画像サイズから拡大表示する場合など、符号データ内のどの階層符号データをデコードすればよいかも簡単に判断することができる。
またこの符号変換処理は、画像サイズの小さい画像データを対象に行うため、高速に変換できる。さらにはこの変換処理には、DWT(Discrete Wavelet Transform)のLLサブバンドデータへの変換であるため、再エンコード時においても、DWT処理を行うことなく、符号化処理だけを行えばよい。
更には、符号データをサーバに要求するような場合は、JPIPの仕組みを利用し、サーバがリクエスト文字列を判断することにより、サーバで自動的に判断することも可能である。このためクライアントはサーバで管理されている符号データのエンコード・オプションを意識することなく、アプリケーションが設定する最低解像度の画像データを簡単に入手することができ、さらには階層数を削減することで、サーバから返送する符号の通信量まで削減できる。
あるいは、サーバとクライアント間で画像データの通信の前に、ネゴシエーションすることも可能であり、これを行うことでより正確に双方の状態などを知らせることが可能となる。さらにはこのネゴシエーションには、JPIPの“vendor capability”として実装も可能であり、JPIPの仕組みの範囲内での実装が可能である。
なお、上記実施形態から明らかなように本発明は、コンピュータで実行するコンピュータプログラムがその主要部にあるわけであるから、当然、そのようなコンピュータプログラムは本発明の範疇に入る。また、通常、コンピュータプログラムはCD−ROM等のコンピュータ可読記憶媒体に格納されていて、それをコンピュータにセットしてシステムにコピーもしくはインストールすることで実行可能になるわけであるから、当然そのようなコンピュータ可読記憶媒体も本発明の範疇に入る。
実施形態におけるネットワーク構成を示す図である。 実施形態におけるクライアントPCのブロック構成図である。 JPEG2000の符号化データの構造を示す図である。 ウェーブレット変換によるタイルとサブバンドの概念図である。 実施形態におけるアプリケーションプログラムを実行した際の表示ウインドウを示す図である。 実施形態におけるオリジナル符号化データと符号変換後の符号化データの関係を示す図である。 実施形態における符号変換の処理手順を示すフローチャートである。 符号変換の詳細を示すフローチャートである。 JPIPPのプロトコルの概念図である。 Precinct data-binの概念図である。 JPIPレスポンスデータの概念図である。 第2の実施形態における符号変換の処理手順を示すフローチャートである。 第2の実施形態における符号変換の詳細フローチャートである。 符号変換処理におけるサブバンドの概念図である。

Claims (8)

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