Mismatch encoding limits - encoding matrix

[ckolbPTB]

The encoding matrix describes the size of the k-space which needs to be encoded based on the resolution and FOV settings. Commonly data acquisition is then carried out in this matrix (or smaller due to partial fourier or undersampling). This means the encoding limits are smaller or equal to the matrix.

There are cases where this is not the case. If the encoding matrix along PE is 188 but the number of samples per shot (e.g. PE points acquired after a prep-pulse or a trigger signal) is 20, then actually 200 PE samples will be obtained leading to the encoding limits of [0, 199].

For Cartesian sampling this currently breaks then e.g. here https://github.com/PTB-MR/mrpro/blob/9abbd8c90563d5b922f42757314d2902de615627/src/mrpro/operators/_CartesianSamplingOp.py#L128.

Easy solution would be to ignore points outside of encoding_matrix but of course it would be nicer to extend the encoding_matrix to include these points. This would require image-based interpolation to achieve to correct resolution.

[fzimmermann89]

But wouldn't doing an interpolation kind-of defeat the some of the purpose of a Cartesian FFT? To get from, say, 0.9mm resolution to 1mm resolution correctly would most likely involve an interpolation at least as expensive as the FFT... (Fastest might actually be to crop in fourierspace....)

If an encoding_matrix smaller than what is actually acquired is specified, I would assume that the k-data is cropped to the matrix size. (similarly, if the matrix if bigger I might assume zero padding to match the matrix...)

If I want to use all available data, I would have to increase the matrix in the header. I would vote for doing exactly what is specified as best as possible and printing a warning: "There is unused k-space data that could be used is the matrix size is increased by setting kdata.header.encoding_matrix = increased matrix size "

Or am I misunderstanding the issue?

[ckolbPTB]

Yes, that makes sense. I was thinking we could have the 0.9mm during the entire iterative recon and then have an interpolation step at the end, but I agree that in the end this wouldn't be much different from reconstructing the 1mm data in the first place.

We could (a) ignore them when we read in the data and not put them into kdata.data. Advantage: kdata.data does not contain anything which is later ignored. (b) ignore them in the CartesianSamplingOp. Advantage: The encoding_matrix can be easily adapted after reading in the data to include the additional samples

Any preferences?

[fzimmermann89]

Let me think about it... If we decide to do (a), we should output in the warning a mention of the override setting. Still, just setting kdata.encoding_matrix later on is conceptually easier.

What is the expected result if you do not use the cartesian sampling operator, but instead do a nufft?

[fzimmermann89]

... and do you have some example data?