Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with echo times from dual-echo field maps #789

Open
1 of 2 tasks
levchenkoegor opened this issue Oct 8, 2024 · 5 comments
Open
1 of 2 tasks

Issue with echo times from dual-echo field maps #789

levchenkoegor opened this issue Oct 8, 2024 · 5 comments

Comments

@levchenkoegor
Copy link

Summary

I am converting my raw data to BIDS format. I’m encountering an issue with HeuDiConv during the conversion of field maps, and I suspect it has to do with how the tool groups sequences into the CSV file during the conversion process.

I am using dcm2niix within HeuDiConv to convert raw DICOM files into BIDS format. The dataset includes dual-echo GRE field mapping sequences with two echo times. dcm2niix correctly generates the nifti files and associated JSON sidecars, with accurate metadata:

gre_field_mapping_1acq_e1.json
gre_field_mapping_1acq_e1.nii
gre_field_mapping_1acq_e2.json
gre_field_mapping_1acq_e2.nii         
gre_field_mapping_1acq_e2_ph.json
gre_field_mapping_1acq_e2_ph.nii

If I check the echo times in JSON files it correctly shows 0.01 sec, 0.01246 sec and 0.01246 sec respectively for _e1, _e2 and _e2_ph files.

However, when HeuDiConv generates the TSV file that groups the sequences, it seems to misinterpret or incorrectly group the echoes, resulting in misleading or duplicated entries for the field map sequences. Here is the part of the TSV file:

<style> </style>
dim1 dim2 dim3 dim4 TR TE protocol_name
64 64 128 1 1.02 12.46 gre_field_mapping_1acq_rl
64 64 64 1 1.02 12.46 gre_field_mapping_1acq_rl

As you can see there is definitely a problem: there is only two field_mapping protocols with the same TE (there should be three and two of them with different TE).

I am running HeuDiConv using docker on our lab server:

  docker run --rm -v "${project_path}:/base" nipy/heudiconv:latest \
    -d "/base/raw_data/sub-{subject}/sess-{session}/*/*.dcm" \
    -o "/base/analysis/heudiconv_first_outputs/" \
    -f convertall -s "$subj_id" -ss "$sess_id" \
    -c none

I plan to use the heuristic.py file later to organise the data in BIDS-valid format, but if the grouping is done wrong at the first step it seems hard to find a solution.

I am wondering if:

  1. Has anyone encountered similar issues with HeuDiConv misgrouping multi-echo field map sequences?
  2. Are there known bugs or limitations in HeuDiConv’s handling of dual-echo field maps?
  3. Is there a recommended workaround or fix (e.g., manually adjusting the heuristic file, editing the TSV)?

Any help or insights would be greatly appreciated! I’d be happy to provide more details if needed.

Thanks in advance!

Platform details:

Choose one:

  • Local environment
  • Container
  • Heudiconv version: 1.3.0
  • Dcm2niix version: v1.0.20220720
@yarikoptic
Copy link
Member

Thanks @levchenkoegor for the bug report!

Is there a sample of DICOM files you might be willing to share?

I plan to use the heuristic.py file later to organise the data in BIDS-valid format,

checkout this ReproNim/reproin#18 (comment) -- may be you could just remap into reproin, and if we fix this fieldmap issue -- should might be the easiest way.

@levchenkoegor
Copy link
Author

Hey @yarikoptic! Thank you for your response!

Sure! Please find attached the archive with DICOMs.
DICOMs_fieldmap_dualecho_Siemens.zip

@levchenkoegor
Copy link
Author

I've been reading the code and have a feeling that the problem appears here:

if mw.is_same_series(mwgroup[idx]):

When one DICOM is treated as the same as the other one based on is_same_series() method. Probably the TE isn't taken into account when two DICOMs are compared.

@yarikoptic
Copy link
Member

didn't look myself yet -- did you figure it out @levchenkoegor ?

@levchenkoegor
Copy link
Author

@yarikoptic not really, unfortunately couldn't specify exactly where the problem actually occurs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants