[Insight-developers] The Insight Journal-New Submission :
Refactoring of the image registration framework
Luis Ibanez
luis.ibanez at kitware.com
Wed Jul 18 09:20:46 EDT 2007
Hi Marius,
In principle there may be a performance penalty for using the PointSet
as a replacement for a DataContainer where the element store both the
point coordinates and the pixel value.
The second should be a better storage, just as Stephen implemented in
the Optimized ImageToImage metrics, because memory coherence is
improved. How big of a difference would that make ?, we will not know
until we run a controlled test and profile the results. It may or may
not be significant when compared to the rest of the computation.
We encourage you to describe your experience in a paper to the Insight
Journal. Keep in mind that the paper style of the Insight Journal is
closer to a technical report.
It is a document intended to be read by developers, other people just
like you, so you can dive into the technical details that you consider
relevant, and you can skip the usual protocol of Decadent Journal where
authors have to pretend to be making "original" work, rather than
demonstrating that it is "reproducible" work.
In the Insight Journal we prefer code that "works", rather than
methods that are "original". :-)
It will be important for ITK to gather the views and experiences
of different groups working on image registration, before we bring
into the toolkit the speed-up improvements that Stephen's team has
made in to the framework. That will make possible for us to make
a more consistent refactoring.
We look forward to your submission.
Thanks
Luis
---------------------
Marius Staring wrote:
> Hi Luis,
>
> Good point about the PointSet :-)
>
> The PointSet indeed looks like a good alternative to the
> VectorDataContainer that we made. Would there be any performance
> difference, since the point and the value (pointdata) are stored in two
> separate vectors in the PointSet? Do you think we should replace the
> VectorDataContainer by a PointSet in our implementation?
>
> We have thought about the Insight Journal, but postponed it. We will try
> to write something as soon as possible.
>
> Stefan and Marius
>
> Luis Ibanez wrote:
>
>>
>> Marius, Stefan,
>>
>> I agree with Stephen, it will be interesting to consider the Sampler
>> as an alternative way of providing the selection of points from the
>> fixed image.
>>
>>
>> A random thought:
>>
>> An image to image registration is equivalent to a PointSet to
>> Image registration with a very dense point set. Note that the
>> itkPointSet keeps the values of pixels.
>>
>> There is a moment when all the sampling strategies could be used
>> as preprocessing for generating the "FixedPointSet", and we
>> could convert the ImageToImage metrics into PointSetToImage
>> metrics.
>>
>> That saves a bit of time in not having to convert indices to points
>> in the Fixed image. In fact, if you look at the class:
>> FixedImageSamplePoint class in the itkOptImageToImageMetric.h file,
>> it is equivalent to what we could have stored in an itkPointSet.
>>
>>
>> ---
>>
>>
>> Your sampler classes will be useful for many other applications
>> beside registration.
>>
>> Have you considered submitting them as a paper to the Insight Journal ?
>>
>>
>>
>> Regards,
>>
>>
>> Luis
>>
>>
>> -------------------------
>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>
More information about the Insight-developers
mailing list