Dear Todd,
If the images that you receive contain this scaling information then
any processing on them in FSL, including converting them to nifti with
avwchfiletype, will result in this information being lost, which is a
problem.
So I recommend checking the funused fields (you can look at the
output of avwhd) and if they are zeros then you can proceed without
problem. If they are not zero then you will need to convert them to
nifti format some other way - maybe with SPM functions, or with other
conversion software on the web, or with a script that uses avwhd
and avwmaths to apply the scaling to the data.
All the best,
Mark
On 7 Mar 2006, at 20:50, Todd Penney wrote:
> Hi Mark and other FSLers,
>
> Thanks for the response. I just have one more quick question. I
> receive image files from my colleagues in Analyze 7.5 format. I
> converted them to NIFTI format using the avwchfiletype command
> before using them in SPM5 or FSL. I preprocess my data using both
> SPM5 and FSL with the new image files in NIFTI format. Could there
> be a potential scaling problem here?
>
> Thanks
>
> Todd Penney
>
> Quoting Mark Jenkinson <[log in to unmask]>:
>
>> Dear Todd,
>>
>> The inconsistencies are eliminated by having a common standard
>> that is properly defined and that everyone has agreed upon how
>> to interpret. The scaling information is now contained in fields
>> called scl_slope and scl_inter rather than in the funused* fields.
>> In the Analyze format some packages decided to use the funused
>> fields to store information about scaling, but the standard said
>> nothing about this, as these fields were designated as *unused*.
>> Hence some packages do use this info and some don't. In Nifti
>> it is defined at the outset and so packages need to be able to
>> deal with it in order to be properly nifti-compliant.
>>
>> When converting to and from SPM outputs, these scalings in Analyze
>> can be a problem, but in the nifti format they will be read in
>> correctly
>> and dealt with by FSL. Note that images that we output always have
>> scaling set to unity, however, in order to simplify our internal
>> code base.
>>
>> Hope this answers your questions.
>> I expect that the use of Analyze format will diminish rapidly over
>> the
>> next couple of years, so I strongly encourage everyone to use the
>> nifti format if they can.
>>
>> All the best,
>> Mark
>>
>>
>> On 6 Mar 2006, at 17:38, Todd Penney wrote:
>>
>>> Hi Mark,
>>>
>>> I just had a question about his response you sent. How does
>>> NIFTI file format get rid of these inconsistencies in format?
>>> What does NIFTI file format do to avoid the issues with
>>> intensity scaling the images? Are the funused1, funused2 and
>>> funused3 fields in Analyze files the variables that control the
>>> image intensity? What are these variables normally set to? Are
>>> there any issues you are aware of with scaling (or anything
>>> else) when using avwmerge/ avwsplit with NIFTI files?
>>>
>>> Thanks
>>>
>>> Todd Penney
>>>
>>>
>>> Quoting Mark Jenkinson <[log in to unmask]>:
>>>
>>>> Dear Ged,
>>>>
>>>> Nifti was introduced precisely in order to get rid of these
>>>> inconsistencies
>>>> in format, like the scaling in the Analyze format. As all the
>>>> major
>>>> software packages, including FSL and SPM, are moving away from
>>>> Analyze support, this is no longer going to be an issue in the
>>>> future.
>>>>
>>>> I would strongly encourage you to avoid Analyze format if possible.
>>>> It is likely to support for the Analyze format will be dropped
>>>> in the
>>>> future.
>>>>
>>>> |f you really need to extract this information from the SPM Analyze
>>>> files you can script it yourself by looking at the funused1 and
>>>> funused2
>>>> fields in the avwhd output. By using these with avwmaths it is
>>>> easy
>>>> enough to rescale appropriately.
>>>>
>>>> All the best,
>>>> Mark
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 28 Feb 2006, at 16:52, Ged Ridgway wrote:
>>>>
>>>>> Andreas Bartsch wrote:
>>>>>> Hi,
>>>>>> it is a non-standard analyze extension.
>>>>>
>>>>> But if converting from such an image to NiFTI -- where it is
>>>>> standard:
>>>>>
>>>>> http://nifti.nimh.nih.gov/nifti-1/documentation/nifti1fields/
>>>>> nifti1fields_pages/scl_slopeinter.html
>>>>>
>>>>> couldn't this be preserved? It seems to be used in the exact
>>>>> way suggested in the NiFTI standard, and it does seem to be a
>>>>> useful extension (e.g. for having probability images stored
>>>>> as integers).
>>>>>
>>>>> Best,
>>>>> Ged.
>>>>
>>>>
>>
>>
|