thanks Souheil Bruce
On Tue, 28 Aug 2012, Inati, Souheil (NIH/NIMH) [E] wrote: > Hi Bruce and Freesurfers, > > The standard part of the nifti_1 header specifies that the first three > dimensions are space and the fourth dimension is time and you can store > dX,dY,dZ,dT and units. This page has a nice description of that part of the > standard: > http://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/nifti1fields_pages/xyzt_units.html > "Time" can be TR, TE, frequency, whatever. > > Whether or not these fields are set correctly is dicom converter dependent. > I have no idea what most converters out there do. If memory serves (which it > does less and less in my middle-age), the converter that I was involved in at > NYU (written by Valerio Luccio, http://cbi.nyu.edu/software/dinifti.php) > assumes that you are doing fMRI and puts the TR in the fourth dimension. > Note also that what the label 'TR' means is another pulse sequence/vendor > specific story. For evenly sampled fmri experiments we know what we're > talking about. For other things, not so clear. > > If you want to use the extension fields in the nifti header, then you could > put more information there, but there's no real convention on how to do this. > > This is all a mess. NIFTI is not a real data format. It's just a hack to > get us past the misery that was fmri analysis software interoperability in > the 1990s. Unfortunately, DICOM is worse. I'll back off of that > inflammatory comment and say that for a restricted set of imaging, NIFTI is > great and very useful, but it's not a good all purpose MRI image storage > format. Someday the MNI guys will win and we'll end up with a real HDF5 > based format. > > If any of you are still reading this, there is an interesting project being > put forward by the ISMRM and the MRM journal for a standardized format for > MRI raw data storage. The idea is that you can have reproducible research in > image reconstruction unless you agree on a file format. It's just getting > off the ground, and it's not that useful for post processing, but the idea is > to store all the scan parameters and the raw k-space data and sampling > pattern, including things like diffusion encoding, physiological signals, > etc. Here's a link: > http://ismrmrd.sourceforge.net > > Cheers, > Souheil > > On Aug 28, 2012, at 12:39 PM, Bruce Fischl wrote: > >> Hi Souheil, >> >> does NIFTI store the MR parameters? >> >> thanks >> Bruce >> >> On Tue, 28 Aug 2012, Inati, Souheil (NIH/NIMH) [E] wrote: >> >>> On most (all?) scanners TR is stored as an integer. For example, on >> siemens it's in microseconds and then stored as a long. (this is the value >> in the protocol, not the actual execution TR, but when/if there are no >> bugs, then this is correct). When you convert a long to float (single or >> double precision) you will get some junk in the low bits because of type >> conversion. In the dicom it's all string representations. >>> >>> Does the dicom say 50.000 or 50? >>> How does the conversion from int >>> >>> -- >>> >>> Souheil Inati, PhD >>> Staff Scientist >>> Functional MRI Facility >>> NIMH/NIH/DHHS >>> souheil.in...@nih.gov >>> >>> >>> >>> >>> On Aug 28, 2012, at 12:06 PM, Bruce Fischl wrote: >>> >>>> does NIFTI support the MR parameters? I'm not sure it does. I suspect >>>> that 50 is correct and not 50.000000745058060 (can you imagine setting >>>> that on the console)? >>>> On Tue, 28 Aug 2012, dgw wrote: >>>> >>>>> Hi, >>>>> >>>>> I'm not sure if this is a bug report or a feature request. I have been >>>>> using mri_convert to convert dicoms to nii.gz and mgz files, and I >>>>> have noticed some discrepancies when reading the volumes in with >>>>> MRIread in either matlab or octave. The volumes differ in their >>>>> support of the flip angle, tr, te, and ti fields (I realize some of >>>>> this may be due to file type differences). Thought the standard output >>>>> of mri_convert shows the expected values. >>>>> >>>>> In the mgz file the TR seems to be rounded i.e. >>>>> 50 instead of 50.000000745058060 in the nii.gz >>>>> >>>>> In the mgz file the flip angle and te are recorded >>>>> FA 0.52.... while in the nii.gz it is 0 >>>>> te 10.39... while in the nii.gz it is 0 >>>>> >>>>> The ti value appears strange to me in the mgz >>>>> ti = -1 while in the nii.gz it is 0 >>>>> >>>>> I have generated two files using mri convert off of the same MR volume >>>>> as a test case: >>>>> /cluster/hbot/agario_p2_2/dcm/020_t1_fl2d_tra_TEMP/004/877000-000020-000003.dcm >>>>> >>>>> /cluster/hbot/agario_p2_2/dcm/020_t1_fl2d_tra_TEMP/004/volume.nii.gz >>>>> >>>>> /cluster/hbot/agario_p2_2/dcm/test.mgz >>>>> >>>>> These files were generated using /usr/local/freesurfer/stable5_1_0/ >>>>> >>>>> Thanks, >>>>> D >>>>> _______________________________________________ >>>>> Freesurfer mailing list >>>>> Freesurfer@nmr.mgh.harvard.edu >>>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Freesurfer mailing list >>>> Freesurfer@nmr.mgh.harvard.edu >>>> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer >>>> >>>> >>>> The information in this e-mail is intended only for the person to whom it >>>> is >>>> addressed. If you believe this e-mail was sent to you in error and the >>>> e-mail >>>> contains patient information, please contact the Partners Compliance >>>> HelpLine at >>>> http://www.partners.org/complianceline . If the e-mail was sent to you in >>>> error >>>> but does not contain patient information, please contact the sender and >>>> properly >>>> dispose of the e-mail. >>>> >>> >>> >>> >>> > > > > _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
