FourierOp Norm

[fzimmermann89]

At least two potential issues with Fourier Op:

• I thought to norm of FourierOp should always be 1?
• Forcing use of nufft should result in the same as using the cartesian operator -- just slower, or?

Currently, the answer two both is "No" This adds the tests showcasing the potential problems

[github-actions[bot]]

Coverage Report

File	Stmts	Miss	Cover	Missing
src/mrpro/algorithms/csm
inati.py	24	1	96%	44
walsh.py	16	1	94%	34
src/mrpro/algorithms/dcf
dcf_voronoi.py	53	4	92%	15, 48–49, 76
src/mrpro/algorithms/optimizers
adam.py	20	1	95%	69
src/mrpro/algorithms/reconstruction
DirectReconstruction.py	28	16	43%	51–71, 85
IterativeSENSEReconstruction.py	13	1	92%	76
Reconstruction.py	50	22	56%	42, 54–56, 80–87, 104–113
RegularizedIterativeSENSEReconstruction.py	41	17	59%	96–100, 114–139
src/mrpro/data
AcqInfo.py	128	3	98%	26, 169, 207
CsmData.py	29	3	90%	15, 82–84
DcfData.py	45	8	82%	18, 66, 78–83
IData.py	67	9	87%	119, 125, 129, 159–167
IHeader.py	75	7	91%	75, 109, 127–131
KHeader.py	153	17	89%	25, 119–123, 150, 199, 210, 217–218, 221, 228, 260–271
KNoise.py	31	15	52%	39–52, 56–61
KTrajectory.py	69	5	93%	178–182
MoveDataMixin.py	137	18	87%	15, 113, 129, 143–145, 207, 305–307, 320, 399, 419–420, 422, 437–438, 440
QData.py	39	7	82%	42, 65–73
Rotation.py	674	35	95%	100, 198, 335, 433, 477, 495, 581, 583, 592, 626, 628, 691, 768, 773, 776, 791, 808, 813, 889, 1077, 1082, 1085, 1109, 1113, 1240, 1242, 1250–1251, 1315, 1397, 1690, 1846, 1881, 1885, 1996
SpatialDimension.py	232	22	91%	33, 103, 128, 135, 141, 261–263, 276–278, 312, 330, 343, 356, 369, 382, 391–392, 407, 416, 420
acq_filters.py	12	1	92%	47
src/mrpro/data/_kdata
KData.py	134	18	87%	109–110, 125, 132, 142, 150, 204–205, 243, 248–249, 268–279
KDataRemoveOsMixin.py	29	2	93%	44, 46
KDataSelectMixin.py	19	2	89%	48, 63
KDataSplitMixin.py	48	3	94%	53, 84, 93
src/mrpro/data/traj_calculators
KTrajectoryCalculator.py	25	2	92%	23, 45
KTrajectoryIsmrmrd.py	13	2	85%	41, 50
KTrajectoryPulseq.py	29	1	97%	54
src/mrpro/operators
CartesianSamplingOp.py	89	2	98%	118, 280
ConstraintsOp.py	60	2	97%	46, 48
DensityCompensationOp.py	14	3	79%	32–34
EndomorphOperator.py	65	2	97%	228, 234
FiniteDifferenceOp.py	27	2	93%	40, 105
FourierOp.py	160	3	98%	266, 384, 389
Functional.py	71	5	93%	20–22, 117, 119
GridSamplingOp.py	136	9	93%	72–73, 82–83, 90–91, 94, 96, 98
LinearOperator.py	171	12	93%	55, 91, 190, 220, 261, 270, 278, 287, 295, 320, 418, 423
LinearOperatorMatrix.py	158	16	90%	82, 119, 152, 161, 166, 175–178, 191–194, 203, 215, 304, 331, 359
MultiIdentityOp.py	13	2	85%	43, 48
Operator.py	78	2	97%	25, 74
ProximableFunctionalSeparableSum.py	39	3	92%	50, 103, 110
SliceProjectionOp.py	173	8	95%	44, 61, 63, 69, 206, 227, 260, 300
WaveletOp.py	120	5	96%	152, 170, 205, 210, 233
ZeroPadOp.py	16	1	94%	30
src/mrpro/utils
filters.py	62	2	97%	44, 49
slice_profiles.py	46	6	87%	20, 36, 113–116, 149
sliding_window.py	34	1	97%	34
split_idx.py	10	2	80%	43, 47
summarize_tensorvalues.py	11	9	18%	20–29
typing.py	18	11	39%	8–23
zero_pad_or_crop.py	31	6	81%	26, 30, 54, 57, 60, 63
TOTAL	4877	357	93%

Tests	Skipped	Failures	Errors	Time
2293	0 :zzz:	18 :x:	0 :fire:	2m 46s :stopwatch:

[github-actions[bot]]

:books: Documentation

:file_folder: Download as zip :mag: View online

[fzimmermann89]

Note to myself: wondering if this could also cause issues with self-supervised training.

Should check if F(subset of trajectory)(image) = F(image)[subset] -- which might also be a good test.

[fzimmermann89]

Also, what was the outcome of #381 ?

[fzimmermann89]

@ckolbPTB @schuenke

[ckolbPTB]

I thought to norm of FourierOp should always be 1?

I don't think this holds for arbitrary FourierOps. If a FourierOp only yields an undersampled k-space then the Norm will not be 1. Also if padding or cropping of image-space/k-space is required (mismatch of recon_matrix and encoding_matrix) the norm will not be 1.

Here I verified that FFT and NUFFT lead to the same result: https://github.com/PTB-MR/mrpro/blob/3c6d873cd72afe1feda0abba93d677036d783b9f/tests/operators/test_non_uniform_fast_fourier_op.py#L51

for recon_matrix == encoding_matrix and fully-sampled k-space.

The oversampling-parameter of the NUFFT I am not sure about. All the packages I know do not ensure that the norm is independent of this parameter but this does not mean it is the correct thing to do.

[fzimmermann89]

It should also match for all of the common MR trajectories. Otherwise, a tiny trajectory change would result in a scaled image -- which would be quite surprising. Ill try if I can make these tests pass..

[koflera]

I thought to norm of FourierOp should always be 1?

I don't think this holds for arbitrary FourierOps. If a FourierOp only yields an undersampled k-space then the Norm will not be 1. Also if padding or cropping of image-space/k-space is required (mismatch of recon_matrix and encoding_matrix) the norm will not be 1.

Here I verified that FFT and NUFFT lead to the same result:

https://github.com/PTB-MR/mrpro/blob/3c6d873cd72afe1feda0abba93d677036d783b9f/tests/operators/test_non_uniform_fast_fourier_op.py#L51

for recon_matrix == encoding_matrix and fully-sampled k-space.

The oversampling-parameter of the NUFFT I am not sure about. All the packages I know do not ensure that the norm is independent of this parameter but this does not mean it is the correct thing to do.

For the Fast Fourier operator, the operator norm should always be be one (if norm="ortho" is used, which we always have, right?), regardless of full or undersampling. For the general FourierOp, the norm will indeed not always be one.

[fzimmermann89]

My current opinion:

As we calculate the operator norm using the gram, it should be independent of the norm setting in the fft as long as it's the same in fft and ifft (we only use fft.gram for our operator norm)

Nufft and fft should match for on grid trajectories.

Nufft scaling should be independent of grid size.

An undersampled fft should always have norm <=1: The eigenvektor with energy only at sampled k space points has the highest ew. If and only if this is also ev to ew 1 of the fully sampled fft, the norm will be one. (Imdersamplimg only removes eigenvalues)

A zero padded fft should have norm 1 It's eogencektor will be the zero padded eogencektor of the normal fft.

I think depending on how to normalize, we can either make the zero padded(oversampled) or undersampled fft have norm 1.

What can't be norm 1 are transforms with row sum>1 - repeated samples in the Nufft. Here, dcf@fourier should have norm 1