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.<p>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.<p>Had I brought the viewer, she would have probably launched the .exe with equally no hesitation.<p>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.
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.
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!).<p>Dicom Compliance is a well paying job.
You might be interested in a series of articles dealing with the multi planar rendering algorithm (starts at part 2): <a href="http://site.novidee.com/blog/blog-entry.html?article=20200912-from-DICOM-to-MPR-part2.html" rel="nofollow">http://site.novidee.com/blog/blog-entry.html?article=2020091...</a><p>How to render an MPR image (an arbitrary slice of 3D data volume) from scratch starting from the bare DICOM files.
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.
There is also a file format called DICOS which is based off of DICOM which is used by the TSA and various inspection systems:<p><a href="https://www.nema.org/directory/nema-councils/imaging-and-communications-council/dicosusa" rel="nofollow">https://www.nema.org/directory/nema-councils/imaging-and-com...</a><p>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.
> The standard includes a file format definition and a network communications protocol that uses TCP/IP to communicate between systems.<p>Is this as cursed as it sounds?
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.
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.<p>To me, specifically streaming and caching strategies to move the load of (often hopelessly legacy) hospital infrastructure are an interesting challenge.
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.<p>They all have the basic property of having raster data of arbitrary channels/depth plus a whole bunch of metadata.<p>It feels like every new industry I work with I discover they have their own redundant image format.
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.<p>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.<p>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.<p>So because of that one particular vendor, I have to check <i>both</i> 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!
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.<p><a href="https://github.com/d00rt/pedicom" rel="nofollow">https://github.com/d00rt/pedicom</a>
Very nicely written article. I guess that it is pleasant to read even if we don't have to work with the Dicom format.<p>The explanation of TLV could be interesting also in itself.