Sorry - didn't spot the -datatype short.
That will definitely force the output to be short.
Ah, but you were getting a max of 65535 which
is not in the range of a *signed* short, which is
what these images would be (see the nifti standard
for datatype 4, which is what these would be).
Hence I think it was just the slightly negative
ringing which was causing signed short values
which were being misinterpretted as up at 65535,
since the max a signed short can store is 32767.
That, I think, is the answer to the riddle!
All the best,
Mark
On 14 Jan 2010, at 17:20, joel bruss wrote:
> Mark-
>
> 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.
>
> Perhaps I'm misunderstanding you, but I used "-datatype short" on
> both the registration and application of transform (first try). On
> my second go, I first converted both inputs to float, and then used
> "-datatype float" and got more reasonable values. Will flirt,
> regardless of "-datatype" flag, output as float then?
>
> -Joel
>
>
> On Wed, Jan 13, 2010 at 10:47 PM, Mark Jenkinson
> <[log in to unmask]> wrote:
> 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
>
>
|