[Insight-users] [insight-users] 3D sequence registration . ( Fighthing Superstition )
marco giordano
marco.giord at gmail.com
Thu Feb 19 07:16:11 EST 2009
Hi Luis,
I have run the multiresolution registration as you suggested,
you can see the results hereby; I personally think that it does not do
better than the others cause I can still see some edges due to motion
.
Regarding Bspline Registration with Mutual Information I havent found
time to play with parameters but there is something more crucial I can
not solve:
Out of 64 axial slices only the first 58 are actually registered (see
Y:\umc_dataset_dsa_reg_bspline.img.d_z_58.pgm) , while the rest
remains unchanged (umc_dataset_dsa_reg_bspline_unr.img.d_z_59.pgm).
Is it is something related to the grid points that needs to be adjusted?
I would be glad to have your feedback.
Thank you,
Regards
2009/2/16 Luis Ibanez <luis.ibanez at kitware.com>:
>
> Hi Marco,
>
> Thanks a lot for posting your images,
> they are quite illustrative.
>
> From your images, it looks like the Demons algorithm is leaving less
> unregister residuals than the Bspline registration.
>
> If you are interesting in further pursuing the use of MutualInformation
> from the example
>
> DeformableRegistration8.cxx
>
> you may want to try:
>
>
> A) Increasing the Grid resolution
>
> You can do this by changing:
>
> unsigned int numberOfGridNodesInOneDimension = 5;
>
> since with the current setting you only get a grid of 8x8x8.
>
> This restrict the capacity of the grid for accommodating local
> deformations.
>
> By increasing the number, you will have a finer BSpline grid
> that should be able to adapt to smaller and more local
> deformations.
>
>
> B) Running the optimizer for more iterations.
> Which may imply in this case to do the following:
>
> optimizer->SetCostFunctionConvergenceFactor( 1.e7 ); << make it smaller
> optimizer->SetProjectedGradientTolerance( 1e-6 ); << make it smaller
> optimizer->SetMaximumNumberOfIterations( 200 ); << make it larger
> optimizer->SetMaximumNumberOfEvaluations( 30 ); << make it larger
> optimizer->SetMaximumNumberOfCorrections( 5 ); << make it larger
>
>
> Another way to approach this, is for you to give it a try
> at the example
>
> DeformableRegistration15.cxx
>
> which uses a multi-resolution approach to this same type of
> BSpline deformable registration.
>
> This example will use several levels of BSpline grids, in such a
> way that you can model small local deformations, but without
> having to compute them from the very beginning.
>
>
> Please give it a try at this latter example,
> and let us know what you find,
>
>
> Thanks
>
>
> Luis
>
>
>
> ---------------------------------------------------------------------
> On Wed, Feb 11, 2009 at 10:44 AM, marco giordano <marco.giord at gmail.com>
> wrote:
>>
>> Hi Luis,
>>
>> I first want to thank you for the response.
>>
>> Second I want to apologize because I did not express myself clearly.
>>
>> I believe that you are right saying that there is not the "Best"
>> method, but what I meant by best
>> is of course the best that I can get to run "my application".
>>
>> Anyway I wanted to stress the fact that I am not an expert in
>> registration and that to me it is only needed as a preprocessing
>> step, thus I would like to spend little time but have a decent result
>> that can allow my application to run correctly, but this of course it
>> will be hardly possible and I think someone needs to understand how
>> things work.
>>
>> My images are CT scan of the calf.
>>
>> I hereby attach 3 images of the axial view (WIN=100HU,LEV=0HU), I
>> subtracted the 29th timeframe from the 1st timeframe to show the
>> motion state. What you see is a contrast enhancement in the left leg
>> (vessels and muscles) and noise of course.
>>
>> -original contains the original DS
>> -bspline contains the one after registration with
>> DeformableRegistration8.cxx
>> -demons contains the one after the registration with
>> DeformableRegistration2.cxx
>>
>> I am quite satisftited with the bspline using the Mutual Information
>> but I am still wondering if one can get something with less
>> contours by changing some parameters.
>>
>> Any further help of course is welcome.
>>
>> Marco G.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2009/2/11 Luis Ibanez <luis.ibanez at kitware.com>:
>> >
>> > Hi Marco,
>> >
>> >
>> > Thanks for the detailed description of the problem
>> > that you are working on.
>> >
>> >
>> > Please note that:
>> >
>> >
>> > 0) The is *no such thing* as the "most suitable" or the "best"
>> > metric for a given registration problem.
>> >
>> > The popularization of the misguided notion that there is
>> > a "best method" for solving image processing problems is
>> > the result of the *decadence* of the publishing system in
>> > our field. Those who claim that they have a "best method"
>> > for any kind of problem are confused or are trying to
>> > confuse you; probably to try to sell you something that
>> > you don't need to buy.
>> >
>> > The desire to claim that a method is better than any other
>> > one was born from absence of scientific rigor in publications
>> > that disregard the importance of reproducibility in the scientific
>> > method, and are simply dedicated to fulfilling the needs of
>> > academics for filling up their yearly quotas of intellectual
>> > "production" by publishing a require N number of papers a year.
>> >
>> > First of all, *all* methods have parameters, and by changing
>> > the numerical values of these parameters you get *entirely*
>> > different results. Therefore any claim that "Method A" is
>> > better than "Method B", but doesn't list the set of parameters
>> > used on each method, has to produced in a context of ignorance,
>> > incompetence or malice.
>> >
>> > An honest an educated claim will instead report
>> > something like:
>> >
>> > Method A (as implemented in the source code that you can
>> > download from website Xa), when run on the images K, L
>> > (that you can download from the website Y), using the
>> > set of parameter (p1=0.5,p2=2.3.....etc) produce the
>> > following results (R1), while
>> >
>> > Method B (as implemented in the source code that you can
>> > download from website Xb), when run on the images K, L
>> > (that you can download from the website Y), using the
>> > set of parameter (q1=0.7,q2=7.3.....etc) produce the
>> > following results (Z1)
>> >
>> > and in the context of the application (AA: which can be
>> > radiation treatment, or surgical planning, or teaching,
>> > ...) we consider that the result R1 is better than Z1.
>> >
>> > That is a serious technical report,
>> > while the simple claim:
>> >
>> > "Method A" is better than "Method B"
>> >
>> > is simply a *superstition*.
>> >
>> >
>> > Please,
>> > demand from authors and editor of technical publications
>> > to raise their standards to the at least the basic
>> > scientific level that undergrad students will learn in
>> > Physics 101.
>> >
>> > Please,
>> > Refuse to collaborate in the dissemination of superstitious
>> > beliefs.
>> >
>> >
>> >
>> > That being said,
>> >
>> >
>> > 1) Mean squares may still be able to register your images,
>> > if the propagation of the contrast agent between Image N
>> > and image N-1 is not too large, and if there are enough
>> > regions of high intensity contrast (not agent contrast)
>> > that could guide the metric down the registration process.
>> >
>> > But of course, only a set of experiments that include
>> > a process of parameter fine-tunning will tell for sure
>> > if that is the case for your specific set of images.
>> >
>> >
>> > 2) The Demons algorithm is essentially using a Mean Squares
>> > metric. The motion that it computes is represented as
>> > a vector field, where you get a displacement vector per
>> > pixel, and the vector field is smoothed using Gaussians.
>> >
>> >
>> > 3) BSpline and MutualInformation: Both of these classes
>> > have a set of about ten parameters combined
>> >
>> > * number of grid point in the Spline
>> > * spline order
>> > * number of samples in the metric
>> > * number of histogram bins
>> > * Sigmas for the distributions
>> >
>> > not to mention the parameters of the optimizer that
>> > are typically 3 to 5.
>> >
>> > If the registration is not capturing large deformations,
>> > you may have to consider a multi-resolution approach to
>> > the BSpline grid, such as the one used in
>> >
>> > DeformableRegistration15.cxx
>> >
>> >
>> > 4) You may also find useful to try the Demons multi-resolution
>> > examples in
>> >
>> > DeformableRegistration16.cxx
>> > DeformableRegistration17.cxx
>> >
>> >
>> >
>> > Specific suggestions will require that you tell us more
>> > about the images that you are registering
>> >
>> > Anatomy : (brain ? lung ? liver ?)
>> > Modality : MRI ? CT ?
>> >
>> > Screen shots of the images and the current results would
>> > be great.
>> >
>> > BTW, you may be interested in trying the application VV
>> > http://www.midasjournal.org/browse/publication/288
>> > that is designed for visualizing the result of these kind
>> > of registration problems.
>> >
>> >
>> >
>> > Regards,
>> >
>> >
>> >
>> > Luis
>> >
>> >
>> >
>> > ---------------------
>> > marco giordano wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I am doing a registration of a 3D temporal sequence that consist of 40
>> >> frames (Vol1 .... Vol40).
>> >> .
>> >> The sequence shows the contrast uptake in vessels and human tissues
>> >> and during the sequence some squeezing and non rigid motion occurs .
>> >>
>> >> Normally I register all the frame ( Vol2 ... Vol 40) to the first
>> >> frame (Vol1) or use a concatenation of registration (register VolN to
>> >> Vol(N-1)registered)
>> >>
>> >> For such kind of problem I heard that the Mutual Information is the
>> >> most suitable metric.
>> >>
>> >> In fact a metric as meansquaredifference would try to minimize the
>> >> difference in intensities, but the intensities are already different
>> >> for
>> >> the fact that contrast changes the intensity in each frame.
>> >>
>> >> So far I tried:
>> >>
>> >> -DemonsAlgorithm DeformableRegistration2.cxx (registration is good but
>> >> the some changes occur in the intensities )
>> >> Anyway I do not undestand what kind of metric is used here and for
>> >> what kind of motion is most suitable for this algorithm
>> >>
>> >> -Bspline with Mutual Information DeformableRegistration8.cxx ( here
>> >> strong motion is not completely removed ).
>> >>
>> >> I wanted to ask if anyone has suggestion on how to carry on and if
>> >> there is some parameters that can be changed
>> >> e.g:
>> >>
>> >> -the grid spaces etc.
>> >> -number of iteration
>> >> -the optimizer
>> >>
>> >> Any help would be appreciated
>> >>
>> >> PS: I would like to cite ITK whenever the results are suitable for an
>> >> article.
>> >>
>> >> Thanks
>> >>
>> >
>>
>>
>>
>> --
>> Marco Giordano
>> MSN:gilmour812002 at yahoo.it
>> ICQ :285-118-610
>> SKYPE:marcogiord81
>
>
--
Marco Giordano
MSN:gilmour812002 at yahoo.it
ICQ :285-118-610
SKYPE:marcogiord81
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multiresolution_dsa.img.d_z_30.pgm
Type: image/x-portable-graymap
Size: 262159 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090219/772d0fac/attachment-0003.pgm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: umc_dataset_dsa_reg_bspline.img.d_z_58.pgm
Type: image/x-portable-graymap
Size: 262159 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090219/772d0fac/attachment-0004.pgm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: umc_dataset_dsa_reg_bspline_unr.img.d_z_59.pgm
Type: image/x-portable-graymap
Size: 262159 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090219/772d0fac/attachment-0005.pgm>
More information about the Insight-users
mailing list