[Insight-users] mutual information again

[Luis Ibanez]

Hi Jorn,

Your suggestion sound like a pretty useful
addition for the MutualInformation metric.
(in fact, for all the metrics).

You are probably aware that currently you
can restrict the computation of the metric
to use only a user-specified region of the
fixed image. I wonder if this feature can
help somehow to aleviate the complication
you are facing. The limitation of this
feature is that only rectangular regions
can be specified.

We could imagine to add a third input to
the metrics (not only MutualInformation)
and provide an image with a binary mask
in this input. A second possibility could
be to use an itk::SpatialObject which is
intended to represent shapes. The extra
querying of the mask will slow down the
registration but at least will ensure that
it keeps running continually.

However, I have some doubts about the image
in your email. The overlap on the images
doesn't look that small. The metric is
throwing 50 samples in a uniform spatial
distribution. It seems to be an unlikely
event to get all these samples outside of
the overlap zone. But...it may be one of
this Murphy's law effect that will make your
program fail only when you are presenting
a demo...

Another alternative (as you suggested)
is to ignore the samples that fall outside
the moving image. That is, instead of:

- generationg 50 samples,
- map them
- and then finding that all of them went off,

we could keep generating random samples
until completing 50 that *do* fall inside
the moving image.

This will require a bit of tweaking on the
itk::RandomImageIterator, but seems to be
easier to implement than the mask idea.
It will be also much easier for users since
they will simply not have to deal with it.

The mask on the other hand has the appeal
of allowing you to focus the registration
process in a specific  anatomical structure.

So, to summarize the options:

1) Adding an image mask as third input.
2) Adding a spatial object as third input.
3) Count only successfully mapped samples.


(1) is a particular case of (2) since spatial
objects can be implemented as binary masks.
So it seem better to go for (2).

(3) is actually independent of (1,2) an
could be good to having it in addition to
them.

-------------

Could you please try the following ?

This is a rapid way of testing and
implementation of (3)...

In the file:
itkMutualInformationImageToImageMetric.txx
in Insight/Code/Algorithms

replace lines 121 to 150 with the
following code

----------------------

  for( iter = samples.begin(); iter != end; ++iter )
     {

     bool pointIsOutside = true;

     // keep sampling until we hit the moving image
     while( pointIsOutside )
     {	
     // get sampled index
     FixedImageIndexType index = randIter.GetIndex();

     // get convert index to point
     PointType fixedImagePoint;
     m_FixedImage->TransformIndexToPhysicalPoint(
                               index, fixedImagePoint);

     // map the point onto the moving image space
     MovingImagePointType mappedPoint =
       m_Transform->TransformPoint( fixedImagePoint );

     // test if the point is inside the moving image buffer
     if( m_Interpolator->IsInsideBuffer( mappedPoint ) )
       {
       (*iter).MovingImageValue =
                m_Interpolator->Evaluate( mappedPoint );
       allOutside = false;

     // get sampled fixed image value
     (*iter).FixedImageValue      = randIter.Get();
     (*iter).FixedImagePointValue = fixedImagePoint;

      pointIsOutside = false;

     }
   else
     {
     (*iter).MovingImageValue = 0;
     --randIter;  // random jump and decrement internal
                  // counter for number of samples
     }

     ++randIter;      // jump to random position

   } // end of while( pointIsOutside )

} // end of for()


----


And in the file

itkImageRandomConstIteratorWithIndex.txx
in Insight/Code/Common

on line 137 where the operator-- is defined
add

    m_NumberOfSamplesDone -= 2;

before

   return ++(*this);

This will decrement the counter of samples
when the operator-- is invoked by the metric.


-------


These changes should make that only succesfully
mapped points are counted for completing the
quota of 50 samples.

It shouldn't slow your program a lot...

------


BTW
Lydia checked in recently another implementation
of MutualInformation following the paper by
Mattes et al. You may want to give it a try in
your problem.  It has the advantage of producing
a much smoother landscape for the cost-function.
(This probably will not make any difference in
regard to the problem of mapping points inside
the moving image. It is just something you may want
to try on the side).


Please let us know what you find, and if you think
it is useful to make these modifications on the
cvs repository.


Thanks


    Luis



-----------------------------------

J. Van Dalen wrote:
> Dear itk-users,
> 
> First of all, thanks for your useful answers to my questions so far.
> Not all problems are solved, yet, so here a question on the use of 
> mutual information using itk, again!
> 
> To get "good" results, I am still working on a solution for a particular
> problem. Whenever the two image volumes that I want to register with
> mutual information, do not have "enough" overlap, an exception is thrown
> when I start the registration (Exception message:
> 
>>itk::ERROR: MutualInformationImageToImageMetric(003C6D20): All the
>>sampled point mapped to outside of the moving image ).
>>
> Somehow I understand this problem, but what to do when I have to images
> that are already aligned up to some level, but where the volumes are
> not overlapping sufficiently (eg when I have two cubes with the 
> center-of-mass points on top of each other but where one is rotated 
> wrt to other, along some axis, by eg TENS of degrees; A FEW degrees does
> not give a problem!). A more practical example is shown in the attached
> jpg-file where you see a MRI (grey) and CT (colour) slice of medical image
> volumes that I want to register. The MRI is rotated (with about 14
> degrees) wrt the CT, so that I do not have a good overlap between the two
> images. Moreover, the CT and MRI are already aligned reasonably. Note: The
> reason for this rotation is that the MRI has a rotation in the
> index2physicaltransform and the CT has not!
> 
> Personally, I see a solution by making a mask where I set all grey values
> of pixels that do not overlap to zero and then, when using mutual
> information, NOT using those pixels with zero grey value in the itk mutual
> information program. But how to do this? Is it somehow possible to exclude
> pixels in the registration calculation using
> itkMutualInformationImageToImageMetric. Hopefully someone has an answer to
> this question.
> 
> Note: To my opinion it would be very useful to be able to exclude some
> pixels in the mutual information registration: then, not only areas where
> no overlap is present can be excluded, but also parts where there is a lot
> of noise, or parts that you do not want to use due to deformations (of
> organs or tissue) that are present.
> 
> Thanks in advance,
> Regards,
> Jorn.
> 
> 
> ------------------------------------------------------------------------
>