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