From blowekamp at mail.nih.gov  Fri Aug  1 09:36:09 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 1 Aug 2014 09:36:09 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
 <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
 <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>
Message-ID: <C588C78C-F0CA-40F9-A0CA-74D84B12983C@mail.nih.gov>

Nick,

I hope you can make it to today's TCON. I can demo that notebook I linked too. It should clarify things.

Brad

On Jul 30, 2014, at 1:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:

>> To try to summaries... sorry if have not been clear enough in my explanations.
> 
> No, I blame me?I?m consistently distracted by the scenery outside here in
> California and it?s definitely affecting my ability to concentrate on code
> questions.
> 
>> INITIAL QUESTION
>> 
>> How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?
> 
> The composite transform is agnostic with respect to whether or not a 
> transform has a center or any other fixed parameter set.  The only
> distinction we make is typology with respect to linear/deformable. To 
> be clear, we?re not discussing any of the  ?Centered? transforms:
> 
> * CenteredAffineTransform
> * CenteredEuler3DTransform
> * CenteredEuler2DTransform
> * CenteredSimilarity2DTransform
> 
> None of those transforms are used in ANTs but I don?t think 
> their optimization would be an issue in the new ITKv4 registration 
> framework.
> 
> The virtual domain is simply defined in terms of standard image 
> geometry (origin, spacing, etc.) and is currently set in terms of the 
> fixed image geometry.  
> 
>> MY UNDERSTANDING
>> 
>> 1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )
> 
> I don?t see why it would only work correctly for a single transform.  Suppose
> I optimize a translation transform to get it?s optimal parameters for a given
> registration problem.  It?s not clear to me why it would be a problem to follow
> that with optimizing an Euler3D transform (which we do all the time in ANTs).  
> Obviously, we have to specify a staring point for the second transform (which
> is identity by default) and perhaps it would be better to have a different 
> starting point but I don?t see why starting with the default parameters is a 
> problem.
> 
> If the ?Center initialized transform? is one of the transforms listed above 
> then we don?t use those.  If it?s simply the result of using the 
> CenteredTransformInitializer, then we just pull the itk::TranslationTransform 
> part from the result and push that translation transform into the composite 
> transform queue.   I don?t see why it would be a problem to then optimize, 
> for example, the Euler3DTransform which just has 3 translation parameters 
> and 3 angle parameters to optimize where the center is implicitly defined 
> (unlike the CenteredEuler3DTransform which does have additional Center 
> parameters).  
> 
>> 2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.
> 
> Yes, that would probably be a better initialization but I don?t know why it would
> be a problem for the current framework to optimize with the origin elsewhere.
> Right now, each transform within the composite transform queue is 
> optimized starting from its identity parameters but perhaps the initializer
> idea that you propose would improve optimization. 
> 
>> I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.
>> PROPOSAL
>> 
>> Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 
>> 
>> Brad
> 


From ntustison at gmail.com  Fri Aug  1 10:15:19 2014
From: ntustison at gmail.com (Nick Tustison)
Date: Fri, 1 Aug 2014 08:15:19 -0600
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <C588C78C-F0CA-40F9-A0CA-74D84B12983C@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
 <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
 <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>
 <C588C78C-F0CA-40F9-A0CA-74D84B12983C@mail.nih.gov>
Message-ID: <6D8816B7-9BE5-494A-BAE8-81057667632E@gmail.com>

Sorry, Brad, but I'm currently in Salt Lake at a funeral.  I'd really like to understand better so, if you're available, I can do it anytime during the week on another call.

Sent from Howling Fantods

> On Aug 1, 2014, at 7:36 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
> Nick,
> 
> I hope you can make it to today's TCON. I can demo that notebook I linked too. It should clarify things.
> 
> Brad
> 
> On Jul 30, 2014, at 1:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
> 
>>> To try to summaries... sorry if have not been clear enough in my explanations.
>> 
>> No, I blame me?I?m consistently distracted by the scenery outside here in
>> California and it?s definitely affecting my ability to concentrate on code
>> questions.
>> 
>>> INITIAL QUESTION
>>> 
>>> How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?
>> 
>> The composite transform is agnostic with respect to whether or not a 
>> transform has a center or any other fixed parameter set.  The only
>> distinction we make is typology with respect to linear/deformable. To 
>> be clear, we?re not discussing any of the  ?Centered? transforms:
>> 
>> * CenteredAffineTransform
>> * CenteredEuler3DTransform
>> * CenteredEuler2DTransform
>> * CenteredSimilarity2DTransform
>> 
>> None of those transforms are used in ANTs but I don?t think 
>> their optimization would be an issue in the new ITKv4 registration 
>> framework.
>> 
>> The virtual domain is simply defined in terms of standard image 
>> geometry (origin, spacing, etc.) and is currently set in terms of the 
>> fixed image geometry.  
>> 
>>> MY UNDERSTANDING
>>> 
>>> 1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )
>> 
>> I don?t see why it would only work correctly for a single transform.  Suppose
>> I optimize a translation transform to get it?s optimal parameters for a given
>> registration problem.  It?s not clear to me why it would be a problem to follow
>> that with optimizing an Euler3D transform (which we do all the time in ANTs).  
>> Obviously, we have to specify a staring point for the second transform (which
>> is identity by default) and perhaps it would be better to have a different 
>> starting point but I don?t see why starting with the default parameters is a 
>> problem.
>> 
>> If the ?Center initialized transform? is one of the transforms listed above 
>> then we don?t use those.  If it?s simply the result of using the 
>> CenteredTransformInitializer, then we just pull the itk::TranslationTransform 
>> part from the result and push that translation transform into the composite 
>> transform queue.   I don?t see why it would be a problem to then optimize, 
>> for example, the Euler3DTransform which just has 3 translation parameters 
>> and 3 angle parameters to optimize where the center is implicitly defined 
>> (unlike the CenteredEuler3DTransform which does have additional Center 
>> parameters).  
>> 
>>> 2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.
>> 
>> Yes, that would probably be a better initialization but I don?t know why it would
>> be a problem for the current framework to optimize with the origin elsewhere.
>> Right now, each transform within the composite transform queue is 
>> optimized starting from its identity parameters but perhaps the initializer
>> idea that you propose would improve optimization. 
>> 
>>> I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.
>>> PROPOSAL
>>> 
>>> Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 
>>> 
>>> Brad
> 

From blowekamp at mail.nih.gov  Fri Aug  1 10:17:46 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 1 Aug 2014 10:17:46 -0400
Subject: [ITK-dev] Google Hangout TCON now
Message-ID: <D16B74C1-4EFE-4095-A57C-FCD452F122AB@mail.nih.gov>

Hello,

I set up a google hangout TCON for now:
https://plus.google.com/hangouts/_/event/cn8hv391boek27j8c7blph7igho

Brad


From matt at mmmccormick.com  Fri Aug  1 10:48:29 2014
From: matt at mmmccormick.com (Matthew McCormick (thewtex))
Date: Fri, 1 Aug 2014 10:48:29 -0400
Subject: [ITK-dev] Google Hangout TCON now
In-Reply-To: <D16B74C1-4EFE-4095-A57C-FCD452F122AB@mail.nih.gov>
References: <D16B74C1-4EFE-4095-A57C-FCD452F122AB@mail.nih.gov>
Message-ID: <CA+XjkaBqAJp58vvy70a2Rzb1oZyOQfKPOhTk8ETPqMinzffmBg@mail.gmail.com>

Thanks for setting this up.  I am traveling again this week, but I
will be resuming a more normal schedule next week and should be able
to join.

Matt

On Fri, Aug 1, 2014 at 10:17 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Hello,
>
> I set up a google hangout TCON for now:
> https://plus.google.com/hangouts/_/event/cn8hv391boek27j8c7blph7igho
>
> Brad
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers

From blowekamp at mail.nih.gov  Fri Aug  1 11:31:54 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Fri, 1 Aug 2014 11:31:54 -0400
Subject: [ITK-dev] Move ITK TCONs to Google Hangout?
Message-ID: <A7658BA6-ED9E-415B-B212-B49A8C9AEC24@mail.nih.gov>

Hello,

Should we move the weekly ITK TCONs to Google hangouts?

Using Google hangouts would be more visible and public along with having an automatic process to start the event. Additionally there is the ability to phone in people to the hang out?

Brad

From stnava at gmail.com  Fri Aug  1 12:06:42 2014
From: stnava at gmail.com (brian avants)
Date: Fri, 1 Aug 2014 12:06:42 -0400
Subject: [ITK-dev] Move ITK TCONs to Google Hangout?
In-Reply-To: <A7658BA6-ED9E-415B-B212-B49A8C9AEC24@mail.nih.gov>
References: <A7658BA6-ED9E-415B-B212-B49A8C9AEC24@mail.nih.gov>
Message-ID: <CABWzF4VyhYNb8vUiaPXyA305+hX=KpBSeW4DV8i+v8qTm9Tqdw@mail.gmail.com>

+1

brian




On Fri, Aug 1, 2014 at 11:31 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> Hello,
>
> Should we move the weekly ITK TCONs to Google hangouts?
>
> Using Google hangouts would be more visible and public along with having an automatic process to start the event. Additionally there is the ability to phone in people to the hang out?
>
> Brad
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers

From blowekamp at mail.nih.gov  Sat Aug  2 08:39:25 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Sat, 02 Aug 2014 08:39:25 -0400
Subject: [ITK-dev] Upgraded factory.kitware Mac compiler
Message-ID: <96995EF3-CB2E-4DBD-9360-A7D3909D25E6@mail.nih.gov>

Hello,

Hello there is recently some regular failing tests on the factory.kitware Mac robot build:
http://open.cdash.org/viewTest.php?onlyfailed&buildid=3433716

What specific compiler, Xcode, and os version is the system now running? Was it recently upgraded?

These failures look vaguely familiar to me, not sure quite why. May have been at some point in the GNU gcc->llvm-gcc transition when things didn't work too good...

Brad



From jchris.fillionr at kitware.com  Sat Aug  2 11:03:59 2014
From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin)
Date: Sat, 2 Aug 2014 11:03:59 -0400
Subject: [ITK-dev] Upgraded factory.kitware Mac compiler
In-Reply-To: <96995EF3-CB2E-4DBD-9360-A7D3909D25E6@mail.nih.gov>
References: <96995EF3-CB2E-4DBD-9360-A7D3909D25E6@mail.nih.gov>
Message-ID: <CANLz8R5YpnDffP2MzXz1Yzd3qhSC+eSQP8-d3OmJj02C-6Sw1Q@mail.gmail.com>

Hi Brad,

All details are captured here:

    http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=23528


XCode before:

 * Xcode: 3.2.6 - uildVersion: 10M2518
 * gcc-4.0: i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494)
 * gcc-4.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc.
build 5666) (dot 3)
 * llvm-gcc: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on
Apple Inc. build 5658) (LLVM build 2335.6)
 * clang: Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn

XCode after:

 * Xcode: 4.2 - Build version 4C199
 * gcc-4.0: i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494)
 * gcc-4.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc.
build 5666) (dot 3)
 * llvm-gcc: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on
Apple Inc. build 5658) (LLVM build 2336.1.00)
 * clang: Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based
on LLVM 3.0svn)



Hth
Jc


On Sat, Aug 2, 2014 at 8:39 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Hello,
>
> Hello there is recently some regular failing tests on the factory.kitware
> Mac robot build:
> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3433716
>
> What specific compiler, Xcode, and os version is the system now running?
> Was it recently upgraded?
>
> These failures look vaguely familiar to me, not sure quite why. May have
> been at some point in the GNU gcc->llvm-gcc transition when things didn't
> work too good...
>
> Brad
>
>
>


-- 
+1 919 869 8849
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140802/9386ea66/attachment.html>

From blowekamp at mail.nih.gov  Sat Aug  2 11:25:49 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Sat, 02 Aug 2014 11:25:49 -0400
Subject: [ITK-dev] Upgraded factory.kitware Mac compiler
In-Reply-To: <CANLz8R5YpnDffP2MzXz1Yzd3qhSC+eSQP8-d3OmJj02C-6Sw1Q@mail.gmail.com>
References: <96995EF3-CB2E-4DBD-9360-A7D3909D25E6@mail.nih.gov>
 <CANLz8R5YpnDffP2MzXz1Yzd3qhSC+eSQP8-d3OmJj02C-6Sw1Q@mail.gmail.com>
Message-ID: <AA4A0D35-5F18-480B-8476-F4ABDAE4A1E1@mail.nih.gov>

OK,

I think the compiler being used on the system is not a winner.

Something need to be changes on the system to make this more identifiable, perhaps changing the build name to be llvm-gcc-4.2. As it's not apparent in the configuration:
 The C compiler identification is GNU 4.2.1
-- The CXX compiler identification is GNU 4.2.1
-- Checking whether C compiler has -isysroot
-- Checking whether C compiler has -isysroot - yes
-- Checking whether C compiler supports OSX deployment target flag
-- Checking whether C compiler supports OSX deployment target flag - yes
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Checking whether CXX compiler has -isysroot
-- Checking whether CXX compiler has -isysroot - yes
-- Checking whether CXX compiler supports OSX deployment target flag
-- Checking whether CXX compiler supports OSX deployment target flag - yes
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
Digging into the system information test[1] we can find the following:
sing built-in specs.
Target: i686-apple-darwin10
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
 /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin10/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.6.8 -weak_reference_mismatches non-weak -o cmTryCompileExec885700192 -lcrt1.10.6.o -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64 -L/usr/lib/i686-apple-darwin10/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/lib/gcc/i686-apple-darwin10/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/../../.. -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/../../.. -search_paths_first -headerpad_max_install_names -v CMakeFiles/cmTryCompileExec885700192.dir/CMakeCCompilerABI.c.o -lSystem -lgcc -lSystem
collect2 version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) (i686 Darwin)

But the GCC masquerading version is not too helpful. 

[1] http://open.cdash.org/testDetails.php?test=272099142&build=3433750
On Aug 2, 2014, at 11:03 AM, Jean-Christophe Fillion-Robin <jchris.fillionr at kitware.com> wrote:

> Hi Brad, 
> 
> All details are captured here: 
> 
>     http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=23528
> 
> 
> XCode before:
> 
>  * Xcode: 3.2.6 - uildVersion: 10M2518
>  * gcc-4.0: i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494)
>  * gcc-4.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
>  * llvm-gcc: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.6)
>  * clang: Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM 2.9svn
> 
> XCode after:
> 
>  * Xcode: 4.2 - Build version 4C199
>  * gcc-4.0: i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494)
>  * gcc-4.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
>  * llvm-gcc: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
>  * clang: Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
> 
> 
> Hth
> Jc
> 
> 
> On Sat, Aug 2, 2014 at 8:39 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello,
> 
> Hello there is recently some regular failing tests on the factory.kitware Mac robot build:
> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3433716
> 
> What specific compiler, Xcode, and os version is the system now running? Was it recently upgraded?
> 
> These failures look vaguely familiar to me, not sure quite why. May have been at some point in the GNU gcc->llvm-gcc transition when things didn't work too good...
> 
> Brad
> 
> 
> 
> 
> 
> -- 
> +1 919 869 8849

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140802/96bfd5da/attachment.html>

From blowekamp at mail.nih.gov  Sat Aug  2 19:48:53 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Sat, 02 Aug 2014 19:48:53 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
 transform
In-Reply-To: <EAA163371EE66741A63B092281D1F3FE1884ED74@itsnt444.iowa.uiowa.edu>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>,
 <CFFD962C.871A8%hans-johnson@uiowa.edu>
 <EAA163371EE66741A63B092281D1F3FE1884ED74@itsnt444.iowa.uiowa.edu>
Message-ID: <97C77D92-4BAD-4D90-912D-E2AB95D63E19@mail.nih.gov>

Hello Ali,

I created a notebook to try to demonstrate the problem you are describing:
http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Importance%20of%20Center%20with%20Affine%20Registration.ipynb

If the center of an Affine transformation isn't correctly initialized then the optimization is not speedy or robust. I think it's best illustrated with these two graphs:




Notice that with the Center being the origin, all 1000 iterations are exhausted, and the metric is slowing decreasing. And this is with the translation path being around the length to 10. If the spacing was bigger or more offset from the origin the situation would be worse.

I don't think this is a bug with the registration framework. I think new initializers for composite transforms are needed, along with documentation how the 2 good ways to initialize the registration methods transforms.


Brad

On Aug 1, 2014, at 8:08 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:

> Brad,
> 
> I have exactly the same issue. I wrote a simple registration program that is run in two stages:
> -Translation
> -Affine
> 
> My fixed and moving images are in 2D, and the moving image is created from the fixed image by
> rotation of 10 degree and translation of [13,17] in X and Y directions.
> 
> The first stage does a translation registration and the result transform is added to a composite transform
> that is used as the initial moving transform of the second stage.
> 
> After the registration the result transform of the second stage is also added to the composite transform
> to be used by the resampler.
> 
> I have printed the composite transform to the screen:
> 
> 2481: CompositeTransform (0x7fa359a18b00)
> 2481:   RTTI typeinfo:   itk::CompositeTransform<double, 2u>
> 2481:   Reference Count: 2
> 2481:   Modified Time: 20949
> 2481:   Debug: Off
> 2481:   Object Name: 
> 2481:   Observers: 
> 2481:     none
> 2481:   Transforms in queue, from begin to end:
> 2481:   >>>>>>>>>
> 2481:   TranslationTransform (0x7fa359a199b0)
> 2481:     RTTI typeinfo:   itk::TranslationTransform<double, 2u>
> 2481:     Reference Count: 7
> 2481:     Modified Time: 1648
> 2481:     Debug: Off
> 2481:     Object Name: 
> 2481:     Observers: 
> 2481:       none
> 2481:     Offset: [12.801, 15.8578]
> 2481:   >>>>>>>>>
> 2481:   AffineTransform (0x7fa359d095a0)
> 2481:     RTTI typeinfo:   itk::AffineTransform<double, 2u>
> 2481:     Reference Count: 5
> 2481:     Modified Time: 20946
> 2481:     Debug: Off
> 2481:     Object Name: 
> 2481:     Observers: 
> 2481:       none
> 2481:     Matrix: 
> 2481:       1.01593 -0.0100051 
> 2481:       -0.00835669 1.01113 
> 2481:     Offset: [-0.358829, -0.290093]
> 2481:     Center: [0, 0]
> 2481:     Translation: [-0.358829, -0.290093]
> 2481:     Inverse: 
> 2481:       0.984397 0.00974056 
> 2481:       0.00813575 0.989073 
> 2481:     Singular: 0
> 2481:   End of MultiTransform.
> 2481: <<<<<<<<<<
> 
> As it can be seen, the translation transform provides a good initialization since its offset (Offset: [12.801, 15.8578]) is close to the shift parameters.
> 
> However, the Affine transform fails to rotate the moving image since its Matrix is almost identity.
> Possible reason can be the improper Center of Affine transform that is fixed to [0,0], and not at geometrical center or center of mass.
> 
> To make sure that I have not made any crazy mistake in my example, I simulated my example parameters in ANTs, and ANTs returned
> the same results and failed to register the images!!
> 
>>>>>> ANTs command line <<<<<<<<<<<
> 
> PROGPATH=/scratch/ANTS/release-new/bin
> fi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainT1SliceBorder20.png
> mi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainProtonDensitySliceR10X13Y17.png
> 
> time ${PROGPATH}/antsRegistration -d 2 \
> --float \
> --output [test1, warpedMoving.nii.gz] \
> --transform "Translation[16]" \
> --metric MI[${fi},${mi},1,32,None,1] \
> --convergence [100,1e-2,5] \
> --shrink-factors 3 \
> --smoothing-sigmas 2 \
> --use-histogram-matching 1 \
> \
> --transform "Affine[1]" \
> --metric MI[${fi},${mi},1,32] \
> --convergence [100x100,1e-2,2] \
> --shrink-factors 2x1 \
> --smoothing-sigmas 1x0 \
> --use-histogram-matching 1
> 
> <<<<<<<<<<<<<<<<<<<<<<<<
> 
> Fixed and moving images can be loaded from the ITK data files. What do you think about this example? Is it a bug in ITK or just the parameters are not tuned finely?
> 
> Thanks,
> Ali
> 
> ________________________________________
> From: Johnson, Hans J
> Sent: Tuesday, July 29, 2014 6:19 PM
> To: Ghayoor, Ali
> Subject: FW: [ITK-dev] [ITK] Optimizing composite transforms and center of transform
> 
> Ali,
> 
> You need to follow this discussion.
> 
> Hans
> 
> On 7/29/14, 6:16 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
> 
>> Hello,
>> 
>> Ok, to further explore this problem, and hopeful help other people too: I
>> created an IPython Notebook viewable here:
>> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/bl
>> ob/master/Transform%20Composition%20And%20Order.ipynb
>> 
>> It doesn't come through on the static page, but I added some nifty
>> interactive slider widgets to change the rotation parameter. Which is
>> really the point  to enable understanding of the parameters for the
>> transform and how they should be best optimized. The notebook should work
>> with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one
>> to try it out :) IPython Notebooks widget are very cool!
>> 
>> EXPLANATION:
>> 
>> The the order of the composite transform is that the new transforms are
>> applied first.
>> 
>> BUT they map from the virtual domain ( fixed ) to the moving image.
>> Therefore if your first transform moves the center of mass to the origin
>> then the second added transform's space will be centered on the mass,
>> which is good for optimizing rotation and affine parameters.
>> 
>> QUESTION:
>> 
>> Therefore I am inclined to conclude that its best practices to map the
>> fixed and moving image to the virtual domain such that the center of mass
>> ( or some other "center feature" ) are at the origin. This would then the
>> scale, rotation and other affine parameters around the center, with out
>> having to used the "Center" parameter the transforms currently have.
>> 
>> Is this what others are doing in their registration? For general best
>> practices should this be recommend?
>> 
>> @Brian I know I have seen this multi-domain description many time, but I
>> think I may have just gotten it... Is the well describe in the literature
>> some place? I think this may be an important part add the software guide.
>> 
>> Thanks,
>> Brad
>> 
>> 
>> 
>> 
>> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com>
>> wrote:
>> 
>>> Hi Brad,
>>> 
>>> Your assessment that the fixed center is important is correct.
>>> 
>>> In most cases, a transform with a Center is the first transform in a
>>> Composite transform. There not any issues here.  However, if the
>>> transform with a Center is further along the chain, then a
>>> CenteredTransformInitializer that was applied before the registration
>>> is started will not generate the desired result. In this case, we
>>> would have to respond to an Event in the registration process and
>>> estimated the center on the imaged after the other transforms have
>>> been applied. It is more work, but it is a more unusual case.
>>> 
>>> HTH,
>>> Matt
>>> 
>>> 
>>> 
>>> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
>>> <blowekamp at mail.nih.gov> wrote:
>>>> Helloo Nick!
>>>> 
>>>> I am glad you got back to me.
>>>> 
>>>> I suspect that I have spent more time this past week looking at the
>>>> ITK affine transforms than anyone else[1] this week. With that here is
>>>> my current understanding...
>>>> 
>>>> 1) The CenterTransformInitializers estimates an initial "Center" and
>>>> an initial "Translation" parameter from either the geometry or the
>>>> first moments. From my problematic experiences, getting the initial
>>>> transform which is a "good" guess is been critical for the optimizer to
>>>> head to the correct solution.
>>>> 
>>>> 2) The Center parameter of a transform can either be "Fixed" or an
>>>> optimizable parameter. The transforms with the "Centered" monkier are
>>>> the the ones with the Center parameter optimizable. This issue seems to
>>>> be what you were referring to in to message.
>>>> 
>>>> In many ways the point I am trying to make is independent of #2. I
>>>> have observed that it's important to have the "Center" of an affine
>>>> transform ( or sub parameterization thereof ) at the center of the
>>>> object you are trying to register. That is the coordinate space of the
>>>> optimizable parameters' point 0 is near the center. This enables
>>>> rotation to easily rotate around the center, as well as scaling to
>>>> maintain the same relative center when "zooming". This issue is
>>>> independent of wether that center point can be optimized.
>>>> 
>>>> For example, consider changing the origin of an image for alignment by
>>>> say 500, and compensating with just an initial translation and not
>>>> setting the "Center" parameter. If we are trying to optimize rotation
>>>> and translation, then the optimization path would be very difficult to
>>>> traverse with these inter-dependent parameters to force it to rotate
>>>> around the center of the object. This scenario may be more common in
>>>> microscopy then medical imaging, due to microscopy frequently having
>>>> multiple subjects across large images. I could write up a IPython
>>>> Notebook to illustrate the case.
>>>> 
>>>> So that is my understanding of why using a fixed center is important.
>>>> I thought this may have been shared knowledge, but perhaps is not or is
>>>> incorrect...
>>>> 
>>>> Now I am trying to understand how this interacts with all the
>>>> coordinate frames involved with the ITKv4 registration framework, and
>>>> the composite transforms. Specifically the composite transform apply
>>>> the transforms in "reverse order"[2]. As I understand that that means
>>>> that the newest transform get applied first. So that transform
>>>> parameters are being optimized in the images space not in the virtual
>>>> domains we are working towards. Therefore the center of our transforms
>>>> is still important as we composite transforms?
>>>> 
>>>> I hope I explained that clearly, a white board may really be needed....
>>>> 
>>>> Thanks,
>>>> Brad
>>>> 
>>>> 
>>>> [1]
>>>> https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94
>>>> 099d3519eb23bcc16c7cf015
>>>> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>>>> 
>>>> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com>
>>>> wrote:
>>>> 
>>>>> Hi Brad,
>>>>> 
>>>>> I apologize for the delayed response.  I?m still catching up on my
>>>>> workload after moving to CA.  We might want to talk to Luis as it
>>>>> was my understanding that the ?center? component of the linear
>>>>> transforms might be a carry-over from all the ?Centered? transforms,
>>>>> e.g.,
>>>>> 
>>>>> 
>>>>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.htm
>>>>> l
>>>>> 
>>>>> which, if I remember correctly, Luis said were somewhat sub optimally
>>>>> conceived but this was such a long time ago that I might be completely
>>>>> misremembering.  However, fixing the center for all transforms within
>>>>> a composite transform is certainly not necessary within the specified
>>>>> framework.  Rather, the matrix and offset are updated with the
>>>>> ?Center?
>>>>> being updated implicitly.
>>>>> 
>>>>> Nick
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp
>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> There are a lot of transforms involved in the new registration
>>>>>> framework.
>>>>>> 
>>>>>> I am trying to figure out what the implications for the fix
>>>>>> parameters of the transform "Center" ( ie center of rotation/scaling
>>>>>> ) are when combined with composite transforms and the
>>>>>> fixed/moving/registration coordinate frames...
>>>>>> 
>>>>>> Based on how the transforms are composed it seems necessary to set
>>>>>> the  fix "Center" for subsequent transformations. Additionally, I am
>>>>>> unsure how one would "improve" ( poorly defined? ) the center for a
>>>>>> subsequent transform ie Affine after a similarity...
>>>>>> 
>>>>>> Are there some documented guidance or figures to help with this
>>>>>> issue?
>>>>>> Do we have a comprehensive diagram of these transforms?
>>>>>> 
>>>>>> Thanks,
>>>>>> Brad
>>>>>> 
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> 
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> http://kitware.com/products/protraining.php
>>>> 
>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>> _______________________________________________
>>>> Community mailing list
>>>> Community at itk.org
>>>> http://public.kitware.com/mailman/listinfo/community
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-developers
> 
> 
> 
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
> ________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140802/7e72278a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.png
Type: image/png
Size: 15787 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140802/7e72278a/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.png
Type: image/png
Size: 15016 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140802/7e72278a/attachment-0003.png>

From blowekamp at mail.nih.gov  Mon Aug  4 09:13:53 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 4 Aug 2014 09:13:53 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <6D8816B7-9BE5-494A-BAE8-81057667632E@gmail.com>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
 <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
 <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>
 <C588C78C-F0CA-40F9-A0CA-74D84B12983C@mail.nih.gov>
 <6D8816B7-9BE5-494A-BAE8-81057667632E@gmail.com>
Message-ID: <2BBBE077-9880-4FAC-9873-DC265CFD7C35@mail.nih.gov>

Nick,

Would 2pm EST on day this week for you for a google hang out?

Let's plan on review these points I've made along with the notebooks. I'd think the likely output is going to be some initial requirements for a new transform optimizer for composite transforms and the v4 framework.

Brad

On Aug 1, 2014, at 10:15 AM, Nick Tustison <ntustison at gmail.com> wrote:

> Sorry, Brad, but I'm currently in Salt Lake at a funeral.  I'd really like to understand better so, if you're available, I can do it anytime during the week on another call.
> 
> Sent from Howling Fantods
> 
>> On Aug 1, 2014, at 7:36 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>> 
>> Nick,
>> 
>> I hope you can make it to today's TCON. I can demo that notebook I linked too. It should clarify things.
>> 
>> Brad
>> 
>> On Jul 30, 2014, at 1:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>> 
>>>> To try to summaries... sorry if have not been clear enough in my explanations.
>>> 
>>> No, I blame me?I?m consistently distracted by the scenery outside here in
>>> California and it?s definitely affecting my ability to concentrate on code
>>> questions.
>>> 
>>>> INITIAL QUESTION
>>>> 
>>>> How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?
>>> 
>>> The composite transform is agnostic with respect to whether or not a 
>>> transform has a center or any other fixed parameter set.  The only
>>> distinction we make is typology with respect to linear/deformable. To 
>>> be clear, we?re not discussing any of the  ?Centered? transforms:
>>> 
>>> * CenteredAffineTransform
>>> * CenteredEuler3DTransform
>>> * CenteredEuler2DTransform
>>> * CenteredSimilarity2DTransform
>>> 
>>> None of those transforms are used in ANTs but I don?t think 
>>> their optimization would be an issue in the new ITKv4 registration 
>>> framework.
>>> 
>>> The virtual domain is simply defined in terms of standard image 
>>> geometry (origin, spacing, etc.) and is currently set in terms of the 
>>> fixed image geometry.  
>>> 
>>>> MY UNDERSTANDING
>>>> 
>>>> 1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )
>>> 
>>> I don?t see why it would only work correctly for a single transform.  Suppose
>>> I optimize a translation transform to get it?s optimal parameters for a given
>>> registration problem.  It?s not clear to me why it would be a problem to follow
>>> that with optimizing an Euler3D transform (which we do all the time in ANTs).  
>>> Obviously, we have to specify a staring point for the second transform (which
>>> is identity by default) and perhaps it would be better to have a different 
>>> starting point but I don?t see why starting with the default parameters is a 
>>> problem.
>>> 
>>> If the ?Center initialized transform? is one of the transforms listed above 
>>> then we don?t use those.  If it?s simply the result of using the 
>>> CenteredTransformInitializer, then we just pull the itk::TranslationTransform 
>>> part from the result and push that translation transform into the composite 
>>> transform queue.   I don?t see why it would be a problem to then optimize, 
>>> for example, the Euler3DTransform which just has 3 translation parameters 
>>> and 3 angle parameters to optimize where the center is implicitly defined 
>>> (unlike the CenteredEuler3DTransform which does have additional Center 
>>> parameters).  
>>> 
>>>> 2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.
>>> 
>>> Yes, that would probably be a better initialization but I don?t know why it would
>>> be a problem for the current framework to optimize with the origin elsewhere.
>>> Right now, each transform within the composite transform queue is 
>>> optimized starting from its identity parameters but perhaps the initializer
>>> idea that you propose would improve optimization. 
>>> 
>>>> I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.
>>>> PROPOSAL
>>>> 
>>>> Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 
>>>> 
>>>> Brad
>> 


From ntustison at gmail.com  Mon Aug  4 09:36:37 2014
From: ntustison at gmail.com (Nick Tustison)
Date: Mon, 4 Aug 2014 06:36:37 -0700
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <2BBBE077-9880-4FAC-9873-DC265CFD7C35@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
 <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
 <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>
 <C588C78C-F0CA-40F9-A0CA-74D84B12983C@mail.nih.gov>
 <6D8816B7-9BE5-494A-BAE8-81057667632E@gmail.com>
 <2BBBE077-9880-4FAC-9873-DC265CFD7C35@mail.nih.gov>
Message-ID: <51C874C8-7984-4C5C-B53B-F08D10B6BC6D@gmail.com>

Hi Brad,

Yes, 2 pm EST would work for me any day this week.

Nick

> On Aug 4, 2014, at 6:13 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
> Nick,
> 
> Would 2pm EST on day this week for you for a google hang out?
> 
> Let's plan on review these points I've made along with the notebooks. I'd think the likely output is going to be some initial requirements for a new transform optimizer for composite transforms and the v4 framework.
> 
> Brad
> 
>> On Aug 1, 2014, at 10:15 AM, Nick Tustison <ntustison at gmail.com> wrote:
>> 
>> Sorry, Brad, but I'm currently in Salt Lake at a funeral.  I'd really like to understand better so, if you're available, I can do it anytime during the week on another call.
>> 
>> Sent from Howling Fantods
>> 
>>> On Aug 1, 2014, at 7:36 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>> 
>>> Nick,
>>> 
>>> I hope you can make it to today's TCON. I can demo that notebook I linked too. It should clarify things.
>>> 
>>> Brad
>>> 
>>> On Jul 30, 2014, at 1:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>>> 
>>>>> To try to summaries... sorry if have not been clear enough in my explanations.
>>>> 
>>>> No, I blame me?I?m consistently distracted by the scenery outside here in
>>>> California and it?s definitely affecting my ability to concentrate on code
>>>> questions.
>>>> 
>>>>> INITIAL QUESTION
>>>>> 
>>>>> How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?
>>>> 
>>>> The composite transform is agnostic with respect to whether or not a 
>>>> transform has a center or any other fixed parameter set.  The only
>>>> distinction we make is typology with respect to linear/deformable. To 
>>>> be clear, we?re not discussing any of the  ?Centered? transforms:
>>>> 
>>>> * CenteredAffineTransform
>>>> * CenteredEuler3DTransform
>>>> * CenteredEuler2DTransform
>>>> * CenteredSimilarity2DTransform
>>>> 
>>>> None of those transforms are used in ANTs but I don?t think 
>>>> their optimization would be an issue in the new ITKv4 registration 
>>>> framework.
>>>> 
>>>> The virtual domain is simply defined in terms of standard image 
>>>> geometry (origin, spacing, etc.) and is currently set in terms of the 
>>>> fixed image geometry.  
>>>> 
>>>>> MY UNDERSTANDING
>>>>> 
>>>>> 1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )
>>>> 
>>>> I don?t see why it would only work correctly for a single transform.  Suppose
>>>> I optimize a translation transform to get it?s optimal parameters for a given
>>>> registration problem.  It?s not clear to me why it would be a problem to follow
>>>> that with optimizing an Euler3D transform (which we do all the time in ANTs).  
>>>> Obviously, we have to specify a staring point for the second transform (which
>>>> is identity by default) and perhaps it would be better to have a different 
>>>> starting point but I don?t see why starting with the default parameters is a 
>>>> problem.
>>>> 
>>>> If the ?Center initialized transform? is one of the transforms listed above 
>>>> then we don?t use those.  If it?s simply the result of using the 
>>>> CenteredTransformInitializer, then we just pull the itk::TranslationTransform 
>>>> part from the result and push that translation transform into the composite 
>>>> transform queue.   I don?t see why it would be a problem to then optimize, 
>>>> for example, the Euler3DTransform which just has 3 translation parameters 
>>>> and 3 angle parameters to optimize where the center is implicitly defined 
>>>> (unlike the CenteredEuler3DTransform which does have additional Center 
>>>> parameters).  
>>>> 
>>>>> 2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.
>>>> 
>>>> Yes, that would probably be a better initialization but I don?t know why it would
>>>> be a problem for the current framework to optimize with the origin elsewhere.
>>>> Right now, each transform within the composite transform queue is 
>>>> optimized starting from its identity parameters but perhaps the initializer
>>>> idea that you propose would improve optimization. 
>>>> 
>>>>> I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.
>>>>> PROPOSAL
>>>>> 
>>>>> Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 
>>>>> 
>>>>> Brad
> 

From blowekamp at mail.nih.gov  Mon Aug  4 10:50:54 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Mon, 4 Aug 2014 10:50:54 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <51C874C8-7984-4C5C-B53B-F08D10B6BC6D@gmail.com>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
 <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
 <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>
 <C588C78C-F0CA-40F9-A0CA-74D84B12983C@mail.nih.gov>
 <6D8816B7-9BE5-494A-BAE8-81057667632E@gmail.com>
 <2BBBE077-9880-4FAC-9873-DC265CFD7C35@mail.nih.gov>
 <51C874C8-7984-4C5C-B53B-F08D10B6BC6D@gmail.com>
Message-ID: <EBC32680-2A69-4297-B6FB-558B6BB47947@mail.nih.gov>

Hello,

I have created an Google Hangout event, it should be shared with the ITKBarCamp Google+ group if others are interested in attending.

Thanks,
Brad

On Aug 4, 2014, at 9:36 AM, Nick Tustison <ntustison at gmail.com> wrote:

> Hi Brad,
> 
> Yes, 2 pm EST would work for me any day this week.
> 
> Nick
> 
>> On Aug 4, 2014, at 6:13 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>> 
>> Nick,
>> 
>> Would 2pm EST on day this week for you for a google hang out?
>> 
>> Let's plan on review these points I've made along with the notebooks. I'd think the likely output is going to be some initial requirements for a new transform optimizer for composite transforms and the v4 framework.
>> 
>> Brad
>> 
>>> On Aug 1, 2014, at 10:15 AM, Nick Tustison <ntustison at gmail.com> wrote:
>>> 
>>> Sorry, Brad, but I'm currently in Salt Lake at a funeral.  I'd really like to understand better so, if you're available, I can do it anytime during the week on another call.
>>> 
>>> Sent from Howling Fantods
>>> 
>>>> On Aug 1, 2014, at 7:36 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>>> 
>>>> Nick,
>>>> 
>>>> I hope you can make it to today's TCON. I can demo that notebook I linked too. It should clarify things.
>>>> 
>>>> Brad
>>>> 
>>>> On Jul 30, 2014, at 1:57 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>>>> 
>>>>>> To try to summaries... sorry if have not been clear enough in my explanations.
>>>>> 
>>>>> No, I blame me?I?m consistently distracted by the scenery outside here in
>>>>> California and it?s definitely affecting my ability to concentrate on code
>>>>> questions.
>>>>> 
>>>>>> INITIAL QUESTION
>>>>>> 
>>>>>> How does composite transform and the "Center" parameter interact? How does this relate to the virtual domain?
>>>>> 
>>>>> The composite transform is agnostic with respect to whether or not a 
>>>>> transform has a center or any other fixed parameter set.  The only
>>>>> distinction we make is typology with respect to linear/deformable. To 
>>>>> be clear, we?re not discussing any of the  ?Centered? transforms:
>>>>> 
>>>>> * CenteredAffineTransform
>>>>> * CenteredEuler3DTransform
>>>>> * CenteredEuler2DTransform
>>>>> * CenteredSimilarity2DTransform
>>>>> 
>>>>> None of those transforms are used in ANTs but I don?t think 
>>>>> their optimization would be an issue in the new ITKv4 registration 
>>>>> framework.
>>>>> 
>>>>> The virtual domain is simply defined in terms of standard image 
>>>>> geometry (origin, spacing, etc.) and is currently set in terms of the 
>>>>> fixed image geometry.  
>>>>> 
>>>>>> MY UNDERSTANDING
>>>>>> 
>>>>>> 1) Using a "Center" initialized transform only works correctly for a single transform and directly with a composite. ( This is with the current center initializers, a different approach could be done which takes into consideration the composition )
>>>>> 
>>>>> I don?t see why it would only work correctly for a single transform.  Suppose
>>>>> I optimize a translation transform to get it?s optimal parameters for a given
>>>>> registration problem.  It?s not clear to me why it would be a problem to follow
>>>>> that with optimizing an Euler3D transform (which we do all the time in ANTs).  
>>>>> Obviously, we have to specify a staring point for the second transform (which
>>>>> is identity by default) and perhaps it would be better to have a different 
>>>>> starting point but I don?t see why starting with the default parameters is a 
>>>>> problem.
>>>>> 
>>>>> If the ?Center initialized transform? is one of the transforms listed above 
>>>>> then we don?t use those.  If it?s simply the result of using the 
>>>>> CenteredTransformInitializer, then we just pull the itk::TranslationTransform 
>>>>> part from the result and push that translation transform into the composite 
>>>>> transform queue.   I don?t see why it would be a problem to then optimize, 
>>>>> for example, the Euler3DTransform which just has 3 translation parameters 
>>>>> and 3 angle parameters to optimize where the center is implicitly defined 
>>>>> (unlike the CenteredEuler3DTransform which does have additional Center 
>>>>> parameters).  
>>>>> 
>>>>>> 2) The virtual domain should be initialized such that the two images "Center"s are at the origin. This an alternative to using the "Center" transform parameters, and better works with composite transforms.
>>>>> 
>>>>> Yes, that would probably be a better initialization but I don?t know why it would
>>>>> be a problem for the current framework to optimize with the origin elsewhere.
>>>>> Right now, each transform within the composite transform queue is 
>>>>> optimized starting from its identity parameters but perhaps the initializer
>>>>> idea that you propose would improve optimization. 
>>>>> 
>>>>>> I was not aware that 2 was the best practice with the ITKv4 framework. Do we have any examples/test/documentation to indicate this?  Further more using the current CenterTransformInitalizers to initialize the virtual domain is not readily apparent[1] how to map the parameters.
>>>>>> PROPOSAL
>>>>>> 
>>>>>> Perhaps we need a new Initializer filter to assist with initializing the virtual domain to initialize this practice? 
>>>>>> 
>>>>>> Brad
>> 


From stnava at gmail.com  Mon Aug  4 10:53:00 2014
From: stnava at gmail.com (brian avants)
Date: Mon, 4 Aug 2014 10:53:00 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <EBC32680-2A69-4297-B6FB-558B6BB47947@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <8C9CCC8B-5379-4A6A-902F-ACAE609F5789@gmail.com>
 <8727A959-8F80-471A-9E24-04C0E564D8DC@mail.nih.gov>
 <B64FB7E2-37AE-4D41-9777-064CC6E4CBE8@gmail.com>
 <C588C78C-F0CA-40F9-A0CA-74D84B12983C@mail.nih.gov>
 <6D8816B7-9BE5-494A-BAE8-81057667632E@gmail.com>
 <2BBBE077-9880-4FAC-9873-DC265CFD7C35@mail.nih.gov>
 <51C874C8-7984-4C5C-B53B-F08D10B6BC6D@gmail.com>
 <EBC32680-2A69-4297-B6FB-558B6BB47947@mail.nih.gov>
Message-ID: <CABWzF4UDniCHugfUxUS0WPG_vNNgky9s_sq3N+LEov_mPE83XQ@mail.gmail.com>

what day?
On Aug 4, 2014 10:50 AM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:

> Hello,
>
> I have created an Google Hangout event, it should be shared with the
> ITKBarCamp Google+ group if others are interested in attending.
>
> Thanks,
> Brad
>
> On Aug 4, 2014, at 9:36 AM, Nick Tustison <ntustison at gmail.com> wrote:
>
> > Hi Brad,
> >
> > Yes, 2 pm EST would work for me any day this week.
> >
> > Nick
> >
> >> On Aug 4, 2014, at 6:13 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
> wrote:
> >>
> >> Nick,
> >>
> >> Would 2pm EST on day this week for you for a google hang out?
> >>
> >> Let's plan on review these points I've made along with the notebooks.
> I'd think the likely output is going to be some initial requirements for a
> new transform optimizer for composite transforms and the v4 framework.
> >>
> >> Brad
> >>
> >>> On Aug 1, 2014, at 10:15 AM, Nick Tustison <ntustison at gmail.com>
> wrote:
> >>>
> >>> Sorry, Brad, but I'm currently in Salt Lake at a funeral.  I'd really
> like to understand better so, if you're available, I can do it anytime
> during the week on another call.
> >>>
> >>> Sent from Howling Fantods
> >>>
> >>>> On Aug 1, 2014, at 7:36 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
> wrote:
> >>>>
> >>>> Nick,
> >>>>
> >>>> I hope you can make it to today's TCON. I can demo that notebook I
> linked too. It should clarify things.
> >>>>
> >>>> Brad
> >>>>
> >>>> On Jul 30, 2014, at 1:57 PM, Nicholas Tustison <ntustison at gmail.com>
> wrote:
> >>>>
> >>>>>> To try to summaries... sorry if have not been clear enough in my
> explanations.
> >>>>>
> >>>>> No, I blame me?I?m consistently distracted by the scenery outside
> here in
> >>>>> California and it?s definitely affecting my ability to concentrate
> on code
> >>>>> questions.
> >>>>>
> >>>>>> INITIAL QUESTION
> >>>>>>
> >>>>>> How does composite transform and the "Center" parameter interact?
> How does this relate to the virtual domain?
> >>>>>
> >>>>> The composite transform is agnostic with respect to whether or not a
> >>>>> transform has a center or any other fixed parameter set.  The only
> >>>>> distinction we make is typology with respect to linear/deformable. To
> >>>>> be clear, we?re not discussing any of the  ?Centered? transforms:
> >>>>>
> >>>>> * CenteredAffineTransform
> >>>>> * CenteredEuler3DTransform
> >>>>> * CenteredEuler2DTransform
> >>>>> * CenteredSimilarity2DTransform
> >>>>>
> >>>>> None of those transforms are used in ANTs but I don?t think
> >>>>> their optimization would be an issue in the new ITKv4 registration
> >>>>> framework.
> >>>>>
> >>>>> The virtual domain is simply defined in terms of standard image
> >>>>> geometry (origin, spacing, etc.) and is currently set in terms of the
> >>>>> fixed image geometry.
> >>>>>
> >>>>>> MY UNDERSTANDING
> >>>>>>
> >>>>>> 1) Using a "Center" initialized transform only works correctly for
> a single transform and directly with a composite. ( This is with the
> current center initializers, a different approach could be done which takes
> into consideration the composition )
> >>>>>
> >>>>> I don?t see why it would only work correctly for a single transform.
>  Suppose
> >>>>> I optimize a translation transform to get it?s optimal parameters
> for a given
> >>>>> registration problem.  It?s not clear to me why it would be a
> problem to follow
> >>>>> that with optimizing an Euler3D transform (which we do all the time
> in ANTs).
> >>>>> Obviously, we have to specify a staring point for the second
> transform (which
> >>>>> is identity by default) and perhaps it would be better to have a
> different
> >>>>> starting point but I don?t see why starting with the default
> parameters is a
> >>>>> problem.
> >>>>>
> >>>>> If the ?Center initialized transform? is one of the transforms
> listed above
> >>>>> then we don?t use those.  If it?s simply the result of using the
> >>>>> CenteredTransformInitializer, then we just pull the
> itk::TranslationTransform
> >>>>> part from the result and push that translation transform into the
> composite
> >>>>> transform queue.   I don?t see why it would be a problem to then
> optimize,
> >>>>> for example, the Euler3DTransform which just has 3 translation
> parameters
> >>>>> and 3 angle parameters to optimize where the center is implicitly
> defined
> >>>>> (unlike the CenteredEuler3DTransform which does have additional
> Center
> >>>>> parameters).
> >>>>>
> >>>>>> 2) The virtual domain should be initialized such that the two
> images "Center"s are at the origin. This an alternative to using the
> "Center" transform parameters, and better works with composite transforms.
> >>>>>
> >>>>> Yes, that would probably be a better initialization but I don?t know
> why it would
> >>>>> be a problem for the current framework to optimize with the origin
> elsewhere.
> >>>>> Right now, each transform within the composite transform queue is
> >>>>> optimized starting from its identity parameters but perhaps the
> initializer
> >>>>> idea that you propose would improve optimization.
> >>>>>
> >>>>>> I was not aware that 2 was the best practice with the ITKv4
> framework. Do we have any examples/test/documentation to indicate this?
>  Further more using the current CenterTransformInitalizers to initialize
> the virtual domain is not readily apparent[1] how to map the parameters.
> >>>>>> PROPOSAL
> >>>>>>
> >>>>>> Perhaps we need a new Initializer filter to assist with
> initializing the virtual domain to initialize this practice?
> >>>>>>
> >>>>>> Brad
> >>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140804/6e0ec8b3/attachment.html>

From ali-ghayoor at uiowa.edu  Mon Aug  4 23:56:52 2014
From: ali-ghayoor at uiowa.edu (Ghayoor, Ali)
Date: Tue, 5 Aug 2014 03:56:52 +0000
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
 transform
In-Reply-To: <97C77D92-4BAD-4D90-912D-E2AB95D63E19@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <CFFD962C.871A8%hans-johnson@uiowa.edu>
 <EAA163371EE66741A63B092281D1F3FE1884ED74@itsnt444.iowa.uiowa.edu>
 <97C77D92-4BAD-4D90-912D-E2AB95D63E19@mail.nih.gov>
Message-ID: <D005AFFD.6377%ali-ghayoor@uiowa.edu>

Hello Brad,

It is an awesome way for demonstration, and thanks for verification of my example. It seems that this email is sent on Saturday, but unfortunately I got that this morning! And I should inspect the reason!
Anyway, over the weekend I ran almost the same experiment in ITK and got close results to you.

Also, today I tried to make the registration process work when Affine Transform is used in a multi stage structure, and here is my suggestion:

I think we do not need to bother ourselves to think about a new optimizer or a new initializer for the composite transform since we can initialize the fixed parameters of each transform individually at the beginning of each stage.

Remember how we run a BSpline registration stage after some linear registrations. At the beginning of the BSpline stage, we should instantiate a BSpline transform object and define its fixed parameters (grid size, etc). Then, we pass this initialized transform to the registration filter using ?SetInitialTransform()?, yet we can initialize this stage by passing a composite transform, resultant from the previous stages, to the registration filter by ?SetMovingInitialTransform()?.

The same condition holds for all other transform types with fixed unoptimizable parameters like the center of rotation in our Affine transform case. Attachment file includes a multi stage registration example that I have created for the new software guide. In this example, we use a simple 2 stages registration process for a multi modal problem that moving image is misaligned from the fixed image by a translation shift and rotation. In registration process, a translation transform is followed by an affine transform. Also, an initial transform is used at the beginning.

If I do not set the center of the affine transform, the registration fails as you have shown in your Ipython example. However, if at the beginning of the second stage, I compute the geometrical center (or center of the mass) of the fixed image, and pass that to the affine transform using ?SetCenter()? or ?SetFixedParameters()?, the registration succeeds. Please take a quick look in the attached file that also includes lots of explanations.

Therefore, we can follow the same procedure for all other transform types that their fixed parameters are important in the optimization, but those fixed parameters cannot be set explicitly inside a composite transform. Please let me know with you think about this.

Thank you,
Ali


From: Bradley Lowekamp <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>>
Date: Saturday, August 2, 2014 at 6:48 PM
To: Ali Ghayoor <ali-ghayoor at uiowa.edu<mailto:ali-ghayoor at uiowa.edu>>
Cc: Hans Johnson <hans-johnson at uiowa.edu<mailto:hans-johnson at uiowa.edu>>, Insight Developers List <insight-developers at public.kitware.com<mailto:insight-developers at public.kitware.com>>
Subject: Re: [ITK-dev] [ITK] Optimizing composite transforms and center of transform

Hello Ali,

I created a notebook to try to demonstrate the problem you are describing:
http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Importance%20of%20Center%20with%20Affine%20Registration.ipynb

If the center of an Affine transformation isn't correctly initialized then the optimization is not speedy or robust. I think it's best illustrated with these two graphs:

[unknown.png]
[unknown.png]

Notice that with the Center being the origin, all 1000 iterations are exhausted, and the metric is slowing decreasing. And this is with the translation path being around the length to 10. If the spacing was bigger or more offset from the origin the situation would be worse.

I don't think this is a bug with the registration framework. I think new initializers for composite transforms are needed, along with documentation how the 2 good ways to initialize the registration methods transforms.


Brad

On Aug 1, 2014, at 8:08 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu<mailto:ali-ghayoor at uiowa.edu>> wrote:

Brad,

I have exactly the same issue. I wrote a simple registration program that is run in two stages:
-Translation
-Affine

My fixed and moving images are in 2D, and the moving image is created from the fixed image by
rotation of 10 degree and translation of [13,17] in X and Y directions.

The first stage does a translation registration and the result transform is added to a composite transform
that is used as the initial moving transform of the second stage.

After the registration the result transform of the second stage is also added to the composite transform
to be used by the resampler.

I have printed the composite transform to the screen:

2481: CompositeTransform (0x7fa359a18b00)
2481:   RTTI typeinfo:   itk::CompositeTransform<double, 2u>
2481:   Reference Count: 2
2481:   Modified Time: 20949
2481:   Debug: Off
2481:   Object Name:
2481:   Observers:
2481:     none
2481:   Transforms in queue, from begin to end:
2481:   >>>>>>>>>
2481:   TranslationTransform (0x7fa359a199b0)
2481:     RTTI typeinfo:   itk::TranslationTransform<double, 2u>
2481:     Reference Count: 7
2481:     Modified Time: 1648
2481:     Debug: Off
2481:     Object Name:
2481:     Observers:
2481:       none
2481:     Offset: [12.801, 15.8578]
2481:   >>>>>>>>>
2481:   AffineTransform (0x7fa359d095a0)
2481:     RTTI typeinfo:   itk::AffineTransform<double, 2u>
2481:     Reference Count: 5
2481:     Modified Time: 20946
2481:     Debug: Off
2481:     Object Name:
2481:     Observers:
2481:       none
2481:     Matrix:
2481:       1.01593 -0.0100051
2481:       -0.00835669 1.01113
2481:     Offset: [-0.358829, -0.290093]
2481:     Center: [0, 0]
2481:     Translation: [-0.358829, -0.290093]
2481:     Inverse:
2481:       0.984397 0.00974056
2481:       0.00813575 0.989073
2481:     Singular: 0
2481:   End of MultiTransform.
2481: <<<<<<<<<<

As it can be seen, the translation transform provides a good initialization since its offset (Offset: [12.801, 15.8578]) is close to the shift parameters.

However, the Affine transform fails to rotate the moving image since its Matrix is almost identity.
Possible reason can be the improper Center of Affine transform that is fixed to [0,0], and not at geometrical center or center of mass.

To make sure that I have not made any crazy mistake in my example, I simulated my example parameters in ANTs, and ANTs returned
the same results and failed to register the images!!

ANTs command line <<<<<<<<<<<

PROGPATH=/scratch/ANTS/release-new/bin
fi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainT1SliceBorder20.png
mi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainProtonDensitySliceR10X13Y17.png

time ${PROGPATH}/antsRegistration -d 2 \
--float \
--output [test1, warpedMoving.nii.gz] \
--transform "Translation[16]" \
--metric MI[${fi},${mi},1,32,None,1] \
--convergence [100,1e-2,5] \
--shrink-factors 3 \
--smoothing-sigmas 2 \
--use-histogram-matching 1 \
\
--transform "Affine[1]" \
--metric MI[${fi},${mi},1,32] \
--convergence [100x100,1e-2,2] \
--shrink-factors 2x1 \
--smoothing-sigmas 1x0 \
--use-histogram-matching 1

<<<<<<<<<<<<<<<<<<<<<<<<

Fixed and moving images can be loaded from the ITK data files. What do you think about this example? Is it a bug in ITK or just the parameters are not tuned finely?

Thanks,
Ali

________________________________________
From: Johnson, Hans J
Sent: Tuesday, July 29, 2014 6:19 PM
To: Ghayoor, Ali
Subject: FW: [ITK-dev] [ITK] Optimizing composite transforms and center of transform

Ali,

You need to follow this discussion.

Hans

On 7/29/14, 6:16 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:

Hello,

Ok, to further explore this problem, and hopeful help other people too: I
created an IPython Notebook viewable here:
http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/bl
ob/master/Transform%20Composition%20And%20Order.ipynb

It doesn't come through on the static page, but I added some nifty
interactive slider widgets to change the rotation parameter. Which is
really the point  to enable understanding of the parameters for the
transform and how they should be best optimized. The notebook should work
with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one
to try it out :) IPython Notebooks widget are very cool!

EXPLANATION:

The the order of the composite transform is that the new transforms are
applied first.

BUT they map from the virtual domain ( fixed ) to the moving image.
Therefore if your first transform moves the center of mass to the origin
then the second added transform's space will be centered on the mass,
which is good for optimizing rotation and affine parameters.

QUESTION:

Therefore I am inclined to conclude that its best practices to map the
fixed and moving image to the virtual domain such that the center of mass
( or some other "center feature" ) are at the origin. This would then the
scale, rotation and other affine parameters around the center, with out
having to used the "Center" parameter the transforms currently have.

Is this what others are doing in their registration? For general best
practices should this be recommend?

@Brian I know I have seen this multi-domain description many time, but I
think I may have just gotten it... Is the well describe in the literature
some place? I think this may be an important part add the software guide.

Thanks,
Brad




On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com<mailto:matt.mccormick at kitware.com>>
wrote:

Hi Brad,

Your assessment that the fixed center is important is correct.

In most cases, a transform with a Center is the first transform in a
Composite transform. There not any issues here.  However, if the
transform with a Center is further along the chain, then a
CenteredTransformInitializer that was applied before the registration
is started will not generate the desired result. In this case, we
would have to respond to an Event in the registration process and
estimated the center on the imaged after the other transforms have
been applied. It is more work, but it is a more unusual case.

HTH,
Matt



On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:
Helloo Nick!

I am glad you got back to me.

I suspect that I have spent more time this past week looking at the
ITK affine transforms than anyone else[1] this week. With that here is
my current understanding...

1) The CenterTransformInitializers estimates an initial "Center" and
an initial "Translation" parameter from either the geometry or the
first moments. From my problematic experiences, getting the initial
transform which is a "good" guess is been critical for the optimizer to
head to the correct solution.

2) The Center parameter of a transform can either be "Fixed" or an
optimizable parameter. The transforms with the "Centered" monkier are
the the ones with the Center parameter optimizable. This issue seems to
be what you were referring to in to message.

In many ways the point I am trying to make is independent of #2. I
have observed that it's important to have the "Center" of an affine
transform ( or sub parameterization thereof ) at the center of the
object you are trying to register. That is the coordinate space of the
optimizable parameters' point 0 is near the center. This enables
rotation to easily rotate around the center, as well as scaling to
maintain the same relative center when "zooming". This issue is
independent of wether that center point can be optimized.

For example, consider changing the origin of an image for alignment by
say 500, and compensating with just an initial translation and not
setting the "Center" parameter. If we are trying to optimize rotation
and translation, then the optimization path would be very difficult to
traverse with these inter-dependent parameters to force it to rotate
around the center of the object. This scenario may be more common in
microscopy then medical imaging, due to microscopy frequently having
multiple subjects across large images. I could write up a IPython
Notebook to illustrate the case.

So that is my understanding of why using a fixed center is important.
I thought this may have been shared knowledge, but perhaps is not or is
incorrect...

Now I am trying to understand how this interacts with all the
coordinate frames involved with the ITKv4 registration framework, and
the composite transforms. Specifically the composite transform apply
the transforms in "reverse order"[2]. As I understand that that means
that the newest transform get applied first. So that transform
parameters are being optimized in the images space not in the virtual
domains we are working towards. Therefore the center of our transforms
is still important as we composite transforms?

I hope I explained that clearly, a white board may really be needed....

Thanks,
Brad


[1]
https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94
099d3519eb23bcc16c7cf015
[2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html

On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com<mailto:ntustison at gmail.com>>
wrote:

Hi Brad,

I apologize for the delayed response.  I?m still catching up on my
workload after moving to CA.  We might want to talk to Luis as it
was my understanding that the ?center? component of the linear
transforms might be a carry-over from all the ?Centered? transforms,
e.g.,


http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.htm
l

which, if I remember correctly, Luis said were somewhat sub optimally
conceived but this was such a long time ago that I might be completely
misremembering.  However, fixing the center for all transforms within
a composite transform is certainly not necessary within the specified
framework.  Rather, the matrix and offset are updated with the
?Center?
being updated implicitly.

Nick



On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov<mailto:blowekamp at mail.nih.gov>> wrote:

Hello,

There are a lot of transforms involved in the new registration
framework.

I am trying to figure out what the implications for the fix
parameters of the transform "Center" ( ie center of rotation/scaling
) are when combined with composite transforms and the
fixed/moving/registration coordinate frames...

Based on how the transforms are composed it seems necessary to set
the  fix "Center" for subsequent transformations. Additionally, I am
unsure how one would "improve" ( poorly defined? ) the center for a
subsequent transform ie Affine after a similarity...

Are there some documented guidance or figures to help with this
issue?
Do we have a comprehensive diagram of these transforms?

Thanks,
Brad



_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

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://public.kitware.com/mailman/listinfo/insight-developers
_______________________________________________
Community mailing list
Community at itk.org<mailto:Community at itk.org>
http://public.kitware.com/mailman/listinfo/community

_______________________________________________
Powered by www.kitware.com

Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html

Kitware offers ITK Training Courses, for more information visit:
http://kitware.com/products/protraining.php

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://public.kitware.com/mailman/listinfo/insight-developers



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140805/cb1de653/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.png
Type: image/png
Size: 15787 bytes
Desc: unknown.png
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140805/cb1de653/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unknown.png
Type: image/png
Size: 15016 bytes
Desc: unknown.png
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140805/cb1de653/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MultiStageImageRegistration1.cxx
Type: application/octet-stream
Size: 35511 bytes
Desc: MultiStageImageRegistration1.cxx
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140805/cb1de653/attachment-0001.obj>

From blowekamp at mail.nih.gov  Tue Aug  5 09:03:11 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Tue, 5 Aug 2014 09:03:11 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <D005AFFD.6377%ali-ghayoor@uiowa.edu>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <CFFD962C.871A8%hans-johnson@uiowa.edu>
 <EAA163371EE66741A63B092281D1F3FE1884ED74@itsnt444.iowa.uiowa.edu>
 <97C77D92-4BAD-4D90-912D-E2AB95D63E19@mail.nih.gov>
 <D005AFFD.6377%ali-ghayoor@uiowa.edu>
Message-ID: <85D2068C-A0FC-46EE-8CF8-3F44CDB40E5D@mail.nih.gov>

Ali,

Glad to hear the registration iteration graphs where effective.

Yes, you are right you can initialize the parameters of the second stage affine registration. Specifically the Center. However, it not readily apparent ( no example, no filter/initializer ) how that center fixed parameter should be initialized. And the "CenteredTransformInitializer" is not the correct way.

For a Composite transformed defined as ?=T0(T1(x)) where ?:?fixed??moving then if C such that C??moving is the correct center initialization for T1, then the correct center initialization for T0 when in the composite transform is C?=T?10(C).

Cool pasting from the IPython Notebook with inline latex appears to have worked :)

While it is easy to do this with the MomentsCaluclator and manually doing the transform inverse, I think to make it more readily apparent and easier to use it should be available as a filter/initializer.

There are several things  that are done manually in the examples that I would think should be updated to use the latest filters and initializers. For example The BSplines are manually initialized instead of using the BSplineTransform Initializer[1]. Additionally,  conversion of BSpline to a deformation field[2], and the the upsampling of the BSpine[3], though that last one still looks like ITKv3 framework, so maybe it'll be updated to the adaptors with v4. However I am after simple functions for these common tasks for SimpleITK, so I have a bit different perspective then one who is OK with implementing a 50 line solution in C++ and being OK with the interface.

We'll discuss these initialization issue further this afternoon.

Brad

[1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L215-L235
[2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L401-L430
[3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration6.cxx#L273-L330

On Aug 4, 2014, at 11:56 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:

> Hello Brad,
> 
> It is an awesome way for demonstration, and thanks for verification of my example. It seems that this email is sent on Saturday, but unfortunately I got that this morning! And I should inspect the reason! 
> Anyway, over the weekend I ran almost the same experiment in ITK and got close results to you.
> 
> Also, today I tried to make the registration process work when Affine Transform is used in a multi stage structure, and here is my suggestion:
> 
> I think we do not need to bother ourselves to think about a new optimizer or a new initializer for the composite transform since we can initialize the fixed parameters of each transform individually at the beginning of each stage.
> 
> Remember how we run a BSpline registration stage after some linear registrations. At the beginning of the BSpline stage, we should instantiate a BSpline transform object and define its fixed parameters (grid size, etc). Then, we pass this initialized transform to the registration filter using ?SetInitialTransform()?, yet we can initialize this stage by passing a composite transform, resultant from the previous stages, to the registration filter by ?SetMovingInitialTransform()?.
> 
> The same condition holds for all other transform types with fixed unoptimizable parameters like the center of rotation in our Affine transform case. Attachment file includes a multi stage registration example that I have created for the new software guide. In this example, we use a simple 2 stages registration process for a multi modal problem that moving image is misaligned from the fixed image by a translation shift and rotation. In registration process, a translation transform is followed by an affine transform. Also, an initial transform is used at the beginning.
> 
> If I do not set the center of the affine transform, the registration fails as you have shown in your Ipython example. However, if at the beginning of the second stage, I compute the geometrical center (or center of the mass) of the fixed image, and pass that to the affine transform using ?SetCenter()? or ?SetFixedParameters()?, the registration succeeds. Please take a quick look in the attached file that also includes lots of explanations. 
> 
> Therefore, we can follow the same procedure for all other transform types that their fixed parameters are important in the optimization, but those fixed parameters cannot be set explicitly inside a composite transform. Please let me know with you think about this.
> 
> Thank you,
> Ali
> 
> 
> From: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date: Saturday, August 2, 2014 at 6:48 PM
> To: Ali Ghayoor <ali-ghayoor at uiowa.edu>
> Cc: Hans Johnson <hans-johnson at uiowa.edu>, Insight Developers List <insight-developers at public.kitware.com>
> Subject: Re: [ITK-dev] [ITK] Optimizing composite transforms and center of transform
> 
> Hello Ali,
> 
> I created a notebook to try to demonstrate the problem you are describing:
> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Importance%20of%20Center%20with%20Affine%20Registration.ipynb
> 
> If the center of an Affine transformation isn't correctly initialized then the optimization is not speedy or robust. I think it's best illustrated with these two graphs:
> 
> <unknown.png>
> <unknown.png>
> 
> Notice that with the Center being the origin, all 1000 iterations are exhausted, and the metric is slowing decreasing. And this is with the translation path being around the length to 10. If the spacing was bigger or more offset from the origin the situation would be worse.
> 
> I don't think this is a bug with the registration framework. I think new initializers for composite transforms are needed, along with documentation how the 2 good ways to initialize the registration methods transforms.
> 
> 
> Brad
> 
> On Aug 1, 2014, at 8:08 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:
> 
>> Brad,
>> 
>> I have exactly the same issue. I wrote a simple registration program that is run in two stages:
>> -Translation
>> -Affine
>> 
>> My fixed and moving images are in 2D, and the moving image is created from the fixed image by
>> rotation of 10 degree and translation of [13,17] in X and Y directions.
>> 
>> The first stage does a translation registration and the result transform is added to a composite transform
>> that is used as the initial moving transform of the second stage.
>> 
>> After the registration the result transform of the second stage is also added to the composite transform
>> to be used by the resampler.
>> 
>> I have printed the composite transform to the screen:
>> 
>> 2481: CompositeTransform (0x7fa359a18b00)
>> 2481:   RTTI typeinfo:   itk::CompositeTransform<double, 2u>
>> 2481:   Reference Count: 2
>> 2481:   Modified Time: 20949
>> 2481:   Debug: Off
>> 2481:   Object Name: 
>> 2481:   Observers: 
>> 2481:     none
>> 2481:   Transforms in queue, from begin to end:
>> 2481:   >>>>>>>>>
>> 2481:   TranslationTransform (0x7fa359a199b0)
>> 2481:     RTTI typeinfo:   itk::TranslationTransform<double, 2u>
>> 2481:     Reference Count: 7
>> 2481:     Modified Time: 1648
>> 2481:     Debug: Off
>> 2481:     Object Name: 
>> 2481:     Observers: 
>> 2481:       none
>> 2481:     Offset: [12.801, 15.8578]
>> 2481:   >>>>>>>>>
>> 2481:   AffineTransform (0x7fa359d095a0)
>> 2481:     RTTI typeinfo:   itk::AffineTransform<double, 2u>
>> 2481:     Reference Count: 5
>> 2481:     Modified Time: 20946
>> 2481:     Debug: Off
>> 2481:     Object Name: 
>> 2481:     Observers: 
>> 2481:       none
>> 2481:     Matrix: 
>> 2481:       1.01593 -0.0100051 
>> 2481:       -0.00835669 1.01113 
>> 2481:     Offset: [-0.358829, -0.290093]
>> 2481:     Center: [0, 0]
>> 2481:     Translation: [-0.358829, -0.290093]
>> 2481:     Inverse: 
>> 2481:       0.984397 0.00974056 
>> 2481:       0.00813575 0.989073 
>> 2481:     Singular: 0
>> 2481:   End of MultiTransform.
>> 2481: <<<<<<<<<<
>> 
>> As it can be seen, the translation transform provides a good initialization since its offset (Offset: [12.801, 15.8578]) is close to the shift parameters.
>> 
>> However, the Affine transform fails to rotate the moving image since its Matrix is almost identity.
>> Possible reason can be the improper Center of Affine transform that is fixed to [0,0], and not at geometrical center or center of mass.
>> 
>> To make sure that I have not made any crazy mistake in my example, I simulated my example parameters in ANTs, and ANTs returned
>> the same results and failed to register the images!!
>> 
>>>>>>> ANTs command line <<<<<<<<<<<
>> 
>> PROGPATH=/scratch/ANTS/release-new/bin
>> fi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainT1SliceBorder20.png
>> mi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainProtonDensitySliceR10X13Y17.png
>> 
>> time ${PROGPATH}/antsRegistration -d 2 \
>> --float \
>> --output [test1, warpedMoving.nii.gz] \
>> --transform "Translation[16]" \
>> --metric MI[${fi},${mi},1,32,None,1] \
>> --convergence [100,1e-2,5] \
>> --shrink-factors 3 \
>> --smoothing-sigmas 2 \
>> --use-histogram-matching 1 \
>> \
>> --transform "Affine[1]" \
>> --metric MI[${fi},${mi},1,32] \
>> --convergence [100x100,1e-2,2] \
>> --shrink-factors 2x1 \
>> --smoothing-sigmas 1x0 \
>> --use-histogram-matching 1
>> 
>> <<<<<<<<<<<<<<<<<<<<<<<<
>> 
>> Fixed and moving images can be loaded from the ITK data files. What do you think about this example? Is it a bug in ITK or just the parameters are not tuned finely?
>> 
>> Thanks,
>> Ali
>> 
>> ________________________________________
>> From: Johnson, Hans J
>> Sent: Tuesday, July 29, 2014 6:19 PM
>> To: Ghayoor, Ali
>> Subject: FW: [ITK-dev] [ITK] Optimizing composite transforms and center of transform
>> 
>> Ali,
>> 
>> You need to follow this discussion.
>> 
>> Hans
>> 
>> On 7/29/14, 6:16 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
>> 
>>> Hello,
>>> 
>>> Ok, to further explore this problem, and hopeful help other people too: I
>>> created an IPython Notebook viewable here:
>>> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/bl
>>> ob/master/Transform%20Composition%20And%20Order.ipynb
>>> 
>>> It doesn't come through on the static page, but I added some nifty
>>> interactive slider widgets to change the rotation parameter. Which is
>>> really the point  to enable understanding of the parameters for the
>>> transform and how they should be best optimized. The notebook should work
>>> with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one
>>> to try it out :) IPython Notebooks widget are very cool!
>>> 
>>> EXPLANATION:
>>> 
>>> The the order of the composite transform is that the new transforms are
>>> applied first.
>>> 
>>> BUT they map from the virtual domain ( fixed ) to the moving image.
>>> Therefore if your first transform moves the center of mass to the origin
>>> then the second added transform's space will be centered on the mass,
>>> which is good for optimizing rotation and affine parameters.
>>> 
>>> QUESTION:
>>> 
>>> Therefore I am inclined to conclude that its best practices to map the
>>> fixed and moving image to the virtual domain such that the center of mass
>>> ( or some other "center feature" ) are at the origin. This would then the
>>> scale, rotation and other affine parameters around the center, with out
>>> having to used the "Center" parameter the transforms currently have.
>>> 
>>> Is this what others are doing in their registration? For general best
>>> practices should this be recommend?
>>> 
>>> @Brian I know I have seen this multi-domain description many time, but I
>>> think I may have just gotten it... Is the well describe in the literature
>>> some place? I think this may be an important part add the software guide.
>>> 
>>> Thanks,
>>> Brad
>>> 
>>> 
>>> 
>>> 
>>> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com>
>>> wrote:
>>> 
>>>> Hi Brad,
>>>> 
>>>> Your assessment that the fixed center is important is correct.
>>>> 
>>>> In most cases, a transform with a Center is the first transform in a
>>>> Composite transform. There not any issues here.  However, if the
>>>> transform with a Center is further along the chain, then a
>>>> CenteredTransformInitializer that was applied before the registration
>>>> is started will not generate the desired result. In this case, we
>>>> would have to respond to an Event in the registration process and
>>>> estimated the center on the imaged after the other transforms have
>>>> been applied. It is more work, but it is a more unusual case.
>>>> 
>>>> HTH,
>>>> Matt
>>>> 
>>>> 
>>>> 
>>>> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
>>>> <blowekamp at mail.nih.gov> wrote:
>>>>> Helloo Nick!
>>>>> 
>>>>> I am glad you got back to me.
>>>>> 
>>>>> I suspect that I have spent more time this past week looking at the
>>>>> ITK affine transforms than anyone else[1] this week. With that here is
>>>>> my current understanding...
>>>>> 
>>>>> 1) The CenterTransformInitializers estimates an initial "Center" and
>>>>> an initial "Translation" parameter from either the geometry or the
>>>>> first moments. From my problematic experiences, getting the initial
>>>>> transform which is a "good" guess is been critical for the optimizer to
>>>>> head to the correct solution.
>>>>> 
>>>>> 2) The Center parameter of a transform can either be "Fixed" or an
>>>>> optimizable parameter. The transforms with the "Centered" monkier are
>>>>> the the ones with the Center parameter optimizable. This issue seems to
>>>>> be what you were referring to in to message.
>>>>> 
>>>>> In many ways the point I am trying to make is independent of #2. I
>>>>> have observed that it's important to have the "Center" of an affine
>>>>> transform ( or sub parameterization thereof ) at the center of the
>>>>> object you are trying to register. That is the coordinate space of the
>>>>> optimizable parameters' point 0 is near the center. This enables
>>>>> rotation to easily rotate around the center, as well as scaling to
>>>>> maintain the same relative center when "zooming". This issue is
>>>>> independent of wether that center point can be optimized.
>>>>> 
>>>>> For example, consider changing the origin of an image for alignment by
>>>>> say 500, and compensating with just an initial translation and not
>>>>> setting the "Center" parameter. If we are trying to optimize rotation
>>>>> and translation, then the optimization path would be very difficult to
>>>>> traverse with these inter-dependent parameters to force it to rotate
>>>>> around the center of the object. This scenario may be more common in
>>>>> microscopy then medical imaging, due to microscopy frequently having
>>>>> multiple subjects across large images. I could write up a IPython
>>>>> Notebook to illustrate the case.
>>>>> 
>>>>> So that is my understanding of why using a fixed center is important.
>>>>> I thought this may have been shared knowledge, but perhaps is not or is
>>>>> incorrect...
>>>>> 
>>>>> Now I am trying to understand how this interacts with all the
>>>>> coordinate frames involved with the ITKv4 registration framework, and
>>>>> the composite transforms. Specifically the composite transform apply
>>>>> the transforms in "reverse order"[2]. As I understand that that means
>>>>> that the newest transform get applied first. So that transform
>>>>> parameters are being optimized in the images space not in the virtual
>>>>> domains we are working towards. Therefore the center of our transforms
>>>>> is still important as we composite transforms?
>>>>> 
>>>>> I hope I explained that clearly, a white board may really be needed....
>>>>> 
>>>>> Thanks,
>>>>> Brad
>>>>> 
>>>>> 
>>>>> [1]
>>>>> https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94
>>>>> 099d3519eb23bcc16c7cf015
>>>>> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>>>>> 
>>>>> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi Brad,
>>>>>> 
>>>>>> I apologize for the delayed response.  I?m still catching up on my
>>>>>> workload after moving to CA.  We might want to talk to Luis as it
>>>>>> was my understanding that the ?center? component of the linear
>>>>>> transforms might be a carry-over from all the ?Centered? transforms,
>>>>>> e.g.,
>>>>>> 
>>>>>> 
>>>>>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.htm
>>>>>> l
>>>>>> 
>>>>>> which, if I remember correctly, Luis said were somewhat sub optimally
>>>>>> conceived but this was such a long time ago that I might be completely
>>>>>> misremembering.  However, fixing the center for all transforms within
>>>>>> a composite transform is certainly not necessary within the specified
>>>>>> framework.  Rather, the matrix and offset are updated with the
>>>>>> ?Center?
>>>>>> being updated implicitly.
>>>>>> 
>>>>>> Nick
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp
>>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> There are a lot of transforms involved in the new registration
>>>>>>> framework.
>>>>>>> 
>>>>>>> I am trying to figure out what the implications for the fix
>>>>>>> parameters of the transform "Center" ( ie center of rotation/scaling
>>>>>>> ) are when combined with composite transforms and the
>>>>>>> fixed/moving/registration coordinate frames...
>>>>>>> 
>>>>>>> Based on how the transforms are composed it seems necessary to set
>>>>>>> the  fix "Center" for subsequent transformations. Additionally, I am
>>>>>>> unsure how one would "improve" ( poorly defined? ) the center for a
>>>>>>> subsequent transform ie Affine after a similarity...
>>>>>>> 
>>>>>>> Are there some documented guidance or figures to help with this
>>>>>>> issue?
>>>>>>> Do we have a comprehensive diagram of these transforms?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Brad
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>> 
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>> 
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://kitware.com/products/protraining.php
>>>>> 
>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>> _______________________________________________
>>>>> Community mailing list
>>>>> Community at itk.org
>>>>> http://public.kitware.com/mailman/listinfo/community
>>> 
>>> _______________________________________________
>>> Powered by www.kitware.com
>>> 
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>> 
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.php
>>> 
>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>> 
>> 
>> 
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>> ________________________________
> 
> <unknown.png><unknown.png><MultiStageImageRegistration1.cxx>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140805/95e2526f/attachment.html>

From skalexander at gmail.com  Tue Aug  5 09:34:40 2014
From: skalexander at gmail.com (Simon Alexander)
Date: Tue, 5 Aug 2014 09:34:40 -0400
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <85D2068C-A0FC-46EE-8CF8-3F44CDB40E5D@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <CFFD962C.871A8%hans-johnson@uiowa.edu>
 <EAA163371EE66741A63B092281D1F3FE1884ED74@itsnt444.iowa.uiowa.edu>
 <97C77D92-4BAD-4D90-912D-E2AB95D63E19@mail.nih.gov>
 <D005AFFD.6377%ali-ghayoor@uiowa.edu>
 <85D2068C-A0FC-46EE-8CF8-3F44CDB40E5D@mail.nih.gov>
Message-ID: <CAJFNcCSpzwSrsH+Mavke+kO8ehtGwcTwF561cMtLOr9Wx-qj0w@mail.gmail.com>

Hi all,

I have recently been playing around with this issue also.  Has your hangout
happened already?  Is there a summary of conclusions planned or existing?

Thanks!


On Tue, Aug 5, 2014 at 9:03 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Ali,
>
> Glad to hear the registration iteration graphs where effective.
>
> Yes, you are right you can initialize the parameters of the second stage
> affine registration. Specifically the Center. However, it not readily
> apparent ( no example, no filter/initializer ) how that center fixed
> parameter should be initialized. And the "CenteredTransformInitializer" is
> not the correct way.
>
> For a Composite transformed defined as ?=T0(T1(x)) where ?:?fixed??moving then
> if C such that C??moving is the correct center initialization for T1,
> then the correct center initialization for T0 when in the composite
> transform is C?=T?10(C).
>
> Cool pasting from the IPython Notebook with inline latex appears to have
> worked :)
>
> While it is easy to do this with the MomentsCaluclator and manually doing
> the transform inverse, I think to make it more readily apparent and easier
> to use it should be available as a filter/initializer.
>
> There are several things  that are done manually in the examples that I
> would think should be updated to use the latest filters and initializers.
> For example The BSplines are manually initialized instead of using the
> BSplineTransform Initializer[1]. Additionally,  conversion of BSpline to a
> deformation field[2], and the the upsampling of the BSpine[3], though that
> last one still looks like ITKv3 framework, so maybe it'll be updated to the
> adaptors with v4. However I am after simple functions for these common
> tasks for SimpleITK, so I have a bit different perspective then one who is
> OK with implementing a 50 line solution in C++ and being OK with the
> interface.
>
> We'll discuss these initialization issue further this afternoon.
>
> Brad
>
> [1]
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L215-L235
> [2]
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L401-L430
> [3]
> https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration6.cxx#L273-L330
>
> On Aug 4, 2014, at 11:56 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:
>
>  Hello Brad,
>
>  It is an awesome way for demonstration, and thanks for verification of
> my example. It seems that this email is sent on Saturday, but unfortunately
> I got that this morning! And I should inspect the reason!
> Anyway, over the weekend I ran almost the same experiment in ITK and got
> close results to you.
>
>  Also, today I tried to make the registration process work when Affine
> Transform is used in a multi stage structure, and here is my suggestion:
>
>  I think we do not need to bother ourselves to think about a new
> optimizer or a new initializer for the composite transform since we can
> initialize the fixed parameters of each transform individually at the
> beginning of each stage.
>
>  Remember how we run a BSpline registration stage after some linear
> registrations. At the beginning of the BSpline stage, we should instantiate
> a BSpline transform object and define its fixed parameters (grid size,
> etc). Then, we pass this initialized transform to the registration filter
> using ?SetInitialTransform()?, yet we can initialize this stage by passing
> a composite transform, resultant from the previous stages, to the
> registration filter by ?SetMovingInitialTransform()?.
>
>  The same condition holds for all other transform types with fixed
> unoptimizable parameters like the center of rotation in our Affine
> transform case. Attachment file includes a multi stage registration example
> that I have created for the new software guide. In this example, we use a
> simple 2 stages registration process for a multi modal problem that moving
> image is misaligned from the fixed image by a translation shift and
> rotation. In registration process, a translation transform is followed by
> an affine transform. Also, an initial transform is used at the beginning.
>
>  If I do not set the center of the affine transform, the registration
> fails as you have shown in your Ipython example. However, if at the
> beginning of the second stage, I compute the geometrical center (or center
> of the mass) of the fixed image, and pass that to the affine transform
> using ?SetCenter()? or ?SetFixedParameters()?, the registration succeeds.
> Please take a quick look in the attached file that also includes lots of
> explanations.
>
>  Therefore, we can follow the same procedure for all other transform
> types that their fixed parameters are important in the optimization, but
> those fixed parameters cannot be set explicitly inside a composite
> transform. Please let me know with you think about this.
>
>  Thank you,
> Ali
>
>
>   From: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Date: Saturday, August 2, 2014 at 6:48 PM
> To: Ali Ghayoor <ali-ghayoor at uiowa.edu>
> Cc: Hans Johnson <hans-johnson at uiowa.edu>, Insight Developers List <
> insight-developers at public.kitware.com>
> Subject: Re: [ITK-dev] [ITK] Optimizing composite transforms and center
> of transform
>
>   Hello Ali,
>
>  I created a notebook to try to demonstrate the problem you are
> describing:
>
> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Importance%20of%20Center%20with%20Affine%20Registration.ipynb
>
>  If the center of an Affine transformation isn't correctly initialized
> then the optimization is not speedy or robust. I think it's best
> illustrated with these two graphs:
>
>  <unknown.png>
>  <unknown.png>
>
>  Notice that with the Center being the origin, all 1000 iterations are
> exhausted, and the metric is slowing decreasing. And this is with the
> translation path being around the length to 10. If the spacing was bigger
> or more offset from the origin the situation would be worse.
>
>  I don't think this is a bug with the registration framework. I think new
> initializers for composite transforms are needed, along with documentation
> how the 2 good ways to initialize the registration methods transforms.
>
>
>  Brad
>
>  On Aug 1, 2014, at 8:08 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:
>
> Brad,
>
> I have exactly the same issue. I wrote a simple registration program that
> is run in two stages:
> -Translation
> -Affine
>
> My fixed and moving images are in 2D, and the moving image is created from
> the fixed image by
> rotation of 10 degree and translation of [13,17] in X and Y directions.
>
> The first stage does a translation registration and the result transform
> is added to a composite transform
> that is used as the initial moving transform of the second stage.
>
> After the registration the result transform of the second stage is also
> added to the composite transform
> to be used by the resampler.
>
> I have printed the composite transform to the screen:
>
> 2481: CompositeTransform (0x7fa359a18b00)
> 2481:   RTTI typeinfo:   itk::CompositeTransform<double, 2u>
> 2481:   Reference Count: 2
> 2481:   Modified Time: 20949
> 2481:   Debug: Off
> 2481:   Object Name:
> 2481:   Observers:
> 2481:     none
> 2481:   Transforms in queue, from begin to end:
> 2481:   >>>>>>>>>
> 2481:   TranslationTransform (0x7fa359a199b0)
> 2481:     RTTI typeinfo:   itk::TranslationTransform<double, 2u>
> 2481:     Reference Count: 7
> 2481:     Modified Time: 1648
> 2481:     Debug: Off
> 2481:     Object Name:
> 2481:     Observers:
> 2481:       none
> 2481:     Offset: [12.801, 15.8578]
> 2481:   >>>>>>>>>
> 2481:   AffineTransform (0x7fa359d095a0)
> 2481:     RTTI typeinfo:   itk::AffineTransform<double, 2u>
> 2481:     Reference Count: 5
> 2481:     Modified Time: 20946
> 2481:     Debug: Off
> 2481:     Object Name:
> 2481:     Observers:
> 2481:       none
> 2481:     Matrix:
> 2481:       1.01593 -0.0100051
> 2481:       -0.00835669 1.01113
> 2481:     Offset: [-0.358829, -0.290093]
> 2481:     Center: [0, 0]
> 2481:     Translation: [-0.358829, -0.290093]
> 2481:     Inverse:
> 2481:       0.984397 0.00974056
> 2481:       0.00813575 0.989073
> 2481:     Singular: 0
> 2481:   End of MultiTransform.
> 2481: <<<<<<<<<<
>
> As it can be seen, the translation transform provides a good
> initialization since its offset (Offset: [12.801, 15.8578]) is close to the
> shift parameters.
>
> However, the Affine transform fails to rotate the moving image since its
> Matrix is almost identity.
> Possible reason can be the improper Center of Affine transform that is
> fixed to [0,0], and not at geometrical center or center of mass.
>
> To make sure that I have not made any crazy mistake in my example, I
> simulated my example parameters in ANTs, and ANTs returned
> the same results and failed to register the images!!
>
>   ANTs command line <<<<<<<<<<<
>
>
> PROGPATH=/scratch/ANTS/release-new/bin
>
> fi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainT1SliceBorder20.png
>
> mi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainProtonDensitySliceR10X13Y17.png
>
> time ${PROGPATH}/antsRegistration -d 2 \
> --float \
> --output [test1, warpedMoving.nii.gz] \
> --transform "Translation[16]" \
> --metric MI[${fi},${mi},1,32,None,1] \
> --convergence [100,1e-2,5] \
> --shrink-factors 3 \
> --smoothing-sigmas 2 \
> --use-histogram-matching 1 \
> \
> --transform "Affine[1]" \
> --metric MI[${fi},${mi},1,32] \
> --convergence [100x100,1e-2,2] \
> --shrink-factors 2x1 \
> --smoothing-sigmas 1x0 \
> --use-histogram-matching 1
>
> <<<<<<<<<<<<<<<<<<<<<<<<
>
> Fixed and moving images can be loaded from the ITK data files. What do you
> think about this example? Is it a bug in ITK or just the parameters are not
> tuned finely?
>
> Thanks,
> Ali
>
> ________________________________________
> From: Johnson, Hans J
> Sent: Tuesday, July 29, 2014 6:19 PM
> To: Ghayoor, Ali
> Subject: FW: [ITK-dev] [ITK] Optimizing composite transforms and center of
> transform
>
> Ali,
>
> You need to follow this discussion.
>
> Hans
>
> On 7/29/14, 6:16 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
>
> Hello,
>
> Ok, to further explore this problem, and hopeful help other people too: I
> created an IPython Notebook viewable here:
> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/bl
> ob/master/Transform%20Composition%20And%20Order.ipynb
>
> It doesn't come through on the static page, but I added some nifty
> interactive slider widgets to change the rotation parameter. Which is
> really the point  to enable understanding of the parameters for the
> transform and how they should be best optimized. The notebook should work
> with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one
> to try it out :) IPython Notebooks widget are very cool!
>
> EXPLANATION:
>
> The the order of the composite transform is that the new transforms are
> applied first.
>
> BUT they map from the virtual domain ( fixed ) to the moving image.
> Therefore if your first transform moves the center of mass to the origin
> then the second added transform's space will be centered on the mass,
> which is good for optimizing rotation and affine parameters.
>
> QUESTION:
>
> Therefore I am inclined to conclude that its best practices to map the
> fixed and moving image to the virtual domain such that the center of mass
> ( or some other "center feature" ) are at the origin. This would then the
> scale, rotation and other affine parameters around the center, with out
> having to used the "Center" parameter the transforms currently have.
>
> Is this what others are doing in their registration? For general best
> practices should this be recommend?
>
> @Brian I know I have seen this multi-domain description many time, but I
> think I may have just gotten it... Is the well describe in the literature
> some place? I think this may be an important part add the software guide.
>
> Thanks,
> Brad
>
>
>
>
> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com>
> wrote:
>
> Hi Brad,
>
> Your assessment that the fixed center is important is correct.
>
> In most cases, a transform with a Center is the first transform in a
> Composite transform. There not any issues here.  However, if the
> transform with a Center is further along the chain, then a
> CenteredTransformInitializer that was applied before the registration
> is started will not generate the desired result. In this case, we
> would have to respond to an Event in the registration process and
> estimated the center on the imaged after the other transforms have
> been applied. It is more work, but it is a more unusual case.
>
> HTH,
> Matt
>
>
>
> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>
> Helloo Nick!
>
> I am glad you got back to me.
>
> I suspect that I have spent more time this past week looking at the
> ITK affine transforms than anyone else[1] this week. With that here is
> my current understanding...
>
> 1) The CenterTransformInitializers estimates an initial "Center" and
> an initial "Translation" parameter from either the geometry or the
> first moments. From my problematic experiences, getting the initial
> transform which is a "good" guess is been critical for the optimizer to
> head to the correct solution.
>
> 2) The Center parameter of a transform can either be "Fixed" or an
> optimizable parameter. The transforms with the "Centered" monkier are
> the the ones with the Center parameter optimizable. This issue seems to
> be what you were referring to in to message.
>
> In many ways the point I am trying to make is independent of #2. I
> have observed that it's important to have the "Center" of an affine
> transform ( or sub parameterization thereof ) at the center of the
> object you are trying to register. That is the coordinate space of the
> optimizable parameters' point 0 is near the center. This enables
> rotation to easily rotate around the center, as well as scaling to
> maintain the same relative center when "zooming". This issue is
> independent of wether that center point can be optimized.
>
> For example, consider changing the origin of an image for alignment by
> say 500, and compensating with just an initial translation and not
> setting the "Center" parameter. If we are trying to optimize rotation
> and translation, then the optimization path would be very difficult to
> traverse with these inter-dependent parameters to force it to rotate
> around the center of the object. This scenario may be more common in
> microscopy then medical imaging, due to microscopy frequently having
> multiple subjects across large images. I could write up a IPython
> Notebook to illustrate the case.
>
> So that is my understanding of why using a fixed center is important.
> I thought this may have been shared knowledge, but perhaps is not or is
> incorrect...
>
> Now I am trying to understand how this interacts with all the
> coordinate frames involved with the ITKv4 registration framework, and
> the composite transforms. Specifically the composite transform apply
> the transforms in "reverse order"[2]. As I understand that that means
> that the newest transform get applied first. So that transform
> parameters are being optimized in the images space not in the virtual
> domains we are working towards. Therefore the center of our transforms
> is still important as we composite transforms?
>
> I hope I explained that clearly, a white board may really be needed....
>
> Thanks,
> Brad
>
>
> [1]
> https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94
> 099d3519eb23bcc16c7cf015
> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>
> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com>
> wrote:
>
> Hi Brad,
>
> I apologize for the delayed response.  I?m still catching up on my
> workload after moving to CA.  We might want to talk to Luis as it
> was my understanding that the ?center? component of the linear
> transforms might be a carry-over from all the ?Centered? transforms,
> e.g.,
>
>
> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.htm
> l
>
> which, if I remember correctly, Luis said were somewhat sub optimally
> conceived but this was such a long time ago that I might be completely
> misremembering.  However, fixing the center for all transforms within
> a composite transform is certainly not necessary within the specified
> framework.  Rather, the matrix and offset are updated with the
> ?Center?
> being updated implicitly.
>
> Nick
>
>
>
> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>
> Hello,
>
> There are a lot of transforms involved in the new registration
> framework.
>
> I am trying to figure out what the implications for the fix
> parameters of the transform "Center" ( ie center of rotation/scaling
> ) are when combined with composite transforms and the
> fixed/moving/registration coordinate frames...
>
> Based on how the transforms are composed it seems necessary to set
> the  fix "Center" for subsequent transformations. Additionally, I am
> unsure how one would "improve" ( poorly defined? ) the center for a
> subsequent transform ie Affine after a similarity...
>
> Are there some documented guidance or figures to help with this
> issue?
> Do we have a comprehensive diagram of these transforms?
>
> Thanks,
> Brad
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>
>
>
>
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by
> the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
> confidential and may be legally privileged.  If you are not the intended
> recipient, you are hereby notified that any retention, dissemination,
> distribution, or copying of this communication is strictly prohibited.
>  Please reply to the sender that you have received the message in error,
> then delete it.  Thank you.
> ________________________________
>
>
>    <unknown.png><unknown.png><MultiStageImageRegistration1.cxx>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140805/2e54fd99/attachment-0001.html>

From matt.mccormick at kitware.com  Tue Aug  5 11:37:46 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Tue, 5 Aug 2014 11:37:46 -0400
Subject: [ITK-dev] Upgraded factory.kitware Mac compiler
In-Reply-To: <AA4A0D35-5F18-480B-8476-F4ABDAE4A1E1@mail.nih.gov>
References: <96995EF3-CB2E-4DBD-9360-A7D3909D25E6@mail.nih.gov>
 <CANLz8R5YpnDffP2MzXz1Yzd3qhSC+eSQP8-d3OmJj02C-6Sw1Q@mail.gmail.com>
 <AA4A0D35-5F18-480B-8476-F4ABDAE4A1E1@mail.nih.gov>
Message-ID: <CALzTN-QqY5g3T3JhAt7w7Y+Q90sRk0LWbi1p=TG8RqN7Cn2f=A@mail.gmail.com>

Hi,

I have updated the CDash at Home client configuration to use Clang
instead of GCC.  Clang will hopefully be more reliable with this new
version of XCode.

Thanks,
Matt

On Sat, Aug 2, 2014 at 11:25 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> OK,
>
> I think the compiler being used on the system is not a winner.
>
> Something need to be changes on the system to make this more identifiable,
> perhaps changing the build name to be llvm-gcc-4.2. As it's not apparent in
> the configuration:
>
>  The C compiler identification is GNU 4.2.1
> -- The CXX compiler identification is GNU 4.2.1
> -- Checking whether C compiler has -isysroot
> -- Checking whether C compiler has -isysroot - yes
> -- Checking whether C compiler supports OSX deployment target flag
> -- Checking whether C compiler supports OSX deployment target flag - yes
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Checking whether CXX compiler has -isysroot
> -- Checking whether CXX compiler has -isysroot - yes
> -- Checking whether CXX compiler supports OSX deployment target flag
> -- Checking whether CXX compiler supports OSX deployment target flag - yes
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
>
> Digging into the system information test[1] we can find the following:
>
> sing built-in specs.
> Target: i686-apple-darwin10
> Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/src/configure
> --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2
> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++
> --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
> --with-slibdir=/usr/lib --build=i686-apple-darwin10
> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.1~3/dst-llvmCore/Developer/usr/local
> --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10
> --target=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
>  /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin10/4.2.1/collect2
> -dynamic -arch x86_64 -macosx_version_min 10.6.8 -weak_reference_mismatches
> non-weak -o cmTryCompileExec885700192 -lcrt1.10.6.o
> -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/x86_64
> -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
> -L/usr/lib/gcc/i686-apple-darwin10/4.2.1/x86_64
> -L/usr/lib/i686-apple-darwin10/4.2.1
> -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1
> -L/usr/llvm-gcc-4.2/bin/../lib/gcc
> -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1
> -L/usr/lib/gcc/i686-apple-darwin10/4.2.1
> -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin10/4.2.1/../../..
> -L/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin10/4.2.1/../../..
> -search_paths_first -headerpad_max_install_names -v
> CMakeFiles/cmTryCompileExec885700192.dir/CMakeCCompilerABI.c.o -lSystem
> -lgcc -lSystem
> collect2 version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
> 2336.1.00) (i686 Darwin)
>
>
> But the GCC masquerading version is not too helpful.
>
> [1] http://open.cdash.org/testDetails.php?test=272099142&build=3433750
> On Aug 2, 2014, at 11:03 AM, Jean-Christophe Fillion-Robin
> <jchris.fillionr at kitware.com> wrote:
>
> Hi Brad,
>
> All details are captured here:
>
>     http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=23528
>
>
> XCode before:
>
>  * Xcode: 3.2.6 - uildVersion: 10M2518
>  * gcc-4.0: i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build
> 5494)
>  * gcc-4.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build
> 5666) (dot 3)
>  * llvm-gcc: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple
> Inc. build 5658) (LLVM build 2335.6)
>  * clang: Apple clang version 1.7 (tags/Apple/clang-77) (based on LLVM
> 2.9svn
>
> XCode after:
>
>  * Xcode: 4.2 - Build version 4C199
>  * gcc-4.0: i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build
> 5494)
>  * gcc-4.2: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build
> 5666) (dot 3)
>  * llvm-gcc: i686-apple-darwin10-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple
> Inc. build 5658) (LLVM build 2336.1.00)
>  * clang: Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM
> 3.0svn)
>
>
>
> Hth
> Jc
>
>
> On Sat, Aug 2, 2014 at 8:39 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
> wrote:
>>
>> Hello,
>>
>> Hello there is recently some regular failing tests on the factory.kitware
>> Mac robot build:
>> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3433716
>>
>> What specific compiler, Xcode, and os version is the system now running?
>> Was it recently upgraded?
>>
>> These failures look vaguely familiar to me, not sure quite why. May have
>> been at some point in the GNU gcc->llvm-gcc transition when things didn't
>> work too good...
>>
>> Brad
>>
>>
>
>
>
> --
> +1 919 869 8849
>
>

From blowekamp at mail.nih.gov  Wed Aug  6 15:06:56 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 6 Aug 2014 15:06:56 -0400
Subject: [ITK-dev] DisplacementFieldTransform::SetIdentity method missing?
Message-ID: <2C3F55CD-43B8-4ECF-BA2B-083F54235AA7@mail.nih.gov>

Hello,

I noticed there was no SetIdentity method for the DisplacementFields. It seems like it should be pretty easy to add, just fill the displace field with zeros, and inverse if set?

Brad

From matt.mccormick at kitware.com  Wed Aug  6 15:16:41 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 6 Aug 2014 15:16:41 -0400
Subject: [ITK-dev] [ITK] DisplacementFieldTransform::SetIdentity method
	missing?
In-Reply-To: <2C3F55CD-43B8-4ECF-BA2B-083F54235AA7@mail.nih.gov>
References: <2C3F55CD-43B8-4ECF-BA2B-083F54235AA7@mail.nih.gov>
Message-ID: <CALzTN-R1kThoaEibAdjaCK8PYs0K_fMDtsut6u8ciw-0SweDyw@mail.gmail.com>

Hi Brad,

Sounds like a good plan.

Thanks,
Matt

On Wed, Aug 6, 2014 at 3:06 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello,
>
> I noticed there was no SetIdentity method for the DisplacementFields. It seems like it should be pretty easy to add, just fill the displace field with zeros, and inverse if set?
>
> Brad
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community

From blowekamp at mail.nih.gov  Thu Aug  7 09:21:56 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Thu, 7 Aug 2014 09:21:56 -0400
Subject: [ITK-dev] A couple minor FFT valgrind defects.
Message-ID: <1A49D266-39FE-40F0-B550-6DDFB175E262@mail.nih.gov>

Matt,

After addressing the large number of ThreadPool defects, there appears to a a minor uninitialized condition with these new complex fft filters:

http://open.cdash.org/viewDynamicAnalysis.php?buildid=3440158

Let me know if you have the time.

Thanks,
Brad

From matt.mccormick at kitware.com  Thu Aug  7 09:33:19 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 7 Aug 2014 09:33:19 -0400
Subject: [ITK-dev] A couple minor FFT valgrind defects.
In-Reply-To: <1A49D266-39FE-40F0-B550-6DDFB175E262@mail.nih.gov>
References: <1A49D266-39FE-40F0-B550-6DDFB175E262@mail.nih.gov>
Message-ID: <CALzTN-TNVQ3zoKZS-TsZBOufDSJHHn=JxDbbUB7Xj3VMpPPUWQ@mail.gmail.com>

Hi Brad,

Happy to see we are getting back to zero :-).

Yes, please review this patch:

  http://review.source.kitware.com/#/c/16542/

Thanks,
Matt

On Thu, Aug 7, 2014 at 9:21 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Matt,
>
> After addressing the large number of ThreadPool defects, there appears to a a minor uninitialized condition with these new complex fft filters:
>
> http://open.cdash.org/viewDynamicAnalysis.php?buildid=3440158
>
> Let me know if you have the time.
>
> Thanks,
> Brad

From matt.mccormick at kitware.com  Thu Aug  7 14:20:19 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 7 Aug 2014 14:20:19 -0400
Subject: [ITK-dev] ITK Development Meeting
Message-ID: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>

Hi,

Are we having the development meeting teleconference tomorrow?  If
not, would folks like to do a Google Hangout at 9 AM?

On a positive side note, Google Hangout's no longer require a Google
Plus account [1], and it no longer requires plugins with Chrome/ium
[2].

I am happy to see the Goog-Monster moving towards greater openness and
liberty.  Maybe the internal forces for good are becoming stronger
:-).

Thanks,
Matt

[1] http://techcrunch.com/2014/07/30/hangouts-now-works-without-google-account-becomes-part-of-google-apps-for-business-and-gets-sla/

[2] http://www.omgchrome.com/google-hangouts-chrome-plugin-free-2/

From blowekamp at mail.nih.gov  Thu Aug  7 14:23:07 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Thu, 7 Aug 2014 14:23:07 -0400
Subject: [ITK-dev] ITK Development Meeting
In-Reply-To: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>
References: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>
Message-ID: <09B4CD10-BCDE-4F28-BDB1-D3791E36BBD8@mail.nih.gov>

Hello,

I am in favor of using Google Hangout as it appears to be more accessible to people and more seem to be able to join.

Brad

On Aug 7, 2014, at 2:20 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:

> Hi,
> 
> Are we having the development meeting teleconference tomorrow?  If
> not, would folks like to do a Google Hangout at 9 AM?
> 
> On a positive side note, Google Hangout's no longer require a Google
> Plus account [1], and it no longer requires plugins with Chrome/ium
> [2].
> 
> I am happy to see the Goog-Monster moving towards greater openness and
> liberty.  Maybe the internal forces for good are becoming stronger
> :-).
> 
> Thanks,
> Matt
> 
> [1] http://techcrunch.com/2014/07/30/hangouts-now-works-without-google-account-becomes-part-of-google-apps-for-business-and-gets-sla/
> 
> [2] http://www.omgchrome.com/google-hangouts-chrome-plugin-free-2/


From bill.lorensen at gmail.com  Thu Aug  7 14:24:40 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Thu, 7 Aug 2014 14:24:40 -0400
Subject: [ITK-dev] [ITK] ITK Development Meeting
In-Reply-To: <09B4CD10-BCDE-4F28-BDB1-D3791E36BBD8@mail.nih.gov>
References: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>
 <09B4CD10-BCDE-4F28-BDB1-D3791E36BBD8@mail.nih.gov>
Message-ID: <CADZJ4hMuGpKQvyumyw6qz8PrMqEKfLUtpfnSijdUprU7gNAhKg@mail.gmail.com>

+1


On Thu, Aug 7, 2014 at 2:23 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> Hello,
>
> I am in favor of using Google Hangout as it appears to be more accessible to people and more seem to be able to join.
>
> Brad
>
> On Aug 7, 2014, at 2:20 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>
>> Hi,
>>
>> Are we having the development meeting teleconference tomorrow?  If
>> not, would folks like to do a Google Hangout at 9 AM?
>>
>> On a positive side note, Google Hangout's no longer require a Google
>> Plus account [1], and it no longer requires plugins with Chrome/ium
>> [2].
>>
>> I am happy to see the Goog-Monster moving towards greater openness and
>> liberty.  Maybe the internal forces for good are becoming stronger
>> :-).
>>
>> Thanks,
>> Matt
>>
>> [1] http://techcrunch.com/2014/07/30/hangouts-now-works-without-google-account-becomes-part-of-google-apps-for-business-and-gets-sla/
>>
>> [2] http://www.omgchrome.com/google-hangouts-chrome-plugin-free-2/
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community



-- 
Unpaid intern in BillsBasement at noware dot com

From millerjv at ge.com  Thu Aug  7 14:30:04 2014
From: millerjv at ge.com (Miller, James V (GE Global Research))
Date: Thu, 7 Aug 2014 18:30:04 +0000
Subject: [ITK-dev] ITK Development Meeting
In-Reply-To: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>
References: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>
Message-ID: <2CD24A027ACF154199B5D6F6E5EF830BB487D924@CINMBCNA06.e2k.ad.ge.com>

I don't have a strong preference.

Note, it looks like Hangouts require either a Google+ or a Google Apps account. It doesn't look like a plain old Google account is supported yet.

Jim

-----Original Message-----
From: Matt McCormick [mailto:matt.mccormick at kitware.com] 
Sent: Thursday, August 07, 2014 2:20 PM
To: ITK; community at itk.org; Bradley Lowekamp; Miller, James V (GE Global Research); Padfield, Dirk R (GE Global Research)
Subject: ITK Development Meeting

Hi,

Are we having the development meeting teleconference tomorrow?  If not, would folks like to do a Google Hangout at 9 AM?

On a positive side note, Google Hangout's no longer require a Google Plus account [1], and it no longer requires plugins with Chrome/ium [2].

I am happy to see the Goog-Monster moving towards greater openness and liberty.  Maybe the internal forces for good are becoming stronger :-).

Thanks,
Matt

[1] http://techcrunch.com/2014/07/30/hangouts-now-works-without-google-account-becomes-part-of-google-apps-for-business-and-gets-sla/

[2] http://www.omgchrome.com/google-hangouts-chrome-plugin-free-2/

From matt.mccormick at kitware.com  Thu Aug  7 15:19:02 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 7 Aug 2014 15:19:02 -0400
Subject: [ITK-dev] [ITK] ITK Development Meeting
In-Reply-To: <913EF9B6-84A0-4BD3-A154-EBCFD92685E5@gmail.com>
References: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>
 <09B4CD10-BCDE-4F28-BDB1-D3791E36BBD8@mail.nih.gov>
 <CADZJ4hMuGpKQvyumyw6qz8PrMqEKfLUtpfnSijdUprU7gNAhKg@mail.gmail.com>
 <913EF9B6-84A0-4BD3-A154-EBCFD92685E5@gmail.com>
Message-ID: <CALzTN-SGcCYQuNNXsnJGdfmBbEkWmf7a6puCWKfsG+xhh25ZEA@mail.gmail.com>

OK, let's do 9 AM Eastern Time Zone (GMT-4). :-)

I created an Event here [1].

If you are subscribed to the ITK Bar Camp Community [2], you should
already have received an invitation.

Thanks,
Matt

[1] https://plus.google.com/events/cauvj61hvr7kirg5g5vjsupt4pg

[2] https://plus.google.com/communities/111375098792764998322

On Thu, Aug 7, 2014 at 2:43 PM, Michka Popoff <michkapopoff at gmail.com> wrote:
> +1
>
> 9 AM, what timezone ? ;D
>
> On 7 ao?t 2014, at 20:24, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>
>> +1
>>
>>
>> On Thu, Aug 7, 2014 at 2:23 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>> Hello,
>>>
>>> I am in favor of using Google Hangout as it appears to be more accessible to people and more seem to be able to join.
>>>
>>> Brad
>>>
>>> On Aug 7, 2014, at 2:20 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Are we having the development meeting teleconference tomorrow?  If
>>>> not, would folks like to do a Google Hangout at 9 AM?
>>>>
>>>> On a positive side note, Google Hangout's no longer require a Google
>>>> Plus account [1], and it no longer requires plugins with Chrome/ium
>>>> [2].
>>>>
>>>> I am happy to see the Goog-Monster moving towards greater openness and
>>>> liberty.  Maybe the internal forces for good are becoming stronger
>>>> :-).
>>>>
>>>> Thanks,
>>>> Matt
>>>>
>>>> [1] http://techcrunch.com/2014/07/30/hangouts-now-works-without-google-account-becomes-part-of-google-apps-for-business-and-gets-sla/
>>>>
>>>> [2] http://www.omgchrome.com/google-hangouts-chrome-plugin-free-2/
>>>
>>> _______________________________________________
>>> Community mailing list
>>> Community at itk.org
>>> http://public.kitware.com/mailman/listinfo/community
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community

From norman-k-williams at uiowa.edu  Mon Aug 11 12:49:31 2014
From: norman-k-williams at uiowa.edu (Williams, Norman K)
Date: Mon, 11 Aug 2014 16:49:31 +0000
Subject: [ITK-dev] VtkGlue module -- strange configuration.
Message-ID: <D00E5E39.A366%norman-k-williams@uiowa.edu>

I?ve been messing with making the VtkGlue module use a more specific signature for find_package(VTK)*

In ITK/Modules/Bridge/VtkGlue/itk-module-init.cmake there?s this:

set(VERSION_MIN "5.9.20110419")

? which as far as I can tell is nonsense; I checked out the VTK version from April 19th 2011, and the VTK version is set to be 5.9.0

I don?t think the VTK_BUILD_VERSION would ever be set to a specific date stamp.

What is required ? in order to use find_package(VTK COMPONENTS ?) -- would be the first revision after VTK Modularization was working.  And in fact, given how VTK sets its version numbers ? hard coded in the top level CMakeLists.txt ? I don?t even know how that would work.

Any ideas?

*This is an outgrowth of the work I?m doing on tailoring BRAINSTools? dependency processing in CMake for Slicer inclusion.  Specifically, rather than use find_package(ITK REQUIRED) use find_package(ITK COMPONENTS ? REQUIRED) ? this only adds the include paths (to compiles) and libraries (to link commangs) actually used by the specific programs.  There?s no find_package(ITK) at the top level of the build tree; there?s a specific find_package in each subdirectory that only requests the COMPONENTS actually referenced.





________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140811/74dae80d/attachment.html>

From bill.lorensen at gmail.com  Mon Aug 11 13:32:21 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 11 Aug 2014 13:32:21 -0400
Subject: [ITK-dev] VtkGlue module -- strange configuration.
In-Reply-To: <D00E5E39.A366%norman-k-williams@uiowa.edu>
References: <D00E5E39.A366%norman-k-williams@uiowa.edu>
Message-ID: <CADZJ4hNYe_8c56dfOVtFQi=7yRgwt+d6n6yXWf=bDHNYFFdz6Q@mail.gmail.com>

I set that version. VTK used to use a nightly version stamp. If I
recall, there was a fix made in vtk regarding meta library
configurations. It could probably be set to 6.0.


On Mon, Aug 11, 2014 at 12:49 PM, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:
> I?ve been messing with making the VtkGlue module use a more specific
> signature for find_package(VTK)*
>
> In ITK/Modules/Bridge/VtkGlue/itk-module-init.cmake there?s this:
>
> set(VERSION_MIN "5.9.20110419")
>
> ? which as far as I can tell is nonsense; I checked out the VTK version from
> April 19th 2011, and the VTK version is set to be 5.9.0
>
> I don?t think the VTK_BUILD_VERSION would ever be set to a specific date
> stamp.
>
> What is required ? in order to use find_package(VTK COMPONENTS ?) -- would
> be the first revision after VTK Modularization was working.  And in fact,
> given how VTK sets its version numbers ? hard coded in the top level
> CMakeLists.txt ? I don?t even know how that would work.
>
> Any ideas?
>
> *This is an outgrowth of the work I?m doing on tailoring BRAINSTools?
> dependency processing in CMake for Slicer inclusion.  Specifically, rather
> than use find_package(ITK REQUIRED) use find_package(ITK COMPONENTS ?
> REQUIRED) ? this only adds the include paths (to compiles) and libraries (to
> link commangs) actually used by the specific programs.  There?s no
> find_package(ITK) at the top level of the build tree; there?s a specific
> find_package in each subdirectory that only requests the COMPONENTS actually
> referenced.
>
>
>
>
>
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by the
> Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential
> and may be legally privileged.  If you are not the intended recipient, you
> are hereby notified that any retention, dissemination, distribution, or
> copying of this communication is strictly prohibited.  Please reply to the
> sender that you have received the message in error, then delete it.  Thank
> you.
> ________________________________
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>



-- 
Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Mon Aug 11 13:33:00 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 11 Aug 2014 13:33:00 -0400
Subject: [ITK-dev] VtkGlue module -- strange configuration.
In-Reply-To: <CADZJ4hNYe_8c56dfOVtFQi=7yRgwt+d6n6yXWf=bDHNYFFdz6Q@mail.gmail.com>
References: <D00E5E39.A366%norman-k-williams@uiowa.edu>
 <CADZJ4hNYe_8c56dfOVtFQi=7yRgwt+d6n6yXWf=bDHNYFFdz6Q@mail.gmail.com>
Message-ID: <CADZJ4hPVF0U1-Wb1rOkPaZrRs8awAqNKRNMxOWByEJ_3Kp5AHQ@mail.gmail.com>

Or set to VTK 5.10


On Mon, Aug 11, 2014 at 1:32 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> I set that version. VTK used to use a nightly version stamp. If I
> recall, there was a fix made in vtk regarding meta library
> configurations. It could probably be set to 6.0.
>
>
> On Mon, Aug 11, 2014 at 12:49 PM, Williams, Norman K
> <norman-k-williams at uiowa.edu> wrote:
>> I?ve been messing with making the VtkGlue module use a more specific
>> signature for find_package(VTK)*
>>
>> In ITK/Modules/Bridge/VtkGlue/itk-module-init.cmake there?s this:
>>
>> set(VERSION_MIN "5.9.20110419")
>>
>> ? which as far as I can tell is nonsense; I checked out the VTK version from
>> April 19th 2011, and the VTK version is set to be 5.9.0
>>
>> I don?t think the VTK_BUILD_VERSION would ever be set to a specific date
>> stamp.
>>
>> What is required ? in order to use find_package(VTK COMPONENTS ?) -- would
>> be the first revision after VTK Modularization was working.  And in fact,
>> given how VTK sets its version numbers ? hard coded in the top level
>> CMakeLists.txt ? I don?t even know how that would work.
>>
>> Any ideas?
>>
>> *This is an outgrowth of the work I?m doing on tailoring BRAINSTools?
>> dependency processing in CMake for Slicer inclusion.  Specifically, rather
>> than use find_package(ITK REQUIRED) use find_package(ITK COMPONENTS ?
>> REQUIRED) ? this only adds the include paths (to compiles) and libraries (to
>> link commangs) actually used by the specific programs.  There?s no
>> find_package(ITK) at the top level of the build tree; there?s a specific
>> find_package in each subdirectory that only requests the COMPONENTS actually
>> referenced.
>>
>>
>>
>>
>>
>> ________________________________
>> Notice: This UI Health Care e-mail (including attachments) is covered by the
>> Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential
>> and may be legally privileged.  If you are not the intended recipient, you
>> are hereby notified that any retention, dissemination, distribution, or
>> copying of this communication is strictly prohibited.  Please reply to the
>> sender that you have received the message in error, then delete it.  Thank
>> you.
>> ________________________________
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Mon Aug 11 13:36:06 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Mon, 11 Aug 2014 13:36:06 -0400
Subject: [ITK-dev] VtkGlue module -- strange configuration.
In-Reply-To: <CADZJ4hPVF0U1-Wb1rOkPaZrRs8awAqNKRNMxOWByEJ_3Kp5AHQ@mail.gmail.com>
References: <D00E5E39.A366%norman-k-williams@uiowa.edu>
 <CADZJ4hNYe_8c56dfOVtFQi=7yRgwt+d6n6yXWf=bDHNYFFdz6Q@mail.gmail.com>
 <CADZJ4hPVF0U1-Wb1rOkPaZrRs8awAqNKRNMxOWByEJ_3Kp5AHQ@mail.gmail.com>
Message-ID: <CADZJ4hPPXPGHM8ik9UCEP9-Eep766+jm-X2hqGP6xzbVR2rQLQ@mail.gmail.com>

The commit log for my change says it all:

commit 913e2164cca521f791aac6d20bce34cba9831e96
Author: Bill Lorensen <bill.lorensen at gmail.com>
Date:   Sun Feb 19 08:21:41 2012 -0500

    BUG: Older version of VTK cannot be used with ITK

    Versions of VTK prior to April 19, 2011 cannot be used with ITKv4
    because of issues with MetaIO. Note that VTK 5.9 contains this error.
    These older version will produce the compile errors:
    MetaObject does not name a type
    MetaObjectType does not name a type
    plus others.

    The errors are caused by a change in the way MetaIO configures
    itself. Since VTK commit eb532553, (MetaIO: Avoid requiring parent
    projects to provide "../metaIOConfig.h", 2011-04-06) MetaIO configures
    a header into it's build tree.)

    The earliest VTK commit tag that will work is
    be4c4f115793598f6c8937a98bdd1f227d471540

    Change-Id: I58506c09b53344a8550df9aed5a9ceda844597e4

On Mon, Aug 11, 2014 at 1:33 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Or set to VTK 5.10
>
>
> On Mon, Aug 11, 2014 at 1:32 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> I set that version. VTK used to use a nightly version stamp. If I
>> recall, there was a fix made in vtk regarding meta library
>> configurations. It could probably be set to 6.0.
>>
>>
>> On Mon, Aug 11, 2014 at 12:49 PM, Williams, Norman K
>> <norman-k-williams at uiowa.edu> wrote:
>>> I?ve been messing with making the VtkGlue module use a more specific
>>> signature for find_package(VTK)*
>>>
>>> In ITK/Modules/Bridge/VtkGlue/itk-module-init.cmake there?s this:
>>>
>>> set(VERSION_MIN "5.9.20110419")
>>>
>>> ? which as far as I can tell is nonsense; I checked out the VTK version from
>>> April 19th 2011, and the VTK version is set to be 5.9.0
>>>
>>> I don?t think the VTK_BUILD_VERSION would ever be set to a specific date
>>> stamp.
>>>
>>> What is required ? in order to use find_package(VTK COMPONENTS ?) -- would
>>> be the first revision after VTK Modularization was working.  And in fact,
>>> given how VTK sets its version numbers ? hard coded in the top level
>>> CMakeLists.txt ? I don?t even know how that would work.
>>>
>>> Any ideas?
>>>
>>> *This is an outgrowth of the work I?m doing on tailoring BRAINSTools?
>>> dependency processing in CMake for Slicer inclusion.  Specifically, rather
>>> than use find_package(ITK REQUIRED) use find_package(ITK COMPONENTS ?
>>> REQUIRED) ? this only adds the include paths (to compiles) and libraries (to
>>> link commangs) actually used by the specific programs.  There?s no
>>> find_package(ITK) at the top level of the build tree; there?s a specific
>>> find_package in each subdirectory that only requests the COMPONENTS actually
>>> referenced.
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>> Notice: This UI Health Care e-mail (including attachments) is covered by the
>>> Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential
>>> and may be legally privileged.  If you are not the intended recipient, you
>>> are hereby notified that any retention, dissemination, distribution, or
>>> copying of this communication is strictly prohibited.  Please reply to the
>>> sender that you have received the message in error, then delete it.  Thank
>>> you.
>>> ________________________________
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.php
>>>
>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From ntustison at gmail.com  Wed Aug 13 12:39:50 2014
From: ntustison at gmail.com (Nicholas Tustison)
Date: Wed, 13 Aug 2014 09:39:50 -0700
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center of
	transform
In-Reply-To: <DEB2BC6C-1B55-4B37-9B4B-35702294B826@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <CFFD962C.871A8%hans-johnson@uiowa.edu>
 <EAA163371EE66741A63B092281D1F3FE1884ED74@itsnt444.iowa.uiowa.edu>
 <97C77D92-4BAD-4D90-912D-E2AB95D63E19@mail.nih.gov>
 <D005AFFD.6377%ali-ghayoor@uiowa.edu>
 <85D2068C-A0FC-46EE-8CF8-3F44CDB40E5D@mail.nih.gov>
 <DEB2BC6C-1B55-4B37-9B4B-35702294B826@mail.nih.gov>
Message-ID: <C18E1892-6D0F-42A7-A384-2A66660F5454@gmail.com>

I?ll change it and add an origin far from (0,0) in the example.

Nick

On Aug 13, 2014, at 9:23 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Nick,
> 
> Thanks you for working on the patch. It appears that I was incorrect with my proposed formula for propagating the center.
> 
> Hans, Ali, and myself have continued this discussion over the the last couple of days. After further experimentation with IPython notebooks and composite transform we developed a better test cases to interact with. This lead to the conclusion that the Center parameter is not an point in the moving image's domain, but a point in the fixed. Therefore the same center can be used for all composite affine transforms and it can more simply be just copied along. Here is the corrected statement:
> 
> 
> For a Composite transformed defined as ?=T0(T1(x)) where ?:?fixed??moving then if C such that C??fixed is the correct center initialization for T0, then the correct center initialization for T1 is still C, as it is set in the in the domain ( not the range ) of the individual transforms.
> 
> And here is a link to a viewer of the revisited notebooks:
> 
> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/UpdateCompositeTransformCenter/Transform%20Composition%20And%20Order.ipynb
> 
> Brad
> 
> On Aug 5, 2014, at 8:03 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
>> Ali,
>> 
>> Glad to hear the registration iteration graphs where effective.
>> 
>> Yes, you are right you can initialize the parameters of the second stage affine registration. Specifically the Center. However, it not readily apparent ( no example, no filter/initializer ) how that center fixed parameter should be initialized. And the "CenteredTransformInitializer" is not the correct way.
>> 
>> For a Composite transformed defined as ?=T0(T1(x)) where ?:?fixed??moving then if C such that C??moving is the correct center initialization for T1, then the correct center initialization for T0 when in the composite transform is C?=T?10(C).
>> 
>> Cool pasting from the IPython Notebook with inline latex appears to have worked :)
>> 
>> While it is easy to do this with the MomentsCaluclator and manually doing the transform inverse, I think to make it more readily apparent and easier to use it should be available as a filter/initializer.
>> 
>> There are several things  that are done manually in the examples that I would think should be updated to use the latest filters and initializers. For example The BSplines are manually initialized instead of using the BSplineTransform Initializer[1]. Additionally,  conversion of BSpline to a deformation field[2], and the the upsampling of the BSpine[3], though that last one still looks like ITKv3 framework, so maybe it'll be updated to the adaptors with v4. However I am after simple functions for these common tasks for SimpleITK, so I have a bit different perspective then one who is OK with implementing a 50 line solution in C++ and being OK with the interface.
>> 
>> We'll discuss these initialization issue further this afternoon.
>> 
>> Brad
>> 
>> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L215-L235
>> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L401-L430
>> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration6.cxx#L273-L330
>> 
>> On Aug 4, 2014, at 11:56 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:
>> 
>>> Hello Brad,
>>> 
>>> It is an awesome way for demonstration, and thanks for verification of my example. It seems that this email is sent on Saturday, but unfortunately I got that this morning! And I should inspect the reason! 
>>> Anyway, over the weekend I ran almost the same experiment in ITK and got close results to you.
>>> 
>>> Also, today I tried to make the registration process work when Affine Transform is used in a multi stage structure, and here is my suggestion:
>>> 
>>> I think we do not need to bother ourselves to think about a new optimizer or a new initializer for the composite transform since we can initialize the fixed parameters of each transform individually at the beginning of each stage.
>>> 
>>> Remember how we run a BSpline registration stage after some linear registrations. At the beginning of the BSpline stage, we should instantiate a BSpline transform object and define its fixed parameters (grid size, etc). Then, we pass this initialized transform to the registration filter using ?SetInitialTransform()?, yet we can initialize this stage by passing a composite transform, resultant from the previous stages, to the registration filter by ?SetMovingInitialTransform()?.
>>> 
>>> The same condition holds for all other transform types with fixed unoptimizable parameters like the center of rotation in our Affine transform case. Attachment file includes a multi stage registration example that I have created for the new software guide. In this example, we use a simple 2 stages registration process for a multi modal problem that moving image is misaligned from the fixed image by a translation shift and rotation. In registration process, a translation transform is followed by an affine transform. Also, an initial transform is used at the beginning.
>>> 
>>> If I do not set the center of the affine transform, the registration fails as you have shown in your Ipython example. However, if at the beginning of the second stage, I compute the geometrical center (or center of the mass) of the fixed image, and pass that to the affine transform using ?SetCenter()? or ?SetFixedParameters()?, the registration succeeds. Please take a quick look in the attached file that also includes lots of explanations. 
>>> 
>>> Therefore, we can follow the same procedure for all other transform types that their fixed parameters are important in the optimization, but those fixed parameters cannot be set explicitly inside a composite transform. Please let me know with you think about this.
>>> 
>>> Thank you,
>>> Ali
>>> 
>>> 
>>> From: Bradley Lowekamp <blowekamp at mail.nih.gov>
>>> Date: Saturday, August 2, 2014 at 6:48 PM
>>> To: Ali Ghayoor <ali-ghayoor at uiowa.edu>
>>> Cc: Hans Johnson <hans-johnson at uiowa.edu>, Insight Developers List <insight-developers at public.kitware.com>
>>> Subject: Re: [ITK-dev] [ITK] Optimizing composite transforms and center of transform
>>> 
>>> Hello Ali,
>>> 
>>> I created a notebook to try to demonstrate the problem you are describing:
>>> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Importance%20of%20Center%20with%20Affine%20Registration.ipynb
>>> 
>>> If the center of an Affine transformation isn't correctly initialized then the optimization is not speedy or robust. I think it's best illustrated with these two graphs:
>>> 
>>> <unknown.png>
>>> <unknown.png>
>>> 
>>> Notice that with the Center being the origin, all 1000 iterations are exhausted, and the metric is slowing decreasing. And this is with the translation path being around the length to 10. If the spacing was bigger or more offset from the origin the situation would be worse.
>>> 
>>> I don't think this is a bug with the registration framework. I think new initializers for composite transforms are needed, along with documentation how the 2 good ways to initialize the registration methods transforms.
>>> 
>>> 
>>> Brad
>>> 
>>> On Aug 1, 2014, at 8:08 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:
>>> 
>>>> Brad,
>>>> 
>>>> I have exactly the same issue. I wrote a simple registration program that is run in two stages:
>>>> -Translation
>>>> -Affine
>>>> 
>>>> My fixed and moving images are in 2D, and the moving image is created from the fixed image by
>>>> rotation of 10 degree and translation of [13,17] in X and Y directions.
>>>> 
>>>> The first stage does a translation registration and the result transform is added to a composite transform
>>>> that is used as the initial moving transform of the second stage.
>>>> 
>>>> After the registration the result transform of the second stage is also added to the composite transform
>>>> to be used by the resampler.
>>>> 
>>>> I have printed the composite transform to the screen:
>>>> 
>>>> 2481: CompositeTransform (0x7fa359a18b00)
>>>> 2481:   RTTI typeinfo:   itk::CompositeTransform<double, 2u>
>>>> 2481:   Reference Count: 2
>>>> 2481:   Modified Time: 20949
>>>> 2481:   Debug: Off
>>>> 2481:   Object Name: 
>>>> 2481:   Observers: 
>>>> 2481:     none
>>>> 2481:   Transforms in queue, from begin to end:
>>>> 2481:   >>>>>>>>>
>>>> 2481:   TranslationTransform (0x7fa359a199b0)
>>>> 2481:     RTTI typeinfo:   itk::TranslationTransform<double, 2u>
>>>> 2481:     Reference Count: 7
>>>> 2481:     Modified Time: 1648
>>>> 2481:     Debug: Off
>>>> 2481:     Object Name: 
>>>> 2481:     Observers: 
>>>> 2481:       none
>>>> 2481:     Offset: [12.801, 15.8578]
>>>> 2481:   >>>>>>>>>
>>>> 2481:   AffineTransform (0x7fa359d095a0)
>>>> 2481:     RTTI typeinfo:   itk::AffineTransform<double, 2u>
>>>> 2481:     Reference Count: 5
>>>> 2481:     Modified Time: 20946
>>>> 2481:     Debug: Off
>>>> 2481:     Object Name: 
>>>> 2481:     Observers: 
>>>> 2481:       none
>>>> 2481:     Matrix: 
>>>> 2481:       1.01593 -0.0100051 
>>>> 2481:       -0.00835669 1.01113 
>>>> 2481:     Offset: [-0.358829, -0.290093]
>>>> 2481:     Center: [0, 0]
>>>> 2481:     Translation: [-0.358829, -0.290093]
>>>> 2481:     Inverse: 
>>>> 2481:       0.984397 0.00974056 
>>>> 2481:       0.00813575 0.989073 
>>>> 2481:     Singular: 0
>>>> 2481:   End of MultiTransform.
>>>> 2481: <<<<<<<<<<
>>>> 
>>>> As it can be seen, the translation transform provides a good initialization since its offset (Offset: [12.801, 15.8578]) is close to the shift parameters.
>>>> 
>>>> However, the Affine transform fails to rotate the moving image since its Matrix is almost identity.
>>>> Possible reason can be the improper Center of Affine transform that is fixed to [0,0], and not at geometrical center or center of mass.
>>>> 
>>>> To make sure that I have not made any crazy mistake in my example, I simulated my example parameters in ANTs, and ANTs returned
>>>> the same results and failed to register the images!!
>>>> 
>>>>>>>>> ANTs command line <<<<<<<<<<<
>>>> 
>>>> PROGPATH=/scratch/ANTS/release-new/bin
>>>> fi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainT1SliceBorder20.png
>>>> mi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainProtonDensitySliceR10X13Y17.png
>>>> 
>>>> time ${PROGPATH}/antsRegistration -d 2 \
>>>> --float \
>>>> --output [test1, warpedMoving.nii.gz] \
>>>> --transform "Translation[16]" \
>>>> --metric MI[${fi},${mi},1,32,None,1] \
>>>> --convergence [100,1e-2,5] \
>>>> --shrink-factors 3 \
>>>> --smoothing-sigmas 2 \
>>>> --use-histogram-matching 1 \
>>>> \
>>>> --transform "Affine[1]" \
>>>> --metric MI[${fi},${mi},1,32] \
>>>> --convergence [100x100,1e-2,2] \
>>>> --shrink-factors 2x1 \
>>>> --smoothing-sigmas 1x0 \
>>>> --use-histogram-matching 1
>>>> 
>>>> <<<<<<<<<<<<<<<<<<<<<<<<
>>>> 
>>>> Fixed and moving images can be loaded from the ITK data files. What do you think about this example? Is it a bug in ITK or just the parameters are not tuned finely?
>>>> 
>>>> Thanks,
>>>> Ali
>>>> 
>>>> ________________________________________
>>>> From: Johnson, Hans J
>>>> Sent: Tuesday, July 29, 2014 6:19 PM
>>>> To: Ghayoor, Ali
>>>> Subject: FW: [ITK-dev] [ITK] Optimizing composite transforms and center of transform
>>>> 
>>>> Ali,
>>>> 
>>>> You need to follow this discussion.
>>>> 
>>>> Hans
>>>> 
>>>> On 7/29/14, 6:16 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Ok, to further explore this problem, and hopeful help other people too: I
>>>>> created an IPython Notebook viewable here:
>>>>> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/bl
>>>>> ob/master/Transform%20Composition%20And%20Order.ipynb
>>>>> 
>>>>> It doesn't come through on the static page, but I added some nifty
>>>>> interactive slider widgets to change the rotation parameter. Which is
>>>>> really the point  to enable understanding of the parameters for the
>>>>> transform and how they should be best optimized. The notebook should work
>>>>> with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one
>>>>> to try it out :) IPython Notebooks widget are very cool!
>>>>> 
>>>>> EXPLANATION:
>>>>> 
>>>>> The the order of the composite transform is that the new transforms are
>>>>> applied first.
>>>>> 
>>>>> BUT they map from the virtual domain ( fixed ) to the moving image.
>>>>> Therefore if your first transform moves the center of mass to the origin
>>>>> then the second added transform's space will be centered on the mass,
>>>>> which is good for optimizing rotation and affine parameters.
>>>>> 
>>>>> QUESTION:
>>>>> 
>>>>> Therefore I am inclined to conclude that its best practices to map the
>>>>> fixed and moving image to the virtual domain such that the center of mass
>>>>> ( or some other "center feature" ) are at the origin. This would then the
>>>>> scale, rotation and other affine parameters around the center, with out
>>>>> having to used the "Center" parameter the transforms currently have.
>>>>> 
>>>>> Is this what others are doing in their registration? For general best
>>>>> practices should this be recommend?
>>>>> 
>>>>> @Brian I know I have seen this multi-domain description many time, but I
>>>>> think I may have just gotten it... Is the well describe in the literature
>>>>> some place? I think this may be an important part add the software guide.
>>>>> 
>>>>> Thanks,
>>>>> Brad
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi Brad,
>>>>>> 
>>>>>> Your assessment that the fixed center is important is correct.
>>>>>> 
>>>>>> In most cases, a transform with a Center is the first transform in a
>>>>>> Composite transform. There not any issues here.  However, if the
>>>>>> transform with a Center is further along the chain, then a
>>>>>> CenteredTransformInitializer that was applied before the registration
>>>>>> is started will not generate the desired result. In this case, we
>>>>>> would have to respond to an Event in the registration process and
>>>>>> estimated the center on the imaged after the other transforms have
>>>>>> been applied. It is more work, but it is a more unusual case.
>>>>>> 
>>>>>> HTH,
>>>>>> Matt
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
>>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>> Helloo Nick!
>>>>>>> 
>>>>>>> I am glad you got back to me.
>>>>>>> 
>>>>>>> I suspect that I have spent more time this past week looking at the
>>>>>>> ITK affine transforms than anyone else[1] this week. With that here is
>>>>>>> my current understanding...
>>>>>>> 
>>>>>>> 1) The CenterTransformInitializers estimates an initial "Center" and
>>>>>>> an initial "Translation" parameter from either the geometry or the
>>>>>>> first moments. From my problematic experiences, getting the initial
>>>>>>> transform which is a "good" guess is been critical for the optimizer to
>>>>>>> head to the correct solution.
>>>>>>> 
>>>>>>> 2) The Center parameter of a transform can either be "Fixed" or an
>>>>>>> optimizable parameter. The transforms with the "Centered" monkier are
>>>>>>> the the ones with the Center parameter optimizable. This issue seems to
>>>>>>> be what you were referring to in to message.
>>>>>>> 
>>>>>>> In many ways the point I am trying to make is independent of #2. I
>>>>>>> have observed that it's important to have the "Center" of an affine
>>>>>>> transform ( or sub parameterization thereof ) at the center of the
>>>>>>> object you are trying to register. That is the coordinate space of the
>>>>>>> optimizable parameters' point 0 is near the center. This enables
>>>>>>> rotation to easily rotate around the center, as well as scaling to
>>>>>>> maintain the same relative center when "zooming". This issue is
>>>>>>> independent of wether that center point can be optimized.
>>>>>>> 
>>>>>>> For example, consider changing the origin of an image for alignment by
>>>>>>> say 500, and compensating with just an initial translation and not
>>>>>>> setting the "Center" parameter. If we are trying to optimize rotation
>>>>>>> and translation, then the optimization path would be very difficult to
>>>>>>> traverse with these inter-dependent parameters to force it to rotate
>>>>>>> around the center of the object. This scenario may be more common in
>>>>>>> microscopy then medical imaging, due to microscopy frequently having
>>>>>>> multiple subjects across large images. I could write up a IPython
>>>>>>> Notebook to illustrate the case.
>>>>>>> 
>>>>>>> So that is my understanding of why using a fixed center is important.
>>>>>>> I thought this may have been shared knowledge, but perhaps is not or is
>>>>>>> incorrect...
>>>>>>> 
>>>>>>> Now I am trying to understand how this interacts with all the
>>>>>>> coordinate frames involved with the ITKv4 registration framework, and
>>>>>>> the composite transforms. Specifically the composite transform apply
>>>>>>> the transforms in "reverse order"[2]. As I understand that that means
>>>>>>> that the newest transform get applied first. So that transform
>>>>>>> parameters are being optimized in the images space not in the virtual
>>>>>>> domains we are working towards. Therefore the center of our transforms
>>>>>>> is still important as we composite transforms?
>>>>>>> 
>>>>>>> I hope I explained that clearly, a white board may really be needed....
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Brad
>>>>>>> 
>>>>>>> 
>>>>>>> [1]
>>>>>>> https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94
>>>>>>> 099d3519eb23bcc16c7cf015
>>>>>>> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>>>>>>> 
>>>>>>> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi Brad,
>>>>>>>> 
>>>>>>>> I apologize for the delayed response.  I?m still catching up on my
>>>>>>>> workload after moving to CA.  We might want to talk to Luis as it
>>>>>>>> was my understanding that the ?center? component of the linear
>>>>>>>> transforms might be a carry-over from all the ?Centered? transforms,
>>>>>>>> e.g.,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.htm
>>>>>>>> l
>>>>>>>> 
>>>>>>>> which, if I remember correctly, Luis said were somewhat sub optimally
>>>>>>>> conceived but this was such a long time ago that I might be completely
>>>>>>>> misremembering.  However, fixing the center for all transforms within
>>>>>>>> a composite transform is certainly not necessary within the specified
>>>>>>>> framework.  Rather, the matrix and offset are updated with the
>>>>>>>> ?Center?
>>>>>>>> being updated implicitly.
>>>>>>>> 
>>>>>>>> Nick
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp
>>>>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>>> 
>>>>>>>>> Hello,
>>>>>>>>> 
>>>>>>>>> There are a lot of transforms involved in the new registration
>>>>>>>>> framework.
>>>>>>>>> 
>>>>>>>>> I am trying to figure out what the implications for the fix
>>>>>>>>> parameters of the transform "Center" ( ie center of rotation/scaling
>>>>>>>>> ) are when combined with composite transforms and the
>>>>>>>>> fixed/moving/registration coordinate frames...
>>>>>>>>> 
>>>>>>>>> Based on how the transforms are composed it seems necessary to set
>>>>>>>>> the  fix "Center" for subsequent transformations. Additionally, I am
>>>>>>>>> unsure how one would "improve" ( poorly defined? ) the center for a
>>>>>>>>> subsequent transform ie Affine after a similarity...
>>>>>>>>> 
>>>>>>>>> Are there some documented guidance or figures to help with this
>>>>>>>>> issue?
>>>>>>>>> Do we have a comprehensive diagram of these transforms?
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Brad
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Powered by www.kitware.com
>>>>>>> 
>>>>>>> Visit other Kitware open-source projects at
>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>> 
>>>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>>>> http://kitware.com/products/protraining.php
>>>>>>> 
>>>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>>>> _______________________________________________
>>>>>>> Community mailing list
>>>>>>> Community at itk.org
>>>>>>> http://public.kitware.com/mailman/listinfo/community
>>>>> 
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>> 
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>> 
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://kitware.com/products/protraining.php
>>>>> 
>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>> 
>>>> 
>>>> 
>>>> ________________________________
>>>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>>>> ________________________________
>>> 
>>> <unknown.png><unknown.png><MultiStageImageRegistration1.cxx>
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140813/0addcf3a/attachment-0001.html>

From blowekamp at mail.nih.gov  Wed Aug 13 12:23:18 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 13 Aug 2014 11:23:18 -0500
Subject: [ITK-dev] [ITK] Optimizing composite transforms and center
	of	transform
In-Reply-To: <85D2068C-A0FC-46EE-8CF8-3F44CDB40E5D@mail.nih.gov>
References: <A76E0CCE-1303-4F0F-ADFC-FECD8CAFA023@mail.nih.gov>
 <1C9E74C7-FD25-45DB-AABB-87A6FD6F48AD@gmail.com>
 <AE65F8A6-9A8A-4EE6-A614-C9EE691FA4F4@mail.nih.gov>
 <CALzTN-R2pX8PdsJu6P-4_JZP3oJxqh=79pWnxXQaidcDtb7kgw@mail.gmail.com>
 <2A37CDEA-B4F3-4826-BAF8-D64D6C4A53F6@mail.nih.gov>
 <CFFD962C.871A8%hans-johnson@uiowa.edu>
 <EAA163371EE66741A63B092281D1F3FE1884ED74@itsnt444.iowa.uiowa.edu>
 <97C77D92-4BAD-4D90-912D-E2AB95D63E19@mail.nih.gov>
 <D005AFFD.6377%ali-ghayoor@uiowa.edu>
 <85D2068C-A0FC-46EE-8CF8-3F44CDB40E5D@mail.nih.gov>
Message-ID: <DEB2BC6C-1B55-4B37-9B4B-35702294B826@mail.nih.gov>

Nick,

Thanks you for working on the patch. It appears that I was incorrect with my proposed formula for propagating the center.

Hans, Ali, and myself have continued this discussion over the the last couple of days. After further experimentation with IPython notebooks and composite transform we developed a better test cases to interact with. This lead to the conclusion that the Center parameter is not an point in the moving image's domain, but a point in the fixed. Therefore the same center can be used for all composite affine transforms and it can more simply be just copied along. Here is the corrected statement:


For a Composite transformed defined as ?=T0(T1(x)) where ?:?fixed??moving then if C such that C??fixed is the correct center initialization for T0, then the correct center initialization for T1 is still C, as it is set in the in the domain ( not the range ) of the individual transforms.

And here is a link to a viewer of the revisited notebooks:

http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/UpdateCompositeTransformCenter/Transform%20Composition%20And%20Order.ipynb

Brad

On Aug 5, 2014, at 8:03 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Ali,
> 
> Glad to hear the registration iteration graphs where effective.
> 
> Yes, you are right you can initialize the parameters of the second stage affine registration. Specifically the Center. However, it not readily apparent ( no example, no filter/initializer ) how that center fixed parameter should be initialized. And the "CenteredTransformInitializer" is not the correct way.
> 
> For a Composite transformed defined as ?=T0(T1(x)) where ?:?fixed??moving then if C such that C??moving is the correct center initialization for T1, then the correct center initialization for T0 when in the composite transform is C?=T?10(C).
> 
> Cool pasting from the IPython Notebook with inline latex appears to have worked :)
> 
> While it is easy to do this with the MomentsCaluclator and manually doing the transform inverse, I think to make it more readily apparent and easier to use it should be available as a filter/initializer.
> 
> There are several things  that are done manually in the examples that I would think should be updated to use the latest filters and initializers. For example The BSplines are manually initialized instead of using the BSplineTransform Initializer[1]. Additionally,  conversion of BSpline to a deformation field[2], and the the upsampling of the BSpine[3], though that last one still looks like ITKv3 framework, so maybe it'll be updated to the adaptors with v4. However I am after simple functions for these common tasks for SimpleITK, so I have a bit different perspective then one who is OK with implementing a 50 line solution in C++ and being OK with the interface.
> 
> We'll discuss these initialization issue further this afternoon.
> 
> Brad
> 
> [1] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L215-L235
> [2] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration4.cxx#L401-L430
> [3] https://github.com/InsightSoftwareConsortium/ITK/blob/master/Examples/RegistrationITKv4/DeformableRegistration6.cxx#L273-L330
> 
> On Aug 4, 2014, at 11:56 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:
> 
>> Hello Brad,
>> 
>> It is an awesome way for demonstration, and thanks for verification of my example. It seems that this email is sent on Saturday, but unfortunately I got that this morning! And I should inspect the reason! 
>> Anyway, over the weekend I ran almost the same experiment in ITK and got close results to you.
>> 
>> Also, today I tried to make the registration process work when Affine Transform is used in a multi stage structure, and here is my suggestion:
>> 
>> I think we do not need to bother ourselves to think about a new optimizer or a new initializer for the composite transform since we can initialize the fixed parameters of each transform individually at the beginning of each stage.
>> 
>> Remember how we run a BSpline registration stage after some linear registrations. At the beginning of the BSpline stage, we should instantiate a BSpline transform object and define its fixed parameters (grid size, etc). Then, we pass this initialized transform to the registration filter using ?SetInitialTransform()?, yet we can initialize this stage by passing a composite transform, resultant from the previous stages, to the registration filter by ?SetMovingInitialTransform()?.
>> 
>> The same condition holds for all other transform types with fixed unoptimizable parameters like the center of rotation in our Affine transform case. Attachment file includes a multi stage registration example that I have created for the new software guide. In this example, we use a simple 2 stages registration process for a multi modal problem that moving image is misaligned from the fixed image by a translation shift and rotation. In registration process, a translation transform is followed by an affine transform. Also, an initial transform is used at the beginning.
>> 
>> If I do not set the center of the affine transform, the registration fails as you have shown in your Ipython example. However, if at the beginning of the second stage, I compute the geometrical center (or center of the mass) of the fixed image, and pass that to the affine transform using ?SetCenter()? or ?SetFixedParameters()?, the registration succeeds. Please take a quick look in the attached file that also includes lots of explanations. 
>> 
>> Therefore, we can follow the same procedure for all other transform types that their fixed parameters are important in the optimization, but those fixed parameters cannot be set explicitly inside a composite transform. Please let me know with you think about this.
>> 
>> Thank you,
>> Ali
>> 
>> 
>> From: Bradley Lowekamp <blowekamp at mail.nih.gov>
>> Date: Saturday, August 2, 2014 at 6:48 PM
>> To: Ali Ghayoor <ali-ghayoor at uiowa.edu>
>> Cc: Hans Johnson <hans-johnson at uiowa.edu>, Insight Developers List <insight-developers at public.kitware.com>
>> Subject: Re: [ITK-dev] [ITK] Optimizing composite transforms and center of transform
>> 
>> Hello Ali,
>> 
>> I created a notebook to try to demonstrate the problem you are describing:
>> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/blob/master/Importance%20of%20Center%20with%20Affine%20Registration.ipynb
>> 
>> If the center of an Affine transformation isn't correctly initialized then the optimization is not speedy or robust. I think it's best illustrated with these two graphs:
>> 
>> <unknown.png>
>> <unknown.png>
>> 
>> Notice that with the Center being the origin, all 1000 iterations are exhausted, and the metric is slowing decreasing. And this is with the translation path being around the length to 10. If the spacing was bigger or more offset from the origin the situation would be worse.
>> 
>> I don't think this is a bug with the registration framework. I think new initializers for composite transforms are needed, along with documentation how the 2 good ways to initialize the registration methods transforms.
>> 
>> 
>> Brad
>> 
>> On Aug 1, 2014, at 8:08 PM, Ghayoor, Ali <ali-ghayoor at uiowa.edu> wrote:
>> 
>>> Brad,
>>> 
>>> I have exactly the same issue. I wrote a simple registration program that is run in two stages:
>>> -Translation
>>> -Affine
>>> 
>>> My fixed and moving images are in 2D, and the moving image is created from the fixed image by
>>> rotation of 10 degree and translation of [13,17] in X and Y directions.
>>> 
>>> The first stage does a translation registration and the result transform is added to a composite transform
>>> that is used as the initial moving transform of the second stage.
>>> 
>>> After the registration the result transform of the second stage is also added to the composite transform
>>> to be used by the resampler.
>>> 
>>> I have printed the composite transform to the screen:
>>> 
>>> 2481: CompositeTransform (0x7fa359a18b00)
>>> 2481:   RTTI typeinfo:   itk::CompositeTransform<double, 2u>
>>> 2481:   Reference Count: 2
>>> 2481:   Modified Time: 20949
>>> 2481:   Debug: Off
>>> 2481:   Object Name: 
>>> 2481:   Observers: 
>>> 2481:     none
>>> 2481:   Transforms in queue, from begin to end:
>>> 2481:   >>>>>>>>>
>>> 2481:   TranslationTransform (0x7fa359a199b0)
>>> 2481:     RTTI typeinfo:   itk::TranslationTransform<double, 2u>
>>> 2481:     Reference Count: 7
>>> 2481:     Modified Time: 1648
>>> 2481:     Debug: Off
>>> 2481:     Object Name: 
>>> 2481:     Observers: 
>>> 2481:       none
>>> 2481:     Offset: [12.801, 15.8578]
>>> 2481:   >>>>>>>>>
>>> 2481:   AffineTransform (0x7fa359d095a0)
>>> 2481:     RTTI typeinfo:   itk::AffineTransform<double, 2u>
>>> 2481:     Reference Count: 5
>>> 2481:     Modified Time: 20946
>>> 2481:     Debug: Off
>>> 2481:     Object Name: 
>>> 2481:     Observers: 
>>> 2481:       none
>>> 2481:     Matrix: 
>>> 2481:       1.01593 -0.0100051 
>>> 2481:       -0.00835669 1.01113 
>>> 2481:     Offset: [-0.358829, -0.290093]
>>> 2481:     Center: [0, 0]
>>> 2481:     Translation: [-0.358829, -0.290093]
>>> 2481:     Inverse: 
>>> 2481:       0.984397 0.00974056 
>>> 2481:       0.00813575 0.989073 
>>> 2481:     Singular: 0
>>> 2481:   End of MultiTransform.
>>> 2481: <<<<<<<<<<
>>> 
>>> As it can be seen, the translation transform provides a good initialization since its offset (Offset: [12.801, 15.8578]) is close to the shift parameters.
>>> 
>>> However, the Affine transform fails to rotate the moving image since its Matrix is almost identity.
>>> Possible reason can be the improper Center of Affine transform that is fixed to [0,0], and not at geometrical center or center of mass.
>>> 
>>> To make sure that I have not made any crazy mistake in my example, I simulated my example parameters in ANTs, and ANTs returned
>>> the same results and failed to register the images!!
>>> 
>>>>>>>> ANTs command line <<<<<<<<<<<
>>> 
>>> PROGPATH=/scratch/ANTS/release-new/bin
>>> fi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainT1SliceBorder20.png
>>> mi=/scratch/ITK-softwareGuide/release/ITKv4/Examples/Data/BrainProtonDensitySliceR10X13Y17.png
>>> 
>>> time ${PROGPATH}/antsRegistration -d 2 \
>>> --float \
>>> --output [test1, warpedMoving.nii.gz] \
>>> --transform "Translation[16]" \
>>> --metric MI[${fi},${mi},1,32,None,1] \
>>> --convergence [100,1e-2,5] \
>>> --shrink-factors 3 \
>>> --smoothing-sigmas 2 \
>>> --use-histogram-matching 1 \
>>> \
>>> --transform "Affine[1]" \
>>> --metric MI[${fi},${mi},1,32] \
>>> --convergence [100x100,1e-2,2] \
>>> --shrink-factors 2x1 \
>>> --smoothing-sigmas 1x0 \
>>> --use-histogram-matching 1
>>> 
>>> <<<<<<<<<<<<<<<<<<<<<<<<
>>> 
>>> Fixed and moving images can be loaded from the ITK data files. What do you think about this example? Is it a bug in ITK or just the parameters are not tuned finely?
>>> 
>>> Thanks,
>>> Ali
>>> 
>>> ________________________________________
>>> From: Johnson, Hans J
>>> Sent: Tuesday, July 29, 2014 6:19 PM
>>> To: Ghayoor, Ali
>>> Subject: FW: [ITK-dev] [ITK] Optimizing composite transforms and center of transform
>>> 
>>> Ali,
>>> 
>>> You need to follow this discussion.
>>> 
>>> Hans
>>> 
>>> On 7/29/14, 6:16 PM, "Bradley Lowekamp" <blowekamp at mail.nih.gov> wrote:
>>> 
>>>> Hello,
>>>> 
>>>> Ok, to further explore this problem, and hopeful help other people too: I
>>>> created an IPython Notebook viewable here:
>>>> http://nbviewer.ipython.org/github/blowekamp/SimpleITK-Notebook-Answers/bl
>>>> ob/master/Transform%20Composition%20And%20Order.ipynb
>>>> 
>>>> It doesn't come through on the static page, but I added some nifty
>>>> interactive slider widgets to change the rotation parameter. Which is
>>>> really the point  to enable understanding of the parameters for the
>>>> transform and how they should be best optimized. The notebook should work
>>>> with SimpleITK >= 0.8 and IPython Notebooks 2.1. I'll encourage every one
>>>> to try it out :) IPython Notebooks widget are very cool!
>>>> 
>>>> EXPLANATION:
>>>> 
>>>> The the order of the composite transform is that the new transforms are
>>>> applied first.
>>>> 
>>>> BUT they map from the virtual domain ( fixed ) to the moving image.
>>>> Therefore if your first transform moves the center of mass to the origin
>>>> then the second added transform's space will be centered on the mass,
>>>> which is good for optimizing rotation and affine parameters.
>>>> 
>>>> QUESTION:
>>>> 
>>>> Therefore I am inclined to conclude that its best practices to map the
>>>> fixed and moving image to the virtual domain such that the center of mass
>>>> ( or some other "center feature" ) are at the origin. This would then the
>>>> scale, rotation and other affine parameters around the center, with out
>>>> having to used the "Center" parameter the transforms currently have.
>>>> 
>>>> Is this what others are doing in their registration? For general best
>>>> practices should this be recommend?
>>>> 
>>>> @Brian I know I have seen this multi-domain description many time, but I
>>>> think I may have just gotten it... Is the well describe in the literature
>>>> some place? I think this may be an important part add the software guide.
>>>> 
>>>> Thanks,
>>>> Brad
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Jul 29, 2014, at 5:38 PM, Matt McCormick <matt.mccormick at kitware.com>
>>>> wrote:
>>>> 
>>>>> Hi Brad,
>>>>> 
>>>>> Your assessment that the fixed center is important is correct.
>>>>> 
>>>>> In most cases, a transform with a Center is the first transform in a
>>>>> Composite transform. There not any issues here.  However, if the
>>>>> transform with a Center is further along the chain, then a
>>>>> CenteredTransformInitializer that was applied before the registration
>>>>> is started will not generate the desired result. In this case, we
>>>>> would have to respond to an Event in the registration process and
>>>>> estimated the center on the imaged after the other transforms have
>>>>> been applied. It is more work, but it is a more unusual case.
>>>>> 
>>>>> HTH,
>>>>> Matt
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Jul 28, 2014 at 10:11 PM, Bradley Lowekamp
>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>> Helloo Nick!
>>>>>> 
>>>>>> I am glad you got back to me.
>>>>>> 
>>>>>> I suspect that I have spent more time this past week looking at the
>>>>>> ITK affine transforms than anyone else[1] this week. With that here is
>>>>>> my current understanding...
>>>>>> 
>>>>>> 1) The CenterTransformInitializers estimates an initial "Center" and
>>>>>> an initial "Translation" parameter from either the geometry or the
>>>>>> first moments. From my problematic experiences, getting the initial
>>>>>> transform which is a "good" guess is been critical for the optimizer to
>>>>>> head to the correct solution.
>>>>>> 
>>>>>> 2) The Center parameter of a transform can either be "Fixed" or an
>>>>>> optimizable parameter. The transforms with the "Centered" monkier are
>>>>>> the the ones with the Center parameter optimizable. This issue seems to
>>>>>> be what you were referring to in to message.
>>>>>> 
>>>>>> In many ways the point I am trying to make is independent of #2. I
>>>>>> have observed that it's important to have the "Center" of an affine
>>>>>> transform ( or sub parameterization thereof ) at the center of the
>>>>>> object you are trying to register. That is the coordinate space of the
>>>>>> optimizable parameters' point 0 is near the center. This enables
>>>>>> rotation to easily rotate around the center, as well as scaling to
>>>>>> maintain the same relative center when "zooming". This issue is
>>>>>> independent of wether that center point can be optimized.
>>>>>> 
>>>>>> For example, consider changing the origin of an image for alignment by
>>>>>> say 500, and compensating with just an initial translation and not
>>>>>> setting the "Center" parameter. If we are trying to optimize rotation
>>>>>> and translation, then the optimization path would be very difficult to
>>>>>> traverse with these inter-dependent parameters to force it to rotate
>>>>>> around the center of the object. This scenario may be more common in
>>>>>> microscopy then medical imaging, due to microscopy frequently having
>>>>>> multiple subjects across large images. I could write up a IPython
>>>>>> Notebook to illustrate the case.
>>>>>> 
>>>>>> So that is my understanding of why using a fixed center is important.
>>>>>> I thought this may have been shared knowledge, but perhaps is not or is
>>>>>> incorrect...
>>>>>> 
>>>>>> Now I am trying to understand how this interacts with all the
>>>>>> coordinate frames involved with the ITKv4 registration framework, and
>>>>>> the composite transforms. Specifically the composite transform apply
>>>>>> the transforms in "reverse order"[2]. As I understand that that means
>>>>>> that the newest transform get applied first. So that transform
>>>>>> parameters are being optimized in the images space not in the virtual
>>>>>> domains we are working towards. Therefore the center of our transforms
>>>>>> is still important as we composite transforms?
>>>>>> 
>>>>>> I hope I explained that clearly, a white board may really be needed....
>>>>>> 
>>>>>> Thanks,
>>>>>> Brad
>>>>>> 
>>>>>> 
>>>>>> [1]
>>>>>> https://github.com/SimpleITK/SimpleITK/compare/master...9bc9bc8440e64d94
>>>>>> 099d3519eb23bcc16c7cf015
>>>>>> [2] http://www.itk.org/Doxygen/html/classitk_1_1CompositeTransform.html
>>>>>> 
>>>>>> On Jul 28, 2014, at 8:57 PM, Nicholas Tustison <ntustison at gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi Brad,
>>>>>>> 
>>>>>>> I apologize for the delayed response.  I?m still catching up on my
>>>>>>> workload after moving to CA.  We might want to talk to Luis as it
>>>>>>> was my understanding that the ?center? component of the linear
>>>>>>> transforms might be a carry-over from all the ?Centered? transforms,
>>>>>>> e.g.,
>>>>>>> 
>>>>>>> 
>>>>>>> http://www.itk.org/Doxygen/html/classitk_1_1CenteredAffineTransform.htm
>>>>>>> l
>>>>>>> 
>>>>>>> which, if I remember correctly, Luis said were somewhat sub optimally
>>>>>>> conceived but this was such a long time ago that I might be completely
>>>>>>> misremembering.  However, fixing the center for all transforms within
>>>>>>> a composite transform is certainly not necessary within the specified
>>>>>>> framework.  Rather, the matrix and offset are updated with the
>>>>>>> ?Center?
>>>>>>> being updated implicitly.
>>>>>>> 
>>>>>>> Nick
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Jul 24, 2014, at 7:27 AM, Bradley Lowekamp
>>>>>>> <blowekamp at mail.nih.gov> wrote:
>>>>>>> 
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> There are a lot of transforms involved in the new registration
>>>>>>>> framework.
>>>>>>>> 
>>>>>>>> I am trying to figure out what the implications for the fix
>>>>>>>> parameters of the transform "Center" ( ie center of rotation/scaling
>>>>>>>> ) are when combined with composite transforms and the
>>>>>>>> fixed/moving/registration coordinate frames...
>>>>>>>> 
>>>>>>>> Based on how the transforms are composed it seems necessary to set
>>>>>>>> the  fix "Center" for subsequent transformations. Additionally, I am
>>>>>>>> unsure how one would "improve" ( poorly defined? ) the center for a
>>>>>>>> subsequent transform ie Affine after a similarity...
>>>>>>>> 
>>>>>>>> Are there some documented guidance or figures to help with this
>>>>>>>> issue?
>>>>>>>> Do we have a comprehensive diagram of these transforms?
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Brad
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Powered by www.kitware.com
>>>>>> 
>>>>>> Visit other Kitware open-source projects at
>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>> 
>>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>>> http://kitware.com/products/protraining.php
>>>>>> 
>>>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>>>>> _______________________________________________
>>>>>> Community mailing list
>>>>>> Community at itk.org
>>>>>> http://public.kitware.com/mailman/listinfo/community
>>>> 
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> 
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> http://kitware.com/products/protraining.php
>>>> 
>>>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>> 
>>> 
>>> 
>>> ________________________________
>>> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
>>> ________________________________
>> 
>> <unknown.png><unknown.png><MultiStageImageRegistration1.cxx>
> 
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-developers
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140813/a26b276c/attachment-0001.html>

From matt.mccormick at kitware.com  Fri Aug 15 01:25:52 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Fri, 15 Aug 2014 01:25:52 -0400
Subject: [ITK-dev] [ITK] ITK Development Meeting
In-Reply-To: <5CB49492-605B-434E-BE5D-7F1B33F289CA@gmail.com>
References: <CALzTN-QjuNfa_x-UJQbitj=VOT2FOcQkbmq=ONSbWUTZT0icXw@mail.gmail.com>
 <09B4CD10-BCDE-4F28-BDB1-D3791E36BBD8@mail.nih.gov>
 <CADZJ4hMuGpKQvyumyw6qz8PrMqEKfLUtpfnSijdUprU7gNAhKg@mail.gmail.com>
 <913EF9B6-84A0-4BD3-A154-EBCFD92685E5@gmail.com>
 <CALzTN-SGcCYQuNNXsnJGdfmBbEkWmf7a6puCWKfsG+xhh25ZEA@mail.gmail.com>
 <5CB49492-605B-434E-BE5D-7F1B33F289CA@gmail.com>
Message-ID: <CALzTN-RHRsYWDObaPECfSYJ+15zdf2-hjPw+HReeGN_oCDDx6A@mail.gmail.com>

Follow-up:

Following feedback from last week, I have scheduled a Hangout for 11
AM  Eastern Time (GMT-4) for today, Friday 2014-08-15.


Here is the link:

 https://plus.google.com/u/1/events/cioior9b5k16e3uaqsjsa1km2t0?authkey=COiD36DYzNGxMg


For those that cannot join via Hangout, telephone call-in is also
possible.  Dial:

  585-632-6296

Enter pin:

  31423?

On Thu, Aug 7, 2014 at 3:50 PM, Michka Popoff <michkapopoff at gmail.com> wrote:
> Perfect, 3 PM for me :)
>
> Thanks
>
> On 7 ao?t 2014, at 21:19, Matt McCormick <matt.mccormick at kitware.com> wrote:
>
>> OK, let's do 9 AM Eastern Time Zone (GMT-4). :-)
>>
>> I created an Event here [1].
>>
>> If you are subscribed to the ITK Bar Camp Community [2], you should
>> already have received an invitation.
>>
>> Thanks,
>> Matt
>>
>> [1] https://plus.google.com/events/cauvj61hvr7kirg5g5vjsupt4pg
>>
>> [2] https://plus.google.com/communities/111375098792764998322
>>
>> On Thu, Aug 7, 2014 at 2:43 PM, Michka Popoff <michkapopoff at gmail.com> wrote:
>>> +1
>>>
>>> 9 AM, what timezone ? ;D
>>>
>>> On 7 ao?t 2014, at 20:24, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>>
>>>> +1
>>>>
>>>>
>>>> On Thu, Aug 7, 2014 at 2:23 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
>>>>> Hello,
>>>>>
>>>>> I am in favor of using Google Hangout as it appears to be more accessible to people and more seem to be able to join.
>>>>>
>>>>> Brad
>>>>>
>>>>> On Aug 7, 2014, at 2:20 PM, Matt McCormick <matt.mccormick at kitware.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Are we having the development meeting teleconference tomorrow?  If
>>>>>> not, would folks like to do a Google Hangout at 9 AM?
>>>>>>
>>>>>> On a positive side note, Google Hangout's no longer require a Google
>>>>>> Plus account [1], and it no longer requires plugins with Chrome/ium
>>>>>> [2].
>>>>>>
>>>>>> I am happy to see the Goog-Monster moving towards greater openness and
>>>>>> liberty.  Maybe the internal forces for good are becoming stronger
>>>>>> :-).
>>>>>>
>>>>>> Thanks,
>>>>>> Matt
>>>>>>
>>>>>> [1] http://techcrunch.com/2014/07/30/hangouts-now-works-without-google-account-becomes-part-of-google-apps-for-business-and-gets-sla/
>>>>>>
>>>>>> [2] http://www.omgchrome.com/google-hangouts-chrome-plugin-free-2/
>>>>>
>>>>> _______________________________________________
>>>>> Community mailing list
>>>>> Community at itk.org
>>>>> http://public.kitware.com/mailman/listinfo/community
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>>> _______________________________________________
>>>> Community mailing list
>>>> Community at itk.org
>>>> http://public.kitware.com/mailman/listinfo/community
>>>
>>> _______________________________________________
>>> Community mailing list
>>> Community at itk.org
>>> http://public.kitware.com/mailman/listinfo/community
>

From bill.lorensen at gmail.com  Fri Aug 15 14:59:42 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 15 Aug 2014 14:59:42 -0400
Subject: [ITK-dev] The patch you merged does not work
Message-ID: <CADZJ4hOa7Wcdw7ggBmskx39kZi3-TFG0MZ5mDOjkPMuFst7rCQ@mail.gmail.com>

Matt,

That patch does not work. http://review.source.kitware.com/#/c/16697/

I merged the original patch as a temporary fix. Now I'm not sure what
state we are in...

Bill

From bill.lorensen at gmail.com  Fri Aug 15 15:08:39 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 15 Aug 2014 15:08:39 -0400
Subject: [ITK-dev] The patch you merged does not work
In-Reply-To: <CADZJ4hOa7Wcdw7ggBmskx39kZi3-TFG0MZ5mDOjkPMuFst7rCQ@mail.gmail.com>
References: <CADZJ4hOa7Wcdw7ggBmskx39kZi3-TFG0MZ5mDOjkPMuFst7rCQ@mail.gmail.com>
Message-ID: <CADZJ4hPV++22ObCc-Ew-MVQreTb5oX7gz62O2sWivVHRG0W6gA@mail.gmail.com>

Ooops. Sorry. I think we are OK. Too many pathes/topics... We'll see tomorrow.

Bill


On Fri, Aug 15, 2014 at 2:59 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Matt,
>
> That patch does not work. http://review.source.kitware.com/#/c/16697/
>
> I merged the original patch as a temporary fix. Now I'm not sure what
> state we are in...
>
> Bill



-- 
Unpaid intern in BillsBasement at noware dot com

From matt.mccormick at kitware.com  Fri Aug 15 18:53:42 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Fri, 15 Aug 2014 18:53:42 -0400
Subject: [ITK-dev] The patch you merged does not work
In-Reply-To: <CADZJ4hPV++22ObCc-Ew-MVQreTb5oX7gz62O2sWivVHRG0W6gA@mail.gmail.com>
References: <CADZJ4hOa7Wcdw7ggBmskx39kZi3-TFG0MZ5mDOjkPMuFst7rCQ@mail.gmail.com>
 <CADZJ4hPV++22ObCc-Ew-MVQreTb5oX7gz62O2sWivVHRG0W6gA@mail.gmail.com>
Message-ID: <CALzTN-RCjgOuuNTiPjyYVmHNvffCMUPeSBZVhERV0fzZ+c4JLQ@mail.gmail.com>

Looking a bit closer at how the merge occurred, I think it will still
need more work. :-(

Here is another patch:

  http://review.source.kitware.com/#/c/16703

Thanks,
Matt

On Fri, Aug 15, 2014 at 3:08 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
> Ooops. Sorry. I think we are OK. Too many pathes/topics... We'll see tomorrow.
>
> Bill
>
>
> On Fri, Aug 15, 2014 at 2:59 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Matt,
>>
>> That patch does not work. http://review.source.kitware.com/#/c/16697/
>>
>> I merged the original patch as a temporary fix. Now I'm not sure what
>> state we are in...
>>
>> Bill
>
>
>
> --
> Unpaid intern in BillsBasement at noware dot com

From bill.lorensen at gmail.com  Fri Aug 15 19:17:33 2014
From: bill.lorensen at gmail.com (Bill Lorensen)
Date: Fri, 15 Aug 2014 19:17:33 -0400
Subject: [ITK-dev] The patch you merged does not work
In-Reply-To: <CALzTN-RCjgOuuNTiPjyYVmHNvffCMUPeSBZVhERV0fzZ+c4JLQ@mail.gmail.com>
References: <CADZJ4hOa7Wcdw7ggBmskx39kZi3-TFG0MZ5mDOjkPMuFst7rCQ@mail.gmail.com>
 <CADZJ4hPV++22ObCc-Ew-MVQreTb5oX7gz62O2sWivVHRG0W6gA@mail.gmail.com>
 <CALzTN-RCjgOuuNTiPjyYVmHNvffCMUPeSBZVhERV0fzZ+c4JLQ@mail.gmail.com>
Message-ID: <CADZJ4hPbq=z-hA9GnFQzQLTs7wH=Cz0wcLoUfjz+2OUJGqZ95g@mail.gmail.com>

master seems to be ok now?


On Fri, Aug 15, 2014 at 6:53 PM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> Looking a bit closer at how the merge occurred, I think it will still
> need more work. :-(
>
> Here is another patch:
>
>   http://review.source.kitware.com/#/c/16703
>
> Thanks,
> Matt
>
> On Fri, Aug 15, 2014 at 3:08 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Ooops. Sorry. I think we are OK. Too many pathes/topics... We'll see tomorrow.
>>
>> Bill
>>
>>
>> On Fri, Aug 15, 2014 at 2:59 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>>> Matt,
>>>
>>> That patch does not work. http://review.source.kitware.com/#/c/16697/
>>>
>>> I merged the original patch as a temporary fix. Now I'm not sure what
>>> state we are in...
>>>
>>> Bill
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

From yves.frederix+itk at gmail.com  Mon Aug 18 10:30:36 2014
From: yves.frederix+itk at gmail.com (Yves Frederix)
Date: Mon, 18 Aug 2014 16:30:36 +0200
Subject: [ITK-dev] Problem with itkPCAShapeSignedDistanceFunction in
 multithreaded environment when using a 'dense' solver
Message-ID: <CAFmT9kQ4OQPVe-2fSQVjThn0TynwAmn2goTt3aqydGjD_+3sAw@mail.gmail.com>

Hi all,

I am writing you with a crash I encountered while experimenting with
the GeodesicActiveContour  image filter with shape guidance. Although
I did not find the root cause of the problem, I did implement a small
change which might be a useful contribution.

Currently, the GeodesicActiveContourShapePriorLevelSetImageFilter is
based on a SparseField solver. For my application, this was not very
suitable and I implemented a version of this image filter based on a
dense solver. After doing this, however, I consistently experienced a
crash in the algorithm when more than one thread was used. After some
debugging, I tracked down the problem to
itkPCAShapeSignedDistanceFunction, which contains a smart pointer
member variable which caused the crash in the multithreaded run. In
particular, it seemed to me that the reference counting somehow got
confused, and things went wrong.
I did not feel comfortable enough to dig deeper into the root cause of
the problem, but I did do a simple fix to the
itkPCAShapeSignedDistanceFunction code that avoids the problem, which
I would like to share (see attach). Basically, I replaced the
problematic reference counting member variable by a raw pointer, so
that during iteration no reference counting takes place. In this
particular case, I think that this change does not impose any risks as
there is no issue with ownership or life time management.

I am unsure if this mailing list is the best or correct medium to
report this, so if not, please point me to the right direction. If
somebody would be interested in looking at the root cause of this
issue, I should be able to provide some code to reproduce the crash.
Just let me know.

Best regards,
Yves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix.patch
Type: application/octet-stream
Size: 2277 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140818/baed5118/attachment.obj>

From matt.mccormick at kitware.com  Thu Aug 21 17:54:56 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 21 Aug 2014 17:54:56 -0400
Subject: [ITK-dev] Friday gathering
Message-ID: <CALzTN-RiENMmYwR+7NMg7squ4esWbDc4PWxHtHFHfR=1rdSv5A@mail.gmail.com>

Hi,

I will not be able to host or attend the regular gathering tomorrow.
If someone is interested in hosting, please do so.

Thanks,
Matt

From matt.mccormick at kitware.com  Mon Aug 25 23:31:16 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Mon, 25 Aug 2014 23:31:16 -0400
Subject: [ITK-dev] [ITK] Problem with itkPCAShapeSignedDistanceFunction
 in multithreaded environment when using a 'dense' solver
In-Reply-To: <CAFmT9kQ4OQPVe-2fSQVjThn0TynwAmn2goTt3aqydGjD_+3sAw@mail.gmail.com>
References: <CAFmT9kQ4OQPVe-2fSQVjThn0TynwAmn2goTt3aqydGjD_+3sAw@mail.gmail.com>
Message-ID: <CALzTN-RJiERcYjnE2oXeHdVx+OoanH=NOtd=PTATvsmZC139Fg@mail.gmail.com>

Hi Yves,

Yes, your comments are very welcome.  Thank you for discussing this
issue with the list!

Regarding the issue described and the patch, I think it is a good
start.  As you not, the smart pointers are not very effective from an
efficiency perspect, and it would be fine to replace them by raw
pointer since there is no issue with ownership or life time
management.  However, the thread-safety is still an issue. Digging
into the code, it looks like the m_Selectors member in
PCAShapeSignedDistanceFunction can be removed altogether.  Please
review this patch:

  http://review.source.kitware.com/#/c/16824/

Thanks,
Matt

On Mon, Aug 18, 2014 at 10:30 AM, Yves Frederix
<yves.frederix+itk at gmail.com> wrote:
> Hi all,
>
> I am writing you with a crash I encountered while experimenting with
> the GeodesicActiveContour  image filter with shape guidance. Although
> I did not find the root cause of the problem, I did implement a small
> change which might be a useful contribution.
>
> Currently, the GeodesicActiveContourShapePriorLevelSetImageFilter is
> based on a SparseField solver. For my application, this was not very
> suitable and I implemented a version of this image filter based on a
> dense solver. After doing this, however, I consistently experienced a
> crash in the algorithm when more than one thread was used. After some
> debugging, I tracked down the problem to
> itkPCAShapeSignedDistanceFunction, which contains a smart pointer
> member variable which caused the crash in the multithreaded run. In
> particular, it seemed to me that the reference counting somehow got
> confused, and things went wrong.
> I did not feel comfortable enough to dig deeper into the root cause of
> the problem, but I did do a simple fix to the
> itkPCAShapeSignedDistanceFunction code that avoids the problem, which
> I would like to share (see attach). Basically, I replaced the
> problematic reference counting member variable by a raw pointer, so
> that during iteration no reference counting takes place. In this
> particular case, I think that this change does not impose any risks as
> there is no issue with ownership or life time management.
>
> I am unsure if this mailing list is the best or correct medium to
> report this, so if not, please point me to the right direction. If
> somebody would be interested in looking at the root cause of this
> issue, I should be able to provide some code to reproduce the crash.
> Just let me know.
>
> Best regards,
> Yves
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/mailman/listinfo/community
>

From yves.frederix+itk at gmail.com  Tue Aug 26 02:42:17 2014
From: yves.frederix+itk at gmail.com (Yves Frederix)
Date: Tue, 26 Aug 2014 08:42:17 +0200
Subject: [ITK-dev] [ITK] Problem with itkPCAShapeSignedDistanceFunction
 in multithreaded environment when using a 'dense' solver
In-Reply-To: <CALzTN-RJiERcYjnE2oXeHdVx+OoanH=NOtd=PTATvsmZC139Fg@mail.gmail.com>
References: <CAFmT9kQ4OQPVe-2fSQVjThn0TynwAmn2goTt3aqydGjD_+3sAw@mail.gmail.com>
 <CALzTN-RJiERcYjnE2oXeHdVx+OoanH=NOtd=PTATvsmZC139Fg@mail.gmail.com>
Message-ID: <CAFmT9kTFDa5owXkXMscZNXEs17=pKqR_SGxG0c+7+iMccU=rJA@mail.gmail.com>

Hi Matt,

You are right, the troublesome member variable can be removed
entirely, making your solution the correct fix. Thank you.

Best regards,
Yves


On Tue, Aug 26, 2014 at 5:31 AM, Matt McCormick
<matt.mccormick at kitware.com> wrote:
> Hi Yves,
>
> Yes, your comments are very welcome.  Thank you for discussing this
> issue with the list!
>
> Regarding the issue described and the patch, I think it is a good
> start.  As you not, the smart pointers are not very effective from an
> efficiency perspect, and it would be fine to replace them by raw
> pointer since there is no issue with ownership or life time
> management.  However, the thread-safety is still an issue. Digging
> into the code, it looks like the m_Selectors member in
> PCAShapeSignedDistanceFunction can be removed altogether.  Please
> review this patch:
>
>   http://review.source.kitware.com/#/c/16824/
>
> Thanks,
> Matt
>
> On Mon, Aug 18, 2014 at 10:30 AM, Yves Frederix
> <yves.frederix+itk at gmail.com> wrote:
>> Hi all,
>>
>> I am writing you with a crash I encountered while experimenting with
>> the GeodesicActiveContour  image filter with shape guidance. Although
>> I did not find the root cause of the problem, I did implement a small
>> change which might be a useful contribution.
>>
>> Currently, the GeodesicActiveContourShapePriorLevelSetImageFilter is
>> based on a SparseField solver. For my application, this was not very
>> suitable and I implemented a version of this image filter based on a
>> dense solver. After doing this, however, I consistently experienced a
>> crash in the algorithm when more than one thread was used. After some
>> debugging, I tracked down the problem to
>> itkPCAShapeSignedDistanceFunction, which contains a smart pointer
>> member variable which caused the crash in the multithreaded run. In
>> particular, it seemed to me that the reference counting somehow got
>> confused, and things went wrong.
>> I did not feel comfortable enough to dig deeper into the root cause of
>> the problem, but I did do a simple fix to the
>> itkPCAShapeSignedDistanceFunction code that avoids the problem, which
>> I would like to share (see attach). Basically, I replaced the
>> problematic reference counting member variable by a raw pointer, so
>> that during iteration no reference counting takes place. In this
>> particular case, I think that this change does not impose any risks as
>> there is no issue with ownership or life time management.
>>
>> I am unsure if this mailing list is the best or correct medium to
>> report this, so if not, please point me to the right direction. If
>> somebody would be interested in looking at the root cause of this
>> issue, I should be able to provide some code to reproduce the crash.
>> Just let me know.
>>
>> Best regards,
>> Yves
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>>
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>>
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/mailman/listinfo/community
>>

From joseignacio.prieto at gmail.com  Tue Aug 26 11:35:50 2014
From: joseignacio.prieto at gmail.com (Jose Ignacio Prieto)
Date: Tue, 26 Aug 2014 11:35:50 -0400
Subject: [ITK-dev] Create PolygonToMeshFilter
Message-ID: <CANkppu4z5KvydhVi_uM0dvO+ZgU4RzzrAXv-X6UaY2rsu3k+og@mail.gmail.com>

Hi all,
I am trying to create a filter that receives many 2D polygons in the form
of PolyLineParametricPath (which in turn has an itkImage as input) and
returns an itkMesh for later visualization. I have completed the
GenerateData() method by calling internally to
itkAutomaticTopologyMeshSource. The problem seems to be that before
GenerateData, the filter fails in itkPointSet::CopyInformation (because it
tries to cast the polygon as a mesh). I discovered that the call stack
comes from UpdateOutputInformation on my PolygonToMeshFilter and then
GenerateOutputInformation, then itkMesh::CopyInformation and
itkPointset::CopyInformation.
I think I should edit my PolygonToMesh::GenerateOutputInformation() but I
don't know how. Inside it I just called
Superclass::GenerateOutputInformation.
My filter PolygonToMeshFilter is a copy of MeshToMesh filter and inherits
from MeshSource. Maybe I should inherit from anothe filter.
Thank you very much

Ignacio Prieto

--
Ignacio Prieto
Research Assistant
Biomedical Imaging Center
Pontificia Universidad Catolica de Chile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140826/b952893b/attachment.html>

From joseignacio.prieto at gmail.com  Tue Aug 26 11:56:27 2014
From: joseignacio.prieto at gmail.com (Jose Ignacio Prieto)
Date: Tue, 26 Aug 2014 11:56:27 -0400
Subject: [ITK-dev] Create PolygonToMeshFilter
In-Reply-To: <CANkppu4z5KvydhVi_uM0dvO+ZgU4RzzrAXv-X6UaY2rsu3k+og@mail.gmail.com>
References: <CANkppu4z5KvydhVi_uM0dvO+ZgU4RzzrAXv-X6UaY2rsu3k+og@mail.gmail.com>
Message-ID: <CANkppu5xKnqsYhPJanoG6t4xqDhPXm11sYUyZVuiSTjr+oGXoA@mail.gmail.com>

I solved it partially but don't know why it works. I just set
GenerateOutputInformation(){} on my .h file as it is done on
itkSpatialObjecToPointSetFilter so it goes straight to
GenerateInputRequestedRegion.



On Tue, Aug 26, 2014 at 11:35 AM, Jose Ignacio Prieto <
joseignacio.prieto at gmail.com> wrote:

> Hi all,
> I am trying to create a filter that receives many 2D polygons in the form
> of PolyLineParametricPath (which in turn has an itkImage as input) and
> returns an itkMesh for later visualization. I have completed the
> GenerateData() method by calling internally to
> itkAutomaticTopologyMeshSource. The problem seems to be that before
> GenerateData, the filter fails in itkPointSet::CopyInformation (because it
> tries to cast the polygon as a mesh). I discovered that the call stack
> comes from UpdateOutputInformation on my PolygonToMeshFilter and then
> GenerateOutputInformation, then itkMesh::CopyInformation and
> itkPointset::CopyInformation.
> I think I should edit my PolygonToMesh::GenerateOutputInformation() but I
> don't know how. Inside it I just called
> Superclass::GenerateOutputInformation.
> My filter PolygonToMeshFilter is a copy of MeshToMesh filter and inherits
> from MeshSource. Maybe I should inherit from anothe filter.
> Thank you very much
>
> Ignacio Prieto
>
> --
> Ignacio Prieto
> Research Assistant
> Biomedical Imaging Center
> Pontificia Universidad Catolica de Chile
>



-- 
Jos? Ignacio Prieto
celular(nuevo): 94348182
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140826/228e2a06/attachment.html>

From blowekamp at mail.nih.gov  Wed Aug 27 09:52:20 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 27 Aug 2014 09:52:20 -0400
Subject: [ITK-dev] System PNG sCal issue
Message-ID: <060332A9-7A8F-4E15-B9AF-BCB308A597DD@mail.nih.gov>

Kent,

I am getting a failing test when using a new system PNG. It appears to be related to this issue:

https://issues.itk.org/jira/browse/ITK-3067

and commit:

https://github.com/InsightSoftwareConsortium/ITK/commit/74b5e6e4bbcbebcee860dd7b52ed76a4941c9efe

I have just upgraded my system to redhat7 and I now have libpng 1.5.13.

Here is the build on the dashboard:

http://open.cdash.org/buildSummary.php?buildid=3465169

There are compiler warnings related to unused variables, and then the failing test has sCal warnings. So I am assuming the failing test is due to sCal issue. As I am diving into the libPNG API and its changes, I thought I'd post up to case someone knows more about this issue.

Thanks,
Brtad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140827/ef5dff15/attachment.html>

From blowekamp at mail.nih.gov  Wed Aug 27 10:35:54 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 27 Aug 2014 10:35:54 -0400
Subject: [ITK-dev] System PNG sCal issue
In-Reply-To: <060332A9-7A8F-4E15-B9AF-BCB308A597DD@mail.nih.gov>
References: <060332A9-7A8F-4E15-B9AF-BCB308A597DD@mail.nih.gov>
Message-ID: <E5219AC4-B415-4E0E-ABF1-7530FE6D6BC3@mail.nih.gov>

It looks this there was also a discussion about this on the user mailing list to with a proposed patch:
http://public.kitware.com/pipermail/insight-users/2012-December/046756.html

Anyone know the state of this?

Brad

On Aug 27, 2014, at 9:52 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:

> Kent,
> 
> I am getting a failing test when using a new system PNG. It appears to be related to this issue:
> 
> https://issues.itk.org/jira/browse/ITK-3067
> 
> and commit:
> 
> https://github.com/InsightSoftwareConsortium/ITK/commit/74b5e6e4bbcbebcee860dd7b52ed76a4941c9efe
> 
> I have just upgraded my system to redhat7 and I now have libpng 1.5.13.
> 
> Here is the build on the dashboard:
> 
> http://open.cdash.org/buildSummary.php?buildid=3465169
> 
> There are compiler warnings related to unused variables, and then the failing test has sCal warnings. So I am assuming the failing test is due to sCal issue. As I am diving into the libPNG API and its changes, I thought I'd post up to case someone knows more about this issue.
> 
> Thanks,
> Brtad
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
> 
> 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://public.kitware.com/mailman/listinfo/insight-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140827/38baff7b/attachment.html>

From matt.mccormick at kitware.com  Wed Aug 27 10:56:38 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 27 Aug 2014 10:56:38 -0400
Subject: [ITK-dev] System PNG sCal issue
In-Reply-To: <E5219AC4-B415-4E0E-ABF1-7530FE6D6BC3@mail.nih.gov>
References: <060332A9-7A8F-4E15-B9AF-BCB308A597DD@mail.nih.gov>
 <E5219AC4-B415-4E0E-ABF1-7530FE6D6BC3@mail.nih.gov>
Message-ID: <CALzTN-T=XbCsegt=A2BSDk75BRXb7vVJqVQVN+BAca=NxVM2Cw@mail.gmail.com>

Here is the patch in Gerrit:

  http://review.source.kitware.com/#/c/8884/

HTH,
Matt

On Wed, Aug 27, 2014 at 10:35 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> It looks this there was also a discussion about this on the user mailing
> list to with a proposed patch:
> http://public.kitware.com/pipermail/insight-users/2012-December/046756.html
>
> Anyone know the state of this?
>
> Brad
>
> On Aug 27, 2014, at 9:52 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
> wrote:
>
> Kent,
>
> I am getting a failing test when using a new system PNG. It appears to be
> related to this issue:
>
> https://issues.itk.org/jira/browse/ITK-3067
>
> and commit:
>
> https://github.com/InsightSoftwareConsortium/ITK/commit/74b5e6e4bbcbebcee860dd7b52ed76a4941c9efe
>
> I have just upgraded my system to redhat7 and I now have libpng 1.5.13.
>
> Here is the build on the dashboard:
>
> http://open.cdash.org/buildSummary.php?buildid=3465169
>
> There are compiler warnings related to unused variables, and then the
> failing test has sCal warnings. So I am assuming the failing test is due to
> sCal issue. As I am diving into the libPNG API and its changes, I thought
> I'd post up to case someone knows more about this issue.
>
> Thanks,
> Brtad
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>

From blowekamp at mail.nih.gov  Wed Aug 27 11:06:41 2014
From: blowekamp at mail.nih.gov (Bradley Lowekamp)
Date: Wed, 27 Aug 2014 11:06:41 -0400
Subject: [ITK-dev] System PNG sCal issue
In-Reply-To: <CALzTN-T=XbCsegt=A2BSDk75BRXb7vVJqVQVN+BAca=NxVM2Cw@mail.gmail.com>
References: <060332A9-7A8F-4E15-B9AF-BCB308A597DD@mail.nih.gov>
 <E5219AC4-B415-4E0E-ABF1-7530FE6D6BC3@mail.nih.gov>
 <CALzTN-T=XbCsegt=A2BSDk75BRXb7vVJqVQVN+BAca=NxVM2Cw@mail.gmail.com>
Message-ID: <D8E52C92-9360-4842-86B1-FA1001B7F09F@mail.nih.gov>

Great! That is what I was looking for and why I kept thinking I have seen this issue around...

Not sure what the real issue is... maybe the png file in the test in invalid, and the lib png change the behavior for this case.... I just don't know yet.

I did determine that the spacing of the output put image for this system in 1, while the passing tests have 0.25. So this is the right problem... just need to figure out where the behavior is going wrong.

Brad

On Aug 27, 2014, at 10:56 AM, Matt McCormick <matt.mccormick at kitware.com> wrote:

> Here is the patch in Gerrit:
> 
>  http://review.source.kitware.com/#/c/8884/
> 
> HTH,
> Matt
> 
> On Wed, Aug 27, 2014 at 10:35 AM, Bradley Lowekamp
> <blowekamp at mail.nih.gov> wrote:
>> It looks this there was also a discussion about this on the user mailing
>> list to with a proposed patch:
>> http://public.kitware.com/pipermail/insight-users/2012-December/046756.html
>> 
>> Anyone know the state of this?
>> 
>> Brad
>> 
>> On Aug 27, 2014, at 9:52 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
>> wrote:
>> 
>> Kent,
>> 
>> I am getting a failing test when using a new system PNG. It appears to be
>> related to this issue:
>> 
>> https://issues.itk.org/jira/browse/ITK-3067
>> 
>> and commit:
>> 
>> https://github.com/InsightSoftwareConsortium/ITK/commit/74b5e6e4bbcbebcee860dd7b52ed76a4941c9efe
>> 
>> I have just upgraded my system to redhat7 and I now have libpng 1.5.13.
>> 
>> Here is the build on the dashboard:
>> 
>> http://open.cdash.org/buildSummary.php?buildid=3465169
>> 
>> There are compiler warnings related to unused variables, and then the
>> failing test has sCal warnings. So I am assuming the failing test is due to
>> sCal issue. As I am diving into the libPNG API and its changes, I thought
>> I'd post up to case someone knows more about this issue.
>> 
>> Thanks,
>> Brtad
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>> 
>> 
>> 
>> _______________________________________________
>> Powered by www.kitware.com
>> 
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>> 
>> Kitware offers ITK Training Courses, for more information visit:
>> http://kitware.com/products/protraining.php
>> 
>> 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://public.kitware.com/mailman/listinfo/insight-developers
>> 


From matt.mccormick at kitware.com  Wed Aug 27 13:30:56 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Wed, 27 Aug 2014 13:30:56 -0400
Subject: [ITK-dev] Opportunities to share, discuss, design,
 and learn with other ITK community members
Message-ID: <CALzTN-R3iUdTM7DaEc9xr0Nr_dNUh_jk0yKF6E-cQa8rNPXy4A@mail.gmail.com>

There are a couple of upcoming opportunities to share, discuss,
design, and learn with your fellow
ITK community members.


On Thursday (tomorow), 9 AM Eastern USA time, there will be a Google+ Hangout
where we will be doing code reviews:

  https://plus.google.com/u/0/events/cj4tf2heirsligiim1blh9j3498


On Friday, 10 AM Eastern USA time, an ITK development teleconference,

  (866) 546-4138 USA or
  +1 (404) 602-0798 International
  Access code 5687046#


All are welcome.  Hope to talk to you then!

From mohammedrashadkm at gmail.com  Thu Aug 28 04:48:44 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Thu, 28 Aug 2014 10:48:44 +0200
Subject: [ITK-dev] System PNG sCal issue
In-Reply-To: <D8E52C92-9360-4842-86B1-FA1001B7F09F@mail.nih.gov>
References: <060332A9-7A8F-4E15-B9AF-BCB308A597DD@mail.nih.gov>
 <E5219AC4-B415-4E0E-ABF1-7530FE6D6BC3@mail.nih.gov>
 <CALzTN-T=XbCsegt=A2BSDk75BRXb7vVJqVQVN+BAca=NxVM2Cw@mail.gmail.com>
 <D8E52C92-9360-4842-86B1-FA1001B7F09F@mail.nih.gov>
Message-ID: <CANNqv9cUT3q2ORtQGvOBp69gTKRNuzopNEM5W1hHYaTLYTnJ6w@mail.gmail.com>

Hello,

Here is another related issuse regarding png sCal. -
http://public.kitware.com/pipermail/insight-developers/2014-July/023918.html


On Wed, Aug 27, 2014 at 5:06 PM, Bradley Lowekamp <blowekamp at mail.nih.gov>
wrote:

> Great! That is what I was looking for and why I kept thinking I have seen
> this issue around...
>
> Not sure what the real issue is... maybe the png file in the test in
> invalid, and the lib png change the behavior for this case.... I just don't
> know yet.
>
> I did determine that the spacing of the output put image for this system
> in 1, while the passing tests have 0.25. So this is the right problem...
> just need to figure out where the behavior is going wrong.
>
> Brad
>
> On Aug 27, 2014, at 10:56 AM, Matt McCormick <matt.mccormick at kitware.com>
> wrote:
>
> > Here is the patch in Gerrit:
> >
> >  http://review.source.kitware.com/#/c/8884/
> >
> > HTH,
> > Matt
> >
> > On Wed, Aug 27, 2014 at 10:35 AM, Bradley Lowekamp
> > <blowekamp at mail.nih.gov> wrote:
> >> It looks this there was also a discussion about this on the user mailing
> >> list to with a proposed patch:
> >>
> http://public.kitware.com/pipermail/insight-users/2012-December/046756.html
> >>
> >> Anyone know the state of this?
> >>
> >> Brad
> >>
> >> On Aug 27, 2014, at 9:52 AM, Bradley Lowekamp <blowekamp at mail.nih.gov>
> >> wrote:
> >>
> >> Kent,
> >>
> >> I am getting a failing test when using a new system PNG. It appears to
> be
> >> related to this issue:
> >>
> >> https://issues.itk.org/jira/browse/ITK-3067
> >>
> >> and commit:
> >>
> >>
> https://github.com/InsightSoftwareConsortium/ITK/commit/74b5e6e4bbcbebcee860dd7b52ed76a4941c9efe
> >>
> >> I have just upgraded my system to redhat7 and I now have libpng 1.5.13.
> >>
> >> Here is the build on the dashboard:
> >>
> >> http://open.cdash.org/buildSummary.php?buildid=3465169
> >>
> >> There are compiler warnings related to unused variables, and then the
> >> failing test has sCal warnings. So I am assuming the failing test is
> due to
> >> sCal issue. As I am diving into the libPNG API and its changes, I
> thought
> >> I'd post up to case someone knows more about this issue.
> >>
> >> Thanks,
> >> Brtad
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Kitware offers ITK Training Courses, for more information visit:
> >> http://kitware.com/products/protraining.php
> >>
> >> 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://public.kitware.com/mailman/listinfo/insight-developers
> >>
> >>
> >>
> >> _______________________________________________
> >> Powered by www.kitware.com
> >>
> >> Visit other Kitware open-source projects at
> >> http://www.kitware.com/opensource/opensource.html
> >>
> >> Kitware offers ITK Training Courses, for more information visit:
> >> http://kitware.com/products/protraining.php
> >>
> >> 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://public.kitware.com/mailman/listinfo/insight-developers
> >>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>



-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140828/c4875c1f/attachment.html>

From hans-johnson at uiowa.edu  Thu Aug 28 14:37:29 2014
From: hans-johnson at uiowa.edu (Johnson, Hans J)
Date: Thu, 28 Aug 2014 18:37:29 +0000
Subject: [ITK-dev] issues.itk.org maintenance
Message-ID: <D024E0AE.B1FF%hans-johnson@uiowa.edu>

The ITK bug tracker will be down for approximately 30 minutes at 4:30CST today for routine maintenance.

Hans



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140828/5d2dcb34/attachment.html>

From matt.mccormick at kitware.com  Thu Aug 28 22:35:03 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Thu, 28 Aug 2014 22:35:03 -0400
Subject: [ITK-dev] Create PolygonToMeshFilter
In-Reply-To: <CANkppu5xKnqsYhPJanoG6t4xqDhPXm11sYUyZVuiSTjr+oGXoA@mail.gmail.com>
References: <CANkppu4z5KvydhVi_uM0dvO+ZgU4RzzrAXv-X6UaY2rsu3k+og@mail.gmail.com>
 <CANkppu5xKnqsYhPJanoG6t4xqDhPXm11sYUyZVuiSTjr+oGXoA@mail.gmail.com>
Message-ID: <CALzTN-R8dDD8u1RkXowL9zi+iUoiizhECDH8nUYqw5kNJQMadw@mail.gmail.com>

Hi Ignacio,

The default implementation of GenerateOutputInformation() in
itk::ProcessObject is to call ::CopyInformation() on all the pipeline
objects from the input to the output DataObjects.  The information
that is copied for itk::PointSet / itk::Mesh is related to Region's
(see their implementations of ::CopyInformation()).  You may write a
GenerateOutputInformation() that sets these regions, or you could
leave the default values given in the constructors, which is what the
SpatialObjectToPointSetFilter does.

Hope this helps,
Matt

On Tue, Aug 26, 2014 at 11:56 AM, Jose Ignacio Prieto
<joseignacio.prieto at gmail.com> wrote:
> I solved it partially but don't know why it works. I just set
> GenerateOutputInformation(){} on my .h file as it is done on
> itkSpatialObjecToPointSetFilter so it goes straight to
> GenerateInputRequestedRegion.
>
>
>
> On Tue, Aug 26, 2014 at 11:35 AM, Jose Ignacio Prieto
> <joseignacio.prieto at gmail.com> wrote:
>>
>> Hi all,
>> I am trying to create a filter that receives many 2D polygons in the form
>> of PolyLineParametricPath (which in turn has an itkImage as input) and
>> returns an itkMesh for later visualization. I have completed the
>> GenerateData() method by calling internally to
>> itkAutomaticTopologyMeshSource. The problem seems to be that before
>> GenerateData, the filter fails in itkPointSet::CopyInformation (because it
>> tries to cast the polygon as a mesh). I discovered that the call stack comes
>> from UpdateOutputInformation on my PolygonToMeshFilter and then
>> GenerateOutputInformation, then itkMesh::CopyInformation and
>> itkPointset::CopyInformation.
>> I think I should edit my PolygonToMesh::GenerateOutputInformation() but I
>> don't know how. Inside it I just called
>> Superclass::GenerateOutputInformation.
>> My filter PolygonToMeshFilter is a copy of MeshToMesh filter and inherits
>> from MeshSource. Maybe I should inherit from anothe filter.
>> Thank you very much
>>
>> Ignacio Prieto
>>
>> --
>> Ignacio Prieto
>> Research Assistant
>> Biomedical Imaging Center
>> Pontificia Universidad Catolica de Chile
>
>
>
>
> --
> Jos? Ignacio Prieto
> celular(nuevo): 94348182
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>

From mohammedrashadkm at gmail.com  Sun Aug 31 01:28:21 2014
From: mohammedrashadkm at gmail.com (Rashad M)
Date: Sun, 31 Aug 2014 10:58:21 +0530
Subject: [ITK-dev] ITKVideo module
Message-ID: <CANNqv9eQkVRvtA5JcwtOPDx1HPhvuMt8qnC=ZyjdWuSnZ4q8qg@mail.gmail.com>

Hi all,

I have trying to process a video from UAV along with a GPS data to try
generate a stream in KLV[1] format. So far I had found[2],[3], [4]. The
github.io page gives an sample code and a demo video which looks great!

So I would to know if there is more examples as with other ITK modules?
Using OpenCV bridge is it possible to have a mix of algorithms in opencv
and itk?

[1] http://en.wikipedia.org/wiki/KLV
 [2] http://www.itk.org/Wiki/ITK_Release_4/Video
[3] http://www.itk.org/Wiki/ITK_Release_4/Video/HowToBuildVideoModules
[4]
http://insightsoftwareconsortium.github.io/ITKBarCamp-doc/ITK/VideoProcessingUsingOpenCVBridge/index.html


-- 
Regards,
   Rashad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/insight-developers/attachments/20140831/1cc0db5c/attachment-0001.html>

From matt.mccormick at kitware.com  Sun Aug 31 08:09:14 2014
From: matt.mccormick at kitware.com (Matt McCormick)
Date: Sun, 31 Aug 2014 08:09:14 -0400
Subject: [ITK-dev] ITKVideo module
In-Reply-To: <CANNqv9eQkVRvtA5JcwtOPDx1HPhvuMt8qnC=ZyjdWuSnZ4q8qg@mail.gmail.com>
References: <CANNqv9eQkVRvtA5JcwtOPDx1HPhvuMt8qnC=ZyjdWuSnZ4q8qg@mail.gmail.com>
Message-ID: <CALzTN-QkwPO29fPFJ5diBCWK+BWLbWGWY6PP4u8TT+ZdfstoBQ@mail.gmail.com>

Hi Rashad,

Here is one more example that shows how to work with ITK-OpenCV [1].

HTH,
Matt

[1] http://itk.org/ITKExamples/src/Video/BridgeOpenCV/ConvertAnITKGrayScaleImageToCVMat/Documentation.html

On Sun, Aug 31, 2014 at 1:28 AM, Rashad M <mohammedrashadkm at gmail.com> wrote:
> Hi all,
>
> I have trying to process a video from UAV along with a GPS data to try
> generate a stream in KLV[1] format. So far I had found[2],[3], [4]. The
> github.io page gives an sample code and a demo video which looks great!
>
> So I would to know if there is more examples as with other ITK modules?
> Using OpenCV bridge is it possible to have a mix of algorithms in opencv and
> itk?
>
> [1] http://en.wikipedia.org/wiki/KLV
> [2] http://www.itk.org/Wiki/ITK_Release_4/Video
> [3] http://www.itk.org/Wiki/ITK_Release_4/Video/HowToBuildVideoModules
> [4]
> http://insightsoftwareconsortium.github.io/ITKBarCamp-doc/ITK/VideoProcessingUsingOpenCVBridge/index.html
>
>
> --
> Regards,
>    Rashad
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.php
>
> 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://public.kitware.com/mailman/listinfo/insight-developers
>