 |
 |
Hi Mariam, The FEAT pipeline can be run in a wide number of modes. For hand-modifications to FEAT folders/files, it is not always obvious the decisions that the FEAT script will make with regard to the analysis space. So it is not easy to figure out when FEAT will perform its analysis in native, as opposed to standard space. Good to hear that you solved your problem though. Cheers, Paul On Sun, Feb 15, 2015 at 4:35 PM, Mariam Sood <[log in to unmask]> wrote: > Hi Paul, > > I had a design.lev (dummy file I created to facilitate post-stats only > analysis) in my feat folders which was causing gfeat analysis to skip > applying standard registration etc. Deleting that file makes it work as > normal. I understood a bit about design.lev file, by looking at code but > still no idea when exactly it gets created (it doesn’t get created for a > full first-level analysis). Anyway, I can at least do everything the way I > wanted now. Thanks very much for your help. > > Many thanks, > Mariam. > > > On 14 Feb 2015, at 16:26, Mariam Sood <[log in to unmask]> wrote: > > Hi Paul, > > Thanks very much. Now it makes sense. > I used to think that gfeat results are always in standard space. What is > the criterion on which this (whether gfeat is in native/standard space) is > determined? > > Many thanks, > Mariam. > > On 13 Feb 2015, at 13:33, paul mccarthy <[log in to unmask]> wrote: > > Hi Mariam, > > Ok, the .gfeat statistics are actually in native subject space, but your > tksurfer command is assuming that they are in standard (MNI152) space - > this is why your surface image was flipped. > > It may be best to re-run the .gfeat analysis upon the first-level cope > images in standard space, rather than native space. For each of your first > level .feat runs: > > - Back up the stats directory (e.g. 'cp -r stats stats_backup') > - Copy the contents of reg_standard/stats/ into stats/ (e.g. 'cp > reg_standard/stats/* stats/') > > Then re-run the .gfeat analysis. The resulting statistics should then be > in standard space. > > Cheers, > > Paul > > > > > On Fri, Feb 13, 2015 at 12:57 PM, Mariam Sood <[log in to unmask]> > wrote: > >> Hi Paul, >> >> I am actually doing the group analysis in Freesurfer, So I was viewing >> them on the surface using the registration matrices computed first at the >> FSL level and converted to Freesurfer formats (hence I really want to avoid >> redoing registrations). The command I was using was >> tksurfer ES_PRJ1 lh inflated -annot aparc.annot -ov >> ./Run1/Read1+.gfeat/cope11.feat/stats/zstat1.nii.gz -ovreg >> ./Run1/Read1+.feat/reg/freesurfer/std2anat.reg.dat -fthresh 3.09 -fmid 4 >> -fslope 1 >> What I was seeing was 180 degree rotation in the way data is shown. >> I understand that you cannot view the results this way as the cortical >> surface files are not present. >> >> So I just checked the results on FSL view, the way I tried to view is >> open the standard.nii.gz file under FEAT/reg folder and add >> GFEAT/cope5.feat/stats/zstat1.nii.gz. This works for original GFEAT which I >> had done, but for the GFEAT done after the post-stats analysis only, comes >> back with an ‘incompatible overlay’ error. I also notice that >> GFEAT/report_reg.html is not having any relevant information, so is >> inputregs folder missing. >> >> Thanks very much. >> Mariam. >> >> >> >> >> >> On 13 Feb 2015, at 10:54, paul mccarthy <[log in to unmask]> wrote: >> >> Hi Mariam, >> >> I'm having trouble finding anything wrong with your second level analysis >> (.gfeat) results - it all seems to line up with the first level .feat >> results. >> >> Can you clarify exactly which image(s) you were looking at that were >> incorrectly oriented, and how you were viewing them? >> >> Thanks, >> >> Paul >> >> On Wed, Feb 11, 2015 at 6:17 AM, Mariam Sood <[log in to unmask]> >> wrote: >> >>> Hi Paul, >>> >>> I have uploaded the folders (Mariam-FSL.zip) to the URL. There is a >>> Readme in it mentioning anything non-standard I have done. >>> Much appreciate your help. >>> >>> Many thanks, >>> Mariam. >>> >>> On 10 Feb 2015, at 16:36, paul mccarthy <[log in to unmask]> wrote: >>> >>> Hi Mariam, >>> >>> Could you please upload your .gfeat folder, and one of the first level >>> .feat folders to this URL? >>> >>> https://oxfile.ox.ac.uk/oxfile/work/extBox?id=214687855CEEB78A7E >>> >>> Thanks, >>> >>> Paul >>> >>> On Mon, Feb 9, 2015 at 3:41 PM, Mariam Sood <[log in to unmask]> >>> wrote: >>> >>>> Dear FSL experts, >>>> >>>> I am doing a partial post-stats analysis to my data. I had selected >>>> ‘Copy original FEAT directory for post-stats/registration’ in the misc tab. >>>> I did not want to loose my original registration, hence turned off the >>>> registration. Post-stats works fine (during the process of backing up, the >>>> software was complaining about a few missing files such as design.lev which >>>> is never in my FEAT directory. I worked around the problem by creating >>>> dummy files). After post-stats, individual run’s FEAT results looks fine. >>>> >>>> Next I did a GFEAT using the newly created FEAT folders, and there >>>> seems to be something not right with the registration. The new GFEAT folder >>>> doesn’t seem to have inputregs folder, and the data is oriented in the >>>> opposite way. If I look at the GFEAT results using my original >>>> registration, what should be seen at the occipital lobe is at frontal lobe >>>> and vice versa. >>>> >>>> I tried to edit design.fsf files in the new FEAT folders (after >>>> individual runs were processed) to suggest that they had gone through >>>> registration, hoping GFEAT process is looking at the registration settings >>>> in these files, but that does not seem to fix the problem. >>>> >>>> I am happy to edit any settings in the files rather than redo >>>> registration. >>>> >>>> Please advice. >>>> >>>> Many thanks, >>>> Mariam. >>>> >>>> Mariam Sood >>>> PhD Student. >>>> Birkbeck, London. >>> >>> >>> >>> >> >> > > >