How to Redact DICOM Pixel Data Without Breaking the Image

A computed tomography (CT) slice stored as DICOM (Digital Imaging and Communications in Medicine) can come back from de-identification looking perfect on screen and still be broken. The numbers behind the picture may no longer mean what the scanner recorded. To redact DICOM pixel data without breaking the image, the mask has to be written in the image's own values, and the result has to be checked against the original.

Medical images are not photographs, and tools built for photographs make assumptions that fail on them. A CT image stores between 12 and 16 bits per pixel, sometimes as signed numbers, and rescale values in its header turn them into tissue density. A magnetic resonance (MR) or X-ray image may keep 12 bits of data inside 16, and what a viewer shows depends on rescaling, windowing and whether the image is displayed inverted. Our guide to DICOM de-identification covers where burned-in text comes from and the header that surrounds the pixels.

The work itself runs in five steps, whatever tool does it, and the sections below follow them in order.

1. Read the attributes that say how the file stores its pixels before changing any value.
2. Find the text on a viewable copy of each frame, and set the copy aside once the text is located.
3. Write the mask into the original stored values, in the image's own type and range, choosing a mask style that suits the release.
4. Decide what the pixel data is written back as, compressed or uncompressed.
5. Compare the result with the original, value by value, before anything is released.

Read how the file stores its pixels

Every pixel in a DICOM image is a stored value, and a handful of header attributes say how to turn stored values into measurements and then into something a screen can show. The definitions below come from the Image Pixel Module, the CT Image Module and the VOI LUT Module that handles windowing, all in PS3.3.

The attributes work together, which is why none of them can be read alone. A CT file can store unsigned values and reach negative densities through a negative intercept, or it can store signed values directly. The meaning of a fill value therefore depends on both Pixel Representation and the rescale attributes.

The usual shortcut of exporting to an 8-bit picture, blacking out the text and importing the result back throws most of this information away. Thousands of possible values collapse into 256 display levels chosen by one window setting, and negative values have nowhere to go. If that picture is written back, the whole frame holds an approximation instead of what the scanner measured, including the regions that never held any text.

Find the text on a copy, then set the copy aside

Text detection needs an image a recognizer can read, so it runs on a viewable copy of each frame, and that copy exists only to find the text. Writing the copy back would replace the frame's diagnostic values with a display approximation, so it is set aside once the text is located and the mask goes into the original stored values. In a multi-frame file that happens on every frame. Deciding which of the text found counts as personal is a separate step, and the article on burned-in text in DICOM images takes it up.

Write the mask in the image's own values

Signed CT data is where a careless round trip does the most damage, because the values run on both sides of zero. Air sits far below zero and dense bone far above it, and a mask computed on an 8-bit copy and pasted back can clip the negative values or rescale the region. If the pixel type or signedness changes on the way out, viewers can misread the whole file, and the damage reaches well beyond the masked corner. Everything outside the masked regions should come back exactly as it was decoded from the original, with the same pixel type, signedness and range.

The DICOM standard is explicit that de-identifying pixels means changing the stored values themselves. The Clean Pixel Data Option in PS3.15 says "The Stored Pixel Values are to be changed (blacked out)". It adds that "it is not sufficient to superimpose an overlay or graphic annotation or shutter" to hide them. An overlay can be switched off, and a viewer that does not support it never draws it, which is the same weakness overlay redaction has in documents.

Choosing the mask: solid, blur or pixelate

Solid fill is the conservative choice for text, because it replaces the region with one value and leaves no trace of the letter shapes. Blur and pixelate keep more of the image's look, which some readers prefer, but the region they leave behind is still derived from what was underneath. Images headed for a dataset that will train a model raise a further question, since a blurred patch can look like texture to an algorithm while a solid box is easy to find and exclude.

A fill value does not simply mean black, because what it looks like depends on the photometric interpretation and the display window. On a MONOCHROME1 image, where the minimum value is displayed as white, a fill at the lowest stored value shows as a white box. On any image, the window settings decide whether the box reads as black, gray or white, so a fill that looks right on one modality needs testing on the others. Color adds its own traps, because a mask has to reach every sample of each pixel. In a YBR image, whose three planes are luminance and two color-difference channels, writing zero into all three produces a colored box instead of a black one.

Pixelation fails in a way that is easy to miss, because the failure shows up only on the smallest regions. A pixelation step that uses one fixed block size can return a region only a few pixels across exactly as it was. Masking is then weakest precisely where a single burned-in character or a thin strip of text sits. Pixelation has to be sized to each region so that even a region a few pixels across is obscured, and the smallest masked regions are the first ones to compare with the original.

Compression and file size after masking

Changing pixels means decoding them first, and that forces a decision every pixel-level tool has to make about what it writes back. A study stored with JPEG or JPEG 2000 compression has to be decompressed before any value can change, and the tool then either writes the pixel data uncompressed or compresses it again. Re-compressing with a lossy method changes pixels across the whole frame, including those the mask never touched, while writing uncompressed data keeps every value exact at the cost of size.

The transfer syntax records how a file's pixel data is encoded, and some compressed transfer syntaxes, lossless JPEG among them, raise decoding questions of their own. Whether to re-compress at all is a decision to make with the team that stores and moves the data, since the de-identified copy may be much larger than the original. A file whose pixels needed no mask has no reason to be re-encoded, so in a well-behaved workflow only the files that were actually masked change size.

Compare the result with the original

Changing the right pixels is half of the requirement, and leaving every other pixel exactly as it was is the other half. In a benchmark challenge for medical image de-identification tools held in 2024, one of the pixel checks tested only that pixels which should stay unchanged were unchanged, and half of the submissions failed it. The organizers caution that the dataset held only a small number of images with burned-in identifiers, but the result is a reminder to compare every unmasked pixel with the original.

The comparisons below need only the original file, the de-identified file and a DICOM toolkit, and they work on any tool's output.

What Redactor writes back

VIDIZMO Redactor writes each mask into the stored values of the frame, and the file it hands back has the properties below.

• The pixel type does not change, so 12- and 16-bit data, signed or unsigned, stays in its native range whichever of solid fill, blur or pixelation the job used.
• The output is a DICOM file rather than a converted image or PDF.
• The pixel data is written uncompressed after masking, so a compressed study comes back larger, and storage and transfer for the release should be planned with that in mind.

The header side of the same workflow, and the formats Redactor accepts, are on Redactor's page for DICOM redaction.