A software tool for verifying appropriate software handling of DWI metadata
Under development
A Docker image is now provided that embeds all requisite functionalities and data. This can be done via eg.:
docker build . -t dwi_metadata:latest
mkdir scratch
docker run -it --rm -v $(pwd)/scratch:/scratch /main.py /data /scratch /scratch/log.logThe main.py script currently expects all relevant commands to be present in PATH.
This includes the peakscheck and peaksconvert commands proposed for MRtrix3,
which currently necessitates installation of the following branch:
https://github.com/MRtrix3/mrtrix3/pull/2918
dcm2niix3.0.4, intended to be included in 3.0.5The gradient table utilised in acquisition of data for this project can be found at:
The crucial feature of this gradient table is that, for the first three non-b=0 volumes, diffusion sensitisation was applied along each of the three native axes of the Device Coordinates System (DCS): [1.0, 0.0, 0.0], then [0.0, 1.0, 0.0], then [0.0, 0.0, 1.0]. The known directions of diffusion sensitisation of these three volumes can therefore be utilised as fiducials, ensuring that no interpretation of these data from the respsective DICOM series nor subsequent image processing steps result in erroneous transformation of these vectors. The gradient table intotality is however still relatively homogeneously distributed, and can therefore be used for downstream diffusoin model fitting without bias.
Note that the directions of these vectors is predicated on the coordinate system of the scanner hardware gradients; this is not equivalent to the Right-Anterior-Superior (RAS) convention used in many neuroimaging softwares / formats.
The DICOM data included in the Docker image can be found at:
Here there are 24 DWI DICOM series.
These represent every single possible combination of slice encoding direction, slice order, and phase encoding direction,
for non-oblique fields of view.
In addition, all are isotropic acquisitions,
and use a cubic Field of View (FoV);
this facilitates concatenation of data across all series,
provided that the data are reoriented appropriately.
The contents of DICOM field SeriesDescription,
as well as the names of the directories in which they are stored,
also encode the slice encoding direction, slice order, and phase encoding direction;
any software handling of the metadata encoding this information can therefore be cross-checked
against what is known to have been acquired.
The following is a summary of the validation currently performed by this tool. It is hoped that this list will expand in the future. Every test involves verification of all 24 DICOM series.
bvec / bval, based on image header transformation.
Compare fiducials transformed to "real" / "scanner" space against known diffusion directions.dw_scheme".
Image header transformation is irrelevant in this case,
given that gradient directions are defined with respect to "real" / "scanner" space.
Compare fiducials against known diffusion directions.SliceEncodingDirection and SliceTiming,
given that a temporal reversal of the slice timing vector and an inversion of the slice encoding direction
are equivalent operations.
Additionally, the relevant metadata may be stored internally within an image header,
or it could be stored in a sidecar metadata file.
Direction based on image axis identifier / signedness compared to SeriesDescription.SeriesDescription.dcm2niix:
SliceEncodingDirection" is not explicitly written by dcm2niix;
this tool must therefore assume a value of "k" in its absence.MRtrix3:
bvec & bvaldcm2niixFSL:
dcm2niixmrconvert
dtifit:
bedpostx:
RS (@Lestropie) is a fellow of the National Imaging Facility, a National Collaborative Research Infrastructure Strategy (NCRIS) capability, at the Florey Institute of Neuroscience and Mental Health.