Hi,
I agree with Jesper, but just have a couple of little things to add
here.
The scale and offset can be applied to any storage type - including
float. So there is no guarantee of it ever being 1.0 and 0.0 for the
slope and offset. You need to look at the header!
Also, it might just be that the sinc output is stored as a float image
and by not looking at the header, you are interpretting it incorrectly
as an integer type. This would certainly explain your hard limited
max values.
All the best,
Mark
On 13 Jan 2010, at 15:46, Jesper Andersson wrote:
> Dear Joel,
>
> I don't think you actually see any rescaling. It would be
> interesting to know what you'd get with fslstats -M. I suspect it
> would be very similar for the different interpolation methods.
>
>> vol1_raw
>> ----------
>> method min max
>> tal_stat 0 396
>> fslstats (-R) 0 1021
>> fslstats (-r) 0 393.084991
>>
>> vol2_raw
>> ----------
>> method min max
>> tal_stat 0 364
>> fslstats (-R) 0 1100
>> fslstats (-r) 0 393.799988
>>
>> vol2_to_vol1_trilinear
>> -----------------------
>> method min max
>> tal_stat 0 441
>> fslstats (-R) 0 915
>> fslstats (-r) 0 383.385010
>
> With fslstats you see a reduction in the highest values (compared to
> raw values for vol2), which is pretty much what you would expect
> from trilinear interpolation. Your tal_stat command gives you
> increased values, which is really an impossibility. I suspect that
> the discrepancy between fslstats and tal_stat (which I am not
> familiar with) is caused by the fact that tal_stat doesn't use the
> header, which means that it always assumes a scale factor of 1.0 and
> an offset of 0. And this is not something that one can always assume
> for files created by an FSL application.
>
>> vol2_to_vol1_nearest neighbor
>> ------------------------------
>> method min max
>> tal_stat 0 472
>> fslstats (-R) 0 1012
>> fslstats (-r) 0 392.656006
>
> Again reasonable.
>
>> vol2_to_vol1_sinc
>> -----------------------
>> method min max
>> tal_stat 0 65535
>> fslstats (-R) -111 990
>> fslstats (-r) -0.900002 391.056000
>
> This is, as far as I can understand, your concern. It is true that
> flirt has rescaled the raw voxel values in the .img file, as
> evidenced by the big difference in tal_stat output. On the other
> hand the output from fslstats is still reasonable (you will often
> get negative undershoots from truncated sinc kernels), which shows
> that once the raw voxel values have been scaled and subtracted you
> get the correct values. So there hasn't been any rescaling of the
> images as a consequence of the sinc interpolation, just a rescaling
> of the raw voxel values.
>
> I am not 100% of this, but I suspect you might "solve" your problem
> by simply changing the type of your images before you do any
> analysis. If you do
>
> fslmaths vol2 new_vol2 -odt float
>
> you'll have a new copy of vol2 that now stores the voxel values as
> floating point. I _think_ that means that FSL will always use a
> slope and intercept of 1 and 0 respectively, which means that your
> inhouse software will get away with ignoring the header. If you now
> do your flirt resamplings on your new_vol2 it will retain the new
> type and therefore the slope and intercept should still be 1 and 0.
>
> Good luck Jesper
>
|