Quick questions on the NKI sample:

The acquisition parameters say interleaved for the fMRI - is this ascending or descending?
Also what format/scale are the fieldmap images?

Thanks a lot and apologies if I've missed the answers elsewhere,
Jonathan

Hi Jonathan,

The NKI scanner is a siemens scanner, in that case interleaved is by definition ascending. Whether is starts at slice 1 or slice 2 depends on the number of slices. In this case the resting state scan has 38 slices, so the interleaved sequence will go 2,4,6,..38,1,3,5,...,37.

Could yoy maybe clarify your question regarding the fielmap images?

Maarten

Hi Maarten,

Thanks a lot - assumed ascending but wanted to be sure.

I'm afraid the question on fieldmaps isn't clear because I don't know a huge amount about them but I'll try to be specific...

There are two magnitude (I think) images available for most subjects:
fieldmapBOLDA_1/fieldmapBOLD.nii.gz
fieldmapBOLDA_1/fieldmapBOLDA.nii.gz
They appear to be an asymmetric split of the acquisition (22 slices in one image and 16 in the other) - how are they combined? (same question for the DTI acquisition)

Apologies if this is a bit of a naive question - I don't have any experience with field-maps.

All the best,
Jonathan

Hi Jonathan,

Yes, the two images in fieldmapBOLDA_1 are both magnitude images. It looks like dcm2nii split the phase image into fieldmapBOLD_1.

I'll follow-up when I get an answer about the split into the different slices...

Maarten

Don't spend too much time - I think I figured it out for 1 dataset at least (DTI and fMRI) last Friday - Ill see if I it generalises and post a fslsplit + fslmerge command tomorrow when I'm back at my desk.

Always delayed (this time by a month - a new record...).

The distribution of slices seem to be a bit random - in the fieldmapBOLDA folder the two created images have between 9 and 27 slices per image for fieldmapBOLDA.nii.gz and therefore between 29 and 11 slices per image for fieldmapBOLD.nii.gz. - they do go together but I'd need to figure out how manually for 200 odd datasets.


Is it possible to package up just the DICOMs of the fieldmap images and I'll try to put them together to nifti and send back?

All the best, 
Jonathan

Hi all,

Sorry to resurrect a zombie thread here, but was the issue with the split fieldmaps that Jonathan describes ever resolved?

Thank you,

Dylan

Kind of - I have them in a big tar file.

I reconstructed them back in 2011 and then changed jobs, forgetting to upload. I still have them so I'll try and get in contact with someone to upload them to the indi site.

Hi,

sorry to resurrect this post again,
my question is pretty simple, where are the fieldmaps stored in dicoms? It does not seems to be included in the big tars. Or maybe this is only for a subset of NKI_RS?
Many thanks for your help.
Cheers.
basile

I uploaded the fieldmaps stored as niftis to someone at NKI last March but they may have gone awol somewhere in between. I don't see them on the website.

I'm happy to upload again if needed - I think I found slice identifiers in the dicom headers and reconstructed them with an elaborate for loop but it was a few years ago so I don't entirely remember. If I remember, dcm2nii split the fieldmaps unpredictably.


Originally posted by Basile Pinsard:

Hi Jonathan,

yes I would be greatly interested by the fieldmaps, the test-retest data only would be nice if they exists, the purpose is to try to the benefit of use of fieldmap in preprocessing of both regular and multiband imaging, and reproducibility is always interesting to assess.

I would rather the dicoms than nifti converted, I personally used dcmstack to convert to nifti or even just for ordering the dicom slices, and I am quite happy with it. The fact is that you can create some specific ordering class to handle different constructor fields and also this enables to handle vendor specific scaling of the values which are meaningful in the case of fieldmaps contrary to other mri acquisitions.

Many thanks for you answer.
Cheers.

basile

Hi 

I would also be very interested in getting the fieldmap magnitude image correct to using in pre-proprocessing.

I also have a question about slice timing correction: this is a multi-slice parallel acquisition if i am not mistaken?  Which slices are acquired together? Where can we find this information?

Thank you!
Paul

Hi Paul

the way I found to get the slicetiming as this is Siemens data is to look in the csa header for the MosaicRefAcqTimes field.
for example using python nibabel you can do:

import nibabel.nicom.dicomwrappers
dw=nibabel.nicom.dicomwrappers.wrapper_from_file('NKI_enhanced/2475376/session1/RfMRI_mx_1400/IM-0001-0001.dcm')
dw.csa_header['tags']['MosaicRefAcqTimes']

{'items': [0.0,
615.00000001000001,
1230.0000000099999,
437.5,
1052.5000000099999,
262.50000001000001,
877.5,
87.500000009999994,
702.5,
1317.5,
527.50000001000001,
1140.0,
350.00000001000001,
965.00000001000001,
175.0,
790.00000001000001,
0.0,
615.00000001000001,
1230.0000000099999,
437.5,
1052.5000000099999,
262.50000001000001,
877.5,
87.500000009999994,
702.5,
1317.5,
527.50000001000001,
1140.0,
350.00000001000001,
965.00000001000001,
175.0,
790.00000001000001,
0.0,
615.00000001000001,
1230.0000000099999,
437.5,
1052.5000000099999,
262.50000001000001,
877.5,
87.500000009999994,
702.5,
1317.5,
527.50000001000001,
1140.0,
350.00000001000001,
965.00000001000001,
175.0,
790.00000001000001,
0.0,
615.00000001000001,
1230.0000000099999,
437.5,
1052.5000000099999,
262.50000001000001,
877.5,
87.500000009999994,
702.5,
1317.5,
527.50000001000001,
1140.0,
350.00000001000001,
965.00000001000001,
175.0,
790.00000001000001],
'last3': 77,
'n_items': 66,
'syngodt': 4,
'tag_no': 80,
'vm': 0,
'vr': u'FD'}

which seems to give the precise timing of each slice of the mosaic volume.

Cheers.

basile

Was this ever sorted? I'm working with the NKI - Rockland Sample (NIfTI) and I have to combine the slices of the magnitude images. The NIfTI header apparently gives no information on this.

Also, what are the two Echo times used? The header contains only one echo time.

In case any others come across this issue:
if you start with dicom files and use dcm2niix, and two magnitude nifti files will be generated with one correspoding to each echotime, and you will also see the following warning:
"Slices not stacked: echo varies (TE 4.92, 7.38; echo 1, 2). Use 'merge 2D slices' option to force stacking
Warning: Interslice distance varies in this volume (incompatible with NIfTI format)."
  
More digging gives me the following answer
"Specifically, when dcm2niix generates the warning Interslice distance varies for a Siemens fieldmap, it typically suggests that one of your tools that handles DICOM images has deleted some of the images. You can fix this by getting the images directly off of the console, or checking the tools that archive your DICOM images. It is not a problem with dcm2niix, but reflects data loss upstream. The core issue is that Siemens will generate identical Session, Series and Instance IDs for each echo in a field map. Many tools assume this means that these "identical" images are redundant, and randomly deletes one of the echoes. Which echo is deleted varies randomly for the 2D slices in a 3D stack."
 
Since fieldmap correction does not care which magnitude image to use (https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/F... also see below), you can force stack data from two echos to obtain one magnitude image using -m option.
"If you have data from a SIEMENS scanner then we strongly recommend that the tool fsl_prepare_fieldmap is used to generate the required input data for FEAT or fugue. Fieldmap data from a SIEMENS scanner takes the form of one phase difference image and two magnitude images (one for each echo time). In the following, where a magnitude image is required, pick the "best looking" one. This image is used for registration and masking but the process is not particularly sensitive to the quality and typically either image will work fine."

Oliver