处理电子图像以提供组织病理学切片的改进的可视化和渲染的系统和方法

相关申请

本申请要求2020年8月11日提交的第63/064,401号美国临时申请的优先权，所述临时申请的全部公开内容在此通过引用以其整体并入本文。

技术领域

本公开的各种实施方案总体上涉及改进组织病理学切片的可视化和渲染。更具体地，本公开的特定实施方案涉及用于处理电子图像以提供组织病理学切片的改进的可视化和渲染的系统和方法。本公开进一步提供用于使用机器学习、人工智能和计算机视觉来处理电子图像以提供组织病理学切片的改进的可视化和渲染的系统和方法。

背景技术

组织病理学切片是从活组织检查中提取的组织切片，并且放置在载玻片上用于显微镜检查。为了使组织在显微镜下可见，这些切片用一种或多种颜料染色，其中最常见的颜料是苏木精和曙红(H&E)，它们赋予切片显著的粉红色调。虽然这些切片可能在历史上是在显微镜下检查的，但近年来数字病理学已经得到推动。在数字病理学中，可以以非常高的分辨率扫描切片，以便稍后在监视器上查看。虽然数字病理学提供了某些优势，但以足够的分辨率扫描和可视化切片以提供所需的图像和视场可能具有挑战性。

前述一般描述和以下详细描述都仅为示例性和解释性的并且不限制本公开。本文提供的背景描述是为了一般性地呈现本公开的上下文。除非本文另有说明，否则本部分中描述的材料不是本申请中权利要求的现有技术，并且不因包含在本部分中而被承认为现有技术或现有技术的建议。

发明内容

根据本公开的某些方面，公开了用于处理电子图像以提供组织病理学切片的改进的可视化和渲染的系统和方法。

一种用于处理电子图像的计算机实现的方法，所述方法包括：由查看器接收电子图像和FOV(视场)，其中FOV包括至少一个坐标、至少一个维度和放大倍数；由查看器在FOV内加载多个图块；由查看器确定多个图块在高速缓存中的状态；以及响应于确定多个图块在高速缓存中的状态是完全加载状态，由查看器将多个图块渲染到显示器。

一种用于处理电子图像的计算机系统，所述计算机系统包括存储指令的至少一个存储器，以及至少一个处理器，所述处理器被配置为执行所述指令以执行操作，所述操作包括：由查看器接收电子图像和FOV(视场)，其中FOV包括至少一个坐标、至少一个维度和放大倍数；由查看器在FOV内加载多个图块；由查看器确定多个图块在高速缓存中的状态；以及响应于确定多个图块在高速缓存中的状态是完全加载状态，由查看器将多个图块渲染到显示器。

一种存储指令的非暂时性计算机可读介质，所述指令在由处理器执行时使所述处理器执行用于处理电子图像的操作，所述操作包括：由查看器接收电子图像和FOV(视场)，其中FOV包括至少一个坐标、至少一个维度和放大倍数；由查看器在FOV内加载多个图块；由查看器确定多个图块在高速缓存中的状态；以及响应于确定多个图块在高速缓存中的状态是完全加载状态，由查看器将多个图块渲染到显示器。

应理解，以上概述和以下详述都仅是示例性和解释性的，并且不限制要求保护的所公开的实施方案。

附图说明

并入本说明书并且构成本说明书的一部分的附图说明各种示例性实施方案，并且连同描述一起用来解释所公开的实施方案的原理。

图1描绘根据本公开的示例性实施方案的整个切片图像的金字塔结构。

图2描绘根据本公开的实施方案的示例性查看器的视场(FOV)。

图3描绘根据本公开的实施方案的示例性查看器的架构。

图4示出根据本公开的实施方案的来自查看器的示例性图块请求的定时分解。

图5是示出根据本公开的实施方案的示例性图块请求的控制流程的流程图。

图6A是根据本公开的实施方案的查看器的架构。

图6B是根据本公开的实施方案的查看器的本机应用程序的架构。

图7A是示出根据本公开的实施方案的图块请求的控制流程的流程图。

图7B是示出根据本公开的实施方案的具有时延指示的图块请求的控制流程的流程图。

图8是示出根据本公开的实施方案的图块请求的静态控制流程的流程图。

图9是示出根据本公开的实施方案的查看器架构的主循环的流程图。

图10A描绘根据本公开的实施方案的在查看器中对切片的第一注视。

图10B描绘根据本公开的实施方案的查看器中的加载视场。

图11描绘根据本公开的实施方案的在示例性查看器中具有预加载图块的视场。

图12示出根据本公开的实施方案的查看器内的示例性图块解码的定时分解。

图13A示出根据本公开的实施方案的具有动态图块化的示例性实施方案的视场(FOV)完成。

图13B示出根据本公开的实施方案的具有静态图块化的示例性实施方案的FOV完成。

图14示出根据本公开的实施方案的具有图块预加载的示例性实施方案的FOV完成。

图15A至图15F示出根据本公开的实施方案的示例性实施方案的不同FOV完成。

图16是根据本公开的实施方案的流媒体查看器的示例性架构。

具体实施方式

现在将详细参考本公开的示例性实施方案，附图中示出了示例性实施方案的实例。在可能的情况下，贯穿附图将使用相同的附图标记来指代相同或相似的部分。

本文公开的系统、装置和方法通过示例并参考附图进行详细描述。本文讨论的示例仅是示例并且被提供以帮助解释本文描述的设备、装置、系统和方法。除非明确指定为强制性的，否则附图中所示或以下讨论的任何特征或组件均不应被视为针对这些装置、系统或方法中的任何一个的任何特定实现方式为强制性的。

此外，对于所描述的任何方法，无论所述方法是否结合流程图进行描述，都应理解，除非上下文另有规定或要求，否则在执行方法时所执行的步骤的任何显式或隐式排序不暗示这些步骤必须按照给出的顺序执行，而是也可以以不同的顺序或并行执行。

如本文所用，术语“示例性”在“示例”而非“理想”的意义上使用。此外，本文中的术语“一(a/an)”并不表示数量限制，而是表示存在一个或多个所引用的项目。

扫描仪制造商通常会维护自己的软件，以便在扫描仪旁边可视化切片。它们还可能使第三方软件能够以大致相同的方式打开和读取这些切片。这些软件包或模块通常称为切片查看器。除了其他内容之外，本公开包括可以打开从各种扫描仪获取的切片的新颖切片查看器的示例性实施方案。此查看器可以在所有现代互联网浏览器(即Google Chrome、Mozilla Firefox、Microsoft Edge、Apple Safari等)上运行。除了其切片查看功能之外，切片查看器还可以通过具有用于癌症检测的高级医疗级人工智能推理来与其他产品结合。

切片扫描是分辨率范围从20,000x20,000到超过120,000x120,000像素的图像。这些图像描述性地称为全切片图像(WSI)，即使在有损压缩后，磁盘上的重量也可能达到数千兆字节，并且无法有效地传输到客户端以供及时查看。处理大型数字图像存在某些技术障碍。首先，带宽是在特定时间量内可以传输多少数据的限制因素。由于查看器是通过互联网访问的，因此这种带宽通常有每秒几兆字节的上限。这意味着传输千兆字节图像将花费数秒甚至数分钟。另外，可能需要大量的处理能力以便解码这些图像。虽然256x256的小图像可以在大约一毫秒内解码，但解码十亿像素图像需要几秒钟，如果不是几分钟的话。最后，就内存而言，虽然压缩图像可能有大约千兆字节的重量，但未压缩数据要大一个数量级。此数据量将无法一次放入计算机的内存中。

一个目标是在涉及WSI时找到改进当前技术栈的方法。本公开涉及的几个感兴趣的领域包括流式传输组织病理学切片数据的新方法。当前的切片查看器可以使用开源库和供应商软件开发工具包(SDK)来打开和读取切片。这些选项不是最有效的，并且更好的技术可以显著加快流式传输。

例如，这可能涉及更改切片的数据表示格式，因为它们存储在磁盘上以启用新的优化或充分利用现有的优化。从历史上看，切片一直以其原始格式存储，这完全取决于扫描仪供应商。不同的供应商可能有不同的限制，并且这意味着没有统一的格式可能会使优化所有可能途径变得更加困难。

新的压缩技术也可以改进当前切片查看技术。此项研究的中心侧重于可以更有效地存储切片图像数据的新压缩技术。例如，组织检测算法可以避免必须存储未检测到组织的大部分图像。较新的图像格式也可能通过在编码过程中利用更先进的技术或更多的计算能力来产生更好的压缩比。

此外，服务器端渲染可以改进当前的切片查看技术。虚拟网络计算(VNC)技术已经证明，可以通过将视觉源流式传输到客户端，进而将用户输入发送到服务器来构建实时交互体验。由于高性能视频编解码器，这种方法可能能够最大限度地减少数据传输，同时实现卓越的用户体验。

此外，切片查看技术的改进可能包括前端渲染技术。网络浏览器现在已经能够利用图形处理单元(GPU)渲染。WebGL应用程序编程接口(API)允许JavaScript应用程序以受OpenGL启发的习语执行渲染指令，OpenGL是3D渲染的行业标准。最近，WebGL 2.0和WebGPU等新API通过允许对GPU原语进行较低层级访问而取得进一步成果。这些技术可以应用于切片查看器，以加快切片查看器的速度并减少其内存消耗。

在以下部分中，将使用特定词汇来描述与示例性WSI查看器相关的概念。

如上所述，WSI是组织病理学切片的高分辨率图像扫描。这些图像的分辨率在十亿像素范围内。此属性使得以传统方式存储和显示这些图像变得不切实际。事实上，要在内存中解码整个图像非常困难，因为它会占用数十千兆字节的空间，这超过了当今可用的许多个人计算机的内存容量。此外，显示整个图像也很困难，因为监测器分辨率接近百万像素。

因此，WSI的编码方式允许区域解码。可以显示图像的每个区域，而不必用它读取或解码整个图像。如前所述，病理学家用来查看切片的监测器通常无法显示全分辨率图像。因此，通常只有当前呈现在屏幕上的区域可以被解码并发送到客户端。这种优化可以实时索引化和读入WSI。

但是，如果病理学家决定缩小屏幕并在屏幕上显示整个切片，这种方法就不够了。为了甚至显示完整图像的下采样版本，可能仍然需要完整读取图像。为了解决这个问题，除了全分辨率基线图像之外，WSI还包括具有较小分辨率的中间放大级别，一直到可以适合屏幕的缩略图。这样的组织通常被称为金字塔结构，金字塔的底部是基线图像，并且上面的每一级别可能是一个中间放大级别。

为了允许区域解码，每一级别可以被切割成规则网格中的图块。可以随机访问这些图块。为了解码图像的区域，可能只需要读取和解码与其重叠的图块。图1是此金字塔结构的示意图。

如图1所示，金字塔结构具有包括全分辨率图像的基线图像1。至少一个下采样图像，即图1中的下采样图像2和3可以放置在基线图像1的顶部。基线图像1以及下采样图像2和3可以如上所述切割成规则网格。

查看器的视场(FOV)是当前显示的图像区域。它可以被认为是坐标(x，y)、维度(w，h)和放大倍数z的分组。放大倍数可以确定WSI的哪个级别最适合显示，而坐标和维度可以确定应解码级别图像的哪个区域。

图2示出如何为了显示所请求的FOV 12可能仅需要解码级别图像10的几个活动图块11。空闲图块13可以不包括在FOV 12中。

当FOV12移动时，活动图块11将改变。只有当前需要显示的图块可能需要保存在存储器中。因此，所需的图形内存可以是显示器分辨率的函数，而不是图像大小的函数。

为了更好地识别要改进的不同区域，一种可能的方法是仔细研究示例性切片查看器的架构。图3中示出示例性切片查看器的架构。示例性切片查看器可以由前端20和后端(“图块服务器”)30组成。前端20可以负责向用户显示WSI，而后端30可以负责将可能需要的数据传送到前端。在以下部分中公开了关于示例性组件的更多细节。

由于用户可以通过网络浏览器访问示例性切片查看器，因此前端20(如图3所示)可以是用JavaScript编写的网络应用程序。示例性切片查看器可以广泛使用查看器21，例如OpenSeadragon开源库，它是用于高分辨率图像的基于网络的查看器。

例如OpenSeadragon的查看器21可以处理WSI的一些或所有渲染，以及用户交互，例如使用“切片导航”面板进行平移、缩放和跳跃。用户可以用鼠标拖动屏幕来平移显示，同时滚动放大和缩小。可能还有其他功能，例如旋转显示、测量物理距离、在画布上绘制注释等。

如上所述，WSI被分成多个放大级别并且被切割成图块(参见图1的金字塔)。为了显示给定的FOV，查看器21(例如OpenSeadragon)从后端30加载覆盖FOV的所有图块，所述后端也可以称为图块服务器。

OpenSeadragon是用于查看高分辨率图像的强大解决方案。然而，与针对网络平台的一些其他高分辨率图像查看器解决方案相比，OpenSeadragon在用户交互过程中并不总是能够保持恒定的60帧/每秒(FPS)。这可能会导致次优的用户体验。Seadragon也可能仅支持仅使用2D浏览器画布应用程序编程接口(API)进行渲染。因此，WebGL可以用作可以更好地利用客户端的图形功能的性能更高的API。

OpenSeadragon并不是可用于在浏览器中查看大图像的唯一的可能解决方案。其他合适的查看器解决方案包括OpenLayers、Leaflet、MapBox和DeckGL。所有这些解决方案都是为地理数据量身定制的，但也可以适用于支持2D像素数据。这些解决方案中的一些支持WebGL并具有良好的性能。但是，它们可能包含不需要的特征。因此，可能的解决方案的表面积可能非常大，这使得修改变得更加困难。

前端20还可以包括商业逻辑算法22。

示例性切片查看器的后端30可以包括用C#编写的网络服务器31。网络服务器31可以利用IIS网络服务器32上的软件来高效地服务于HTTP请求。

后端30是示例性查看器中的一个感兴趣组件：给定具有在坐标(x，y)和放大级别z处的维度(w，h)的图块的请求，后端30返回对应图像。由于示例性切片查看器可以支持多种WSI格式，因此后端30可以调用不同的实现方式34，例如深度缩放实现方式34，如图3所示。这些实现方式34拥有从原始WSI文件中解码请求的图像区域的逻辑。通常，WSI文件可以存储在与后端30相关联的文件系统35上。

深度缩放是一种用于流式传输和可视化超大图像的技术。深度缩放图像(DZI)由两部分组成：DZI文件和目录。DZI文件(.dzi)描述用于可视化目的的图像格式。两个重要的属性可能是图块大小和基线分辨率，通过将基线分辨率乘以2的负幂，可以从中推断出一些或所有中间放大级别。例如，基线分辨率为1024×1024，第一个中间级别的分辨率为512×512，第二个为256×256等。除了DZI文件，目录可能包含一些或所有图块图像，它们自己排列在对应于不同放大级别的文件夹中。例如，存储在路径tiles/3/12.jpg下的文件对应于放大级别z＝3和坐标(x，y)＝(1，2)的图块。在z＝3时，级别分辨率是基线图像分辨率的八分之一。

就网络服务器的性能而言，图块请求应该是近乎即时的。为了让查看器感受到响应，图块请求可能需要具有低时延和高吞吐量。因此，可能需要使用最快的可用技术，尽可能缩短检索和服务图块的管线。在这种情况下，使用例如IIS的成熟网络服务器可能过犹不及。

有可能以C#构建低时延系统，但所述语言可能使其变得困难。C#是一种难以收集的语言：内存分配是自动的，并且进程可能偶尔遍历已分配对象的图形以确定哪些可以解除分配并释放内存。这意味着C#是完全内存安全的，并且程序员很少需要担心内存管理。但是，此进程并非没有代价，并且当它在请求待决的同时运行时可能导致时延尖峰。此外，垃圾收集语言可能平均使用更多的内存来跟踪对象的活跃度。最后，编译后的C#代码在虚拟机上运行，这会占用其自身的性能和内存使用量。在个人机器上，服务器的开发版本可能需要整整一分钟并分配多达700MB的内存才能开始响应HTTP请求。使用不同的实现和支持技术，这两个数字都可以显著减少。

图4和图5从用户的角度提供图块请求的定时和控制流程的快速概览。图块请求的控制流程是底层算法的简化版本。

如图4所示，时间线度量可以包括请求41、传送首字节的时间(TTFB)42、下载43、解码44和绘图45可能花费的相对时间。例如下载43的慢速路径以条纹图案表示，而例如TTFB的慢速操作以具有较粗条纹的另一种图案表示。请求41可以在图块请求的控制流程中包括相对较短的时间，而TTFB可以花费相对长得多的时间。传送首字节的时间(TTFB)42度量表示服务器的时延，并且是关于本公开的其余部分可能最关注的度量。下载43在控制流程中也可能花费较长的时间，而解码44和绘图45步骤可以较快地完成。

图5是从用户的角度示出图块请求的定时和控制流程的概览方法50的流程图。

在步骤51中，所述方法可以包括查看器请求坐标(x，y，z)处的图块。此请求可以经由HTTP协议发送。

在步骤52中，服务器(例如，如图3所示的图块服务器或后端30)可以接收请求并且可以确定服务器是否已经准备好请求的图块。

在步骤53a中，如果服务器已经确定切片没有准备好，则服务器可以从存储装置加载切片。

在步骤53b中，如果服务器改为确定切片已经准备好，则所述方法可以包括服务器然后可以确定服务器是否已经准备好在所请求坐标处的图块。

在步骤54中，如果已经从存储装置加载切片或者如果服务器还没有准备好图块，则所述方法可以包括服务器生成所请求的图块并存储所述图块。

在步骤55中，所述方法可以包括查看器从服务器接收图块，所述图块或在步骤54中生成或在步骤53b中已经由服务器处理。

切片查看器的示例性实施方案具有两个目标。首先，切片查看器应该很快。在加载FOV之前，用户可能不必等待很长时间，并且查看器在平移和缩放时应保持恒定的60FPS。病理学家习惯于显微镜，其中时延仅受光速限制。对于示例性查看器，可能更愿意努力尽可能接近地复制这种体验。最终目标是没有可察觉的时延。作为参考，100ms的响应时间被认为是向用户提供即时反馈感觉的上限。

其次，切片查看器需要是可测量的。能够提供关于示例性查看器在使用中如何执行的精确度量可能很重要。为了与现有的切片查看器进行比较，需要代表实际负载的基准套件。

通常，网络应用程序(例如切片查看器)有一个常量。JavaScript主要是网络的主要语言，并且以前是浏览器将本地运行的唯一语言。

最近，浏览器开始实现虚拟机来运行WebAssemb1y(Wasm)，这是一种针对网络平台的汇编代码。由于安全性在浏览器中至关重要，因此它被设计为完全沙盒化。访问网站是不可取的，因为它只能完全访问机器。除了Wasm的优势：它的执行速度也比JavaScript快得多。为了让浏览器执行JavaScript，可以执行以下步骤：

a.下载原始JavaScript源。

b.将JavaScript解析为抽象语法树(AST)。

c.将JavaScript编译为机器代码，这可能因实现方式而异。从历史上看，JavaScript是一种完全解释性的语言。随着即时(JIT)编译的出现，现在通常将其称为编译语言。

d.执行JavaScript。

以上步骤说明了所述过程的概述。在实践中，可以部分地跳过一些步骤。例如，浏览器的JavaScript引擎不需要解析整个JavaScript源就可以开始执行。事实上，它可以使用其词法分析器快速跳过首次执行时可能不需要的整个代码区段。这可以称为惰性编译。

然而，一些步骤无法完全优化掉。尽管现代JavaScript代码在发送到客户端之前缩小和压缩，但它比原始字节码更重。同样，虽然在某些情况下可以跳过解析，但它需要在某个时候发生。JIT编译可能具有令人印象深刻的性能，但它在运行时涉及额外的步骤。

作为字节码，Wasm为大部分这些问题提供简练的解决方案。但更重要的是，Wasm是编译目标。这意味着实现Wasm后端的任何语言都可以在浏览器2中运行，这在网络历史上是非常令人兴奋的发展。

Rust是新的现代语言，具有许多有趣的特性：与C和C++一样，所述语言具有手动内存管理的特点，可以精确地控制程序的内存消耗模式。

然而，与C和C++不同的是，Rust是内存安全的。由于包含称为生命周期的新概念和内置的资源获取即初始化(RAII)，手动内存管理的大部分复杂性和易变性都由编译器本身处理。这被认为是Rust的定义特征：其通过默认禁止可证明不安全的操作来消除一整类程序员错误。

Rust遵从LLVM(低级虚拟机)后端进行编译。因此，Rust可以利用LLVM编译器提供的许多优化，这可能产生与其C/C++对应物一样快、有时甚至更快的代码。此外，所有LLVM目标都可能得到本机支持，包括Linux、WindowS、macOS等。此列表可能还包括Wasm。

Rust还包括现代编程语言中预期的许多其他特征，例如但不限于：高级类型系统；零成本抽象；模式匹配；功能基元；异步编程；内置包管理器和编译工具链；内置自动代码格式化和1检查；以及自动C和C++绑定生成。Rust仍在快速演进，并且可能提供更多改进，同时保持严格的向后兼容性策略。由于其原始性能和迭代速度，Rust越来越受欢迎。手动内存管理和本机目标的结合意味着Rust的运行速度可能没有任何人为的界限。此外，由于Rust不进行垃圾回收，因此性能是可预测的：没有“滞后尖峰”效应。重要的是，Rust是安全的一已经证明70％的全部严重安全漏洞是由内存安全问题引起。Rust还可以在浏览器中运行，这意味着用户可以利用Rust代码库和Wasm性能的所有优势，而没有与网络应用程序相关联的历史缺陷。这也使得在浏览器和本机目标之间共享代码成为可能。尽管有前述内容，但预期当前存在的或未来开发的任何期望的语言或代码库可用于运行与本公开的实施方案一致的网络服务器和/或切片查看器。

图6A是切片查看器100的示例性实施方案的示例性示意图。在前端60上，核心查看器61和渲染逻辑可以用Rust编写，而更高级别的用户界面逻辑62可以用带有React7的TypeScript6编写。对于图块服务器或后端70，可以使用网络服务器71，例如目前被认为是性能最高的网络服务器之一的Actix Web网络服务器。路由逻辑72、图像解码或切片读取器逻辑73和文件系统逻辑74都可以用Rust编写。然而，在此示例性实施方案的范围内，还可以实现对Aperio SVS切片的支持。实现对其他切片格式的支持可能需要将绑定写入C++库(例如Philips iSyntax)或手动重新实现解码逻辑。查看器核心逻辑可以用Rust编写，从而解锁新的可能性，例如本机渲染。通过混合前端和图块服务器代码库，查看器的本机版本可以在Linux、Windows和macOS上的窗口中运行。

图6B示出这种程序的示例架构。在图6B中，本机应用程序400是用Rust编写的，并且包括查看器401、用户界面402、切片读取器403和通用文件系统404。

图块请求剖析

当用户请求坐标(x，y)和放大级别z(称为坐标(z，x，y))处的图块时，图块服务器启动图7A和图7B所示的程序。所述程序经历多个步骤和分支，并以向用户提供与所请求图块相对应的图像结束。

图7A是示出来自用户的示例性图块请求程序700(例如，步骤702-710)的流程图，如上所述。示例性图块请求程序700的所有步骤可以是可选的并且可以以任何顺序完成。每个步骤的出现也可能不同，如步骤之间线条图案的差异所示。线条中的一种虚线图案可以表示所述步骤总是、经常或很少发生，而连续的、不间断的线可以表示所述步骤很少发生(即，通常只发生一次，例如发生步骤705、706和707)。

在示例性图块请求程序700中，用户701可以向服务器请求图块。特定图块请求可包括与病理学标本图像相关联的数字图像的多于一个图块，或者可以是数字图像的单个图块。

在步骤702中，所述程序可以包括将图块请求路由到服务器。

在步骤703中，服务器可以确定所述图块是否已经由服务器生成。如果图块已经由服务器生成，则过程可以前进到步骤709，如下所述。

如果服务器还没有生成图块，则服务器然后可以在步骤704中确定与所请求的图块相关联的切片是否在高速缓存中。在所请求的图块尚未生成但WSI在高速缓存中的一种情况下，服务器可以读取对应于图块的区域并将得到的图像文件提供给用户，如步骤708中所述。保存此文件以防客户端再次请求相同的图块，如步骤710中所述，在这种情况下，所述程序可能能够完全绕过区域解码步骤。

如果与所请求的图块相关联的切片不在高速缓存中，则服务器然后可以在步骤705中确定所述切片是否在本地文件系统(FS)上。如果切片在本地文件系统上，则程序可以前进到步骤707，如下所述。

如果切片不在本地文件系统上，则服务器然后可以在步骤706中将切片下载到本地文件系统。一旦切片被下载到本地文件系统，服务器可以在步骤707中打开切片。

在步骤708中，服务器可以读取图块区域，并且可以在步骤710中继续保存图块文件，或者可以在步骤709中将文件返回给用户701。

当用户第一次请求切片，或者自从他们上次请求切片离开高速缓存并从本地FS中清除后已经过了足够长的时间时，服务器可能需要从远程FS检索切片(例如，亚马逊网络服务(AWS)S3桶)到本地FS并打开切片。当客户端第一次检索与WSI相关的元数据时，此操作可能只会发生一次。

示出相同的示例性图块请求程序700的图7B中描述的步骤可以进一步示出与每个步骤相关联的时间成本，其被称为发生的时延。此时延加起来形成整个请求的总时延，用户将所述总时延体验为TTFB度量。

每个步骤发生的时延可以由每个步骤周围的图案化线条来说明。例如，带有虚线图案的线条可表示步骤发生的时延小于一毫秒，而较细的线条可表示发生的时延在一到十毫秒之间等。

图8通过示出每一步骤发生的时延来补充图7。最快路径可以是当图块已经由服务器生成(由服务器在步骤703中确定)并且只需要被服务时。在这种情况下，图块存在于FS上，并且可以直接流式传输给用户。

然而，最常见的情况是FS上不存在图块并且必须从WSI生成图块，但切片在高速缓存中可用。与最快路径相比，这种情况需要两个额外的步骤：

a.从WSI解码图块区域，这是阻塞的。

b.将文件保存到FS，这是非阻塞的：操作与服务文件并行发生。

最后，在切片不存在于高速缓存中(由服务器在步骤704中确定)并且可能不存在于本地FS上的罕见情况下，服务器可能需要从FS中检索WSI文件(如在步骤706中)。由于文件非常大，因此这可能需要几秒钟的时间。有利的是，当用户首次请求切片时，这种情况通常只会命中一次，这可能使其高时延可以接受。

此算法可类似于图5中所示的算法。由于一个示例性实施方案实现方式的开销较低，因此其平均时延可能较低，如下文所示。

区域解码

解码WSI区域的程序可完全取决于图像的格式。

一个此种格式的WSI可以采用ScanScope虚拟切片(SVS)图像的形式，它使用TIFF图像容器格式。这些图像由以下部分组成：

a.指向图像标头注册表的标头；

b.指向图像元数据注册表的图像标头；

c.图像元数据，其包括宽度、高度、描述、色度信息等细节；以及

d.图像数据，可能有两种不同的格式：

i.连续的像素行。将这些行垂直堆叠在一起将重新组合图像。此格式可用于较小的图像。在SVS中，这些是标签、缩略图和宏图像。

ii图块从上到下、从左到右列出。在这种情况下，图像被切割成可以单独地进行编码的矩形图块的规则网格。此格式可用于图像的不同放大级别，以便允许对这些大图像进行部分解码。此原理由图1示出。

SVS文件中的图像数据可以用三种不同的方式编码。标签图像可以使用LZW压缩算法进行编码，而缩略图和宏图像可以使用JPEG进行编码。基线图像和不同的放大级别可以用JPEG或JPEG2000编码。

由于图块服务器公开的放大级别和图块尺寸与存储在WSI中的放大级别和图块尺寸可能不同，因此为了生成图块而解码图像区域比简单地在正确的放大级别索引正确的图块更复杂：

a.首先，所述程序可以选择放大倍率最接近用户请求的WSI级别，并且如果可能，选择更高的放大倍率：选择更低的放大倍率可能会导致信息丢失。

b.然后，将覆盖所请求区域的所有WSI图块位块传输到一个缓冲区，所述缓冲区的尺寸等于所请求区域尺寸，所述尺寸投影到所选WSI级别的放大倍率。

c.然后将此缓冲区线性重采样为所请求区域的尺寸。如果客户请求的级别的放大倍率与所选WSI级别的放大倍率相同，则可能不需要此步骤。

最后，一旦一个区域被解码并且在可以将所述区域提供给客户端之前，它可能需要被编码回浏览器能够理解的图像格式。有关图像格式的更多详细信息可以参见下文。在示例性图块服务器中，图像被编码为质量设置为75的JPEG。

这一系列操作可涉及解码太多图像、可能调整图像大小以及对最终结果进行编码。这可能需要10与100ms之间的任何时间，有时在病理情况下会更长。这些步骤的性能还取决于所使用的编码、解码和大小调整算法。在图块服务器的示例性实施方案中，可以使用MozJPEG5图像解码器和编码器，因为它的速度至少是当前最佳Rust实现方式的两倍。

图像格式

存在多种WSI格式，其使用不同的容器格式和压缩技术：SVS(.svs)；PhilipsiSyntax(.isyntax)；Hamamatsu(.vms，.vmu，.ndpi)；Leica(.scn)；MIRAX(.mrxs)；Sakura(.svslide)和其他TIFF变体。这些格式可以是对应制造商的扫描仪的输出。一些切片查看器可以存储原件并使用供应商框架和OpenSlide开源库在用户打开和查看切片时打开和读取图像。然而，此进程可能有许多缺点。

为了让框架读取切片，切片可能需要出现在本地FS上。下载图块或安装远程FS将增加进程的时延。此外，由于这些文件非常大，因此将它们保存在热存储装置中的成本是不经济的。

其次，这些框架可能各自有自己的实现方式、行为和API。这可能会导致它们之间的性能配置文件不同。因此，切片格式之间的用户体验可能有所不同，因为有些切片格式的加载时间会比其他切片格式长。也大大增加了图块服务器的复杂度，可能需要全部调用进去。

最后，对WSI格式使用的压缩技术的控制较少。一些文件格式使用较旧的压缩技术，这些技术在今天可能不是最佳的，因此比必要时占用更多空间或使用更多的处理时间进行解码。

压缩方法

SVS和Philips iSyntax使用的主要压缩技术是离散余弦变换(DCT)(JPEG)和离散小波变换(DWT)(JPEG2000)。尽管它们都支持无损压缩(通过JPEG无损扩展的JPEG)，但它们以有损形式使用。

JPEG2000是比JPEG更新的技术，并且在相同的图像质量级别下，它的压缩率比JPEG更好。但是，它的计算成本更高，这使得它不太适合涉及重复编码和解码的场景。此外，自20年前出现以来，JPEG2000未能获得广泛采用，并且仅在组织病理学切片存储等极少数情况下使用。最后，浏览器本机不支持JPEG2000，但支持JPEG。

压缩方法

最近的图像压缩技术包括：

a.WebP，其使用VP8编解码器。虽然WebP不是当今性能最高的格式，但除了Safari之外的所有主要浏览器都支持它，Safari可能在版本14中支持它。

b.HEIF，其使用HEVC编解码器。目前没有任何浏览器支持。

c.AVIF，其使用AV1编解码器。目前没有任何浏览器支持，但打算在Chrome和Firefox中支持。

d.FLIF.没有任何浏览器支持。

e.JPEG XL.未最终确定，并且没有任何浏览器支持。

在一般情况下，上述所有格式的性能都可能优于JPEG，而且通常也可能优于JPEG2000。

对于本公开，JPEG XL可能是最有前途的图像格式。在联合图像专家组(JPEG)的支持下，它承诺具有以下特性：

a.一流的图像压缩比和图像质量；

b.归因于适用于多线程和单指令多数据(SIMD)的设计，具有快速编码和解码性能；

c.与JPEG解码器的某些向后兼容性；以及

d.传统JPEG文件的无损转码。

此外，JPEG XL还可能包括Brunsli13JPEG重新打包器，其可以减少文件大小，同时允许逐字节恢复原始JPEG。考虑到本公开的示例性实施方案存储的传统JPEG图像流的数量，采用这种格式可产生显著的节省。

如上所述，除了WebP和Safari之外，目前这些较新的格式没有浏览器本机支持。然而，这并不一定会消除它们的使用：由于Wasm，仍有可能在浏览器中解码这些格式中的一些格式。值得注意的是，参考JPEG XL实现方式附带对WebAssemb1y的支持。

与浏览器的本机JPEG解码器相反，Wasm实现方式可能无法利用多线程或SIMD，因为这些特征目前仅在浏览器中部分可用。因此，尚不清楚这些实现方式是否能够为快速客户端解码提供必要的性能。尽管如此，由于这些格式中的一些格式通常比当今可用的最佳JPEG解码器更快，因此这很可能是可能的。

预图块化

上文描述图块请求的剖析，并解释当已经生成所请求图块时会出现更快的路径。如果这个想法更进一步，并且用户希望所有的图块都已经生成，则可能简化图块服务器的架构。事实上，所述架构可以简化到成为静态文件服务器的程度，即其目的可能是提供永不更改的内容的服务器。此种服务器可能经过高度优化，因此请求非常快。图8示出此服务器的架构。

图8是示出服务器架构的示例性实施方案的工作流程。工作流程可以从用户801开始，所述用户可以从服务器请求文件。在步骤802中，工作流程可以包括服务器确定文件是否存在于服务器上。当用户请求不存在的图块时，在服务器上找不到相应的文件，并向客户端发送错误803。然而，如果文件确实存在，则服务器可以在步骤804中提供所述文件。

热路径(例如，步骤802与804之间的进程)直接为文件提供服务。然而，这种情况在图块服务器的正常使用下可能是不希望的，因为客户端确切地知道哪些图块是可用的。

此架构仍然会涉及在某些时候生成图块。这可能是切片摄取管线的责任，并且可能会在切片在相关联服务器上可用时立即发生。这样，用户可以尽快使用它。

虽然预图块化似乎是合适的解决方案，但它仍然存在一些缺点：

a.预图块化意味着在切片到达相关联服务器的时间与它对用户可用的时间之间增加了一些时延。然而，这在实践中可能不是问题，因为此进程可能是连续的和自动化的，并且用户可能不需要立即得到结果。此外，理论上可以通过在图块尚不可用时回退到原始图块服务器架构来缓解这种情况。最后，如果生成图块的过程足够快，这可能只会导致几十秒的延迟。

b.与按需图块化相反，预图块化可能意味着始终存储切片的所有生成的图块。实际上，这会使存储切片所需的空间量翻倍，进而增加存储成本。由此得出的一个推论是它还可以最大限度地延长生成图块所需的处理时间。

查看器架构

在一些实施方案中，查看器可以在两个主循环中运行。一个循环是后台循环，其处理图像请求、解码和图形内存中的加载，以及高速缓存修剪或高速缓存排序操作。第二个循环是渲染循环，其可能只处理对显示器的渲染。

在执行期间，这两个循环可以调用查看器的不同组件。核心计算图块可见性和绘制调用，可能需要在显示器上绘制这些绘制调用。渲染器充当底层图形实现方式的绑定，它可以是2D Canvas、WebGL或任何本机图形API。加载程序从远程源(网络)或从本地文件系统(本机)异步加载图块。

高速缓存存储图块图像和GPU纹理，并在达到其最大占用率时偶尔自行修剪或排序。存储在高速缓存中的图块可以以两种状态之一存储：(1)图块请求状态，或(2)完全加载状态。在图块请求状态下，图块可能处于例如从图块服务器或其他存储装置加载的进程中。在完全加载状态下，图块图像可能已经完全加载。此外，例如，如果来自前一组的图块尚未完全加载，则查看器可能不存储来自下一组的图块。

此外，可能还有取决于查看器运行的平台的第三个循环：事件循环，其处理用户事件，例如鼠标事件和键盘事件。在浏览器中，所述第三个循环可由JavaScript引擎自动处理。事件循环是应用FOV更改的地方：当用户单击并拖动显示时，会触发事件，并且应用程序逻辑相应地更新FOV。

图9是这两个循环的流程图的总结900。

后台循环901

后台循环901可能是大部分后台处理发生的地方。后台循环可以安排在下一帧开始之前进程有空闲时间的任何时候运行。后台循环甚至可以安排在后台线程中。后台循环901可以如下进行：

给定FOV 903，后台循环901可以计算其中当前可见的图块。这可以通过查看器的核心处理器在步骤905中确定哪些图块可见来实现。

例如，当查看器的FOV发生变化时，查看器可以按照以下优先级顺序从高速缓存中成组加载图块：

a.在放大级别下处于FOV内的图块，可以等于或大于FOV的放大倍数;

b.在放大级别下与FOV接壤的图块，可以等于或大于FOV的放大倍数;

c.在更高放大级别下处于FOV内的图块；以及

d.在更低放大级别下处于FOV内的图块。

另外，当查看器从高速缓存加载图块时，如果所述图块之前未存储在高速缓存中，则所述图块可以自动存储在高速缓存中。

例如，从高速缓存中检索到的图块可能具有等于或大于FOV的放大级别的放大级别。然而，在一些实施方案中，这并不总是可能的，因为可能无法针对任意大的放大级别的无穷大计算图块。在这种情况下，例如，当FOV的放大倍数可能超过可用的最大图块放大级别时，可以从高速缓存中检索来自可用的最大图块放大级别的图块。

FOV的放大倍数可以是连续值。例如，FOV放大倍数可以是0.1、2.0，也可能是0.123456……等。图块或WSI的放大级别可以是一组图块，其中这组图块可以对应于离散和有界的放大倍数，例如1、2、4、8等。例如，当FOV的放大倍数为2时，可以加载放大倍数大于或等于2的图块。然而，如果不存在这样的图块，则可以加载放大级别为可用的最大放大倍数的图块。此进程可以发生在图块服务器和/或查看器上。

如果在查看器的高速缓存中未找到任何图块907，如可在步骤909中确定，则高速缓存可开始异步加载它们的图像。图像可以由查看器的加载器加载，所述加载器可以在步骤912中请求图像910。在进行请求之后，可以将图像910发送回高速缓存。

如果这些图块907中的任何一个具有加载到高速缓存中的图像910但没有相关联的纹理911，其可以开始将纹理911异步上传到查看器的GPU，如步骤913所示。

一旦做出了所有请求，如果有必要，在步骤914中可以修剪高速缓存以释放未使用的图块图像和GPU纹理的图形和系统内存。

渲染循环

渲染循环912可负责更新显示以反映对FOV 903的改变。渲染循环912可以安排为每个显示帧运行一次，这在大多数监测器上将是60次/每秒(60FPS)。渲染循环912可以具有如下进程：

给定FOV 903，渲染循环912可以计算当前在FOV 903内可见的图块。进程可以包括步骤915，其中查看器的渲染可以确定哪些图块是可见的。如果在高速缓存中没有找到任何图块，则渲染循环912可以替代地从覆盖图块表面区域的不同放大级别寻找图块。

然后渲染器可以根据需要检索纹理，如步骤916所示。然后，渲染循环可以生成描述在显示器上的何处绘制图块纹理的绘制调用917，并将它们发送到渲染器，渲染器负责实际执行它们，如步骤918所示。

渲染技术

使用泛型，查看器可以将一些或全部渲染逻辑委托给外部实现方式。这使得可能快速添加新的图形实现方式，例如支持新平台，而无需更改任何现有代码。

从历史上看，2D canvas是所有主要浏览器都支持的第一JavaScript图形API。这使它成为最便携的。然而，顾名思义，它可能只支持2D上下文。因此，可能不适合大量应用。此外，作为高级抽象，它可能以性能和可定制性为代价隐藏了图形渲染的大部分复杂性。由于查看器在一些实施方案中是2D应用程序，因此画布可能特别适合对其进行渲染。

WebGL是OpenGL ES 2.0标准的实现方式，旨在在浏览器上下文中运行。它公开了用于渲染3D图形的JavaScript API，这也使其适用于2D图形。它是比画布更低级别的API，可以更好地控制操作的组成方式和内存的管理方式。作为OpenGL之上的薄层，WebGL具有在大多数平台上进行硬件加速的优势，这使得它通常比画布API具有更高的性能。

与OpenGL类似，WebGL程序由用于安排操作的JavaScript代码和以OpenGL ES着色语言(GLSL ES)编写的着色器组成，这些代码和着色器直接在用户的GPU上执行。WebGL后端比画布实现方式复杂得多。然而，WebGL提供的优于画布替代方案的许多优势使其成为某些情况下更好的选择。如前所述，WebGL比画布API性能更高并且内存效率更高。WebGL支持开箱即用的子像素渲染，而画布实现方式的支持因浏览器而异。由于浮点精度问题，这可能会在合成彼此相邻的图块时导致可见的图块接缝，并且可能需要渲染器部分的更多逻辑来处理这些特殊情况。WebGL API几乎1：1映射到OpenGL API，这意味着可以在本机上下文与浏览器上下文之间共享实现方式。此外，着色器提供了非常高效的方式来向图像添加后处理和高级合成，这是图像查看器的基本功能。

为了支持最大的浏览器版本区域，网络开发世界中的常见模式可能会默认使用WebGL实现方式，并且如果当前浏览器不支持WebGL，则回退到画布实现方式。但是，这可能涉及仅使用画布支持的WebGL特征的子集，如果程序具有复杂的着色器代码，这可能不起作用。

WebGL2.0是基于OpenGL ES 3.0标准的新规范。但是，并非所有主要浏览器都支持它，其中Safari是明显的障碍。

WebGPU是即将推出的API，它向网络应用程序公开甚至更低级别的图形功能。它部分基于Vulkan规范，目标是也有效地映射到Direct3D(Windows)和Metal API。

虽然WebGPU如今在大多数浏览器上都不是开箱即用的，但仍然可以在最新浏览器的实验设置中启用。WebGPU代表图形编程领域的有前景的发展：统一API的前景，它可以针对任何图形后端，从而在不同平台上无缝工作。

本公开包括使用wgpu5 Rust crate来实现WebGPU后端的实施方案。目前，此后端仅支持查看器的本机版本。通过一种实现方式，本机查看器可能够在Linux、Windows和macOS上运行，并有望在浏览器中针对OpenGL、WebGL和未来的WebGPU实现方式。

由于它针对甚至更低级别的API，因此所公开的WebGPU实现方式比画布或WebGL实现方式更复杂。但是，WebGPU API设计良好，并且wgpu crate提供的抽象可能使其相对容易使用。在未来几年，随着更好的工具和支持变得可用，WebGPU开发可能会变得更加容易。

优化技术

在切片查看器的示例性实施方案中，性能可能是关键组成部分并用于指导技术选择。然而，由于产品限制，已经做出这些选择中的一些选择。也许其中最重要的是查看器可能是网络应用程序。

如果查看器是网络应用程序，则可用于查看器的技术数量可能会受到限制。然而，部分由于WebAssembly、WebGL和潜在的WebGPU，仍然可以编写非常高性能的图形网络应用程序。尽管如此，这些应用程序的某些部分仍然必须通过网络进行通信，因此受到浏览器网络堆栈和客户端互联网连接的限制。网络应用程序可能会因需要适应分配的浏览器内存而受到进一步限制，可能只能访问Web API。

高速缓存启发法

浏览器，以及更广泛意义上的用户计算机可具有有限量的可用内存。因此，可能无法将所有将作为用户会话的一部分加载的图像保存在内存中，因为这类似于将整个切片图像存储在用户的装置上。这些图像可经过千兆字节的编码，以及数十千兆字节的解码。因此，如上所述，可能有必要实现高速缓存修剪、或高速缓存排序、启发法，以便将高速缓存的占用保持在可管理的大小。

对高速缓存进行修剪或排序可以指确定当前存储在高速缓存中的每个图块的优先级并且在必要时修剪高速缓存的操作。当高速缓存超过最大占用时，可以触发高速缓存的排序。例如，查看器可以确定当高速缓存完全满时达到最大容量。或者，查看器可以确定最大占用率是高速缓存的特定容量级别。当高速缓存处于和/或超过最大占用率时，可以检查高速缓存的内容以确定哪些图块具有最低优先级。可以从高速缓存中移除具有最低优先级的图块，直到高速缓存达到或低于最大占用率。

在一个实施方案中，高速缓存中图块优先级的顺序可以包括：

a.在放大级别下处于FOV内的图块，可以等于或大于FOV的放大倍数；

b.在放大级别下与FOV接壤的图块，可以等于或大于FOV的放大倍数;

c.在更高放大级别下处于FOV内的图块；

d.在更低放大级别下处于FOV内的图块；以及

e.所有其他图块。

在另一个实施方案中，在每个高速缓存周期期间，图块可以被分类为三个类别：

a.当前直接需要显示的图块。回过头来看图2，这些是标记为“活动”的图块11。这些活动图块11也可以在图11中看到。

b.如图10A所示，当首次加载切片图像时，它可以完整地显示。在这种第一次显示期间，可以以低放大级别加载一组图块。当加载正确放大级别下的图块并且可能需要显示一些东西来代替这些图块时，这些图块可用于插值目。图10B展示此类示例，其中当加载高放大图块时，低放大图块进行插值以代替高放大图块显示。

c.其他图块按重要性降序分为四个子类别：

i.直接与FOV接壤的图块；

ii位于FOV内但放大级别更高的图块；

iii.位于FOV内但放大级别更低的图块；

iv.所有其他图块。

属于类别1和2的图块可能始终保存在内存中，因为它们要么立即需要，要么最终可能始终需要用于插值目的。属于类别3的图块只能保留直到最大占用率，之后被认为是低优先级的图块开始进行修剪。

此外，这些启发法不仅仅适用于解码图像。事实上，图像请求将遵循相同的启发法，增加的限制是来自类别3的请求不能与来自类别1和2的请求同时运行。当对高优先级图块的请求传入时，将取消对低优先级图块的待决请求。这样确保对必要图块的请求可能始终被优先考虑。

图块预加载

图2示出了查看器可以加载的以便渲染特定FOV 12的活动图块11。然而，示例性实施方案可以开始加载查看器预测用户接下来可能访问的图块。

图11展示这种行为的实际示例。由于切片查看器可能期望用户在某个点平移FOV12，因此查看器可能会增加它的大小以形成“预加载区域”，例如预加载区域112。预加载区域112中的图块111可以在后台加载，使得它们可以在用户需要它们时变得立即可用。

如上所述，这些图块111可以被认为是子类别(c)(i)的一部分。因此，请求这些图块111可能不会减慢其他图块请求，并且可能不会以修剪其他更重要的图块为代价。

尽管在用户体验方面有潜在的好处，但这种方法也可能有缺点。一个缺点可能是抢先加载图像的较大区域，这意味着向图块服务器发出更多请求，并且这些请求中的一些请求将被浪费。因此，具有预加载图块的数据传输成本高于没有预加载图块的数据传输成本。另一个缺点是预加载太大的区域可能会给用户和服务器带来压力。实际上，这可能会导致前端卡顿，并增加后端时延。但是，这可以通过在服务器端使用内容分发网络(CDN)并在客户端进行适当的请求调度来缓解。

并行图块加载和解码

在现代浏览器中，虽然资源加载在后台异步发生，但图像解码可能在主线程中发生。因此，解码大量图像可能导致时延增加、渲染循环延迟，从而导致FPS下降。图12示出以顺序方式请求、加载和解码图块的示例性时间线，其中顺序请求121、122和123在上半部分120中，并且顺序请求126、127和128在下半部分125中。如果图像解码只发生在主线程中，它可能是纯顺序的，并且可能需要等待解码完成才能执行渲染循环。

在图12的上半部分120中，顺序请求121、122和123可以在主线程或另一线程内。顺序请求121、122和123可以顺序解码并存储，或者可以作为主线程的一部分以另一顺序解码并顺序存储。顺序请求121、122和123的并行加载可能涉及不同的时间量，但可以以顺序开始。

这类似于图12的下半部分125，其中顺序请求126、127和128可以存在于主线程中或其他线程内。顺序请求126、127和128之间的间隔可以在主线程内变化。在其他线程内，顺序请求的并行加载和解码时间也可能不同，并且可能在线程的同一步骤内完成。下面提供有关顺序请求的其他详细信息。

WebWorker最近添加到网络API家族。WebWorker可以利用现代处理器的多线程功能与主线程并行执行JavaScript和Wasm代码。JavaScript本质上是单线程的，这意味着它可能只在单个线程上运行。为了允许在JavaScript中进行并行计算，可能需要使用多处理和消息传递。这是WebWorker的基本概念：它可以在独立的JavaScript上下文中运行，并且可以通过通道向主线程来回传递数据。

使用WebWorker，可以在主线程之外解码图像。将工作卸载到不同的线程可以确保主线程自由地执行其更重要的职责，包括事件处理和渲染。图12示出通过将解码延迟到不同的线程，实现更高频率的更快渲染。

由于最近添加OffscreenCanvas API，因此此技术也可用于渲染。但是，渲染目前可能不是查看器的瓶颈，因此未进行实现。

最后，必须指出的是，虽然JavaScript不能有线程，但由于SharedArrayBufferAPI，将来仍然可以直接共享内存。此外，Wasm规范支持线程模型，并且Wasm线程可能已经在Chrome和Firefox中可用。

示例实施方案

一个示例实施方案可以包括用户调整FOV，使得FOV覆盖4个图块，这些图块由它们在网格中的坐标，例如(4，4)、(5，4)、(4，5)、(5，5)索引化。查看器然后可以加载图块(4，4)、(5，4)、(4，5)、(5，5)，它们可能都位于FOV内。图块(4，4)和(5，4)可能已在完全加载状态下由高速缓存存储。图块(4，5)和(5，5)可能未存储在高速缓存中，这可能使得此类图块在图块请求状态下存储。图块请求状态可以存储在查看器或图块服务器中。例如，查看器可以向图块服务器发送图块请求以加载图块(4，5)和(5，5)。图块请求可以包括图块标识符，例如特定的FOV坐标或不同的唯一标识符。图块服务器可以将数据传输给查看器。此类数据可以包括完整的图块信息以使图块进行完全加载。查看器可以将图块(4，5)和(5，5)移动到完全加载状态。现在所有图块都处于完全加载状态，查看器可以继续加载边界图块(3，4)、(4，3)等，其中先前描述的方法可以对边界图块和后续图块组重复。此外，用户可以再次调整FOV，并且查看器可以从高速缓存中为新的FOV加载图块。

高速缓存可能处于先前方法的最大占用率。例如，从所述方法加载的所有图块可能已将高速缓存填充到最大占用率。使用新的(或当前的)FOV，高速缓存可以对存储的图块进行排序并移除低优先级的图块，直到高速缓存不再处于最大容量。这样的排序过程也可能发生在进程中的任何时刻。

此外，查看器可以在上述进程中的任何时间点渲染图块。查看器可以将完全加载状态下的图块渲染给显示器或存储装置。这可能是渲染循环，其中渲染循环的执行可能独立于后台循环方法。

工作安排

如上所述，只要当前进程有空闲时间，就可能需要执行后台循环。在网络查看器上，后台循环可能被安排为就在渲染循环之前运行。虽然这是可行的，但它可能不是最佳的，因为如果后台循环花费的时间太长，它可能会导致渲染循环错过一帧。

工作安排的一个早期示例是实验性requestIdleCallback API。使用此API，只要浏览器有空闲时间，就可以调用后台循环。此外，由于它执行多个小的工作单元，因此后台循环本质上是可暂停的。如果达到超时，它的执行可以暂时暂停，然后在下一帧恢复。因此，在不久的将来，它的模型可能够利用安排API的新浏览器。

性能度量

仪器框架的跟踪器组件负责计时从对图块进行第一请求的时刻到从服务器加载图块的时刻到图块最终在屏幕上渲染的时刻之间的持续时间。这些事件在图9中示出。由于加载和渲染可能发生在查看器的不同组件中，因此跟踪器广泛应用于整个应用程序。跟踪器可以通过包装它需要测量的不同组件来实现这一点，这些组件都揭示通用API。因此，为了禁用跟踪器，用户可能只需要删除这些包装器。

仪器框架收集的重要度量是FOV完成时间。FOV完成时间可以测量用户交互使得FOV变化的时刻与新FOV在屏幕上完全渲染的时刻之间经过的时间。

某些交互可能会使得FOV立即完成，因为显示FOV所需的图块可能已经在高速缓存中。因此，当针对至少一帧向用户呈现不完整的FOV时，框架可仅考虑FOV完成事件。不完整的FOV是尚未加载图块纹理的视场，并且可由高速缓存中较低放大率图块的插值版本替换。

FOV完成时间也称为周转时间。美国食品和药物管理局(FDA)对不同用户交互的查看器应用程序的周转时间有具体的指南。示例性实施方案仅使用了FDA周转时间线指南的一小部分。

虽然FOV完成时间是纯粹的定量度量，但更定性的用户体验度量是测量用户会话中FOV完成的平均百分比。此度量的目的是量化用户在不完整FOV上花费的时间量，以及任何时候屏幕上显示的部分信息量。

对于屏幕上渲染的每一帧，跟踪器可以查看图块绘制调用以查看哪些绘制调用引用了比当前FOV放大级别低的放大级别下的纹理。由于完整的FOV可能只显示放大级别等于或高于其自身的纹理，因此包含较低放大级别纹理的帧必然是不完整的。可以测量这些绘制调用覆盖的面积并除以FOV的面积，从而指示FOV的未完成(以及相反，完成)的百分比。算法可能稍微复杂一些，因为放大级别较高的纹理有可能覆盖在放大级别较低的纹理上：虽然渲染图块所需的确切纹理可能尚不可用，但高速缓存中可能有放大级别较高的子图块和放大级别较低的超级图块。

最后，最简单的测量度量是加载和渲染单个图块所需的时间。此度量可能主要指示图块服务器的性能，但也可能揭示图块加载和渲染管线的问题。

例如，使用HTTP/1.1协议，大多数浏览器会限制可以并行向特定主机发出的请求数目。在Chrome中，此数目可为6。即使有快速的图块服务器，这样的限制也可能在并行加载超过6个图块时人为地增加图块加载时间，因为后续请求将被浏览器排队。在本文描述的示例性实施方案中，图块服务器专门使用HTTP/2.0协议，所述协议可能不受这些限制。

记录和重放用户会话

收集足够的数据来编译有意义的比较基准始终是一个挑战。因此，需要一种快速有效地生成实际使用数据的方法。

将一种解决方案与另一种解决方案进行比较的一种方法可能是在启用跟踪的情况下手动重放正常用户会话的步骤，以查看在查看样本后哪个解决方案似乎具有最佳性能。这种方法可能有几个缺点，包括用户花费额外的时间，因为它是完全手动的。此外，所述方法可能不科学，可能无法收集足够的样本来显示任何显著差异。

为了避免这些缺点，可以使用会话记录器和播放器。用户交互可能在它们发生的那一刻被记录下来，因此可在以后以相同的速度重放所述用户交互。原始用户会话与重放会话之间的一个主要区别可能是会话播放器一旦注意到FOV已完全解析，就不会在用户交互之间再等待。这可能意味着重放会话通常可能比原始会话更快。这也可能意味着它们将对查看器造成更大的负担，因为事件平均会以更快的速度发生。因此，它并不代表完全现实的使用场景，但在最坏的情况下，它代表对系统施加更多压力。

基准

以下基准在具有以下规格的计算机上捕获：

型号：MacBook Pro，13英寸，2019年

CPU 2.8GHz四核英特尔酷睿i7

显卡Intel Iris Plus Graphics 655(集成)

显存1536MB

内存16GB 2133MHz LPDDR3

互联网带宽300Mbps

在服务器端，实例在m5a.4xlarge类型的AWS EC2实例上运行，具有以下规格：

CPU 2.5GHz AMD EPYC 7571，16个线程

内存64GB

这些基准在来自不同组织的一组10个SVS切片上捕获。所有切片均以40倍放大倍率扫描。下表详细说明了组织类型、切片大小和分辨率。

为了对示例性查看器/图块服务器组合进行基准测试，过程分为两部分。首先，记录一系列用户操作，将其保存为用户会话以供以后回放。然后，一旦为数据集中的所有切片生成用户会话，重放用户会话。

记录用户会话的过程可能包括以下步骤：

a.单击切片托盘上的切片以将其打开并开始记录。

b.使用一系列缩放和平移导航切片3分钟。

c.保存用户会话。

d.对下一切片重复所述过程。

生成基准的进程可包括以下步骤：

a.清除所有以前生成的图块。

b.将查看器配置为所需的设置以进行基准测试。

c.选择要重放的用户会话。

d.查看器可以自动重放所选会话多次并将结果保存到磁盘。

FOV完成

缩放动作平均完成速度可能比平移动作慢，因为它们可能导致FOV完全失效：由于查看器正在从一个放大级别转换到另一个放大级别，因此它无法重复使用之前显示的图块。这与平移动作形成对比，平移动作可能仍然能够在新FOV的外围重复使用这些图块中的一些图块。

即使以下配置可能遵循完全相同的一系列动作，但它们之间收集的样本数目可能有很大差异。最终，样本数目表示导致为用户呈现不完整FOV的动作的数目。因此，较少数目的样本可以表示较小百分比的动作是这样做的。对于如上所述的图块预加载配置，这种效果可能特别明显，并且可以通过多种方式进行解释。当FOV完成时间非常快时，完成事件可能在用户平移或缩放时发生多次。当它们变慢时，它们可能只在用户完成这些动作后才会发生。需要显示较少不完整FOV的配置可能反过来具有较少的FOV完成事件样本。

如图13A所示，示例性查看器可以被配置为从不使用图块高速缓存，而是始终按需生成图块。这可能是动态图块化基准的情况。

图13B中示出为静态图块化基准配置的示例性查看器。对于静态图块化基准，查看器所需的所有图块都是提前生成的，并通过图块服务器从S3流式传输。以下所有基准也将使用静态图块化，因为静态图块化可能被认为是向前移动的最现实的方法。

预加载基准将图块预加载添加到混合中，具有四种不同的预加载偏移配置。预加载偏移可以表示为配置的图块大小的因子。例如，如果图块大小为512×512且预加载偏移被配置为0.5，则以像素为单位的实际预加载偏移可为512×0.5＝256个像素。

配置预加载偏移

预加载，10.5

预加载，21.0

预加载，31.5

预加载，42.0

图14示出预加载偏移的值可能直接影响FOV完成时延。此外，预加载偏移可能使更大的预加载偏移必然涉及更快的完成时间的这一直觉无效。这可以用多种方式来解释。更大的预加载偏移可能最终需要加载更多的图块。要加载的图块数目可能会随着预加载偏移的增加而呈二次方增长，这可能产生大量的性能问题。此外，同时加载大量图块可能对图块服务器造成压力并增加请求的时延。在示例性实施方案中，所有预加载图块可具有相同的优先级。这可能意味着对于更大的预加载偏移值，离FOV较远因此不太可能需要的一些图块可能在较近的图块之前解析。最后，基准测试中的动作可以非常快速地连续运行，而无需在FOV完成事件之间等待。这是图块预加载的病态情况，图块预加载可能期望用户在动作之间等待至少半秒。在此期间，大多数(如果不是全部)预加载图块都应正确加载。

慢速互联网连接基准可能人为地将互联网带宽限制为10Mbps以模拟较慢的连接。

图15A是已知切片查看器与使用动态图块化的示例性实施方案的性能比较。结果可以表明示例性实施方案在加载FOV方面几乎总是(如果不是总是)比已知的切片查看器更快。

图15B是使用动态图块化的实施方案与使用静态图块化的实施方案的性能比较。在需要使显示完全无效的事件中(例如，初始加载和缩放)，差异可能很明显。另一方面，需要使显示部分无效的事件(平移)可能几乎没有明显差异。这可能是因为这些事件对服务器造成的压力不同：与部分无效相比，完全使显示无效可能需要并行加载更多图块，进而可能导致时延尖峰。

当前的静态图块化实现方式可能并不完美，因为它可能需要图块服务器充当后备存储(AWS S3)与客户端(浏览器)之间的代理。这可能给所有请求增加一些时延。消除这种时延的方法可包括直接从后备存储提供图块；和/或通过AWS内容交付网络(CDN)、CloudFront提供图块。CDN可以针对提供静态内容进行优化，并且可以通过将对应数据物理移动到更靠近客户端的服务器来大大改善频繁查询的内容的时延。

这些方法可能需要将身份验证逻辑部分地从图块服务器(在这一点上，它更像是身份验证提供程序)移动到客户端最终将与之通信的服务(例如，S3或CloudFront)。

图15C是禁用和启用预加载且预加载偏移为1的示例性实施方案的性能比较，其中来自上述解释的基准已显示在时延与加载的图块数目之间取得折衷。在此配置中，预加载偏移为1意味着在FOV周围添加512x512的预加载边界。

正如预期的那样，由于当前的预加载实现方式可能仅对相同放大级别的边界图块进行操作，因此缩放动作的性能几乎没有变化。然而，可以看出预加载大大加快了平移操作。初始加载的时延差异可能仅用这些事件的少量样本来解释。

最后，为了进一步说明示例性实施方案可能比已知的切片查看器快得多，图15E示出了在300Mbps连接上运行的已知切片查看器与在10Mbps连接上运行的示例性实施方案之间的比较。示例性实施方案在初始加载和平移动作上都更快，但在缩放动作上与已知的切片查看器一样快。如前所述，这些动作可能需要加载更多的图块，这会使有限的带宽饱和。

加载图块所花费的时间是查看器感知性能的重要因素。如图15F所示，示例性实施方案图块服务器实现方式可能够比已知图块服务器更快地提供图块，这可以为用户带来更短的加载时间。按需生成图块的动态图块服务器与已预先生成所有图块的静态图块服务器之间的区别并不那么明显。

在决定采用哪种配置时，出现的主要折衷是用户体验质量与维护成本之间的折衷。

虽然用户体验的质量可能取决于更多的定量度量，例如平均图块加载时间，但这些度量并不能说明全部情况。为了获得更具代表性的度量，示例性实施方案可以使用在用户会话期间向用户呈现不完整FOV的时间百分比。此度量是平均FOV完成率，且在上文中进一步描述。另一方面，对于查看器而言，维护成本的主要因素是会话期间加载的平均图块数目。加载图块在处理能力和数据出口方面都有成本。

下表是针对不同测试配置的这两个度量的细分。

直觉认为预加载偏移设置越高，最终加载的图块就越多。但不一定是这种情况，因为查看器可以在证明不再需要图块请求时自动取消待决的图块请求。这可能是切片查看器的示例性实施方案中的图块请求值和图块引导值不同的原因。在预加载图块时，这种效果可能特别明显。

类似地，由于播放的用户会话是相同的，并且除了绝对必要之外没有加载图块，所以可以预期图块请求值在示例性实施方案的动态、静态和10Mbps配置之间是相等的。但是，由于浏览器调度API可能不是完全确定的，因此同一会话的不同运行之间会发生细微变化。负责进行图块请求的后台循环可能在不同时间运行，并捕获不同FOV。这种影响很小，可以忽略不计。考虑到这些要点，示例性实施方案可以提供更流畅的用户体验，即使在看似相当的数据出口成本下也是如此。

流媒体查看器

代替让用户直接渲染切片查看器，在流媒体查看器中将责任转移到服务，所述服务发回视频流供用户显示。实现方式可广泛使用流媒体库，例如GStreamer及其WebRTC支持，以便以最小的时延(<100ms)为用户启用实时视频编码和流式传输。这可能部分归功于对例如VP8和VP9的新视频编解码器的支持。

图16中示出流媒体切片查看器的示例性实施方案的架构。表示为“块组”的不同片段指的是流媒体库组件。

在示例性实施方案中，用户的浏览器可以通过WebRTC接收视频馈送，并且发送回对应于用户与查看器163的交互的事件，以便服务器相应地更新FOV。

WebRTCBin161可以通过WebRTC向网络播放器162发送数据包。网络播放器162又可以通过WebSocket将事件发送到查看器163。查看器163可以从WebGPU渲染器164绘制调用。帧可以从WebGPU渲染器164发送到视频块组165，所述FFGI可以包括源166、编码器167和有效载荷器168。

基于GStreamer的插件生态系统以及GStreamer与Rust的集成质量，示例性实施方案可能很容易实现。在本机和浏览器中运行相同的代码可确保查看器的行为在其所有渲染后端之间保持相同。

应当理解，在本发明的示例性实施例的上述描述中，本发明的各种特征有时分组在单个实施方案、附图或其描述中，目的是简化本公开和帮助理解一个或多个不同的创造性方面。然而，本公开的这种方法不应解释为反映了以下意图：所要求保护的发明要求比每项权利要求中明确叙述的特征更多的特征。相反，如随附权利要求书所反映，发明方面在于比单个前述公开实施方案的所有特征更少的特征。由此，具体实施方式之后的权利要求在此明确地并入此具体实施方式中，其中各权利要求代表其本身作为本发明的独立的实施方案。

此外，尽管本文所述的一些实施方案包括一些但在其他实施方案中没有包括的其他特征，但不同实施方案的特征组合意欲涵盖在本发明的范围之内，并且形成本领域的技术人员应理解的不同的实施方案。例如，在所附权利要求中，所要求保护的实施方案中的任何一个都可以以任何组合使用。

因此，虽然已经描述了某些实施方案，但是本领域技术人员将认识到在不脱离本发明的精神的情况下可以对其进行其他和进一步的修改，并且旨在要求保护落入本发明范围内的所有此类改变和修改。例如，可以在框图中添加或删除功能，并且可以在功能块之间互换操作。在本发明的范围内，可以向描述的方法添加或删除步骤。

上面公开的主题应被认为是说明性的而不是限制性的，并且随附的权利要求旨在覆盖所有此类更改、增强以及落入本公开的真实精神和范围内的其他实现方式。因此，在法律所允许的最大范围内，本公开的范围由随附权利要求及其等效要求的最广义许可的解释来确定，并且不应受前面的具体实施方式约束或限制。虽然已经描述了本公开的各种实现方式，但是对于本领域普通技术人员来说显而易见的是，在本公开的范围内可以做出很多实现方式。因此，除根据所附权利要求及其等同物之外，本公开不受限制。