bruker2dicom: echoNumbers missing in dicom + different acquisitionNumber for the same serie

[michaelkain]

Dear Julien,

thank you a lot for Dicomifier, he works well and is amazingly fast.

I will sent you the example I am talking about via email.

In the example the serie Serie: FLI_02_T2map_MSME-128x128_CERMEP contains 144 images.

When bruker2dicom is called and I import the data into Shanoir, I realized two things, where I am not sure about, as I am not the total expert:

• echoNumbers are missing in all dicom files (not only in the above serie)
• acquisitionNumbers are different within the serie (16 datasets are created in Shanoir),
  but imageOrientationsPatient are the same (not sure if this helps)

Thank you a lot for having a look,
Michael

[lamyj]

The series we're dealing with is a multi-slice multi-echo sequence with 16 echo times, 9 parallel and equally-spaced slices, and a single repetition. I think the generated DICOM and NIfTI files are correct: we are getting a 4D NIfTI file with 16 3D volumes, each of them having 9 slices. Additionally, the values of EchoTime in the JSON file are matching those in the Bruker file.

Regarding AcquisitionNumber, I chose to store the Frame Group index in this element, which in this case is equal to the echo number. The DICOM standard is a bit vague regarding this field ("a single continuous gathering of data"), but if we are thinking about 3D images (and not k-space), this is not too far from the truth.

Regarding EchoNumbers, this is a bit tricky. We would actually need to have the details of the loop structure to know if we're acquiring one echo per TR, or several with refocalization. Logic (and the official Bruker doc for the MSME sequence) tells us we have refocalization, but, to the best of my knowledge, this information is not present in the Bruker file.

I'm not actually sure whether I can do something about this. Out of curiosity, why do you need the Echo Number for?