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

Support for susceptibility imaging including QSM, SWI and SWI-MIP #1566

Open
astewartau opened this issue Jul 28, 2023 · 3 comments
Open

Support for susceptibility imaging including QSM, SWI and SWI-MIP #1566

astewartau opened this issue Jul 28, 2023 · 3 comments
Labels
MRI For things that affect all MRI datatypes

Comments

@astewartau
Copy link

astewartau commented Jul 28, 2023

Your idea

Support for Quantitative Susceptibility Mapping (QSM) currently exists as it is considered a quantitative, derivative and anatomical MR image and uses the _Chimap suffix. It also has a BIDS example. I believe this was introduced by the qMRI extension integrated in 2022 based on Karakuzu et al.'s Scientific Data publication.

However, similar support for Susceptibility Weighted Imaging (SWI) and associated Minimum Intensity Projections (SWI-MIP) is to be integrated. The inactive BEP004 proposal suggests a swi/ datatype and proposes storing the input _GRE images there with the resultant files using proposed _swi and _minIP suffixes.

Currently, _MEGRE and _T2starw suffixes already exist in the anat/ datatype, so the remaining changes to fully support SWI may be smaller and consist only of adding the _swi and _minIP suffixes.

Myself, @stebo85, and @neurolabusc propose to finalise support for susceptibility imaging by making some minor pull requests to do this. We also have open examples on OSF of DICOM input data and its mapping to BIDS, which are suitable for QSM and SWI reconstruction that we propose to adapt into similar BIDS examples.

We are opening this issue to begin discussions with the wider susceptibility imaging and software developer community so we can share ideas before changes are made and integrated.

@tsalo
Copy link
Member

tsalo commented Jul 28, 2023

I believe you will also need a coil or channel entity. There's an open PR for that (#425), but it stalled a while back (mostly my fault).

@stebo85
Copy link

stebo85 commented Jul 31, 2023

Dear @tsalo,

Although storing single channel data was something we had to do in the past to get proper phase combination offline, this is now solved quite well by proper channel combinations on the systems that deliver phase without singularities.

Would there be a tool that needs single channel data as an input which would really profit from this? My feeling is that adding this would complicate things without providing much benefit?

Even if single channel information would be seen as useful in BIDS, I would argue that it shouldn't be part of the SWI/QSM proposal, because it would affect also other modalities and would be something more general?

Thank you
Steffen

@tsalo
Copy link
Member

tsalo commented Jul 31, 2023

@stebo85, you definitely would know more about SWI than I do. The coil entity was part of the original SWI BEP, and I only broke out that element into a separate PR because I had some single-channel data on hand. If online coil combination methods are suitable at this point, then you can definitely drop the coil entity.

@Remi-Gau Remi-Gau added the MRI For things that affect all MRI datatypes label Sep 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
MRI For things that affect all MRI datatypes
Projects
None yet
Development

No branches or pull requests

4 participants