Hi,
I would say that the trouble you have here is not to do with FSL
but with the nifti format. The *definition* of the intensity stored
within a voxel is, according to the nifti format, the value stored
in the data segment scaled by the scl_slope value (and associated
offset, if set). So it is incorrect, according to the nifti format, to
save out your matlab image with a non-unity scaling factor
when you actually wanted unscaled values.
FSL is simply interpreting the nifti format according to its
definitions. It is the matlab processing which needs to be
modified to be correct.
Also, displaying the scaled intensities in FSLView is again
the only sensible thing that can be done according to the
nifti format. In general I prefer to work with floating point
images and a unity-scaling factor (easily achieved by
running an image through fslmaths with the -odt float
option) as this way you never have headaches with
respect to data range or scaling factors. This is just a
personal preference though - not in any way related to
the nifti standard.
All the best,
Mark
On 23 Feb 2010, at 16:13, Najmeh Khalili-Mahani wrote:
> Hi Dave, I get it now.
>
> To record, for future users:
>
> I ran into trouble because of importing the nifti raw (INT16) to
> matlab, doing quantitative analyses and then saving the result with
> the "same" header information (using save_untouch_nii), thus
> confusing FSL with an arbitrary scale slope (since it was already
> factored out of data through the analyses), hence magnifying my
> expected quantities by an order of ~2!
>
> Thanks everyone for your help.
>
> (Now, is there already a script to divide a 4D volume by a
> vector? ;) )
>
> Best
> Naj
>
>
>
>
> On Tue, Feb 23, 2010 at 3:20 PM, David Flitney
> <[log in to unmask]> wrote:
> I.e. the value IS 1165.95 regardless of underlying representation?
> This would seem entirely correct to me. The fact that the INT16
> value needs to be scaled by 2.268.... is correct. Otherwise when
> viewing the INT16 image it would, incorrectly, report an intensity
> of 514!!
>
> On 23 Feb 2010, at 13:19, Najmeh Khalili-Mahani wrote:
>
>> Thanks Matthew,
>>
>> However,
>>
>> in "raw" file 4D file A (INT16) intensity of
>> voxel(36,26,8,0) is 1165.95 and the scl_slope = 2.268376.
>> in vol0 of 'fslsplit'ted file (FLOAT32) intensity of voxel
>> (36,26,8) is 1165.95 and the scl_slope = 1.000000
>>
>> So, it seems to me that fslsplit has changed the data type, and the
>> scale-slope label, without scaling the actual intensities?
>>
>> ?
>>
>> Tnx,
>> Naj
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 23, 2010 at 1:36 PM, Matthew Webster <[log in to unmask]
>> > wrote:
>> Hi,
>> I just spotted that your file had a non-unitary scl_slope -
>> this means that your file is read in as a float to honour the
>> scl_slope value ( e.g. for voxel (36,26,8,0) the "raw" stored value
>> is 514, multiplied by the the scl_slope this gives 1165.95 which
>> will be the value used in our tools, and the output files will be
>> saved with the scaled values and a scl_slope of 1.0 ).
>>
>> Hope this helps,
>> Many Regards
>> Matthew
>>
>>> Hi Matthew,
>>>
>>> While at it, it seems that the fslsplit also sets the scl_slope to
>>> 1.00 (without scaling the intensities with the initial scl_slope?)?
>>>
>>> Many thanks
>>> Naj
>>>
>>>
>>> On Tue, Feb 23, 2010 at 10:10 AM, Matthew Webster <[log in to unmask]
>>> > wrote:
>>> Hello!
>>> I've been able to replicate this behaviour locally ( it
>>> seems to be for 4D splits only ) and we're looking into a fix...
>>>
>>> Many Regards
>>> Matthew
>>>> Hello;
>>>>
>>>> I just noticed that running fslsplit changed the data type?!
>>>>
>>>> I had a 4D image of (INT16) which is split into (FLOAT32) files.
>>>> Attached, the histograms. Top (float32), bottom (INT16).
>>>>
>>>> Many thanks
>>>> Naj
>>>> <bad_top_good_below.tiff>
>>>
>>>
>>
>>
>
> --
> Dave Flitney, IT Manager
> Oxford Centre for Functional MRI of the Brain
> E:[log in to unmask] W:+44-1865-222713 F:+44-1865-222717
> URL: http://www.fmrib.ox.ac.uk/~flitney
>
>
>
>
|