So, I've been investigating this issue and have found some interesting
items.
1) There is another problem subject who under-reports all of the mask
voxel counts, but only by 10-20 voxels (as opposed to 1000s). Neither of
the problem subjects have registration reports that show anything out of
the ordinary.
2) For all subjects the cope images, zstat images, and mask images that
I'm using in Featquery are all in MNI152 space and are all FLOAT32 file
types.
3) For all subjects the images files that are being used for
registration and analysis are of identical voxel dimensions and counts
(64x64x35 for func, 256x256x60 for struct, and 91x109x91 for std space
xfms), but the file types for the functional volumes are split ~80%
FLOAT32 and ~20% INT16.
4) For the subject that over-reports voxel counts, even though the image
dimensions of the cope & zstat images are 91x109x91, avwstats -v gives a
total voxel count of 893415 instead of 902629, and avwstats -V gives a
non-zero voxel count 5 standard deviations greater than the sample mean.
For the subject that under-reports voxel counts, the total voxels is the
correct 902629, but the non-zero voxel count is 3 sd's below the mean.
5) In scouring the report.log files, I found three subjects who had
errors in the Fixed Effects cross-session means analysis when Feat was
creating the file 'mean_func.nii.gz,' but neither of the
Featquery-problem subjects are in this group. Strangely, I can run all
sorts of avw commands on the single-session 'mean_func' images, except
trying to run avwmerge on them ends with a segmentation fault. All three
of these subjects have lower-level 'mean_func' files that are a mix of
FLOAT32 and INT16 file types, but there are other subjects with this
same mixed-filetype situation and they all went through their gfeat
analysis just fine.
So, I now have two two-part questions:
How can an image have dimensions set to 91x109x91 but actually
be short 9214 voxels,
then over-report voxel counts in Featquery by approximately that
same amount?
Why would my file types be mixed within some subjects,
and is there a way to convert the images to the same type?
Thanks so very much,
Jim Porter
TRiCAM Lab Coordinator
Elliott Hall N437
612.624.3892
www.psych.umn.edu/research/tricam
Steve Smith wrote:
> Hi,
>
> On 15 Aug 2007, at 19:16, James N. Porter wrote:
>
>> Hello-
>>
>> I'm having an odd error with Featquery. For one subject in my sample
>> everything seems to not work properly when passing in a mask. For
>> example, in one instance I specify a mask that is 51 voxels in size,
>> and everybody but this one subject spits out a featquery report that
>> has '51' in the voxels column.
>
> What space is the mask in? If it's in standard space I would have
> thought that this would corresponding to slightly different numbers of
> voxels in different subjects, and if it's in native (example_func)
> space, then I would have thought that it wouldn't be aligned with all
> the subjects?
>
>> This subject reports on 9265 voxels instead. The situation is the
>> same, no matter what mask I pass in, with the problem subject wildly
>> inflating the number of voxels to report upon.
>
> You should check in detail the registration results for this subject,
> as well as its mask image and stats images (cope* etc.).
>
> Cheers, Steve.
>
>
>> The thing is, every step of my analysis from pre- to post-processing
>> has been performed with for each loops, so everybody has been given
>> exactly the same set of commands from dinifti through featquery. Does
>> anybody have any ideas why this one subject would have this problem?
>>
>> Thanks,
>>
>> --
>> Jim Porter
>> TRiCAM Lab Coordinator
>> Elliott Hall N437
>> 612.624.3892
>> www.psych.umn.edu/research/tricam
>
>
> ---------------------------------------------------------------------------
>
> Stephen M. Smith, Professor of Biomedical Engineering
> Associate Director, Oxford University FMRIB Centre
>
> FMRIB, JR Hospital, Headington, Oxford OX3 9DU, UK
> +44 (0) 1865 222726 (fax 222717)
> [log in to unmask] http://www.fmrib.ox.ac.uk/~steve
> ---------------------------------------------------------------------------
>
|