[Insight-users] affine transform without scaling?

Fri Oct 30 20:09:30 EDT 2009

For a 2D affine transform, what are the parameters returned by
GetParameters?

Thanks,
Darren

On Mon, Oct 26, 2009 at 12:17 PM, Darren Weber <darren.weber.lists at gmail.com
> wrote:

>
>
> On Sun, Oct 25, 2009 at 2:50 PM, Richard Beare <richard.beare at gmail.com>wrote:
>
>> Hi,
>>
>> My solution to a similar problem was to use the similarity transform
>> and throw away the scale component. In my data (marmoset brain
>> sections) there was enough change in size between adjacent slices to
>> make the more complex transform necessary. Without it the registration
>> had a range of equivalent and wrong solutions - consider registering
>> two discs of different sizes. Most metrics will consider all solutions
>> with the small one inside the big one as equivalent, but you're
>> probably going to want the one with the discs centres aligned.
>>
>>
> 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).
>
>
>
>> So I can see a couple of options - try using the simularity transform
>> as your bulk transform and then turn of the scale later. (did you find
>> a nice way of composing bsplines?)
>>
>
> 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).
>
> typedef itk::CenteredTransformInitializer< TransformType, bwInputImageType,
> bwInputImageType > TransformInitializerType;
> TransformInitializerType::Pointer initializer =
> TransformInitializerType::New();
> initializer->SetTransform( affineTransform );
> initializer->SetFixedImage(  bwFixInfoFilter->GetOutput() );
> initializer->SetMovingImage( bwMovInfoFilter->GetOutput() );
> initializer->MomentsOn();
> initializer->InitializeTransform();
>
>
>
>
>>
>> Or
>>
>> There are ways of decomposing the affine transform matrix into shift,
>> rotation, shear and scale components - from memory the publications
>> relating to flirt (the fsl registration tool) discussed this, and it
>> is probably available elsewhere.
>>
>>
> 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.)
>
> 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).
>
> There are some general online resources on affine transform matrices:
> http://en.wikipedia.org/wiki/Affine_transformation
> http://mathworld.wolfram.com/AffineTransformation.html
>
> Some libraries use specific methods for each component: translation,
> rotation, shear, scale.
>
> For example, in java 1.2:
> http://www.glyphic.com/transform/imageonly/1intro.html
>
> Also here in the Apple core graphics lib, there are methods for each
> component of the transform:
>
> http://opensource.apple.com/source/WebCore/WebCore-4A102/platform/AffineTransform.h
> That is,
>
>     AffineTransform &scale(double sx, double sy);
>     AffineTransform &rotate(double d);
>     AffineTransform &translate(double tx, double ty);
>
>     AffineTransform &shear(double sx, double sy);
>
>
> In this page you can see a decomposition of a 2D affine matrix into the
> rotation, shear, scaling, and translation:
>
> http://www.gnome.org/~mathieu/libart/libart-affine-transformation-matrices.html<http://www.gnome.org/%7Emathieu/libart/libart-affine-transformation-matrices.html>
> 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.
>
> However, ITK doesn't appear to represent the matrix in component parts.  My
> current project work is using 2D images and ITK 3.16,
> http://www.itk.org/Doxygen316/html/classitk_1_1AffineTransform.html
>
> 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:
>
> MatrixType thisMatrix = affineTFM->GetMatrix();
> // modify thisMatrix to remove scale component
> affineTFM->SetMatrix(thisMatrix);
>
>
> The trick is knowing which elements of the matrix contain the scale
> factor(s).  Perhaps it is the diagonal elements, as in:
>
> http://www.gnome.org/~mathieu/libart/libart-affine-transformation-matrices.html<http://www.gnome.org/%7Emathieu/libart/libart-affine-transformation-matrices.html>
>
> 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).
>
> Does that make sense?  Has anyone done this before?
>
> Best regards,
> Darren
>
>
>
>
>
>
>> On Sun, Oct 25, 2009 at 2:16 PM, Darren Weber
>> <darren.weber.lists at gmail.com> wrote:
>> >
>> >
>> > On Sat, Oct 24, 2009 at 7:58 PM, Darren Weber <
>> darren.weber.lists at gmail.com>
>> > wrote:
>> >>
>> >> Is there an easy way to turn off the scaling component of an affine
>> >> transform?
>> >>
>> >> Is there a method in itkAffineTransform to set the scale component to a
>> >> constant?
>> >>
>> >> Would you manually pull out the matrix, etc., modify it and then reset
>> it
>> >> in the itkAffineTransform?
>> >>
>> >> TIA,
>> >> Darren
>> >>
>> >
>> > PS,  Maybe a geometric problem can help (or obscure) the problem.
>> Imagine a
>> > series of conic sections, starting at the tip of a cone and working down
>> > toward the base.  Each of these 2D conic sections needs to be registered
>> > into a 3D volume to recreate the cone.  If each section were a "pure"
>> > section taken along the axis from the tip to the center of the base,
>> this
>> > would be fairly trivial as a rigid-body registration (probably no
>> > registration at all is required, just a known sequence of slices).
>> However,
>> > assume each section has an unknown deformation (but the series of
>> sections
>> > is given in a known order).  If the affine registration starts at the
>> tip
>> > (img001) and propagates all the way to the base (img100), the final
>> diameter
>> > of the base section will be decreased to about the same diameter as the
>> tip.
>> >
>> > The real problem is a series of microscopy images for a worm, which has
>> a
>> > smaller diameter at the head and tail than in the body.
>> >
>> >
>> > _____________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Please keep messages on-topic and check the ITK FAQ at:
>> > http://www.itk.org/Wiki/ITK_FAQ
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://www.itk.org/mailman/listinfo/insight-users
>> >
>> >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-users/attachments/20091030/6c7f2b46/attachment-0001.htm>