DICOM Recovery in Practice: From Recovered Bytes to Verified Images

1. Why might a recovered DCM file still fail to open?

General-purpose recovery tools can recover DICOM files correctly. When allocation records and original data survive, the original file may be recovered. TestDisk's official demonstration includes files stored in multiple fragments.

Distinguish three layers:

PhotoRec, for example, locates signatures and documents that some formats require subsequent signatures to determine where recovery should stop. DICOM adds several challenges:

1. Names and sizes can survive after content changes. A directory record does not prove the referenced storage still holds the original bytes.
2. Fragments need not be contiguous. A sequential export can omit a region or include unrelated content. A tool with valid allocation records may instead reconstruct it correctly.
3. There is no universal DICOM rule of “start marker to end marker.” Element lengths, nested sequences, and encapsulated fragments govern parsing.
4. One recovered container can contain multiple real objects. Some embedded images may be intact even though the enclosing file is not one valid DICOM file.
5. Missing codec support can look like corruption. A missing JPEG 2000 decoder is not evidence of missing pixels.
6. One file may hold multiple frames, and one study may contain multiple series. File counts or a visible first frame do not establish study completeness.

A folder named Decompress is a lead for finding compressed originals, expanded copies, or workstation caches, not proof of an overwrite mechanism. SSD TRIM is a notification about released storage; its current setting alone cannot establish whether a particular file's bytes were erased.

2. Preserve the source and recovery evidence

Stop writing to the source. Keep the original disk, all recovery outputs, recovery projects and logs, directory information, and allocation mappings. An image used to investigate deleted files should cover the complete relevant disk or partition range, including unallocated areas that may contain deleted data, rather than only currently allocated files.

The following Linux example is for readers familiar with disk handling. It was not run against your disks. Verify model, capacity, and serial number; unmount every source partition. The destination must be another healthy physical disk with sufficient space and new output filenames.

lsblk -o NAME,SIZE,MODEL,SERIAL,TYPE,MOUNTPOINTS,RO

# Replace the source placeholder with the independently verified device.
# The output directory must be on another physical disk.
sudo ddrescue --ask --no-scrape --retry-passes=0 \
  /dev/disk/by-id/REPLACE_WITH_SOURCE_ID \
  /mnt/OTHER_DISK/recovery/source.img \
  /mnt/OTHER_DISK/recovery/source.map

Keep source.map with the image: it distinguishes successfully read areas from unread or failed areas. Zeros in an image can represent holes or unread regions, so do not assume they are authentic pixels without checking the mapfile. This is an initial pass, not a prescription for repeated retries. Clicking, disconnecting, or persistently failing drives require an assessment of physical recovery risks.

Windows users can use another computer or a Live USB for imaging. Do not install tools on the system disk being recovered. This guide does not instruct you to repair, format, or write replacement data to the source filesystem.

3. Examine recovered files without changing the originals

Work from a verified copy. Record file size, hashes, offsets, and recovery provenance. Check Part 10 preamble and DICM marker, file meta information, Transfer Syntax UID, SOP identifiers, and element boundaries. A marker alone does not establish completeness.

4. Separate codec incompatibility from missing data

Compare Rows, Columns, Samples per Pixel, Bits Allocated, Number of Frames, Pixel Data length, and the actual transfer syntax. For encapsulated JPEG/JPEG 2000 data, inspect fragment and frame boundaries. Try an independently supported decoder before declaring pixels lost.

5. Locate and validate candidate objects

In mixed or shifted recovery output, candidate DICOM headers can be found by signature and plausible element parsing. Determine byte ranges from reliable structural and filesystem evidence; never assume the next DICM marker is the end of the preceding object. Extract only confirmed ranges into separate copies and preserve provenance.

6. Repair only what the evidence supports

When a dataset is complete but its file wrapper is missing, a Part 10 wrapper may be rebuilt using a verified transfer syntax and SOP identity. If a compressed image fully decodes, a compatible uncompressed copy may be produced and checked pixel by pixel. Do not invent missing pixels, patient identity, slice locations, or compression parameters.

7. Validate the resulting study

Reopen every output, verify decoded frames and pixel equivalence where applicable, compare source and output metadata, and group by Study and Series Instance UIDs. Check geometry, duplicates, missing frames, and original equipment/PACS manifests. Label partial recovery clearly.

8. Reconcile grouping, duplicates, and study completeness

Group using StudyInstanceUID and SeriesInstanceUID while cross-checking identity and provenance. Interpret PatientID within its issuer or source system; a name or folder label is not a unique identity.

For repeated SOP Instance UIDs, compare bytes, decoded pixels, and key metadata. Different transfer syntaxes can produce different bytes. Conflicting pixels, identity, or geometry must be isolated and reported rather than silently overwritten.

For ordinary single-frame spatial slices with consistent orientation, use geometry to sort:

normal = np.cross(iop[:3], iop[3:])
position_on_normal = np.dot(normal, ipp)

Do not apply this as a universal series-merging rule. Dynamic, multiphase, multi-echo, differently oriented, and enhanced multiframe objects require dimension and per-frame information. Repeated positions are not automatically duplicate images. Consecutive instance numbers do not prove that every series survived; compare with the original workstation or PACS inventory.

After decoding every image, inspect representative slices, adjacent continuity, and multiplanar views for implausible discontinuities or substituted content. A normal-looking display still does not replace provenance and inventory checks.

9. Package the result

Record verified objects, partial extraction, and unresolved candidates separately. pydicom's FileSet can build a DICOMDIR; reload it and check that every referenced file exists.

If required identity or directory attributes are absent, resolve the evidence gap rather than inventing patient details. Deliver missing-data lists, source-to-output mappings, conversion information, and validation results with the files. ZIP CRC checks archive contents; it does not replace DICOM or pixel validation.

A standard directory layout does not imply complete IOD or media application-profile conformance. Disclose any remaining metadata issues.