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

Multi-slice acquisition with 3D phantom #474

Open
aTrotier opened this issue Sep 4, 2024 · 10 comments
Open

Multi-slice acquisition with 3D phantom #474

aTrotier opened this issue Sep 4, 2024 · 10 comments
Labels
bug Something isn't working

Comments

@aTrotier
Copy link
Contributor

aTrotier commented Sep 4, 2024

What happened?

Hi,
I would like to create a simultaneous multi-slice (SMS) example for a course.

First, I created with pypulseq a standard Multi-slice GRE sequence with long TR=1000ms in order to not worry about the spoiling.

The images are ok but with signal / contrast variation along the slice dimension
image

With phantom2D i have the same issue :
image

If I try with the EPI_MS from the example repository
I think I have the same issue (hard to tell with only 3 slices, I think it happens when I go further away from isocenter)

image

In order to change the slice position I am using this line of code in pulseq :

    rf_1.freq_offset = gz_1.amplitude * slice_gap * (sl - round((NSlices - 1) / 2))

Any idea ?

Environment

OS x86_64-linux-gnu
Julia 1.10.3
KomaMRIPlots 0.8.3
KomaMRIFiles 0.8.2
KomaMRI 0.8.2
KomaMRICore 0.8.3
KomaMRIBase 0.8.5
@aTrotier aTrotier added the bug Something isn't working label Sep 4, 2024
@JuliaHealth JuliaHealth deleted a comment Sep 4, 2024
@cncastillo
Copy link
Member

Hi! Hard to say. What do the different images mean? 20 slices are acquired simultaneously? or are the slices acquired sequentially?

Interestingly, the problem is also observed for the EPI_MS example; at least when simulating independently, the slice profiles have the same magnitude. Maybe a larger delay must be included between acquisitions for the magnetization to recover.

I will try running the MS EPI example using the development branch in #458, which should more precisely simulate RF pulses to discard a simulation accuracy problem

@aTrotier
Copy link
Contributor Author

aTrotier commented Sep 5, 2024

The slice are acquired sequentially. I also tried to acquire each slice in different sequence en get the same results :

Screenshot 2024-09-05 at 10 04 23

If needed you can find attach the sequence (.ipynb and .seq) and reco (.jl)
GRE_MS.zip

@aTrotier
Copy link
Contributor Author

aTrotier commented Oct 31, 2024

@cncastillo do you still observe this on the dev branch ?

I finally have some time to create the SMS example

@cncastillo
Copy link
Member

cncastillo commented Oct 31, 2024

Hi!, sorry for not looking at this earlier. Thanks for the patience, I was submitting my thesis and I was quite busy.

In the latest version Koma v0.9 I get this:

GRE_SMS_slX.seq
X = 0, 1, 2, 3, 4
image

Is this more similar to what you expected?

@aTrotier
Copy link
Contributor Author

aTrotier commented Nov 1, 2024 via email

@cncastillo
Copy link
Member

cncastillo commented Nov 1, 2024

Upon further examination, it seems that the phantom could be the problem. By default, brain_phantom3D is a thin slab of 2cm (z from -1cm to 1cm). The slice thickness (3mm) and slice gaps (10mm) of the sequence make it so the excitation goes beyond the phantom (x-axis in cm):

image

By modifying the phantom to

obj = brain_phantom3D(;start_end=[120, 240]) # z from -3 cm to 3 cm

I get:

image

Which looks a lot more uniform (XZ view vol[64,:,:]):

image

@aTrotier
Copy link
Contributor Author

aTrotier commented Nov 1, 2024 via email

@cncastillo
Copy link
Member

cncastillo commented Nov 1, 2024

The docstring for brain_phantom3D does not mention it, so that needs to be better explained. But it is mentioned here: https://juliahealth.org/KomaMRI.jl/stable/tutorial/04-3DSliceSelective/

A section at the end of that tutorial could be helpful, but ...

... even I forgot that brain_phantom3D was not the whole head. So maybe we can remove the start_end thing and always do the complete head. If a smaller slab is needed, the user can do obj[abs.(obj.z) .< 3e-2] (z from -3cm to 3 cm), for example. What do you think?

@aTrotier
Copy link
Contributor Author

aTrotier commented Nov 1, 2024 via email

@cncastillo
Copy link
Member

Yeah it sounds reasonable. I will do that now, and update the tutorial accordingly.

Off course, If you have any cool example I would be glad to put it in the tutorials as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants