MP2RAGE

[mathieuboudreau]

branch: mp2rage

We might be able to write one, the original author has MATLAB code available to do this on github: https://github.com/JosePMarques/MP2RAGE-related-scripts

He just doesn't have a license, we could open an issue and ask if he'd be willing to upload a license that's permissive that allows for reuse (e.g. MIT).

[mathieuboudreau]

Spoke with Jose Marques by email today, and he gave us the green light to integrate his code into a qMRLab model. I'll get started on it after the VFA interactive notebook gets released, as the MP2RAGE notebook will be the next interactive notebook.

[mathieuboudreau]

To do:

• Copy files from https://github.com/JosePMarques/MP2RAGE-related-scripts into repo
• Upload data files to OSF
• Create empty template MP2RAGE model, and make sure it opens.
• Copy demo script from Marques' repo into MP2RAGE template, and make it run when "Fit data" is clicked.
• Refactor how data inputs are handled
• Refactor how options are handled, but still use hardcoded values
• Create GUI options, but don't replace the hardcoded values in the code yet
• Assert that the default input options are equal to the hardcoded demo values
• Replace hardcoded values by passed options values
• Refactor to handle optional B1 map case

[agahkarakuzu]

@mathieuboudreau
Difference between T1corrected.nii (B1 corrected, original output, uint16) and T1.nii.gz (B1 corrected in qMRLab, double).

Differences may be due to compression and data type. To ensure, fit using orig code and compare outputs in matlab workspace.

• Do one more comparison
• Add B1map range control/correction

This is how the mp2rage panel looks like:

[ileppe]

Hi @mathieuboudreau @agahkarakuzu! I'm trying out this model for some data that I have, I want to test different B1maps. Can I make a couple of comments/suggestions, that either I can incorporate if we agree or whoever is working on this?
1 - It's not clear which combination of inputs is required, I tried inputting just the 2 magnitude images and got an error
2 - RepetitionTimes-Exc(s): that's the echo spacing right? I think this should be named the same as it is on the protocol (Siemens or other), otherwise it's difficult to know what it's referring to
3 - How would someone find the NumberOfShots. Can we give them an idea based on the other parameters? Maybe more info in the tooltip?
4 - Inversion Efficiency: should we have a more extensive tooltip describing what this should be? How would a user know what to put here?

Thoughts?

[mathieuboudreau]

Hi @ileppe!

Thanks for the feedback! I think @agahkarakuzu was the last one to work on this just prior to the ISMRM deadline, and I don't think it's been touched since.

Brief explanation of a few things: the code used for this model is from this repo, from the author that wrote the initial paper. As far as I know, this model has only been tested for example data in that repository, so there might be a lot of use cases that we'll need to figure out as we encounter other data.

1 - I believe that the data required is the magnitude images of from both measurements (both inversion times); that's from reading the documented class. But maybe @agahkarakuzu refactored it to use the combined MP2RAGE image (what Marques calls "UNI" in his example data I think), but he'll have to chime in.

2- I think that's a naming convention that Agah used from BIDS. If I were to guess, it's the repetition time in MP2RAGE between the excitation pulses (as opposed to between the inversion pulses). If you see two repetition times in your protocol, it should be the short one.

3- re: number of shots, I was always curious as to how this would pan out in practice. I'm not entirely sure without seeing the pulse sequence or protocol files how this can be extracted (and how other groups extract it). Essentially, if it there is no accelerations or partial Fourier, it will be half of the number of acquisitions within one of the inversion time measurements (you have to look at the pulse sequence figure to understand it better), assuming that the center of k-space is acquired at that point. I'm not sure how this is automatically extracted from BIDS, @agahkarakuzu do you know?

4- Yes, a tooltip would be helpful. I think it's mostly guesswork, as I've only seen 0.96 being used. It's an estimate of how good your 180 degree pulse is I think.

Hope some of this helps, please feel free to contribute to this branch (unless @agahkarakuzu says otherwise).

[spinicist]

Hi,

QUIT has an MP2-RAGE program here

1 - The MP2-RAGE sequence produces two raw complex volumes. These then get combined into what Siemens calls the UNIform image, and from there you can make a T1 map via a lookup table (I went a step further and used spline interpolation in QUIT). You need the complex data to correctly deal with the signal null. I prefer to start from the raw data and produce my own UNI image, because the Siemens product recon does not implement the regularisation in this paper: http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0099676 and so you get background noise. In QUIT, the user can produce a regularised UNI image but the T1 map is always calculated from the unregularised image to avoid bias.

2 - There is indeed a lot of confusion about what to call this value. I can't remember what it is called in the Siemens protocol, but:
a) It's not the same across vendors - on GE this will be called TR
b) "Echo Spacing" is a term more associated with Fast-Spin Echo, where you have an "Echo Train" from a single excitation and multiple refocussing pulses. I argue strongly against using this term for MP2-RAGE for the very practical reason that there are people doing multi-echo MP2-RAGE, and at that point the echo-spacing naturally refers to the spacing between echoes from a single excitation, not the time between excitations.

3 - Something doesn't look right here. There should only be one value for the number of "shots", and the number of shots is more likely to be 1 or 2 than >30. I think there is a confusion between the number of shots/segments and the number of k-space lines acquired per shot/segment. It's the latter that is required for the MP2-RAGE signal equation. In QUIT I used the term SegLength for this. In principal, you can work out the segment length from the number of PE steps and the number of segments/shots, but in practice that is hard because of partial k-space/parallel imaging, so I strongly recommend changing to this.

Anyway - tl;dr the number you want from a Siemens protocol is the Turbo Factor, which is also a term inherited from Turbo Spin Echo (Fast Spin Echo).

[agahkarakuzu]

Hi @ileppe @mathieuboudreau and thanks @spinicist for the input!

1. There are two common MP2RAGE inputs to calculate T1 maps that I've observed so far: i) UNI image and ii) 2 magnitude and 2 phase images. Given that (i) is the combination of (ii), all input data are optional for this model, yet the inputs are controlled in this fashion:
   

   qMRLab/src/Models/T1_relaxometry/mp2rage.m

   Lines 94 to 116 in ca4b07e

   	if noINV1mag && noINV1phase && noINV2mag && noINV2phase && ~noUNI
   	availabledata.onlyUNI = true;
   	elseif ~noINV1mag && ~noINV1phase && ~noINV2mag && ~noINV2phase && noUNI
   	availabledata.allbutUNI = true;
   	elseif ~noINV1mag && ~noINV1phase && ~noINV2mag && ~noINV2phase && ~noUNI
   	availabledata.all = true;
   	warning(sprintf(['=============== qMRLab::Fit ======================\n' ...
   	'MP2RAGE data is available. Data from the following fields will not be used for T1 mapping:\n' ...
   	'- Inv1mag \n -INV1phase \n -INV2mag \n -INV2phase' ...
   	'If you would like to use the data listed above for fitting, please leave MP2RAGE directory empty.']));
   	else
   	error(sprintf(['=============== qMRLab::Fit ======================\n' ...
   	'Required data is not provided to perform T1 fitting.']));
   	end

That's why you ran into an error with 2 magnitude images only.

2. @mathieuboudreau is right, implementation is from this repo but the naming is a mixture of BIDS and pymp2rage at the moment. @spinicist summarized this clearly. I don't know its Siemens equivalent off the top of my head either, will try looking at some Siemens data.

3. The definition of number shots in BIDS is here. It indeed corresponds to the excitations before and after kspace center, but I see the confusion you had with the naming. I think pinging @Gilles86 here is a good idea , he can let us know how widely adopted is the parameter name NumberShots by MP2RAGE users.

As for regularized robust combination, the implementation is included in our repo , however we decided not to add it to the model for simplicity.

[ileppe]

Thanks all for the discussion!
2- I guess that's the issue, Siemens calls it Echo spacing and it refers to the spacing between excitation pulses. Wouldn't you agree that when you have multiple echoes (ME-MP2RAGE), they would be specified by different TEs?
3- I opened up Xbuilder on the Siemens console, and there are parameters called #exc. before and #exc. after, which must be what is being referred to in that repo? So not NumberOfShots but NumberOfLines. I don't know if that makes into the DICOM header though. For my protocol, #exc. before=60 and #exc. after=120, TurboFactor=16. So if I understand correctly, the QUIT code and JosePMarques code differ in how they choose to read in the # of lines per shot/segment. TurboFactor is definitely easier to find, at least on the Siemens protocol.