我們開啟了 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、帶有非預期 direction 屬性的 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 個中有 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，針對當天的最新版本。解碼器升級可能使這些數字上升，也可能下降。