Show HN: DICOM Medical Image Parser in Go | Hacker News Reader

Show HN: DICOM Medical Image Parser in Go

github.com

142 pointssuyashkumar36 comments

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?

Quick glance at the source repo shows all the familiar symptoms of an abandoned project.

I believe this is the person who created the source repo when he was working with the company that owns the source repo.

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...

Where would you use the functionality of converting DICOM into protocol buffers?

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).

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.

Of course, and sweet thanks! Open to ideas and contribs as well!

I use this and it's great!

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!

Exciting! I'll have to take a look at the new interface. Thanks!

This (https://github.com/suyashkumar/dicom) ... is a fork of this (https://github.com/gradienthealth/dicom) ... which is a fork of this (https://github.com/gillesdemey/go-dicom) ... which inturn depends on other open sources (https://github.com/ivmartel/dwv/ and https://github.com/cornerstonejs/dicomParser)

I always wonder, what happens to an upstream source if one of the downstream guy loses interest.

Nice library! Added here https://github.com/kakoni/awesome-healthcare

Thanks!

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?

On GitHub click the tags for this project. You can observe other projects' pages, docs, and code to learn more.

At a past company, we used https://brainbrowser.cbrain.mcgill.ca, which may come in help to you.

Full disclosure: I am the CEO of Innolitics, a development firm that specializes in medical imaging applications.

The most authoritative source on DICOM is the free standard:

https://www.dicomstandard.org/current/

It is not particularly easy to read and thus not a great starting place.

The DICOM forum is a good place to ask questions:

https://groups.google.com/forum/#!forum/comp.protocols.dicom

David Clunie, a very nice guy and the editor of the DICOM standard, is active on this forum. He also has is own website that has many other links:

https://www.dclunie.com

If you are interested in parsing or generating DICOM files, our DICOM standard browser is a great resource:

https://dicom.innolitics.com/ciods

I also wrote a very brief article about DICOM, which was meant to be the first in a series of articles, but alas I have been to busy to continue them:

https://innolitics.com/articles/dicom-i-facilitating-interop...

Oh, and here is a pretty good blog about DICOM:

http://dicomiseasy.blogspot.com

Checkout his "DICOM Tutorial" in the sidebar.

If you have any particular questions about DICOM, message me and I would be happy to try and answer them.

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:

https://innolitics.com/img/dicom-file-upload.png

Edit: make it clear the files are not uploaded to any server, but stay within the browser

Great work as always!

I use your DICOM standard browser routinely. Thanks for maintaining it.

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.

Thanks! Lots to learn here.

likewise, I'm a huge fan of innolitics and their dicom browser. It's awesome and has helped me a lot!

I use Innolitics's DICOM browser for looking up tags every day. :) Thank you :)

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).

[0]: https://www.springer.com/gp/book/9783642108495

I've always found this book to be a good starting place: https://www.amazon.com/Digital-Imaging-Communications-Medici...

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!

Go v1.11+ compiles to WebAssembly https://github.com/golang/go/wiki/WebAssembly

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.

[0] https://www.sqlite.org/appfileformat.html

Cool! I haven't worked in the medical field in a while but it's always nice to see more DICOM libraries.

Thanks! Totally open to suggestions or contribs!

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

What does "parsing" mean in the context of images?

Reply on news.ycombinator.com