...
We'll use the antsRegistrationSyNQuick.sh script to illustrate the above concepts since its arguments correspond quite simply (correspond to what?). Assume $fixed and $moving are image files in approximately the same orientation but not necessarily the same spatial location (if not, consider doing a rigid alignment either manually via register or via antsAI, rotational_minctracc.py, or similar); for instance, on MICe systems you may
...
Here -d 3 specifies the image dimensionality and -t s specifies the transformation type (in this case consecutive rigid, affine, and nonlinear SyN registrations). -f and -m of course specify the fixed and moving images, and -o some arbitrary prefix o specifies the prefix for the output filesfile names.
The following output files are produced:
...
Both of these programs take many other options, e.g. antsRegistrationSyNQuick.sh can accept masks or initial transformations of the fixed or moving image; antsApplyTransforms can take options to change the interpolator (the default is trilinear, while you need to use a nearest neighbour/generic label interpolator for segmentation volumes), or apply inverse transforms via -t [transform_to_invert,1]. Regarding inverse transforms, note that only transforms known to be invertible such as affine transforms will work can be inverted this way; ANTs won't numerically invert an arbitrary transform for you. Also, inverting a composite is achieved by composing the inverses in reverse order, so to apply the inverse transform we'd use -t [fixed_to_moving0GenericAffine.mat,1] -t fixed_to_moving1InverseWarp.nii.gz.
...
This command is daunting, but we can simply run it as-is or with slight modifications. For instance, we could change the output files to .mnc instead of .nii.gz in the --output section, or add the --minc flag to generate MNI .xfm files instead of ITK-style transform files (.mat and .nii.gz). We won't go into full details here, but see the page Anatomy of an antsRegistration Call. Note that a mutual information ("MI") metric was used. This metric is suitable for inter-modality registration (e.g. MRI to CT, or structural MRI to dMRI). For intra-modality registration, the cross-correlation ("CC") metric could be used instead. In fact, the slower antsRegistrationSyN.sh script generates a CC-based antsRegistration command (What does this mean/Why is this important?). Note that the MI parameters don't have a spatial scale, but one of the CC parameters is a radius (in mm), and should be adjusted to some much smaller value than the antsRegistrationSyN.sh defaults when registering rodent images, otherwise immense amounts of time and memory will be needed. Can you recommend a radius value for your bog-standard structural MRI mouse brain registration? What flag should be used for this?
Hints and caveats
You can often increase fine accuracy by adding some nonzero number of iterations at the native resolution (e.g. --convergence [ 100x100x100x100x50 ] or similar in the --transform SyN part of the registration) at the cost of greatly increased time and memory usage. To save yourself lots of time, make sure the registration is working at a coarse level before doing this!
...
MINC registration programs such as minctracc typically refer to 'source' and 'target' rather than 'fixed' and 'moving' images, e.g., minctracc ${options} -source $source -target $target -o source_to_target.xfm followed by mincresample source -like target -transform source_to_target.xfm -o source_to_target_resampled.mnc. From this you might guess the (incorrect) correspondence source ~ moving, target ~ fixed, mincresample ~ antsApplyTransform 
. However Why is this red X here?. However, mincresample and antsApplyTransforms quite different algorithms that use different registration strategies and give different results, which is resolved by inspecting . One can prove this to themselves by inspecting the mincresample source code to reveal that and noting that without the -invert flag, mincresample uses the libminc function invert_general_transform is used, while mincresample -invert calls general_transform. Thus, applying to apply a transform such as done by antsApplyTransforms is actually achieved by mincresample -invert, and for , but using the mincresample algorithm, one must use mincresample -invert. For this to make sense, we must have source ~ fixed, target ~ moving. (Also, we should prefer to use -invert when possible to avoid numerically inverting a transform!)to avoid numerically inverting a transform - to avoid doing whatnow? How would this invert a transform?!) I think the tilde here is unclear. What does it mean, in words? Does it indicate similarly, or stepwise progression, or ...?
The resulting oddity to keep in mind is that in the MINC world, individual subjects are typically (images?) are typically considered the 'source' and templates templates used as the 'target', while in . On the other hand, in the ANTs world, subjects are typically 'moving' and templates templates are 'fixed', so the 'direction' in which a registration algorithm has been applied will likely be different (assuming one is interested in warping a subject to a template in both cases) between the two worlds, resulting in different transformations (since most registration algorithms are not symmetric or invertible and even ANTs's SyN transformations are only so up to various numerical approximations.). It's the extra inversion hidden in (hidden? Don't you have to add it manually as a flag? Doesn't seem very hidden) in mincresample which reconciles everything, of course.
Another issue to keep in mind is that often one wants to initialize the transformation of the moving image to some with some existing warping, say from a previous stage of registration. (This is not equivalent to resampling the moving image first since the any cost function applied to the transform won't consider this pre-applied part, and also introduces some extra numerical error.) ANTs tools allow --initial-moving-transform as well as --initial-fixed-transform, but `minctracc` allows only `-transform` which is applied to the source, i.e. fixed, image. One way to get around this might be to use minctracc's -invert option to recover a transform going in the opposite direction, effectively identifying source with moving and target with fixed, but it should be checked whether this actually inverts the transform or just swaps the images in the registration process.
...