3D DWI files produce are not marked as invalid, but fail VOLUME_COUNT_MISMATCH

[effigies]

Creating a fake DWI volume with shape (5, 5, 5, 1), bval of 0 and bvec of 0\n0\n0\n is valid. If I change the shape to (5, 5, 5), then I get the following error:

❯ docker run --rm -it -v $PWD/synthdwi:/data:ro bids/validator:v1.14.0 /data
[email protected]
	1: [ERR] The number of volumes in this scan does not match the number of volumes in the corresponding .bvec and .bval files. (code: 29 - VOLUME_COUNT_MISMATCH)
		./sub-1/dwi/sub-1_acq-TRACE_dwi.nii.gz
...

We have a couple options here:

1. Permit missing bval/bvec for 3D volumes. This would mostly apply to ADC/TRACE images. This would probably require a spec stating that in this case, the file SHOULD be treated as having bval of 0 and bvec of $\vec 0$.
2. Treat 3D volumes as being 4D with a size of 1 in the 4th dimension for the purposes of this check.

I don't have a strong sense of which would be the simplest or most maintainable. Schema checks would be easy to write in either case, so I would prefer to go with what makes the most sense from the perspective of understanding a dataset.

cc @neurolabusc

xref https://neurostars.org/t/question-regarding-validation-of-dwi-data/27542

[effigies]

cc @arokem @oesteban for thoughts on the best approach here.

[oesteban]

We may need both.

1. would be a cleaner solution to the problem stated above
2. would be necessary for a file having only b0s, where you have a shape of, e.g., (5, 5, 5, 3). Currently, you would send this into fmap/ and store it as _epi, but @mattcieslak has reported previously this issue because there could be an interest to not having those under fmap/. I cannot remember where this is reported, though.

[neurolabusc]

I would like to see this resolved. While @effigies noted a kludge to describe the data as 4D, this causes subsequent scripts to assume that images have different dimensions. Consider comparing two NIfTI files (e.g. from our new valid OpenNeuro dataset) where one claims to be 4D with a single volume in the 4th dimension and the other claims to be 3D. The following script detects them as different:

Warning: Dimensions of 'TRACElesion.nii.gz' differ from 'TRACE.nii.gz'.
(432, 432, 26) != (432, 432, 26, 1)

def check_nifti_files(file_list):
    if len(file_list) < 2:
        return True
    # Load the first NIfTI file
    reference_img = nib.load(file_list[0])
    for file_path in file_list[1:]:
        # Load the current NIfTI file
        current_img = nib.load(file_path)
        # Check spatial dimensions
        if reference_img.shape != current_img.shape:
            print(f"Warning: Dimensions of '{file_list[0]}' differ from '{file_path}'.")
            print(f"{reference_img.shape} != {current_img.shape}")
            return False
    return True

In this case, one can correct this with if reference_img.shape[:3] != current_img.shape[:3]:, but it illustrates the unintended consequences of this kludge.

[arokem]

I understand that the current spec requires this, but I don't think that it makes much sense to require b-values and b-vectors to accompany TRACE/ADC images, or even to implicitly assume that they have a b-value and b-vector associated with them (even 0). I understand that these fall under the definition of "raw" data, because they are produced by the computer that is attached to the scanner, but I think that we need a different tack for these files. Would it make sense to implement "ADC"/"TRACE" suffixes for these files?

[ins0mniac2]

Has a decision been made about this, even if not already part of the specs, and/or coded into validator ? I also think requiring bval/bvec files for these images is silly, so if we are still unsure, perhaps we can leave these as 3D without the proposed hack and place them in .bidsignore.

[effigies]

No, there hasn't been a decision and I just saw another post that reminded me of this. How about I just make an issue on the spec where we can vote about whether ADC/TRACE volumes should be dwi/*_acq-{ADC,TRACE}_dwi.nii.gz with no required bval/bvec or dwi/*_{ADC,TRACE}.nii.gz files?

[oesteban]

Please note that this would still not cover the case of a b=0 with just one volume. We could require _dwi to be 4D always in the spec and dimension 1 in the last for these. The validator should check that the number of items in bvec, bval, and last dimension of _dwi match. We could allow the _dwi be 3D if the length of bvec, bval is one.

Alternative, one more b0 suffix could do, but I don't particularly like this option.

[effigies]

Please vote on ADC/TRACE here: https://github.com/bids-standard/bids-specification/issues/1723

The validator should check that the number of items in bvec, bval, and last dimension of _dwi match. We could allow the _dwi be 3D if the length of bvec, bval is one.

I'm okay with this; this would be a simple patch to the validator, and any added text to the spec would be clarification, not a change. If there are alternatives that others would like to consider for B0 volumes then we can make a voting issue, but if not, let's just do the straightforward thing.

[effigies]

The fix will be to use alternative suffixes.