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.
|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.|
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.
Debug / Testing
|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.|
|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:
- 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.
- 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.