suyashkumar

Thanks for the kind words! I will definitely check out wolfpacs.

As for your question: I've run into a couple scenarios that require "lookback" into the parsed Dataset to parse correctly. For example, parsing Native PixelData correctly requires looking back for the Rows Element, Cols element, BitsAllocated element, etc in order to correctly parse the NativePixel data. The futzy thing is that these context "elements" need to come from the current Sequence (if parsing within a sequence). So, I do most of my parsing of sequences recursively, with each recursive frame holding pointers to the already parsed elements in this sequence (it's a stack essentially for nested sequences).

Not sure if that answers your question? For most generic elements though, as a parsing library I try to parse it generically and make the value payload available to the caller in case they need to apply any special logic to interpreting it. Though if you have a specific usecase that needs something that is missing here, please let me know or open an issue :).

You may be able to find some longitudinal data sets at The Cancer Imaging Archive: https://www.cancerimagingarchive.net/ (some are also already preloaded into Google Cloud buckets: https://cloud.google.com/healthcare/docs/resources/public-da...)

Indeed, there are some good sources of public, deidentified medical images released under various generally permissive licenses.

I've found The Cancer Imaging Archive to be very useful in this regard: https://www.cancerimagingarchive.net/ (some are also already preloaded into Google Cloud buckets: https://cloud.google.com/healthcare/docs/resources/public-da...

Thanks!

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

Great work as always!

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!

Thanks! Totally open to suggestions or contribs!

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

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

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

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!

A simple, single-command SSL/TLS reverse proxy in Go for fun. Handy in a pinch when running jupyter notebooks (usually self-signed certs) or other services I want to slap SSL/TLS onto. Got tired of apache/nginx configs and of minting self-signed certs on my own.