Open schuenke opened 7 months ago
Do we have any progress here?
Is this caused by the converter? Or the sequences? Or pulseq? Or the scanner?
How does recon_matrix get set anyways if using pulseq? At least the encoding_matrix issue is something (I think) should be fixed upstream somewhere. Question is where.. (The recon_matrix might be something that connot be fixed without writing a valid ismrmrd header for each sequence.)
Currently, the header information for the
recon_matrix
andencoding_matrix
extracted from the ismrmrd header of siemens raw data files acquired with Pulseq sequences are not correct.For my example cases, the following information were off:
kdata.header.recon_matrix.y
this value seems to be twice as high as it should be. Like an oversampling factor.kdata.header.encoding_matrix.z
this value defaults to 2 instead of 1 for 2D acquisitions.Interestingly, the y-value is wrong for recon, but correct for encoding and the z-value is correct for recon, but wrong for encoding.
Not sure where we want to catch this. Maybe we can discuss it in the next meeting, because there might be several options along the entire pipeline like trying to fix it in the seq-files, in the converter, in the data loader, in the trajectory calculator etc ...