CMRR-C2P / MB

Support for CMRR multi-band pulse sequences
http://www.cmrr.umn.edu/multiband/
MIT License
57 stars 20 forks source link

Banding artifact on 12-channel coil array #269

Closed jcaballeroi closed 2 years ago

jcaballeroi commented 3 years ago

Hi,

We are trying to accomplish SMS-accelerated functional and diffusion imaging and we are observing a significant banding artifact, especially in the standard-deviation map. We use the bold sequence (gradient-echo), version R016 on VE11P-SP04. Our scanner is a 3T Siemens Biograph_mMR (software version syngo_MR_E11), with a 12-channel coil array (head and neck coils active).

We did some of the tests suggested in other issues such as #67 (closed), #131, #99, #91, #217. Some of those who appear to solve the problem (as in #67) do not report the std or tsnr maps nor the coil array they used (only in #131, 20-channel), so we are unsure whether all these are really the same issue or different ones.

We would like to share our experience and to ask for any advances in this issue.

Based on the sequence's documentation we run some pilots assuming that a low multiband acceleration of MB=2 would perform reasonably, but we have observed a clear banding artifact in the slice direction, affecting mostly to the standard deviation and tsnr maps, but not (apparently) to the mean or single images.

Test 1: Excite pulse duration: In one test (as suggested in #217) we tried to increase the excite pulse duration on a gel phantom. [50 volumes; SliceTilt = -15º; resolution 3.25 mm isotropic; PE: A>P; FA = 76º; TR = 3690 ms; TE = 30 ms; BW = 2400 Hz/pix; partial Fourier 7/8; iPAT none; interleaved slice-timing scheme; LeakBlock on].In our case, the artifact appears to be related to an increase of standard deviation in the middle of the multi-band "block", i.e., away from the center and edges of the image (figure not included, but with MB=3 three bands appear). Note that it is not evident in the mean image. The pulse duration didn't appear to have an effect. We also see some ghosting in the phase direction, even with no acceleration. Banding_Pdur

Test 2: Grappa/Multi band: We tested for the effect of different acceleration factors (Grappa=1, 2; MB = 1, 2), holding all other parameters equal: [50 volumes; SliceTilt = ACPC-15º; 3.25 mm isotropic; PE: A>P; FA = 83º; TR = 2710 ms; TE = 30 ms; excite pulse duration = 4000us; BW = 2400 Hz/pix; partial fourier 7/8; interleaved slice-timing scheme; LeakBlock on]. An abrupt change in the std occurs in the slice direction at exactly the half of the image. The effect is clearly specific from multi band acceleration, although it appears to get worse in combination with GRAPPA: Banding_MB_Grappa

Test 3: Slice-timing scheme: In the same session of Test 2 and with the same acquisition parameters, as sugested in previous issues (#37) also tried to change the slice-timing scheme (sequential/interleaved), observing no effects: Banding_Seq

Test 3: Slice orientation In the same session, we tested for the effect of the coil geometry, which appears to be the main problem with 12-channel coil arrays (https://practicalfmri.blogspot.com/2019/02/using-multi-band-aka-sms-epi-on-on-low.html) by acquiring in coronal with PE=L>R, seeking for a greater sensitivity heterogeneity. Again, the same acquisition parameters, but with iPat=Grappa2 and for MB1 we had to reduced the number of slices to maintain the TR. Aside from the obvious distortion in PE, and the higher tsnr in occipital, we don't see any evident banding in the slice direction: Banding_coronal

Have there been any advances to accomplish low-acceleration SMS with this kind of coil arrays with a normal axial or axial-tilted orientation? There are more parameters that we can tweak to improve quality?

Regards, Jaime

mharms commented 3 years ago

If this is a 12 ch "head + neck" coil, then I'm guessing that there are probably only 8 channels specific to the head? It simply might not have a coil geometry that works well to un-alias axial scans. 2x total acceleration is the most you can reasonably hope for with only 8 head channels (if my guess is correct). Thanks for sharing -- nice set of images.

jcaballeroi commented 3 years ago

Thank you very much @mharms for your quick and sincere response.

Your guess about the channels, although we activated the 4 neck channels just in case they contributed for unaliasing.

I understand that we can't go with mid or high accelerations, but we hoped that the lowest multiband factor could be achievable somehow. Does this mean that even multiband factor of 2 is completely impossible with this kind of coil geometry?

Thanks Jaime

whitecraine commented 3 years ago

Given this seems more related to coil geometry limitations, there's probably not much that can be done. However, you could try modifying some of your reconstruction options which could influence g-factor related noise:

From the acquisition side, you could try tilting your slices more or changing the PE direction. If your coil is like the 12 ch head coil shown in the practical fmri blog post, there is clearly no coil encoding information along the axial direction unfortunately. Btw, do you happen to have a link or photo of your coil? I know Siemens has a 20 and 64 ch head/neck coils but I didn't know they have a 12 ch version. If you have a chance, it may also be worth trying with the neck coils off (in case they are mainly contributing noise to the reconstruction).

mharms commented 3 years ago

@whitecraine: Recently I noticed a Prisma protocol that had Matrix Optimization = Performance for its dMRI and fMRI SMS scans (using the Siemens product SMS sequences). What does that feature do?

whitecraine commented 3 years ago

Siemens product SMS defaults to turning it on but I've not evaluated recon performance with vs without yet. The help menu says it is a form of coil compression (lowers the effective number of channels) which increases recon speed and presumably reduces raw k-space data size. So depending on how the compression is done and how many channels there are, it's possible using it might increase the g-factor penalty.

On Thu, Jun 10, 2021 at 7:14 AM Michael Harms @.***> wrote:

@whitecraine https://github.com/whitecraine: Recently I noticed a Prisma protocol that had Matrix Optimization = Performance for its dMRI and fMRI SMS scans (using the Siemens product SMS sequences). What does that feature do?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/CMRR-C2P/MB/issues/269#issuecomment-858659300, or unsubscribe https://github.com/notifications/unsubscribe-auth/AATFYMFLZAR53CA3GGGNLX3TSDCD7ANCNFSM43XECA5A .