[Insight-developers] Inverse transforms

Fri, 31 Oct 2003 15:59:50 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C39FF1.ECC2A2D2
Content-Type: text/plain

I think I am with Stephen here.

Figure 8.2 of the User's Guide seems to indicate that the registration
framework estimates the transformation that maps the moving image into the
fixed image. This makes sense to me since the moving image is "moving" and
the fixed image is "fixed".

However, Figure 8.34 seems to indicate the opposite.

I think what you consider "moving" and "fixed" is dependent on whether you
are considering viewpoint of the clinical application or the viewpoint of
the registration algorithm.

Consider a surgical clinical application. You need align preoperative
information (say a surgical plan) with intra-operative information. The
preoperative information is static and the intraoperative information is
dynamic.  It is tempting to treat the static information as "fixed" and the
dynamic information as "moving".  However, in this application you want to
transition preoperative information to the current state of the patient, so
you need to "move" the preoperative information to the current patient
coordinate frame.

What you consider moving and fixed is really a function of the environment
and robustness of the metric.  In some applications, you have "things" in
one of the dataset that are not in the other data set and you do not want
them to bias the registration.  Consider registering a geometric model with
a point cloud of measurements.  The point cloud may have many spurious
measurements (outliers) that do not have correspondences to the model. In
you are using an ICP algorithm, you would want to match points from the
model to points from the scene.  You wouldn't want to match points from the
scene to points from the model because the outliers shouldn't match the
model at all.  Now on the other hand, the model may have structures that are
not present in the data (for instance, registering a model of a complete
bone with data of the bone after part of it is broken off).  So in this
case, you would want to run an ICP algorithm from data to model since the
complete model would never match the data.

My point is that what is "fixed" and what is "moving" is a function of the
data (outliers, missing data, etc.) as well as the model.  In some of our
applications we actually run our registrations both ways.  We run the
algorithm with one assignment of fixed and moving.  Use these results to
trim out mismatched data, and run the registration with moving and fixed
reversed.  So we might go model to data then data to model.

This all being said, I stand by original position that after running a
registration with a fixed and moving image, I would expect the output
transformation to take the moving image to the fixed image.

Jim

-----Original Message-----
From: Stephen R. Aylward [ mailto:aylward at unc . edu <mailto:aylward at unc . edu> ]
Sent: Friday, October 31, 2003 2:42 PM
To: Insight-developers (E-mail)
Subject: [Insight-developers] Inverse transforms

Hi,

1) ITK registration actually returns a transform from the fixed image to
the moving image
2) ITK resample image filter expects a transform from the fixed image to
the moving image
3) No model-to-image registration process is easily implemented using a
fixed-to-moving image transform - the model drives where in the fixed
image the fit should be calculated.   So, all spatial-object-to-image
transforms, the landmark-landmark registration stuff we are doing, and
the ICP method we are implementing apply the transform to the moving
model/points to quantify their match with the fixed image/points.
Therefore we have to pass the Inverse transform to the resample image
filter for them.

We have the landmark initialized MI registration app that must

1) register using landmarks
2) resample the image using the inverse of that transform
3) invert the transform to initialize the MI registration process
4) resmaple the image using the non-inverse of that transform

This is really inconsistent.   Can be documented by saying most
image-image transforms are fixed to moving transforms and all spatial
object transforms are moving to fixed.   I say most image-image
transforms since we are writing one that internally calculates features
and landmarks from the moving image to drive the registration with the
fixed image.

I consider this a huge flaw with no easy answer - I understand why the
resampling is driven by the fixed image.   However, couldn't the
resampling take the inverse and all of the rest be done in the correct
way: tranaform maps moving to fixed?

Stephen

--
===========================================================
Dr. Stephen R. Aylward
Associate Professor of Radiology
Adjunct Associate Professor of Computer Science and Surgery
http://caddlab . rad . unc . edu <http://caddlab . rad . unc . edu> 
aylward at unc . edu
(919) 966-9695

_______________________________________________
Insight-developers mailing list
Insight-developers at itk . org
http://www . itk . org/mailman/listinfo/insight-developers
<http://www . itk . org/mailman/listinfo/insight-developers> 

------_=_NextPart_001_01C39FF1.ECC2A2D2
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE></TITLE>

<META content="MSHTML 6.00.2800.1264" name=GENERATOR></HEAD>
<BODY>
I think I am with Stephen here. Figure 8.2 of the User's 
Guide seems to indicate that the registration framework estimates the 
transformation that maps the moving image into the fixed image. This makes sense 
to me since the moving image is "moving" and the fixed image is 
"fixed". However, Figure 8.34 seems to indicate the opposite. I 
think what you consider "moving" and "fixed" is dependent on whether you are 
considering viewpoint of the clinical application or the viewpoint of the 
registration algorithm. Consider a surgical clinical application. You 
need align preoperative information (say a surgical plan) with intra-operative 
information. The preoperative information is static and the intraoperative 
information is dynamic.&nbsp; It is tempting to treat the static information as 
"fixed" and the dynamic information as "moving".&nbsp; However, in this 
application you want to transition preoperative information to the current state 
of the patient, so you need to "move" the preoperative information to the 
current patient coordinate frame. What you consider moving and fixed is 
really a function of the environment and robustness of the metric.&nbsp; In some 
applications, you have "things" in one of the dataset that are not in the other 
data set and you do not want them to bias the registration.&nbsp; Consider 
registering a geometric model with a point cloud of measurements.&nbsp; The 
point cloud may have many spurious measurements (outliers) that do not have 
correspondences to the model. In you are using an ICP algorithm, you would want 
to match points from the model to points from the scene.&nbsp; You wouldn't want 
to match points from the scene to points from the model because the outliers 
shouldn't match the model at all.&nbsp; Now on the other hand, the model may 
have structures that are not present in the data (for instance, registering a 
model of a complete bone with data of the bone after part of it is broken 
off).&nbsp; So in this case, you would want to run an ICP algorithm from data to 
model since the complete model would never match the data. My point is 
that what is "fixed" and what is "moving" is a function of the data (outliers, 
missing data, etc.) as well as the model.&nbsp; In some of our applications we 
actually run our registrations both ways.&nbsp; We run the algorithm with one 
assignment of fixed and moving.&nbsp; Use these results to trim out mismatched 
data, and run the registration with moving and fixed reversed.&nbsp; So we might 
go model to data then data to model. This all being said, I stand by 
original position that after running a registration with a fixed and moving 
image, I would expect the output transformation to take the moving image to the 
fixed image. Jim -----Original Message----- From: 
Stephen R. Aylward [<A 
href="mailto:aylward at unc . edu">mailto:aylward at unc . edu</A>] Sent: Friday, 
October 31, 2003 2:42 PM To: Insight-developers (E-mail) Subject: 
[Insight-developers] Inverse transforms Hi, 1) ITK 
registration actually returns a transform from the fixed image to the moving 
image 2) ITK resample image filter expects a transform from the fixed image 
to the moving image 3) No model-to-image registration process is easily 
implemented using a fixed-to-moving image transform - the model drives where 
in the fixed image the fit should be calculated.&nbsp;&nbsp; So, all 
spatial-object-to-image transforms, the landmark-landmark registration stuff 
we are doing, and the ICP method we are implementing apply the transform to 
the moving model/points to quantify their match with the fixed 
image/points. Therefore we have to pass the Inverse transform to the resample 
image filter for them. We have the landmark initialized MI 
registration app that must 1) register using landmarks 2) resample the 
image using the inverse of that transform 3) invert the transform to 
initialize the MI registration process 4) resmaple the image using the 
non-inverse of that transform This is really inconsistent.&nbsp;&nbsp; 
Can be documented by saying most image-image transforms are fixed to moving 
transforms and all spatial object transforms are moving to fixed.&nbsp;&nbsp; 
I say most image-image transforms since we are writing one that internally 
calculates features and landmarks from the moving image to drive the 
registration with the fixed image. I consider this a huge flaw with no 
easy answer - I understand why the resampling is driven by the fixed 
image.&nbsp;&nbsp; However, couldn't the resampling take the inverse and all 
of the rest be done in the correct way: tranaform maps moving to 
fixed? Stephen -- =========================================================== Dr. 
Stephen R. Aylward Associate Professor of Radiology Adjunct Associate 
Professor of Computer Science and Surgery <A 
href="http://caddlab . rad . unc . edu" 
target=_blank>http://caddlab . rad . unc . edu</A> aylward at unc . edu (919) 
966-9695 _______________________________________________ Insight-developers 
mailing list Insight-developers at itk . org <A 
href="http://www . itk . org/mailman/listinfo/insight-developers" 
target=_blank>http://www . itk . org/mailman/listinfo/insight-developers</A> </BODY></HTML>

------_=_NextPart_001_01C39FF1.ECC2A2D2--