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
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
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.inati@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.
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.inati@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.
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_pa... "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.inati@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.
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_pa... "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.inati@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.
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.inati@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_pa... "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.inati@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.
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.inati@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_pa... "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.inati@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@nmr.mgh.harvard.edu
-
Bruce Fischl -
dgw -
Inati, Souheil (NIH/NIMH) [E]