List of Containers and Commands

This page is a list of docker images and commands for the container service. Some of them are finished, and others are in some stage of design or progress.

Contributions to this page are very welcome. These can be in the form of links to published images / commands, proposals for future work, or comments. Edit the page directly on the wiki, or make a pull request to the markdown source document in the container service repo.


Title Author Docker Hub GitHub Notes
DICOM to NIFTI Flavin xnat/dcm2niix nrgxnat/docker-images/dcm2niix
DICOM to BIDS Flavin xnat/dcm2bids-session nrgxnat/docker-images/dcm2bids-session Convert a session full of DICOM files into NIFTI files with BIDS metadata. Store that metadata back to XNAT as resources in the way that the xnat2bids setup container expects.
XNAT Populate Charlie Moore greppy/xnat-populate nrgxnat/xnat-populate Meant for dev use only.
CONDR_METS lesion atlas Misha / Flavin Not published. 1. see note on NIL Tools. 2. This was built as a demo that relies on access to a non-public CNDA project.
niftyreg Flavin / Marc Modat Image not published nrgxnat/docker-images/niftyreg Developed during container hackathon at UCL. I was unsure whether to publish this image or not, so I did not.
BIDS MRIQC Flavin N/A nrgxnat/docker-images/bids-mriqc Not published as an image, only as a command. This fits the degin goal of the BIDS containers: use off-the-shelf BIDS docker images and write the command metadata to run them.

Setup Containers

As of Container Service 1.4.0, commands can request to launch a setup container to pre-process the files received from XNAT before they are mounted.

Title Author Docker Hub GitHub Notes
BIDS Setup Flavin xnat/xnat2bids-setup nrgxnat/docker-images/setup-commands/xnat2bids

Debug / Testing

Title Author Docker Hub GitHub Notes
Debug Flavin xnat/debug-command nrgxnat/docker-images/debug-command Test that your container service is working by executing something, anything at all. Look through the command JSON to understand the basic structure.
Debug Setup Command Flavin xnat/debug-setup nrgxnat/docker-images/debug-setup-command A minimally functional setup command to test that setup commands work at all.
Debug Command with Setup Command Flavin xnat/debug-command-with-setup nrgxnat/docker-images/debug-setup-command A minimally functional command which uses and verifies a setup command.
Debug Wrapup Command Flavin xnat/debug-wrapup nrgxnat/docker-images/debug-wrapup-command A minimally functional setup command to test that wrapup commands work at all.
Debug Command with Wrapup Command Flavin xnat/debug-command-with-wrapup nrgxnat/docker-images/debug-wrapup-command A minimally functional command which uses and verifies a wrapup command.


On deck

Title Container Notes Status Ticket
BIDS Apps Numerous We can now run BIDS containers on XNAT-style BIDS formatted data. This unlocks several potential containers. But many are made to be run either on a single subject or across a group of subjects with the change of a single flag. This is not great for us because we can’t launch in the latter way (bulk launching N inputs into one container). Distribution is also less than ideal, because we do not control the source images, only the command metadata that is used by the container service to run them. So we cannot create XNAT-ready images. IN PROGRESS CS-237 - Getting issue details... STATUS
Freesurfer Roll our own Current sticky issue is the license file. We will have to include one in the image, as we have no good way to get one at runtime from XNAT. IN PROGRESS CS-199 - Getting issue details... STATUS
PUP Roll our own This will need to include some NIL Tools binaries, and probably atlases as well. So it will be big. OPEN CS-200 - Getting issue details... STATUS
Slicer federov/slicerdockers I have investigated and categorized the executables within the slicer image, and manually tested running several of them. Some simple executables would make good commands. IN PROGRESS CS-198 - Getting issue details... STATUS
Defacer Either an official one with the MATLAB runtime, or roll our own Use Misha’s mask_face; also see face masking pipeline on Marketplace. This tool uses MATLAB, which is a problem. As of last discussion this had been assigned to Misha. He had worked on it, but I do not know the status of this. UNKNOWN CS-195 - Getting issue details... STATUS
Snapshot generator ImageJ? Don’t want to just containerize WebBasedQcImageCreator. Want to re-write snapshot generation, possibly with ImageJ script. As of most recent discussion, the task of developing this script had been assigned to Rick, but that has fallen through the cracks. OPEN CS-193 - Getting issue details... STATUS
ImageJ fiji/fiji or build from Dockerfiles ImageJ is less a single tool and more of a scripting platform. As such, users would want to be able to run their own scripts for this container to be useful. Or we would need to write a ton of commands covering lots of basic functions (which I do not know, and which would never cover everything). NEEDS EXPERT REVIEW CS-196 - Getting issue details... STATUS


Title Blocked by Would be better if… Ticket
Anonymizer …container service could delete / quarantine existing unanonymized (nonymized?) data; …container service could provide project and/or site-wide anon scripts CS-48 - Getting issue details... STATUS CS-194 - Getting issue details... STATUS

A Note on NIL Tools

Many of the existing tools employed in the NRG lab—often as pipelines on CNDA or TIP—rely on tools written by the NeuroImaging Lab (NIL). These tools are not easily containerizable for two reasons:

  1. The source code is not publicly available. This impedes publishing derivative works in several ways.
    • Dockerfiles should not reference this code. The purpose of a Dockerfile is to facilitate reproducible builds of Docker images on different machines or by different people. If the NIL tools are included, then the build may only take place on those few machines that have access to the source code.
    • The code should not be contained within a Docker image not controlled by NIL. This image would become the de facto official release of the tools. If such an image were to exist, it should by all rights belong to the owner and creator of those tools: the NIL.
  2. The tools often rely on the local availablity of atlas image files. Those altas images are available on the internal servers we have here, but are not generally available. If the atlases were included in a Docker image, its size would be many tens of gigabytes (typical sizes are tens to hundreds of megabytes). This would be prohibitive to install or develop against.

For this reason, any tool that is written using the NIL tools is not, in general, possible to containerize at this time. Exceptions are certainly possible; for instance, the lesion atlas image used only a few NIL tools, which could be copied directly into the Docker image itself. However, while this image can be created, is not distributable for reason 1. above.