NiFTI-1.1 does in fact support both signed and unsigned int16: #define DT_INT16 4 ... #define DT_UINT16 512 /* unsigned short (16 bits) */
I don't know if this was the case in NiFTI-1.0, but NiFTI-1.1 has been around so long it would be strange if tools didn't support it, but did support 1.0. If dcm2nii or MRICron is treating them incorrectly, then you should contact the tool's authors. MRICron isn't reading it as analyze format, is it? The old analyze format doesn't support uint16. I don't know whether topup cares what the input datatype is. float32 can exactly represent any value of int16 or uint16, so it seems unlikely that conversion to float32 would cause problems (unless the data scaling and offset do something unusual...). Tim On Thu, Mar 3, 2016 at 2:42 PM, Garrett T. McGrath <[email protected]> wrote: > We've had a set of users that have discovered an issue with their latest > datasets that I'm hoping there might be a best practice for dealing with in > regards to FSL. > > I've received some specific context from the end users on what they are > capturing: > Users are collecting single-band spin echo EPI images in opposing phase > encode directions with the CMRR sequence (cmrr_mbep2d_se) on our 3T Prisma > to provide means of correcting for susceptibility distortions via FSL’s > ‘TOPUP’ tool. Their protocol parameters closely follow what is specified in > the HCP Q3 Release Appendix I. The dicom output of this data is UINT16 > which isn’t supported by nifti 1.0 format. Is there a recommended solution > that would play nice with FSL (TOPUP in particular) ? With the dcm2nii > conversion tool, we can either go ahead and set the data type to UINT16 or > set it to float32, but is there a specific recommendation from your end? > > I've verified the values using the MRICron tool to visually inspect values > and they are infact overflowing into negative numbers so we have a few > options: Force unit16 (out of standard), force Float32 (in standard but > larger, slower, and brings along the baggage of float numbers), divide all > intensities by 2 (lossy, I don't regard it as an acceptable solution for > raw data), or fall back on dicom files (I'm not clear if this is supported > by FSL). > > Any suggestions or feedback would be appreciated. > > Garrett McGrath > HPC and Research Computing > Princeton Neuroscience Institute, Princeton University > _______________________________________________ > HCP-Users mailing list > [email protected] > http://lists.humanconnectome.org/mailman/listinfo/hcp-users > _______________________________________________ HCP-Users mailing list [email protected] http://lists.humanconnectome.org/mailman/listinfo/hcp-users
