Why convert
Most digital pathology archives started in the scanner vendor's format. That works while the scanner, its image server and its viewer stay together. It stops working when the lab adds a second scanner brand, moves to an enterprise image archive, adopts a new viewer, or wants slides alongside radiology in a VNA.
DICOM WSI gives whole-slide images the same things radiology already has: a standard object any conformant archive can store, standard query and retrieve, patient and specimen context inside the object, and a path to keep the images when the scanner vendor changes.
SVS and DICOM WSI compared
| Aspect | Aperio SVS | DICOM WSI |
|---|---|---|
| Container | One TIFF-based file per slide | A DICOM series per slide, one instance per image |
| Resolution levels | Several pages in the same file | Each level a separate tiled, multi-frame instance |
| Label and overview | Extra pages in the file | Separate instances, identified by Image Type (LABEL, OVERVIEW) |
| Tile compression | Usually JPEG or JPEG 2000 | Any DICOM transfer syntax; JPEG Baseline and JPEG 2000 are common |
| Scanner metadata | Free text in the TIFF description field | Structured attributes: pixel spacing, objective power, optical path |
| Patient and specimen | Usually absent | Patient, accession, specimen and container modules |
| Access | Vendor image server or a file share | DICOM and DICOMweb, from any conformant archive |
Carrying the pixels over
A whole-slide image is a pyramid: the full-resolution image cut into tiles, plus progressively smaller copies so a viewer can zoom out without loading gigabytes. DICOM stores each level of that pyramid as its own instance of the VL Whole Slide Microscopy Image Storage SOP class, with the tiles as frames.
- Copy, don't recompress, where possible. If the SVS tiles use a compression that has a matching DICOM transfer syntax, the compressed tiles can be placed into DICOM frames as they are. No decode, no re-encode, no generation loss, and much faster than recompressing.
- Decode and re-encode only when you must. Some files use compression variants that have no direct DICOM equivalent. Those tiles must be decoded and re-encoded. Choose lossless re-encoding unless the lab has explicitly accepted lossy, and expect larger output.
- Keep the whole pyramid. Viewers depend on the lower-resolution levels for fast navigation. If the source is missing levels, generate them, and record that they were generated.
- Keep the color profile. Scanner ICC profiles affect how stains display. Carry them into the DICOM optical path information so slides look the same in the new viewer.
The metadata is the hard part
An SVS file knows about the scan: dimensions, microns per pixel, magnification, scanner and date. It usually does not know whose tissue is on the slide. In DICOM, the object carries that context, so it has to come from somewhere.
- The link. Usually the slide barcode, read from the label image or captured at scan time, or the file name if the lab used a consistent naming convention.
- The source of truth. The laboratory information system: patient, case accession, specimen, block, stain, and the container identifier for the slide.
- The gaps. Slides with unreadable barcodes, files renamed by hand, and cases that were re-accessioned. Plan for an exception list, exactly as with unmatched radiology studies.
Decide early which identifiers the target archive and viewer expect, because a pathology viewer will typically find slides by case accession, not by patient ID.
The slide label is PHI
The label image is a photograph of the glass slide's label. It often shows the patient name, case number and barcode. The overview image can capture the label too. In a clinical archive that is useful. In a research or AI dataset it is burned-in PHI.
For research exports, drop the label instances, mask the label area in the overview, and de-identify the headers like any other DICOM object. More on that in de-identification for research and AI.
Validating the conversion
Whole-slide images are big enough that "it opened" is not a test. Check each slide against its source:
- Every source file produced a DICOM series, or is on the exception list with a reason
- Full-resolution dimensions and tile counts match the source
- Pixel spacing and magnification match the scanner metadata
- Where tiles were copied, the compressed tile data is identical to the sourceWhere tiles were re-encoded losslessly, decoded pixels match
- Patient, accession, specimen and stain match the LIS record for the slide
- Slides open and navigate in the target viewer, with correct color, on a sample from every scanner and stain type
- The archive returns every instance when queried by accession
Planning a conversion project
- Inventory first. Count files per scanner model and software version, and sample their compression and metadata. Archives built over years usually hold more variety than expected.
- Size the storage and network. A single slide can be several gigabytes. Conversion that copies tiles keeps sizes close to the original; re-encoding can grow them.
- Decide on the source files. Keep the originals until the converted archive is validated and accepted, and decide up front how long after.
- Run it in batches. Convert, load, validate and sign off batch by batch, so a problem in batch three doesn't invalidate everything.
Questions
What is an SVS file?
SVS is the whole-slide image format used by Aperio scanners (Leica Biosystems). It is a TIFF-based file that holds the full-resolution image as tiles, several lower-resolution copies of it, and usually a thumbnail, a label image and an overview (macro) image, with scanner metadata stored as text.
What is DICOM WSI?
DICOM Whole Slide Imaging is the DICOM standard for digital pathology, defined by the VL Whole Slide Microscopy Image Storage SOP class (1.2.840.10008.5.1.4.1.1.77.1.6). Each resolution level of the slide is stored as its own tiled, multi-frame DICOM instance, and the label and overview images are separate instances, all in one series.
Can SVS be converted to DICOM without losing quality?
Often, yes. When the tiles in the SVS are compressed with a scheme DICOM supports, they can be copied into DICOM without being decoded and re-encoded, so the pixels are bit-for-bit the same. Files whose compression has no DICOM equivalent have to be decoded and re-encoded, which can be lossless at the cost of larger files.
Where does the patient information come from?
Usually not from the SVS file, which typically holds scanner metadata and a slide identifier at most. Patient, case, specimen, block and stain information comes from the laboratory information system, linked by the slide barcode or accession number.