[Insight-users] [insight-users] 3D sequence registration . ( Fighthing Superstition )
marco giordano
marco.giord at gmail.com
Wed Feb 11 10:44:33 EST 2009
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: original_subtracted.pgm
Type: image/x-portable-graymap
Size: 1048593 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090211/1a4c17ec/attachment-0003.pgm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bspline_subtracted.pgm
Type: image/x-portable-graymap
Size: 1048593 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090211/1a4c17ec/attachment-0004.pgm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demons_subtracted.pgm
Type: image/x-portable-graymap
Size: 1048593 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20090211/1a4c17ec/attachment-0005.pgm>
More information about the Insight-users
mailing list