Hi - yes it may depend on the context/pipeline but for simplicity and safety 
pretty much everything we do just works in floats.
Cheers

> On 3 Mar 2016, at 21:18, Harms, Michael <mha...@wustl.edu> wrote:
> 
> 
> Maybe Steve or MJ can chime in regarding the FSL issues, but I do recall 
> there being some concern years ago whether ‘FSL’ was fully compliant with 
> UINT16 NIFTI’s.
> 
> Regardless, in terms of what we are currently using, it is FLOAT32.
> 
> -- 
> Michael Harms, Ph.D.
> -----------------------------------------------------------
> Conte Center for the Neuroscience of Mental Disorders
> Washington University School of Medicine
> Department of Psychiatry, Box 8134
> 660 South Euclid Ave.  Tel: 314-747-6173
> St. Louis, MO  63110  Email: mha...@wustl.edu
> 
> From: <hcp-users-boun...@humanconnectome.org 
> <mailto:hcp-users-boun...@humanconnectome.org>> on behalf of Timothy Coalson 
> <tsc...@mst.edu <mailto:tsc...@mst.edu>>
> Date: Thursday, March 3, 2016 at 3:14 PM
> To: "Garrett T. McGrath" <gmcgr...@princeton.edu 
> <mailto:gmcgr...@princeton.edu>>
> Cc: "hcp-users@humanconnectome.org <mailto:hcp-users@humanconnectome.org>" 
> <hcp-users@humanconnectome.org <mailto:hcp-users@humanconnectome.org>>
> Subject: Re: [HCP-Users] Negative Voxel Values signed int 16 vs uint16 issue
> 
> 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 <gmcgr...@princeton.edu 
> <mailto:gmcgr...@princeton.edu>> 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
>> HCP-Users@humanconnectome.org <mailto:HCP-Users@humanconnectome.org>
>> http://lists.humanconnectome.org/mailman/listinfo/hcp-users 
>> <http://lists.humanconnectome.org/mailman/listinfo/hcp-users>
> 
> _______________________________________________
> HCP-Users mailing list
> HCP-Users@humanconnectome.org <mailto:HCP-Users@humanconnectome.org>
> http://lists.humanconnectome.org/mailman/listinfo/hcp-users 
> <http://lists.humanconnectome.org/mailman/listinfo/hcp-users>
> 
>  
> The materials in this message are private and may contain Protected 
> Healthcare Information or other information of a sensitive nature. If you are 
> not the intended recipient, be advised that any unauthorized use, disclosure, 
> copying or the taking of any action in reliance on the contents of this 
> information is strictly prohibited. If you have received this email in error, 
> please immediately notify the sender via telephone or return mail.
> _______________________________________________
> HCP-Users mailing list
> HCP-Users@humanconnectome.org
> http://lists.humanconnectome.org/mailman/listinfo/hcp-users


---------------------------------------------------------------------------
Stephen M. Smith, Professor of Biomedical Engineering
Head of Analysis,  Oxford University FMRIB Centre

FMRIB, JR Hospital, Headington, Oxford  OX3 9DU, UK
+44 (0) 1865 222726  (fax 222717)
st...@fmrib.ox.ac.uk    http://www.fmrib.ox.ac.uk/~steve 
<http://www.fmrib.ox.ac.uk/~steve>
---------------------------------------------------------------------------

Stop the cultural destruction of Tibet <http://smithinks.net/>






_______________________________________________
HCP-Users mailing list
HCP-Users@humanconnectome.org
http://lists.humanconnectome.org/mailman/listinfo/hcp-users

Reply via email to