Standalone runner

[etpeterson]

This code will be used in pipeline processing. It is currently called on each dataset individually. However, medical imaging software is often configured so images can be pushed to it and it then pushes the results onward in the chain. It would be useful for this to be wrapped in a way that it can be triggered with DICOM pushes, and the processed images are subsequently pushed onward.

DICOM pushes should be supported, but also nifti files, for example bids format, should also be supported. This could take the form of websocket or HTTP methods.

[Unique-Usman]

@etpeterson can you give more description on, I am hoping to work on it.

[etpeterson]

@Unique-Usman this is probably a multipart project and I wrote this up a while back so I wouldn't forget. Basically, what happens in hospitals is the images are created in DICOM format and pushed around using the c-store operation. It would be very convenient to be able to have a dicom listener running that accepts these pushes, then trigger the processing, then push the result somewhere else. It's much more complicated than that, but that's the basics.

I think it would make most sense as a docker image, but it could be a standalone program itself. Here's a list of projects that would have to be completed to make this work - roughly in order.

• Read medical images as either DICOM or NIFTI - essentially wrap the wrapper with a program the reads these files and send them in with appropriate options. NIFTI is already used somewhat in the phantoms so is probably easier. DICOM is the "standard" but much harder to work with. This is probably a 2 part project - support NIFTI first and then DICOM.
• Dockerize the code so that processing could be run from the command line, e.g. docker run <TF2.4image> <IVIM input images> <IVIM output images>
• Allow the docker container to receive DICOM image pushes and push the results back with a basic config file based configuration. The best DICOM library I know of is dcmtk and it has a server that can dump files to a folder for a start.
• Allow the docker container to communicate in NIFTI files. I'm not sure if this is natively possible, but perhaps an FTP server or websockets? I'm not sure this is truly necessary but might be useful.
• Allow basic configuration to happen. There could be a simple website to choose what IVIM algorithm to use, for example. But also some basic HTTP commands to change the defaults for one series or all might be a good start here.
• Intelligently handle resources. E.g. manage number of active threads and memory to optimize performance.

Almost surely I forgot something, but I think that largely outlines my thoughts. The goal is at the end to have a standalone container that can be integrated into processing pipelines with very little effort. I could create a new issue for some of the earlier ones with more detail if that still sounds interesting.

[Unique-Usman]

This sounds interesting. It also a big project. I think starting with the earlier ones seems interesting and I will like to work on it also. Thank you.

[etpeterson]

This sounds interesting. It also a big project. I think starting with the earlier ones seems interesting and I will like to work on it also. Thank you.

@Unique-Usman here's an issue I created for the first bullet if you want to tackle that one.

[Unique-Usman]

@etpeterson, thanks for the guidiance during the contribution. Can we move to the next line of action ?

[etpeterson]

@etpeterson, thanks for the guidiance during the contribution. Can we move to the next line of action ?

Sure! I created the next bullet point as a separate issue here.