Dicom File Format Basics(vladsiv.com)
vladsiv.com
Dicom File Format Basics
https://www.vladsiv.com/dicom-file-format-basics/
89 comments
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.
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.
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.
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.
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/
[1] https://sourceforge.net/projects/amide/
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.
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.
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.
That said, I was in IT before I got my MD.
What your preference, and do you like https://www.slicer.org/ ?
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).
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.
> 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.
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.
> 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.
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.
> 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.
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.
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).
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).
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
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
You needed to bring a free DICOM viewer and have her install it ;-)
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.
Weasis is good on Linux
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.
Only supported on OSX. I'd be interested if anyone can recommend something similar for Windows and/or Linux.
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.
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.
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.
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.
A complex/overkill but open source approach on Windows is to install Orthanc and use the new webassembly viewer. But it's not as fast/good as RadiAnt and it's certainly nothing next to OsiriX.
https://www.orthanc-server.com/static.php?page=stone-web-vie...
https://www.orthanc-server.com/static.php?page=stone-web-vie...
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.
As an added bonus, you can run it as a portable app.
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.
It's similar on Windows. Part of the problem is that access to DICOM images is a major barrier. OsiriX happened because OS X didn't have a viewer. The "eFilm Workstation" crowd moved to OsiriX. It's complex but eFilm used to be pretty good but they couldn't add features and fix bugs fast enough. And then they couldn't make high DPI work. In the mean time, OsiriX was very nice looking and adaptable for radiologists who like to tinker. Radiologists can be extremely picky and demanding about UI and efficiency and OsiriX served that well. Not to mention that OSX brought all the linux research packages. So, they all just bought Macs and left eFilm behind for OsiriX particularly after it obtained FDA/EC clearance.
OsiriX is a great and bad viewer that made life easier and cheaper for lots of radiologists and doctor (although not cheap enough for some countries)
The bad part: OsiriX was LGPL for a while, but they began to mix it with closed binaries. I reported some inconsistencies on the license in their mailing list, they moderated me, and some time later stopped publishing source. That's were Horos started growing.
The bad part: OsiriX was LGPL for a while, but they began to mix it with closed binaries. I reported some inconsistencies on the license in their mailing list, they moderated me, and some time later stopped publishing source. That's were Horos started growing.
I have always avoided OsiriX, but at my new job it's used a lot in the image processing lab (that I help support). I want to build/provide some simple QA utilities for the people who do use OsiriX, but I'm a physicist and I can't justify buying that MD license to tinker with and that damn timeout nag bullshit is not something I will waste my time on. I can't even tell how compatible Horos is with OsiriX or if it's maintained anymore. If I knew that plugins developed for Horos would work on OsiriX I might consider that "ecosystem" but as is it's not worth the effort to me. I barely tolerate OS X.
Ginkgo CADx was a project by a Spanish company giving services to public and private health services, but they dissolved some years ago, and seems like nobody took the maintenance.
InVesalius
https://invesalius.github.io/
https://invesalius.github.io/
Oh, nice! Somehow I had missed this one and was wondering why nobody had created a cross-platform python viewer that's simpler than slicer. I'll check it out!
https://github.com/invesalius/invesalius3
https://github.com/invesalius/invesalius3
Developer here. If you are going to use in Linux, I recommend you to install it using flatpak.
I'm using this one on macOS https://github.com/rordenlab/MRIcroGL
It is available for linux too.
I find https://www.slicer.org/ awesome once you get past the initial learning curve.
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.
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.
Dicom Compliance is a well paying job.
> 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.
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.
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.
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).
Source: I wrote the DICOM viewer & anonymizer for Radiopaedia (okay, most of the heavy lifting is done by cornerstone.js).
For certain definitions of "just fine". Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag—and even sometimes put different values in the two, with the private tag being correct.
> Some manufacturers will use a private tag to hold the same information that's meant to be in a standard tag...
Agree! Also some applications have "special" features that rely on data stored in private tags which, of course, you don't have any idea how to use.
Agree! Also some applications have "special" features that rely on data stored in private tags which, of course, you don't have any idea how to use.
Viewer of what? Dicom can contain other things than just nD imagery.
Also, the difficulty in my experience is the getting data back in part; getting data out is usually a lot easier (you don't need to care about those tags).
Also, the difficulty in my experience is the getting data back in part; getting data out is usually a lot easier (you don't need to care about those tags).
I had a good snicker at the "Basics" in the title for exactly this reason!
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.
How to render an MPR image (an arbitrary slice of 3D data volume) from scratch starting from the bare DICOM files.
Thanks! This is great, I'll definitely check it out in-depth.
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:
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.
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.
Yes, I remember stumbling upon DICOS when I researched DICOM. Quite interesting application of the standard!
> 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?
Is this as cursed as it sounds?
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.
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.
A standard uncompressed CT slice is ~512kb, so multiply that by the number of slices. Angiograms tend to be much larger as well.
I'm starting to see 1000-slice scans more often, but I hear 100-400 was more common back when size was a pressing concern.
Apparently you haven’t seen what the Toshibas/Canons can pump out. Some can be 6000 slices or more.
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.
Yes.
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.
To me, specifically streaming and caching strategies to move the load of (often hopelessly legacy) hospital infrastructure are an interesting challenge.
To me, specifically streaming and caching strategies to move the load of (often hopelessly legacy) hospital infrastructure are an interesting challenge.
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.
Between HL7 and vendors doing custom things with HL7 and DICOM, IT support in healthcare is always going to be desperately needed.
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.
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.
Yep. Quit making new ones!
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!
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!
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
https://github.com/d00rt/pedicom
I still wonder how can DICOM be any better than PNG...
But that is supposedly due to my ignorance.
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.
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...
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.
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.
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.
In your professional opinion:
Is there any need or demand for a decent Java language DICOM parsing library?
Mid-aughts, I wrote a DICOM image viewing applet. (Before tile-servers a la Google Maps, which would have been a better strategy.) My library could read DICOM filestores. But not do network interchange.
DICOM applet was intended to be part of our EMR web client, our frontend to showcase our portable electronic medical records backend stuff. At the time, it was an amazing demo, greatly helping our Sales team.
My code (IP) got lost, abandoned. (Acquisition, abandonment, high mgmt turnover, etc. Typical M&A story.) So sad. Anyone who'd know or remember what my code did is long gone.
--
Ditto my HL7 2.x and 3.x libraries, FWIW. I wrote my stuff in response to the available tools at the time. SeeBeyond ICAN/JCAPS, Mirth, BizTalk, a bunch of others I now forget. Turrible. I'm out of the field, so I imagine the world's moved on. FHIR and whatnot.
Is there any need or demand for a decent Java language DICOM parsing library?
Mid-aughts, I wrote a DICOM image viewing applet. (Before tile-servers a la Google Maps, which would have been a better strategy.) My library could read DICOM filestores. But not do network interchange.
DICOM applet was intended to be part of our EMR web client, our frontend to showcase our portable electronic medical records backend stuff. At the time, it was an amazing demo, greatly helping our Sales team.
My code (IP) got lost, abandoned. (Acquisition, abandonment, high mgmt turnover, etc. Typical M&A story.) So sad. Anyone who'd know or remember what my code did is long gone.
--
Ditto my HL7 2.x and 3.x libraries, FWIW. I wrote my stuff in response to the available tools at the time. SeeBeyond ICAN/JCAPS, Mirth, BizTalk, a bunch of others I now forget. Turrible. I'm out of the field, so I imagine the world's moved on. FHIR and whatnot.
We lived predominantly in the .NET world and leveraged Fellow Oak Dicom pretty heavily, but when I did have to use anything in Java-land we pretty much always leveraged dcm4che, as it did what we needed and we didn't need to monkey with it much. Ultimately given my ignorance of that ecosystem I'd be hard pressed to advise about the need or demand in Java one way or the other unfortunately. Sorry about that!
You made me shudder by mentioning BizTalk just now, though. I had long since shut that way in the corners of my mind.
You made me shudder by mentioning BizTalk just now, though. I had long since shut that way in the corners of my mind.
Thanks for the feedback.
Ya, with all the ETL work I've done, I've been cured of any interest in visual programming, "no-code", and the latest iteration of CASE tools in general.
Aside from all the BizTalk specific heartache...
With patch-cord programming, you always have to drop down to actual code for that last 5% of work, the fit & finish. Then you're fighting the framework (tool).
Better to have an API that's easy and bulletproof. My solution for HL7 "interface" implementations was to ingest the specifications (authored by our customer facing business analysts) and output Java source code. Then use any IDE (tool stack) to proceed as normal for that last 5%.
We'd onboard new teammates (to do "HL7 interfaces"), most who had never seen Java before, in about 2 weeks. At the time, the assumption was onboarding to ICAN (or equiv) would take about 3 months. (Yikes.)
I was always interested in playing with C# and LINQ for our work. But none those sales leads panned out.
Ya, with all the ETL work I've done, I've been cured of any interest in visual programming, "no-code", and the latest iteration of CASE tools in general.
Aside from all the BizTalk specific heartache...
With patch-cord programming, you always have to drop down to actual code for that last 5% of work, the fit & finish. Then you're fighting the framework (tool).
Better to have an API that's easy and bulletproof. My solution for HL7 "interface" implementations was to ingest the specifications (authored by our customer facing business analysts) and output Java source code. Then use any IDE (tool stack) to proceed as normal for that last 5%.
We'd onboard new teammates (to do "HL7 interfaces"), most who had never seen Java before, in about 2 weeks. At the time, the assumption was onboarding to ICAN (or equiv) would take about 3 months. (Yikes.)
I was always interested in playing with C# and LINQ for our work. But none those sales leads panned out.
>Is there any need or demand for a decent Java language DICOM parsing library?
Dcm4che is that, though perhaps there could be some debate as to whether it's decent. I don't know; I'm stuck using quite an old version.
Dcm4che is that, though perhaps there could be some debate as to whether it's decent. I don't know; I'm stuck using quite an old version.
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.
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).
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).
Yup, the way you interpret the JSON or DICOM matters.
In DICOM, the interpretation of the data is coupled with a specific file format, when it doesn't need to be.
We want window leveling to work the same way across the board, but whether you transmit the width, center, and algorithm (linear, sigmoid, etc.) in a DCM file or in JSON or in carrier pigeon doesn't particularly matter so long as the receiver can interpret it.
Would it be better if all modality manufacturers started sending JSON? Probably not, however manufacturers produce non-compliant DICOM ALL THE TIME so there's still an issue there with complexity and lack of strong testing tools for the standard.
In DICOM, the interpretation of the data is coupled with a specific file format, when it doesn't need to be.
We want window leveling to work the same way across the board, but whether you transmit the width, center, and algorithm (linear, sigmoid, etc.) in a DCM file or in JSON or in carrier pigeon doesn't particularly matter so long as the receiver can interpret it.
Would it be better if all modality manufacturers started sending JSON? Probably not, however manufacturers produce non-compliant DICOM ALL THE TIME so there's still an issue there with complexity and lack of strong testing tools for the standard.
*supported by every medical imaging device manufacturer going back something like 3+ decades.
This is much less of a problem of shiny-object-syndrome not providing a "better" way of solving the problem(s) and much more one of market inertia, IMO. Many people overlook this.
This is much less of a problem of shiny-object-syndrome not providing a "better" way of solving the problem(s) and much more one of market inertia, IMO. Many people overlook this.
Especially considering that medical information can often need review decades later. Can't just support the new stuff, you need to support the priors that were rendered in the pre-2000s as well.
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.
There’s probably multiple reasons why DICOM does not support PNG. Most compression formats in DICOM are those published as official standards in the JPEG family from ISO.
The original JPEG from ‘92 already included a Lossless mode which supports 16/12/8 bit color and monochrome and is very fast to encode and decode. All of those were important features.
Adding PNG later would not benefit anyone: it can not handle all of these usecases, it is usually slower and it came later.
You are correct, DICOM does not support PNG:
https://dicomlibrary.com/dicom/transfer-syntax/
https://dicomlibrary.com/dicom/transfer-syntax/
I always convert dicoms to nifti format. Is there any advantage not to??
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.