[Insight-users] Joint Histogram same "appearance" number of samples MI Bspline

[Matt McCormick]

Hi Emma,


> Thanks for the help.  I am not plotting the histogram however in an image
> registration setting, but simply using the images themselves, so can't find
> a way to alter the number of samples.  Could you possibly point me in the
> right direction.

A possible strategy would look at the histogram of a "typical"
sub-region of the image, and vary its size.

>
> Is there also ball park time requirements for me to estimate if my
> registration process is performing well from a convergence / speed point of
> view.  My images are MRI 200 x 30 x 200 voxels.  I haven't reached
> convergence as of yet and am running for around 2 hours?

I am not sure offhand, but it may require some tweaking of parameters.
 For example, increasing the convergence tolerance first.

Hope this helps,
Matt




>
> Thanks for your help
>
>
> On Thu, Dec 5, 2013 at 9:09 PM, Matt McCormick <matt.mccormick at kitware.com>
> wrote:
>>
>> Hi Emma,
>>
>> > Hi I'm performing some Bspline registration and have looked on the list
>> > to
>> > find this information give regarding the number of samples.
>> >
>> >    The number of samples to take must be enough
>> >          for producing the same "appearance" of the joint histogram
>> >
>> >
>> > I have plotted the joint histogram but not sure what the same appearance
>> > means, how do I estimate the number of samples to use from the joint
>> > histogram?
>> >
>>
>> Plotting the histogram is a good first step.  Instead of plotting a
>> single histogram, it may be sufficient to plot multiple histograms
>> corresponding to different number of samples and look for convergence.
>>
>> >
>> > As an aside what drives the number of grid nodes to use, is it simply
>> > the
>> > detail in the image, the amount of motion?
>> >
>>
>> It is related to how often the motion is expected to vary, i.e. how
>> "high frequency" the motion is expected to be.  However, avoid too
>> many grid nodes, at least initially, to prevent the node parameter
>> optimization from falling into a local minimum.
>>
>> Hope this helps,
>> Matt
>
>