Issue with Minnesota s-LASER TE & water references

[CWDAVIESJENKINS]

Hi Will

We've acquired some data using the latest Siemens s-LASER sequence from Dinesh Deelchand at Minnesota and I encountered two issues when using spec2nii to convert the data:

1. The TE is not correctly recognized in the NIfTI (TWIX and DCM). Looking at the TWIX header, it seems the sub-echo times are stored separately (they're specified separately in the exam card) and spec2nii grabs the first sub-echo time, rather than the full TE.
2. Relatively minor but thought I'd flag it, spec2nii doesn't identify when users acquire the water reference as a part of their protocol. In our case, we acquired 4 unsuppressed averages-two stored before the water-suppressed transients and two afterward.

I have a workaround for both of these in our data, so no urgency, and I'm happy to share the de-identified data if it would be useful to you!

[wtclarke]

Hi @CWDAVIESJENKINS I thought I had got specific handling code for this sequence, see this line, but maybe a slightly different sequence, and I don't think I've tried to handle it through twix. In twix are the reference scans flagged using different MDH flags (which would be nice)?

Regarding the TE, is that in the main TE field or is that in one of the special card parameters?

[wtclarke]

That code is looking for a very specific sequence name svs_slaservoi_dkd, perhaps not the best way of identifying it.

[CWDAVIESJENKINS]

Hi Will,

Thanks so much for the response.

In twix are the reference scans flagged using different MDH flags (which would be nice)?

Unfortunately not, they seem to be packaged into the same set. Perhaps it's readable via the special card, though?

Regarding the TE, is that in the main TE field or is that in one of the special card parameters?

It's in the main TE field: hdr.MeasYaps.alTE.

That code is looking for a very specific sequence name svs_slaservoi_dkd, perhaps not the best way of identifying it.

Our sequence is irritatingly closely named: %CustomerSeq%\svs_slaserVOI_dkd2. I'm guessing this is the issue, regarding the reference transients?

Chris

[wtclarke]

Hi Chris,

I've make a partial fix to the above by changing the name check to regex rather than an explicit string. Is there any chance you could sling me some data to test the TE issue on? Do you have any phantom data I could host permanently as a test? Finally, will this just be on VX scanners or any on XA as well? The headers are different, so would be good to fix both TEs in one if possible.

Will

[wtclarke]

I've just released a new version that should fix a few of these things, but I haven't yet touched the Twix implementation. Let me know if you have some test data fro that.

[CWDAVIESJENKINS]

Thanks so much, Will!

Unfortunately, we don't currently don't have any phantom data for this sequence but I can send some de-identified participant data to test the TE issue for now. I'll drop you an email. We don't have an XA30 scanner on site, so it'll just be Vx, but I'll look into acquiring some phantom data between sessions as a longer-term test set.

Thanks again, Chris

[wtclarke]

Hi @CWDAVIESJENKINS , Has this now been sorted with the recent additions? Or is something still outstanding?

[wtclarke]

@CWDAVIESJENKINS Any update? Keen to close or address.

[CWDAVIESJENKINS]

HI @wtclarke ,

Apologies, I didn't see your previous message. I'll check this next week and let you know.

Thanks, Chris

[CWDAVIESJENKINS]

Hi @wtclarke ,

Apologies, by next week, I apparently meant next month... I just re-tested this data and it converted without issue. Thanks so much for you help!

Chris

[wtclarke]

Thanks for checking.