JP2023540872A - 病理組織スライドの改善された可視化及びレンダリングを提供するために電子画像を処理するシステム及び方法 - Google Patents

Abstract

電子画像を処理するための方法は、ビューアによって、電子画像及びＦＯＶ（視野）を受信することであって、ＦＯＶは少なくとも１つの座標、少なくとも１つの寸法、及び拡大因子を含む、受信することと、ビューアによって、ＦＯＶ内に複数のタイルをロードすることと、ビューアによって、キャッシュ内の複数のタイルの状態を決定することと、キャッシュ内の複数のタイルの状態が全ロード状態であると決定することに応答して、ビューアによって、複数のタイルをディスプレイにレンダリングすることとを含む。【選択図】なし

Description

関連出願（複数可）
本出願は、２０２０年８月１１日に出願された米国仮出願第６３／０６４，４０１号に対する優先権を主張するものであり、その全体の開示は、参照により、その全体が本明細書に援用されている。

本開示の様々な実施形態は、一般に、病理組織スライドの可視化及びレンダリングを改善することに関する。より具体的には、本開示の特定の実施形態は、病理組織スライドの改善された可視化及びレンダリングを提供するために電子画像を処理するシステム及び方法に関する。さらに本開示は、機械学習、人工知能、及びコンピュータビジョンを使用して、電子画像を処理し、病理組織スライドの改善された可視化及びレンダリングを提供するためのシステム及び方法を提供する。

病理組織スライドには、生検から抽出され、顕微鏡検査用にスライドガラス上に置かれた組織切片がある。組織が顕微鏡下で可視であるように、これらの切片を１つまたは複数の色素で染色する。最も一般的な色素は、スライドに目立つピンクの色合いを与えるＨｅｍａｔｏｘｙｌｉｎ ａｎｄ Ｅｏｓｉｎ（Ｈ＆Ｅ）のものである。これらのスライドは、歴史的に顕微鏡下で検査され得るが、近年ではデジタルパソロジーの推進が見られる。デジタルパソロジーでは、スライドを非常に高い解像度でスキャンして、後でモニタに表示することができる。デジタルパソロジーには一定の利点があるが、所望の画像及び視野を提供するのに十分な解像度でスライドをスキャンして可視化することは困難な場合がある。

前述の一般的な説明と以下の詳細な説明は、例示的及び説明的なものに過ぎず、本開示を限定するものではない。本明細書で提供される背景説明は、本開示の文脈を一般的に提示することを目的としている。本明細書で別段の指示がない限り、この条文に記載されている資料は、本出願での特許請求の範囲に対する先行技術ではなく、この条文に含めることによって、先行技術または先行技術の示唆であるとは認められない。

本開示の特定の態様によれば、電子画像を処理して病理組織スライドの改善された可視化及びレンダリングを提供するためのシステム及び方法を開示する。

電子画像を処理するためのコンピュータ実装方法であって、この方法は、ビューアによって、電子画像及びＦＯＶ（視野）を受信することであって、ＦＯＶは少なくとも１つの座標、少なくとも１つの寸法、及び拡大因子を含む、受信することと、ビューアによって、ＦＯＶ内に複数のタイルをロードすることと、ビューアによって、キャッシュ内の複数のタイルの状態を決定することと、キャッシュ内の複数のタイルの状態が全ロード状態であると決定することに応答して、ビューアによって、複数のタイルをディスプレイにレンダリングすることとを含む。

電子画像を処理するためのコンピュータシステムであって、このコンピュータシステムは、命令を格納する少なくとも１つのメモリ、及びこれらの命令を実行して操作を行うように構成された少なくとも１つのプロセッサを含み、これらの操作は、ビューアによって、電子画像及びＦＯＶ（視野）を受信することであって、ＦＯＶは少なくとも１つの座標、少なくとも１つの寸法、及び拡大因子を含む、受信することと、ビューアによって、ＦＯＶ内に複数のタイルをロードすることと、ビューアによって、キャッシュ内の複数のタイルの状態を決定することと、キャッシュ内の複数のタイルの状態が全ロード状態であると決定することに応答して、ビューアによって、複数のタイルをディスプレイにレンダリングすることとを含む。

命令を格納する非一時的なコンピュータ可読媒体であって、これらの命令は、プロセッサによって実行されると、電子画像を処理するための操作をプロセッサに実行させ、これらの操作は、ビューアによって、電子画像及びＦＯＶ（視野）を受信することであって、ＦＯＶは少なくとも１つの座標、少なくとも１つの寸法、及び拡大因子を含む、受信することと、ビューアによって、ＦＯＶ内に複数のタイルをロードすることと、ビューアによって、キャッシュ内の複数のタイルの状態を決定することと、キャッシュ内の複数のタイルの状態が全ロード状態であると決定することに応答して、ビューアによって、複数のタイルをディスプレイにレンダリングすることとを含む。

上述の概略的な説明と以下の詳細な説明は共に、例示で単に説明をしているものであり、クレームされているように、開示の実施形態を限定するものではないという旨を理解すべきである。

添付の図面は、この明細書の一部に組み込まれ、これを構成し、種々の例示の実施形態を図示しており、この説明と併せて、開示している実施形態の原理を説明する役目を果たしている。

本開示の例示的な実施形態による、全スライド画像のピラミッド構造を示す。 本開示の一実施形態による、例示的なビューアの視野（ＦＯＶ）を示す。 本開示の一実施形態による、例示的なビューアのアーキテクチャを示す。 本開示の一実施形態による、ビューアからの例示的なタイル要求のタイミング詳細を示す。 本開示の一実施形態による、例示的なタイル要求の制御フローを示すフローチャートである。 本開示の一実施形態による、ビューアのアーキテクチャである。 本開示の一実施形態による、ビューアのネイティブアプリケーションのアーキテクチャである。 本開示の一実施形態による、タイル要求の制御フローを示すフローチャートである。 本開示の一実施形態による、レイテンシインジケーションを有するタイル要求の制御フローを示すフローチャートである。 本開示の一実施形態による、タイル要求の静的制御フローを示すフローチャートである。 本開示の一実施形態による、ビューアアーキテクチャのメインループを示すフローチャートである。 本開示の一実施形態による、ビューア内のスライドの第１外見を示す。 本開示の一実施形態による、ビューア内のロード視野を示す。 本開示の一実施形態による、例示的なビューア内にタイルをプリロードする視野を示す。 本開示の一実施形態による、ビューア内にデコードする例示的なタイルのタイミング詳細を示す。 本開示の一実施形態による、動的タイリングによる例示的な実施形態の視野（ＦＯＶ）完了を示す。 本開示の一実施形態による、静的タイリングによる例示的な実施形態のＦＯＶ完了を示す。 本開示の一実施形態による、タイルプリロードによる例示的な実施形態のＦＯＶ完了を示す。 本開示の一実施形態による、例示的な実施形態の異なるＦＯＶ完了を示す。 本開示の一実施形態による、例示的な実施形態の異なるＦＯＶ完了を示す。 本開示の一実施形態による、例示的な実施形態の異なるＦＯＶ完了を示す。 本開示の一実施形態による、例示的な実施形態の異なるＦＯＶ完了を示す。 本開示の一実施形態による、例示的な実施形態の異なるＦＯＶ完了を示す。 本開示の一実施形態による、例示的な実施形態の異なるＦＯＶ完了を示す。 本開示の一実施形態による、ストリーミングビューアの例示的なアーキテクチャである。

これから本開示の例示的な実施形態について詳細に言及するが、それらの例は添付の図面に示されている。可能な場合は必ず、図面全体を通して、同じまたは類似の部分を示すために、同じ参照番号が使用される。

本明細書で開示されるシステム、デバイス、及び方法は、例として、そして図面を参照して詳細に説明される。本明細書で説明される例は、単なる例であり、本明細書で説明される装置、デバイス、システム、及び方法の説明を助けるために提供される。図面に示されている、または以下で説明されている特徴またはコンポーネントは、特に必須として指定されない限り、これらのデバイス、システム、または方法のいずれかの任意の特定の実装に必須と見なされるべきではない。

また、説明されるいずれかの方法については、その方法がフロー図に関連して説明されているかどうかに関係なく、文脈による別段の指定または要求がない限り、方法の実行で行われるステップのいずれかの明示的または黙示的な順序付けにより、これらのステップを提示された順序で実行する必要があることが黙示されないが、代替に別の順序でまたは並列して実行することができることを理解されたい。

本明細書で使用される場合、用語「例示的」は、「理想的」ではなく「例」の意味で使用される。さらに、本明細書における「ａ」及び「ａｎ」という用語は、量の制限を意味するのではなく、むしろ言及された項目のうちの１つ以上が存在していることを意味する。

スキャナの製造元は、多くの場合、スキャナと共にスライドを可視化する独自のソフトウェアを維持している。また、製造元は、これらのスライドを、第三者のソフトウェアがほぼ同じ方法で開いて読み出すことを可能にする場合がある。これらのソフトウェアパッケージまたはモジュールは、一般にスライドビューアと呼ばれる。本開示は、とりわけ、様々なスキャナから取得されたスライドを開くことができる新規のスライドビューアの例示的な実施形態を含む。このビューアは、最新のすべてのインターネットブラウザ（すなわち、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ、Ｍｏｚｉｌｌａ Ｆｉｒｅｆｏｘ、Ｍｉｃｒｏｓｏｆｔ Ｅｄｇｅ、Ａｐｐｌｅ Ｓａｆａｒｉなど）で実行することができる。スライドビューアは、そのスライド表示機能に加えて、がん検出のために高度な医療用の人工知能推論を特徴付けることによって、他の製品と連携することもできる。

スライドスキャンは、解像度が２０，０００ｘ２０，０００から１２０，０００ｘ１２０，０００ピクセル以上にわたる画像である。これらの画像は、記述的に全スライド画像（ＷＳＩ）と称され、非可逆圧縮の後でもディスク上で複数ギガバイトの重さになる可能性があり、クライアントに効率的に転送されてタイムリーな方法で表示されることができない。大規模なデジタル画像の処理には、特定の技術的障害が存在する。最初に、帯域幅は、特定の時間内に転送することができるデータ量を制限する因子である。ビューアにインターネット経由でアクセスするため、通常、この帯域幅には１秒あたり数メガバイトの上限がある。これは、ギガバイトの画像を転送するには数秒またはさらに数分かかることを意味する。さらに、これらの画像をデコードするために、かなりの処理能力が必要になる場合がある。小さい２５６ｘ２５６画像をミリ秒単位でデコードすることができるが、ギガピクセル画像のデコードには数分ではないにしても数秒かかる。最後に、メモリに関しては、圧縮された画像の重さはギガバイトのオーダーになることがあるが、圧縮されていないデータは桁違いに大きくなる。このような量のデータは、コンピュータのメモリに一度に収まらない。

目標の１つは、ＷＳＩに関して現在の技術スタックを改善する方法を見つけることである。本開示によって対処されるいくつかの関心領域には、病理組織スライドデータをストリーミングする新しい方法が含まれる。現在のスライドビューアは、オープンソースライブラリ及びベンダーのソフトウェア開発キット（ＳＤＫ）を使用して、スライドを開いて読み出すことができる。これらのオプションは、最も効率のよいものではないが、より優れた技法により、ストリーミングが有意に高速化される可能性がある。

例えば、これは、スライドがディスク上に格納されている場合、スライドのデータ表現フォーマットを変更して、新しい最適化を有効にすること、または既存の最適化を最大限に活用することを伴うことがある。歴史的に、スライドは、スキャナのベンダーに完全に依存する、それらの元のフォーマットで格納されてきた。ベンダーが異なれば制約も異なる場合があり、これは、ユニファイドフォーマットがないと、考えられるすべての経路を最適化することが難しくなる可能性があることを意味する。

新しい圧縮技法は、スライド表示の現在の技術を改善する可能性もある。この研究軸は、スライド画像データをより効率的に格納することができる新しい圧縮技法に焦点を当てる。例えば、組織検出アルゴリズムは、組織が検出されなかった画像の大部分を格納する必要がないようにすることができる。新しい画像フォーマットでは、エンコード時により高度な技法またはより多くの計算能力を活用することで、より優れた圧縮率が得られる場合もある。

さらに、サーバ側のレンダリングは、現在のスライド表示技術を改善する可能性がある。仮想ネットワークコンピューティング（ＶＮＣ）テクノロジは、ビジュアルフィードをクライアントにストリーミングし、クライアントがユーザ入力をサーバに送信することで、リアルタイムのインタラクティブなエクスペリエンスを構築することができることを証明している。このようなアプローチは、パフォーマンスの高いビデオコーデックのおかげでデータ転送を最小にすることができ、優れたユーザエクスペリエンスを可能にする可能性がある。

さらに、スライド表示技術の改善には、フロントエンドレンダリング技法が含まれる場合がある。Ｗｅｂブラウザは、グラフィックスプロセッシングユニット（ＧＰＵ）レンダリングを利用できるようになった。ＷｅｂＧＬアプリケーションプログラミングインタフェース（ＡＰＩ）により、ＪａｖａＳｃｒｉｐｔ（登録商標）アプリケーションは、３Ｄレンダリングの業界標準であるＯｐｅｎＧＬに触発されたイディオムでレンダリング命令を実行することが可能になる。最近では、ＷｅｂＧＬ２．０及びＷｅｂＧＰＵなどの新しいＡＰＩは、ＧＰＵプリミティブへの低レベルのアクセスを可能にすることで、さらに進化している。これらのテクノロジをスライドビューアに適用して、スライドビューアを高速化し、そのメモリ消費を削減することができる。

以下のセクションでは、特定の語彙を使用して、例示的なＷＳＩビューアに関連する概念を説明する。

前述のように、ＷＳＩは病理組織スライドの高解像度画像スキャンである。これらの画像の解像度はギガピクセルに及ぶ。この特性により、これらの画像を従来の方法で格納して表示することは現実的ではない。実際、メモリ内の全画像をデコードすることは、現在利用可能な多くのパーソナルコンピュータのメモリ容量を超える数十ギガバイトを占めるようになるため、非常に困難である。さらに、モニタの解像度はメガピクセルに近くなるため、全画像を表示することも困難である。

したがって、ＷＳＩは、領域のデコードを可能にするような方法でエンコードされる。画像の各領域は、それで全画像を読み出す、またはデコードする必要なく表示されることができる。前述のように、病理学者がスライドを表示するために使用するモニタは、通常、フル解像度の画像を表示することができない。その結果、通常、現在画面に提示されている領域のみがデコードされ、クライアントに送信され得る。この最適化により、リアルタイムでＷＳＩにインデックス付けして読み出すことが可能になる。

ただし、病理学者がズームアウトして全スライドを画面に表示することを決定する場合、このアプローチは不十分である。フル画像のダウンサンプリングされたバージョンを表示する場合でも、その全体を読み出す必要がある場合がある。これを改善するために、ＷＳＩには、フル解像度のベースライン画像に加えて、画面に収めることができるサムネイル画像まで、解像度の低い中間拡大レベルも含まれる。このような編成は、ピラミッド構造と呼ばれることが多く、ピラミッドの基部がベースライン画像であり、それより上の各レベルが中間拡大レベルである場合がある。

領域のデコードを可能にするために、各レベルは規則的なグリッド内でタイルにカットされることができる。これらのタイルにはランダムにアクセスできる。画像の領域をデコードするには、その領域にオーバーラップするタイルのみを読み出してデコードする必要があり得る。図１は、このピラミッド構造の模式図である。

図１に示されるように、ピラミッド構造は、フル解像度画像を含むベースライン画像１を有する。少なくとも１つのダウンサンプリングされた画像、すなわち、図１のダウンサンプリングされた画像２及び３は、ベースライン画像１の上に配置され得る。ベースライン画像１だけでなく、ダウンサンプリングされた画像２及び３は、上記のように規則的なグリッドにカットされ得る。

ビューアの視野（ＦＯＶ）は、現在ディスプレイ上にある画像のエリアである。これは、座標（ｘ，ｙ）、寸法（ｗ，ｈ）、及び拡大因子ｚのグループ化と考えられることができる。拡大因子は、ＷＳＩのどのレベルが表示に最も適しているかを決定することができ、座標及び寸法は、レベル画像のどの領域をデコードする必要があるかを決定することができる。

図２は、要求されたＦＯＶ１２を表示するために、レベル画像１０の少数のアクティブなタイル１１のみをどのようにデコードする必要がある場合があるかを示す。アイドルタイル１３は、ＦＯＶ１２に含まれない場合がある。

ＦＯＶ１２が移動すると、アクティブなタイル１１が変化する。表示に現在必要なタイルのみをメモリに保持する必要がある場合がある。したがって、必要なグラフィックスメモリは、画像のサイズの関数ではなく、ディスプレイの解像度の関数である可能性がある。

改善すべき様々なエリアをより適切に識別するために、考えられる１つのアプローチは、例示的なスライドビューアのアーキテクチャを詳しく調べることであった。例示的なスライドビューアのアーキテクチャが図３に示されている。例示的なスライドビューアは、フロントエンド２０及びバックエンド（「タイルサーバ」）３０から構成され得る。フロントエンド２０は、ＷＳＩをユーザに表示することに応答可能であり得、バックエンド３０は、潜在的に必要なデータをフロントエンドに通信することに応答可能であり得る。例示的なコンポーネントについてのさらなる詳細は、以下の節で開示される。

ユーザは、ウェブブラウザを介して例示的なスライドビューアにアクセスすることができるので、フロントエンド２０（図３に示されるような）は、ＪａｖａＳｃｒｉｐｔ（登録商標）で書き込まれたウェブアプリケーションであり得る。例示的なスライドビューアは、高解像度画像用のウェブベースのビューアであるＯｐｅｎＳｅａｄｒａｇｏｎオープンソースライブラリなどのビューア２１を広範囲に使用することができる。

ビューア２１、例えばＯｐｅｎＳｅａｄｒａｇｏｎは、ＷＳＩの一部またはすべてのレンダリング、ならびに「スライドナビゲーション」パネルを使用した周囲のパン、ズーム、及びジャンプなどのユーザインタラクションを処理することができる。ユーザは、マウスで画面をドラッグしてディスプレイをパンし、スクロールするとズームインすることもズームアウトすることもできる。ディスプレイの回転、物理的な距離の測定、キャンバスへのアノテーションの描画などの追加の機能がある場合がある。

上記に開示されたように、ＷＳＩは複数の拡大レベルに分割され、タイルにカットされる（図１のピラミッドを参照）。所与のＦＯＶを表示するために、ビューア２１（ＯｐｅｎＳｅａｄｒａｇｏｎなど）は、ＦＯＶをカバーするすべてのタイルを、タイルサーバとも呼ばれ得るバックエンド３０からロードする。

ＯｐｅｎＳｅａｄｒａｇｏｎは、高解像度画像を表示するための堅牢なソリューションである。ただし、ウェブプラットフォームを対象とする他の高解像度画像ビューアのソリューションと比較すると、ＯｐｅｎＳｅａｄｒａｇｏｎは、ユーザインタラクション中に常に一定の６０フレーム／秒（ＦＰＳ）を維持できるとは限らない。これにより、ユーザエクスペリエンスが最適ではなくなる可能性がある。Ｓｅａｄｒａｇｏｎは、２Ｄブラウザキャンバスのアプリケーションプログラミングインタフェース（ＡＰＩ）のみを使用するレンダリングのみをサポートする場合もある。その結果、ＷｅｂＧＬは、クライアントのグラフィカル機能をより有効に活用できる、よりパフォーマンスの高いＡＰＩとして使用されることができる。

ＯｐｅｎＳｅａｄｒａｇｏｎは、ブラウザで大きい画像を表示するために利用できる唯一の可能なソリューションではない。他の適切なビューアソリューションには、ＯｐｅｎＬａｙｅｒｓ、Ｌｅａｆｌｅｔ、ＭａｐＢｏｘ、及びＤｅｃｋＧＬが含まれる。これらのソリューションはすべて地理データ用に調整されているが、２Ｄピクセルデータをサポートするように適合されている場合もある。これらのソリューションの一部は、ＷｅｂＧＬをサポートし、優れたパフォーマンスを発揮する。ただし、不要な機能が含まれている場合がある。その結果、可能なソリューションの表面積が非常に大きくなり得、修正が難しくなる。

またフロントエンド２０は、ビジネスロジックアルゴリズム２２を含み得る。

例示的なスライドビューアのバックエンド３０は、Ｃ＃で書き込まれたウェブサーバ３１を含むことができる。ウェブサーバ３１は、ＨＴＴＰ要求を効率的に処理するために、ＩＩＳウェブサーバ３２上のソフトウェアを活用することができる。

バックエンド３０は、例示的なビューアで対象となるコンポーネントの１つであり、座標（ｘ，ｙ）及び拡大レベルｚで寸法（ｗ，ｈ）のタイルを要求されると、バックエンド３０は対応する画像を返す。例示的なスライドビューアが複数のＷＳＩフォーマットをサポートすることができるため、バックエンド３０は、図３に示されるように、Ｄｅｅｐ Ｚｏｏｍ実装３４などの様々な実装３４を呼び出すことができる。これらの実装３４は、元のＷＳＩファイルから要求された画像領域をデコードするロジックを所有する。一般に、ＷＳＩファイルは、バックエンド３０に関連付けられたファイルシステム３５に格納されることができる。

Ｄｅｅｐ Ｚｏｏｍは、非常に大きい画像をストリーミングして可視化するためのテクノロジである。Ｄｅｅｐ Ｚｏｏｍ Ｉｍａｇｅ（ＤＺＩ）は、ＤＺＩファイル及びディレクトリという２つの部分から構成される。ＤＺＩファイル（．ｄｚｉ）は、可視化のために画像のフォーマットを記述する。２つの重要なプロパティは、タイルサイズ及びベースライン解像度であり得、これらから、ベースライン解像度に２の負の冪乗を乗算することで、中間拡大レベルの一部またはすべてを推論することができる。例えば、ベースライン解像度が１０２４×１０２４である場合、中間レベルでは第１解像度が５１２×５１２、第２解像度が２５６×２５６などである。ＤＺＩファイル以外に、ディレクトリにはタイル画像の一部またはすべてが含まれ得、それら自体は、様々な拡大レベルに対応するフォルダに配置され得る。例えば、ｔｉｌｅｓ／３／１＿２．ｊｐｇというパスに格納されているファイルは、拡大レベルｚ＝３、及び座標（ｘ，ｙ）＝（１，２）のタイルに対応する。ｚ＝３では、レベル解像度はベースライン画像の８分の１である。

ウェブサーバのパフォーマンスに関しては、タイル要求はほぼ即時に行われる必要がある。ビューアの応答性を感じるためには、タイル要求のレイテンシが低く、スループットが高いことが必要になる場合がある。そのため、タイルを取得して提供するためのパイプラインは、利用可能な最速のテクノロジを使用して、できるだけ短く保つ必要がある場合がある。この場合、ＩＩＳなどの本格的なウェブサーバを使用するのは過剰である場合がある。

Ｃ＃で低レイテンシシステムを構築することは可能であり得るが、言語によっては難しくなる場合がある。Ｃ＃は、メモリの割り振りが自動的に行われ、プロセスが割り振られたオブジェクトのグラフを時々走査し、割り振りを解除してメモリを解放することができるオブジェクトを決定し得るという難しいコレクション言語である。これは、Ｃ＃が完全にメモリセーフであることを意味し、プログラマは、メモリ管理について心配する必要がほとんどない。ただし、このプロシージャはコストがかからないわけではなく、要求がペンディング中であるときに同時に実行すると、レイテンシのスパイクが発生する可能性がある。さらに、ガベージコレクション言語は、オブジェクトのライブネスを追跡し続けるために、平均してより多くのメモリを使用する場合がある。最後に、コンパイルされたＣ＃コードが仮想マシン上で実行されるが、これには独自のパフォーマンス及びメモリ使用量というコストがかかる。パーソナルマシンでは、サーバの開発バージョンは、ＨＴＴＰ要求への回答を開始することができる前に丸一分かかり、最大７００ＭＢのメモリを割り振る場合がある。これらの数は両方とも、異なる実装及びバッキングテクノロジによって大幅に削減される可能性がある。

図４及び図５は、ユーザの視点からのタイル要求のタイミング及び制御フローの簡単な概要を提供する。タイル要求の制御フローは、基になるアルゴリズムの簡略化されたバージョンである。

図４に示されるように、タイムラインメトリックは、要求４１、最初のバイトまでの時間（ＴＴＦＢ）４２、ダウンロード４３、デコード４４、及び描画４５にかかり得る相対時間を含み得る。ダウンロード４３などの低速パスは縞模様で表され、ＴＴＦＢなどの低速操作は別の太い縞模様で表される。要求４１は、タイル要求の制御フロー内で比較的短い時間を含み得るのに対し、ＴＴＦＢは比較的はるかに長い時間を要する可能性がある。最初のバイトまでの時間（ＴＴＦＢ）４２のメトリックは、サーバのレイテンシを表し、本開示の残りの部分に関して最も注目され得るメトリックである。またダウンロード４３は、制御フロー内で比較的長い時間を要する可能性があるが、デコード４４及び描画４５のステップは比較的迅速に完了する可能性がある。

図５は、ユーザの視点からタイル要求のタイミング及び制御フローの概要方法５０を示すフローチャートである。

ステップ５１では、この方法は、ビューアが座標（ｘ，ｙ，ｚ）でタイルを要求することを含むことができる。この要求は、ＨＴＴＰプロトコル経由で送信される場合がある。

ステップ５２では、図３に示されるようなタイルサーバまたはバックエンド３０などのサーバは、その要求を受信し得、サーバが要求されたタイルを既に準備しているかどうかを決定することができる。

ステップ５３ａでは、スライドの準備ができていないとサーバが決定した場合、サーバは、ストレージデバイスからスライドをロードすることができる。

ステップ５３ｂでは、代替に、スライドの準備が既にできているとサーバが決定する場合、この方法は、サーバが要求された座標にタイルを既に準備できているかどうかを決定し得ることを含み得る。

ステップ５４では、スライドがストレージからロードされた場合、またはサーバがまだタイルを準備できていない場合、方法は、サーバが要求されたタイルを生成し、それを格納することを含むことができる。

ステップ５５では、この方法は、ビューアが、ステップ５４で生成されたタイルか、ステップ５３ｂでサーバによって既に処理されたタイルかいずれかをサーバから受信することを含むことができる。

スライドビューアの例示的な実施形態は、２つの目標を有する。第一に、スライドビューアは高速である必要がある。ＦＯＶがロードされるまでユーザは長く待つ必要がなくなり得、ビューアはパン及びズームの際に一定の６０ＦＰＳを維持する必要がある。病理学者は顕微鏡に慣れており、レイテンシは光速によってのみ制限される。例示的なビューアの場合、このエクスペリエンスを可能な限り複製するよう努めることが好ましい場合がある。最終的な目標は、知覚できるレイテンシを有しないことである。参考までに、１００ｍｓの応答時間は、ユーザに即時フィードバックの感覚を与えるための上限と見なされる。

第二に、スライドビューアには測定可能である必要がある。例示的なビューアが使用中にどのように機能するかについて、正確なメトリックを提供できることが重要な場合がある。既存のスライドビューアと比較するには、現実的なロードを表すベンチマークスイートが必要である。

一般に、スライドビューアなどのウェブアプリケーションには定数が１つある。ＪａｖａＳｃｒｉｐｔ（登録商標）は、主にウェブの言語であり、以前はブラウザがネイティブに実行する唯一の言語であった。

最近、ブラウザは、ウェブプラットフォームを対象としたアセンブリコードの一種であるＷｅｂＡｓｓｅｍｂｌｙ（Ｗａｓｍ）を実行するための仮想マシンを実装し始めた。ブラウザではセキュリティが最も重要であるため、完全にサンドボックス化されるように設計される。ウェブサイトを訪問するだけで、そのウェブサイトがマシンを介して完全にアクセスできることは望ましくない。Ｗａｓｍのその利点は別として、ＪａｖａＳｃｒｉｐｔ（登録商標）よりもはるかに実行速度が高速であることもある。ブラウザがＪａｖａＳｃｒｉｐｔ（登録商標）を実行するには、次のステップを実行することができる：
ａ．元のＪａｖａＳｃｒｉｐｔ（登録商標）ソースをダウンロードする。
ｂ．ＪａｖａＳｃｒｉｐｔ（登録商標）を抽象構文木（ＡＳＴ）にパースする。
ｃ．ＪａｖａＳｃｒｉｐｔ（登録商標）をマシンコードにコンパイルするが、これは実装によって異なる場合がある。歴史的に、ＪａｖａＳｃｒｉｐｔ（登録商標）は完全にインタプリタ言語であった。ジャストインタイム（ＪＩＴ）コンパイルの出現により、それをコンパイル済み言語と呼ぶことが一般的になった。
ｄ．ＪａｖａＳｃｒｉｐｔ（登録商標）を実行する。

上記のステップは、プロセスの概要を示す。実際には、一部のステップは部分的にスキップされる場合がある。例えば、ブラウザのＪａｖａＳｃｒｉｐｔ（登録商標）エンジンは、その実行を開始するためにＪａｖａＳｃｒｉｐｔ（登録商標）ソース全体をパースする必要がない。実際、字句解析器を使用して、最初の実行には必要のない可能性があるコードのセクション全体を迅速にジャンプすることができる。これは、遅延コンパイルと呼ばれることがある。

ただし、一部のステップは完全に最適化されることができない。最新のＪａｖａＳｃｒｉｐｔ（登録商標）コードは、クライアントに送信される前に縮小されて圧縮されても、生のバイトコードよりも重くなる。同様に、場合によってはパースをスキップすることができるが、ある時点で行う必要がある。ＪＩＴコンパイルは、優れたパフォーマンスを発揮することができるが、ランタイムに追加のステップが必要になる。

バイトコードとして、Ｗａｓｍはこれらの問題のほとんどにエレガントなソリューションを提供する。ただし、さらに重要なのは、Ｗａｓｍがコンパイルターゲットであることである。これは、Ｗａｓｍバックエンドを実装する任意の言語がブラウザ２で実行できる可能性があることを意味し、これは、ウェブの歴史において非常にエキサイティングな開発である。

Ｒｕｓｔは、Ｃ及びＣ＋＋のように、多くの興味深いプロパティを有する新しい最新の言語であり、この言語は、手動のメモリ管理を特徴としており、プログラムのメモリ消費パターンを正確に制御することができる。

ただし、Ｃ及びＣ＋＋の両方とは異なり、Ｒｕｓｔはメモリセーフである。ライフタイムと、ビルトインされたリソースの取得は初期化である（ＲＡＩＩ）と呼ばれる新しい概念が含まれているおかげで、手動メモリ管理の複雑さと揮発性の多くはコンパイラ自体によって処理される。これは、デフォルトで明らかに安全でない操作を禁止することにより、プログラマエラーのクラス全体を除去する、Ｒｕｓｔの定義機能と考えられる。

Ｒｕｓｔは、コンパイルのためにＬＬＶＭ（低レベル仮想マシン）バックエンドにデファーする。したがって、ＲｕｓｔはＬＬＶＭコンパイラによって提供される多くの最適化を利用することができ、その結果、Ｃ／Ｃ＋＋の対応物と同じくらい高速で、場合によってはそれより高速なコードになる可能性がある。さらに、Ｌｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、ｍａｃＯＳなどを含む、すべてのＬＬＶＭターゲットがネイティブにサポートされる可能性がある。このリストにはＷａｓｍも含まれる場合がある。

またＲｕｓｔには、最新のプログラミング言語で期待される他の多くの機能、例えば、高度な型システム、ゼロコスト抽象化、パターンマッチング、関数プリミティブ、非同期プログラミング、ビルトインパッケージマネージャ及びコンパイルツールチェーン、ビルトイン自動コードフォーマット及びリンティング、ならびに自動Ｃ及びＣ＋＋バインディング生成が含まれるが、これらに限定されない。Ｒｕｓｔは依然として急速に進化しており、厳密な後方互換性ポリシーを維持しながら、さらに改善を提供する可能性がある。Ｒｕｓｔは、生のパフォーマンス及び反復速度により人気が高まっている。手動メモリ管理とネイティブターゲットとの組み合わせは、Ｒｕｓｔの実行速度にいかなる人為的な境界もない可能性があることを意味する。さらに、Ｒｕｓｔがガベージコレクションではないため、パフォーマンスは予測可能であり、「ラグスパイク」の影響がない。重要なのは、Ｒｕｓｔが安全であることであり、すべての重大なセキュリティバグの７０％がメモリの安全性の問題によって引き起こされたことが示されている。Ｒｕｓｔはブラウザで実行されることもできる。つまり、ユーザはＲｕｓｔコードベース及びＷａｓｍパフォーマンスのすべての利点を、ウェブアプリケーションに関連する過去の欠点なしで活用することができる。これにより、ブラウザとネイティブターゲットとの間でコードを共有することも可能になる。前述にかかわらず、現在存在するまたは今後開発される任意の所望の言語またはコードベースを使用して、本開示の実施形態に沿ってウェブサーバ及び／またはスライドビューアを実行できることが企図される。

図６Ａは、スライドビューア１００の例示的な実施形態の例示的な模式図である。フロントエンド６０では、コアビューア６１及びレンダリングロジックはＲｕｓｔで書き込まれることができるが、より高レベルのユーザインタフェースロジック６２はＲｅａｃｔ７を使用したＴｙｐｅＳｃｒｉｐｔ６で書き込まれることができる。タイルサーバまたはバックエンド７０については、現在、最もパフォーマンスの高いウェブサーバの１つと考えられているＡｃｔｉｘ Ｗｅｂウェブサーバなどのウェブサーバ７１が使用され得る。ルーティングロジック７２、画像デコードまたはスライドリーダロジック７３、及びファイルシステムロジック７４は、すべてＲｕｓｔで書き込まれてもよい。ただし、この例示的な実施形態の範囲内で、Ａｐｅｒｉｏ ＳＶＳスライドのサポートを実装することもできる。他のスライドフォーマットのサポートを実装するには、Ｃ＋＋ライブラリ（Ｐｈｉｌｉｐｓ ｉＳｙｎｔａｘなど）にバインディングして書き込むこと、またはデコードロジックを手動で再実装することを必要とする場合がある。ビューアのコアロジックがＲｕｓｔで書き込まれ得るため、ネイティブレンダリングなどの新しい可能性が開かれる。フロントエンド及びタイルサーバのコードベースを混在させることで、ネイティブバージョンのビューアをＬｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、及びｍａｃＯＳ上のウィンドウで実行することができる。

図６Ｂは、そのようなプログラムの例示的なアーキテクチャを示す。図６Ｂでは、ネイティブアプリケーション４００は、Ｒｕｓｔで書き込まれ、ビューア４０１、ユーザインタフェース４０２、スライドリーダ４０３、及び汎用ファイルシステム４０４を含む。

タイル要求の構造
ユーザが座標（ｘ，ｙ）及び拡大レベルｚ（座標（ｚ，ｘ，ｙ）と呼ばれる）でタイルを要求すると、タイルサーバは、図７Ａ及び図７Ｂに示されるプロシージャを開始する。このプロシージャは複数のステップ及び分岐を通過し、要求されたタイルに対応する画像がユーザに提供されて終了する。

図７Ａは、上述のように、ユーザからの例示的なタイル要求プロシージャ７００（例えば、ステップ７０２～７１０）を示すフロー図である。例示的なタイル要求プロシージャ７００のすべてのステップはオプションであってもよく、任意の順序で完了してもよい。各ステップの発生は、ステップ間の線パターンでの違いによって示されるように、変化し得る。線の１つのパターンの破線は、ステップが常に、頻繁に、またはまれに発生することを表し得、連続した切れ目のない線は、ステップがごくまれにしか発生しない（つまり、ステップ７０５、７０６及び７０７の発生など、通常は１回だけ発生する）ことを表し得る。

例示的なタイル要求プロシージャ７００では、ユーザ７０１は、サーバからタイルを要求することができる。特異的なタイル要求は、病理標本画像に関連付けられたデジタル画像の１つより多いタイルを含んでもよく、またはデジタル画像の唯一のタイルであってもよい。

ステップ７０２では、プロシージャは、タイル要求をサーバにルーティングすることを含み得る。

ステップ７０３では、サーバは、タイルがサーバによって生成されたかどうかを決定することができる。タイルがサーバによって生成された場合、下記のように、プロシージャはステップ７０９に進むことができる。

タイルがまだサーバによって生成されていない場合、サーバは、ステップ７０４では、要求されたタイルに関連付けられたスライドがキャッシュ内にあるかどうかを決定することができる。要求されたタイルが生成されていないが、ＷＳＩがキャッシュ内にあるという１つの場合には、サーバは、タイルに対応する領域を読み出すことができ、ステップ７０８で説明されるように、結果の画像ファイルをユーザに提供する。このファイルは、ステップ７１０で説明されるように、クライアントが同じタイルを再度要求する場合に保存され、その場合、プロシージャは領域デコードステップを完全にバイパスすることができる。

要求されたタイルに関連付けられたスライドがキャッシュにない場合、サーバは、ステップ７０５では、スライドがローカルファイルシステム（ＦＳ）上にあるかどうかを決定することができる。スライドがローカルファイルシステム上にある場合、以下に説明されるように、プロシージャはステップ７０７に進むことができる。

スライドがローカルファイルシステム上にない場合、サーバは、ステップ７０６ではスライドをローカルファイルシステムにダウンロードすることができる。スライドがローカルファイルシステムにダウンロードされると、サーバはステップ７０７でスライドを開くことができる。

ステップ７０８では、サーバはタイル領域を読み出すことができ、ステップ７１０でタイルファイルの保存に進むか、ステップ７０９でファイルをユーザ７０１に送り返すかいずれかができる。

ユーザが初めてスライドを要求する場合、またはスライドがキャッシュを出てローカルＦＳからクリアされた最後の要求から十分長い時間が経過した場合、サーバは、リモートＦＳ（例えば、アマゾンウェブサービス（ＡＷＳ）Ｓ３バケット）からローカルＦＳにスライドを取得し、それを開く必要がある場合がある。この操作は、クライアントがＷＳＩに関連するメタデータを最初に取得するときに、１回だけ発生する可能性がある。

図７Ｂで説明されるステップは、同じ例示的なタイル要求プロシージャ７００を示すが、レイテンシの発生と呼ばれる、各ステップに関連する時間コストをさらに示し得る。このレイテンシが合計されて、要求全体の全体的なレイテンシを形成し、ユーザはこれをＴＴＦＢメトリックとして経験する。

各ステップで発生するレイテンシは、各ステップの周りのパターン化された線で示され得る。例えば、点線パターンの線は、ステップで発生したレイテンシが１ミリ秒未満であることを示し得るが、細い線は、発生したレイテンシが１～１０ミリ秒の間のものであることを示し得るなど。

図８は、各ステップで発生したレイテンシを示すことによって図７を補完する。最速のパスは、タイルがサーバによって既に生成されており（ステップ７０３でサーバによって決定された）、提供されるだけでよい場合であり得る。この場合、タイルはＦＳに存在し、ユーザに直接ストリーミングされることができる。

ただし、最もよくある場合には、タイルは、ＦＳに存在せず、ＷＳＩから生成される必要があるが、スライドがキャッシュで使用できる場合がある。最速のパスと比較して、この場合は次の２つの追加のステップを伴う：
ａ．ブロックしているＷＳＩからタイル領域をデコードする。
ｂ．ブロックしていないＦＳにファイルを保存する：この操作はファイルの提供と並列して行われる。

最後に、まれに、スライドがキャッシュに存在せず（ステップ７０４でサーバによって決定されるように）、ローカルＦＳ上に存在しない可能性がある場合、サーバはＦＳからＷＳＩファイルを取得する必要がある場合がある（ステップ７０６でのように）。ファイルが非常に大きいため、これには最大数秒かかる場合がある。有益なことに、この場合は、通常、スライドがユーザによって最初に要求されるときに１回だけヒットするため、長いレイテンシが許容可能になる場合がある。

このアルゴリズムは、図５に示されるものと類似し得る。１つの例示的な実施形態の実装のオーバーヘッドが低くなるおかげで、以下に実証されるように、その平均レイテンシは短くなり得る。

領域デコード
ＷＳＩの領域をデコードするプロシージャは、画像フォーマットに完全に依存する場合がある。

ＷＳＩのそのようなフォーマットの１つは、ＴＩＦＦ画像コンテナフォーマットを使用するＳｃａｎＳｃｏｐｅバーチャルスライド（ＳＶＳ）画像形式であってもよい。これらの画像は、次の部分から構成される：
ａ．画像ヘッダのレジストリを指すヘッダ、
ｂ．画像メタデータのレジストリを指す画像ヘッダ、
ｃ．幅、高さ、記述、比色分析情報などの詳細を含む画像メタデータ、及び
ｄ．次の２つの異なるフォーマットのものであり得る画像データ：
ｉ．近接するピクセルロウ。これらのロウを合わせて垂直方向に積み重ねると、画像がリアセンブルされる。このフォーマットは、小さい画像に使用されることができる。ＳＶＳでは、これらはラベル画像、サムネイル画像及びマクロ画像である。
ｉｉ．上から下、左から右にリストされているタイル。この場合、画像は、矩形タイルの規則的なグリッドにカットされると、個別にエンコードされることができる。このフォーマットは、これらの大きい画像の部分的なデコードを可能にするために、画像の様々な拡大レベルに使用されることができる。この原理を図１に示す。

ＳＶＳファイルの画像データは、３つの異なる方法でエンコードされることができる。ラベル画像はＬＺＷ圧縮アルゴリズムを使用してエンコードされることができるが、サムネイル画像及びマクロ画像はＪＰＥＧでエンコードされることができる。ベースライン画像及び様々な拡大レベルは、ＪＰＥＧかＪＰＥＧ２０００かいずれかでエンコードされることができる。

タイルサーバによって公開される拡大レベル及びタイル寸法と、ＷＳＩに格納される拡大レベル及びタイル寸法とは異なる場合があるため、タイルを生成する目的で画像領域をデコードすることは、適切な拡大レベルで適切なタイルを単純にインデックス付けするよりも複雑である：
ａ．第一に、プロシージャは、拡大力がユーザによって要求されたものに最も近く、かつ可能であれば拡大力がより大きいＷＳＩレベルを選択することができる（拡大力が小さいものを選択すると、情報が失われる可能性がある）。
ｂ．次に、要求された領域をカバーするすべてのＷＳＩタイルは、選択されたＷＳＩレベルの拡大力に投影されている要求された領域の寸法に等しい寸法のバッファにブリットされる。
ｃ．次に、このバッファは、要求された領域の寸法に線形にリサンプリングされる。クライアントが要求するレベルの拡大力が選択されたＷＳＩレベルのものと等しい場合、このステップは必要ない場合がある。

最後に、領域は、デコードされてクライアントに提供されることができる前に、ブラウザが理解する画像フォーマットにエンコードされて戻される必要がある場合がある。画像フォーマットのさらなる詳細については、以下に見いだされる。例示的なタイルサーバでは、画像は７５の画質設定でＪＰＥＧにエンコードされる。

この一連の操作には、多すぎる画像のデコード、場合によっては画像のリサイズ、及び最終結果のエンコードが含まれる場合がある。これには１０～１００ｍｓのいずれかがかかることがあり、異常な場合では時にはそれ以上かかることもある。これらのステップのパフォーマンスは、使用されるエンコード、デコード、及びリサイズのアルゴリズムにも依存する。タイルサーバの例示的な実施形態では、現在の最良のＲｕｓｔ実装よりも少なくとも２倍の速さであるため、ＭｏｚＪＰＥＧ５画像デコーダ及びエンコーダを使用することができる。

画像フォーマット
様々なコンテナフォーマット及び圧縮技法：ＳＶＳ（．ｓｖｓ）、Ｐｈｉｌｉｐｓ ｉＳｙｎｔａｘ（．ｉｓｙｎｔａｘ）、Ｈａｍａｍａｔｓｕ（．ｖｍｓ、．ｖｍｕ、．ｎｄｐｉ）、Ｌｅｉｃａ（．ｓｃｎ）、ＭＩＲＡＸ（．ｍｒｘｓ）、Ｓａｋｕｒａ（．ｓｖｓｌｉｄｅ）、及びその他のＴＩＦＦバリアントを使用する多数のＷＳＩフォーマットが存在する。これらのフォーマットは、対応する製造元のスキャナの出力である場合がある。一部のスライドビューアは、オリジナルを格納してもよく、ベンダーフレームワーク及びＯｐｅｎＳｌｉｄｅオープンソースライブラリを使用して、ユーザがスライドを開いて表示するたびに画像を開いて読み出してもよい。ただし、このプロセスにはいくつかの欠点があり得る。

フレームワークがスライドを読み出すためには、スライドがローカルＦＳに存在する必要がある場合がある。タイルをダウンロードすると、またはリモートＦＳをマウントすると、プロセスにレイテンシが追加される。さらに、これらのファイルが非常に大きいため、ホットストレージに保持するコストは経済的ではない。

第二に、これらのフレームワークにはそれぞれ独自の実装、ビヘイビア、及びＡＰＩがある場合がある。これにより、それらの間でパフォーマンスプロファイルが異なる場合がある。その結果、一部のスライドフォーマットは他のスライドフォーマットよりもロードするのに時間がかかるため、ユーザエクスペリエンスはスライドフォーマットによって異なる場合がある。また、タイルサーバの複雑さも大幅に増加し、それらすべてを呼び出す必要がある場合がある。

最後に、ＷＳＩフォーマットで使用される圧縮技法は制御しにくい。一部のファイルフォーマットでは、今日では最適ではない可能性が高い古い圧縮技法が使用されるため、デコードに必要以上に多くのスペースを占有する、または多くの処理時間を費やす。

圧縮方法
ＳＶＳ及びＰｈｉｌｉｐｓ ｉＳｙｎｔａｘで使用される主な圧縮技法は、離散コサイン変換（ＤＣＴ）（ＪＰＥＧ）及び離散ウェーブレット変換（ＤＷＴ）（ＪＰＥＧ２０００）である。どちらも可逆圧縮（ＪＰＥＧ可逆拡張によるＪＰＥＧ）をサポートしているが、非可逆形式で使用される。

ＪＰＥＧ２０００は、ＪＰＥＧよりも新しい技法であり、同じ画質レベルでＪＰＥＧよりも優れた圧縮率をもたらす。ただし、計算コストが高くなるため、エンコード及びデコードが繰り返されるシナリオには適していない。さらに、ＪＰＥＧ２０００は、２０年前の登場以来、普及に失敗しており、病理組織スライドストレージなど、まれな場合でのみ使用されている。最後に、ＪＰＥＧ２０００はブラウザでネイティブにサポートされていないが、ＪＰＥＧはサポートされている。

圧縮方法
最近の画像圧縮技法には、次のものがある：
ａ．ＶＰ８コーデックを使用するＷｅｂＰ。現在最もパフォーマンスの高いフォーマットではないが、バージョン１４でサポートされる可能性があるＳａｆａｒｉを除く、すべての主要なブラウザでサポートされている。
ｂ．ＨＥＶＣコーデックを使用するＨＥＩＦ。現在、どのブラウザでもサポートされていない。
ｃ．ＡＶ１コーデックを使用するＡＶＩＦ。現在、どのブラウザでもサポートされていないが、Ｃｈｒｏｍｅ及びＦｉｒｅｆｏｘでサポートする予定である。
ｄ．ＦＬＩＦ。どのブラウザでもサポートされていない。
ｅ．ＪＰＥＧ ＸＬ。ファイナライズされておらず、どのブラウザでもサポートされていない。

前述のすべてのフォーマットは、一般的な場合ではＪＰＥＧより優れている可能性があり、多くの場合、ＪＰＥＧ２０００よりも優れている可能性もある。

本開示では、ＪＰＥＧ ＸＬが最も有望な画像フォーマットである可能性がある。Ｊｏｉｎｔ Ｐｈｏｔｏｇｒａｐｈｉｃ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＪＰＥＧ）の支援を受けて、次のプロパティが約束されている：
ａ．クラス最高の画像圧縮率及び画質、
ｂ．マルチスレッド及び単一命令複数データ（ＳＩＭＤ）に適合した設計による高速エンコード及びデコードパフォーマンス、
ｃ．ＪＰＥＧデコーダとの一部の後方互換性、ならびに
ｄ．レガシーＪＰＥＧファイルの可逆トランスコード。

さらに、ＪＰＥＧ ＸＬには、Ｂｒｕｎｓｌｉ１３ ＪＰＥＧリパッカも含まれる場合があるため、元のＪＰＥＧをバイト単位でリカバリすることができながら、ファイルサイズを縮小することができる。本開示の例示的な実施形態が格納するレガシーＪＰＥＧ画像ストリームの量を考慮すると、そのようなフォーマットを採用することで、大幅な節約をもたらす可能性がある。

前述のように、ＷｅｂＰ及びＳａｆａｒｉを除いて、現在、これらの新しいフォーマットはいずれもブラウザでネイティブにサポートされない。ただし、必ずしもこれらの使用がなくなるわけではなく、Ｗａｓｍのおかげで、これらのフォーマットの一部を依然としてブラウザでデコードできる可能性がある。特に、リファレンスＪＰＥＧ ＸＬ実装は、ＷｅｂＡｓｓｅｍｂｌｙをサポートして出荷される。

ブラウザのネイティブＪＰＥＧデコーダとは対照的に、Ｗａｓｍ実装では、マルチスレッドまたはＳＩＭＤを、これらの機能が現在ブラウザで部分的にしか利用できないため、利用できない場合がある。したがって、これらの実装が高速なクライアント側のデコードに必要なパフォーマンスを提供できるかどうかは不明である。それにもかかわらず、これらのフォーマットの一部は一般に現在利用可能な最高のＪＰＥＧデコーダよりも高速であるため、これが可能である可能性がある。

プレタイリング
タイル要求の構造は上記で説明されており、要求されたタイルが既に生成されている場合に、より高速なパスが発生することが説明されている。この考え方をさらに進めて、すべてのタイルが既に生成されていることをユーザが期待する場合、タイルサーバのアーキテクチャは単純化される可能性がある。実際、アーキテクチャは、静的ファイルサーバ、つまり、決して変更されないコンテンツを提供することを目的とし得るサーバになるところまで単純化される可能性がある。このようなサーバは、要求が非常に高速になるように高度に最適化されている場合がある。そのようなサーバのアーキテクチャが図８に示されている。

図８は、サーバアーキテクチャの例示的な実施形態を示すワークフローである。ワークフローは、サーバからファイルを要求し得るユーザ８０１から開始され得る。ステップ８０２では、ワークフローは、ファイルがサーバ上に存在するかどうかを決定するサーバを含むことができる。存在しないタイルをユーザが要求すると、対応するファイルがサーバ上に見つからず、エラー８０３がクライアントに送信される。しかしステップ８０４では、ファイルが存在する場合、サーバはファイルを提供することができる。

ホットパス（例えば、ステップ８０２と８０４との間のプロセス）は、ファイルを直接提供している。ただし、この場合には、クライアントが利用可能なタイルを正確に認識しているため、タイルサーバの通常の使用では望ましくないことがある。

このようなアーキテクチャには、それでもある時点でタイルが生成されることが含まれる。これは、スライドインジェストパイプラインの役割である可能性があり、関連付けられたサーバでスライドが使用可能になるとすぐに発生する可能性がある。そうすることで、できるだけ早くユーザが利用できるようになる。

プレタイリングは適切なソリューションのように思われる可能性があるが、それでも以下のようないくつかの欠点がある：
ａ．プレタイリングは、スライドが関連付けられたサーバに到着する時間からユーザに利用可能になる時間までの間にレイテンシが若干追加されることを黙示する。ただし、このようなプロセスは継続的で自動化されている可能性があり、ユーザは即時に結果を必要としない可能性があるため、これは実際には問題にならない場合がある。さらに、理論的には、タイルがまだ利用できない場合に元のタイルサーバのアーキテクチャにフォールバックすることで軽減されることができる。最後に、タイルを生成するプロセスが十分に高速である場合、これには数十秒の遅延しか発生しない可能性がある。
ｂ．オンデマンドのタイリングとは対照的に、プレタイリングは、スライドの生成されたすべてのタイルを常に格納することを黙示する場合がある。実際には、これにより、スライドを格納するために必要なスペースが２倍になり、ストレージコストが増加する。これにより、タイルの生成に必要な処理時間も最大になる。

ビューアのアーキテクチャ
一部の実施形態では、ビューアは、２つのメインループで実行することができる。第１ループは、バックグラウンドループであり、グラフィックスメモリでの画像の要求、デコード、及びロードだけでなく、キャッシュのプルーニング（またはキャッシュのソート）操作を処理する。第２ループはレンダリングループであり、ディスプレイへのレンダリングのみを処理する場合がある。

実行中、これら２つのループはビューアの異なるコンポーネントを呼び出す場合がある。コアは、タイルの可視性と、それらをディスプレイに描画するために必要な可能性のあるドローコールとを計算する。レンダラは、２Ｄ Ｃａｎｖａｓ、ＷｅｂＧＬ、または任意のネイティブグラフィックスＡＰＩであることができる、基になるグラフィックス実装へのバインディングとして機能する。ローダは、リモートソース（ウェブ）かローカルファイルシステム（ネイティブ）かいずれかから非同期的にタイルをロードする。

キャッシュはタイル画像及びＧＰＵテクスチャを格納し、最大占有率に達したときにキャッシュ自体をプルーニング（またはソート）することがある。キャッシュに格納されたタイルは、（１）タイル要求状態、または（２）全ロード状態、という２つの状態のうちの１つで格納され得る。タイル要求状態では、タイルは、タイルサーバまたは他のストレージデバイスからなど、ロードされているプロセス中である可能性がある。全ロード状態では、タイル画像が完全にロードされている可能性がある。さらに、例えば、前のグループからのタイルがまだ完全にロードされていない場合、ビューアは次のグループからのタイルを格納しない場合がある。

さらに、ビューアが実行されているプラットフォームに依存する第三ループ、つまり、マウスイベント及びキーボードイベントなどのユーザイベントを処理するイベントループが存在する場合があるブラウザでは、それは、ＪａｖａＳｃｒｉｐｔ（登録商標）エンジンによって自動的に処理される場合がある。イベントループは、ＦＯＶの変更が適用される位置であり、ユーザがディスプレイをクリックしてドラッグすると、イベントが発生し、それに応じてアプリケーションロジックがＦＯＶを更新する。

図９は、これら両方のループのフローチャートの要約９００である。

バックグラウンドループ９０１
バックグラウンドループ９０１は、ほとんどのバックグラウンド処理が行われる位置であり得る。次のフレームが開始する前に、プロセスに時間があるときにいつでも実行するようにスケジュールされることができる。バックグラウンドスレッドでスケジュールされる場合もある。バックグラウンドループ９０１は、次のように進行し得る：

ＦＯＶ９０３が与えられると、バックグラウンドループ９０１は、その中で現在可視なタイルを計算することができる。これは、ビューアのコアプロセッサが、ステップ９０５で、どのタイルが可視であるかを決定することによって達成され得る。

例えば、ビューアのＦＯＶが変更されると、ビューアは次の優先順位でキャッシュからグループでタイルをロードする場合がある：
ａ．ＦＯＶの拡大因子以上であり得る、拡大レベルでＦＯＶ内にあるタイル、
ｂ．ＦＯＶの拡大因子以上であり得る、拡大レベルでＦＯＶに境界を接するタイル、
ｃ．より高い拡大レベルでＦＯＶ内にあるタイル、及び
ｄ．より低い拡大レベルでＦＯＶ内にあるタイル。

さらに、ビューアがキャッシュからタイルをロードするときに、タイルが前もってキャッシュに格納されていなかった場合、タイルは自動的にキャッシュに格納される場合がある。

例えば、キャッシュから取得されたタイルは、ＦＯＶの拡大レベル以上の拡大レベルを有する場合がある。しかしながら、いくつかの実施形態では、タイルが無限大の任意の大きい拡大レベルに対して計算されない場合があるため、これは常に可能であるとは限らない。これらのような状況では、例えば、ＦＯＶの拡大因子が利用可能な最大のタイル拡大レベルを超えている可能性がある場合、利用可能な最大のタイル拡大レベルからのタイルをキャッシュから取得することができる。

ＦＯＶの拡大因子は連続値であってもよい。例えば、ＦＯＶ拡大因子は０．１、２．０であってもよく、または０．１２３４５６．．．などであってもよい。タイルまたはＷＳＩの拡大レベルは、タイルのセットであり得、タイルのセットは、離散的で有界な拡大因子、例えば、１、２、４、８などに対応し得る。例えば、ＦＯＶの拡大因子が２である場合、拡大レベルが２以上のタイルがロードされる場合がある。ただし、それらのようなタイルが存在しない場合、利用可能な最大拡大因子を有する拡大レベルのタイルをロードする場合がある。このようなプロセスは、タイルサーバ及び／またはビューアで発生する可能性がある。

ビューアのキャッシュ内にタイル９０７のいずれも見つからない場合、ステップ９０９で決定され得るように、キャッシュはそれらの画像を非同期でロードし始め得る。画像は、ステップ９１２で画像９１０を要求することができる、ビューアのローダによってロードされてもよい。要求が行われた後、画像９１０をキャッシュに送り返すことができる。

これらのタイル９０７のいずれかがキャッシュにロードされた画像９１０を有するが、関連付けられたテクスチャ９１１を有しない場合、ステップ９１３に示されるように、ビューアのＧＰＵにテクスチャ９１１を非同期でアップロードし始めてもよい。

すべての要求が行われると、必要に応じて、ステップ９１４では、未使用のタイル画像及びＧＰＵテクスチャのグラフィックス及びシステムメモリを解放するために、キャッシュをプルーニングすることができる。

レンダリングループ
レンダリングループ９１２は、ＦＯＶ９０３への変更を反映するために表示を更新する役割を果たし得る。レンダリングループ９１２は、表示フレームごとに１回実行するようにスケジュールされることができる。これは、ほとんどのモニタで１秒あたり６０回（６０ＦＰＳ）になる。レンダリングループ９１２は、以下のようなプロセスを有することができる：

ＦＯＶ９０３が与えられると、レンダリングループ９１２は、ＦＯＶ９０３内で現在可視なタイルを計算することができる。プロセスはステップ９１５を含むことができ、ここではビューアのレンダリングは、どのタイルが可視であるかを決定することができる。キャッシュ内にいかなるタイルも見つからない場合、代わりに、レンダリングループ９１２はタイルの表面積をカバーする様々な拡大レベルからタイルを探すことができる。

次いで、ステップ９１６に示されるように、レンダラは、必要に応じてテクスチャを取得することができる。次に、レンダリングループは、ステップ９１８に示されるように、タイルのテクスチャをディスプレイ上のどこに描画する必要があるかを記述するドローコール９１７を生成し得、それらを実際に実行する役割を課されるレンダラに送信する。

レンダリング技法
ジェネリックを使用すると、ビューアは一部またはすべてのレンダリングロジックを外部実装にデリゲートすることができる。これにより、いかなる既存のコードも変更することなく、新しいプラットフォームをサポートするなど、新しいグラフィックス実装を迅速に追加することができる場合がある。

歴史的に、２Ｄキャンバスは、すべての主要なブラウザでサポートされる最初のＪａｖａＳｃｒｉｐｔ（登録商標）グラフィックスＡＰＩであった。これにより、最もポータブルになる。ただし、その名前が示すように、２Ｄコンテキストしかサポートしない場合がある。そのため、多数のアプリケーションには適していない可能性がある。さらに、高レベルの抽象化として、パフォーマンス及びカスタマイズ性を犠牲にして、グラフィックスレンダリングの複雑さの多くを隠す可能性がある。ビューアはいくつかの実施形態では２Ｄアプリケーションであるため、キャンバスはそれをレンダリングするのに特に適している場合がある。

ＷｅｂＧＬは、ブラウザコンテキストで実行するように設計されたＯｐｅｎＧＬ ＥＳ２．０規格の実装である。３ＤグラフィックスをレンダリングするためのＪａｖａＳｃｒｉｐｔ（登録商標） ＡＰＩを公開しているため、２Ｄグラフィックスにも適している。これは、キャンバスよりも低レベルのＡＰＩであり、操作の構成方法及びメモリの管理方法をより適切に制御する。ＷｅｂＧＬは、ＯｐｅｎＧＬより上のシンレイヤであるため、ほとんどのプラットフォームでのハードウェアアクセラレーションという利点があり、通常はキャンバスＡＰＩよりもパフォーマンスが高くなる。

ＯｐｅｎＧＬと同様に、ＷｅｂＧＬプログラムは、操作をスケジュールするＪａｖａＳｃｒｉｐｔ（登録商標）コードと、ユーザのＧＰＵで直接実行されるＯｐｅｎＧＬ ＥＳシェーディング言語（ＧＬＳＬ ＥＳ）で書き込まれたシェーダとで構成される。ＷｅｂＧＬバックエンドは、キャンバス実装よりも相対的にはるかに複雑である。ただし、ＷｅｂＧＬは、キャンバスの代替手段よりも多くの利点を提供するため、特定の状況ではより適切な選択となる。前述のように、ＷｅｂＧＬはキャンバスＡＰＩよりもパフォーマンスが高く、メモリ効率も高くなる。ＷｅｂＧＬはサブピクセルレンダリングをすぐにサポートするが、キャンバス実装のサポートはブラウザによって異なる。浮動小数点の精度の問題により、タイルを隣り合わせに合成するときにタイルのシームが可視である可能性があり、これらの特殊な場合を処理するためにレンダラ側でさらに何らかのロジックが必要になる場合がある。ＷｅｂＧＬ ＡＰＩはほぼ１：１でＯｐｅｎＧＬ ＡＰＩにマッピングされる。つまり、ネイティブコンテキストとブラウザコンテキストとの間で実装を共有することができる。さらに、シェーダは、イメージビューアの基本機能である後処理及び高度な合成を画像に追加するための非常にパフォーマンスの高い方法を提供する。

最大のブラウザバージョンエリアをサポートするために、Ｗｅｂ開発の世界でよくあるパターンでは、ＷｅｂＧＬ実装をデフォルトにし、現在のブラウザでＷｅｂＧＬがサポートされない場合にキャンバス実装にフォールバックする場合がある。ただし、これにはキャンバスがサポートするＷｅｂＧＬの機能のサブセットのみを使用することが含まれる場合があり、プログラムが複雑なシェーダコードを備えている場合に機能しない可能性がある。

ＷｅｂＧＬ２．０は、ＯｐｅｎＧＬ ＥＳ３．０規格に基づく新しい仕様である。ただし、すべての主要なブラウザでサポートされているわけではなく、Ｓａｆａｒｉは注目すべきホールドアウトである。

ＷｅｂＧＰＵは、さらに低レベルのグラフィックス機能をウェブアプリケーションに公開する予定のＡＰＩである。Ｖｕｌｋａｎ仕様に部分的に基づいており、Ｄｉｒｅｃｔ３Ｄ（Ｗｉｎｄｏｗｓ（登録商標））及びＭｅｔａｌ ＡＰＩにも効率的にマッピングすることを目標としている。

ＷｅｂＧＰＵは現在、ほとんどのブラウザですぐに使用できないが、それでも最新のブラウザの実験的な設定で有効にすることは可能である。ＷｅｂＧＰＵは、あらゆるグラフィックス バックエンドをターゲットにして、異なるプラットフォーム間でシームレスに機能することができる統合型ＡＰＩの見込みがある、グラフィックスプログラミングの世界における有望な開発を表している。

本開示は、ｗｇｐｕ５ Ｒｕｓｔクレートを使用するＷｅｂＧＰＵバックエンドの実装を伴う一実施形態を含む。今のところ、このバックエンドはビューアのネイティブバージョンでのみ動く。１つの実装では、ネイティブビューアは、Ｌｉｎｕｘ（登録商標）、Ｗｉｎｄｏｗｓ（登録商標）、及びｍａｃＯＳ上で実行できる可能性があり、ブラウザでＯｐｅｎＧＬ、ＷｅｂＧＬ、及び将来のＷｅｂＧＰＵ実装を対象にすることができる見込みがある。

さらに低レベルのＡＰＩを対象にしているため、開示されているＷｅｂＧＰＵ実装は、キャンバス実装かＷｅｂＧＬ実装かいずれかよりも複雑である。ただし、ＷｅｂＧＰＵ ＡＰＩは適切に設計されており、ｗｇｐｕクレートによって提供される抽象化により、比較的使いやすくなる可能性がある。今後数年間で、ＷｅｂＧＰＵの開発はさらに簡単になり、より優れたツール及びサポートが利用可能になる可能性がある。

最適化技法
パフォーマンスは重要なコンポーネントであり得、スライドビューアの例示的な実施形態における技術的な選択を導くのに役立つ。ただし、製品の制約により、これらの選択の一部は既に行われている。おそらくそれらの中で最も重要なのは、ビューアがウェブアプリケーションであり得ることである。

ビューアがウェブアプリケーションである場合、ビューアで使用できるテクノロジの数が制限される場合がある。ただし、一部にはＷｅｂＡｓｓｅｍｂｌｙ、ＷｅｂＧＬ、及び潜在的にＷｅｂＧＰＵにより、非常にパフォーマンスの高いグラフィカルウェブアプリケーションを書き込むことは依然として可能である。それにもかかわらず、これらのアプリケーションの一部は、依然としてネットワーク経由で通信する必要があるため、ブラウザのネットワークスタックとクライアントのインターネット接続との両方によって制約される。ウェブアプリケーションは、Ｗｅｂ ＡＰＩにしかアクセスできない状態で、割り振られたブラウザのメモリに収まる必要があることにより、さらに制約される場合がある。

キャッシュヒューリスティック
ブラウザ、そしてより広い意味ではユーザのコンピュータは、使用可能なメモリ量が限られている場合がある。そのため、メモリにユーザのセッションの一部としてロードされるすべての画像を保持することは、ユーザのデバイスに全スライド画像を格納することに似ているため、不可能な場合がある。これらの画像は、エンコードされると数ギガバイトの大きさになり、デコードされると数十ギガバイトの大きさになる場合がある。そのため、前述のように、キャッシュの占有率を管理可能なサイズに保つために、キャッシュのプルーニングまたはキャッシュのソートのヒューリスティックを実装する必要がある場合がある。

キャッシュのプルーニングまたはソートは、キャッシュに現在格納されている各タイルの優先度を決定し、必要に応じてキャッシュをプルーニングする操作を指し得る。キャッシュが最大占有率を超えると、キャッシュのソートがトリガされる場合がある。例えば、ビューアは、キャッシュが完全にいっぱいになると、最大容量に達したと決定する場合がある。代替的に、ビューアは、最大占有率がキャッシュの特定のレベルの容量であると決定してもよい。キャッシュが最大占有率に達する、及び／またはそれを超える場合、キャッシュのコンテンツを調べて、優先度が最も低いタイルを決定することができる。優先度が最も低いタイルは、キャッシュが最大占有率以下になるまでキャッシュから除去されることができる。

一実施形態では、キャッシュ内のタイルの優先順位は、以下を含むことができる：
ａ．ＦＯＶの拡大因子以上であり得る、拡大レベルでＦＯＶ内にあるタイル、
ｂ．ＦＯＶの拡大因子以上であり得る、拡大レベルでＦＯＶに境界を接するタイル、
ｃ．より高い拡大レベルでＦＯＶ内にあるタイル、
ｄ．より低い拡大レベルでＦＯＶ内にあるタイル、及び
ｅ．他のすべてのタイル。

別の実施形態では、各キャッシュサイクル中に、タイルを次の３つのカテゴリにソートすることができる：
ａ．現在表示に直接必要なタイル。図２に戻り参照すると、これらは「アクティブ」とマーク付けされたタイル１１である。これらアクティブなタイル１１は、図１１にも見られることができる。
ｂ．図１０Ａに示されるように、スライド画像が最初にロードされるときに、その全体が表示され得る。この最初の表示中に、タイルのセットを低い拡大レベルでロードすることができる。これらのタイルは、正しい拡大レベルでタイルをロードしており、それらの代わりに何かを表示する必要があり得る場合に、補間目的で使用されることができる。図１０Ｂは、そのような一例を示しており、拡大の低いタイルは、拡大の高いタイルの代わりに、後者がロードされている間に表示されるように補間される。
ｃ．その他のタイルは、重要度の降順で次の４つのサブカテゴリにソートされる：
ｉ．ＦＯＶに直接境界を接しているタイル、
ｉｉ．ＦＯＶ内にあるが、拡大レベルが高いタイル、
ｉｉｉ．ＦＯＶ内にあるが、拡大レベルが低いタイル、
ｉｖ．他のすべてのタイル。

カテゴリ１及び２に属するタイルは、即時に必要になるか、常に補間目的で最終的に必要になる可能性があるかいずれかであるため、常にメモリに保持され得る。カテゴリ３に属するタイルは、最大占有率までしか保持されることができず、その後、優先度が低いと見なされるタイルはプルーニングされ始める。

さらに、これらのヒューリスティックは、デコードされた画像以外にも適用される。実際、画像要求は同じヒューリスティックに従うが、カテゴリ３からの要求がカテゴリ１及び２からの要求と同時に実行できないという制約が追加される。ペンディング中の優先度の低いタイルの要求は、優先度の高いタイルの要求を着信する場合、キャンセルされる。これにより、必要なタイルの要求が常に優先され得ることが確保される。

タイルのプリロード
図２は、ビューアが特異的なＦＯＶ１２をレンダリングするためにロードすることができるアクティブなタイル１１を示す。しかしながら、例示的な実施形態は、ユーザが次に訪問する可能性があるとビューアが予測するタイルのロードを開始することができる。

図１１は、アクション中のこのビヘイビアの一例を示す。スライドビューアは、ユーザがある時点でＦＯＶ１２をパンすることを予期する場合があるため、そのサイズを拡大して、プリロードエリア１１２などの「プリロードエリア」を形成する場合がある。プリロードエリア１１２内のタイル１１１は、それらをユーザが必要とするときに即時に利用可能になり得るように、バックグラウンドにロードされてもよい。

上述のように、これらのタイル１１１は、サブカテゴリ（ｃ）（ｉ）の一部と見なされることができる。そのため、これらのタイル１１１を要求しても、他のタイル要求の速度が低下することはなく、他のより重要なタイルをプルーニングするという犠牲を払わなくてもよい。

ユーザエクスペリエンスが向上する可能性があるが、このアプローチには欠点もあり得る。そのような欠点の１つは、より大きい画像領域をプリエンプティブにロードすること、つまり、タイルサーバに対してより多くの要求が行われ、これらの要求の一部が無駄になることであり得る。そのため、タイルをプリロードした場合のデータ転送コストは、そうでない場合よりも高くなる。もう１つの欠点は、大きすぎるエリアをプリロードすると、ユーザとサーバとの両方に負荷がかかる可能性があることである。実際には、これによりフロントエンドでスタッタが発生し、バックエンドでレイテンシが増加する可能性がある。ただし、これは、サーバ側でコンテンツ配信ネットワーク（ＣＤＮ）を使用し、クライアント側で適切に要求をスケジュールすることで軽減される場合がある。

タイルのロード及びデコードの並列化
最新のブラウザでは、リソースのロードはバックグラウンドで非同期に行われるが、画像のデコードはメインスレッドで行われる場合がある。そのため、多数の画像をデコードすることで、レイテンシが増加し、レンダリングループが遅延した結果、ＦＰＳが低下する可能性がある。図１２は、上半分１２０に順次要求１２１、１２２、及び１２３、ならびに下半分１２５に順次要求１２６、１２７、及び１２８を有するタイルを順次方法で要求し、ロードし、デコードする例示的なタイムラインを示す。画像のデコードがメインスレッドでのみ発生する場合、純粋に順次である可能性があり、レンダリングループを実行できるようになる前に、デコードが完了するまで待機することが必要になる場合がある。

図１２の上半分１２０では、順次要求１２１、１２２、及び１２３は、メインスレッドまたは別のスレッド内にあり得る。順次要求１２１、１２２、及び１２３は、順次にデコードされて格納されてもよく、または別の順序でデコードされてメインスレッドの一部として順次に格納されてもよい。順次要求１２１、１２２、及び１２３の並列ロードは、様々な時間量を伴う場合があるが、順次に開始する場合がある。

これは、図１２の下半分１２５に類似している。ここでは、順次要求１２６、１２７、及び１２８は、メインスレッドまたは他のスレッド内に存在することができる。順次要求１２６、１２７、及び１２８の間の間隔は、メインスレッド内で異なる可能性がある。他のスレッド内では、順次要求の並列したロード及びデコードの時間も異なる可能性があり、スレッドの同じステップ内で完了する場合がある。順次要求に関する追加の詳細を以下に提供する。

ＷｅｂＷｏｒｋｅｒは、ウェブＡＰＩファミリに最近追加されたものである。ＷｅｂＷｏｒｋｅｒは、最新のプロセッサのマルチスレッド機能を利用して、ＪａｖａＳｃｒｉｐｔ（登録商標）及びＷａｓｍコードをメインスレッドと並列して実行することができる。ＪａｖａＳｃｒｉｐｔ（登録商標）は本質的にシングルスレッドである。つまり、シングルスレッドでしか実行できない。ＪａｖａＳｃｒｉｐｔ（登録商標）で並列計算を可能にするには、マルチプロセッシング及びメッセージパッシングを使用する必要がある場合がある。これがＷｅｂＷｏｒｋｅｒの基本概念であり、独立したＪａｖａＳｃｒｉｐｔ（登録商標）コンテキストで実行でき、チャネルを介してメインスレッドとデータをやり取りできる。

ＷｅｂＷｏｒｋｅｒを使用すると、メインスレッドから画像をデコードできるようになる可能性がある。作業を別のスレッドにオフロードすることで、イベント処理及びレンダリングを含む、より重要な役割をメインスレッドが自由に実行することが確保されることができる。図１２は、異なるスレッドへのデコードをデファーすることによって、より高い頻度でより高速なレンダリングが達成されることを示す。

この技法は、最近追加されたＯｆｆｓｃｒｅｅｎＣａｎｖａｓ ＡＰＩのおかげでレンダリングにも使用されることができる。ただし、現在のレンダリングはビューアにとってボトルネックではない可能性があるため、実装されなかった。

最後に、ＪａｖａＳｃｒｉｐｔ（登録商標）はスレッドを有することができないが、ＳｈａｒｅｄＡｒｒａｙＢｕｆｆｅｒ ＡＰＩのおかげで、それでも将来的にメモリを直接共有できる可能性があることに留意されたい。さらに、Ｗａｓｍ仕様はスレッドモデルをサポートしており、ＷａｓｍスレッドはＣｈｒｏｍｅ及びＦｉｒｅｆｏｘで既に利用できる場合がある。

例示的な実施形態
例示的な実施形態は、４つのタイルをＦＯＶがカバーするように、ユーザがＦＯＶを調整することを含み得る。これら４つのタイルは、（４，４）、（５，４）、（４，５）、（５，５）など、グリッド内のそれらの座標によってインデックス付けされる。次いで、ビューアはタイル（４，４）、（５，４）、（４，５）、（５，５）をロードすることができ、これらはすべてＦＯＶ内に位置していることができる。タイル（４，４）及び（５，４）は、全ロード状態でキャッシュによって既に格納されている場合がある。タイル（４，５）及び（５，５）はキャッシュに格納されない場合があり、この場合、それらのようなタイルはタイル要求状態で格納される可能性がある。タイル要求状態は、ビューアまたはタイルサーバに格納されることができる。例えば、ビューアは、タイル（４，５）及び（５，５）をロードするタイル要求をタイルサーバに送信することができる。このタイル要求は、専用のＦＯＶ座標または異なる一意の識別子などのタイル識別子を含むことができる。タイルサーバは、ビューアにデータを転送する場合がある。このようなデータには、タイルを完全にロードするために、完全なタイル情報が含まれる場合がある。ビューアは、タイル（４，５）及び（５，５）を全ロード状態に移行させることができる。すべてのタイルが全ロード状態になったので、ビューアは境界タイル（３，４）、（４，３）などのロードに進むことができ、前述の方法は、境界タイル及び後続のタイルグループに対して繰り返される可能性がある。さらに、ユーザはＦＯＶを再度調整することができ、ビューアは新しいＦＯＶのキャッシュからタイルをロードすることができる。

キャッシュは、前の方法から最大占有率になる可能性がある。例えば、この方法からロードされたすべてのタイルは、キャッシュを最大占有率まで満たしている可能性がある。新しい（または現在の）ＦＯＶを使用して、キャッシュは格納されたタイルをソートし得、キャッシュが最大容量でなくなるまで優先度の低いタイルを除去し得る。そのようなソートプロセスは、プロセス中にいつでも発生する可能性もある。

さらに、ビューアは、上述のプロセス中の任意の時点でタイルをレンダリングすることができる。ビューアは、全ロード状態のタイルをディスプレイまたはストレージデバイスにレンダリングすることができる。これは、レンダリングループの実行がバックグラウンドループ方法に依存しない可能性がある、レンダリングループである可能性がある。

作業スケジューリング
前述のように、現在のプロセスに時間がある場合は常にバックグラウンドループを実行する必要があり得る。ウェブビューアでは、レンダリングループの直前に実行するようにスケジュールされている場合がある。これは、機能するが、バックグラウンドループに時間がかかりすぎると、レンダリングループがフレームを見逃す可能性があるため、最適ではない可能性がある。

作業スケジューリングの早期の例は、実験的なｒｅｑｕｅｓｔＩｄｌｅＣａｌｌｂａｃｋ ＡＰＩである。このＡＰＩを使用すると、ブラウザにアイドル期間があるたびに、バックグラウンドループを呼び出すことができる。さらに、複数の小さい作業単位を実行するため、バックグラウンドループは本質的に一時停止可能である。タイムアウトに達する場合、その実行は一時停止され、次のフレームで再開される場合がある。したがって、近い将来、そのモデルは新しいブラウザスケジューリングＡＰＩを利用できる可能性がある。

パフォーマンスメトリクス
インストルメンテーションフレームワークのトレーサコンポーネントは、タイルに最初の要求を行う瞬間と、タイルをサーバからロードする瞬間と、タイルを最終的に画面にレンダリングする瞬間との間の持続時間を計測する役割を果たす。これらのイベントは、図９に示されている。ビューアの様々なコンポーネントでロード及びレンダリングが発生する可能性があるため、トレーサはアプリケーション全体に広範に及ぶ。トレーサは、測定する必要がある様々なコンポーネントをラップすることでこれを実現し、これらのコンポーネントはすべて汎用ＡＰＩを公開する。そのため、トレーサを無効にするには、ユーザはこれらのラッパを除去するだけでよい。

インストルメンテーションフレームワークによって収集される重要なメトリックは、ＦＯＶ完了時間である。ＦＯＶ完了時間は、ユーザインタラクションがＦＯＶの変化を引き起こす瞬間と、新しいＦＯＶが画面上に完全にレンダリングされる瞬間との間の経過時間を測定する場合がある。

ＦＯＶを表示するために必要なタイルが既にキャッシュに存在する可能性があるため、一部のインタラクションにより、ＦＯＶが即時に完了する場合がある。そのため、フレームワークは、少なくとも１つのフレームの未完了のＦＯＶがユーザに提示された場合にのみ、ＦＯＶ完了イベントを考慮することができる。未完了のＦＯＶは、タイルテクスチャがまだロードされていないＦＯＶであり、キャッシュ内の拡大の低いタイルの補間バージョンに置き換えられる可能性がある。

ＦＯＶ完了時間はターンアラウンドタイムとも呼ばれる。Ｆｏｏｄ ａｎｄ Ｄｒｕｇ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ（ＦＤＡ）には、様々なユーザインタラクションに対するビューアアプリケーションのターンアラウンドタイムの許容時間に関する専用のガイドラインがある。例示的な実施形態は、ＦＤＡターンアラウンドタイムラインガイドラインの一部のみを使用する。

ＦＯＶ完了時間は純粋に定量的なメトリックであるが、ユーザエクスペリエンスのより定性的なメトリックは、ユーザのセッションでのＦＯＶの平均完了率を測定することである。このメトリックの目的は、ユーザが未完了のＦＯＶに費やした時間の量と、いつでも画面に表示される部分的な情報の量とを定量化することである。

画面にレンダリングされるフレームごとに、トレーサはタイルのドローコールを調べて、現在のＦＯＶ拡大レベルよりも低い拡大レベルのテクスチャを参照しているドローコールを確認することができる。完了したＦＯＶは、それ自体の拡大レベル以上の拡大レベルでしかテクスチャを表示することができないため、拡大の低いテクスチャを含むフレームは必然的に未完了になる。これらのドローコールによってカバーされるエリアを測定し、ＦＯＶのエリアで除算することができると、ＦＯＶの未完了率（及び逆に完了率）を示すことができる。タイルのレンダリングに必要な正確なテクスチャがまだ使用できない可能性がありながら、拡大の高いテクスチャを拡大の低いテクスチャの上に重ねることができ、拡大の高いサブタイル及び拡大の低いスーパータイルがキャッシュで使用できるため、アルゴリズムは少し複雑になる可能性がある。

最後に、測定する最も単純なメトリックは、シングルタイルをロードしてレンダリングするのにかかる時間のものである。このメトリックは、主にタイルサーバのパフォーマンスを示し得るが、タイルロード及びレンダリングパイプラインに関する問題も明らかにする場合がある。

例えば、ＨＴＴＰ／１．１プロトコルを使用する場合、ほとんどのブラウザは、専用のホストに並列して行われることができる要求の数を制限する。Ｃｈｒｏｍｅでは、その数は６である場合がある。高速なタイルサーバを使用しても、このような制限により、６超のタイルを並列してロードするときに、後の要求がブラウザによってキューイングされるため、タイルのロード時間が人為的に増える可能性がある。本明細書に記載される例示的な実施形態では、タイルサーバは、ＨＴＴＰ／２．０プロトコルを排他的に使用するため、これらの制限の影響を受けないことがある。

ユーザセッションの録画及び再生
意味のある比較ベンチマークをコンパイルするのに十分なデータを収集することは、常に課題である。そのため、現実的な使用状況データを迅速かつ効率的に生成する方法が必要である。

１つのソリューションをもう１つのソリューションと比較するアプローチの１つは、トレースを有効にして通常のユーザセッションのステップを手動で再生し、サンプルを調べた後、どのソリューションが最高のパフォーマンスを発揮したかを確認することであり得る。このアプローチは、完全に手動であるため、ユーザが追加の時間を費やすなど、いくつかの欠点を有する可能性がある。さらに、この方法は科学的でない可能性があり、いずれかの有意差を示すのに十分なサンプルを収集することができない。

これらの欠点を回避するために、セッションレコーダ及びプレーヤを使用することができる。ユーザインタラクションは、発生した瞬間と同時に録画され得るため、後で同じ速度で再生され得る。元のユーザセッションと再生されたセッションとの間の主な差異の１つは、ＦＯＶが完全に解像されたことをセッションプレーヤが認めると、ユーザインタラクション間でそれ以上待機しないことであり得る。これは、通常、再生されたセッションが元のセッションよりも高速になる可能性があることを意味する場合がある。また、イベントが平均してより高速の速度で発生するため、ビューア側の負荷が増えることを意味する場合がある。そのため、これは完全に現実的な使用状況シナリオを表さないが、最悪の場合、システムにもう１つの負荷がかかることを表す。

ベンチマーク
次のベンチマークは、次の仕様のコンピュータでキャプチャされた：
モデル：ＭａｃＢｏｏｋ Ｐｒｏ、１３インチ、２０１９
ＣＰＵ ２．８ＧＨｚ クアッドコア Ｉｔｅｌ Ｃｏｒｅ ｉ７
グラフィックス Ｉｎｔｅｌ Ｉｒｉｓ Ｐｌｕｓ Ｇｒａｐｈｉｃｓ６５５（統合型）
グラフィックスメモリ １５３６ＭＢ
メモリ １６ＧＢ ２１３３ＭＨｚ ＬＰＤＤＲ３
インターネット帯域幅 ３００Ｍｂｐｓ
サーバ側では、インスタンスは次の仕様のｍ５ａ．４ｘｌａｒｇｅタイプのＡＷＳ ＥＣ２インスタンスで実行されている：
ＣＰＵ ２．５ＧＨｚ ＡＭＤ ＥＰＹＣ７５７１、１６スレッド
メモリ ６４ＧＢ

ベンチマークは、様々な組織からの１０枚のＳＶＳスライドのセットでキャプチャされた。すべてのスライドは、４０ｘの拡大力でスキャンされた。下記のチャートは、組織の種類、スライドのサイズ及び解像度の詳細を示す。

例示的なビューア／タイルサーバの組み合わせをベンチマークするために、プロセスは２つの部分に分けられる。最初に、一連のユーザアクションは、録画され、後で再生するためにユーザセッションとして保存される。次に、データセット内のすべてのスライドに対してユーザセッションが生成されると、ユーザセッションが再生される。

ユーザセッションを録画するプロセスには、次のステップが含まれる場合がある：
ａ．スライドトレイ上のスライドをクリックして開き、録画を開始する。
ｂ．３分間、一連のズーム及びパンを使用してスライドをナビゲートする。
ｃ．ユーザセッションを保存する。
ｄ．次のスライドにプロセスを繰り返す。

ベンチマークを生成するプロセスには、次のステップが含まれる場合がある：
ａ．以前に生成されたすべてのタイルをクリアする。
ｂ．ベンチマークの所望の設定にビューアを構成する。
ｃ．再生するユーザセッションを選択する。
ｄ．ビューアは、選択したセッションを何度も自動的に再生し、結果をディスクに保存する場合がある。

ＦＯＶ完了
ビューアが１つの拡大レベルからもう１つの拡大レベルに移行しており、以前に表示されたタイルを再利用することができないことから、ズームアクションは、ＦＯＶを完全に無効にする可能性があるため、パンアクションよりも完了が平均して遅くなる可能性がある。これは、新しいＦＯＶの周辺でこれらのタイルの一部を依然として再利用できる可能性があるパンアクションとは対照的である。

次の構成がまったく同じ一連のアクションに従う場合があるが、それらの間で収集されるサンプルの数が大きく異なる場合がある。最終的に、サンプル数は、ユーザに未完了のＦＯＶを提示する結果となったアクション数を示す。そのため、サンプル数が少ないほど、そのような結果となったアクションの割合が少ないことを示す可能性がある。この影響は、前述のようなタイルのプリロード構成で特に顕著であり得、いくつかの方法で説明されることができる。ＦＯＶ完了時間が非常に速い場合、ユーザがパンまたはズームしているときに完了イベントが複数回発生することがある。それらが遅い場合、ユーザがこれらのアクションを完了した後にのみ発生する可能性がある。表示する未完了のＦＯＶの数を少なくする必要がある構成では、ＦＯＶ完了イベントのサンプルを少なくする可能性がある。

図１３Ａに示されるように、例示的なビューアは、タイルキャッシュを決して使用せず、代わりに常にオンデマンドでタイルを生成するように構成され得る。これは、動的タイリングベンチマークの場合に当てはまることがある。

静的タイリングベンチマーク用に構成された例示的なビューアが図１３Ｂに示される。静的タイリングベンチマークでは、ビューアが必要とするすべてのタイルが事前に生成され、タイルサーバを介してＳ３からストリーミングされた。次のすべてのベンチマークでも静的タイリングは、今後最も現実的なアプローチであると考えられ得るため、使用される。

プリロードベンチマークは、プリロードオフセットの４つの異なる構成で、タイルのプリロードをミックスに追加する。プリロードオフセットは、構成されたタイルサイズの因子として表されることができる。例えば、タイルサイズが５１２×５１２であり、プリロードオフセットが０．５に設定される場合、ピクセル単位での実際のプリロードオフセットは５１２×０．５＝２５６ピクセルになり得る。

プリロードオフセットの設定
プリロード、１ ０．５
プリロード、２ １．０
プリロード、３ １．５
プリロード、４ ２．０

図１４は、プリロードオフセットの値がＦＯＶ完了レイテンシに直接影響し得ることを示す。さらに、プリロードオフセットは、プリロードオフセットが大きいと、必然的に完了時間が速くなるという直感を無効にする可能性がある。これは、いくつかの方法で説明されることができる。プリロードオフセットが大きくなると、最終的にロードする必要があるタイルが多くなり得る。ロードするタイルの数は、プリロードオフセットによって二次関数的に増加することができるため、数が多いとパフォーマンスの問題が発生する可能性がある。さらに、多数のタイルを同時にロードすることが原因で、タイルサーバに負荷がかかり、要求のレイテンシが増加する可能性がある。例示的な実施形態では、すべてのプリロードタイルが同じ優先度を有することができる。これは、プリロードオフセット値が大きいほど、一部のタイルが、ＦＯＶから遠くなるので、必要になる可能性が低くなるため、より近いタイルよりも先に解像される可能性があることを意味し得る。最後に、ベンチマークでのアクションは、ＦＯＶ完了イベント間で待機することなく、非常に迅速に連続して実行されることができる。これは、タイルのプリロードの異常な場合であり、ユーザがアクション間で少なくとも０．５秒待機することが予想される場合がある。この間、すべてではないにしてもほとんどのプリロードタイルが適切にロードされる。

低速インターネット接続ベンチマークは、より低速の接続をシミュレートするために、インターネット帯域幅を人為的に１０Ｍｂｐｓに制限する場合がある。

図１５Ａは、既知のスライドビューアと動的タイリングに関する例示的な実施形態とのパフォーマンスの比較である。結果は、例示的な実施形態が、常にではないが、ほとんどの場合、ＦＯＶのロード中に既知のサイドビューアよりも高速であることを示し得る。

図１５Ｂは、一実施形態の動的タイリングと静的タイリングとに関するパフォーマンスの比較である。差異は、表示の完全な無効化を必要とするイベント（例えば、初期ロード及びズーム）で顕著になる場合がある。一方、表示の部分的な無効化を必要とするイベント（パン）には、識別可能な差異がほとんどまたはまったくない場合がある。これは、表示を完全に無効にすると、部分的な無効化よりも多くのタイルを並列してロードする必要があり得ることが原因で、レイテンシスパイクが発生する可能性があるという、これらのイベントがサーバに与える負荷での差異によって説明される可能性がある。

現在の静的タイリングの実装は、バッキングストア（ＡＷＳ Ｓ３）とクライアント（ブラウザ）との間のプロキシとして機能するタイルサーバを必要とする場合があるため、完全ではない可能性がある。これにより、すべての要求に何らかのレイテンシが追加される場合がある。このレイテンシを除去する方法には、バッキングストアから直接タイルを提供すること、及び／またはＡＷＳコンテンツ配信ネットワーク（ＣＤＮ）、ＣｌｏｕｄＦｒｏｎｔを介してタイルを提供することが含まれる場合がある。ＣＤＮは、静的コンテンツを提供するために最適化されてもよく、対応するデータをクライアントにより近いサーバに物理的に移動させることで、頻繁にクエリされるコンテンツのレイテンシを大幅に改善する可能性がある。

これらのアプローチでは、認証ロジックをタイルサーバ（この時点では認証プロバイダに近い）から、クライアントが最終的に通信するサービス（例えば、Ｓ３またはＣｌｏｕｄＦｒｏｎｔ）に部分的に移動させる必要がある場合がある。

図１５Ｃは、例示的な実施形態の１のプリロードオフセットでプリロードが無効である場合と、有効である場合とのパフォーマンスの比較であり、上記の説明からのベンチマークは、レイテンシとロードされたタイルの数との間の妥協点に達することが示されている。この構成では、１のプリロードオフセットは、ＦＯＶの周囲に５１２ｘ５１２のプリロード境界を追加することを意味する。

予想どおり、プリロードの現在の実装が同じ拡大レベルでの境界タイルでのみ動作する可能性があるため、ズームアクションのパフォーマンスはほとんど変わらない。ただし、プリロードによってパン操作が大幅に高速化されることがわかり得る。初期ロードのレイテンシでの差異は、これらのイベントのサンプル数が少ないことによってのみ説明される場合がある。

最後に、例示的な実施形態が既知のスライドビューアよりもかなり高速であり得ることをさらに説明するために、図１５Ｅは、３００Ｍｂｐｓ接続で動作する既知のスライドビューアと、１０Ｍｂｐｓ接続で動作する例示的な実施形態との間の比較を示す。例示的な実施形態は、初期ロード及びパンアクションの両方でより高速であるが、ズームアクションでは既知のスライドビューアと同様に行う。前に説明したように、これらのアクションでは、さらに多くのタイルをロードする必要がる場合があり、限られた帯域幅が飽和状態になる。

タイルのロードにかかる時間は、ビューアのパフォーマンスが知覚されるための重要な因子である。図１５Ｆに示されるように、例示的な実施形態のタイルサーバの実装により、既知のタイルサーバよりもはるかに高速でタイルが提供されることができ、その結果、ユーザのロード時間が短縮され得る。タイルをオンデマンドで生成する動的タイルサーバと、すべてのタイルが既に事前に生成されている静的タイルサーバとの差異はそれほど明確ではない。

採用する構成を決定する際に生じる主な妥協点は、ユーザエクスペリエンスの質とメンテナンスのコストとのものである。

ユーザエクスペリエンスの質は、タイルの平均ロード時間など、より定量的なメトリックスに依存する場合があるが、それらのようなメトリックスはすべてを物語るものではない。より代表的なメトリックを取得するために、例示的な実施形態は、ユーザセッション中に未完了のＦＯＶがユーザに提示される時間の割合を使用することができる。このメトリックは、平均ＦＯＶ完了であり、上記でさらに説明されている。一方、ビューア側のメンテナンスコストの主な因子は、セッション中にロードされるタイルの平均数である。タイルのロードには、処理能力とデータエグレスとの両方のコストがかかる。

次の表は、様々なテスト済み構成に対するこれら２つのメトリックの詳細である。

直感では、プリロードオフセットの設定が高いほど、最終的にロードされるタイルが多くなる。これは、ペンディング中のタイル要求が不要になるとわかる場合、それらのタイル要求をビューアは自動的にキャンセルする場合があるため、必ずしもそうであるとは限らない。これは、スライドビューアの例示的な実施形態でタイル要求値とタイル先行値が異なる理由である可能性がある。この影響は、タイルをプリロードするときに特に顕著になる場合がある。

同様に、再生されたユーザセッションが同じであり、絶対に必要な場合を除いてタイルがロードされないため、タイル要求値が例示的な実施形態の動的構成、静的構成、及び１０Ｍｂｐｓ構成の間で等しいと予想され得る。ただし、ブラウザのスケジューリングＡＰＩが完全に決定論的ではない可能性があるため、同じセッションの異なる実行の間にわずかな変動が発生する。タイル要求の作成の役割を果たすバックグラウンドループは、異なる時間に実行され、異なるＦＯＶをキャプチャする場合がある。この影響は無視できるほど小さいものである。これらの点を念頭に置いて、例示的な実施形態は、一見同等のデータエグレスコストであっても、はるかにスムーズなユーザエクスペリエンスを提供することができる。

ストリーミングビューア
ユーザがスライドビューアを直接レンダリングする代わりに、ストリーミングビューアでは、その役割がサービスに移され、サービスはユーザが表示するビデオストリームを送り返す。実装では、ＧＳｔｒｅａｍｅｒ及びそのＷｅｂＲＴＣサポートなどのストリーマライブラリを広範囲に使用し得、最小限のレイテンシ（＜１００ｍｓ）でライブビデオのエンコードとユーザへのストリーミングとを可能にする。これは、ＶＰ８及びＶＰ９などの新しいビデオコーデックのサポートのおかげによるところもあり得る。

ストリーミングスライドビューアの例示的な実施形態のアーキテクチャが図１６に示されている。「ビン」として示される様々な部分は、ストリーマライブラリコンポーネントを指す。

例示的な実施形態では、ユーザのブラウザは、ＷｅｂＲＴＣを介してフィードされたビデオを受信し得、ビューア１６３とのユーザインタラクションに対応するイベントを送り返し、それに応じてサーバがＦＯＶを更新する。

ＷｅｂＲＴＣＢｉｎ１６１は、ＷｅｂＲＴＣを介してパケットをＷｅｂプレーヤ１６２に送信することができる。次に、Ｗｅｂプレーヤ１６２は、ＷｅｂＳｏｃｋｅｔを介してビューア１６３にイベントを送信することができる。ビューア１６３は、ＷｅｂＧＰＵレンダラ１６４からドローコールされ得る。フレームは、ＷｅｂＧＰＵレンダラ１６４からビデオビン１６５に送信され得、このＦＦＧＩは、ソース１６６、エンコーダ１６７、及びペイローダ１６８を含み得る。

例示的な実施形態は、ＧＳｔｒｅａｍｅｒのプラグインのエコシステムだけでなく、ＧＳｔｒｅａｍｅｒとＲｕｓｔとの統合の質に基づいて、容易に実装することができる。同じコードをネイティブでブラウザに実行すると、ビューアのビヘイビアがすべてのそのレンダリングバックエンド間で同じままになることが確保される。

本発明の例示的な実施形態の上記の説明において、本発明の様々な特徴が、本開示を合理化し、様々な発明態様のうちの１つ以上の理解を助ける目的で、単一の実施形態、図、またはその説明にまとめられることがあることを理解されたい。ただし、開示の本方法は、特許請求の範囲に記載された本発明がそれぞれの請求項に明示的に述べられるよりも多くの特徴を必要とするという意図を反映するものとして解釈されるべきではない。むしろ、以下の特許請求の範囲が反映するように、発明の態様は、単一の前述の開示される実施形態の全ての特徴にあるわけではない。このように、詳細な説明に続く特許請求の範囲は、本明細書によって詳細な説明内に明示的に組み込まれ、それぞれの請求項は、本発明の別個の実施形態として独立している。

さらに、本明細書に記載されるいくつかの実施形態は、他の実施形態に含まれる特徴の一部を含むが他を含まず、異なる実施形態の特徴の組み合わせは、当業者によって理解されるように、本発明の範囲内であり、異なる実施形態を形成することを意味するものである。例えば、以下の特許請求の範囲において、請求された実施形態のいずれも、任意の組み合わせに用いることができる。

したがって、特定の実施形態について説明してきたが、当業者は、本発明の趣旨から逸脱することなく、他のさらなる修正形態がそれに対してなされ得ることを認識するであろうし、本発明の範囲内に入るようなすべてのそれらのような変更形態及び修正形態を主張することが意図される。例えば、機能はブロック図に追加されてもよく、またはそれらから削除されてもよく、操作は機能ブロック間で置き換えられてもよい。ステップは、本発明の範囲内で記載された方法に追加されてもよく、または削除されてもよい。

上記で開示された主題は、限定的ではなく例示的であると見なされるべきであり、添付の特許請求の範囲は、本開示の真の趣旨及び範囲内に入る、それらのようなすべての修正、強化、及び他の実装を網羅することを意図したものである。したがって、法律で認められる最大限の範囲で、本開示の範囲は、以下の特許請求の範囲及びそれらの均等物の最も広く許容できる解釈によって決定されるべきであり、前述の詳細な説明によって制限または限定されてはならない。本開示の様々な実装について説明してきたが、当業者には、本開示の範囲内でさらに多くの実装が可能であることは明らかであろう。したがって、本開示は、添付の特許請求の範囲及びそれらの均等物に照らさない限り、制限されるべきではない。

Claims (20)

1. 電子画像を処理するためのコンピュータ実装方法であって、
   ビューアによって、前記電子画像及びＦＯＶ（視野）を受信することであって、前記ＦＯＶは少なくとも１つの座標、少なくとも１つの寸法、及び拡大因子を含む、前記受信することと、
   前記ビューアによって、前記ＦＯＶ内に複数のタイルをロードすることと、
   前記ビューアによって、キャッシュ内の前記複数のタイルの状態を決定することと、
   前記キャッシュ内の前記複数のタイルの前記状態が全ロード状態であると決定することに応答して、前記ビューアによって、前記複数のタイルをディスプレイにレンダリングすることと、
   を含む、前記コンピュータ実装方法。
2. 前記ビューアによって、前記キャッシュ内の前記複数のタイルのうちの１つのタイルの前記状態がタイル要求状態であると決定することと、
   前記決定に応答して、前記ビューアによって、前記タイル要求状態をタイルサーバに送信することと、
   前記ビューアによって、前記タイルサーバからのデータ転送を受信することであって、前記データ転送は前記タイルサーバが前記タイル要求状態を受信することに応答し、前記データ転送は前記複数のタイルの前記１つのタイルに対応するタイルデータを含む、前記受信することと、
   前記ビューアによって、前記複数のタイルのうちの前記１つのタイルを前記全ロード状態に移行させることと、
   前記ビューアによって、前記複数のタイルをレンダリングすることと、
   をさらに含む、請求項１に記載のコンピュータ実装方法。
3. 前記電子画像を受信することは、１セットのタイルを低い拡大レベルで前記キャッシュにロードすることを含む、請求項１に記載のコンピュータ実装方法。
4. 前記ＦＯＶ内に前記複数のタイルを前記ロードすることは、
   前記ビューアによって、前記キャッシュが前記複数のタイルのうちの１つのタイルを格納するかどうかを決定することと、
   前記キャッシュが前記１つのタイルを格納すると決定することに応答して、前記ビューアによって、前記１つのタイルが前記拡大因子以上の拡大レベルを有するかどうかを決定することと、
   前記タイルが前記拡大因子以上の前記拡大レベルを有すると決定することに応答して、前記ビューアによって、前記１つのタイルを前記キャッシュからロードすることと、
   をさらに含む、請求項１に記載のコンピュータ実装方法。
5. 前記１つのタイルが前記拡大因子以上の前記拡大レベルを有しないと決定することに応答して、前記ビューアによって、前記複数のタイルのうちの前記１つのタイルに対応する格納されたタイルを取得することであって、前記格納されたタイルは最も高い格納された拡大レベルを有する、前記取得すること、
   をさらに含む、請求項４に記載のコンピュータ実装方法。
6. 前記電子画像はＷＳＩ（全スライド画像）である、請求項１に記載のコンピュータ実装方法。
7. 前記ＷＳＩは、複数の画像のピラミッド構造を含み、前記複数の画像の前記ピラミッド構造は、少なくとも１つのＷＳＩ拡大レベルを含み、
   前記少なくとも１つのＷＳＩ拡大レベルは、前記拡大因子に対応する１セットのタイルを含む、請求項６に記載のコンピュータ実装方法。
8. 前記ビューアによって、前記キャッシュが最大占有率を有するかどうかを決定することと、
   前記キャッシュが前記最大占有率を有すると決定することに応答して、前記ビューアによって、前記ＦＯＶに基づいて前記キャッシュをソートすることと、
   をさらに含む、請求項１に記載のコンピュータ実装方法。
9. 前記ＦＯＶに基づいて前記キャッシュを前記ソートすることは、
   前記ビューアによって、前記キャッシュに格納された前記複数のタイルのうちの少なくとも１つのタイルを残すことであって、前記残すことは優先順位に従い、前記残すことは前記キャッシュが前記最大占有率以下になるまで続く、前記残すことと、
   前記キャッシュが前記最大占有率以下になると決定することに応答して、前記ビューアによって、前記キャッシュから前記複数のタイルのいずれかの残りのタイルを除去することと、
   をさらに含む、請求項８に記載のコンピュータ実装方法。
10. 前記優先順位は、前記拡大因子以上の拡大レベルを有するＦＯＶタイル、前記拡大因子以上の前記拡大レベルを有するＦＯＶ境界タイル、拡大レベルの降順では前記拡大因子より低い前記拡大レベルを有する複数のＦＯＶタイル、及び少なくとも１つの他のタイルを含む、請求項９に記載のコンピュータ実装方法。
11. 命令を格納する少なくとも１つのメモリ、及び
    前記命令を実行して操作を実行するように構成された少なくとも１つのプロセッサ、
    を含む、電子画像を処理するためのコンピュータシステムであって、
    前記操作は、
    ビューアによって、前記電子画像及びＦＯＶ（視野）を受信することであって、前記ＦＯＶは少なくとも１つの座標、少なくとも１つの寸法、及び拡大因子を含む、前記受信することと、
    前記ビューアによって、前記ＦＯＶ内に複数のタイルをロードすることと、
    前記ビューアによって、キャッシュ内の前記複数のタイルの状態を決定することと、
    前記キャッシュ内の前記複数のタイルの前記状態が全ロード状態であると決定することに応答して、前記ビューアによって、前記複数のタイルをディスプレイにレンダリングすることと、
    を含む、前記コンピュータシステム。
12. 前記ビューアによって、前記キャッシュ内の前記複数のタイルのうちの１つのタイルの前記状態がタイル要求状態であると決定することと、
    前記決定に応答して、前記ビューアによって、前記タイル要求状態をタイルサーバに送信することと、
    前記ビューアによって、前記タイルサーバからのデータ転送を受信することであって、前記データ転送は前記タイルサーバが前記タイル要求状態を受信することに応答し、前記データ転送は前記複数のタイルの前記１つのタイルに対応するタイルデータを含む、前記受信することと、
    前記ビューアによって、前記複数のタイルのうちの前記１つのタイルを前記全ロード状態に移行させることと、
    前記ビューアによって、前記複数のタイルをレンダリングすることと、
    をさらに含む、請求項１１に記載のコンピュータシステム。
13. 前記電子画像を受信することは、１セットのタイルを低い拡大レベルで前記キャッシュにロードすることを含む、請求項１１に記載のコンピュータシステム。
14. 前記ＦＯＶ内に前記複数のタイルを前記ロードすることは、
    前記ビューアによって、前記キャッシュが前記複数のタイルのうちの１つのタイルを格納するかどうかを決定することと、
    前記キャッシュが前記１つのタイルを格納すると決定することに応答して、前記ビューアによって、前記１つのタイルが前記拡大因子以上の拡大レベルを有するかどうかを決定することと、
    前記タイルが前記拡大因子以上の前記拡大レベルを有すると決定することに応答して、前記ビューアによって、前記１つのタイルを前記キャッシュからロードすることと、
    をさらに含む、請求項１１に記載のコンピュータシステム。
15. 前記１つのタイルが前記拡大因子以上の前記拡大レベルを有しないと決定することに応答して、前記ビューアによって、前記複数のタイルのうちの前記１つのタイルに対応する格納されたタイルを取得することであって、前記格納されたタイルは最も高い格納された拡大レベルを有する、前記取得することと、
    をさらに含む、請求項１４に記載のコンピュータシステム。
16. 前記電子画像はＷＳＩ（全スライド画像）である、請求項１１に記載のコンピュータシステム。
17. 命令を格納する非一時的なコンピュータ可読媒体であって、
    前記命令は、プロセッサによって実行されると、電子画像を処理するための操作を前記プロセッサに実行させ、
    前記操作は、
    ビューアによって、前記電子画像及びＦＯＶ（視野）を受信することであって、前記ＦＯＶは少なくとも１つの座標、少なくとも１つの寸法、及び拡大因子を含む、前記受信することと、
    前記ビューアによって、前記ＦＯＶ内に複数のタイルをロードすることと、
    前記ビューアによって、キャッシュ内の前記複数のタイルの状態を決定することと、
    前記キャッシュ内の前記複数のタイルの前記状態が全ロード状態であると決定することに応答して、前記ビューアによって、前記複数のタイルをディスプレイにレンダリングすることと、
    を含む、前記非一時的なコンピュータ可読媒体。
18. 前記ビューアによって、前記キャッシュが最大占有率を有するかどうかを決定することと、
    前記キャッシュが前記最大占有率を有すると決定することに応答して、前記ビューアによって、前記ＦＯＶに基づいて前記キャッシュをソートすることと、
    をさらに含む、請求項１７に記載の非一時的なコンピュータ可読媒体。
19. 前記ＦＯＶに基づいて前記キャッシュを前記ソートすることは、
    前記ビューアによって、前記キャッシュに格納された前記複数のタイルのうちの少なくとも１つのタイルを残すことであって、前記残すことは優先順位に従い、前記残すことは前記キャッシュが前記最大占有率以下になるまで続く、前記残すことと、
    前記キャッシュが前記最大占有率以下になると決定することに応答して、前記ビューアによって、前記キャッシュから前記複数のタイルのいずれかの残りのタイルを除去することと、
    をさらに含む、請求項１８に記載の非一時的なコンピュータ可読媒体。
20. 前記優先順位は、前記拡大因子以上の拡大レベルを有するＦＯＶタイル、前記拡大因子以上の前記拡大レベルを有するＦＯＶ境界タイル、拡大レベルの降順では前記拡大因子より低い前記拡大レベルを有する複数のＦＯＶタイル、及び少なくとも１つの他のタイルを含む、請求項１９に記載の非一時的なコンピュータ可読媒体。