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

[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!

[kspacewalk]

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

[suyashkumar]

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

[avip]

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

[carbocation]

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