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 HCP-Users@humanconnectome.org http://lists.humanconnectome.org/mailman/listinfo/hcp-users
