Note that an 'image' for DICOM software can mean many things, from a collection of slices through a volume from an MRI scan to x-rays and ultrasound along with a whole pile of annotation and other meta data. DICOM is fairly complex and a good reference implementation of a parser in any language is a fantastic gift if it will be maintained long term.
Is there anything known about the reason for a fork rather than contributing back to the original?
Indeed, DICOM is a beast of a spec. Dicomtk is a solid reference implementation in C++ imo, but a bit difficult to work with sometimes.
The goal here is to have a featured implementation in Go that's easy to work with as a library and easy to iterate on and add new features on top of. This library unpacks most standard elements and metadata inside the dicom, in addition to multiple image frames that may be stored in the dicom in a variety of formats. More utils for normalizing and working with these images are coming soon! Also will be looking forward to dumping the dicom data into protocol buffers (that I also helped generate at github.com/gradienthealth/dicom-protos).
As for the forking--I did a lot of work on the parent fork (which isn't maintained anymore) and decided to introduce a lot of API breaking changes and opinionated new features on my actively maintained fork so decided to move ahead with a hard fork (with all the git history and credit maintained). You can see the original author's blessing here: https://www.reddit.com/r/golang/comments/bnu47l/high_perform...
Super, thank you for the detailed answer. I'll be sure to point a couple of companies to your repository, they may be able to contribute in various ways.
Perhaps sending structured slices of dicoms to downstream microservices (or clients), Tensorflow inputs, perhaps in other places too? Proto representations of data can be nice because they are super easy to unpack (way easier than a dicom directly) and offer language-native data containers to work with the data. But ultimately you could always just deal with the dicom, or store the data in some other representation (JSON, etc).
One thing that would be helpful (and perhaps it's already included and I just haven't seen it?) is a set of functions to make the parsed image appropriate for display.
Right now, the raw pixel values are given. To turn this into an image, you have to determine the word size (e.g., 16 bits), then interpret the results in the context of the window and center values from the metadata. For my current batch of images, for example, unless I do postprocessing, the images just look black.
Thanks! Indeed, right now if you're opening a DICOM with Native PixelData the API gives you the raw PixelData without manipulating (normalizing) it. This is so that you can apply WindowWith and WindowCenter settings to your choosing, should you want to (and sometimes, there are multiple window withs and centers to choose from in the metadata).
I recently introduced a CommonFrame interface that wraps both Native pixel data and encapsulated pixel data that gives you a clean Go stdlib image.Image to use for post processing (no matter the underlying data). Introducing some options to this that allows setting of window width and level would also make sense!
So I may be working with DICOMs in the very near future and know nothing about them. This seems like it will be helpful to me. Where can I learn more about the format and how to use it?
I've used the Innolitics standard browser in the past and can attest to this browser as a very helpful reference. Of the options available, this has been the most pleasant to work with while also linking to the spec. for that occasional deep dive.
Thank you for the kind words! We appreciate it, and it is nice to hear that people find it to be useful.
We just added a new feature yesterday---it is a new tab that allows you to analyze a DICOM file within the browser, see the values it contains, and easily cross check the tags with the standard. Any feedback would be welcome.
Here is a screenshot of the DICOM file analysis feature in action:
I'm glad to hear it is useful! Our mission at Innolitics is:
> To accelerate progress in medical imaging by sharing knowledge, creating tools, and providing quality services to our clients, with the ultimate purpose of improving patient health. We do so while providing meaningful, flexible, and financially rewarding careers to our team.
So it is nice to hear that, to some degree, we are accomplishing the "creating tools" part of this.
Please do let us know if you have ideas for improvements.
Read the standard. There truly is no way around it if you need to perform actual "real" work with DICOM. You need to become familiar with the vocabulary. Also get a copy of [0]. Write a small C program that outputs whether a file is in DICOM format or not (don't do extensive validation, but learn enough to know what to look for). Will you be doing networking? If so, read the standard. Use Wireshark. Look up the DUL state machine and read some library's net code (e.g. pynetdicom).
I work with DICOM pretty regularly and it's cool to see new implementations of parsers popping up. I've recently been toying with an implementation in rust with a goal of eventually compiling to web assembly. I've not learned golang but exploring this implementation is a fun experience since having recently been digging into the dicom standard.
Thanks, that sounds awesome. Rust seems like an interesting language, haven't really had the chance to dive too deep into it recently though. Go programs can also compile down to webassembly, so looking forward to playing with that as well!
I wonder if most of these older standards could be replaced by new standards that use SQLite as the Application File Format [0], making life easier for everyone.
Wow, kudos to them - I tried to write a Dicom parser many years ago (trying to look at an mri) and just gave up. The standard seemed to be one of those obtuse “standards” that just defined wrappers around proprietary blobs
Is there anything known about the reason for a fork rather than contributing back to the original?