Error converting Spiral from mMR to ismrmrd

[NikEfth]

When converting a spiral acquired with WIP 992, I get the following error.
I am using the mMR.

WARNING: Unexpected number of mystery bytes detected: 32 
ParcFileEntries[1].off_ = 17950720 
ParcFileEntries[1].len_ = 1045908128 
siemens_dat.tellg() = 1063858816 
Please check the result. 
WARNING: End of file was not reached during conversion. There are 384 additional bytes at the end of file. 

Have encountered any similar problems?

[hansenms]

It's not exactly an error. Is the conversion failing? and what is mMR?

[NikEfth]

Thank you for your prompt reply!

Is the conversion failing?

This is a good question. We don't have the means to reconstruct this dataset accurately.
As far as I understand, 3D spiral with Gadgetron is not supported yet.

However, running siemens_to_ismrmrd -f XXX.dat -z 2 -X
a colleague got some promising results with some custom reconstruction.
Without the flags -z 2 -X, the executable does not create an mrd file.

and what is mMR?

It is this scanner here

[hansenms]

Not totally sure how to help here, -z 2 means the second measurement in the dat file. The first one is probably dependencies. -X just means to dump some debug information, so I am guessing it is the -z 2 that "makes it work" for you and you get an ISMRMRD file. If you can reconstruct (with some reconstruction), then that would seem to be OK, or am I missing something?

[NikEfth]

In the images, we get some strong artifacts (primarily truncation for now), and I am trying to figure out whether this could have something to do with the warning.

[hansenms]

Trying to debug this from reconstructed images is probably going to be tough. I would start by validating that you have the right number of readouts (acquisitions) in the dataset and that each of the readouts have the correct number of samples. I would also check the XML header to see if it it has the expected information. If that checks out, it is probably not a conversion problem.

[NikEfth]

Hi all,
I am picking up this thread. I have made a lot of progress and practically I am able to reconstruct most of the data I acquire.

However, in some datasets, not all of them this flag gets triggered

 if ((scanhead.aulEvalInfoMask[0] & (1ULL << 10)))
       ismrmrd_acq.setFlag(
               ISMRMRD::ISMRMRD_ACQ_IS_SURFACECOILCORRECTIONSCAN_DATA);

I know that the data are part of the k-space, so some times this bit flags inaccurately as correction data.
Any ideas?

[fzimmermann89]

I believe this could be a misnomer of the flag:
If I understand correctly, scanhead.aulEvalInfoMask[0][10] signifies that the data needs a raw data correction, i.e. acquisitions with this flag enabled should be multiplied by a factor. The factor can be found in the raw file as dRawDataCorrectionFactorRe / dRawDataCorrectionFactorIm for each coil.
I think it does not mean that this data is actual correction data and can be ignored.

Not sure if this is a bug in the converter or just unfortunate naming, either way it is a bit non-obvious how to interpret ISMRMRD_ACQ_IS_SURFACECOILCORRECTIONSCAN_DATA and could maybe be documented somewhere.

Maybe somebody with more knowledge about the Siemens data and the ISMRMRD specification can chime in?

Rel:ismrmrd/ismrmrd#246