Hi,

The NaN values in your logfile are not necessarily relating to NaNs in  
the images but some other problem. It's not clear from this what might  
have caused this - probably the best thing is if you want to try the  
beta version of FSL4.1 (email [log in to unmask] to get that) or  
wait a couple of weeks for the new release.

Cheers, Steve.


On 12 Jul 2008, at 13:39, David V. Smith wrote:

> Hi Steve,
>
> I was wondering if there was any chance that the altered FEAT code  
> you posted
> for the masking problem in 4.0 could cause NaNs to appear after  
> first level
> analyses? When I originally tested your code, I did a couple of  
> first level
> analyses and it looked great, but I never did a higher level  
> analyses using the
> altered code so I never ran into the NaN problem.
>
> The NaNs are a really odd problem and no one here can seem to figure  
> it out (I
> think someone from our group mailed the FSL list a couple of weeks  
> ago, but it
> never got resolved). We can basically run an analyses that used to  
> work (i.e.,
> not have NaNs) and now it suddenly has NaNs in higher level  
> analyses. It seems
> like something is going awry when the smoothness (and/or whatever  
> else is
> needed for GRF) is being calculated for the second level (see lines  
> from a
> second level log below):
>
> echo 288689 > thresh_zstat1.vol
> zstat1: DLH=nan VOLUME=288689 RESELS=nan
>
> /usr/local/fsl/bin/cluster -i thresh_zstat1 -c stats/cope1 -t 2.3 -p  
> 0.05 -d nan
> --volume=288689 --othresh=thresh_zstat1 -o cluster_mask_zstat1 -- 
> connectivity=26
> --mm --olmax=lmax_zstat1_std.txt > cluster_zstat1_std.txt
>
> There aren't any NaNs anywhere up to this point in the analysis  
> (i.e., no NaNs
> before second level). And the NaNs seem to only appear around the  
> edge of the
> brain.
>
> Thanks for any insight and/or solutions. I suspect this will all be  
> moot in a
> few weeks anyway once the new release comes out unless this some  
> problem with
> out computing cluster.
>
> Cheers,
> David
>
>
>
>
>
>
>
>
>
> Quoting "David V. Smith" <[log in to unmask]>:
>
>>
>> Hi Steve,
>>
>> Sorry for the long delay in getting back to you on this masking  
>> issue...
>>
>> This fix works very well! There aren't any holes in the mask, and  
>> the mask is
>> slightly larger (one or two voxels) and smooth around the edges.  
>> See attached
>> image showing the default mask overlayed on the new mask generated  
>> by the fixed
>> code you sent (%brain/bkg thresh was the default .10 in both cases).
>>
>> Could you make this an option in the next patch? It would be nice  
>> to have an
>> option for creating the masks with the code you sent rather than  
>> the default
>> FSL 4.0 way, which produces the large holes and rough edges around  
>> the edge of
>> the brain that were discussed earlier on this thread. Or, if  
>> everyone agrees
>> that the FSL 3 masks are better than the FSL 4 masks, simply make  
>> the the code
>> you sent the default way of doing it in FSL 4.
>>
>> Thanks so much for helping out with this!
>>
>> Cheers,
>> David
>>
>>
>>
>>
>>
>>
>> Quoting Steve Smith <[log in to unmask]>:
>>
>>> Joe, David, Greg, thanks all for your input.
>>>
>>> Firstly, let's be clear about registration: registration is  
>>> completely  unaffected by all of these issues because it uses  
>>> "example_func" which  is created before any other processing  
>>> begins. The only exception to  this is if you did the  
>>> preprocessing in one run of FEAT and then ran a  new FEAT using  
>>> the previously preprocessed data as input, including  registration  
>>> in the second FEAT run - this is to be avoided for  obvious  
>>> reasons as the registration will suffer!  [A separate issue is   
>>> Joe's question about whether the non-brain voxels in the FMRI  
>>> data  might affect the registration to the brain-extracted  
>>> structural; in  our experience it doesn't.]
>>>
>>> Anyway, the general preference seems to be for returning to the   
>>> slightly liberal brain masking that FSL3 had. To recap: the  
>>> reason  that the masking got more "accurate" (as opposed to  
>>> liberal) was not  so much a design decision but a result of  
>>> swtiching to the better  smoothing approach of only smoothing  
>>> within the brain mask. Anyway,  it's easy to avoid that: brain  
>>> extract, intensity threshold, and then  dilate the resulting mask.  
>>> Smoothing is then achieved using SUSAN,  which, when called with  
>>> the right intensity "threshold", will act like  Gaussian smoothing  
>>> within brain tissue, but will not blur the brain  edges.
>>>
>>> Attached is some amended code that does this. The process is:
>>>
>>> 1. Run stages that do not do any masking/thresholding: (motion   
>>> correction, unwarping, slice timing correction) -> funcdata_unmasked
>>> 2. funcdata_unmasked -> timeseries mean -> BET -> brain_mask (-f  
>>> 0.3,  NO dilation)
>>> 3. apply BET mask to funcdata_unmasked, find timeseries MIN, do   
>>> intensity thresholding, update brain_mask
>>> 4. dilate brain_mask by one voxel and apply to func_data_unmasked  
>>> to  create new funcdata_masked (now having liberal brain edge)
>>> 5. apply SUSAN smoothing (to funcdata_masked) to apply Gaussian   
>>> smoothing within the brain, without blurring brain edge
>>> 6. etc.
>>>
>>> I'd be grateful if people could try this out and send feedback.  
>>> Do  people want even _more_ liberal masking? The main downside is  
>>> the more  aggressive multiple-comparison correction, etc.
>>>
>>> Warning: one big gotcha here relates to the 4D (aka "grand mean")   
>>> intensity normalisation. This normalisation derives a single  
>>> intensity  scaling factor for the whole dataset, in order to make  
>>> different  sessions' analyses "compatible" with each other.  
>>> However, this scaling  factor is affected by the exact brain  
>>> masking/thresholding, so it is  very important NOT to mix (in  
>>> second-level analyses) first-level FEAT  outputs that have been  
>>> created with different versions of FEAT if the  preprocessing has  
>>> changed (like it has between FSL3 and FSL4.0 and  between FSL4.0  
>>> and the attached code). Just make sure that all first- level  
>>> sessions are processed with the same version of the software.
>>>
>>> Note that the attached code doesn't clean up the intermediate   
>>> preprocessing outputs (prefiltered*) so you'll end up using up  
>>> lots of  disk space if you don't uncomment the line:
>>> #fsl:exec "/bin/rm -rf prefiltered_func_data*"
>>>
>>>
>>> To try the new code, edit $FSLDIR/tcl/featlib.tcl and:
>>>
>>> replace all code between
>>> #{{{ feat5:proc_prestats
>>> and
>>> #{{{ feat5:proc_film
>>> with the attached code.
>>>
>>>
>>
>>
>>
>> --------------------------------------------------
>> David V. Smith
>> Graduate Student, Huettel Lab
>> Center for Cognitive Neuroscience
>> Duke University
>> Durham, NC 27708
>> www.mind.duke.edu
>> --------------------------------------------------
>>
>
>
>
> --------------------------------------------------
> David V. Smith
> Graduate Student, Huettel Lab
> Center for Cognitive Neuroscience
> Duke University
> Durham, NC 27708
> www.mind.duke.edu
> --------------------------------------------------
>


---------------------------------------------------------------------------
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
---------------------------------------------------------------------------