<br><br><div class="gmail_quote">On Sun, Oct 25, 2009 at 2:35 PM, Luis Ibanez <span dir="ltr"><<a href="mailto:luis.ibanez@kitware.com">luis.ibanez@kitware.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 Darren,<br>
<br>
This looks like a very interesting problem.<br>
<br>
Robert's advice is probably the first thing to try<br>
(using the Rigid transform).<br>
<br>
...Although...<br>
you mentioned that you expect to have a deformation<br>
on every slice...<br>
<br>
Do you think that you actually will need shearing<br>
and... maybe a BSpline deformation ?<br></blockquote><div><br><br>Current work is exploring the application of Affine and BSpline transforms. It appears that BSpline transforms may be useful (with a low order). Anyhow, the scale problem is pressing at the moment.<br>
<br>Looking at 'InsightToolkit-3.16.0/Code/Common/itkAffineTransform.h', it contains:<br><br><span style="font-family: courier new,monospace;"> /** Compose affine transformation with a scaling</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> *</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * This method modifies self to magnify the source by a given</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * factor along each axis. If all factors are the same, or only a</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * single factor is given, then the scaling is isotropic;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * otherwise it is anisotropic. If an odd number of factors are</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * negative, then the parity of the image changes. If any of the</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * factors is zero, then the transformation becomes a projection</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * and is not invertible. The scaling is precomposed with self if</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> * pre is true, and postcomposed otherwise. </span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> * Note that the scaling is applied centered at the origin. */</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> void Scale(const OutputVectorType &factor, bool pre=0);</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"> void Scale(const TScalarType &factor, bool pre=0);</span><br>
<br><br>This may provide a way to 'undo' the scale component of the AffineTransform.<br><br>Is it true that <span style="font-family: courier new,monospace;">myAffineTFM->Scale(0, false)</span> would undo the scale component of the transform?<br>
<br>Is the scalar factor input a 1 or 0 to 'remove' the scale component from the transform? The scalar value 1 is probably not going to work, because the composition is a multiplication (?). Is the use of a zero factor the right choice here or does it do something else?<br>
<br>Perhaps we can clarify the meaning of this for me: "<span style="font-family: courier new,monospace;">If any of the</span><span style="font-family: courier new,monospace;"> factors is zero, then the transformation becomes a projection</span><span style="font-family: courier new,monospace;"> and is not invertible."</span><br>
<br>My assumption is that the Scale is independent of the other affine components (rotation, shear, translation), but using the method as above to 'undo' the scale component may have other consequences if that assumption doesn't hold true.<br>
<br>In some respects, it would be nice to pull out the scale values to check for significant anisotropy before discarding the scale. Unfortunately there is no GetScale method (right?). It appears that such methods, Set/Get Scale, are available in Common/itkScalableAffineTransform.h. However, my problem would not be suitable for using that class directly. Perhaps the methods for Set/Get Scale in itkScalableAffineTransform could migrate up to itkAffineTransform? Should I consider programming a custom sub-class to get those methods for the AffineTransform?<br>
<br>Many thanks,<br>Darren<br><br><br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Luis<br>
<br>
<br>
-------------------------------------------------------------------------------------------------<br>
On Sat, Oct 24, 2009 at 11:16 PM, Darren Weber<br>
<div><div></div><div class="h5"><<a href="mailto:darren.weber.lists@gmail.com">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">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 class="h5">> _____________________________________<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><br>