Yes - that's right - FeatQuery will do all the resampling for you
as long as you selected Registration to be run in the FEAT GUI
(which is separate from renderhighres, which you do not need to do).

All the best,
	Mark

On 26 Nov 2010, at 15:44, sere f wrote:

> Hi Mark,
> 
> Ok, I understood the point about the degradation of the images after the resampling.
> 
> From what you wrote I understand that I can use FeatQuery between first level analysis directory and  the ROIs, even if my ROIs are in standard space (MNI space) and thresh_zstat1 is in native space versions (fMRI space).
> So I don't need to resampling any images because Featquery will do it. Am I correct?
> Sorry If I am insistent but I need to understand well!!
> 
> Serena.
> 
> On Fri, Nov 26, 2010 at 3:26 PM, Mark Jenkinson <[log in to unmask]> wrote:
> Dear Serena,
> 
> Your thresh_zstat1 image is in the standard space (MNI152)
> after running Renderhighres.  Hence there are lots of small
> voxels, and many that are non-zero within your mask.  Remember
> that in 3D you only need a box of the size 10 voxels by 10 voxels
> by 10 voxels to end up with 1000 voxels.  In other words, these 2000
> voxels only need to cover a region of dimensions 25mm by 25mm
> by 25mm, which is very easy to see in this data.
> 
> Also note that the upsampling to standard space causes
> some degradation of the z-stats at the edges of the
> thresholded maps, and you really shouldn't use them for
> quantitative calculations.  It is much better to use the native
> space versions.  You can transfer your masks between one space
> and the other instead - the easiest way being to use FeatQuery.
> I see that you are also having trouble with this, which might
> be caused by giving it the renderhighres directory instead of
> the normal FEAT directory.  You do not need to use
> renderhighres to be able to use standard space masks
> with FeatQuery, and it is essential that FeatQuery knows
> where your full FEAT results are.  Hopefully that will solve
> your problems.
> 
> All the best,
>        Mark
> 
> 
> 
> On 26 Nov 2010, at 13:52, sere f wrote:
> 
> > Hi Matthew,
> > thank you for your attention.
> >
> > I write these  commands:
> >
> > fslstats -t  thresh_zstat1.nii.gz   -k   1.nii.gz -V
> > Results: 2042 16336.000000
> >
> > fslstats -t  thresh_zstat1.nii.gz   -k   2.nii.gz -V
> > Results: 2450 19600.000000
> >
> >  I have looked the images with fslview and I don't think that in 1.nii.gz there are 2042 voxels different from 0 because there is small activation in this ROI.
> >
> > Do you think the results are correct?
> > this is the reference number: 580912
> >
> > Thank you very much.
> >
> > Serena.
> >
> >
> > On Fri, Nov 26, 2010 at 2:00 PM, Matthew Webster <[log in to unmask]> wrote:
> > Hello,
> >          If you upload the problematic file(s) ( and details of the command line call used ) to
> >
> > http://www.fmrib.ox.ac.uk/cgi-bin/upload.cgi
> >
> > and let us know the 6-digit reference number we will be able to check what is going wrong.
> >
> > Many Regards
> >
> > Matthew
> > > Hi All,
> > >
> > > I have a problem with fslstats.
> > > I have calculated the volume for non zero voxels in ROI. The obtained number does not appear believable to me because if I look the  thresh_zstat overlapped to the ROI image in fslView, the activation in ROI is really small.
> > >
> > > How can I obtain the correct number?
> > >
> > > Thanks.
> > >
> > > Serena.
> >
>