 |
 |
Hi, I'm not what you mean by "pixmax". Do you mean the maximum intensity stored in the image, as returned by fslstats with -R ? If so, then this is really confusing. However, if you are talking about "calmax", which is stored in some images to indicate the preferred display range, then this is not unexpected and relates to what is stored in the reference image, as this is just copied over. I would be amazed if you have an image that stores intensities less than 400 which then ends up with intensities up to 65535. Can you check the intensities with FSLView and let us know what is happening there? It is also possible that a scaling factor is stored in the image which is being applied to the intensities, which non-FSL software might not be using correctly (the scaling factor is part of the NIfTI standard, but nothing is really "standard" in Analyze I'm afraid). If you can let me know the answer to the queries above then hopefully we can help. All the best, Mark On 8 Jan 2010, at 06:47, joel bruss wrote: > I have two input images, both unsigned short (0-65535 (with pixmax > around 400). After registering vol2 to vol1, with flirt, using sinc > interpolation, the output gets rescaled 0-65535 (with pixmax = > 65535). Does flirt, by default, rescale images or is there some > obvious flag that I'm missing that will force no-rescaling? > > FWIW, I'm running a vanilla registration like so (with the dreaded > Analyze format (Nifti I/O doesn't appear to make any difference)): > > > flirt -cost mutualinfo -interp sinc -datatype short -dof 12 -in > vol2.hdr -inweight vol2_whole.hdr -ref vol1.hdr -refweight whole.hdr > -searchrx -2 2 -searchry -2 2 -searchrz -2 2 -v -bins 20 -omat > vol2_to_vol1_whole_masked.xfm -out vol2_to_vol1_whole_masked > > flirt -interp sinc -datatype short -in vol2.hdr -ref vol1.hdr - > applyxfm -init vol2_to_vol1_whole_masked.xfm -out > vol2_to_vol1_whole_masked_sinc > > > If you use trilinear interpolation there are no rescaling issues. > Is this normal? Any help would be appreciated.