[Insight-developers] The Insight Journal-New Submission

[Stephen R. Aylward]

Hi,

I think we have many options.  We probably should have a default sampler 
that does a uniform random (potentially masked) sub-sampling - the user 
could optionally override.

Regarding Luis' suggestion that our image-to-image metrics become 
pointset-to-image metrics - my concern is efficiency of storage and 
efficiency of processing.  In the ideal world, our bspline metric should 
realize if every pixel in the image is going to be processed, and in 
that situation, only a subset of the bspline basis (the x-direction 
component) needs to be recomputed when moving to the next pixel in the 
x-direction.  I haven't had time to implement this - it could still be 
implemented if we did things as pointset-to-image metrics, but it would 
require some additional trickery.   Note that the motivating case is 
when someone uses a very dense collection of bspline control points - as 
happens in some people's hierarchical registration tasks.

Right now we essentially have two registration metric implementations - 
SpatialObject-to-Image and Image-to-Image metrics.   I guess also in the 
ideal world we should have the image-to-image metrics as a special case 
of the spatialObject-to-image metrics - and I've always argued that an 
image should be a special case of a spatial object at the base level of 
the itk toolkit...but that is for some future generation of itk.   I 
don't think refactoring at that level is appropriate for the current ITK 
toolkit.

Okay - back to the paper...

Stephen

Marius Staring wrote:
> Hi Stephen,
> 
> Thanks for your enthusiastic response!
> 
> Just a thought: if you decide to incorporate the ImageSampler into the 
> ImageToImageMetric, then maybe the SampleFixedImageDomain() function 
> becomes superfluous. Otherwise you have the same functionality 
> implemented twice. Do you agree?
> 
> Also, the SetFixedImageIndexes() functionality could also be implemented 
> by means of an ImageSampler, e.g. via a UserDefinedIndicesImageSampler.
> 
> Stefan and Marius
> 
> Stephen R. Aylward wrote:
>> Hi Marius and Stefan,
>>
>> Thanks for the feedback!
>>
>> The new image-to-image-metric class (in addition to optionally 
>> providing a uniformly distributed, potentially masked, subsampling of 
>> the fixed image for metric computation) also allows a user to pass-in 
>> a list of fixed-image points to be used in computing the metric.  If 
>> we use the same data structure for the point list as you use in your 
>> subsamplers -  our classes should be partially compatible with what 
>> you've done.  The question is, should we also allow your sampler class 
>> to be plugged-in.  I think so - the user can then have the freedom to 
>> specify that re-sampling should occur every N iterations, etc.
>>
>> We (particularly Luis) are still working on the optimizations at a 
>> furious pace.   Once the code settles a bit, we can give you cvs write 
>> access to integrate your code.   I think your modification deserve to 
>> be at the top level instead of in a derived class - it is a good idea!
>>
>> The top-level metric code does check for when it is being used with 
>> bsplines transforms and bspline interpolators and provides appropriate 
>> general optimizations.  Also, the class has member variables that are 
>> bools that specify if the transform or interpolator are the bsplines 
>> versions - so derived classes can also perform related optimizations. 
>> Great minds think alike :)
>>
>> Sorry for not completing the paper yet - been traveling for three 
>> weeks...family staying with me for the summer...my dog ate my 
>> laptop... I should have the final paper uploaded today/tomorrow.
>>
>> Stephen
>>
>> Marius Staring wrote:
>>> Hi all,
>>>
>>> The refactoring of the registration framework is a very nice initiative.
>>>
>>> We have a few remarks/suggestions:
>>>
>>> 1. From the powerpoint presentation in the Insight journal we noticed 
>>> that the new OptImageToImageMetric now includes the functionality to 
>>> sample the fixed image, like the MattesMutualInformation used to do 
>>> already. We have implemented something similar. You may be interested 
>>> to inspect our implementation. We have tried to seperate the sampling 
>>> functionality from the ImageToImageMetric, by designing a set of 
>>> filters that accept an image as input and return a vector containing 
>>> the samples as output (in a so-called itk::VectorDataContainer). For 
>>> this purpose we wrote a base class, the itk::ImageSamplerBase, from 
>>> which different image samplers can inherit. We have implemented 
>>> several of them: the itk::ImageFullSampler (takes all voxels within 
>>> mask), the itk::ImageRandomSampler (which does the same as the 
>>> MattesMutualInformation class does), and some others. The 
>>> ImageSampler is just another component to be set in the metric, just 
>>> like the Interpolator, Transform, etc.
>>>
>>> The code (metricwithsampler.zip) can be found at 
>>> www.isi.uu.nl/People/Stefan. The AdvancedImageToImageMetric inherits 
>>> from the ImageToImageMetric and supports setting an ImageSampler. 
>>> Don't mind the somewhat ambitious name, by the way :)
>>> The relevant methods are:
>>> - SetImageSampler() and GetImageSampler()
>>> - SetUseImageSampler() and GetUseImageSampler()
>>> - InitializeImageSampler()
>>> The provided code won't compile as is, since it contains some 
>>> references to other code that we use, see www.isi.uu.nl/Elastix.
>>>
>>> 2. The same class includes also some functions that benefit from 
>>> transforms that have sparse Jacobians (compact suppport), such as the 
>>> B-spline transform. The code does essentially the same as the code in 
>>> the MattesMutualInformation, but can be re-used by all inheriting 
>>> metrics. The relevant functions for this are:
>>> - CheckForBSplineTransform()
>>> - TransformPoint()
>>> - EvaluateTransformJacobian()
>>>
>>> If you are interested, feel free to adopt (parts of) the code. If you 
>>> have any questions, don't hesitate to contact us.
>>>
>>> Stefan and Marius
>>>
>>>
>>> Insight Journal wrote:
>>>> Hello,
>>>> A new submission has been added to the Insight Journal.
>>>>
>>>> Title: Optimizing ITK’s Registration Methods for Multi-processor, 
>>>> Shared-Memory Systems
>>>> Author(s): Aylward, Stephen; Jomier, Julien; Barre, Sebastien; 
>>>> Davis, Brad; Ibanez, Luis
>>>> 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.
>>>>
>>>>
>>>> The refactoring has reduced computation times by factors of 2 to 200 
>>>> for metrics, interpolators, and transforms computed on 
>>>> multi-processor systems.  Extensive sets of tests are being 
>>>> developed to further test operation and backward compatibility.
>>>>
>>>> Download the paper at: http://hdl.handle.net/1926/566
>>>> Review the paper at: http://insight-journal.org
>>>>
>>>> Generated by the Insight Journal Manager
>>>>
>>>> You are receiving this email because you asked to be informed by the 
>>>> Insight Journal for new submissions.
>>>> To change your email preference go to http://insight-journal.org.
>>>>
>>>> _______________________________________________
>>>> Insight-developers mailing list
>>>> Insight-developers at itk.org
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>>
>>>>   
>>>
>>
> 

-- 
=============================================================
Stephen R. Aylward, Ph.D.
Chief Medical Scientist
Kitware, Inc. - Chapel Hill Office
http://www.kitware.com
Phone: (518)371-3971 x300