This page is a partial 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.
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
|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|
|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|
|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|
|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|
|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|
|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|
|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|
|Anonymizer||…container service could delete / quarantine existing unanonymized (nonymized?) data; …container service could provide project and/or site-wide anon scripts CS-48||CS-194|
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.