[Insight-users] Mutual Info-based Registration on Ultrasoundimage
Luis Ibanez
luis.ibanez at kitware.com
Sun, 25 Apr 2004 18:35:28 -0400
Hi Thomas,
Thansk for posting your image and the output of your test.
Yes, this means that the TIFF image is actually lacking any
spacing information.
Since you are capturing the image with a standard framegrabber,
there is actually no way the software could know what the correct
spacing is. You could equally well be providing the video output
from an electron microscope, a surveillance video camera, or an
astronomical telescope. The framegrabber cannot know about the
original scaling of the image.
It looks like you will have to introduce the spacing resulting from
your calibration as a post-processing of the image when you
read it from the file. In this case the ChangeInformationFilter
is the way to go.
What is very dangerous is that if you ever change settings of
your UltraSound probe, and those changes alter the scale of the
image, your program will continue assuming the values that
you forced from the original callibration. In other words, it is
up to you, to manually make sure that the spacing is still valid.
I would strongly suggest you to use a file format suitable for
medical images. In particular: Analyze, GIPL or MetaImage.
Using BMP and TIFF for medical images is like using Microsoft
Word for writing C++ code. :-/
Most people get attracted to those format, simply because they
can view them with generic viewers... but once you start working
seriouly with medical data, you will actually use a viewer that
takes image origin and spacing into account.
Please let us know if you have further questions,
Thanks
Luis
----------------------------------
Thomas - Kuiran Chen wrote:
>Hi Luis,
>
>The ultrasound image I am using is saved in standard "TIFF" format.
>
>The following are the information I cout using the print method you advised.
>
>============================
>Image (0136FEA0)
> RTTI typeinfo: class itk::Image<unsigned short,2>
> Reference Count: 2
> Modified Time: 171
> Debug: Off
> Observers:
> none
> Source: (0136B238)
> Source output index: 0
> Release Data: Off
> Data Released: False
> Global Release Data: Off
> PipelineMTime: 60
> UpdateTime: 174
> LastRequestedRegionWasOutsideOfTheBufferedRegion: 1
> LargestPossibleRegion:
> Dimension: 2
> Index: [0, 0]
> Size: [343, 381]
> BufferedRegion:
> Dimension: 2
> Index: [0, 0]
> Size: [343, 381]
> RequestedRegion:
> Dimension: 2
> Index: [0, 0]
> Size: [343, 381]
> Spacing: 1 1
> Origin: 0 0
> Origin: 0 0
> Spacing: 1 1
> PixelContainer: ImportImageContainer (0136B308)
> RTTI typeinfo: class itk::ImportImageContainer<unsigned long,unsigned short>
>
> Reference Count: 2
> Modified Time: 172
> Debug: Off
> Observers:
> none
> Pointer: 0136B338
> Container manages memory: true
> Size: 130683
> Capacity: 130683
>
>==========================
>
>As you can see the space is actually 1. Does it mean the original image file doesn't have space information? Or it has a wrong information? According to our calibration process, the actually pixel size of the image is 0.1 mm (pixel-to-pixel spacing).
>
>The original image was captured by standard framegrabber, and I am attaching the image for your reference.
>
>Will standard BMP or TIFF image have spacing information stored in their header?
>
>If not, can we set it in ITK?
>
>Thanks a lot,
>Thomas
>
>
>---------------------- Original Message ------------------------
>From: Luis Ibanez <luis.ibanez at kitware.com>
>To: Thomas - Kuiran Chen <chent at cs.queensu.ca>
>Sent: 2004-04-23 16:13:42
>Subject: Re: [Insight-users] Mutual Info-based Registration on Ultrasoundimage
>
>
>Hi Thomas,
>
>Could you please be more specific ?
>
>Are we talking about the image that you read using
>the ImageFileReader ?
>
>If this is the case, the spacing should already be
>set by the reader. If the spacing that you see
>when you invoke GetSpacing() doesn't match what
>you think it is in the image file, then this may
>indicate a bug in the respective reader.
>
>What fileformat are you using for storing your images ?
>
>Note that many fileformats don't have spacing information
>since they are not necessarily designed for storing
>medical images. In those cases, ITK readers set the
>spacing to the default value = 1.0.
>
>If your file doesn't have spacing information,
>you could use the itk::ChangeInformationImageFilter
>in order to set the spacing of the image. In practice
>this is a dangerous operation, and it may be a better
>idea to chose a more formal image fileformat.
>Calling SetSpacing in the GetOutput() image of a filter
>will not work, because the filter owns the image and
>will refresh the information anytime you call Update()
>again.
>
>You should *not* attempt to modify the content of
>an image that you obtained as GetOutput() from
>an ITK filter. At some point we should impose
>const-correctness to the GetOutput() call in order
>to prevent unwanted modifications.
>
>
>There is no point in worrying about your registration
>process until you solve the spacing issue. ITK performs
>registration in physical coordinates (e.g. millimeters),
>so it is fundamental that you make sure that your images
>have correct information about their Origin and Spacing.
>
>A simple exercise for verifying what you are getting
>after reading is to do:
>
> reader->Update()
> reader->GetOutput()->Print( std::cout );
>
>That will show you information about the image read
>from the file, including origin and spacing.
>
>
> Regards,
>
>
>
> Luis
>
>
>
>-----------------------------
>Thomas - Kuiran Chen wrote:
>
>
>
>>Hi Luis,
>>
>>I've been playing with the mattes mutual information implementation program you sent me for a while. :-)
>>
>>Do I have to explicitly set the pixel spacing using itk::Image::SetSpacing? The reason is that when I use the GetSpacing method of the itk::Image to check what is the spatial setting to read in the image, I found the it was (1,1), which is incorrect because my ultrasound image has a pixel-pixel distance of 0.1 mm. My guess is that (1,1) could be the default setting in ITK.
>>
>>What is more interesting is that even if I set the spacing explicitly as in the example (Image4.cxx), the output (using cout) always shows (1,1). I've explicitly called Update() to refresh the pipeline but it didn't work?
>>
>>Did I do something wrong here?
>>
>>Now what I got is: for two ultrasound images with one of them being shifted a distance in X-axis, the program gives a large mutual info (which is good), but the suggested translation parameters are unbelievable: X- 56.405, Y - 5.29456. If the parameters are given in millimeters, this would have translated the object completely out of the image (as the image size is only 380 x 340 pixels, which is 38x34 mm).
>>
>>That's why I questioned if there should be some setting of pixel spacing I should perform before hand.
>>
>>Thanks a lot,
>>
>>Thomas
>>
>>
>>---------------------- Original Message ------------------------
>>From: Luis Ibanez <luis.ibanez at kitware.com>
>>To: Thomas - Kuiran Chen <chent at cs.queensu.ca>
>>Sent: 2004-04-20 15:57:27
>>Subject: Re: [Insight-users] Mutual Info-based Registration on Ultrasoundimage
>>
>>
>>Hi Thomas,
>>
>>Let me start by saying that we all have a lot of respect
>>for those who dare to work with Ultra Sound images. :-)
>>
>>Ultrasound is more challenging for Mutual Information due
>>to the presence of speckle/noise. Since MI uses a reduced
>>number of samples (typically 50 to 100), there are good
>>chances that the Metric values will have a large variability
>>because samples will fall sometimes in bright speckle spots
>>and sometimes in dark speckle spot.
>>
>>I will suggest you to start by using the Mattes implementation
>>of Mutual Information. This Metric produces a less noisy output
>>than the Viola-Wells implementation. This will not yet solve
>>your problem though...
>>
>>
>>Are you trying to register UltraSound to UltraSound ?
>>or UltraSound to MRI ?
>>
>>This will be very important in order to chose the metric and
>>anticipate its behavior.
>>
>>
>>
>>
>>In order to get some insight on how to tune the parameters
>>for your optimization, probably the best thing to do is to
>>study the characteristics of the Metric when computed over
>>your images. Please find attached a small program that allows
>>you to explore the values of the metric using a translation
>>transform. You want to plot these values in order to get a
>>feeling on the level of noise of the Metric, the presence
>>of local minima, and the overall reproducibility of the Metric
>>function itself. (you will have to convert the dimension
>>to 3D, since the example was configured for 2D)
>>
>>Please run this program first using the *same* input image
>>as fixed and moving images, and let the translation be
>>evaluated for a range that is close to 1/2 of the image extent
>>(physical extent in millimeters).
>>
>>Plot the values using your favorite plotting program. (anything
>>from GNUPlot to Excel).
>>
>>For examples on how these plot will look like, please take
>>a look at the course in Image Registration:
>>
>> http://www.cs.rpi.edu/courses/spring04/imagereg/
>>
>> In particular, look at lectures 8 and 9.
>>
>>
>>Once you get this plot, I'll suggest you to experiment with
>>the edge preserving smoothing filters described in the Software
>>Guide. Run these filter as pre-processing of the input images,
>>and then repeat the metric plots. Since the filters will reduce
>>the noise, and hopefully some of the US speckle, it is to expect
>>that the Metric plot will also be smoothed... and therefore
>>easier to optimize.
>>
>>You could also give it a try to more traditional smoothing such
>>as Gaussians....
>>
>>---
>>
>>It is not productive to fight with the registration + optimization
>>until you find a way of generating relatively smooth Metric plots.
>>Note that this is just an exercise on learning how to tune the
>>parameters. Once you figure out the parameters, you will not need
>>to plot the Metric anymore.
>>
>>Make sure that origin and spacing are correctly set in your images
>>before you start computing all these metric plots.
>>
>>
>>
>> Please let us know if you have further questions.
>>
>>
>> Thanks
>>
>>
>> Luis
>>
>>
>>-------------------------
>>Thomas - Kuiran Chen wrote:
>>
>>
>>
>>
>>>Hi Luis,
>>>
>>>I've been trying to use ITK's implementation of viola's mutual information based registration (itk::MutualInformationImageToImageMetric) for ultrasound images.
>>>
>>>The parameter settings of the matric in the example (ImageRegistration2) work well on MRI image, but when I tried with ultrasound images (I even tried two identical images), the result was interesting but somehow unexpected. The bestValue from the optimizer was around 0.5 (mutual info entropy), and the program suggested a translation of (0.11, 0.09) along X and Y directions, and the number of iterations used was 200.
>>>
>>>The parameters need to be set are (as for the MRI image - BrainT1SliceBorder20.pgn, in the example):
>>>
>>>1. for itk::MutualInformationImageToImageMetric:
>>>- Fixed and moving image standard deviation, the example suggests 0.4;
>>>- Number of Spatial Sample Bins, the example uses 50;
>>>
>>>2. for itk::DiscreteGaussianImageFilter:
>>>- Fixed and moving image smoother various, the example sets 2.0
>>>
>>>3. for itk::GradientDescentOptimizer:
>>>- learning rate: set to 20.0 in the example
>>>- number of iterations: 200
>>>
>>>Can you provide any hints/guidelines of how to play with these parameters for different image modality? In particular, those work for ultrasound images? Also is there any text I can find to explain these parameters in more details?
>>>
>>>Thanks a lot,
>>>Thomas
>>>
>>>
>>>
>>>
>>>
>>================================================================
>>
>>
>>--------------------------------------------------------------------
>>
>>
>>
>>_______________________________________________
>>Insight-users mailing list
>>Insight-users at itk.org
>>http://www.itk.org/mailman/listinfo/insight-users
>>
>>
>>
>
>
>
>_______________________________________________
>Insight-users mailing list
>Insight-users at itk.org
>http://www.itk.org/mailman/listinfo/insight-users
>
>--------------------------------------------------------------------
>
>
>