我们打开了 792 个真实切片文件，并公布了每一项结果

这项基准测试究竟证明了什么？

它证明的是：一个有名有姓的文件，来自一台有名有姓的扫描仪，以其真实大小，能在正式发布的版本中打开并在屏幕上显示像素。不多也不少。格式支持列表声称具备某种能力；而这项测试是在度量这种能力。如果某种厂商布局让解码器失败，该文件会连同用户将看到的错误信息一起出现在失败表中，而不是被悄悄略去。

这是一项厂商自测——软件是我们写的，测试也是我们做的。它之所以仍然值得一读，是因为您可以核查：语料库是公开的，运行脚本在我们的桌面端代码仓库中，而且逐文件原始结果就在本页。

文件是如何测试的

每个文件都交给一个可牺牲的子进程处理，该子进程构建与应用程序相同的加载器，读取图像尺寸，解码一个平面，并通过查看器所用的同一 Qt 渲染路径进行转换。如果一个格式错误的文件导致原生编解码器中止，被终止的只是那个子进程；监控进程会记录当时正在处理的文件并继续运行。正是这种设计，才让一项涉及数 GB 厂商扫描的基准测试得以完成，也让“崩溃”这一类别能如实报告为零。

• 运行脚本：slidescope-desktop/scripts/publish_format_benchmark.py——SlideScope 桌面端代码仓库中的一条命令，运行全部三轮测试，并写出本页所渲染的那份 JSON：python scripts/publish_format_benchmark.py --dataset <corpus> --output format-benchmark.json
• 语料库：Open Microscopy Environment 公开参考语料库、OpenSlide 公布的测试切片、czitools 和 nd2 库的测试数据，以及我们已对照发布方核验过 sha256 的厂商样本。
• 范围：全切片和厂商显微镜格式。来自厂商批量导出的零散单平面 TIFF 不在此列——它们能说明的问题，金字塔式 WSI TIFF 都能说明得更好。
• 每个文件记录的内容：检测到的格式、加载器、解码后的 T/Z/C/Y/X 维度、像素类型、渲染尺寸，以及失败时的异常类型和面向用户的提示信息。

全切片图像格式

这些是扫描仪格式——来自 Aperio、Hamamatsu、3DHISTECH、Leica、Ventana、Akoya 或 Agilent 仪器的文件，通常有好几 GB。

显微镜和医学影像格式

多维采集格式，这里值得关注的不是文件大小，而是有多少通道、Z 平面和时间点能完整显示到屏幕上。

每一个未能打开的文件及原因

792 个文件中有 25 个未能打开，但它们分属两种情况，而非一种。9 个是真正的局限：确实是图像，但我们目前无法读取。另外 16 个文件本来就不含图像，拒绝打开才是正确的做法。把两者混为一谈只会美化我们的成绩——本次运行如实的失败数是 9，而不是 25。

真正的局限：9 个无法读取的文件

这些文件全部完好无损——校验和与发布方一致——因此这些是解码器和厂商布局方面的局限，而不是样本损坏。它们会作为回归测试永久保留在语料库中，这样一旦其中某个文件开始能够打开，我们就会知道。

规律在于厂商布局，而非成像模态。荧光 NDPI 和荧光 MIRAX 都能正常打开；被后端拒绝的是特定的结构变体——没有可识别主图像的 SCN、带有意外方向属性的 BIF、HDF5 之前的 "Imaris Classic" 容器。每条提示信息都会指明原因，而不是称文件已损坏，因为在所有这些情况下，文件本身没有问题，是我们做不到。

并非失败：16 个不含图像的对象

DICOM 既是图像格式，也是文档格式。DICOMDIR 是光盘的索引；呈现状态（presentation state）记录了某人当时如何为一项检查调窗；其他对象则保存报告或测量结果。它们都不含像素。查看器即使打开它们也没有东西可显示，因此 SlideScope 会拒绝打开并给出说明——这是正确的行为，我们将其单独计数，这样它就不会虚增任何一栏的数字。

完整列出名称，没有任何内容隐藏在类别之后：DICOMDIR、PS_0026、PS_0108、PS_0128、PS_0154、PS_0181、XX_0027、XX_0109、XX_0155、XX_0182、XX_0183。

SlideScope 打开了文件却显示了错误内容的情况

这是最重要的失败模式，也是格式支持表从不承认的一种，所以下面是我们的案例。

一个多重标记的 Akoya .qptiff 扫描——Vectra 七色参考文件——打开时没有任何错误。该文件包含五个全分辨率单通道荧光页面（DAPI、FITC、CY3、Texas Red、CY5），尺寸为 34,560 × 24,960，共 33 页，这一点已用 tifffile 独立确认。SlideScope 把所有 .qptiff 都交给其 OpenSlide 后端处理，而那是一个明场读取器，因此它只报告了一个通道并返回了一个 RGB 切面。荧光通道无法访问，通道控件也无可调节。

没有任何警告。同一语料库中的明场 H&E QPTIFF 扫描都能完美打开，这恰恰是问题一直未被察觉的原因。

已在 SlideScope 1.8.48（2026 年 9 月 18 日）中修复：现在按文件而不是按扩展名选择后端。多重标记扫描交给能返回全部五个通道的读取器；明场 QPTIFF 仍使用 OpenSlide 及其全分辨率分块。我们如实说明其中的取舍：多重标记 QPTIFF 以降低的分辨率显示，文件详情面板也会注明这一点。本页的运行结果已反映该修复——QPTIFF 一行列出了两个加载器和五个通道。

本次运行证明的是能够打开。像素是否正确是另一个问题，我们会单独测试：第二轮扫描会通过底层库解码相同的平面，并与加载器返回的结果进行比较。QPTIFF 的问题正是这样发现的。

SlideScope 拒绝打开的文件

SlideScope 没有通用的兜底读取器，而查看器如何处理它本不支持的文件，与它如何处理支持的文件同样重要。我们从参考语料库中为每种不支持的扩展名各取最小的真实文件——共 93 个——逐一交给正式发布的加载器工厂处理。

93 个文件全部被拒绝，并给出了清晰的提示。没有一个崩溃。没有一个被打开一半、看似图像实则不是。列表中包括人们很可能会尝试打开的格式——.jpg、.lof、.nii、.oib、.oir、.png、.psd、.raw、.vsi——在本次运行时，其中包括 .png 和 .jpg，它们被拒绝并给出提示，而不是被猜测着打开。

自本次运行以来：SlideScope 1.10.0（2026 年 10 月 16 日）新增支持 18 种格式，包括此处被拒绝的几种：Olympus .vsi、.oib 和 .oir，Leica .lof 和 .xlef，Hamamatsu .ndpis，以及 PNG、JPEG 和其他常见图像。本页的数字是 9 月 18 日运行的实测结果；1.10.0 中新增的格式不在其中。SlideScope 1.20.0 又能打开本次运行未测试的五种格式：Philips .isyntax、KFBio .kfb、ICS/IDS、Gatan .dm3 和 .dm4，以及 Olympus .sis。最新列表请参阅文件兼容性参考。

这项基准测试不能告诉您什么

• 有两种格式完全没有真实文件覆盖。目前没有公开的 .vmu 或 .svslide 样本——OpenSlide 两者都没有公布——因此这些加载器只经过合成边界用例的测试。我们不声称已对它们进行过测试支持。
• 这不是速度基准测试。首个像素出现的时间取决于您的磁盘，而这些运行都在本地进行。
• 除上文所述的像素比较扫描外，这不是准确性审计，也不是临床验证。SlideScope 用于科研、教育和审阅——不用于诊断。
• 这是一份快照。日期为 2026-09-18，针对当天的当前版本。解码器升级可能使这些数字上升，也可能下降。