Hi Steve,
I think it seems pretty likely that the NaN problem is related to code
you sent
out to fix the masking problem in FSL 4.0, but I'm exactly sure how it's
causing the NaNs to get in there. We never saw the problem prior to updating
our cluster with the new FEAT code. We do not get the problem if we use data
that was preprocessed before implementing the new code. We always see the NaNs
on the edge of the brain or outside of the brain (i.e., voxels at the edge of
the mask).
If I use my fix for the masking problem and essentially prevent FEAT
from doing
any of the masking, then I do not see the problem (at least in a few
tests that
I've ran tonight).
Thanks for looking into it. At this point, I'm happy to wait a couple of weeks
for the new release; however, I'm hoping the new release won't have the same
masking issues as 4.0, or NaNs if it uses the your fix to address the masking
problem in 4.0.
Cheers,
David
Quoting Steve Smith <[log in to unmask]>:
> 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
> ---------------------------------------------------------------------------
>
--------------------------------------------------
David V. Smith
Graduate Student, Huettel Lab
Center for Cognitive Neuroscience
Duke University
Durham, NC 27708
www.mind.duke.edu
--------------------------------------------------
|