Congratulation. Great work. It is such an ancient but important standard.
I just spent around one year writing Wolfpacs, a dicom load balancer in pure Erlang. (In my spare time).
Question: what is your take on the headers that are "undecided"? For example,the headers that have either signed short (ss) or unsigned short (us) value representation. Most of the parsing is "stateless" but a few headers require "rules". "If previous headers X is Y then VR=OW". I wished they could have made the standard better in that regard.
Thanks for the kind words! I will definitely check out wolfpacs.
As for your question: I've run into a couple scenarios that require "lookback" into the parsed Dataset to parse correctly. For example, parsing Native PixelData correctly requires looking back for the Rows Element, Cols element, BitsAllocated element, etc in order to correctly parse the NativePixel data. The futzy thing is that these context "elements" need to come from the current Sequence (if parsing within a sequence). So, I do most of my parsing of sequences recursively, with each recursive frame holding pointers to the already parsed elements in this sequence (it's a stack essentially for nested sequences).
Not sure if that answers your question? For most generic elements though, as a parsing library I try to parse it generically and make the value payload available to the caller in case they need to apply any special logic to interpreting it. Though if you have a specific usecase that needs something that is missing here, please let me know or open an issue :).
Imagine that you have AI solution that do some calculations (e.g, stoke, bleeding in the brain). Often the calculations are very heavy and if you have a lot of data coming in you need to spread the load.
In dicom, a brain scan almost always span many, many dicom files. So when you push over one series, it can contain N images. Which means that there are N transactions to the server.
You cannot simply round-robin the load because all dicom files that belongs to the same series (study) must end up on the same worker.
So the goal of WolfPACS is to inspect the DICOM headers as they files come in, and route the files depending on the StudyUID and Calling AE.
So it is possible to associate certain workers with certain clients. So how a worker is picked is very flexible. Maybe you want to do some A/B testing. Or you want to take a worker offline "softly".
Unrelated: I’m trying to locate or acquire some X-ray or mri scans showing the progression or regression of various diseases( cancer etc) or even broken bones healing. But they need to be of a single patient for the purpose of comparing image sets. Any pointers on where this sort of anonymous data might be?
are there publicly available datasets of dicom images?
my fathers a retired radiologists and ive wondered if making an app that could display images would potentially stave off any cognitive decline in the future.
Medical imaging, like everything medical, nuclear, and military, has somewhat high barriers to entry due to legal requirements, eg getting sued b/c of the proverbial amputation of the wrong leg due to flipped display. Also, from my limited experience in the field, software for radiology workflows and archival, viewing workstations etc. are often expected as part of a deal for the imaging devices (X ray, MRT, etc.) themselves rather than as separate products.
They have high barriers to "marketing." But if you find a radiologist who wants to work with you, using your software, that's their discretion, as long as you don't make "claims" about its efficacy for use. The way to Cover Your Assets is to have them use your software first, then REDO the read on another system marketed for the job. If they come up with a different set of results, you have work to do.
Any idea how one could anonymize their dicom images? I have a disk of a CT Scan of my skull laying around but my medical information seem to be strongly linked to it (opening it in an online viewer displays my name, id, etc.) If it wasn't for that fact, I'd love to be able to upload it somewhere and help science.
I wrote a DICOM parser in Go for the Kaggle competition in 2017, and it was such a pain. It probably only worked for that sample so I never released it but this looks great. Thanks for sharing!
I use MIPAV[1] which can run on Linux (or any OS with a new enough Java Runtime Environment). I don’t have a lot of experience with other DICOM viewers and have somewhat limited use cases for it, but it seems to have a good number of features.
It’s completely free, but accessing the download (or the source) requires (free) registration.[2] Filling out the form should take you straight to the download links (i.e. you should not have to wait for a manual approval to download).
Ginkgo CADx evolved quickly for a while some years ago (while it was partly funded by the Spanish government and developed by a private company), but that project and company closed. The code was released as open source and it gets some commits every once in a while by volunteers.
It has a weird UX/UI, but it might be enough for you.
I just spent around one year writing Wolfpacs, a dicom load balancer in pure Erlang. (In my spare time).
Question: what is your take on the headers that are "undecided"? For example,the headers that have either signed short (ss) or unsigned short (us) value representation. Most of the parsing is "stateless" but a few headers require "rules". "If previous headers X is Y then VR=OW". I wished they could have made the standard better in that regard.