[Insight-users] The Insight Journal-New Submission

[Luis Ibanez]

Just to complement Dan's detailed explanation:

Note however that after Jim introduced the DataObject decorators, the 
itkImageRegistrationMethod was made derive from the itkProcesss, and
a GenerateData() and GetOutput() methods were added (around April 2004).

Therefore, the itkImageRegistrationMethod is now a pipeline object.

The call
            registrationMethod->Update()

now triggers the registration process, including the update of the
source filters that provide the Fixed and Moving images.

and the call

            registrationMethod->GetOutput()

returns an ObjectDecorator containing a Transform.


Most of the examples don't use it as such, except for

    Insight/Examples/Registration/ImageRegistration1.cxx



    Luis



--------------------------------------------
Blezek, Daniel J (GE, Research) wrote:
> Hi Steve,
> 
>   I to am looking forward to Stephen's optimizations.
> 
>   The registration framework is "independent" of the pipeline, more because it is not demand driven, i.e. you call ->StartRegistration() on a registration algorithm object.  The inputs are updated via the pipeline.  The product of registration is a transform which has no concept of the pipeline, so you have to use the transform to drive a resampling process.  So  a basic registration program would read images then register as the first step, then grab the transform and resample as the second step.  This sort of breaks the pipeline concept.
> 
> Regards,
> -dan
> 
> -----Original Message-----
> From: insight-users-bounces+blezek=crd.ge.com at itk.org [mailto:insight-users-bounces+blezek=crd.ge.com at itk.org] On Behalf Of Steve M. Robbins
> Sent: Monday, July 16, 2007 11:32 AM
> To: insight-users at itk.org
> Subject: Re: [Insight-users] The Insight Journal-New Submission
> 
> On Mon, Jul 16, 2007 at 10:57:36AM -0400, Insight Journal wrote:
> 
> 
>>Abstract: 
>>This document describes work-in-progress for refactoring ITK’s 
>>registration methods to exploit the parallel, computation power of 
>>multi-processor, shared-memory systems.  Refactoring includes making 
>>the methods multi-threaded as well as optimizing the algorithms.
>>API backward compatibility is being maintained.  Helper classes that 
>>solve common registration tasks are also being developed.
> 
> 
> Very cool.  I'm looking forward to the complete article.
> 
> One line in the text caught my eye:
> 
>     Regarding multi-threading, while ITK's execution pipeline for
>     filters was designed to support multi-threading, ITK's
>     registration framework operates independently of the filter
>     pipeline and is not multi-threaded.
> 
> In what sense is the registration framework "independent" of the filter pipeline?  I had assumed that the registration was implemented using standard ITK filters and the registration driver was simply calling Update() on the tail.  That would use the standard pipeline framework as long as the individual filters are multi-threaded, wouldn't it?  Is my assumption wrong?
> 
> Thanks,
> -Steve
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users