Are you using DICOM-rs? Share your story here!

[Enet4]

I would like to use this thread to survey the users of DICOM-rs and know what people are using DICOM-rs for, in which scenarios, and how the experience was overall. This may also help the project gain further traction and define priorities for upcoming work.

If you are using or have used DICOM-rs at some point, your comment here is much appreciated!

[troelsarvin]

I've used dicom-rs to write a console application which I would normally have tried using Python or bash for: I had a huge number of DICOM files, and I needed check, if their SOPs existed in a PACS. The PACS could be queried by SIUID and return a list of SOP UIDs, but it could not be queried at a SOP instance level. So I made use of the fact that dirom-rs is so effecient: It wan't a problem to query the PACS at a study level and then cache the responses. All in all, I believe the tool is much, much faster than what I could have hammered together in Python or bash.

[jennydaman]

Our research activities at the FNNDSC of the Boston Children's Hospital involve pulling images from a PACS server and into our containerized software platform, ChRIS. Previously, we used storescp with an instance handler written in Python called pypx. The spawning of a Python process per DICOM instance was very inefficient: pulling a single series would max out all 40 cores of our server.

I am currently working on a rewrite of the instance handler in Rust using dicom-rs. The Rust implementation is, depending on how you measure it (by elapsed time, CPU time i.e. efficiency, memory usage, ...), 100-1000x more efficient than the Python implementation when called per-instance. The speed exceeds the rate at which storescp receives DICOM instances, hence there is no build-up of resource usage. An amusing statistic is that the Rust program is faster and uses less memory than it takes for the Python interpreter to do literally nothing (python -c '').

I am impressed by the design of dicom-rs and I am finding its API very easy to use. Thank you @Enet4!

https://github.com/FNNDSC/pypx-listener

[Enet4]

That's an impressive improvement! Thank you for sharing!

[PierreBou91]

I was looking to learn a new programming language and push my understanding of the dicom standard. Dicom-rs is the perfect library for me to do so:

1. Fully open source
2. Actively and well maintained
3. Early enough so that the code is still understandable and well documented.
4. Mature enough for me to be confident that I could use it in production.

After some learning experiments, I was happy to be able make a very small contribution with your guidance (hopefully I'll soon find other issue that are easy enough for me to help with!).

My biggest project so far is a client to use an API developed by my company (Milvue) . The API allows to send an x-ray and get a AI annotated image (pathology detection and anatomical measurements).
Now :

1. My support team can easily test a production exam on several environments to better debug.
2. My product team can send 100s of exams at a time and get results for several configurations in 2minutes instead of doing it manually in more than an hour
3. My operation team can send big datasets for analysis for a client that is willing to test the solution in a few minutes also (where it always took us a long time).

Now I'm messing around with the dicom web standard, I'd like to build an abstraction on top of the http crates to allow for an easy deployment of a compliant dicomweb server or convenient methods for a dicomweb client.

All of this is, and was, only possible thanks to dicom-rs!

[Enet4]

This is great! Thank you for showing your confidence in the project!

The upcoming dicom-json crate might be of use to you when bringing DICOM data to the Web.
In the meantime, I will continue filing issues and labelling the easier ones with good-first-issue, precisely to foster external contributions and increase author commitment.