You have to be clear when you say support. I don't know what you're trying to do, but you can put anything you like in the extension part of the nifti header. If you want to store TR, TE, flip angle, mother's date of birth, you can. You just have to write the code to handle it. Other programs that support nifti properly but don't know about your fields will silently ignore them. AFNI stores a lot of information in the extension fields. They are very useful for certain applications.
-SI On Aug 28, 2012, at 1:50 PM, dgw wrote: > Ok, so I guess my problem is that the formats don't support it. Sorry > for the run around. > > D > > On Tue, Aug 28, 2012 at 1:46 PM, Inati, Souheil (NIH/NIMH) [E] > <souheil.in...@nih.gov> 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
