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