Thanks for the info. However, it appears that fslchfiletype also ignores
the scl_ values in the *.hdr and presumes they are 1.0, 0. I am
converting them to nifti, but get them from the software in ANALYZE format
with no option for nifti output.
I am able to modify them with other software, but could these be altered
after fslchfiletype conversion by a fsl utility?
John
***********************************************
John E. Richards
Carolina Distinguished Professor
Department of Psychology
University of South Carolina
Columbia, SC 29208
Dept Phone: 803 777 2079
Fax: 803 777 9558
Email: [log in to unmask]
<applewebdata:[log in to unmask]>
HTTP: jerlab.psych.sc.edu
*************************************************
On 1/17/13 8:55 AM, "Mark Jenkinson" <[log in to unmask]> wrote:
>Hi,
>
>It is definitely the case that Analyze images are not sufficiently
>standardised that all packages treat them equally. That is why the nifti
>format was created. We strongly encourage people to use nifti when
>possible in order to avoid such trouble. If you are forced to use
>Analyze then I would convert them into NIFTI as the first stage in your
>FSL processing (you can use fslchfiletype) and correct for the scaling
>errors at this stage (if there are any, since it should be consistently
>applied or not for all images).
>
>All the best,
> Mark
>
>
>
>On 17 Jan 2013, at 01:11, "RICHARDS, JOHN" <[log in to unmask]>
>wrote:
>
>> One further thought on this. Apparently the ANALYZE 7.5 format does not
>> define the scl_slope and scl_intercept values; these apparently were
>>first
>> used by SPM and became part of the NIFTI definition. Perhaps when fsl
>> utils are using *.hdr/*.img files defined as ANALYZE files, it ignores
>> these. I have found the fslmaths will use the scl_slope and
>>scl_intercept
>> if the file is a nii.gz file.
>>
>> Is this the reason?
>>
>> John
>>
>>
>>
>>
>> On 1/16/13 7:15 PM, "RICHARDS, JOHN" <[log in to unmask]> wrote:
>>
>>> I have ANALYZE MRI volumes from CURRY that have current density, which
>>>are
>>> values < 1. The HDR has "calibration scaling" set. When I use fslhd,
>>>or
>>> fslmaths, or fslmerge, with these files, it appears to not read the
>>> calibration scaling. ANALYZE/NIFTII has a calibration intercept and
>>> scale that is supposed to be applied to the store values. MRICRON
>>>reads
>>> these files correctly, shows the calibration scaling, and has voxel
>>>values
>>> with the scaling. If I use:
>>>
>>> Fslmaths inputfile.hdr -add 0 outputfile.nii.gz, then the scaling
>>>factor
>>> is not read; the fslstats -M reports a value that appears to be about
>>> x*scale, and when I view this in MRICron the individual voxels in the
>>> input file, * scale, are what are shown in the output file.
>>>
>>> So it appears the fsl utils are not reading the calibration scale.
>>>
>>> Any help?
>>>
>>> John
>>>
>>> ***********************************************
>>> John E. Richards
>>> Carolina Distinguished Professor
>>> Department of Psychology
>>> University of South Carolina
>>> Columbia, SC 29208
>>> Dept Phone: 803 777 2079
>>> Fax: 803 777 9558
>>> Email: [log in to unmask]
>>>
>>><applewebdata:[log in to unmask]
>>>u>
>>> HTTP: jerlab.psych.sc.edu
>>> *************************************************
>>>
>>>
>>>>
|