 |
 |
Hi, Glad it worked and is much faster. Yes, use the Identity Transformation in ApplyXFM. It is the pixdim1, pixdim2 and pixdim3 fields which show the voxel size (x, y and z respectively) in mm. You can also use fslsize. All the best, Mark On 28 Oct 2008, at 23:45, Anthony Ang wrote: > Hi Mark, > > invwarp took 12 min with the 2mm voxel ref image - this is indeed > much faster and cuts down the processing time tremendously. > Thank you very much! > > For ApplyXFM, I assume the transformation matrix to be Identity > Transformation? > > How do I check the voxel size using fslhd? > > fslhd x1000024_roi_2mmvoxel gave: > sizeof_hdr 348 > data_type INT16 > dim0 3 > dim1 91 > dim2 93 > dim3 88 > dim4 1 > dim5 1 > dim6 1 > dim7 1 > vox_units mm > time_units s > datatype 4 > nbyper 2 > bitpix 16 > pixdim0 0.0000000000 > and so on. > > > Thanks. > > Best regards > Anthony > > > > > > > On Tue, Oct 28, 2008 at 8:51 PM, Mark Jenkinson > <[log in to unmask]> wrote: > Hi, > > OK, my turn. :) > > If you don't like using invwarp because it is taking a long time, then > you can massively speed it up by calculating the warp at 2mm > resolution > rather than 1mm. To do this just make a reference image with the same > (or similar) FOV to your input but with a 2mm voxel size. Then run > invwarp with this as the reference, and later run applywarp as usual > (with your higher resolution image as the reference). On my machine > the invwarp step here took 6 *minutes*! So even at half this speed it > will be quick. And the results, compared with the full results are > almost identical and certainly will be good enough for warping masks > between the spaces. > > To make the 2mm reference image you can use ApplyXFM and set > the output size to be based on Voxel Dimensions. I made it have > 91x93x88 voxels, each of 2x2x2mm for your data, in order to have > the same FOV. > > All the best, > Mark > > > > > > > Jesper Andersson wrote: > Hi Antony, > > > To clarify, I wish to register a MNI image (or more accurately a > lobe-based > mask e.g. temporal lobe mask) into subject space. My question is > whether > flirt and fnirt can be carried out with ref=subject image and > input=MNI-image (lobe-based mask)? > > > you can in principle do like that (with --in=MNI152_T1_2mm) and then > apply > the warps to your "lobe mask". However, you would need a different > configuration file. I recently made one for some people here, and I am > waiting to see how well it performs. If they are happy with it and it > works well then I'll release that configuration file as part of the > next > release. > > Until then I suggest you use invwarp. > > Good luck Jesper > > > On Tue, Oct 28, 2008 at 5:24 PM, Steve Smith <[log in to unmask]> > wrote: > > > Hi - in general if you are just wanting to register a subject into > standard > space then no you don't need to run invwarp to generate the inverse > warp. > You only need that if you _also_ want to apply the inverse warp to > bring > a > standard space image back into subject space. > > Cheers. > > > > > On 27 Oct 2008, at 22:59, Anthony Ang wrote: > > Hi, > > FSL4.1.1 was reinstalled on the computer. fnirt now takes 76 min and > invwarp is finally working! It takes 8.05 h. > The MNI152 image is registered well to the subject image. Also fnirt > -iout > image is the same as applywarp output (with MNI152 image as the ref). > > However, I could not view (under fslview) -iout image initially. The > min > intensity is 3000 and max intensity is 8000. It is only after I have > changed > the intensity range to 0-100 that I could view the -iout image. I > didn't get > this output with the previous FSL version. Why is this so? > > Hence, the problem is indeed due to the use of Analyze rather than > NIFTI > output files. Mark and Jesper, thank you very much for your help! > > Now, I am doing: > flirt (subject to MNI152 linear transform) > fnirt (subject to MNI152 nonlinear transform) > invwarp (MNI152 to subject) > applwarp (MNI152 to subject) > > The question is why is the invwarp step necessary? Why can't I do the > following directly?: - > flirt (MNI152 to subject linear transform) > fnirt (MNI152 to subject nonlinear transform) and using the --iout > file > directly > > I'm trying this out to see what's the result? Mark and Jesper, what > are > the reasons for doing the 4 steps instead of the 2 steps directly? > > Thank you very much. > > Best regards > Anthony > > > > On Fri, Oct 24, 2008 at 11:00 AM, Anthony Ang <[log in to unmask]> > wrote: > Hi Mark, > > My IT Manager said that FSL was previously installed in /usr/local. > But > the latest version was installed in in /usr/share > Both local and share appear to point to /usr/lib. He suspect when the > new > version was installed, some old files may not be overwritten so > although > these files read as FSL4.1, they may have been older versions. > > He would clear this computer of all previous FSL version and reinstall > FSL4.1 > > He said that FSL was downloaded as a binary version from the German > mirror > site and installed as according to the instructions provided. > Is it better to download the binary version or to compile from source? > > I have copied him into this email. Thanks. > > Best regards > Anthony > > > > On Fri, Oct 24, 2008 at 10:17 AM, Mark Jenkinson <[log in to unmask]> > wrote: > Hi, > > The use of Analyze does explain the problem on your machine, as it is > incorrectly reading the warp file (being in Analyze format) and so has > to > do > a lot more filing of blank area and correcting for problems due to > poorly > constrained Jacobians. > > The puzzling thing is that you can get Analyze output from FSL4.1 as > this > should not be possible. Setting my FSLOUTPUTTYPE variable to ANALYZE > (which is what yours is set to) gives me an error of the form: > ERROR:: Unrecognised value (ANALYZE) of environment variable > FSLOUTPUTTYPE > Legal values are: NIFTI, NIFTI_PAIR, NIFTI_GZ, NIFTI_PAIR_GZ > > If you are not getting this error it makes me think that you are not > using > FSL4.1. I notice that in your PATH you have both /usr/share/fsl/bin > and > /usr/lib/fsl. > I would check what version you are really using. See what you get > with > "which invwarp" to see where it is finding the files. > > As for your supercomputer - invwarp will not be run in parallel, so it > is > only using one node of your system, and each node seems to be a 1.5GHz > processor, which may not be so fast. Hence 10 hours, although long, > doesn't > seem unreasonable. However, your setup problems here (I don't know > what > your fslinit file is or why it is needed) also makes me wonder if you > have > the right version of FSL installed and are using that one. > > We really, really strongly recommend using NIFTI for your output > format > (in FSL4.1 you just cannot have ANALYZE for output) and for FNIRT it > is > essential. It is the warp fields - particular the coeff fields - > which > must use > the nifti format and so you cannot use any tools that deal with these > (including > applywarp and invwarp) with ANALYZE. I would change your > FSLOUTPUTTYPE > to NIFTI_GZ, check that you are using FSL4.1 (and install it if > necessary) > and > then try running the sequence of commands again on your machine and > see > if that fixes the problem. > > All the best, > Mark > > > > On 24 Oct 2008, at 00:00, Anthony Ang wrote: > > Hi Jesper, > > Attached is the angs_set.txt file for our lab computer. Yes, I notice > that > Analyze output files are produced. > I also notice that the supercomputer that I used produces NIFTI files > and > when I compared the fnirt --iout file and Applywarp file generated by > the > supercomputer, they are identical. > > My subject images (1000024 and so on) are in Analyze format. Do I need > to > convert them to NIFTI in order for flirt, fnirt, invertwarp, applywarp > to > work correctly? Does the use of Analyze files also affect other FSL > tools > such as bet and fast? > > However, the difference in the file format still does not explain the > > 10 > > hours taken by the supercomputer to complete invwarp. > I remembered when I was using invwarp on the supercomputer, it doesn't > recognize the invwarp command. A fellow colleague helped and found an > fslinit file somewhere; copied and pasted one of the lines (I think it > is > module load fsl ....) into the terminal and execute it. Then the > invwarp is > working. We have no control over the supercomputer. Could this have > explained the long time taken even for this supercomputer to carry out > invwarp, although it uses NIFTI files? > > Thanks. > > Best regards > Anthony > > > > On Thu, Oct 23, 2008 at 8:44 PM, Jesper Andersson > <[log in to unmask]> > wrote: > Hi again Antony, > > the files you sent us are in analyze format. I am not really sure how > that > happened. As of FSL 4.0, there shouldn't really be any (simple) way of > producing analyze files as output. > > This also explains the problems you are having. When fnirt produce > coefficient files (--cout) it uses a number of fields in the nifti > header to > encode various bits of information that is needed for the other > applications > to later decode them. Not all of those fields are present in the > analyze > format, and the files do not get interpreted correctly by either > applywarp > (which explains that mismatch) or invwarp. > > As a first step, could you please do > > set > angs_set.txt > > and then email us angs_set.txt? > > Best regards Jesper > > > On 23 Oct 2008, at 08:19, Anthony Ang wrote: > > Hi Mark, > > The ref no is 470181 > Thanks. > > Best regards > Anthony > > > ---------- Forwarded message ---------- > From: Jesper Andersson <[log in to unmask]> > Date: Thu, Oct 23, 2008 at 5:38 PM > Subject: Re: [FSL] Problem with invwarp > To: [log in to unmask] > Cc: Mark Jenkinson <[log in to unmask]>, [log in to unmask] > > > Hi Antony, > > > fslroi x1000024_resize x1000024_roi 29 182 0 186 41 176 > fslroi x1000024_n3ed x1000024_roi_n3ed 29 182 0 186 41 176 > > flirt -v -ref MNI152_T1_2mm_brain -in x1000024_roi_n3ed -omat > flirted_x1000024_reducedFOV.mat -out flirted_x1000024_reducedFOV.hdr > > flirt_output > > fnirt -v --in=x1000024_roi --aff=flirted_x1000024_reducedFOV.mat > --cout=fnirted_x1000024_cout --iout=fnirted_x1000024_iout > --config=T1_2_MNI152_2mm > fnirt_output > * > applywarp -v --ref=MNI152_T1_2mm --in=x1000024_roi > --warp=fnirted_x1000024_cout --out=warped_x1000024 > applywarp_output > > the fnirted_x1000024_iout and warped_x1000024 files should definitely > be > identical. Could you please tar fnirted_x1000024_iout, warped_x1000024 > and > nirted_x1000024_cout and then go to > > http://www.fmrib.ox.ac.uk/cgi-bin/upload.cgi > > and follow the instructions there to upload the file? When you have > done > that please email me and Mark with the six-digit code that you are > given. > > Best regards Jesper > > > > > > > <angs_set.txt> > > > > > > --------------------------------------------------------------------------- > 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<http://www.fmrib.ox.ac.uk/%7Esteve> > --------------------------------------------------------------------------- > > > > >