Sparse sampling with MB BOLD EPI

[jk619]

Hi,

We are trying to introduce a delay at each TR for auditory research. The idea is to present the stimulus first and acquire the data later so that the stimulus does not overlap with the scanner noise (so called SPARSE sampling). We modified the standard EPI sequence (epfid2d1_104) on our 3T Prisma with multi band factor = 6 and added a delay of 2.4 sec at each TR. Design shown below.

We first acquired data with an ascending slice order and found a block (band?) artifact.

We later tested the interleaved slice order and this made things worse as it additionally introduces zigzag pattern in the slice direction

Lastly, when we collect the data using exactly the same sequence without the delay everything seems to be ok.

I was wondering If anyone has ever encountered a similar artifact and could advise on how to remove it. This seems to be the same problem as discussed.

This seems to be the same problem as discussed here - > #266, so apologies for reposting. I couldn't however find a solution there so I made a new post with data acquired in our center.

thanks, Jan

[mharms]

This is a consequence of the physics of the acquisition when you try to use sparse sampling -- namely, you don't have a steady-state of T1 magnetization recovery. If you examine the slice timing info in the json's returned by dcm2niix you'll see that the temporal interval between the acquisition of adjacent slices is not equal across all slices. That, plus the fact that the slice excitation profiles are not perfect, results in non-steady state effects. The comments in #266 still seem like a good place to start.

[BenInglis]

Hi Jan, it sounds like you're using the product "Delay in TR" parameter which will prevent a true T1 steady state. Issue #266 is indeed reporting the same thing. But from R014 there has been an alternative, a "Sparse TR acq" option which disables the read and phase encode gradients but leaves slice selection on through the quiet(er) periods as usual. This keeps the magnetization at approximately the same steady state throughout. It's in the documentation. Cheers! Ben

[jk619]

Ok, thank you! I'll try the "Sparse TR acq"

[JWinawer]

In principle, the 'Sparse TR acq' can be a useful option. We tried it. However, the slice selection gradients in our sequence were still too loud, so unfortunately this did not solve our problem. We may go back to the "Delay in TR" but with fat saturation turned off, as suggested by julfou81 in issue #266.

[JWinawer]

Indeed, the 'Sparse TR acq' did not work for us because it was too loud during the supposed quiet periods. Instead, we used the "Delay in TR" option and turned off fat suppression. This has worked pretty well.

[mharms]

Aren't you getting a lot of shifted fat signal?

[JWinawer]

Not sure if it's a lot of shifted fat signal but certainly some. I guess it's a matter of picking your poison. So far we have not come up with a perfect solution but remain eager to hear ideas. We are always happy if we can get better data.

[eauerbach]

Another possibility is to try an experimental option: if you enable the normally hidden SparseTRSchemes UI as described in the Wiki linked below, the option (2) for the "Sparse TR acq. scheme" parameter will remove the spoiler gradients around the fat saturation pulse as well as remove the slice refocus gradient. This should reduce the acoustic noise, as only the slice select gradient will remain, but for some protocols maybe there is a risk of introducing artifacts (I don't think it was carefully tested). If that is still too much noise, the RF pulse length could be increased to reduce the slice select gradient. If that is still not enough but seems promising, I could add another option to soften the slice select gradient ramps ("whisper" mode).

https://github.com/CMRR-C2P/MB/wiki#advanced-sequence-options

[nie-xingju]

thanks again for your help!

I tested the SparseTRSchemes = 0 vs 2 after adding the MBAdvancedSettings.ini file since the SparseTRSchemes=2 is much quieter than default SparseTRSchemes=0 . My Sparse paradigm is 4 sparse TR followed by 4 acquisition TR. I extracted whole brain signal from 3 slice and plotted it. I could see the first data after 4 sparse TR (number 1, 5, 9, .... 281, 285) generally has 0.5% higher signal than the rest 3 data acquisition . It looks to me this is more obvious for SparseTRSchemes = 0 (dark blue, grey and orange line) than SparseTRSchemes = 2 (yellow, green and light blue line) (maybe it is scanned later and there is more motion?)

What are your suggestions about this first data? Should I discard the first data out of the 4 TRs from data analysis?

thanks in advance!

Another possibility is to try an experimental option: if you enable the normally hidden SparseTRSchemes UI as described in the Wiki linked below, the option (2) for the "Sparse TR acq. scheme" parameter will remove the spoiler gradients around the fat saturation pulse as well as remove the slice refocus gradient. This should reduce the acoustic noise, as only the slice select gradient will remain, but for some protocols maybe there is a risk of introducing artifacts (I don't think it was carefully tested). If that is still too much noise, the RF pulse length could be increased to reduce the slice select gradient. If that is still not enough but seems promising, I could add another option to soften the slice select gradient ramps ("whisper" mode).

https://github.com/CMRR-C2P/MB/wiki#advanced-sequence-options

[nie-xingju]

I repeated the test by scanning myself. I tried my best to stay still in the magnet and tested Sparse TR acq. Scheme = 2 first then followed by Scheme =0. It looks very obvious for Scheme =0 (dark blue, grey and orange line) that the first TR acquisition has higher signal than the rest of 3. however the patten is not very as clear for option = 2 (yellow, light blue and green line). Any suggestion is appreciated!

[julfou81]

Hi @nie-xingju , this is very interesting. According to your results, it looks like the steady state is not reached for those acquisitions, like if the scanner was totally off (like there were no rf nor slice selection gradient!) during the silent TRs! Did you compare with a similar paradigm but without any noise during the silent TR (no rf nor gradient played explicitly asked) to see if the pattern is the same or bigger? Which scanner and which Syngo version are you using?

[nie-xingju]

Hi @nie-xingju , this is very interesting. According to your results, it looks like the steady state is not reached for those acquisitions, like if the scanner was totally off (like there were no rf nor slice selection gradient!) during the silent TRs! Did you compare with a similar paradigm but without any noise during the silent TR (no rf nor gradient played explicitly asked) to see if the pattern is the same or bigger? Which scanner and which Syngo version are you using?

thanks and my observation is that option = 0, which is supposed to best preserves the steady state (the slice select, slice refocus, and fat saturation spoiler gradients are still present and will make some noise) turned out not as good as Option (2) in preserving steady state. however let me be clear that for my 4 sparse + 4 acquisition paradigm, the 1st signal after 4 sparse is about 0.5% higher signal than the rest 3 data acquisition.

for your comments that " the scanner was totally off (like there were no rf nor slice selection gradient!) during the silent TRs", which is option = 1 if I understand correctly, the first signal is about 55% higher than stead state signal and it would takes about 8-10 seconds to reach stead state again.