BIDS Validator ERROR - [Code 83] ECHOTIME1_2_DIFFERENCE_UNREASONABLE

[bmelo]

When I use the BIDS validator (http://incf.github.io/bids-validator/) on a dataset converted with heudiconv v0.5.1 (dcm2niix v1.0.20180622), I'm getting this error message:

[Code 83] ECHOTIME1_2_DIFFERENCE_UNREASONABLE
The value of (EchoTime2 - EchoTime1) should be within the range of 0.0001 - 0.01.

This dataset has a field mapping sequence with two magnitude images (Siemens MR), converted using this key:

def create_key(template, outtype=('nii.gz'), annotation_classes=None):
    if template is None or not template:
        raise ValueError('Template must be a valid format string')
    return (template, outtype, annotation_classes)

fmap_mag    = create_key('sub-{subject}/fmap/sub-{subject}_magnitude')

For some subjects, EchoTime of magnitude1.nii.gz is higher than EchoTime of magnitude2.nii.gz. But BIDS specification (v1.1.1, section 8.3.5.1) says:

... EchoTime1corresponds to the shorter echo time and EchoTime2 to the longer echo time. Similarly _magnitude1 image corresponds to the shorter echo time and the OPTIONAL _magnitude2 image to the longer echo time.

Obs.: Another point related to this conversion, the BIDS specification template (same section) has not json files for magnitude images, but heudiconv is producing the ".._magnitude1.json" and ".._magnitude2.json" files.

Is it a problem with heudiconv? I can help you figure it out.

[yarikoptic]

https://github.com/nipy/heudiconv/blob/master/heudiconv/bids.py#L144 points to the fact that sometimes the shorter one is the 2nd file although seems to be not the case for me... also from https://github.com/nipy/heudiconv/blob/master/heudiconv/convert.py#L445 where we take output from nipype node for dcm2niix, I wonder now if the order of entries there is guaranteed (sorted) anyhow... if you could check (are comfortable with python's pdb? if not - that is ok, I could guide or add more of .debug msgs to the code) at that point in two "differing" cases -- is it the matter of sorting files within Python side (that fmap_e2 comes before fmap_e1) or it is the output of dcm2niix that EchoTime is swapped and e2 has a shorter one?

[bmelo]

Hi @yarikoptic, thank you!

I understood what is happening. Dcm2niix is converting the files correctly, but for some cases it starts doing the fmap_e2.nii and then the fmap_e1.nii heudiconv_log.txt.

The function save_converted_files in convert.py receive the files in the converted order (https://github.com/nipy/heudiconv/blob/master/heudiconv/convert.py#L445) and (https://github.com/nipy/heudiconv/blob/master/heudiconv/convert.py#L472). When I sort the variables res_files and bids_files before the renaming, this issue disappears. Shall I submit a pull request with these adjustments?

What about the "_magnitude*.json" files? Is it okay to keep them in the dataset even though they are not in the BIDS specification?

[ddwagner]

Jumping in to say I'm also getting this issue pretty consistently on every subject with a few exceptions but no rhyme or reason to them that I can tell. Happy to post log files, but as with bmelo, it appears to be because dcm2niix is writing out fmap_e2.nii files before fmap_e1.nii files. Is there still a fix in the pipeline based on bmelo's pull request?

[yarikoptic]

@ddwagner please try the version in #250 and report back. If solves it for you, we will just merge it! ;-)

[ddwagner]

@yarikoptic Just tried it and it works great. No more issues errors with fieldmaps. Datasets finally pass the bids validator! The weird thing is my heudiconv logs are the same whether I use the new or old version in that the fmap_e2.nii is still being written first by dicon2niix but it no longer poses a problem. Anyhow, thanks for the tip.

[yarikoptic]

Could you also actually apply the correction and see if it correct the right way? :-)

[neurolabusc]

Just a note that the upcoming release of dcm2niix will be more explicit in always naming 'e1' for the first echo in a multi-echo series. @ddwagner be aware that dcm2niix may well write the "_e2" file before the "_e1" file - it generates the files in the order provided by file searching. The images are not saved to disk in the order they were acquired, rather the order they are identified. Therefore, the file name and BIDS header should allow you to accurately sort the images, but not the NIfTI file creation time.