Error from BIDS validator

Hi,

I got this error… SESSION_LABEL_IN_FILENAME_DOESNOT_MATCH_DIRECTORY

Location:

midus2/sub-M2ID10215/ses-EmotionReactivityAndRecovery/func/sub-M2ID10215_ses-EmotionalReactivityAndRecovery_run-2_bold.nii.gz

Reason:

Session label in the filename doesn’t match with the path of the file. File seems to be saved in incorrect session directory.

Evidence:

File: /sub-M2ID10215/ses-EmotionReactivityAndRecovery/func/sub-M2ID10215_ses-EmotionalReactivityAndRecovery_run-2_bold.nii.gz is saved in incorrect session directory as per ses-id in filename.

Initially when I got this error I had no session directory in the participant folder so I created “ses-EmotionalReactivityAndRecovery” and placed the participant data inside. I also changed the file names to match the session directory, for example:

Originally I had: sub-M2ID10215_task-EmotionalReactivityAndRecovery_run-2_bold.nii.gz

Which I changed to: sub-M2ID10215_ses-EmotionalReactivityAndRecovery_run-2_bold.nii.gz

However, due to this change I’m experiencing a new error:

sub-M2ID10040_ses-EmotionalReactivityAndRecovery_run-1_bold.nii.gz 49313.075 KB | application/gzip

Location:

midus2/sub-M2ID10040/ses-EmotionalReactivityAndRecovery/func/sub-M2ID10040_ses-EmotionalReactivityAndRecovery_run-1_bold.nii.gz

Reason:

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.

Evidence:

sub-M2ID10040_ses-EmotionalReactivityAndRecovery_run-1_bold.nii.gz

Can anyone help to rectify these issues I’m having?

Thanks in advance,
Phoenix

Hi @PhoenixByrne,

For functional bold acquisitions, you need to specify the task entity label (task-) in your filename. So in your example, it would need to look something like sub-M2ID10040_ses-EmotionalReactivityAndRecovery_task-taskName_run-1_bold.nii.gz, where “taskName” is the name of your task. I would recommend checking out CogAtlas for choosing an appropriate name.

Additionally, in each functional bold json file, you’ll need to include this line: "TaskName": "taskName", where “taskName” is the name of your task. Do note that you don’t need the comma if this is the last line in your json file(s).

Hope this helps a bit.

Hi,

Thanks for your swift response, it was very helpful in solving my issue. One more question - if I’ve received this error - Error 6: [Code 94] MAGNITUDE_FILE_WITH_TOO_MANY_DIMENSIONS

Location:

midus2/sub-M2ID10040/ses-1/fmap/sub-M2ID10040_ses-1_magnitude1.nii.gz
Reason:

_magnitude1.nii[.gz] and _magnitude2.nii[.gz] files must have exactly three dimensions.
Evidence:

this magnitude file has more than three dimensions.

how would I solve this? Does require making changes to the .JSON files?

Thanks again!
Phoenix

It appears that your midus2/sub-M2ID10040/ses-1/fmap/sub-M2ID10040_ses-1_magnitude1.nii.gz file isn’t 3D and instead contains multiple volumes, meaning that it’s 4D. Can you provide the shape of this data? This can be done for example with fslhd

My guess is that your magnitude file contains the both the magnitude1 and magnitude2, which need to be split into two separate files. I assume you also have a phasediff file (or a phase1 and phase2 file). I’m unsure how you converted your data to BIDS, but if you didn’t use one of the BIDS converters then you should, as they use dcm2niix under the hood, which can detect these magnitude files for you.

Alternatively, if you’re trying to go the manual route, you could use the FSL command fslsplit to break up your 4D magnitude files into two separate 3D files and rename them accordingly.

Hi,

I used fslhd and this is the output:
filename sub-M2ID10040_ses-1_magnitude1.nii.gz
size of header 348
data_type INT16
dim0 5
dim1 256
dim2 256
dim3 30
dim4 1
dim5 1
dim6 0
dim7 0
vox_units mm
time_units ms
datatype 4
nbyper 2
bitpix 16
pixdim0 1.000000
pixdim1 0.937500
pixdim2 0.937500
pixdim3 5.000000
pixdim4 700.000000
pixdim5 1.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.000000
cal_min 0.000000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 3
slice_name Unknown
slice_code 48
slice_start 0
slice_end 29
slice_duration 0.000000
toffset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 0.000000 0.000000 5.000000 -70.744202
qto_xyz:2 -0.937500 0.000000 0.000000 119.530998
qto_xyz:3 0.000000 -0.937500 0.000000 128.897003
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Anterior-to-Posterior
qform_yorient Superior-to-Inferior
qform_zorient Left-to-Right
sform_name Scanner Anat
sform_code 0
sto_xyz:1 0.000000 0.000000 0.937500 -66.322685
sto_xyz:2 -0.937500 0.000000 -0.000000 112.060310
sto_xyz:3 0.000000 -5.000000 -0.000000 644.484985
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Anterior-to-Posterior
sform_yorient Superior-to-Inferior
sform_zorient Left-to-Right
file_type NIFTI-1+
file_code 1
descrip
aux_file PD=ROW

I’m performing a secondary data analysis and when given access to this data I was told it was in BIDS so I’m not 100% sure how/if they converted it.

Thanks!
Phoenix

This is more about the original post, but your session level directory says “Emotion…:”, while the filename says “Emotional…”, creating the mismatch.

1 Like

Whoops, I completely missed that, thanks @Steven !

Whoops, I completely missed that, thanks @Steven

@PhoenixByrne,

Thanks for the header info. I’m noticing some weird stuff with this portion of the header info:

dim0 5
dim1 256
dim2 256
dim3 30
dim4 1
dim5 1
dim6 0
dim7 0

The dim0 value, which specifies the dimension of your data, is 5 (due to what appears to be an aux_file containing extra information), and dim6 & dim7 are zero (these value are typically one). Are you able to share this nifti file and corresponding json file?

Hi,

Unfortunately, I don’t have .json file (this dataset is missing all .json files, but I’m in the process of correcting). As per your previous comment, I used fslsplit on the magnitude file then fslhd to see the shape of the file - does this solve any of the weird stuff?:

size of header 348
data_type INT16
dim0 3
dim1 256
dim2 256
dim3 30
dim4 1
dim5 1
dim6 1
dim7 1
vox_units mm
time_units s
datatype 4
nbyper 2
bitpix 16
pixdim0 1.000000
pixdim1 0.937500
pixdim2 0.937500
pixdim3 5.000000
pixdim4 700.000000
pixdim5 1.000000
pixdim6 0.000000
pixdim7 0.000000
vox_offset 352
cal_max 0.000000
cal_min 0.000000
scl_slope 1.000000
scl_inter 0.000000
phase_dim 0
freq_dim 0
slice_dim 0
slice_name Unknown
slice_code 0
slice_start 0
slice_end 0
slice_duration 0.000000
toffset 0.000000
intent Unknown
intent_code 0
intent_name
intent_p1 0.000000
intent_p2 0.000000
intent_p3 0.000000
qform_name Scanner Anat
qform_code 1
qto_xyz:1 0.000000 0.000000 5.000000 -70.744202
qto_xyz:2 -0.937500 0.000000 0.000000 119.530998
qto_xyz:3 0.000000 -0.937500 0.000000 128.897003
qto_xyz:4 0.000000 0.000000 0.000000 1.000000
qform_xorient Anterior-to-Posterior
qform_yorient Superior-to-Inferior
qform_zorient Left-to-Right
sform_name Scanner Anat
sform_code 0
sto_xyz:1 0.000000 0.000000 0.937500 -66.322685
sto_xyz:2 -0.937500 0.000000 0.000000 112.060310
sto_xyz:3 0.000000 -5.000000 0.000000 644.484985
sto_xyz:4 0.000000 0.000000 0.000000 1.000000
sform_xorient Anterior-to-Posterior
sform_yorient Superior-to-Inferior
sform_zorient Left-to-Right
file_type NIFTI-1+
file_code 1
descrip 6.0.1
aux_file PD=ROW

I really appreciate the help, this dataset has been quite the struggle!
Phoenix

Yes, the header info looks more normal now, at least based on the fields I was concerned with. Can you examine the file(s) in fsleyes to see how they look?

When I performed fslsplit it only created 1 new file, shouldn’t it create 2? I’ve looked at the new file against the original and there doesn’t seem to be any difference?

The difference may not be apparently from visual inspection, but the header information (fslinfo) is now different. Intitally, you had a 5D file, which is now 3D. My thought was that there was an aux_file or something equivalent embedded in your original file, which has been separated.

Can you re-run the BIDS validation with your modified file to see if any errors persist? Also be sure to make the correction that @Steven noted earlier

@dlevitas

I’ve rerun BIDS and I’m no longer getting the error, however, should I have a magnitude 2 file?

That depends, do your fieldmaps pertain to fieldmap case 2 or case 1 in the BIDS specification?

If case 2, then you need four nifti/json file pairs: magnitude1, magnitude2, phase1, and phase2.

If case 1, then only two nifti/json file pairs are required: magnitude1 and phasediff. The magnitude2 is optional, though if you have it, it’s generally a good idea to include it. Be aware that for this case, the phasediff json file needs to contain the EchoTime1 and EchoTime1 metadata fields.

Hope this helps

1 Like

That is really helpful, thank you! What if I appear to have 4 TEs?

Do you mean your nifti file contains these four fields?
`
EchoTime1

EchoTime2
EchoTime3
EchoTime4
`
Out of curiosity, which BIDS converter tool did you use to convert your DICOMS to BIDS, or did you do it manually?