[POLL] Fill out this form to tell us how you're using this repo!

[suyashkumar]

TL;DR: Please fill out this short form here

or comment here and let us know your use cases and if you're using this for research, and if there are any features you might want!

[wkoszek]

All right. Let me be the first one. We're using it at Segmed.ai. You've done a great job supporting this stuff, for which we are grateful.

We use it to process dozens of GBs of DICOMs a day. We use it because Golang's libraries for doing everything else are so fast and rich, it brings us a great flexibility to stay in Golang ecosystem for data processing, and I can parallelize Golang programs easily, when necessary.

We'd love to see how many GBs of DICOMs can one pipe through your library without getting any errors. The idea I have is to grab all DICOMs that are available and try to build a test-suite. It'd be awesome to see your library being able to handle all DICOMs out there.

As for feature requests: docs + examples would be great.

If you want to go ahead of curve, I'd look at pydicom requests for new features, and just implement those in your library.

[suyashkumar]

@wkoszek thanks for the comments, kind words, and suggestions!

Great to hear you all are using the library extensively! I'd love to build an extensive test library of DICOMs to periodically test against--I don't doubt that there are DICOMs out there that will trip up this parser (and others), given the extreme variability and non-standard quirks found in DICOMs. Either way, that will be a great way to triage additional features to build to address various quirks that exist out there.

Would you be interested in helping collect or contribute such a test set?

I think this would also be a great canonical set of dicoms to test any library against once put together (I haven't been able to find a good test set, just a couple small collections here and there).

Also, I was in the process of a ground up rewrite at the s/1.0-rewrite branch, and will probably return to that soon. This way, it'll be easier to change certain design decisions inherited from upstream. If you have any feature requests, feel free to open issues and tag them as "enhancements."

:)

[wkoszek]

@suyashkumar We'd be interested in providing samples and helping with the repository. Do you think joining/ask dicomstandard.org folks would be useful for this? On Segmed's side, I could run Codify for us https://github.com/pydicom/pydicom/blob/master/pydicom/util/codify.py, edit files for privacy, and get us useful test vectors. Better tool would also fill PixelData with some made-up gradient.

Because our pipeline is in Golang, I'd love to use your library to write the tool. Do we have enough API to assemble a synthetic DICOM right now?

Example of an Xray I stumbled upon this week, which caused us problem is a one with charset:

ds.SpecificCharacterSet = 'ISO_IR 6'

I could hack something to make it easier to contribute a file to a public view.

[DanielHeath]

I'm evaluating it for use on radiopaedia.org - hoping to have a prototype of "quite fast" image extraction from dicom files working soon.

It's looking promising, though the sheer variety of dicom formats ensures I'll have plenty of bugs to investigate.

https://github.com/cornerstonejs/cornerstoneWADOImageLoader/blob/00cf0419c98c6bddef121d4409c8a2a9d780f336/src/shared/decodeImageFrame.js looks like a good reference for the dizzying array of ways a jpeg could be hiding in your data...

[suyashkumar]

@DanielHeath hi! That's really exciting, I'd love to help out however I can.

Indeed, JPEG can be annoying in DICOMs. We should support anything the Go stdlib can decode. Which sadly, does not include lossless JPEG (here's the open issue on that one: #85). If you're interested in working together on writing a lossless JPEG decoder in native Go, let me know. That's something I've been toying around with doing myself at some point, though I'm going to be rather busy at work for the next month or so.

Please let me know how I can help--or let me know what you're looking for. Pretty glad that we have several users of the library in production, but of course if there are some features missing that you need it would be great to know so we can prioritze. We welcome contributions, so you are welcome to start to get involved if you'd like!

[wkoszek]

@suyashkumar We had some loseless JPEG. We'd like to participate in that effort. Do you have any ANSI C reference implementations for this? Last time I looked, there was something called "Jasper JPEG" that had some code for doing loseless JPEG.