Bids validator - volume_count_mismatch error for dwi run with 1 direction

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:

fslinfo sub-115_run-01_dwi.nii.gz
data_type	INT16
dim1		104
dim2		104
dim3		72
dim4		1
datatype	4
pixdim1		2.000000
pixdim2		2.000000
pixdim3		2.000000
pixdim4		5.100000
cal_max		0.000000
cal_min		0.000000
file_type	NIFTI-1+

I have also checked that the associated bval and bvec files also only have entries for a single direction:

cat sub-115_run-01_dwi.bval

cat sub-115_run-01_dwi.bvec

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).


Hi Steven,

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 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)
			Evidence: sub-115_run-01_sbref.json
			Evidence: sub-115_run-01_sbref.nii.gz

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.

Thanks again,


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 epi image.


This work-around does require removing the associated .bval and .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.