A very nice feature of afni is that the 4th dimension in the statistics output files (even NIfTIs) can be assigned labels. The labels are viewed by the afni command 3dinfo -verb filename.nii.gz, which prints a list including the "sub-brick" (afni-speak for the 4th dimension) names and (0-based) indices, such as:
-- At sub-brick #102 'Bng#5_Coef' datum type is float: -13.6568 to 14.6825
-- At sub-brick #103 'Bng#5_Tstat' datum type is float: -5.06214 to 4.55812 statcode = fitt; statpar = 1153
-- At sub-brick #104 'Bng#6_Coef' datum type is float: -9.25095 to 13.3367
-- At sub-brick #105 'Bng#6_Tstat' datum type is float: -4.56816 to 3.55517 statcode = fitt; statpar = 1153
-- At sub-brick #106 'Bng_Fstat' datum type is float: 0 to 5.56191 statcode = fift; statpar = 7 1153
What if I want to display the Bng_Fstat image? It's possible to hard-code the corresponding number (107, in this case: R is 1-based) in the knitr R code, but that's dangerous, as the indexing could change. But we can run 3dinfo -label2index label dataset from within knitr to look up the indexes by name:
img <- readNIfTI(fname, reorient=FALSE);
brick.num <- as.numeric(system2("/usr/local/pkg/linux_openmp_64/3dinfo", args=paste("-label2index Bng_Fstat", fname), stdout=TRUE));
if (!is.na(brick.num)) { make.plots(in.img=img[,,,1,brick.num+1]); }
That the make.plots function is from my demo, and I provide the full path to 3dinfo in the system2 call to avoid command-not-found issues. Also note the indexing: afni-created images are often read by oro.nifti with an extra dimension (the sub-bricks are in the 5th dimension rather than the 4th).
dim(img)
[1] 75 90 75 1 152
Also, note again that it's brick.num+1: afni has a sub-brick #0, but R does not have an index 0!
