このベンチマークは実際に何を証明するのか
特定のスキャナーで作られた特定のファイルが、実際のサイズのまま、出荷版のビルドで開き、画面にピクセルを表示できること。それ以上でもそれ以下でもありません。対応形式の一覧は能力を主張するものですが、これはそれを実測します。ベンダー固有の構造によってデコーダーが読み込めなかった場合、そのファイルは行ごと省かれるのではなく、ユーザーが目にするエラー文とともに失敗の表に掲載されます。
これはベンダー自身によるテストです — ソフトウェアを書いたのも、テストを実行したのも私たちです。それでも読む価値があるのは、ご自身で検証できるからです。コーパスは公開されており、実行プログラムは私たちのデスクトップ版リポジトリにあり、ファイルごとの生の結果もこのページにあります。
ファイルのテスト方法
各ファイルは使い捨ての子プロセスに渡されます。そのプロセスはアプリケーションと同じローダーを構築し、画像の次元を読み取り、1 平面をデコードし、ビューアと同じ Qt のレンダリング経路で変換します。不正な形式のファイルがネイティブコーデックを異常終了させても、終了するのはその子プロセスだけです。監視プロセスは処理中だったファイルを記録して処理を続けます。この設計のおかげで、数ギガバイトのベンダースキャンを対象とするベンチマークを最後まで完了でき、この表は「クラッシュ」という分類を正直にゼロと報告できるのです。
- 実行プログラム:
slidescope-desktop/scripts/publish_format_benchmark.py — SlideScope デスクトップ版リポジトリにある 1 つのコマンドで、3 つのパスをすべて実行し、このページが表示する 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 の装置から届き、日常的に数ギガバイトに達するファイルです。
顕微鏡と医用画像の形式
多次元の取得形式です。ここで興味深いのはファイルサイズではなく、画面に表示されるまでにチャンネル、Z 平面、時点がどれだけ保たれるかです。
開かなかったすべてのファイルとその理由
792 個のうち 25 個のファイルが開きませんでしたが、その内訳は 1 つではなく 2 つです。9 個は本当の限界で、現時点で読み込めない正真正銘の画像です。残りの 16 個は、そもそも画像を含まないファイルであり、拒否するのが正しい答えです。両者をひとまとめにすれば私たちを実際より良く見せてしまいます — 今回の実行における正直な失敗件数は、25 件ではなく 9 件です。
本当の限界:読み込めない 9 個のファイル
これらはどれも破損のない状態で — チェックサムは公開元と一致しています — 損傷したサンプルではなく、デコーダーとベンダー固有の構造による限界です。回帰テスト用としてコーパスに恒久的に残しており、そのおかげで、いずれかが開けるようになった日にそれを知ることができます。
問題はモダリティではなく、ベンダー固有の構造にあります。蛍光の NDPI も蛍光の MIRAX も通常どおり開きます。バックエンドが拒否するのは特定の構造上のバリエーション — メイン画像を特定できない SCN、想定外の direction 属性を持つ BIF、HDF5 以前の "Imaris Classic" コンテナー — です。各メッセージはファイルが壊れているとは言わず、原因を具体的に示します。これらのケースではいずれも、問題があるのはファイルではなく私たちの側だからです。
失敗ではないもの:画像を含まない 16 個のオブジェクト
DICOM は画像形式であると同時に、文書形式でもあります。DICOMDIR はディスクのインデックスであり、プレゼンテーションステートは誰かがかつて検査をどのようにウィンドウ調整したかを記録したもので、その他のオブジェクトはレポートや計測値を保持します。いずれもピクセルを含みません。それらを開いたとしても、ビューアには表示するものがありません。そのため 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 の 7 色リファレンスファイル — は、エラーをまったく出さずに開きました。このファイルには、34,560 × 24,960 のフル解像度の単一チャンネル蛍光ページが 5 つ(DAPI、FITC、CY3、Texas Red、CY5)、全 33 ページにわたって含まれており、これは tifffile で独立に確認しています。SlideScope はすべての .qptiff を明視野用リーダーである OpenSlide バックエンドに振り分けていたため、1 チャンネルと報告し、RGB のスライスを返していました。蛍光チャンネルにはアクセスできず、チャンネルの操作には何も表示されませんでした。
何の警告も出ませんでした。同じコーパスにある明視野の H&E QPTIFF スキャンは完璧に開くため、まさにそれが理由でこの問題は見過ごされていました。
SlideScope 1.8.48(2026 年 9 月 18 日)で修正しました:バックエンドは拡張子ごとではなく、ファイルごとに選ばれるようになりました。マルチプレックスのスキャンは 5 つのチャンネルすべてを返すリーダーに渡され、明視野の QPTIFF は引き続き OpenSlide とそのフル解像度のタイル表示を使います。トレードオフも隠さずに明示しています:マルチプレックスの QPTIFF は低い解像度で表示され、ファイルの詳細パネルにもその旨が表示されます。このページの実行結果にはすでに修正が反映されており、QPTIFF の行には両方のローダーと 5 つのチャンネルが記載されています。
開けることはこの実行で証明されます。ピクセルの正しさは別の問題であり、別途テストしています。2 回目のスイープでは、同じ平面を基盤のライブラリでデコードし、ローダーが返す内容と比較します。QPTIFF のケースはこの方法で見つかりました。
SlideScope が開くのを拒否するもの
汎用のフォールバックリーダーはありません。ビューアが想定外のファイルをどう扱うかは、想定内のファイルをどう扱うかと同じくらい重要です。リファレンスコーパスから、非対応の拡張子それぞれについて最小の実ファイルを取り出し(計 93 個)、1 つずつ出荷版のローダーファクトリーにかけました。
93 個中 93 個が明確なメッセージとともに拒否されました。クラッシュは 1 つもありません。画像のように見えて実は画像ではない、中途半端に開いた状態になったものも 1 つもありません。一覧には、ユーザーが試しそうな形式 — .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 では、この実行でテストしていない 5 つの形式も開けるようになりました:Philips の .isyntax、KFBio の .kfb、ICS/IDS、Gatan の .dm3 と .dm4、Olympus の .sis です。最新の一覧はファイル互換性リファレンスをご覧ください。
このベンチマークからわからないこと
- 2 つの形式については、実ファイルによるテストがまったくありません。
.vmu と .svslide の公開サンプルは存在せず — OpenSlide もどちらも公開していません — これらのローダーは合成したエッジケースでしか検証されていません。テスト済みの対応とはうたっていません。
- 速度のベンチマークではありません。最初のピクセルが表示されるまでの時間はディスクに左右され、今回の実行はローカルで行いました。
- 上記のピクセル比較スイープを超える精度監査ではなく、臨床的なバリデーションでもありません。SlideScope は研究、教育、レビュー向けであり、診断用ではありません。
- ある時点のスナップショットです。2026-09-18 時点の最新リリースを対象としています。デコーダーの更新により、これらの数値はどちらの方向にも変動します。
このベンチマークに関する質問
SlideScope は実際にどの顕微鏡形式と全スライド形式を開けますか?
18 のファイル拡張子です:.svs、.ndpi、.mrxs、.scn、.bif、.vms、.vmu、.svslide、.qptiff、.avs、.czi、.nd2、.lif、.ims、.dcm、.dicom、.tif、.tiff。汎用のフォールバックリーダーはなく、一覧にないものは不完全に開くのではなく、わかりやすいメッセージとともに拒否されます。
このベンチマークは独立したものですか?
いいえ。SlideScope が SlideScope について公開しているものなので、第三者による監査ではなく、ベンダー自身によるテストとして扱ってください。独立性の代わりに私たちが提供できるのは検証可能性です。コーパスは公開されており、実行プログラムは公開しているスクリプトディレクトリにあり、生の結果ファイルはこのページからリンクしており、失敗は成功と同じ詳しさで記載しています。
一部のファイルが失敗するのはなぜですか?
ほとんどの場合、基盤となるオープンソースのバックエンドが読み込めない構造をベンダーが書き出しているためです — たとえば、蛍光の SCN で OpenSlide が "Can't find main image" と報告するケースです。これらは上流の限界であり、私たちは隠さずに明示しています。失敗したファイルは破損のない状態で、チェックサムは公開元のものと一致しています。
ファイルが開けば画像は正しいということですか?
それだけでは言えません。だからこそ両方をテストしています。開けることはこの実行で証明され、ピクセルの正しさは sweep_format_reference.py で別途証明されます。これは同じ平面を基盤のライブラリでデコードし、SlideScope がレンダリングする内容と比較するものです。既知のケースが 1 件あり — マルチプレックスの Akoya QPTIFF — エラーなく開いたにもかかわらず、SlideScope 1.8.48 で修正されるまで誤った内容を表示していました。このページに記載しています。
この結果を再現できますか?
はい。Open Microscopy Environment のリファレンスコーパスは一般公開されたダウンロードで、ベンダーサンプルは OpenSlide と各形式ライブラリ自身のテストデータから取得しており、実行プログラムは SlideScope デスクトップ版リポジトリに含まれています。このページのすべての表の元になっている生の JSON は、上にリンクしています。
SlideScope は臨床診断用として承認されていますか?
いいえ。SlideScope は研究、教育、レビュー向けです。診断機器ではなく、一次診断に使用してはなりません。
意味があるのは、あなた自身のテストだけです
私たちのコーパスは、あなたのスライド棚ではありません。SlideScope をインストールし、実際に困っているファイルを開いてみてください。そのうちの 1 つでも失敗したら、私たちに送ってください — このページに掲載されている失敗は、誰かがそうしてくれたからここにあるのです。
SlideScope をダウンロード