Converting a dcm file to JPEG takes one click, and the result opens in anything: a browser, a slide deck, an email attachment, a phone’s photo app. That portability is the entire point of doing it, and it is also where the trouble starts. A DICOM object carries a lot more than a picture, and most of that additional material has nowhere to go once the image lands in an ordinary image file.
Convert a study to JPEG, PNG, or a plain PDF, and the pixels usually still look fine on screen. The bit depth that made subtle density differences visible is gone, along with the physical scale that made a measurement trustworthy and the identifiers that tied the picture to a patient and a study. The window setting is not gone: it is baked into the pixels at whatever value was active on export, and what you lose is the ability to change it. None of that shows up as an error message: it shows up later, when someone tries to use the converted file for something it was never built to support.
What Conversion Actually Throws Away
A .dcm file is not a picture with a few extra tags attached. It is a tagged data set where the pixel array is one element among dozens, alongside the attributes that describe how to decode it, calibrate it, and relate it to its exam. A general-purpose converter reads that data set, renders the pixels the way a viewer would at that moment, and writes a new file in a format built to hold nothing but a flat image. Everything the DICOM object carried that is not pixels either gets discarded outright or gets baked into the pixels themselves, permanently, with no way back.
What follows is where each of those losses actually happens, and which ones matter for a given destination.
Converting a DCM File to JPEG or PNG: Where the Bit Depth Goes
CT and MR data is commonly captured and stored at 12 to 16 bits per pixel sample. DICOM’s Image Pixel module defines Bits Allocated in a single line: “Number of bits allocated for each pixel sample.” Bits Stored gets the equivalent definition for the bits actually carrying data. A 16-bit CT slice needs that range to represent air, soft tissue, and bone as distinct Hounsfield unit values inside one image.
Those Hounsfield values are not the stored numbers themselves. A CT object carries Rescale Slope and Rescale Intercept, and a viewer applies them to every stored value: output units equal slope times the stored value, plus intercept. For an original CT image, those output units are Hounsfield units. Both attributes live in the data set rather than in the pixels, so a converted file keeps the rendering and loses the calibration.
JPEG and PNG, the two formats most conversion tools default to, write 8 bits per channel by default: 256 discrete gray levels. Neither format is locked there on paper, since PNG allows a 16-bit sample depth and the JPEG standard specifies a 12-bit DCT process alongside its 8-bit baseline. What the default export path writes, and what ordinary display hardware takes in, is 8 bits.
Squeezing 4,096 or 65,536 possible values down to 256 is not a cosmetic resize. It is quantization, and it destroys windowing latitude specifically: the ability to move the visible range after the fact to bring out a different tissue contrast from data that already exists in the file. A 16-bit source has values to spare for that kind of remapping. An 8-bit JPEG does not, and whatever contrast survived the one conversion pass is the only contrast the file will ever have.
The Window Setting a Converted Image Bakes In
A DICOM viewer does not render stored pixel values directly. It applies a window first. The standard’s VOI LUT module is direct about what the two controls do: “Window Center contains the input value that is the center of the window.” Window Width gets the parallel definition, the width of that window, and together they map whichever slice of the stored values falls inside the range onto the visible grayscale.
A radiologist reading a chest CT moves between a lung window and a mediastinal window on the same image constantly, because no single window shows everything a study contains. A converted JPEG or PNG carries exactly one window, whichever one happened to be active in the viewer at export time. That window is now fixed into the pixel values, with no way to change it afterward.
The result is not really “the study” anymore. It is a single screenshot of one interpretation of the study, permanently locked at whatever setting someone happened to be looking at.
Pixel Spacing and Why a Ruler Drawn on a Converted Image Can Lie
A distance measurement on a DICOM image is only meaningful because the object carries the physical scale that makes it meaningful. DICOM’s Image Plane module defines Pixel Spacing as the physical distance, in millimeters, between the center of one pixel and the center of the next, given as a row-spacing and column-spacing pair. A viewer converts a line drawn on screen into millimeters by reading that attribute directly, not by guessing from how large the image happens to appear.
A JPEG or PNG carries no such attribute. Its only spatial reference is pixel count, and pixel count is not physical scale. Resize the image at any point, on export, in an email client, in a slide deck, and the relationship between a pixel and a millimeter changes with it, silently.
A tool that lets someone draw a line on a converted image and reads out a number in millimeters is not measuring the patient. It is applying an assumed scale to a file that no longer carries the one it was actually acquired with, and the result can look exactly as credible as a real measurement while being wrong.
Where the Study Hierarchy Goes When a File Leaves DICOM
Every DICOM object carries the identifiers that tie it to a patient, a study, and a series. That structure lets a PACS relate hundreds of individual files back into the exam they came from, without depending on a filename or a folder path. A JPEG or PNG has none of that. Convert three hundred slices of a chest CT and the result is three hundred orphan image files: no Study Instance UID, no Series Instance UID, no patient context, nothing tying one slice to the next.
That loss is invisible right up until someone needs it. A single converted slice attached to an email works fine as a standalone picture. A folder of three hundred converted slices that a downstream system has to reassemble in the right order, for the right patient, is a different matter. The DICOM object solved that by design; the flat files do not solve it at all.
DICOM-Encapsulated PDF Versus an Exported PDF
Reports get converted too, and the standard actually offers a middle path worth knowing about: wrapping a PDF inside a DICOM object rather than exporting one outright. The Encapsulated PDF IOD “describes a PDF document that has been encapsulated within a DICOM Information Object.” Its module table still requires the Patient module and the General Study module alongside the PDF content itself, the same identifying attributes an image object carries. A DICOM-encapsulated PDF stays inside the archive, queryable and retrievable by study like anything else, because structurally it is still a DICOM object with a PDF sitting inside its data set.
An exported PDF, saved out of a viewer as a standalone file and emailed or printed, keeps none of that structure. Whatever patient and study information appears on the page is text a person can read, not metadata a system can index, relate, or retrieve the way it would a DICOM object.
Burned-In PHI Risk When You Convert
Conversion carries one risk that none of the structural losses account for: identifying text that was never an attribute in the first place. A de-identification pass, the kind that clears Patient Name, Patient ID, and the other tagged attributes DICOM defines, works on attributes, not on pixels. Ultrasound in particular routinely carries a patient name and exam date rendered straight into the frame itself, not into a field a scrubbing script can find by tag.
Clearing every attribute in that study does nothing to that text. It is still sitting in the pixel values, and converting the file to JPEG or PNG carries it straight through the export, unchanged, now visible in a format nobody downstream is checking for identity risk.
Converting also removes the one place DICOM gives an implementation to flag that risk before it spreads further. A .dcm file can carry an attribute stating whether it contains identifying text burned into the pixels. A JPEG or PNG has no equivalent field at all, and no downstream system has anything to check before deciding whether the image is safe to forward. Whatever risk review happened, or did not happen, on the DICOM side disappears the moment the file stops being DICOM.
When Converting Out of DICOM Is the Right Answer
None of this is an argument against ever converting a study. It is an argument for knowing what the converted file is actually for.
Think of a slide for a conference talk, a frame in a referring physician’s summary email, or a printed handout for a patient. None of these need bit depth, a live window, calibrated pixel spacing, or a study relationship, because nobody downstream will window, measure, or reassemble them. A flat, fixed image is the right tool for a use case that only ever needed a picture.
The distinction that matters is whether the destination needs to treat the result as a study or just as an image. If it is still a study, it belongs inside DICOM, moved as DICOM, not flattened first and reconstructed later from an image that no longer carries the attributes to support it. Across the EBM mAIn PACS® line, EPS Pi provides the DICOM server, storage, and routing, and the UDE workstation shares studies by QR code, AirDrop, or over the network.
What This Means for Your Evaluation
The practical question before converting anything is narrow: what does the file need to do once it leaves DICOM. If the honest answer is that someone will only look at it, conversion is fine, and choosing it deliberately beats defaulting to it because it was the first export button available. If the answer is anything more than that, the study should move through native DICOM services instead, the way it does between a modality, an archive, and a viewer that speak the same standard.
Either way, the loss is not a bug in a particular converter. It is what happens whenever a data set built to carry calibration, identity, and a live rendering pipeline gets flattened into a format that was only ever built to hold a picture.