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

Validate differences in EchoTimes by using EchoNumbers #2

Open
sinhaharsh opened this issue Jul 20, 2022 · 2 comments
Open

Validate differences in EchoTimes by using EchoNumbers #2

sinhaharsh opened this issue Jul 20, 2022 · 2 comments

Comments

@sinhaharsh
Copy link
Collaborator

Description

The package supports multi-echo modality, but fails to catch discrepancy in echo times. Can we validate in differences in echo times, by using echo number ?

@sinhaharsh
Copy link
Collaborator Author

Gathering evidence, if this is correct way -

Points to consider

  1. Echo Number is optional attribute.
  2. But, it can tell us, if it is an issue or intended

Quotes from dcm2niix github issues

  1. Link

You may also want to encourage your contacts at Bruker to implement the optional Echo Number (0018,0086) to disambiguate echo times. This allows tools to detect discrete echo times without being concerned about rounding errors with the string based Echo Time (0018,0081) tag.

  1. Link

As you note, these DICOMs omit echo number (0018,0086) ... [dcm2niix] explicitly inserts the echo time into the filename for multi echo sequences where 0018,0086 is omitted.

  1. Link

Usually, the output of dcm2niix will provide hints regarding why images from the same DICOM series were saved as separate NIfTI images. For example, variations in slice angulation, echo time, coil, study time, and X-ray exposure are all good reasons to segment data (as these properties can not be encoded in NIfTI).

@raamana
Copy link
Contributor

raamana commented Mar 5, 2023

good catches with these useful pointers/links, Harsh!

let's try parse slice angulation, echo time, coil, study time, and X-ray exposure from DICOM (when available) and keep them in MRdataset for now, so we can decide how to handle them in future.

again, let's table this for discussion in redesigning MRdataset 2.0 as it may involve more testing as we change some key things

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