I am getting a “VOLUME_COUNT_MISMATCH” bids validator error (v1.5.7 and v1.9.3) that I cannot figure out how to fix.
The error is being triggered by a diffusion sequence with a single direction. I have verified that the image file has only a single volume in dim4:
I have also checked that the associated bval and bvec files also only have entries for a single direction:
Everything seems to be lining up, so I’m at a loss as to what might be going on.
Thanks in advance,
This sounds like you are dealing with a b0-reference image. In that case, try renaming it with
_sbref.nii.gz/.json instead of
_dwi (but keep it in your
dwi/ folder). If that doesn’t work, try transpsing your b-vec (so it is in column form instead of rows or vice-versa).
Thanks for the suggestions. I had previously tried to transpose the bvec into 1 row x 3 columns, but that gave an error. So, the bvec file has to be 3 rows x 1 column (where columns = # diffusion directions and rows = x, y, z).
I also just tried renaming the .nii.gz and .json files to sbref instead of dwi, but it looks as if the bids standard doesn’t allow sbref for files in a dwi directory.
2: [ERR] Files with such naming scheme are not part of BIDS specification. This error is most commonly caused by typos in file names that make them not BIDS compatible. Please consult the specification and make sure your files are named correctly. If this is not a file naming issue (for example when including files not yet covered by the BIDS specification) you should include a ".bidsignore" file in your dataset (see https://github.com/bids-standard/bids-validator#bidsignore for details). Please note that derived (processed) data should be placed in /derivatives folder and source data (such as DICOMS or behavioural logs in proprietary formats) should be placed in the /sourcedata folder. (code: 1 - NOT_INCLUDED)
I’ll keep digging around to see if I can find a similar example anywhere. Worst case scenario, I just manually code the file into the .bidsignore.
If you have multiple dwi acquisitions, this may be causing your problem. I have a similar issue where I have the following files in a dwi/ directory:
I thought this seemed clear to have a “real” 5+64-direction dwi alongside a supporting reverse-polarity-encoded acquisition with only two volumes (b=0 and b=1000). Each 4-file set is valid on its own, but bids-validator does not like them together. I had to get into debugging the bids-validator code to figure out that bids-validator makes a list of possible bvec files for a given nifti file. So
sub-U02964_ses-607_dir-rpe_dwi.nii.gz matches both
sub-U02964_ses-607_dir-rpe_dwi.bvec (as I would expect) and
sub-U02964_ses-607_dwi.bvec (which seems wrong), resulting in a mismatch between
sub-U02964_ses-607_dwi_dir-rpe_dwi.nii.gz's 2 volumes, and
sub-U02964_ses-607_dwi.bvec's 69 values.
I would consider this a bug, and I started with good intentions to submit a pull request to fix it, but I don’t understand enough about why they’re considering these different filenames to be matches for each other. I can’t imagine it’s valid BIDS to have
sub-U02964_ses-607_dir-rpe_dwi.nii.gz's bvec be named
sub-U02964_ses-607_dwi.bvec without the
dir-rpe, but I don’t feel knowledgeable enough to start changing how they build their potential file list.
To keep BIDS happy and “fix” this, I tried naming them run-01 and run-02 without the dir-rpe, but the resulting warning reminded me that multiple runs should be of the same acquisition, so this is not valid.
I tried naming the “real” dwi as dir-fpe, to contrast with the dir-rpe, and bids-validator is happy with that. I would prefer that the normal forward-encoded dwi just be named _dwi, and I’m not sure if pre-processing pipelines will recognize this without further tweaking. If anyone has a better recommendation, or knows enough to fix the bids-validator code, I’d love to read about it.
Just to provide an update with our current work-around.
For studies that collect a single gradient DWI image with reverse phase-encoding, we now store those files in the fieldmap directory, as an
This work-around does require removing the associated
.bvec files from the
fmap directory, but it does solve the “VOLUME_MISMATCH_ERROR”. We have included removing these files as part of our post-conversion tuneup routine.
We haven’t yet tested this solution with studies that collected multi-volume reverse phase-encoded diffusion images.
You may need to include the
acq- flag in the filename if the study is also collecting a reverse phase-encoded EPI-BOLD image.