[Insight-users] The Insight Journal-New Submission

[Blezek, Daniel J (GE, Research)]

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