Dicom File Format Basics

https://www.vladsiv.com/dicom-file-format-basics/

by vladsiv • 4 years ago

119 89 4 years ago

vladsiv.com

greatgib• 4 years ago

Very nicely written article. I guess that it is pleasant to read even if we don't have to work with the Dicom format.

The explanation of TLV could be interesting also in itself.

vladsiv6• 4 years ago

Thank you, I really appreciate it!

brnt3• 4 years ago

The problem with extensibility is that everyone does! Manufacturers will dump in all sorts of tags, and check for them, when you read in, but the won't tell you what they are and how you might calculate their supersecret checksums (for safety!).

Dicom Compliance is a well paying job.

vladsiv6• 4 years ago

Manufacturers will dump in all sorts of tags, and check for them, when you read in, but the won't tell you what they are

True. As far as I know it could be also used for a vendor lock-in. If you export DICOM files from X, you have to use software Y. Since they are dumping all sorts of private tags which you don't know anything about.

danielheath3• 4 years ago

In practice, the files can be viewed just fine in any standard-compliant viewer without any awareness of custom tags.

Source: I wrote the DICOM viewer & anonymizer for Radiopaedia (okay, most of the heavy lifting is done by cornerstone.js).

fluidcruft7• 4 years ago

In many cases it's because the standards don't (yet) support storing important information or weren't performant. For example, in DTI imaging recording of the diffusion vectors was not something that DICOM supported until DTI use became more widespread clinically. In other cases it was network performance hacks. Another example with DTI is that initially DICOM for MRI only supported 2D images. Which for DTI is a problem because you easily end up with thousands of images and transferring them as individual 2D with all the network handshaking and storage confirmations is slow as molasses and grinds on PACS that aren't setup for this. Some vendors "solved" this by creating large 2D images of 3D images by laying out multiple 2D slices in a mosaic. Because the 3D volume became one 2D image, transfers were much faster and doesn't consume as many resources on PACS. Eventually the DICOM standard came up with an even better solution, but it's only recently starting to roll out on the scanners and the old ways still persist.

queuebert2• 4 years ago

I have some DICOM experience. How does one go about getting these compliance jobs?

vladsiv6• 4 years ago

I would also like to know :D

brnt3• 4 years ago

Manufacturers of devices and associated software (eg treatment planning systems) tend to have somebody like that. Not sure you actually want to though.

mattkrause• 4 years ago

I had a good snicker at the "Basics" in the title for exactly this reason!

juliansark• 4 years ago

My amazing experience with DICOM, an open standard with viewer software on SourceForge, is that I once took pictures in the format to a locally renowned neurologist.

She plugged my USB stick into her Windows XP workstation, ca. 2019, without the slightest hesitation, then proceeded to claim not to know what DICOM is, and to ask me why I didn't bring her either the proprietary viewer program, or JPEGs.

Had I brought the viewer, she would have probably launched the .exe with equally no hesitation.

At least in these parts of the woods, this once again confirmed to me that medicine and IT usually exist at opposite ends of a spectrum.

phkahler• 4 years ago

You needed to bring a free DICOM viewer and have her install it ;-)

tecleandor3• 4 years ago

Oh yeah, really. Doctors, standards and computers not always mix well.

Thankfully nowadays there are lots of local-only web DICOM viewers, based on Cornerstone or other JS libraries...

https://github.com/ivmartel/dwv

https://github.com/webnamics/u-dicom-viewer

samuel• 4 years ago

Dicom files are usually in a structure that includes a viewer (there is a IHE profile which standardizes it). Barring radiologists physicians rarely know about file formats, and the portable media "just works" (mostly).

lostlogin2• 4 years ago

In my experience the specialists just offload this problem (and any other imaging tech problems) to their radiology provider, and while that might be a local phenomenon, I’d hazard a guess that it’s universal.

tainto• 4 years ago

then proceeded to claim not to know what DICOM is

98% (made up number) a non-radiologist physician is going to bring up the image on whatever institutional lightweight PACS viewer is provided, and then occasionally in clinic on a disk that has some viewer provided. Not providing a viewer with a disc is kind of a dick move. Most people using smartphones have no idea what HEIC or JPG really is, and why should they?

this once again confirmed to me that medicine and IT usually exist at opposite ends of a spectrum.

Do you actually know how to read even a chest X-ray or an echocardiogram?

I never quite understood this tech fascination with pointing out/being surprised that specialized experts are not generally deeply familiar with IT. It has little to nothing to do with their everyday jobs.

I don't know of any doctors that would be surprised that an IT worker/engineer cannot properly read a neuro MRI or any other image for that matter. But people here are always surprised when most doctors don't have beyond a lay understanding of computers. I do think the tech crowd tends to have a lot more hubris though. Amateur docs and lawyers seem not to be in short supply around here.

badsectoracula• 4 years ago

Had I brought the viewer, she would have probably launched the .exe with equally no hesitation. At least in these parts of the woods, this once again confirmed to me that medicine and IT usually exist at opposite ends of a spectrum.

Well, on the other hand she'd be able to do what she needed without any other distractions - and in case you happened to break the machine, you'd be around to slap or pay up for the fixes :-P.

At the end of the day for most people computers are there to help their jobs.

VikingCoder• 4 years ago

This is like a restaurant that has a QR code on the table instead of a menu.

Yes, it's absolutely possible for someone to use the QR code to fetch the menu from a website using their phone. But unless you do it often, you just don't even know how to do it.

Doctors are insulated from DICOM the same way that most humans don't normally type "h t t p : / /" They just click on links and things show up for them.

classichasclass• 4 years ago

My clinical work is in TB control and we read a lot of chest X-rays and CT scans. I'm very used to DICOM and I have my personal preferences for DICOM viewers, but outside of an actual radiology suite most docs will just use whatever viewer came on the disc, if there's one at all. And that's largely true for the ones I've worked with in this field, too.

That said, I was in IT before I got my MD.

nick__m2• 4 years ago

What your preference, and do you like https://www.slicer.org/ ?

solardev• 4 years ago

IMHO, I don't think it's ever safe to assume that someone, even if they're in tech, would readily know what file format X is or have the right software for it. If in doubt, you should provide them the way to easily see whatever it is you want to show them, whether it's a x-ray or a hiking map or a giant party banner.

When I got my scans from the radiologist, they came on a CD-ROM (remember those?). I had to dig up my old disc drive from storage, then loaded the files onto my phone. At the orthopedist, I just showed it to them right on the phone with a Android DICOM viewer. I also brought the original CD, along with the same files plus 2-3 different viewers on my laptop, juuuuust in case. There's no way I was going to risk another clinic visit, at what, $300/visit?, just because they couldn't read the images. I'd do the same anytime I was visiting another professional. I don't assume to know their tech setup or level of file format expertise... that isn't what I'm paying them for, after all.

As an aside, in my brief investigation into DICOM (a format previously unknown to me before my injury), I discovered that it's actually a pretty complex format, with different viewers having pretty different UIs in terms of how they handle layers within a file (in both time and space), overlays and contrast adjustments (to emphasize/deemphasize certain artifacts, apparently), different collections and naming schemes for the same body parts, etc. Some of them were barely more usable than a JPEG viewer, while others could interpolate/extrapolate the data into a 3D point cloud and create rough anatomical models by combining collections of images from different angles. It's quite a complex system of raster imaging plus metadata, and no two viewers worked quite the same, even between the several free and/or open-source options. It reminds of the nonstandard mess that is file packaging for GIS (geographic information systems) -- a lot of power, but no simple system for organizing that power. In that sense DICOM is more like a database of radiological data that happens to be plottable in 2D (and sometimes 3D) space, rather than a simple image. If you export it to JPEG, you get a static output in time & space and lose a lot of the power of DICOM.

There are a loooooooot of ways to store imaging data out in the wild, and many different versions & viewers for each format... rather than looking down on someone for not keeping up with the tech stacks du jour, why not just help them get what they need to do their job more effectively? Especially when they're working to heal you.

xvilka• 4 years ago

There is also a problem that many DICOM viewers are outdated and abandoned, e.g. written in GTK+ 2.x which is not availabe on modern systems, and weren't updated for many years. Take, for example, AMIDE[1] - no changes in the development repository for 5 years already. Same story with many other projects.

[1] https://sourceforge.net/projects/amide/

pc86• 4 years ago

Until I took a senior developer role at a radiology practice I had no idea what DICOM was. The idea that a physician should know is kind of fanciful, isn't it? In 99.99% of cases, they load images by clicking a button that says "Display images" in a PACS, or RIS, or the images are loaded automatically by workflow. It's like expecting someone who has only ever viewed webpages, and never even viewed the source let alone made a webpage, to know the difference between JPEG, GIF, and PNG.

1MachineElf• 4 years ago

Physicians know that a DICOM file is what you get when you export from their viewer software. I asked a chiropractor for my x-rays and they just gave me a CD with two DICOM files on it. That chiropractor was an idiot, but at least they knew what a DICOM was.

riedel• 4 years ago

My father practice moved digital in the late nineties, they had a cd robot that would burn the dicom images together with a quite decent windows viewer from Siemens (actually it had nice contrast and zooming features) on the disk with autorun config (nobody cared at this time about security). The future was here...

Fun side aspect of the story is that they bought the wrong type of CD-Rs for the robot and I am still having empty CD-Rs from a batch of 500 or so I am using (once every other year).

balls187• 4 years ago

that medicine and IT usually exist at opposite ends of a spectrum.

Working in Medicine you learn that specialists, and in particular renowned ones have their worlds optimized around having them do what they do best, and not wasting time not doing what they do best.

petercooper• 4 years ago

Coincidentally, for me, I had an MRI yesterday and they always give me access to the DICOM files so it's interesting to know more about them. "Horos" is a really good viewer if you want something for managing and viewing entire sets of such images, especially as it can create 3D visualizations of all the 2D slices which results in fun/creepy pictures of my brain to show off.

BuildTheRobots• 4 years ago

Only supported on OSX. I'd be interested if anyone can recommend something similar for Windows and/or Linux.

jphoward• 4 years ago

RadiAnt is OK - it's got a trial license model but when the license expires you can request an extension for free (big WinRAR energy). There's nothing as good as Horos that is similarly free and open source, sadly.

What you may prefer to do is use the excellent pydicom library for Python, which loads dicom files as numpy arrays, allowing you to convert to any other file format you fancy, whether that be image or video.

rjzzleep• 4 years ago

I use Ginkgo CAD on linux. Unfortunately a lot of good free DICOM viewers have become abandonware in Linux and shareware on OSX. Don't know about Windows.

fluidcruft7• 4 years ago

On Windows I use RadiAnt. It's not free software, but it is extremely good and not terribly expensive. It will even load and display DICOM out of zip files which is a killer feature.

It used to be that everyone used eFilm Workstation for like legal consulting etc. But eFilm decided to end that (probably because they couldn't figure out how to get it to migrate to high DPI screens and it wasn't a priority).

RadiAnt switched their sales model in a way that's very convenient for law firms to pay consultants. They can basically buy however many months are needed for the consultant.

pilotneko• 4 years ago

I would suggest ImageJ, which is a Java-based image processing program developed at the National Institutes of Health (NIH). It has a very low memory footprint, built-in support for most DICOM file formats, a ton of extensions, and (of course) cross-platform support.

As an added bonus, you can run it as a portable app.

antegamisou• 4 years ago

InVesalius

https://invesalius.github.io/

sbf501• 4 years ago

Every CDROM I've received after an MRI comes with a windows viewer on it. IN 2010 it was E Film Light, then DCSView, then DrayViewer, and today it is Radiant.

pehtis• 4 years ago

I'm using this one on macOS https://github.com/rordenlab/MRIcroGL It is available for linux too.

nick__m2• 4 years ago

I find https://www.slicer.org/ awesome once you get past the initial learning curve.

bick_nyers5• 4 years ago

Weasis is good on Linux

stronglikedan• 4 years ago

I recently had some imaging done as well, and they gave me a DVD with the images. Now I just have to find a DVD player.

zegerius• 4 years ago

Very interesting! I have been working with medical information standards for a while now. Recently, I took an interest in DICOM and ways to modernize it. For example by introducing streaming, caching, moving metadata to a FHIR ImagingStudy resource.

To me, specifically streaming and caching strategies to move the load of (often hopelessly legacy) hospital infrastructure are an interesting challenge.

lostlogin2• 4 years ago

Whatever issues exist within DICOM are dwarfed by HL7 hell, and the point where the two specs meet can by awful.

Between HL7 and vendors doing custom things with HL7 and DICOM, IT support in healthcare is always going to be desperately needed.

notorandit2• 4 years ago

I still wonder how can DICOM be any better than PNG... But that is supposedly due to my ignorance.

an1sotropy• 4 years ago

The information in a DICOM file is a huge huge superset of the information you'd typically find in a PNG, because the amount of metadata you want to tie to a medical image is enormous (e.g. what day, what scanner, which scan, which part of which scan, which radiology tech, which doctor, which patient, with which contrast agent, in what orientation). Even if you did contrive a way to pack that metadata into a PNG file (which is possible), you'd still need a way to unambiguously interpret all that metadata, and know that everything else in the healthcare world is going to interpret it the same way. That's one of the things that the DICOM standard covers.

notorandit2• 4 years ago

As you said, it is nothing you cannot put into a PNG metadata. Unambiguously? It is all about standard definition. XML, JSON, CSV, excel sheet...

chadcmulligan• 4 years ago

DICOM is a lot older than PNG, you can embed multiple images in a DICOM file using different formats - losless and lossy, formats like jpg, tiff and so on. It also includes a bunch of tags that describe the image, patient information, scanner it came from and so on.

randomh3r03• 4 years ago

It also goes well beyond just talking about the imagery itself or the metadata surrounding it, and the standard contains its own network protocol effectively for transmitting data between PACS systems and other endpoints. (I recently worked in medical imaging for over 6 years and know DICOM fairly well, warts and all).

That said, there are absolutely better ways of handling almost any of the cases DICOM supports, the issue is that there is almost no standard that is fully backwards compatible which supports everything DICOM does, so we're sorta shackled to it for better or worse. Otherwise you have to deal with trying to explain to underfunded clinics (not the Mayo or Cleveland type) around the world why their expensive machine that they bought second or third hand is no longer acceptable.

bick_nyers5• 4 years ago

PNG coupled with a JSON can do almost anything that DICOM can do. DICOM can also do video and is starting to dabble in waveform data, but MP4 and SVG exist.

fluidcruft7• 4 years ago

DICOM supports MP4 (and HVEC/H.265, various flavors of JPG, and various other encoders, etc). I don't think PNG is supported, though and I'm not entire certain why but possibly it's a licensing issue. DICOM objects are basically just generic containers.

mhalle• 4 years ago

DICOM is a standard for medical imaging, and the patient data related to it, supported by every medical imaging device manufacturer.

JSON is a data format, it isn't in itself a standard for any content in particular, particularly medical imaging content. Think schema, not encoding (and in fact there is a JSON encoding for DICOM).

kaibee• 4 years ago

The standard includes a file format definition and a network communications protocol that uses TCP/IP to communicate between systems.

Is this as cursed as it sounds?

haolez• 4 years ago

It's fully binary and is document as a Lisp, as far as I remember. It's very nightmarish, but it's from the 80s, so it has its merits for staying for so long.

danielheath3• 4 years ago

The file format is reasonably cursed (header fields to indicate endian-ness, multiple internal metadata tables, and it's a container format so you can encode the image data using any one of 6-8 codecs - or just include a link to the TCP stream).

I haven't used the network protocol, but having some way to only bring the required pixel data across the network is pretty important - uncompressed CT scans are often hundreds of megabytes and the standard was developed before ethernet was widespread.

evulhotdog2• 4 years ago

A standard uncompressed CT slice is ~512kb, so multiply that by the number of slices. Angiograms tend to be much larger as well.

quasarj3• 4 years ago

Yes.

skywal_l• 4 years ago

You might be interested in a series of articles dealing with the multi planar rendering algorithm (starts at part 2): http://site.novidee.com/blog/blog-entry.html?article=2020091...

How to render an MPR image (an arbitrary slice of 3D data volume) from scratch starting from the bare DICOM files.

vladsiv6• 4 years ago

Thanks! This is great, I'll definitely check it out in-depth.

golf_mike• 4 years ago

For those who like to experiment a little, I can recommend firing up a jupyter notebook and explore the image data using pydicom and plotting it via matplotlib (or whatever plotting lib you fancy). For most CT and MRI data you will have a volume/voxels available and its pretty fun to slice'n dice your way through it by using list slices. Also all other data is available to inspect.

mcluck2• 4 years ago

DICOM is a fun format to tinker with. The absolute basics of it are simple enough that I wrote a DICOM viewer in college for a class. All of the extensions mean you can get some really interesting data as well. The various number of attributes and unusual combinations make it a real pain if you're trying to implement it all from the ground up but I'd highly recommend anyone play with it.

thfuran3• 4 years ago

The DICOM standard document is like 6,000 pages and I've never heard anyone call it "fun".

mcluck2• 4 years ago

Like I said, implementing the entire thing is a huge pain but doing the bare minimum to visualize CTs is a lot of fun

ml_giant• 4 years ago

There is also a file format called DICOS which is based off of DICOM which is used by the TSA and various inspection systems:

https://www.nema.org/directory/nema-councils/imaging-and-com...

If you've gone through security at a U.S. airport, the scanners use DICOS format to save scans of your baggage. Someone correct me if I am wrong though - it's possible only a subset of these machines use DICOS, I am not 100% sure.

vladsiv6• 4 years ago

Yes, I remember stumbling upon DICOS when I researched DICOM. Quite interesting application of the standard!

SubiculumCode• 4 years ago

I always convert dicoms to nifti format. Is there any advantage not to??

queuebert2• 4 years ago

I have a funny (or sad, really) DICOM story. I wrote my own DICOM parser in Rust, and I kept encountering a bug where the parsing would fail on a small subset of files in my database.

What you need to know is that DICOM tags have 16-bit group and element values that uniquely identify what the tag contains, and tags that begin with the group 0xfffe are very special, comprising a small set of field delimiters.

Well, the brilliant minds at Codonics decided to use the special group 0xfffe for their private, vendor-specific fields at the end of the file. When parsing a file those private fields would look like delimiters and ruin the logic.

So because of that one particular vendor, I have to check both the group and element of every special tag in every file I parse to make sure it isn't one of their special ones. Whereas, if they had followed the standard, I would only need to check the groups for the value 0xfffe. Thanks, guys!

quasarj3• 4 years ago

Would love to see your Rust parser

randlet• 4 years ago

Things are improving, but non-conformity to the DICOM spec by some vendors is quite common. I regularly encounter DICOM files that don't even have the 128byte preamble or 4byte `DICM` prefix.

rurban• 4 years ago

Thanks for the pedicom hack tip, I was not aware of it. Will add a check against the DOS-Header (4d 5a 90 00) magic immediately.

https://github.com/d00rt/pedicom

etaioinshrdlu• 4 years ago

The amount of redundant scientific/medical/industrial image file formats is amazing. Just off the top of my head there is DICOM, FITS, NIFTI, NRRD, plus TIFF.

They all have the basic property of having raster data of arbitrary channels/depth plus a whole bunch of metadata.

It feels like every new industry I work with I discover they have their own redundant image format.

quasarj3• 4 years ago

Yep. Quit making new ones!

Dicom File Format Basics

Related Stories