
Show HN: DICOM Medical Image Parser in Go - suyashkumar
https://github.com/suyashkumar/dicom
======
jacquesm
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?

~~~
suyashkumar
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...](https://www.reddit.com/r/golang/comments/bnu47l/high_performance_dicom_medical_image_parser_in/en9hp6h?utm_source=share&utm_medium=web2x)

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

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

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

~~~
suyashkumar
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!

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

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

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

------
kakoni
Nice library! Added here [https://github.com/kakoni/awesome-
healthcare](https://github.com/kakoni/awesome-healthcare)

~~~
suyashkumar
Thanks!

------
danielecook
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?

~~~
jdgiese
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/](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](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](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](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...](https://innolitics.com/articles/dicom-i-facilitating-
interoperability/)

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

[http://dicomiseasy.blogspot.com](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.

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

~~~
jdgiese
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](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

~~~
suyashkumar
Great work as always!

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

~~~
tzm
Go v1.11+ compiles to WebAssembly
[https://github.com/golang/go/wiki/WebAssembly](https://github.com/golang/go/wiki/WebAssembly)

------
test9753
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](https://www.sqlite.org/appfileformat.html)

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

~~~
suyashkumar
Thanks! Totally open to suggestions or contribs!

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

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

