<br>For a 2D affine transform, what are the parameters returned by GetParameters?<br><br>Thanks,<br>Darren<br><br><br><br><br><br><br><div class="gmail_quote">On Mon, Oct 26, 2009 at 12:17 PM, Darren Weber <span dir="ltr"><<a href="mailto:darren.weber.lists@gmail.com">darren.weber.lists@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><br><div class="gmail_quote"><div class="im">On Sun, Oct 25, 2009 at 2:50 PM, Richard Beare <span dir="ltr"><<a href="mailto:richard.beare@gmail.com" target="_blank">richard.beare@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
My solution to a similar problem was to use the similarity transform<br>
and throw away the scale component. In my data (marmoset brain<br>
sections) there was enough change in size between adjacent slices to<br>
make the more complex transform necessary. Without it the registration<br>
had a range of equivalent and wrong solutions - consider registering<br>
two discs of different sizes. Most metrics will consider all solutions<br>
with the small one inside the big one as equivalent, but you're<br>
probably going to want the one with the discs centres aligned.<br>
<br></blockquote></div><div><br>I see, so the registration metrics worked better using the similarity transform than a rigid transform, but you get a rigid transform once you throw out the scale from the similarity transform. The similarity transform is required for a more effective registration. My problem is very similar, but using an affine transform (I do want to keep the shear transform component, which is not available in the similarity transform).<br>
<br> </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So I can see a couple of options - try using the simularity transform<br>
as your bulk transform and then turn of the scale later. (did you find<br>
a nice way of composing bsplines?)<br></blockquote></div><div><br>There are some options to look at later for the bspline composition (see Luis' comments in the previous email thread; I'm not clear that it's easily applied to my problem and I don't have time to look into the details right now). The bspline is conditioned using an affine as the bulk transform, so the scale issue needs to be addressed in the affine (or other bulk transform and possibly again in the bspline too). The affine itself is initialized using a centered transform (of some kind; probably a center of mass metric and a translation transform).<br>
<br><span style="font-family: courier new,monospace;">typedef itk::CenteredTransformInitializer< TransformType, bwInputImageType, bwInputImageType > TransformInitializerType;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">TransformInitializerType::Pointer initializer = TransformInitializerType::New();</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">initializer->SetTransform( affineTransform );</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">initializer->SetFixedImage( bwFixInfoFilter->GetOutput() );</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">initializer->SetMovingImage( bwMovInfoFilter->GetOutput() );</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">initializer->MomentsOn();</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">initializer->InitializeTransform();</span><br style="font-family: courier new,monospace;">
<br><br> </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Or<br>
<br>
There are ways of decomposing the affine transform matrix into shift,<br>
rotation, shear and scale components - from memory the publications<br>
relating to flirt (the fsl registration tool) discussed this, and it<br>
is probably available elsewhere.<br>
<br></blockquote></div><div><br>I've FLIRT many times in human brain imaging work, but I assume it will not work with the RGB images of the microscopy data (and I prefer to work with ITK on this project). The approach that I've taken is partly based on prior experience with FLIRT and similar registration tools for brain imaging (fMRI), where a series of pair-wise transforms can be calculated in parallel and applied later using a composition. I didn't anticipate the scale problem in the composition for the data in this project. (Perhaps the FLIRT command line has tools for decomposition of the transform matrix, but I want to do this with ITK.)<br>
<br>In previous work that required understanding a transform matrix, it appeared that there are no obligatory standards on how to shape the matrix (probably depends on whether the matrix is pre-multiplied or post-multiplied in specific applications). The elements of the matrix should have a known role in the affine transform, some for rotation, translation, etc. The specifics of the implementation in ITK are important (the registration provides a transform from fixed-to-moving image).<br>
<br>There are some general online resources on affine transform matrices:<br><a href="http://en.wikipedia.org/wiki/Affine_transformation" target="_blank">http://en.wikipedia.org/wiki/Affine_transformation</a><br><a href="http://mathworld.wolfram.com/AffineTransformation.html" target="_blank">http://mathworld.wolfram.com/AffineTransformation.html</a><br>
<br>Some libraries use specific methods for each component: translation, rotation, shear, scale.<br><br>For example, in java 1.2:<br><a href="http://www.glyphic.com/transform/imageonly/1intro.html" target="_blank">http://www.glyphic.com/transform/imageonly/1intro.html</a><br>
<br>Also here in the Apple core graphics lib, there are methods for each component of the transform:<br>
<a href="http://opensource.apple.com/source/WebCore/WebCore-4A102/platform/AffineTransform.h" target="_blank">http://opensource.apple.com/source/WebCore/WebCore-4A102/platform/AffineTransform.h</a><br>
That is,<br>
<pre> AffineTransform &scale(<span>double</span> sx, <span>double</span> sy);<br> AffineTransform &rotate(<span>double</span> d);<br> AffineTransform &translate(<span>double</span> tx, <span>double</span> ty);<br>
AffineTransform &shear(<span>double</span> sx, <span>double</span> sy);<br></pre>
<br>In this page you can see a decomposition of a 2D affine matrix into the rotation, shear, scaling, and translation:<br><a href="http://www.gnome.org/%7Emathieu/libart/libart-affine-transformation-matrices.html" target="_blank">http://www.gnome.org/~mathieu/libart/libart-affine-transformation-matrices.html</a><br>
Note the method to extract a scale factor, called art_affine_expansion(). When the matrix is represented in it's component parts, it is trivial to "knock out" the scaling component by setting the diagonal elements of the scale matrix to 1.0.<br>
<br>However, ITK doesn't appear to represent the matrix in component parts. My current project work is using 2D images and ITK 3.16,<br><a href="http://www.itk.org/Doxygen316/html/classitk_1_1AffineTransform.html" target="_blank">http://www.itk.org/Doxygen316/html/classitk_1_1AffineTransform.html</a><br>
<br>There seem to be some specific methods to get/set the affine components (translation or offset, rotate2D, rotate3D, etc. - maybe no shear method?), but there are general get/set matrix methods, so perhaps it is possible to use something like:<br>
<br><span style="font-family: courier new,monospace;">MatrixType thisMatrix = affineTFM->GetMatrix();</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">// modify thisMatrix to remove scale component</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">affineTFM->SetMatrix(thisMatrix);</span><br style="font-family: courier new,monospace;"><br><br>The trick is knowing which elements of the matrix contain the scale factor(s). Perhaps it is the diagonal elements, as in:<br>
<a href="http://www.gnome.org/%7Emathieu/libart/libart-affine-transformation-matrices.html" target="_blank">http://www.gnome.org/~mathieu/libart/libart-affine-transformation-matrices.html</a><br>
<br>If so, the diagonal elements of the 'composed' matrix contain both rotation and scaling components. Perhaps it is possible to isolate the scale component from the rotation component with some help from the ITK get/set rotation2D methods? If that can be done, then it should be easy to replace the diagonal of the full affine matrix with just the diagonal elements from the rotation matrix, to effectively remove the scaling component from the diagonal of the 'composed' matrix (and leave everything else alone).<br>
<br>Does that make sense? Has anyone done this before?<br><br>Best regards,<br><font color="#888888">Darren<br><br><br><br><br> </font></div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sun, Oct 25, 2009 at 2:16 PM, Darren Weber<br>
<div><div></div><div><<a href="mailto:darren.weber.lists@gmail.com" target="_blank">darren.weber.lists@gmail.com</a>> wrote:<br>
><br>
><br>
> On Sat, Oct 24, 2009 at 7:58 PM, Darren Weber <<a href="mailto:darren.weber.lists@gmail.com" target="_blank">darren.weber.lists@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Is there an easy way to turn off the scaling component of an affine<br>
>> transform?<br>
>><br>
>> Is there a method in itkAffineTransform to set the scale component to a<br>
>> constant?<br>
>><br>
>> Would you manually pull out the matrix, etc., modify it and then reset it<br>
>> in the itkAffineTransform?<br>
>><br>
>> TIA,<br>
>> Darren<br>
>><br>
><br>
> PS, Maybe a geometric problem can help (or obscure) the problem. Imagine a<br>
> series of conic sections, starting at the tip of a cone and working down<br>
> toward the base. Each of these 2D conic sections needs to be registered<br>
> into a 3D volume to recreate the cone. If each section were a "pure"<br>
> section taken along the axis from the tip to the center of the base, this<br>
> would be fairly trivial as a rigid-body registration (probably no<br>
> registration at all is required, just a known sequence of slices). However,<br>
> assume each section has an unknown deformation (but the series of sections<br>
> is given in a known order). If the affine registration starts at the tip<br>
> (img001) and propagates all the way to the base (img100), the final diameter<br>
> of the base section will be decreased to about the same diameter as the tip.<br>
><br>
> The real problem is a series of microscopy images for a worm, which has a<br>
> smaller diameter at the head and tail than in the body.<br>
><br>
><br>
</div></div><div><div></div><div>> _____________________________________<br>
> Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the ITK FAQ at:<br>
> <a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
><br>
><br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br>