Chauveau 2025 — Converting WSI from DICOM to SVS-like TIFF

An open-source, GUI-driven converter that turns DICOM whole slide images into Aperio-SVS-like TIFF losslessly, so the platforms that still cannot read DICOM can open them.

A single-author tool paper: DICOM is the standard everyone is told to adopt, most viewers still cannot open it, and this converts DICOM to SVS-like TIFF losslessly with a GUI so that pathologists without coding skills can unblock themselves.

The problem it names

Departments digitising are urged toward DICOM for routine diagnosis. Support has not followed. The paper’s Table 1 is the useful artefact — freely available vendor viewers and whether they read DICOM:

Vendor	Free viewer	Main format	DICOM
Leica Biosystems	Aperio ImageScope	.svs	No
3DHistech	SlideViewer	.mrxs, .svs, .dcm	Yes
Hamamatsu	NDP.view2	.ndpi	No
Roche Diagnostics	None	—	—
Olympus/Evident	OlyVia	.vsi, .oir	No
Philips	None	—	—

Collaborative-diagnosis and teaching platforms are the same story — TeleSlide Cloud and Cytomine are named as lacking DICOM support. And on the compute side, RAPIDS cuCIM supports only SVS and generic tiled TIFF, so a DICOM cohort falls back to OpenSlide and loses the GPU-accelerated path.

So the standard is real and the tooling is not there yet. The paper’s judgement is that this gap is worth bridging by conversion rather than by waiting.

What it does

A Python 3.10 script plus Windows and macOS executables (PyInstaller), with a GUI. Five options: unzip inputs, keep or drop the label, keep or drop the macro/overview image, preserve extra DICOM tags, and anonymise during conversion.

The conversion is lossless in the strict sense: JPEG- or JPEG2000-encoded tiles are copied across without decompression, tile size unchanged, all pyramid levels preserved. The ICC profile is preserved if present. A thumbnail is generated if the source lacks one, because SVS requires it.

Deliberately unsupported and auto-skipped: multiplexed immunofluorescence, multiplanar brightfield (more than one Optical Path Sequence or Focal Plane), and any compression scheme other than JPEG/JPEG2000. Grayscale MONOCHROME2 images are assumed singleplex fluorescence and given a colormap, defaulting to FITC.

Validation — what was actually tested

70 DICOM WSIs, which is a real test set for a tools paper rather than a demo:

• In-house: Aperio GT450 DX (n=20), 3DHistech Pannoramic Scan II (n=15 immunostaining, n=11 singleplex fluorescence).
• External, from vendors and colleagues: Roche DP600, Hamamatsu NanoZoomer S360, Olympus/Evident VS200 and DX VS-MI, 3DHistech P1000.
• Plus OpenSlide’s public DICOM test data (n=4).

Five major vendors, which is the closest thing here to external validation and is the right design for a format tool — the failure mode being guarded against is vendor-specific DICOM dialects.

All 70 converted successfully. Converted files opened in Aperio ImageScope 12.4.6, QuPath 0.4.3 and 0.5.1 (OpenSlide and Bio-Formats backends), and TeleSlide Cloud 4.1. Deployed in the author’s institution with >100 converted WSIs, used by pathologists with no coding experience.

Performance. Mean native size 963 MB (34 MB–2.3 GB). Roughly 18 s per GB on an institutional workstation (i7-13700, 16 GB RAM, Windows 11), down to about 3 s per GB on a MacBook Pro M4. Most of the time goes to reading the DICOM input and creating the thumbnail.

File size after conversion — the one number to carry. For tiled-full WSIs (n=67, all tiles encoded) size barely moved: +2.2% mean. For tiled-sparse WSIs (n=3, only tissue-containing tiles encoded with positions as metadata) it rose +75% mean, range +5% to +260% — the worst case being a slide more than 90% background. Sparse organisation is exactly what saves space on a mostly-empty slide, and SVS cannot express it.

Why it matters here

It informs the DICOM open question on Whole Slide Imaging — “is DICOM adoption planned, or does the group stay on vendor formats?” This does not answer it, but it prices it: adopting DICOM today means either accepting that several viewers and platforms cannot open your archive, or running a conversion step. The conversion is cheap and lossless, so the honest framing is that DICOM adoption is affordable with a converter in the workflow, not that it is free.

The QuPath finding is the most immediately useful line in the paper, and it is buried in a table footnote: QuPath has no out-of-the-box ICC profile support, which the author says makes it “dedicated more to WSI analysis rather than WSI viewing.” The group runs QuPath across QuPath Annotation Workflow and its whole tooling stack, on Aperio scanners whose GT450 DX output the paper singles out as needing ICC support. Colour seen in QuPath is therefore not the colour the scanner intended. For annotation and analysis that is tolerable; for anything where a human judges colour, or for Colour Calibration work, it is a real confound.

Conversion is an anonymisation opportunity, and this tool takes it. The anonymise option renames the file, deletes label and macro images, and strips sensitive acquisition and image metadata in one pass. That is precisely the three-surface problem De-identification describes, handled at the moment the file is being rewritten anyway.

Problems and limits

Not a statistical paper, so the appraisal is different in kind — but there are real caveats.

1. Single author, single institution, no comparator. No benchmark against Orthanc, the commercial SlideMaster conversion the discussion mentions, or Clunie’s dual-personality DICOM-TIFF approach. “Successfully converted” is the only outcome measured.
2. Success is defined as “opened without error”, not as “pixel-identical”. No checksum, hash or pixel-level verification of the converted output is reported. For a conversion claimed lossless, a per-level hash comparison is the obvious check and it is absent. [unverified]
3. It converts a standard into a proprietary-lineage format. The paper is candid that this is a workaround, but the direction of travel matters: every converted archive is one more reason for the ecosystem not to implement DICOM. Useful now, and it entrenches what it works around.
4. Executables are distributed via Google Drive links in the paper text (927 MB Windows, 687 MB macOS uncompressed). For a clinical-adjacent tool that is a fragile and unverifiable distribution channel — no checksums, no versioned release, and a link that can rot or change contents silently. The GitHub repository is the durable artefact; the binaries are not.
5. The sparse-tiling penalty is under-emphasised. +260% on a mostly-background slide is the kind of number that decides whether a conversion strategy is viable at archive scale, and it rests on n=3.
6. Nothing measures whether anonymisation succeeded. The option exists and follows published recommendations; no verification of the output is reported, which is exactly the gap De-identification Release Gating is about.

What I would want before adopting it

A pixel-or-hash-level equality check on converted output; a versioned release with checksums rather than Drive links; and a measurement of whether the anonymise path actually removes what it claims, run against the released bytes rather than asserted from the code.