IR

News

Converting Whole-Slide Images to DICOM: SVS, MRXS, NDPI and Vendor-Neutral Pathology Archives

2026.10.13 33

By Jason An, Ph.D., CEO, Medicus
Last updated: 2026-10

Converting a whole-slide image (WSI) to DICOM means re-packaging a scanner's proprietary pyramid file — such as Aperio SVS, 3DHISTECH MRXS or Hamamatsu NDPI — into standard DICOM VL Whole Slide Microscopy Image objects, so that any conformant archive, viewer or AI tool can read the pixels and metadata without the original vendor's software. Done well, it is lossless for many formats and is the practical foundation of a vendor-neutral pathology archive.

This guide is educational and does not replace your institution's validation, IT security and regulatory procedures. Clinical use of converted images should follow local quality management requirements.

Why WSI formats are fragmented

A digital pathology department rarely owns one scanner model. Over time, labs accumulate slides from different vendors, generations and research projects. Each vendor historically defined its own container. The open-source OpenSlide library alone reads 13 format families — Aperio, ARGOS, DICOM, Hamamatsu, Huron, Leica, MIRAX, Philips, Sakura, Trestle, Ventana, Zeiss and generic tiled TIFF — and notes that its support is not endorsed by the vendors and may be incomplete [3].

The consequence is familiar to pathology IT teams: images locked to the viewer that created them, duplicated storage, brittle conversion scripts, and AI projects that spend more time wrangling files than training models.

DICOM was extended to address exactly this. DICOM Working Group 26 (Pathology) prepared Supplement 145, Whole Slide Microscopic Image IOD and SOP Classes, whose final text is dated August 2010 [1]. It defines how a multi-resolution pyramid is stored as tiled, multi-frame DICOM objects so that slides can be managed like any other medical image.

Common WSI formats compared

Vendor / formatExtension(s)Container structureOpennessPath to DICOM
Aperio (Leica) SVS.svsSingle-file tiled pyramidal TIFF with vendor metadata; JPEG or JPEG 2000 tiles [4]Proprietary metadata; TIFF readableLossless conversion supported by open tools [9]
Hamamatsu NDPI.ndpi (also .vms, .vmu)Single-file TIFF-like JPEG pyramid with custom tags; non-standard 64-bit offsets above 4 GB [5]Proprietary; standard libtiff cannot open it [5]Lossless conversion supported by open tools [9]
3DHISTECH MIRAX (Pannoramic).mrxs + folderIndex file, multiple data files and Slidedat.ini; overlapping camera tiles in JPEG/PNG/BMP [6]Proprietary; community-documented [6]; some newer scanners also output DICOM [15]Via OpenSlide decoding → re-encoded (lossy) [9]
Philips.tiff (also iSyntax)Philips TIFF; iSyntax is Philips' own format [3][14]Proprietary; vendor states lossless DICOM export from iSyntax [14]Philips TIFF lossless with open tools [9]; vendor export for iSyntax [14]
Leica SCN, Ventana BIF, Zeiss CZI, Sakura SVSlide.scn, .bif/.tif, .czi, .svslideVendor-specific TIFF variants or containers [3]ProprietaryGenerally decoded and re-encoded (lossy) with open tools [9]
DICOM WSI.dcm (series)One series per slide; multi-frame instances per pyramid level [1][7]Open international standardNative

Two practical lessons follow from the table. First, "lossless" depends on whether the original compressed tiles can be copied into DICOM frames unchanged. The open-source wsidicomizer project performs lossless conversion for SVS, NDPI and Philips TIFF, but formats read through OpenSlide (including MRXS, SCN, SVSlide and Ventana BIF) are converted with re-encoding, and z-stacks or multiple focal planes are not supported [9]. Second, MRXS is structurally different: its camera fields overlap, so building a clean, non-overlapping tile grid requires stitching and therefore re-encoding [6].

What a DICOM WSI actually looks like

A DICOM whole-slide image is not one giant file. It is a series of instances that together describe one slide:

  • VOLUME instances — one per pyramid level, each a multi-frame object where every frame is a tile. OpenSlide, for example, builds slide levels only from VOLUME images and treats LABEL, OVERVIEW and THUMBNAIL instances as associated images [7].
  • Tile organization — the Dimension Organization Type can be TILED_FULL, where tiles fill a complete grid in an implicit order and per-tile positions may be omitted, or TILED_SPARSE, where each frame's position is stored explicitly so empty background tiles can be skipped [2].
  • Transfer syntaxes — common choices include JPEG baseline, JPEG 2000 (lossy or lossless) and uncompressed; OpenSlide's DICOM reader supports these [7].
  • Concatenation — a very large level can be split across multiple files that share a Concatenation UID [7].
  • Metadata — patient, specimen, optical path and pixel spacing travel with the pixels, which is what makes DICOM objects self-describing.

Herrmann et al. demonstrated this end to end: they converted WSIs from four vendor formats, combined pixel data with patient and specimen metadata from two departments, validated the output with DICOM tools, and accessed it both from files and through RESTful DICOMweb services. They also found that compression choice strongly affected access speed — JPEG was fastest among lossy options, and JPEG-LS outperformed JPEG 2000 for lossless compression [8].

Format-specific pitfalls

  • SVS: tiles may use JPEG 2000 under TIFF compression codes 33003 or 33005, where color-space details must be read from the codestream rather than TIFF tags [4]. Converters must carry this through correctly to avoid color shifts.
  • NDPI: files over 4 GB store high-order offset bits outside standard TIFF fields, and JPEG headers record 0 when a dimension exceeds 65,535 pixels [5]. Generic TIFF tools fail on these files.
  • MRXS: a slide is a .mrxs file plus a same-named folder; if the folder is lost or renamed during migration, the slide cannot be opened [6]. Overlapping tiles mean conversion is re-encoded rather than copied [6][9].
  • Z-stacks and fluorescence: multi-focal and multi-channel images need explicit planning; some open converters do not support them yet [9].

From conversion to a vendor-neutral archive

Conversion is a means, not the goal. A 2018 review in the Journal of Pathology Informatics argued that as laboratories go fully digital, WSIs need to be brought into an enterprise-level vendor-neutral archive (VNA) [13]. In practice that means storing slides once, in an open format, with consistent identifiers, and letting viewers, LIS integrations and AI tools retrieve them through standard interfaces such as DICOMweb.

Adoption is progressing. In 2019, DICOM WG-26's connectathon drew six scanner manufacturers alongside viewer and PACS vendors [10]. A 2025 letter on behalf of WG-26 reports that a connectathon co-sponsored with IHE PaLM involved more than 30 vendors and healthcare providers, and describes Michigan Medicine sharing a common PACS for radiology and pathology [11].

The debate is not closed. In 2025, Journal of Pathology Informatics published an exchange in which one author argued DICOM is architecturally heavy for pathology, WG-26 responded with deployment evidence, and the editors recommended continuing DICOM for image exchange while pursuing modular enhancements [12]. For most hospitals, the pragmatic position is the same: standardize on DICOM for storage and exchange, and keep a clear record of how each legacy file was converted.

A practical migration checklist

  1. Inventory formats, scanner models, file counts and total storage per source.
  2. Decide policy per format: lossless tile copy where possible; documented re-encoding settings where not.
  3. Map metadata — accession number, specimen, stain, magnification and pixel spacing — from LIS and file headers.
  4. Handle label and macro images deliberately, since they can show identifiers; decide whether to keep, mask or exclude them for research copies.
  5. Validate a sample: pixel-level comparison against the source, DICOM conformance checks, and viewer display tests [8].
  6. Run in parallel with legacy viewers until pathologists sign off.
  7. Log provenance so every DICOM series can be traced back to its original file and converter version.

How Medicus approaches this

At Medicus, Inc., we see the same problems repeatedly: WSIs fragmented across scanners and solution vendors, operational burden on pathology and IT teams, and a missing data foundation for AI and research. MeDIAuto® is our AI-based integrated pathology data infrastructure (image management system). It standardizes WSIs scattered across scanners and vendors so they can be collected, managed, analyzed and reused for research. According to our company timeline, Medicus signed a supply contract for MeDIAuto with Seoul St. Mary's Hospital in December 2025. The system is now in routine clinical use there.

If you are planning a WSI standardization or DICOM migration project, talk to our team.

FAQ

Is converting SVS or NDPI to DICOM lossless?

It can be. When the original JPEG or JPEG 2000 tiles are copied directly into DICOM frames, no pixels are re-compressed. Open tools such as wsidicomizer report lossless conversion for SVS, NDPI and Philips TIFF [9].

Why is MRXS harder to convert?

MRXS stores overlapping camera fields across several data files plus an index and Slidedat.ini [6]. Producing a non-overlapping DICOM tile grid requires stitching, so the tiles are typically re-encoded [6][9].

Do I need a vendor-neutral archive to use DICOM?

Not strictly, but a VNA or DICOM-capable PACS is where the benefits appear: one copy of each slide, standard retrieval, and shared access for viewers and AI [11][13].

Can I view DICOM WSIs with open-source software?

Yes. OpenSlide reads DICOM WSI series with JPEG, JPEG 2000 and uncompressed transfer syntaxes and both full and sparse tiling [7].

Will DICOM files be larger than the originals?

With lossless tile copying, pixel data size is roughly unchanged, plus metadata overhead (estimate). Sparse tiling can skip background tiles [2]. Re-encoding changes size depending on codec and quality settings [8].

Is DICOM required for clinical AI?

Not universally, but standard formats reduce per-vendor integration work and make it easier to run algorithms across scanners [11].

References

  1. DICOM Standards Committee, Working Group 26. Supplement 145: Whole Slide Microscopic Image IOD and SOP Classes (Final Text, 2010-08-24). dicomstandard.org (PDF)
  2. NEMA. DICOM PS3.3 2024c, Section C.7.6.17.3 (Dimension Organization Type: TILED_FULL / TILED_SPARSE). dicom.nema.org
  3. OpenSlide. Supported formats. openslide.org/formats
  4. OpenSlide. Aperio format. openslide.org/formats/aperio
  5. OpenSlide. Hamamatsu format. openslide.org/formats/hamamatsu
  6. OpenSlide. MIRAX format. openslide.org/formats/mirax
  7. OpenSlide. DICOM format. openslide.org/formats/dicom
  8. Herrmann MD, Clunie DA, Fedorov A, et al. Implementing the DICOM standard for digital pathology. J Pathol Inform. 2018;9:37. doi:10.4103/jpi.jpi_42_18. PubMed 30533276
  9. imi-bigpicture. wsidicomizer (GitHub README). github.com/imi-bigpicture/wsidicomizer
  10. DICOM WG-26. Face-to-face meeting minutes, 2019-10-06 (connectathon participants). dicom.nema.org (PDF)
  11. Yousif M, Napora B, Groth J, et al., on behalf of DICOM WG-26. Maintaining and broadening DICOM adoption in digital pathology. J Pathol Inform. 2025;19:100517. PMC12616093
  12. Pantanowitz L, Parwani A. The path forward: Evolving standards for a smarter digital pathology ecosystem. J Pathol Inform. 2025;19:100516. PMC12546968
  13. Pantanowitz L, Sharma A, Carter AB, Kurc T, Sussman A, Saltz J. Twenty years of digital pathology: An overview of the road travelled, what is on the horizon, and the emergence of vendor-neutral archives. J Pathol Inform. 2018;9:40. PMC6289005
  14. Philips. DICOM in digital pathology. philips.com.au
  15. 3DHISTECH. PANNORAMIC 1000 DX (supports DICOM and MRXS). 3dhistech.com

An AI-powered healthcare platform,
creating new value
for the future of humanity.

Solution Inquiry

IMS Platform

Biomarker AI-IVD

Biomarker Research Pipeline

Solution Inquiry