Dear John,
Yes, you can just take the unscaled nifti image (the one created by fslchfiletype) and multiply the values with fslmaths to scale them correctly (this will stored the scaled values directly, and not the unscaled ones together with a scaling factor, but I think storing the scaled values is less error prone). To figure out the scaling factor you should be able to use fslhd on the Analyze file and extract the funused1 value (if I remember rightly this is what SPM interpreted as the scaling slope).
All the best,
Mark
On 17 Jan 2013, at 16:47, "RICHARDS, JOHN" <[log in to unmask]>
wrote:
> 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
>>>> *************************************************
>>>>
>>>>
>>>>>
|