 |
 |
Dear Steven: This is caused by roundoff errors in reading and writing images. My understanding is that when images are stored I believe that the largest values in the image are set to the maximum value for that image datatype and the scale factor is adjusted accordingly. For example, if the values in your image are 1, and the datatype is integer then the actual data value store is 32767 and the scale factor is 3.0159e-5 (multiply the two together and you get 1.000). However, you don't actually get 1 you get if you look past the 9th decimal place, you get 0.999999999068677.... The result is close enough for image calculations, but is not precisely 1. The problem occurs because you are trying to compare two floating point values, which are not actually equal. If you instead type this round(tmp(find(tmp>0)))==1 you will find that the result is as you expect. The reason volumes are written this way I think has to do with trying to save images as chars or ints when the actual values are floating point. By scaling the actual value I can save a number as an integer but get back the fraction when the image is read in. John Ashburner probably has a better explanation if necessary. Darren Quoting Steven Lacey <[log in to unmask]>: > This is a duplicate. I forgot to include a subject last time. Sorry! > > Hi, > > I have a binary image file. Each element of the matrix is either a 0 or > 0.0312. I want to extract percent signal change using software that applies > a 0.5 threshold to each voxel. So, I want to convert all 0.0312s to 1s. To > do this I use spm_imcalc passing in 'i1>0.03' as the expression to evaluate. > This seems to work. When I load in the new image file, all values >0 are 1s, > as printed in the matlab window. However, if I ask if these displayed 1s are > truly 1, that is, tmp(find(tmp>0))==1, not one of the displayed 1s are > actually 1. Why would this be? The value is 1 < x < 0.999. Is this behavior > related to matlab or spm? I have tried setting pinfo to [1 0 0] in hopes of > elminating this behavior, but it did not make a difference. Any insights on > the cause of this and whether to worry about it would be appreciated. > > Thanks, > > Steve > >