Implementation of a standard Bruker UTE sequence

[aTrotier]

Hi,
I am trying to implement in MRIReco the reconstruction pipeline for the 3D UTE sequence.
I don't have any issue to reconstruct the data if I am directly creating the AcquisitionData structure using the rawdata and trajectory.

I don't really know how to label the encoding counters for 3D non-cartesian acquisition. I can't use the kspace_encode_step_1 to store the number of projection because I have more projection than the Int16 limits (2^15).
I tried to use either :

kspace_encode_step_1= mod(nPhase2,2^15)
kspace_encode_step_2=div(nPhase2,2^15)

or just let that to 0 but I have an issue during the conversion from RawAcquisitionData to AcquisitionData in
function trajectory(f::RawAcquisitionData; slice::Int=1, contrast::Int=1) due to the use of EncSt1/2

traj = zeros(Float32, D, length(i1:i2), numEncSt1, numEncSt2, numSl, numRep)

traj[:, :, encSt1[l], encSt2[l], sl[l]-minimum(sl)+1, rep[l]-minimum(rep)+1] .= f.profiles[l].traj[:,i1:i2]

Do you have an idea how we can manage that problem without breaking the rest ?

Aurélien

[tknopp]

Is this the same issue as #68 ?
Ping @alexjaffray

I yesterday changed Int16 to UInt16 which gives you a factor of 2. Is that already sufficient?

If not we have a problem since this effectively means that one cannot convert BrukerFiles into ISMRMRD.

[aTrotier]

It is related to the same issue yes.

In my example changing to UInt16 is enough, I have 51360 projections for a matrix 128^3

But I can see some cases where it might failed :
Bruker define the number of projection as : pi * (size Matrix read)^2 thus for a matrix 192^3 gives 115000 projections.

If I let 0 in EncStep1/EncStep2, I can convert the data to ISMRMRD. For my understanding the EncSteps only means something for cartesian acquisition. It is directly the position in the k-space and not some non-informative indices. In non-cartesian, the trajectory associated should be enough.

Maybe we can just check the trajectory_dimensions if it is 2 then we still let the possibility to use EncStep2 (it can be a stack-of trajectory) and for 3 we don't use the encstep fields ?

[alexjaffray]

Interesting that we have a similar issue arising from two different sources.

I think that it might be a good idea to clearly state somewhere the use case for each encoding counter index (or where they shouldn't be used, for example encode step 1 as an index for trajectory interleaves). This would also lend itself well to writing a set of tests, to make sure the encoding counters are being properly incorporated into both AcquisitionData and RawAcquisitionData, and accounted for through any conversion between the two.

[aTrotier]

think that it might be a good idea to clearly state somewhere the use case for each encoding counter index (or where they shouldn't be used, for example encode step 1 as an index for trajectory interleaves)

in most of the case it might works with :
kspace_encode_step_1 for interleaves / projection for 2D or 3D stack of acquisition (+ kspace_encode_step_2 for the cartesian encoding)

But even for 2D I can see some very specific cases where it fails : dynamic imaging if you have a 2D golden angle trajectories without any repetition in the trajectory number for example.

Is that really important to store the number of the interleaves ? It is redondant with the trajectory, no ?

[aTrotier]

First try here : #79