JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for FSL Archives


FSL Archives

FSL Archives


FSL@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

FSL Home

FSL Home

FSL  2002

FSL 2002

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re:

From:

"Marenco, Stefano (NIMH)" <[log in to unmask]>

Reply-To:

FSL - FMRIB's Software Library <[log in to unmask]>

Date:

Fri, 1 Feb 2002 15:06:37 -0500

Content-Type:

multipart/mixed

Parts/Attachments:

Parts/Attachments

text/plain (193 lines) , hippo_t1tot2_regv2.mat (193 lines) , t1tot1_regv3.mat (193 lines)

I cannot do this in medx for two reasons: 1) the FSL utilities work only
with 3D registration; 2) even when I do the registration with air medx
cannot save a 2D transform, it can only save a 3D (that is really odd!!!,
and disappointing).

I tried to to 2D transforms in the flirt GUI, without changing cost
functions. I attempted first with my original images (t2 as reference, t1 as
input). I got the message "child killed: SIGABRT", the output file was not
written, but the .mat file was. Since the reference image has very different
contrast (and pretty bad contrast for that matter as compared to the t1
weighted), I also used a t1 weighted image as reference, which I had
obtained from a successful 2D registration in medx. I got the same error
message. I enclose here the transformation (.mat) files I got with the 2
procedures. Should I try to apply the transforms to a 2D image and to a
reference volume from the command line?
Thanks for your help. Stefano



-----Original Message-----
From: Mark Jenkinson [mailto:[log in to unmask]]
Sent: Monday, January 21, 2002 3:32 AM
To: [log in to unmask]
Subject: Re: [FSL]


Dear Stefano,

> Here is my starting problem, it is still quite unclear to me how to do
> things based on your previous email.
>
> My reference image is a single slice. I have another 3 slices in the same
> acquisition, but these slices are 7.5 mm thick, with a 11 mm gap.
>
> Then I have a volume that I want to register to the single slice. I assume
> that the head has moved only in-plane between the two scans (I think that
is
> a reasonable approximation for what I want to do).

Yes - this all sounds fine.
For a 2D registration you do want a single slice for input and a single
slice for reference.

> I thought I would register the best estimate slice of the input with the
> reference slice, save the transform and apply it to the full input volume,
> the same transform for each slice.

Again, this is right.  The first step is to get the 2D registration
using only single slices.  Once you've done this you need to apply
the transformation and only then do you need 3D volumes.

> When I tried this, I used different cost functions and a 2D to 2D rigid
body
> 3 parameter model. In both cases I get an error message:
> child killed SIGABRT
> It saves a .mat file but not the output file. What should I do?

OK, if you used a single slice as the input AND a single slice as the
reference then using the 2D->2D parameter model was correct.  There
should be no need to change the cost functions.  If this isn't
working then we need to debug your images.  However, for the moment
I will assume that this will work if you try it again with single
slice inputs and references.

> I tried to save the original reference volume as a 4 slice 18.5 mm thick
> slice volume. Then I registered the equivalent t1 weighted volume to that.
> The registration was not satisfactory.

The 4 slices volume is unnecessary for you.

How many slices do you have in the input volume?
Lets assume for the moment that you have 10 slices in a volume that you
want to apply the 2D transformation to.

At this stage you have already done the registration - all we want to
do is apply the transformation.   Now in MEDx the transformation file
(saved with save shadow transform) contains information about the original
image size, so you can't easily apply this to a volume.  In fact,
in MEDx the easiest thing is to apply the 2D transformation (the MEDx
shadow transform) to each of the 10 input slices separately and
then group the results together as a 3D volume.

> The other option (which I think you describe in your email) is to create a
> reference volume with the same dimensions as the desired output of the
> shadow transformed t1 weighted file. I tried doing that starting from my 4
> original slices, but with little success. I can resample the volume to
make
> the slices of the right thickness, but should I add extra slices on top
and
> on the bottom to fit the final output volume?

The *alternative* to the above is to do this outside of MEDx.  In that case
you can make a reference volume that has 10 slices (each slice being the
same size as the *reference* slice).  Then you apply the flirt transform
(the .mat file) to the input volume (10 slices), using this new
reference volume (10 slices) to get an output volume (10 slices).
But, I repeat, this is only for doing it *outside* of MEDx.

Hope this makes it clear,
        Mark


> -----Original Message-----
> From: Mark Jenkinson [mailto:[log in to unmask]]
> Sent: Thursday, January 17, 2002 9:58 PM
> To: [log in to unmask]
> Subject: Re: [FSL]
>
> Dear Stefano,
>
> In answer to some of your questions...
>
> > When I use sinc interpolation, which filter should I use and what size?
> > I used Haninng 7 voxels for registering the images prior to
segmentation,
> > how does that sound (there must be a reason why it's default) ?
>
> There is no general concensus on what interpolation gives the best
results.
> We left 7 voxel Hanning as the default as it gave good results in a
> reasonable time.  But the only way to really know if other kernels might
> be better is to try them.  However, my suspicion is that it won't be
> that significant - there isn't anywhere near as much difference as there
> would be between sinc and trilinear.
>
> > The other question is where are the transform files saved after
> > registration? In the GUI I see no option to save the transform files,
yet
> I
> > imagine that the .mat files that are created may be the xform. Can I
take
>
> Yes, that's right.  The .mat files are the transformation files that
> flirt saves.  They are in ascii format (not MATLAB) and can be viewed
> as text files (a 4x4 affine matrix).  However, they are not MEDx
transforms
> and so if you want a MEDx transform then you should use the save shadow
> transform option immediately after getting the transformed image.
> An alternative is to use the command line program "convert_xfm" to
> convert the .mat file into a MEDx .xfm file.
>
> > these files and shadow-transform other volumes? How do I do that?
>
> Once you have the .xfm MEDx version you can happily shadow-transform away
> as normal.
>
> Note: If you want to use it outside of MEDx then you need to
> use the -init and -applyxfm options to the flirt command line program.
>
> > What are MRF's?
>
> Markov Random Fields.
>
> They are a mathematical form for imposing neighbourhood relations between
> the probabilities that helps to do spatial regularisation (like smoothing)
> to the internal segmentation-finding parts of FAST.
>
> Cheers,
>         Mark
>
> > -----Original Message-----
> > From: Stephen Smith [mailto:[log in to unmask]]
> > Sent: Wednesday, January 16, 2002 5:20 PM
> > To: [log in to unmask]
> > Subject: Re: [FSL]
> >
> > Hi
> >
> > On Tue, 15 Jan 2002, Marenco, Stefano (NIMH) wrote:
> >
> > > Is there any particular order I should apply susan and brain
extraction?
> > > I seem to get different results when I invert the order of these
> > operations.
> > > Is this to be expected?
> > > And what does susan actually do?
> >
> > They are both nonlinear processes so yes, the order will affect things.
> >
> > You should not normally need to apply susan before BET. In general, we
do
> > not use SUSAN before our other programs as they are all designed to be
> > robust. For example, the FAST segmentation effectively includes its own
> > "spatial regularisation" (MRFs on the class labels), so SUSAN is
> > definitely not recommended in that case.
> >
> > SUSAN is a nonlinear noise reduction algorithm - see
> > http://www.fmrib.ox.ac.uk/~steve/susan
> >
> > ttfn  :)


Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

April 2024
March 2024
February 2024
January 2024
December 2023
November 2023
October 2023
September 2023
August 2023
July 2023
June 2023
May 2023
April 2023
March 2023
February 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
July 2022
June 2022
May 2022
April 2022
March 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
July 2021
June 2021
May 2021
April 2021
March 2021
February 2021
January 2021
December 2020
November 2020
October 2020
September 2020
August 2020
July 2020
June 2020
May 2020
April 2020
March 2020
February 2020
January 2020
December 2019
November 2019
October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
2006
2005
2004
2003
2002
2001


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager