IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ベイジン ウードン ティアンジュン インフォメーション テクノロジー カンパニー,リミテッドの特許一覧 ▶ ベイジン ジンドン センチュリー トレーディング カンパニー,リミテッドの特許一覧

特表2023-537767画像処理方法及び装置、並びにコンピュータ可読記憶媒体
<>
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図1
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図2
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図3
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図4
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図5
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図6
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図7A
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図7B
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図7C
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図8
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図9
  • 特表-画像処理方法及び装置、並びにコンピュータ可読記憶媒体 図10
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-09-05
(54)【発明の名称】画像処理方法及び装置、並びにコンピュータ可読記憶媒体
(51)【国際特許分類】
   G06T 1/00 20060101AFI20230829BHJP
【FI】
G06T1/00 200D
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2023510486
(86)(22)【出願日】2021-03-29
(85)【翻訳文提出日】2023-02-13
(86)【国際出願番号】 CN2021083678
(87)【国際公開番号】W WO2022048141
(87)【国際公開日】2022-03-10
(31)【優先権主張番号】202010902786.1
(32)【優先日】2020-09-01
(33)【優先権主張国・地域又は機関】CN
(81)【指定国・地域】
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVASCRIPT
(71)【出願人】
【識別番号】522440407
【氏名又は名称】ベイジン ウードン ティアンジュン インフォメーション テクノロジー カンパニー,リミテッド
【氏名又は名称原語表記】BEIJING WODONG TIANJUN INFORMATION TECHNOLOGY CO.,LTD.
【住所又は居所原語表記】Room A402,4/f,No.2 Building,No.18 Kechuang 11th Street,Economic And Technological Development Zone,Beijing 100176,CHINA
(71)【出願人】
【識別番号】522440670
【氏名又は名称】ベイジン ジンドン センチュリー トレーディング カンパニー,リミテッド
【氏名又は名称原語表記】BEIJING JINGDONG CENTURY TRADING CO.,LTD.
【住所又は居所原語表記】Room 201,2/F,Block C,No.18 Kechuang 11 Street,Economic And Technological Development Zone,Beijing 100176,CHINA
(74)【代理人】
【識別番号】100102842
【弁理士】
【氏名又は名称】葛和 清司
(72)【発明者】
【氏名】リ,リンセン
(72)【発明者】
【氏名】イエ,ウェンウェン
【テーマコード(参考)】
5B050
【Fターム(参考)】
5B050CA07
5B050EA09
5B050FA05
(57)【要約】
本開示の実施例は、画像処理方法及び装置、並びにコンピュータ可読記憶媒体を提供する。該方法は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップと、少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するステップであって、少なくとも1つのファイルオブジェクトは少なくとも1つのリンクパスに1対1で対応する、ステップと、少なくとも1つのピクチャーオブジェクトを作成し、少なくとも1つのピクチャーオブジェクトを少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む。本開示の実施例によって、ウェブページアプリケーションのスクリーンショットの性能を向上させることができる。
【特許請求の範囲】
【請求項1】
画像処理方法であって、
ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップと、
前記少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するステップであって、前記少なくとも1つのファイルオブジェクトは前記少なくとも1つのリンクパスに1対1で対応する、ステップと、
少なくとも1つのピクチャーオブジェクトを作成し、前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む、
画像処理方法。
【請求項2】
前記少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するステップは、
前記少なくとも1つのページ画像を少なくとも1つのバイナリラージオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトとして使用するステップと、
前記少なくとも1つのバイナリラージオブジェクトの中の各バイナリラージオブジェクトに対して、ウェブページアプリケーションスクリプトの中のオブジェクト場所パス作成方法を呼び出し、前記各バイナリラージオブジェクトのリソースアドレスをリンクパスとして作成し、これによって前記少なくとも1つのリンクパスを取得するステップと、を含む、
請求項1に記載の画像処理方法。
【請求項3】
前記少なくとも1つのピクチャーオブジェクトを作成し、前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップは、
ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも1つのピクチャーオブジェクトを作成するステップと、
各ピクチャーオブジェクトに対して、前記少なくとも1つのリンクパスの中の各リンクパスを前記各ピクチャーオブジェクトの画像ソースパスとして使用し、前記少なくとも1つのピクチャーオブジェクトを前記ウェブページアプリケーションキャッシュに保存するステップであって、前記画像ソースパスは、前記各ピクチャーオブジェクトをロードするときに、コンテンツデータを取得するパスである、ステップと、
前記セッションデータによって前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けて保存することを実現できるように、前記少なくとも1つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュのセッションデータに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む、
請求項1に記載の画像処理方法。
【請求項4】
前記現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップは、
前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックするステップと、
前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在しない場合、前記現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップと、を含む、
請求項1に記載の画像処理方法。
【請求項5】
前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックするステップの後で、前記画像処理方法はさらに、
前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在する場合、前記セッションデータから前記少なくとも1つのピクチャーオブジェクトに対応する前記少なくとも1つのリンクパスを取得し、前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む、
請求項4に記載の画像処理方法。
【請求項6】
前記現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップは、
前記現在のフルスクリーンページのロードを完成した場合、前記現在のフルスクリーンページの中の各場面に対応する画像を取得し、少なくとも1つのページ画像として使用するステップと、を含む、
請求項1ないし4のいずれか一項に記載の画像処理方法。
【請求項7】
前記ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップは、
前記現在のフルスクリーンページでスクリーンショット命令を受信した場合、前記スクリーンショット命令に応答して、前記スクリーンショット命令により指定される少なくとも1つのスクリーンショット待ち場面に対応する画像を前記少なくとも1つのページ画像として使用するステップと、を含む、
請求項1ないし4のいずれか一項に記載の画像処理方法。
【請求項8】
前記現在のフルスクリーンページのスクリーンショットを完成するステップの後で、前記画像処理方法はさらに、
前記ウェブページアプリケーションにおいて、前記少なくとも1つのピクチャーオブジェクトの中の少なくとも1つの目標ピクチャーに対するアクセス要求を受信した場合、前記少なくとも1つの目標ピクチャーオブジェクトの画像ソースパスによって、前記少なくとも1つの目標ピクチャーオブジェクトに対応する少なくとも1つの目標ファイルオブジェクトを取得するステップであって、前記目標ファイルオブジェクトのリンクパスは、前記目標ピクチャーオブジェクトの画像ソースパスと同じである、ステップと、
前記少なくとも1つの目標ファイルオブジェクトに基づいて、前記少なくとも1つの目標ピクチャーオブジェクトをロードし、これによって、前記少なくとも1つの目標ピクチャーオブジェクトに対する表示及び保存を実現するステップと、を含む、
請求項3又は5に記載の画像処理方法。
【請求項9】
前記ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップは、
現在のフルスクリーンページから少なくとも1つの場面を分割し、前記少なくとも1つの場面に対して少なくとも1つのノード識別子を設定するステップであって、前記少なくとも1つのノード識別子は、前記現在のフルスクリーンページで、前記少なくとも1つの場面に対応する少なくとも1つのデータ位置を表し、前記少なくとも1つの場面は、前記少なくとも1つのノード識別子に1対1で対応する、ステップと、
前記現在のフルスクリーンページで、少なくとも1つのスクリーンショット待ち場面に対応する少なくとも1つの目標ノード識別子を取得するステップであって、前記少なくとも1つのスクリーンショット待ち場面は、前記少なくとも1つの場面の中の目標スクリーンショット場面である、ステップと、
前記少なくとも1つの目標ノード識別子の中の各目標ノード識別子に基づいて、前記現在のフルスクリーンページのコンテンツデータから各目標ノード識別子に対応するコンテンツデータを読み出し、これによって少なくとも1つの目標ページデータを取得するステップと、
ウェブページレンダリング機能によって、前記少なくとも1つの目標ページデータに基づいて、前記少なくとも1つのページ画像を作成するステップと、を含む、
請求項1に記載の画像処理方法。
【請求項10】
前記少なくとも1つのページ画像を少なくとも1つのバイナリラージオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトとして使用するステップは、
ウェブページ描画方法の中のピクチャーからバイナリラージオブジェクトへの変換方法を呼び出し、前記少なくとも1つのページ画像から少なくとも1つのバイナリラージオブジェクトに変換することを実現し、前記少なくとも1つのファイルオブジェクトとして使用するステップと、を含む、
請求項2に記載の画像処理方法。
【請求項11】
前記少なくとも1つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュのセッションデータに保存するステップは、
セッションデータ設定方法を呼び出し、前記少なくとも1つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュに保存することを実現するステップと、を含む、
請求項3に記載の画像処理方法。
【請求項12】
前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックするステップは、
前記少なくとも1つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、前記セッションデータから前記少なくとも1つのピクチャーオブジェクトを抽出することを実行するステップと、
前記セッションデータ取得方法の呼び出しが成功した場合、前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在することを確認するステップと、
前記セッションデータ取得方法の呼び出しが失敗した場合、前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在しないことを確認するステップと、を含む、
請求項4に記載の画像処理方法。
【請求項13】
画像処理装置であって、前記画像処理装置は、取得部と、変換部と、保存部と、を含み、
前記取得部は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するように構成され、
前記変換部は、前記少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するように構成され、前記少なくとも1つのファイルオブジェクトは、前記少なくとも1つのリンクパスに1対1で対応し、
前記保存部は、少なくとも1つのピクチャーオブジェクトを作成し、前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される、画像処理装置。
【請求項14】
画像処理装置であって、前記画像処理装置は、メモリと、プロセッサと、通信バスと、を含み、
前記メモリは、前記通信バスによって前記プロセッサと通信し、前記メモリは、前記プロセッサによって実行可能な1つ又は複数のプログラムを記憶し、
前記プロセッサは、前記1つ又は複数のプログラムを実行して、請求項1ないし12のいずれか一項に記載の画像処理方法を実行する、画像処理装置。
【請求項15】
コンピュータ可読記憶媒体であって、
1つ又は複数のプロセッサに、請求項1ないし12のいずれか一項に記載の画像処理方法を実行させるための1つ又は複数のコンピュータプログラムを記憶した、コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【0001】
(関連出願への相互参照)
本願は、2020年09月01日に中国特許局に提出された、出願番号が202010902786.1であり、発明の名称が「画像処理方法及び装置、並びにコンピュータ可読記憶媒体」である中国特許出願の優先権を主張し、その内容の全てが引用により本願に組み込まれる。
本開示は、端末技術の分野に関し、特に、画像処理方法及び装置、並びにコンピュータ可読記憶媒体に関する。
【背景技術】
【0002】
現在、ユーザは、モバイル端末におけるブラウザを使用して、ハイパー・テキスト・マークアップ言語(HTML:Hyper Text Markup Language)のウェブページ全体におけるコンテンツを閲覧することができる。ウェブページ全体の中の1つ又は複数の画面のページに対して、スクリーンショットを保存する必要がある場合、現在のスクリーンショット方式は、一般的に、HTML仕様のcanvas方法によって、指定されたページのスクリーンショットを撮り、ブラウザのキャッシュで撮られたHTMLページをbase64コーディングフォーマットのピクチャーに変換し、変換されたピクチャーをモバイル端末のローカルに保存する。しかしながら、base64コーディングフォーマットのピクチャーはキャッシュ容量を多く消費し、且つ、HTMLページをbase64ピクチャーへの変換を行う場合、ウェブページ描画の中のレンダリング方法を使用する必要があり、且つ、ページが複雑になればなるほどレンダリングには時間がかかるようになる。したがって、現在のスクリーンショット方式は、ブラウザのキャッシュを大量に消費し、撮るプロセスが長く、これによってブラウザのキャッシュの性能が低下している。
【発明の概要】
【0003】
これを鑑みて、本開示の実施例は、画像処理方法及び装置、並びにコンピュータ可読記憶媒体を提供し、ウェブページアプリケーションのスクリーンショットの性能を向上させることができる。
前記目的を実現するために、本開示の技術案は、以下のように実現される。
本開示の実施例の第1態様において、画像処理方法を提供し、前記画像処理方法は、
ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップと、
前記少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するステップであって、前記少なくとも1つのファイルオブジェクトは前記少なくとも1つのリンクパスに1対1で対応する、ステップと、
【0004】
少なくとも1つのピクチャーオブジェクトを作成し、前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む。
本開示の実施例の第2態様において、画像処理装置を提供し、前記画像処理装置は、取得部と、変換部と、保存部と、を含み、
前記取得部は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するように構成され、
前記変換部は、前記少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するように構成され、前記少なくとも1つのファイルオブジェクトは、前記少なくとも1つのリンクパスに1対1で対応し、
【0005】
前記保存部は、少なくとも1つのピクチャーオブジェクトを作成し、前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
本開示の実施例の第3態様において、画像処理装置を提供し、前記画像処理装置は、メモリと、プロセッサと、通信バスと、を含み、前記メモリは、前記通信バスによって前記プロセッサと通信し、前記メモリは、前記プロセッサによって実行可能な1つ又は複数のプログラムを記憶し、前記プロセッサは、前記1つ又は複数のプログラムが実行して、上記のいずれかの画像処理方法を実行する。
本開示の実施例の第4態様において、コンピュータ可読記憶媒体を提供し、前記コンピュータ可読記憶媒体は、1つ又は複数のコンピュータプログラムを記憶し、前記1つ又は複数のコンピュータプログラムは、1つ又は複数のプロセッサに上記のいずれかの画像処理方法を実行させる。
【発明の効果】
【0006】
本開示の実施例は、画像処理方法及び装置、並びにコンピュータ可読記憶媒体を提供する。該方法は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップと、少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するステップであって、少なくとも1つのファイルオブジェクトは少なくとも1つのリンクパスに1対1で対応する、ステップと、少なくとも1つのピクチャーオブジェクトを作成し、少なくとも1つのピクチャーオブジェクトを少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成するステップと、を含む。本開示の実施例の方法によって、画像処理装置は、少なくとも1つのページ画像を取得した後で、少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、少なくとも1つのファイルオブジェクトのリンクパスを少なくとも1つのピクチャーオブジェクトと関連付けてキャッシュに保存することができ、これによってスクリーンショットを他のコーディングフォーマットに変換することによりキャッシュ占有率が大きいという技術的問題を克服する。そして、現在のフルスクリーンページの少なくとも1つのピクチャーオブジェクトは、キャッシュに保存されるため、ユーザが現在のフルスクリーンページに再び入ってスクリーンショットを撮りたい場合、画像処理装置は、直接にキャッシュから少なくとも1つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
【図面の簡単な説明】
【0007】
図1】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
図2】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
図3】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
図4】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
図5】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
図6】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
図7A】本開示の実施例によって提供されるウェブページアプリケーションのスクリーンショットを撮るプロセスのインターフェース概略図である。
図7B】本開示の実施例によって提供されるウェブページアプリケーションのスクリーンショットを撮るプロセスのインターフェース概略図である。
図7C】本開示の実施例によって提供されるウェブページアプリケーションのスクリーンショットを撮るプロセスのインターフェース概略図である。
図8】本開示の実施例によって提供される画像処理方法の一例示的なフローチャートである。
図9】本開示の実施例によって提供される画像処理装置の構造概略図である。
図10】本開示の実施例によって提供される画像処理装置の構造概略図である。
【発明を実施するための形態】
【0008】
以下では、本開示の実施例の図面を参照して、本開示の実施例の技術案をさらに明確で完全に説明する。
本開示の実施例をさらに詳細に説明する前に、本開示の実施例に関する名詞と用語について説明する。本開示の実施例に関する名詞と用語は、下記のような解釈に適用される。
canvas:HTMLの中のcanvas要素は、JavaScriptスクリプトによって、ウェブページに画像を描くことができる。canvasは、パス、矩形、円形、文字の描画方法及び画像の追加方法など、様々な方法を有する。
<a>タグ:<a>はHTMLタグである。<a>タグはハイパーリンクを定義し、あるページから別のページにリンクするために用いられる。
<img>タグ:HTMLで、<img>タグは、ウェブページに画像を埋め込むために用いられる。<img>タグで組み込まれる画像は、ウェブページに挿入されるのではなく、ウェブページにリンクされる。<img>タグの機能は、参照される画像のプレースホルダーを作成することである。
【0009】
base64コーディング:base64は、64個の印刷可能な文字に基づいてバイナリデータを表す方法である。base64は、3つの8ビットバイトごとに4つの6ビットバイトに変換し(3*8=4*6=24)、変換された6ビットの上位ビットに2つの0を追加して4つの8ビットバイトを生成し、該4つの8ビットバイトの10進数に基づいてインデックステーブルに対応する値を探すことを要求し、その結果は、Base64値である。したがって、理論的に、base64エンコードされた文字列の長さは、元の文字列より1/3長いである。
ドキュメント・オブジェクト・モデル(DOM:Document Object Model):DOMは、ドキュメント全体に対するアクセスモデルを提供する。ドキュメントをツリー構造とし、ツリーのノードのそれぞれは、HTMLタグ又はタグ内のテキスト項を表す。DOMツリーのノードのプロパティーは、ページの基本コンテンツと構造情報を表す。
プログレッシブ・ウェブ・アプリケーション(PWA:Progressive Web App):モバイル端末で標準化されたフレームワークのworkbox-swを利用して、一部のネイティブ機能をエミュレートし、ウェブページアプリケーションは、ネイティブアプリケーションと似たような体験を提供することができる。
バイナリラージオブジェクト(Blob:Binary Large Object):Blobは、ファイルオブジェクトと似たようなバイナリデータであり、ファイルオブジェクトと同じように操作されることができる。
【0010】
現在、一般的に、ウェブアプリケーションの年間勘定書又はアンケートレポートなどのウェブプロモーションページ又はHTML 5アニメーションのフルスクリーンページは、複数の場面を含み、各場面は、複数のピクチャー要素を含み、端末機器にスライド操作によって閲覧する必要がある。ユーザが複数の場面を含むフルスクリーンページを閲覧しているときに、各場面のスクリーンショットを撮り、ピクチャーをローカルに保存したい場合、現在のスクリーンショット方式は、canvas描画方法によって、選択された現在の場面のページのスクリーンショットを撮り、そのピクチャーをbase64コーディングフォーマットに変換し、それからピクチャーの周りに<a>タグを巻き、JavaScriptスクリプトを使用してクリックイベントをシミュレートし、ピクチャーをローカルに保存する。又は、<img>タグによってブラウザのネイティブ方法を呼び起こし、ピクチャーをロングクリックするように提示することで、ピクチャーをローカルに保存する。しかしながら、ローカルのピクチャーが失われ、再び保存したい場合、ユーザは現在の閲覧しているページに移動し、上記の一連の操作を実行する必要がある。
【0011】
現在の方法において、ピクチャーをbase64コーディングフォーマットに変換するプロセスにcanvasレンダリングが必要であり、ページが複雑になればなるほどcanvasレンダリングには時間がかかる。そして、base64ピクチャーコーディングは、非常に長い文字列であり、エンコーディングのフルサイズは、ピクチャー自体のサイズを超えるが、ブラウザのcookie又はブラウザのローカルキャッシュは、あまり容量がない。上記から見ると、現在のブラウザのスクリーンショット保存方法は遅く、ブラウザキャッシュへの要求が厳しく、多くのブラウザ性能を消費する。したがって、実際のアプリケーションにおいて、現在のスクリーンショット方式は、キャッシュ容量の制限によりメモリ容量不足のエラーを起こすことが多く、同時に複数のピクチャーのスクリーンショットを保存することができず、一般的にモバイル端末のブラウザは、9枚以上のウェブページのスクリーンショットを同時にキャッシュで処理することができなくなる。そして、現在のスクリーンショット方式で取得したスクリーンショットが失われ、再びスクリーンショットを保存したい場合、ユーザは現在の閲覧しているページに移動し、上記の一連の操作を実行する必要があり、これによってブラウザの性能をさらに消費する。
【0012】
図1を参照すると、図1は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図1に示すステップを合わせて説明する。
ステップS101において、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得する。
本開示の実施例によって提供される画像処理方法は、ウェブページアプリケーションにおいて、スクリーンショットを保存する場面に適用される。例示的に、端末におけるブラウザによって、フルスクリーンページの中の各場面にスクリーンショットを保存する場面、又はHTMLをサポートするアプリケーション又はクライアントによって、1つのリンクの中の複数のスクリーンで表示されるページのコンテンツのスクリーンショットを撮る場面などである。
ステップS101において、ユーザが、ブラウザなどのウェブページアプリケーションにおいて、複数の場面のフルスクリーンページを閲覧している場合、ページをスライドすることによって、フルスクリーンページの中の複数の場面を閲覧することができる。現在のフルスクリーンページをロードした後で、需要に基づいて、画像処理装置は、現在のフルスクリーンページに含まれる場面のスクリーンショットを撮り、撮られた少なくとも1つの画像を少なくとも1つのページ画像として使用することができる。
【0013】
本開示の実施例において、画像処理装置が、ウェブページアプリケーションの現在のフルスクリーンページでスクリーンショット命令を受信した場合、スクリーンショット命令に応答して、スクリーンショット命令により指定される少なくとも1つのスクリーンショット待ち場面に対応する画像を少なくとも1つのページ画像として使用することができる。
本開示の実施例において、画像処理装置が、現在のフルスクリーンページのロードを完成した場合、現在のフルスクリーンページの中の各場面に対応する画像を取得し、少なくとも1つのページ画像として使用することができる。こうすると、画像処理装置は、ユーザはスクリーンショット命令を送信する前に、ユーザはスクリーンショット命令を送信した後の待ち時間を短縮するために、バックグラウンドで現在のフルスクリーンページの中の各場面のスクリーンショットを無感に撮る。
いくつかの実施例において、画像処理装置は、ブラウザのcanvasスクリーンショット方法によって、現在のフルスクリーンページの中のすべての場面又は一部の場面のスクリーンショットを撮り、これによって少なくとも1つのページ画像を取得することができる。具体的に、html2canvas()方法を呼び出し、スクリーンショット待ちの各場面のスタイルとコンテンツ情報を読み出し、スクリーンショット待ちの各場面のスタイルとコンテンツ情報に基づいてレンダリングし、ピクチャー1枚を作成し、これによって少なくとも1つのページ画像を取得することができる。他のいくつかの実施例において、画像処理装置は、Flashcanvas又はExplorerCanvas方法によって、少なくとも1つのページ画像を取得することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
【0014】
本開示の実施例において、一般的に、canvasスクリーンショット方法で、pngフォーマットのピクチャーを取得し、実際の需要に基づいて他のフォーマットのピクチャーを作成することもできる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
説明すべきこととして、本開示の実施例において、少なくとも1つのページ画像は、現在のフルスクリーンページの中のフルスクリーンページコンテンツをすべてロードした後で取得される。したがって、少なくとも1つのページ画像は、すべてウェブページアプリケーションのローカルで作成された画像である。
ステップS102において、少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成する。少なくとも1つのファイルオブジェクトは少なくとも1つのリンクパスに1対1で対応する。
ステップS102において、画像処理装置は、少なくとも1つのページ画像を取得した後で、ピクチャーフォーマットの少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換することができ、HTMLページでファイルオブジェクトを操作することによって、少なくとも1つのページ画像へのアクセスとコンテンツの読み出しを実現する。
【0015】
いくつかの実施例において、画像処理装置は、canvas.toBlob()方法によって、少なくとも1つのページ画像を少なくとも1つのblobオブジェクトに変換し、少なくとも1つのblobオブジェクトを少なくとも1つのファイルオブジェクトとして使用することができる。他のいくつかの実施例において、画像処理装置は、他の方法によって、少なくとも1つのページ画像を他のファイルタイプのウェブページオブジェクトに変換することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
ステップS102において、画像処理装置は、少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換した後で、ファイルオブジェクトのそれぞれに1つのリンクパスを作成する。
いくつかの実施例において、少なくとも1つのファイルオブジェクトが、少なくとも1つのblobオブジェクトである場合、画像処理装置は、URL.createObjectURL()方法によって、blobオブジェクトのそれぞれにユニフォーム・リソース・ロケータ(URL:Uniform Resource Locator)を作成し、blobオブジェクトのそれぞれに対応するリンクパスとすることができ、これによって少なくとも1つのリンクパスを取得する。
【0016】
本開示の実施例において、少なくとも1つのリンクパスの中の各リンクパスは、対応するファイルオブジェクトを指す。したがって、画像処理装置は、少なくとも1つのリンクパスによって、少なくとも1つのファイルオブジェクトをピクチャーオブジェクトなどの他のタイプのウェブページオブジェクトと関連付けることができ、リンクパスを指定することによって、他のタイプのウェブページオブジェクトは、少なくとも1つのファイルオブジェクトの中のデータを元データとして引用できるようにし、これによって、他のタイプのウェブページオブジェクトへの操作によって、少なくとも1つのファイルオブジェクトに対して多様な処理方法を取得する。
ステップS103において、少なくとも1つのピクチャーオブジェクトを作成し、少なくとも1つのピクチャーオブジェクトを少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
【0017】
ステップS103において、画像処理装置は、ウェブページアプリケーションのローカルキャッシュで少なくとも1つのピクチャータイプのオブジェクト、即ち、少なくとも1つのピクチャーオブジェクトを作成し、少なくとも1つのリンクパスは、少なくとも1つのピクチャーオブジェクトを指すようにし、これによって少なくとも1つのリンクパスを少なくとも1つのピクチャーオブジェクトと関連付ける。画像処理装置は、少なくとも1つのリンクパスと少なくとも1つのピクチャーオブジェクトとともにウェブページアプリケーションキャッシュに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
いくつかの実施例において、画像処理装置は、new Image()方法によって、少なくとも1つのピクチャーオブジェクトを作成することができる。new Image()で作成されたピクチャーオブジェクトに対して、画像処理装置は、該ピクチャーオブジェクトのsrcプロパティーにリンクパスで値を付け、こうすると、該ピクチャーオブジェクトがロードされた場合、対応するリンクパスによって、該リンクパスに対応するファイルオブジェクトにアクセスすることができ、ファイルオブジェクトの中のコンテンツを該ピクチャーオブジェクトでロードするピクチャーのコンテンツデータとし、これによってピクチャーオブジェクト、リンクパス及びファイルオブジェクトの相互関連することを実現する。
【0018】
ステップS103において、スクリーンショットを撮る処理の速度をさらに向上させるために、画像処理装置は、少なくとも1つのリンクパスをウェブページアプリケーションのcookieに記憶することができる。これによって、画像処理装置は現在のフルスクリーンページのスクリーンショットを撮る前に、ウェブページアプリケーションのcookieにスクリーンショットを撮りたい少なくとも1つのリンクパスが存在するか否かをチェックすることによって、且つ、少なくとも1つのリンクパスによって、直接にヒストリーキャッシュされた少なくとも1つのピクチャーオブジェクトを取得することができ、同じページの再びスクリーンショットの処理の必要がない。
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも1つのページ画像を取得した後で、少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、少なくとも1つのファイルオブジェクトのリンクパスを少なくとも1つのピクチャーオブジェクトと関連付けてキャッシュに保存することができ、これによってスクリーンショットを他のコーディングフォーマットに変換することによりキャッシュ占有率が大きいという技術的問題を克服する。そして、現在のフルスクリーンページの少なくとも1つのピクチャーオブジェクトは、キャッシュに保存されるため、ユーザが現在のフルスクリーンページに再び入ってスクリーンショットを撮りたい場合、画像処理装置は、直接にキャッシュから少なくとも1つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
【0019】
図2を参照すると、図2は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図1を基づいて、図1に示すステップS101はステップS1011-S1014によって実現することができる。各ステップを合わせて説明する。
ステップS1011において、現在のフルスクリーンページから少なくとも1つの場面を分割し、少なくとも1つの場面に対して少なくとも1つのノード識別子を設定する。少なくとも1つのノード識別子は、少なくとも1つの場面に現在のフルスクリーンページに対応する少なくとも1つのデータ位置を表し、少なくとも1つの場面は少なくとも1つのノード識別子に1対1で対応する。
ステップS1011において、ロード完成された現在のフルスクリーンページに対して、画像処理装置は、ページに示されるスタイル又はコンテンツに基づいて、少なくとも1つの場面を分割することができ、後で少なくとも1つの場面からスクリーンショットを撮りたい場面を指定するためである。相応的に、画像処理装置は、少なくとも1つの場面に対して少なくとも1つのノード識別子を設定し、少なくとも1つの場面は少なくとも1つのノード識別子に1対1で対応する。
【0020】
本開示の実施例において、少なくとも1つの場面は、現在のフルスクリーンページに含まれるページ場面であり、例えば、現在のフルスクリーンページに含まれる異なる場所における画像やテキスト、又は現在のフルスクリーンページに含まれる各スクリーンページなどである。
本開示の実施例において、少なくとも1つのノード識別子は、少なくとも1つの場面に現在のフルスクリーンページに対応する少なくとも1つのデータ位置を表す。即ち、ノード識別子は、現在のフルスクリーンページに対応する全体コンテンツデータに、その対応するウェブページオブジェクトのコンテンツデータの保存場所である。例示的に、現在のフルスクリーンページに対応する全体コンテンツデータは、HTMLテキストであることができ、ブラウザが、HTMLテキストを解析する場合、HTMLテキストの中の各ウェブページオブジェクトの関連関係に基づいてDOMツリーを構築する。ここで、少なくとも1つのノード識別子は、現在のフルスクリーンページのDOMツリーの中のドキュメントノードであることができ、DOMノードのそれぞれに、ウェブページオブジェクトのそれぞれに対応するコンテンツデータは保存され、DOMツリーで、DOMノードのそれぞれは、他のDOMノードと相互関連する。
【0021】
いくつかの実施例において、画像処理装置は、現在のフルスクリーンページで、DOMスタイルを1画面に表示するように設定することができ、即ち、フルスクリーンページの中の各スクリーンページを1つの場面とする。画像処理装置は、画面のそれぞれに異なるDOM IDを設置し、少なくとも1つのノード識別子とする。
ステップS1012において、現在のフルスクリーンページで、少なくとも1つのスクリーンショット待ち場面に対応する少なくとも1つの目標ノード識別子を取得する。少なくとも1つのスクリーンショット待ち場面は、少なくとも1つの場面の中の目標スクリーンショット場面である。
ステップS1012において、現在のフルスクリーンページで、画像処理装置は、スクリーンショット命令に基づいて少なくとも1つのスクリーンショット待ち場面を決定し、又は、黙認として現在のフルスクリーンページの中のすべての場面を少なくとも1つのスクリーンショット待ち場面とし、少なくとも1つのスクリーンショット待ち場面に対応する少なくとも1つの目標ノード識別子を取得する。
【0022】
ステップS1013において、少なくとも1つの目標ノード識別子の中の各目標ノード識別子に基づいて、現在のフルスクリーンページのコンテンツデータから各目標ノード識別子に対応するコンテンツデータを読み出し、これによって少なくとも1つの目標ページデータを取得する。
本開示の実施例において、少なくとも1つのノード識別子の中のノード識別子のそれぞれに対して、画像処理装置は、ノード識別子のそれぞれに基づいて、現在のフルスクリーンページの全体コンテンツデータに、該ノード識別子が代表するウェブページオブジェクトに対応するコンテンツデータの保存場所を決定する。ノード識別子のそれぞれに対応するデータの保存場所に基づいて、対応するウェブページオブジェクトのそれぞれのコンテンツデータを読み出し、これによって少なくとも1つの目標ページデータを取得する。
ステップS1014において、ウェブページレンダリング機能によって、少なくとも1つの目標ページデータに基づいて、少なくとも1つのページ画像を作成する。
本開示の実施例において、画像処理装置は、少なくとも1つの目標ページデータを読み出した後で、canvas描画方法などのウェブページレンダリング機能によって、少なくとも1つの目標ページデータに基づいて、少なくとも1つのページ画像を作成する。
理解可能なこととして、本開示の実施例において、異なるスタイルのノード識別子をプリセットすることによって、現在のフルスクリーンページに異なる形態のスクリーンショットの処理を行うことができ、これによってページのスクリーンショットを撮るプロセスの柔軟性を高める。
【0023】
本開示の実施例において、図3を参照すると、図3は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図1に示すステップS102はステップS1021-S1022によって実現することができる。各ステップを合わせて説明する。
ステップS1021において、少なくとも1つのページ画像を少なくとも1つのバイナリラージオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトとして使用する。
ステップS1021において、画像処理装置は、少なくとも1つのページ画像を取得した後で、ウェブページ描画方法の中のピクチャーからバイナリラージオブジェクトへの変換方法を呼び出し、少なくとも1つのページ画像から少なくとも1つのバイナリラージオブジェクトに変換することを実現し、少なくとも1つのファイルオブジェクトとして使用することができる。
いくつかの実施例において、画像処理装置は、canvas.toBlob()方法によって、少なくとも1つのページ画像にフォーマット変換を実行し、少なくとも1つのblobオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトとして使用する。
ステップS1021において、現在のスクリーンショット方式と比べると、画像処理装置は、canvas.toDataURL方法ではなくcanvas.toBlob()を使用してページ画像を変換するのは、canvas.toDataURLで変換されたページ画像はbase64コーディングフォーマットであり、データサイズは元ピクチャーのデータサイズより大きく、ウェブページアプリケーションキャッシュ占有率が大きく、スクリーンショットの撮るエラーを起こすからである。
ステップS1022において、少なくとも1つのバイナリラージオブジェクトの中の各バイナリラージオブジェクトに対して、ウェブページアプリケーションスクリプトの中のオブジェクト位置パス作成方法を呼び出し、各バイナリラージオブジェクトのリソースアドレスをリンクパスとして作成し、これによって少なくとも1つのリンクパスを取得する。
【0024】
ステップS1022において、画像処理装置は、少なくとも1つのページ画像を少なくとも1つのblobオブジェクトに変換した後で、blobオブジェクトのそれぞれに対して、URL.createObjectURL()方法を呼び出し、blobオブジェクトのそれぞれに対応するURLアドレスを該blobオブジェクトのリンクパスとして作成し、これによって少なくとも1つのリンクパスを取得する。
本開示の実施例において、URL.createObjectURL()方法を呼び出すと、対応するblobオブジェクトを指定するためのhash付けるurl文字列を返す。
理解可能なこととして、本開示の実施例において、画像処理装置は、canvas.toBlob()とURL.createObjectURL()方法によって、少なくとも1つのページ画像をblobオブジェクト及び対応するパスに変換する。変換されたピクチャーとパスのデータサイズが小さく、ウェブページアプリケーションキャッシュ占有率が小さく、メモリ不足などのエラーを起こさなく、これによってウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図4を参照すると、図4は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図1に示すステップS103はS1031-S1033によって実現することができる。各ステップを合わせて説明する。
ステップS1031において、ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも1つのピクチャーオブジェクトを作成する。
ステップS1031において、画像処理装置は、new image()方法などのウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、ウェブページアプリケーションキャッシュに少なくとも1つのピクチャーオブジェクトを作成する。
【0025】
本開示の実施例において、new image()方法で作成されたピクチャーオブジェクトは、ピクチャー名称とsrcプロパティーなどの情報を含む。ここで、srcプロパティーは、必要であり、srcプロパティーの値は、該ピクチャーオブジェクトのURLであり、即ち、該ピクチャーオブジェクトを引用するファイルの絶対パス又は相対パスである。
いくつかの実施例において、画像処理装置は、ウェブページアプリケーションがサポートする他の方法によって、少なくとも1つのピクチャーオブジェクトを作成することができる。具体的に、実際の状況に基づいて選択されるものであり、本開示の実施例はこれに限定されるものではない。
ステップS1032において、各ピクチャーオブジェクトに対して、少なくとも1つのリンクパスの中の各リンクパスを各ピクチャーオブジェクトの画像ソースパスとして使用し、少なくとも1つのピクチャーオブジェクトをウェブページアプリケーションキャッシュに保存する。画像ソースパスは、各ピクチャーオブジェクトがロードされるときに、コンテンツデータが取得されるパスである。
ステップS1032において、画像処理装置は、少なくとも1つのピクチャーオブジェクトを作成した後で、各ピクチャーオブジェクトに対して、画像処理装置は、対応するリンクパスを該ピクチャーオブジェクトの画像ソースパスとし、即ち、各ピクチャーオブジェクトがウェブページにロードされるときに、コンテンツデータが取得されるパスである。これによって少なくとも1つのファイルオブジェクトを少なくとも1つのピクチャーオブジェクトのコンテンツデータとすることが実現し、両方の関連を実現する。
【0026】
ステップS1032において、画像処理装置は、値を付けることによって、リンクパスのそれぞれを各ピクチャーオブジェクトの画像ソースパスとすることができる。
ステップS1032において、画像処理装置は、少なくとも1つのピクチャーオブジェクトをウェブページアプリケーションキャッシュに保存し、次回のアクセスのときにウェブページアプリケーションのローカルキャッシュから対応するピクチャーオブジェクトを開くことができるためである。
ステップS1033において、セッションデータによって、少なくとも1つのピクチャーオブジェクトを少なくとも1つのリンクパスと関連付けて保存することを実現できるように、少なくとも1つのピクチャーオブジェクトのピクチャー名称と画像ソースパスをウェブページアプリケーションキャッシュのセッションデータに保存し、これによって現在のフルスクリーンページのスクリーンショットを完成する。
【0027】
ステップS1033において、画像処理装置は、セッションデータ設置方法を呼び出し、少なくとも1つのピクチャーオブジェクトのピクチャー名称と画像ソースパスをcookieなどのウェブページアプリケーションキャッシュのセッションデータに保存することを実現することができる。これによって、セッションデータから少なくとも1つのリンクパスを取得することを実現し、さらにそれに関連する少なくとも1つのピクチャーオブジェクトを取得し、これによって現在のフルスクリーンページのスクリーンショットを撮ること及びキャッシュに保存することを完成する。
いくつかの実施例において、画像処理装置は、setCookie()方法を呼び出すことによって、少なくとも1つのピクチャーオブジェクトのピクチャー名称、URL及び有効時間をcookieに保存することができる。対応するコードは下記のように実現することをできる。
canvas.toBlob(function(blobObj){
let imgs = new Image();//ピクチャーオブジェクトを作成する
let src = window.URL.createObjectURL(blobObj);//blobオブジェクトのリンクパスを作成する
imgs.src = src; //リンクパスを使用してピクチャーオブジェクトの画像ソースパスに値を付ける
screenShotCut[ary[i].component] = src;
//リンクパスをcookieに保存する
setCookie(‘imgSrc’,JSON.stringify(screenShotCut))
})
いくつかの実施例において、下記のコードによって、上記のsetCookie()方法を実現することができる。
setCookie(name,value,iMinutes){
var oDate = new Date();
oDate.setMinutes(oDate.getMinutes()+iMinutes);
document.cookie = name+’=’+encodeURIComponent(value)
+’;expires=’+oDate;
},
【0028】
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも1つのファイルオブジェクトのリンクパスを少なくとも1つのピクチャーオブジェクトと関連付けてキャッシュに保存し、ウェブページアプリケーションキャッシュのセッションデータに少なくとも1つのリンクパスを保存した後で、ユーザが現在のフルスクリーンページに再び入った場合、画像処理装置は、直接にキャッシュから少なくとも1つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図5を参照すると、図5は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図1に示すステップS101はS002-S003によって実現することができる。各ステップを合わせて説明する。
ステップS002において、ウェブページアプリケーションキャッシュのセッションデータに、現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックする。
ステップS002において、画像処理装置は、少なくとも1つのページ画像を取得する前に、ウェブページアプリケーションキャッシュのセッションデータをチェックし、セッションデータに現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かを決定する。
【0029】
本開示の実施例において、画像処理装置は、ウェブページアプリケーションキャッシュのセッションデータに、現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックするプロセスは、下記のように実現することができる。
ステップS0021において、少なくとも1つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、セッションデータから少なくとも1つのピクチャーオブジェクトを抽出することを実行する。
いくつかの実施例において、ユーザが、ウェブページアプリケーションによって、現在のフルスクリーンページをアクセスする場合、画像処理装置は、canvasスクリーンショット方式を呼び出して少なくとも1つのページ画像を取得する前に、getCookie()方法を呼び出し、ウェブページアプリケーションのcookieデータを取得し、newImg.load方法によって、cookieデータに少なくとも1つのピクチャーオブジェクトは既に存在するか否かをチェックすることができる。
いくつかの実施例において、画像処理装置は、ウェブページアプリケーションキャッシュに、少なくとも1つのリンクパスに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックするプロセスは、下記のように実現することができる。
async canShot(){
let imgsrc = getCookie(‘imgsrc’);
//ピクチャーをチェックする
if(imgSrc){
let imgAys = JSON.pase(imgSrc);
imgAys.map(item=>{
let newImg = new Imgage();
newImg.src = item;
newImg,load = ()=>{
//ピクチャーはキャッシュにまだ存在するか否かをチェックする
}
})
}else{
let ary = this.comps; //切り取りたいページid
let i = ary,length;
let shotCanvas = async()=>{

}
shotCanvas();
}
}
【0030】
いくつかの実施例において、上記のgetCookie()方法は、下記のコードによって実現することをできる。
getCookie(name){
var arr = document.cookie.split(‘;’);
var i = 0;
for(var i=0;i<arr.length;i++){
var arr2 = arr[i].split(‘=’);
if(arr2[0]==name){
return decodeURIComponent(arr2[1]);
}
}
return ‘’;
},
ステップS0022において、セッションデータ取得方法の呼び出しが成功した場合、セッションデータに少なくとも1つのピクチャーオブジェクトが存在することを確認する。
本開示の実施例において、セッションデータ取得方法の呼び出しが成功した場合、例示的に、上記のgetCookie(‘imgsrc’)方法は、imgsrcに対応するピクチャーオブジェクトを返すことは、該ピクチャーオブジェクトは、セッションデータに既に存在し、画像処理装置は、セッションデータに少なくとも1つのピクチャーオブジェクトが存在することを確認することを示す。
ステップS0023において、セッションデータ取得方法の呼び出しが失敗した場合、セッションデータに少なくとも1つのピクチャーオブジェクトが存在しないことを確認する。
【0031】
本開示の実施例において、セッションデータ取得方法の呼び出しが失敗した場合、画像処理装置はセッションデータに少なくとも1つのピクチャーオブジェクトが存在しないことを確認する。
ステップS003において、セッションデータに少なくとも1つのピクチャーオブジェクトが存在しない場合、現在のフルスクリーンページの少なくとも1つのページ画像を取得する。
本開示の実施例において、セッションデータに少なくとも1つのピクチャーオブジェクトが存在しない場合、画像処理装置は、現在のフルスクリーンページから少なくとも1つのページ画像を取得し、上記のステップS102-S103の中の方法によって、現在のフルスクリーンページのスクリーンショットを撮ることを実現する。
本開示の実施例において、図5に示すように、ステップS002の後で、ステップS004が含まれることもできる。
ステップS004において、セッションデータに少なくとも1つのピクチャーオブジェクトが存在する場合、セッションデータから少なくとも1つのピクチャーオブジェクトに対応する少なくとも1つのリンクパスを取得し、現在のフルスクリーンページのスクリーンショットを完成する。
【0032】
ステップS004において、ウェブページアプリケーションキャッシュに少なくとも1つのピクチャーオブジェクトが存在する場合、画像処理装置は、少なくとも1つのページ画像を取得することなく、現在のフルスクリーンページのスクリーンショットを完成する。
理解可能なこととして、本開示の実施例において、画像処理装置は、ウェブページアプリケーションのcookieからスクリーンショットを撮りたい少なくとも1つのピクチャーオブジェクトの場所を迅速に決定することができ、同じページの再びスクリーンショットの処理の必要がなく、キャッシュされたピクチャーの再利用性を向上させ、これによってウェブページアプリケーションのスクリーンショットの撮る作業負荷を軽減し、ウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、図6を参照すると、図6は、本開示の実施例によって提供される画像処理方法の一例示的なフローチャートであり、図4又は図5に基づいて、ステップS1033又はステップS103の後で、ステップS1034-S1035を実行することができる。各ステップを合わせて説明する。
【0033】
ステップS1034において、ウェブページアプリケーションにおいて、少なくとも1つのピクチャーオブジェクトの中の少なくとも1つの目標ピクチャーに対するアクセス要求を受信した場合、少なくとも1つの目標ピクチャーオブジェクトの画像ソースパスによって、少なくとも1つの目標ピクチャーオブジェクトに対応する少なくとも1つの目標ファイルオブジェクトを取得する。目標ファイルオブジェクトのリンクパスは、目標ピクチャーオブジェクトの画像ソースパスと同じである。
ステップS1034において、ウェブページアプリケーションにおいて、ウェブページのスクリーンショットを表示し、さらに保存する場合、画像処理装置は、ウェブページアプリケーションにおいて、少なくとも1つのピクチャーオブジェクトの中の少なくとも1つの目標ピクチャーに対するアクセス要求を受信することができる。
本開示の実施例において、少なくとも1つの目標ピクチャーは、少なくとも1つのピクチャーオブジェクトの中の抽出待ちのスクリーンショットを表す。画像処理装置は、アクセス要求が帯びるピクチャー名称に基づいて、抽出待ちの少なくとも1つの目標ピクチャーを決定することができる。
ステップS1034において、ファイルオブジェクトのリンクパスは、ピクチャーオブジェクトの画像ソースパスと同じであるために、画像処理装置は、対象各ピクチャーオブジェクトの画像ソースパスによって、少なくとも1つのファイルオブジェクトから対応して目標ファイルオブジェクトを読み出すことができる。
【0034】
ステップS1035において、少なくとも1つの目標ファイルオブジェクトに基づいて、少なくとも1つの目標ピクチャーオブジェクトをロードし、これによって、少なくとも1つの目標ピクチャーオブジェクトに対する表示及び保存を実現する。
ステップS1035において、画像処理装置は、対象各ピクチャーオブジェクトに対応する目標ファイルオブジェクトの中のコンテンツデータに基づいて、ウェブページアプリケーションにおいて、対象各ピクチャーオブジェクトをロードし、これによって、対象各ピクチャーオブジェクトに対する抽出、表示及び保存を実現する。
理解可能なこととして、本開示の実施例において、画像処理装置は、少なくとも1つのリンクパスによって、少なくとも1つのファイルオブジェクトを少なくとも1つのピクチャーオブジェクトのコンテンツデータとすることができる。こうすると、少なくとも1つのリンクパスの中の少なくとも1つの対象リンクパスへのアクセスによって、ロードしたい目標ピクチャーオブジェクトを関連してロードすることができ、これによって、ウェブページアプリケーションのキャッシュでスクリーンショットを撮りたい場面に対する表示及び保存を実現し、ウェブページアプリケーションのスクリーンショットの性能を向上させる。
以下では、本開示の実施例を実際の応用場面に例示的に応用するよう説明する。
【0035】
本開示のいくつかの実施例において、ユーザが、ブラウザ又はウェブページアプリケーションによって、サマリーレポート又は、活動調査などのページを閲覧する場合、インターフェースのインタラクション効果は図7A図7Cに示すようになることができる。図7Aにおいて、ユーザは、ページに上下スライド操作によって、ウェブページ全体の中の各スクリーンページに表示する内容を閲覧することができる。最後のページまでスライドした場合、図7Bに示すように、ウェブページアプリケーションは、ウェブページ全体の中の少なくとも1つの画面のページをすべてローグスクリーンショットとして作成し、インターフェースに保存ボタンコントロール2-1を表示し、保存ボタンコントロール2-1によって、作成されたウェブページ全体のローグスクリーンショットを保存するように、又は、直接にバックグラウンドで該ローグスクリーンショットをダウンロードして保存するように、ユーザを注意する。図7Cに示すように、ウェブページアプリケーションは、ウェブページ全体の中の各スクリーンページに対応するスクリーンショットプレビューピクチャーを作成し、サムネイルの形で当前ページに表示することができる。ユーザは、サムネイルをクリックすることによって、その中の1つ又は複数のスクリーンショットプレビューピクチャーを選択して保存し、確認ボタンコントロール2-2によって選択することを完成することができる。ユーザが、確認ボタンコントロール2-2によって選択することを完成した場合、さらに、保存ボタン2-3をクリックすることによって、選択を確認した1つ又は複数のスクリーンショットプレビューピクチャーに対応するページピクチャーを保存することができる。
本開示の実施例において、ユーザは図7B又は図7Cに示すインターフェースに保存コントロール2-1又は保存コントロール2-3をクリックした後で、画像処理装置は、ウェブページアプリケーションにおいて、スクリーンショット命令を受信することができる。例示的に、ユーザが、図7Cで示すインターフェースに複数のページピクチャーを選択し、保存コントロール2-3をクリックした場合、図8に示すように、画像処理装置は、ステップS301-S307によって、選択された複数のページピクチャーを撮って保存することができる。
【0036】
ステップS301において、ページをロードする。
ステップS301において、画像処理装置は、ブラウザにウェブページ全体をロードする。
ステップS302において、キャッシュにリンクアドレスアレイが存在するか否かを判断する。
ステップS302において、ウェブページ全体をロードした後で、画像処理装置は、キャッシュにリンクアドレスアレイが存在するか否かを判断し、存在するなら、ステップS303-S308を実行し、存在しないなら、スキップしてステップS309を実行する。
ステップS302において、リンクアドレスアレイは、少なくとも1つのリンクアドレスを含む。少なくとも1つのリンクアドレスは、少なくとも1つのピクチャーオブジェクトの元アドレスであり、少なくとも1つのピクチャーオブジェクトは、ウェブページ全体に対応する少なくとも1つのスクリーンショットピクチャーであることができる。
ステップS302の実現プロセスは、ステップS002で説明するものと同じであり、ここでは繰り返さない。
ステップS303において、ウェブページ全体の中の各スクリーンページに対応するDOM IDを取得する。
ステップS303において、画像処理装置は、取得した各スクリーンページのDOM IDからDOM IDアレイを構成することができる。
ステップS303において、画像処理装置は、DOM IDアレイに含まれる少なくとも1つのDOM IDを少なくとも1つのノード識別子とする。ステップS303の実現プロセスは、ステップS1011で説明するものと同じであり、ここでは繰り返さない。
【0037】
ステップS304において、DOM IDごとにCanvasのスクリーンショットを撮り、少なくとも1つのスクリーンショットピクチャーを取得する。
ステップS304の実現プロセスは、ステップS1012-1014で説明するものと同じであり、ここでは繰り返さない。
ステップS305において、canvas.toBlob()方法によって、少なくとも1つのスクリーンショットピクチャーを少なくとも1つのblobオブジェクトに変換する。
ステップS305の実現プロセスは、ステップS1021で説明するものと同じであり、ここでは繰り返さない。
いくつかの実施例において、例示的に、ステップS303-S305に対応するコードは下記のように実現することをできる。
async canShot(){
let ary = this.comps; //アレイthis.compsはすべてのスクリーンショット待ちのDOM IDを記憶する
let i = ary.length;
let shotCanvas = async ()=>{
i--;
if(ary[i]){
//DOM IDのそれぞれに対応するページコンテンツのスクリーンショットを撮る
let canvas = await html2canvas
(document.querySelector(‘.${ary[i].component}’)、{useCORS;true})
canvas.toBlob(function(blobObj) {…})
shotCanvas()
}
}
shotCanvas()
}
【0038】
ステップS306において、URL.createObjectURL()方法によって、少なくとも1つのblobオブジェクトの少なくとも1つのリンクパスを作成する。
ステップS306の実現プロセスは、ステップS1022で説明するものと同じであり、ここでは繰り返さない。
ステップS307において、new Image()方法によって、少なくとも1つのピクチャーオブジェクトimgを作成し、少なくとも1つのリンクパスを使用して少なくとも1つのimg.srcに値を付け、少なくとも1つのimgsをブラウザキャッシュに保存する。
ステップS307の実現プロセスは、ステップS1031-S1032で説明するものと同じであり、ここでは繰り返さない。
ステップS308において、少なくとも1つのリンクパスをアレイの形でcookieに保存する。
ステップS308の実現プロセスは、ステップS1033で説明するものと同じであり、ここでは繰り返さない。
ステップS309において、キャッシュから少なくとも1つのリンクパスを取得する。
【0039】
ステップS309において、キャッシュに少なくとも1つのリンクパスが存在する場合、画像処理装置は、再びスクリーンショットを撮ることなく、直接に少なくとも1つのリンクパスを取得する。
ステップS310において、少なくとも1つのリンクパスに基づいて、キャッシュから少なくとも1つのピクチャーオブジェクトを抽出し、需要に基づいて少なくとも1つのピクチャーオブジェクトをさらに保存する。
ステップS310の実現プロセスは、ステップS1034-S1035で説明するものと同じであり、ここでは繰り返さない。
理解可能なこととして、上記の操作によって、画像処理装置は、多画面スクリーンショット撮ること及びオプショナルスクリーンショット撮ることを実現することができ、ピクチャーを撮ってレンダリングする時間が長いという技術的問題を克服し、キャッシュされたスクリーンショットの再利用性を向上させ、これによってウェブページアプリケーションのスクリーンショットの性能を向上させる。
本開示の実施例において、さらに、画像処理装置は、PWA技術によって、指定するタイプのページ画像をキャッシュすることができる。具体的に、workbox-swプラグインを導入し、blob:null/パスの中のピクチャーを強制的にキャッシュする。例のコードは下記のようになる。
importScripts(‘workbox-sw.prod.v1.1.0.js’);
const workbox = new self.WorkboxSW();
// blob:null/ パスの中の任意の要求をマッチしてキャッシュする
workBox.router.registerRoute(‘blob:null/(.*)’,workbox.stragtegies.cacheFirst())
【0040】
理解可能なこととして、画像処理装置が、ブラウザキャッシュスペースなどのウェブページアプリケーションキャッシュによって、撮られたピクチャーを保存する場合、時効性又はユーザの行動が予測できないことなどの不安定要素が存在する可能性がある。画像処理装置は、PWA技術の中のService Workerでピクチャーをキャッシュし、安定で制御できるピクチャーキャッシュ効果を実現する。
本開示の実施例は画像処理方法に対応する画像処理装置を提供する。図9は本開示の実施例によって提供される画像処理装置の構造概略図である。図9に示すように、画像処理装置100は、取得部10と、変換部20と、保存部30と、を含み、
前記取得部10は、ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するように構成され、
前記変換部20は、前記少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトの少なくとも1つのリンクパスを作成するように構成され、前記少なくとも1つのファイルオブジェクトは、前記少なくとも1つのリンクパスに1対1で対応し、
前記保存部30は、少なくとも1つのピクチャーオブジェクトを作成し、前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けてウェブページアプリケーションキャッシュに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
【0041】
本開示のいくつかの実施例において、前記変換部20はさらに、前記少なくとも1つのページ画像を少なくとも1つのバイナリラージオブジェクトに変換し、前記少なくとも1つのファイルオブジェクトとし、前記少なくとも1つのバイナリラージオブジェクトの中の各バイナリラージオブジェクトに対して、ウェブページアプリケーションスクリプトの中のオブジェクト場所パス作成方法を呼び出し、前記各バイナリラージオブジェクトのリソースアドレスをリンクパスとして作成し、これによって前記少なくとも1つのリンクパスを取得するように構成される。
本開示のいくつかの実施例において、前記保存部30はさらに、ウェブページアプリケーションスクリプトの中のピクチャーオブジェクト作成方法を呼び出し、少なくとも1つのピクチャーオブジェクトを作成し、各ピクチャーオブジェクトに対して、前記少なくとも1つのリンクパスの中の各リンクパスを前記各ピクチャーオブジェクトの画像ソースパスとして使用し、前記少なくとも1つのピクチャーオブジェクトを前記ウェブページアプリケーションキャッシュに保存し、前記画像ソースパスは、前記各ピクチャーオブジェクトをロードするときに、コンテンツデータを取得するパスであり、前記セッションデータによって前記少なくとも1つのピクチャーオブジェクトを前記少なくとも1つのリンクパスと関連付けて保存することを実現できるように、前記少なくとも1つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュのセッションデータに保存し、これによって前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
【0042】
本開示のいくつかの実施例において、前記画像処理装置100はさらに、チェック部を含む。前記チェック部は、前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックするように構成される。前記取得部10はさらに、前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在しない場合、前記現在のフルスクリーンページの少なくとも1つのページ画像を取得するように構成される。
本開示のいくつかの実施例において、前記取得部10はさらに、前記ウェブページアプリケーションキャッシュのセッションデータに、前記現在のフルスクリーンページに対応する少なくとも1つのピクチャーオブジェクトが存在するか否かをチェックするステップの後で、前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在する場合、前記セッションデータから前記少なくとも1つのピクチャーオブジェクトに対応する前記少なくとも1つのリンクパスを取得し、前記現在のフルスクリーンページのスクリーンショットを完成するように構成される。
【0043】
本開示のいくつかの実施例において、前記取得部10はさらに、前記現在のフルスクリーンページのロードを完成した場合、前記現在のフルスクリーンページの中の各場面に対応する画像を取得し、少なくとも1つのページ画像として使用するように構成される。
本開示のいくつかの実施例において、前記取得部10はさらに、前記現在のフルスクリーンページにスクリーンショット命令を受信した場合、前記スクリーンショット命令に応答して、前記スクリーンショット命令により指定される少なくとも1つのスクリーンショット待ち場面に対応する画像を前記少なくとも1つのページ画像として使用するように構成される。
本開示のいくつかの実施例において、前記画像処理装置100はさらに、抽出部を含む。前記抽出部は、前記現在のフルスクリーンページのスクリーンショットを完成するステップの後で、前記ウェブページアプリケーションにおいて、前記少なくとも1つのピクチャーオブジェクトの中の少なくとも1つの目標ピクチャーに対するアクセス要求を受信した場合、前記少なくとも1つの目標ピクチャーオブジェクトの画像ソースパスによって、前記少なくとも1つの目標ピクチャーオブジェクトに対応する少なくとも1つの目標ファイルオブジェクトを取得し、前記目標ファイルオブジェクトのリンクパスは、前記目標ピクチャーオブジェクトの画像ソースパスと同じであり、前記少なくとも1つの目標ファイルオブジェクトに基づいて、前記少なくとも1つの目標ピクチャーオブジェクトをロードし、これによって、前記少なくとも1つの目標ピクチャーオブジェクトに対する表示及び保存を実現するように構成される。
【0044】
本開示のいくつかの実施例において、前記画像処理装置100はさらに、標記部を含む。前記標記部は、前記ウェブページアプリケーションにおいて、現在のフルスクリーンページの少なくとも1つのページ画像を取得するステップの前に、現在のフルスクリーンページから少なくとも1つの場面を分割し、前記少なくとも1つの場面に対して少なくとも1つのノード識別子を設定し、前記少なくとも1つの場面は、前記現在のフルスクリーンページに含まれるページ場面であり、前記少なくとも1つのノード識別子は、前記現在のフルスクリーンページで、前記少なくとも1つの場面に対応する少なくとも1つのデータ位置を表し、前記少なくとも1つの場面は、前記少なくとも1つのノード識別子に1対1で対応するように構成される。
前記取得部10はさらに、前記現在のフルスクリーンページで、少なくとも1つのスクリーンショット待ち場面に対応する少なくとも1つの目標ノード識別子を取得し、前記少なくとも1つのスクリーンショット待ち場面は、前記少なくとも1つの場面の中の目標スクリーンショット場面であり、前記少なくとも1つの目標ノード識別子の中の各目標ノード識別子に基づいて、前記現在のフルスクリーンページのコンテンツデータから各目標ノード識別子に対応するコンテンツデータを読み出し、これによって少なくとも1つの目標ページデータを取得し、ウェブページレンダリング機能によって、前記少なくとも1つの目標ページデータに基づいて、前記少なくとも1つのページ画像を作成するように構成される。
【0045】
本開示のいくつかの実施例において、前記変換部20はさらに、ウェブページ描画方法の中のピクチャーからバイナリラージオブジェクトへの変換方法を呼び出し、前記少なくとも1つのページ画像から少なくとも1つのバイナリラージオブジェクトに変換することを実現し、前記少なくとも1つのファイルオブジェクトとして使用するように構成される。
本開示のいくつかの実施例において、前記保存部30はさらに、セッションデータ設定方法を呼び出し、前記少なくとも1つのピクチャーオブジェクトのピクチャー名称と画像ソースパスを前記ウェブページアプリケーションキャッシュに保存することを実現するように構成される。
本開示のいくつかの実施例において、前記チェック部はさらに、前記少なくとも1つのピクチャーオブジェクトのピクチャー名称に基づいて、セッションデータ取得方法を呼び出し、前記セッションデータから前記少なくとも1つのピクチャーオブジェクトの抽出を実行し、前記セッションデータ取得方法の呼び出しが成功した場合、前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在することを確認し、前記セッションデータ取得方法の呼び出しが失敗した場合、前記セッションデータに前記少なくとも1つのピクチャーオブジェクトが存在しないことを確認するように構成される。
本開示の実施例は、画像処理方法に対応する画像処理装置を提供する。図10は本開示の実施例によって提供される画像処理装置の構造概略図である。図10に示すように、画像処理装置200は、プロセッサ715と、メモリ716と、通信バス717と、を含む。前記メモリ716は、前記通信バス717によって前記プロセッサ715と通信し、前記メモリ716は、前記プロセッサ715によって実行可能な命令を記憶し、前記命令が実行される場合、前記プロセッサ715によって、上記の実施例のいずれかの画像処理方法を実行する。
【0046】
本開示の実施例は、画像処理装置に応用するコンピュータ可読記憶媒体を提供する。記憶媒体は、1つ又は複数のコンピュータプログラムを記憶し、上記の実施例のいずれかの画像処理方法を実現するように、1つ又は複数のコンピュータプログラムは、1つ又は複数のプロセッサによって実行できる。
本開示の実施例は、方法、システム、又はコンピュータプログラム製品として提供できることを、当業者に理解されたい。したがって、本開示は、ハードウェアの実施例、ソフトウェアの実施例、又はソフトウェアとハードウェアを組み合わせる実施例のいずれかの形態をとることができる。さらに、本開示は、コンピュータ使用可能なプログラムコードを含む1つ又は複数のコンピュータ使用可能な記憶媒体(ディスクメモリ、光メモリなどを含むが、これを限定されるものではない)に実行されるコンピュータプログラム製品の形態をとることができる。
本開示は、本開示の実施例に基づく方法、機器(システム)及びコンピュータプログラム製品のフローチャート及び/又はブロック図を参照して説明される。理解可能なこととして、フローチャート及び/又はブロック図におけるフローのそれぞれ及び/又はブロック、そしてフローチャート及び/又はブロック図におけるフロー及び/又はブロックの組み合わせは、コンピュータプログラム命令によって実現できる。該当するコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又は他のプログラマブルデータ処理機器のプロセッサに提供され、マシンを生成し、これによって、コンピュータ又は他のプログラマブルデータ処理機器のプロセッサによって実行される命令は、フローチャートにおける1つ又は複数のプロセス及び/又はブロック図における1つ又は複数のブロックで指定される機能を実現するために用いられる装置を生成することができる。
【0047】
該当するコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理機器は特定の方式で動作するように引導できるコンピュータ可読メモリに記憶されてもよく、これによって、該コンピュータ可読メモリに記憶される命令は、命令装置を含む製品を生成し、該命令装置は、フローチャートにおける1つ又は複数のプロセス及び/又はブロック図における1つ又は複数のブロックで指定される機能を実現する。
該当するコンピュータプログラム命令は、コンピュータ又は他のプログラマブルデータ処理機器にロードされてもよく、コンピュータ又は他のプログラマブル機器に一連のステップを実行し、コンピュータで実現する処理を生成するようになる。これによってコンピュータ又は他のプログラマブル機器に実行される命令は、フローチャートにおける1つ又は複数のプロセス及び/又はブロック図における1つ又は複数のブロックで指定される機能を実現するために用いられるステップを提供する。
以上は、本開示の最適的な実施例に過ぎなく、本開示の保護範囲を限定するためのものではない。
【産業上の利用可能性】
【0048】
本開示の実施例の方法によって、画像処理装置は、少なくとも1つのページ画像を取得した後で、少なくとも1つのページ画像を少なくとも1つのファイルオブジェクトに変換し、少なくとも1つのファイルオブジェクトのリンクパスを少なくとも1つのピクチャーオブジェクトと関連付けてキャッシュに保存することができ、これによってスクリーンショットを他のコーディングフォーマットに変換することによりキャッシュ占有率が大きいという技術的問題を克服する。そして、現在のフルスクリーンページの少なくとも1つのピクチャーオブジェクトは、キャッシュに保存されるため、ユーザが現在のフルスクリーンページに再び入ってスクリーンショットを撮りたい場合、画像処理装置は、直接にキャッシュから少なくとも1つのピクチャーオブジェクトを取得し、対応するページのスクリーンショットとすることができ、再びスクリーンショットを撮る必要がなく、ブラウザ処理の作業負荷を軽減し、最終的にウェブページアプリケーションのスクリーンショットの性能を向上させる。
図1
図2
図3
図4
図5
図6
図7A
図7B
図7C
図8
図9
図10
【国際調査報告】