What this video covers
Format support lists claim capabilities; this video measures them. 792 real files in 14 format families, 44 GB in all, were each opened in an isolated process that builds the same loader the viewer uses, decodes a plane and renders it. 767 opened, 9 could not be read, 16 held no image at all, and none crashed.
The video walks through whole slide formats (SVS, NDPI, MIRAX, SCN, BIF, VMS, QPTIFF, AVS), microscopy formats (CZI, ND2, LIF, OME-TIFF) and DICOM, explains why 16 "failures" are files with no pixels in them, and names the 9 files that genuinely cannot be read. Every result, including the failures, is published on the format benchmark page.
Prefer to read? The format benchmark: every file and result.
Transcript
Updated since recording. Since this video was recorded, the multiplex QPTIFF problem it describes has been fixed: multiplex Akoya QPTIFF files now open with their fluorescence channels instead of a single RGB image. The benchmark page carries the current results.
Seven hundred and ninety two files. Fourteen format families. Forty four gigabytes.
Seven hundred and sixty seven opened. Nine could not be read.
Sixteen held no image at all. None crashed the viewer.
Every result is published, including the ones that make us look bad.
Almost every viewer publishes a list of extensions somebody typed.
That list claims a capability. It does not measure one.
It tells you nothing about whether a real file from a real scanner opens,
or what happens when it does not.
So we tested every file we have, and published the failures next to the successes.
Each file is handed to a sacrificial child process.
That process builds the same loader the application builds, reads the dimensions,
decodes a plane, and renders it through the same path the viewer uses.
A malformed file that aborts a native codec kills only that child.
That is why crashed is a column this table can honestly report as zero.
Chapter one. Whole slide formats.
The files that come off a scanner and routinely run to several gigabytes.
Chapter two. Microscopy formats.
Here the question is not file size, but how many channels, focal planes and timepoints survive.
Chapter three. DICOM, including whole slide DICOM.
Three hundred and seventy eight files tested. Three hundred and sixty two opened.
DICOM is a document format as much as an image format.
A DICOMDIR file is an index of a disc.
A presentation state records how someone once windowed a study.
Others hold reports or measurements. None of them contains pixels.
So refusing them is the correct answer, and counting them as failures would flatter us.
The honest failure count for this run is nine, not twenty five.
Nine files we genuinely cannot open.
Two Leica SCN slides. One has no identifiable main image.
The other has dissimilar main images.
One Ventana BIF with an unexpected direction attribute.
And six older Imaris Classic containers, from before the format moved to HDF5.
Every one of them is pristine. The checksums match the publisher.
These are decoder and vendor layout limits, and they stay in the corpus as regression coverage.
This is the failure that matters most, and the one format tables never admit to.
A multiplex Akoya QPTIFF opens with no error at all.
The file holds five full resolution fluorescence channels, at thirty four thousand pixels across.
DAPI, FITC, Cy3, Texas Red, and Cy5.
We route it to a brightfield reader, so it reports one channel and returns an RGB slice.
The fluorescence channels are unreachable, and nothing warns you.
Brightfield scans of the same format open perfectly, which is exactly why this went unnoticed.
Chapter four. There is no generic fallback reader.
We took the smallest real file of every unsupported extension in the reference corpus.
Ninety three of them, each put through the shipping loader.
All ninety three were refused with a clear message. None crashed.
None was half opened into something that looked like an image but was not.
Two formats have no real file coverage at all.
No public sample of either exists, so we are not claiming tested support for them.
This is not a speed benchmark, and it is not a clinical validation.
And it is a vendor test. We wrote the software and we ran the test.
What we offer instead of independence is checkability.
Our corpus is not your slide drawer.
The raw per file results are published as JSON.
The corpora are public downloads, and the runner is in our repository.
Open the files that actually give you trouble.
And if one of them fails, send it to us.
The failures in this video got here because somebody did.