Print

Print
Thank you very much, Mark.

I use BET to do the brain extraction with the raw T1 image, and the FAST is done successfully.
Also, I'm very curious about the  reason of  the FAST crash with the intensity normalized image in FreeSurfer, and not all the normalized images can not be segmented with FAST.

Best,
Lijie Huang


On Tue, May 27, 2014 at 6:49 PM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

Yes, I think that FAST has been known to crash on images that have been through FreeSurfer pre-processing.  In that case just use the image prior to it being intensity normalised in FreeSurfer.

All the best,
Mark


On 27 May 2014, at 11:34, soft.join Huang <[log in to unmask]> wrote:

Hi, Mark,

Thank you for your susggestion.

I check the brain extraction and it's ok, and re-run the FAST, an all-zeros image is returned.

But maybe I realize what had happened, I run the brain extraction using FreeSurfer, and value in the returned brain image ranges from 0 to about 140 which may be caused by an intensity normalization, and it's dfferent from that in the original mprage image. I also ckeck the value in the brain extracted brain that there is no nan in it. I think it may be the reason of the failzed segmentation.

Best,
Lijie Huang


On Tue, May 27, 2014 at 2:27 PM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

That certainly does sound like FAST is failing.
The FAST call that is made within the registration code (the script epi_reg) that FEAT calls uses no special options, just as you have it.

Do you get a zero image from this when you run it yourself?
On the image that you sent me I got a perfectly good segmentation.
Have you checked that the brain extraction is OK?
And also check that there is nothing unusual with the filenames (no spaces and no unusual characters).

All the best,
Mark



On 26 May 2014, at 12:49, soft.join Huang <[log in to unmask]> wrote:

Hi, Mark,

Yes, I'm running the registeration via FEAT, but when I check the file 
example_func2highres_segwm, it's all zeros in it.

So i think it may be the reason that the flirt is failed.

Best,,
Lijie Huang 


On Mon, May 26, 2014 at 3:42 PM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

I'm a little bit puzzled by this.
I thought you were running the registration via FEAT.
Are you now running it yourself from the command line?
If you are using FEAT then it will run FAST for you automatically and you don't have to worry about this.

All the best,
Mark



On 25 May 2014, at 02:35, soft.join Huang <[log in to unmask]> wrote:

Hi, Mark,

I think I have found the problem. During the linear registeration using BBR, the segmentation using FAST is failed. I sued the following command:
              fast -o example_func2highres highres
without other optional parameters.

I don't know whether you set other parameters to do the segmentation.

Best,
Lijie Huang


On Fri, May 23, 2014 at 9:05 AM, soft.join Huang <[log in to unmask]> wrote:
Hi, Mark,

Thank you very much for your help and suggestion.
I'll check my platform following your tips.

Best regards,
Lijie Huang


On Fri, May 23, 2014 at 4:26 AM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

These images all look fine and when I ran it here, on my Mac laptop using FSL 5.0.6, the registration part finished in 12 minutes!  The results are perfectly good too.  So I do not understand why you are having problems.  I would try the following if you are still experiencing problems:
 - update to the newest FSL version (5.0.6) if you haven't already
 - check if your system uses Sun Grid Engine (SGE) for job management, and whether this is working correctly (if you do not have this, or do not want to use it, then the environment variable SGE_ROOT should be unset)
 - check that your filesystem is not causing problems, and that you have appropriate permissions for directories and are not close to any disk quota limits

Apart from that you will need to investigate the problem locally with your IT staff, since the images work perfectly well with FSL at this end.

All the best,
Mark





On 11 May 2014, at 08:24, soft.join Huang <[log in to unmask]> wrote:

Hi, Mark,

Thank you very much for your help!

I have uploaded one dataset, and hope it woud be helpful.

Best regards,
Lijie Huang


On Sun, May 11, 2014 at 2:32 PM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

I've never seen this before.
Can you zip up the necessary input data and feat design file for one subject where you have this problem?
You can send the zip file to the following upload site:
Hopefully I will be able to figure out what is going wrong when I see the data.
It may take me several days though, as I will be at ISMRM from today onwards.

All the best,
Mark


On 11 May 2014, at 07:00, soft.join Huang <[log in to unmask]>
 wrote:

Hi,

I re-run the analysis using FEAT 6.0, and it gets stuck during FLIRT process.

There is a screenshot of 'top' command in the attachment.

Best,
Lijie Huang


On Sat, May 10, 2014 at 8:02 PM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

What process is currently running during this time?
If you use "top", or some other process viewing tool, what FSL process is using up the most CPU?
This is very unusual, as I've never heard of this problem with FLIRT before.

All the best,
Mark


On 10 May 2014, at 12:57, soft.join Huang <[log in to unmask]>
 wrote:

Hi, Mark,

Thanks for your help.

Actually, for these few data, the FLIRT did not finished correctly. It just keeps running for about 24 hours, and when I noticed the situation, I kill the process.

I run the program on a Linux Server with 64G RAM, and I don't think it's the reason behind this unusul thing.

Lijie Huang


On Sat, May 10, 2014 at 5:24 PM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

This is very unusual then, as I cannot understand why it would take so long for certain datasets.
Is it working correctly in the cases where it takes a long time to run?
Do you have a limited amount of memory on your machine (or run in a virtual machine with limited memory)?  
That could cause problems like you are seeing.

All the best,
Mark





On 10 May 2014, at 04:19, soft.join Huang <[log in to unmask]> wrote:

Hi, Mark,

Thanks for your help.

The resolution of my structural image is not very high, the resolution is 1mm (dimension: 256x256x256).

And for most of my data (same data protocol), the FLIRT could be done in a few minutes. That's why I'm curious about what had happened.

Lijie Huang


On Sat, May 10, 2014 at 2:59 AM, Mark Jenkinson <[log in to unmask]> wrote:
Hi,

If flirt is taking a long time then it is probably because the structural image has very high resolution and the segmentation is taking a long time.
You have a few options:
 (i) pre-calculate your segmentations and save the white matter result with the same name as your brain-extracted structural image, but with "_wmseg" appended;
 (ii) downsample your structural image a little (e.g. making the resolution 1mm);
 (iii) be patient.

If your structural images are not very high resolution then let us know.

All the best,
        Mark


On 7 May 2014, at 04:38, soft.join Huang <[log in to unmask]> wrote:

> Dear experts,
>
> I'm analyzing my fMRI data with FEAT using FSL 5.0. The FLIRT with BBR cost is used in the registration o EPI to structural image. For most of my data/sbjects, the processing is done successfully. However, for few subjects, the FLIRT step costs too much time (about 24 hours).
>
> And I check the log, it only shows following information:
>
> Initialisation
> /usr/local/neurosoft/fsl5/bin/fslmaths /nfs/h2/fmricenter/volume/S0029/obj/002/func prefiltered_func_data -odt float
> Total original volumes = 99
> /usr/local/neurosoft/fsl5/bin/fslroi prefiltered_func_data example_func 49 1
> /usr/local/neurosoft/fsl5/bin/mainfeatreg -d /nfs/h2/fmricenter/volume/S0029/obj/002/func.feat -l /nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/logs/feat5_reg -R /nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/report_unwarp.html -r /nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/report_reg.html  -i /nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/example_func.nii.gz  -h /nfs/h2/fmricenter/volume/S0029/3danat/reg/T1_brain -w  BBR -x 90
> Option -d ( output directory ) selected with  argument "/nfs/h2/fmricenter/volume/S0029/obj/002/func.feat"
> Option -l ( logfile )input with argument "/nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/logs/feat5_reg"
> Option -R ( html unwarping report ) selected with  argument "/nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/report_unwarp.html"
> Option -r ( html registration report ) selected with  argument "/nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/report_reg.html"
> Option -i ( main input ) input with argument "/nfs/h2/fmricenter/volume/S0029/obj/002/func.feat/example_func.nii.gz"
> Option -h ( high-res structural image ) selected with  argument "/nfs/h2/fmricenter/volume/S0029/3danat/reg/T1_brain"
> Option -w ( highres dof ) selected with  argument "BBR"
> Option -x ( highres search ) selected with  argument "90"
>
> I don't know what's wrong with this processing, it it normal?
>
> Hope for help.
>
> Thanks in advance.
>
> Best,
> Lijie Huang
> Beijing Normal University





<top_result.png>