We usually use Twix data with Gannet and our results look very reasonable.
As the new version provides option to use also nii data, we converted our twix to nii using spec2nii. But Gannet results of the converted nii data are very different than the original twix data - much worse, I’d say unreasonable.
Here is an example of GannetFit for the original twix and for the converted nii
To convert we used:
It looks like the data are not in the correct format. I wonder if something went wrong during the conversion from TWIX to NIfTI. I see that there are fewer data points in the TWIX output compared to the NIfTI output. Usually, there are extra points in the TWIX data that need to be removed during data loading.
@wclarke: Is the below command correct for converting TWIX to NIfTI when using spec2nii?
That command looks right. No truncation of datapoints before the centre of the echo will happen with spec2nii, perhaps it should for data if the offset is robustly available in the raw data.
The fields that hold the number of points acquired before the top of the echo vary between sequence implementations. The SiemensTwixRead function I wrote for Gannet back then should get the correct fields for the most common implementations, though certainly not all, I think we added a few newer ones in our io_loadspec_twix function in Osprey. We also lop these extra points off right away after loading, hence the difference in points.
Does that mean that nii files created with ‘spec2nii twix’ cannot be used for analysis with Gannet?
Should we process the twix file (remove the datapoints?) before converting to nii?
I tried to see what the results would be if I converted dicom data to nii. But with the nii files converted with ‘spec2nii dicom’, Gannet Load keeps showing this error
I looked at another example data. In this case there are no difference between data points, and in dat there are 0 points before echo. But the results for nii version are still ‘wrong’.
I don’t know whether it matters but the volume dimensions are different between dat and nii versions.
The fields that hold the number of points acquired before the top of the echo vary between sequence implementations
That’s why it isn’t in spec2nii as default. I haven’t spent the effort to write something for all the cases I know of. Though TBH if Siemens and CMRR are (self)consistent that’s many of the sequences.
@dace I think your last screenshot revealed the problem. The order of the transients are different; it looks like there are all the control/saturation transients then all the saturation/control transients (i.e. saturation, saturation, …, control, control,…). For twix, they are just interleaved: control, saturation, control, saturation, … This is probably interacting with the gannet code and the differencing is going wrong.
If you run mrs_tools info path/to/converted/file.nii.gz what’s the output? Does it have a shape 1x1x1x4128xNCoilsx128x2 with dimension tags DIM_COILS, DIM_DYN and DIM_EDIT? (NCoils is probably 32). Or is it 1x1x1x4128xNCoilsx256 with dimension tags DIM_COILS and DIM_DYN.
If you run mrs_tools info path/to/converted/file.nii.gz what’s the output? Does it have a shape 1x1x1x4128xNCoilsx128x2 with dimension tags DIM_COILS, DIM_DYN and DIM_EDIT? (NCoils is probably 32). Or is it 1x1x1x4128xNCoilsx256 with dimension tags DIM_COILS and DIM_DYN.
It returns the following:
NIfTI-MRS version 0.7
Data shape (1, 1, 1, 4128, 32, 2, 128)
Dimension tags: [‘DIM_COIL’, ‘DIM_EDIT’, ‘DIM_DYN’]
Spectrometer Frequency: 123.229393 MHz
Dwelltime (Bandwidth): 4.167E-04s (2400 Hz)
Nucleus: 1H
Field Strength: 2.89 T
Thanks! That looks right. Do you have fsl-mrs installed? If so you could see if the crude combination looks right with mrs_tools vis --display_dim DIM_EDIT path/to/file.nii.gz.
OK, again that looks roughly right, less the 1st order phase that we know about, and perhaps a little noisier than the comparison. @mmikkel Any thoughts on what might be up?
@dace, are you able to share an example of a dataset that is both the .dat and .nii.gz format? Tbh, I’ve only really tested NIfTI-MRS data that were converted from the GE P-file .7 format.
I’ve discovered the issue. As @wclarke noted above, the spec2nii-converted .dat > .nii.gz data are stored blockwise: i.e., all edit-OFFs first, then all edit-ONs. Gannet was assuming they were interleaved. I’ve added a fix for this. Please update your version of Gannet.
You will notice a slight difference in the post-alignment spectra/metabolite levels. This is a result of a certain subroutine in the alignment algorithm that deals with very strong water suppression, which applies a random change to transients across datasets during the actual alignment. Systematically, this should not be an issue for within-dataset reproducibility.
However, I’ve discovered a new issue: the .nii.gz dataset results in incorrect voxel co-registration with the anatomical image. Specifically, it is flipped L-R compared to the .dat dataset. At present, I’m unsure whether this is a Gannet or spec2nii conversion issue.
@dace: Could you please confirm if the voxel should be in the left or right insula?
@wclarke: Have geometry issues for converted .dat > .nii.gz data been a problem before?
I’ve attached all the Gannet output from both data formats for your reference.
The orientation of Siemens data is something I’m fairly confident on. I have a (I hope) well tested pathway to convert twix/.dat orientation information into the Image Orientation/Position (Patient) tags of DICOM, and then both go through a pathway lifted from dcm2niix to calculate the NIfTI affine. I then produce images like the ones below in the testing of spec2nii to validate against the orientation specified on the scanner. I test using spec2nii, dcm2niix, and fsleyes.
@dace If you were willing, would you mind also sending me the data? @mmikkel what do things look like in fsleyes (or MRIcro)? Or could you send me the original T1s, the nii converted by gannet and the raw and nifti MRS data?
Running fsleyes CBU_MPRAGE_32chn_20220310153233_series002.nii.gz meas_MID00199_FID32114_CBU_svs_mpress_GABA_INS.nii.gz gives me the below view, with the MRS voxel appearing on the right and matching the Gannet .dat processing.
fslhd reports the following for the mrs
and the following for the T1
FSLeyes reports the voxel centre position as [36, 24, -14] i.e. the same as reported by Gannet for .nii (i.e. when it appears wrong). I think this makes sense because multiplying [0,0,0,1] with the above affine gives this position. So not sure what is going on inside the Gannet code.
I opened both datasets’ MRS mask images in MRIcroGL with the concomitant anatomical image, and as you see below, it’s definitely a Gannet visualization issue. I will work on a fix
@dace, @wclarke, looking back at the Gannet data, it’s specific to Gannet’s CoRegister output but not the Segmentation or Quantification output. I will need to add a fix.
@dace, note, however, that there is a slight difference in the voxel compositions depending on how voxels are co-registered if the data are .nii.gz or .dat. This is not specific to the data but to the co-registration code.
