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...
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?
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
[+] [-] jacquesm|6 years ago|reply
Is there anything known about the reason for a fork rather than contributing back to the original?
[+] [-] suyashkumar|6 years ago|reply
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...
[+] [-] avip|6 years ago|reply
[+] [-] carbocation|6 years ago|reply
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|6 years ago|reply
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!
[+] [-] samdung|6 years ago|reply
I always wonder, what happens to an upstream source if one of the downstream guy loses interest.
[+] [-] kakoni|6 years ago|reply
[+] [-] suyashkumar|6 years ago|reply
[+] [-] danielecook|6 years ago|reply
[+] [-] jdgiese|6 years ago|reply
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.
[+] [-] tpfour|6 years ago|reply
[0]: https://www.springer.com/gp/book/9783642108495
[+] [-] CraftThatBlock|6 years ago|reply
[+] [-] aesh2Xa1|6 years ago|reply
[+] [-] ezarowny|6 years ago|reply
[+] [-] neandrake|6 years ago|reply
[+] [-] tzm|6 years ago|reply
[+] [-] suyashkumar|6 years ago|reply
[+] [-] test9753|6 years ago|reply
[0] https://www.sqlite.org/appfileformat.html
[+] [-] ezarowny|6 years ago|reply
[+] [-] suyashkumar|6 years ago|reply
[+] [-] olliej|6 years ago|reply
[+] [-] amelius|6 years ago|reply