Projects:RegistrationDocumentation:ReferenceManual

From NAMIC Wiki
Revision as of 15:21, 22 October 2009 by Meier (talk | contribs)
Jump to: navigation, search
Home < Projects:RegistrationDocumentation:ReferenceManual

Back to ARRA main page

Back to Registration main page

Main Register Images Parameters

  • 'Parameter set: could be made into the "Presets" menu?
  • IO
    • Fixed Image:
    • Moving Image:
    • Resample Image:
*Registration Parameters
  • Load Transform: provide the Loaded Transform for the loaded phase of registration
  • Save Transform: results of the entire registration pipeline will be saved here
  • Initialization: see registration pipeline discussion
  • Metric: Mutual Information metric. It is an multithreaded and optimized version of the Mattes MI method. For more information, check the code; Insight/Code/Review/itkOptMattesMutualInformationImageMetric.h/txx
      • "Expected Offset" controls the offset scales in rigid and affine registration the deformation vector scale in bspline registration
      • "Expected Rotation" is roughly in terms of radians. It controls the rotation angles in rigid and affine registration
      • "Expected Scale" is for scaling during affine registration
      • "Expected Skew" is for skew for affine registration

Advaned Registration Parameters Tab

  • Verbosity level
    • Controls the level of detail in the reports in the log file
  • Sample from fixed/moving overlap
    • When the fixed image is much larger than the moving image, it is CRITICAL to set this flag and to pick a good initialization method. In that way, only the portion of the fixed image that is initially covered by the moving image will be used during registration. This prevents ITK from throwing an exception (error) stating that too many fixed-image samples miss (map outside of) the moving image.
  • Fixed image intensity percentage threshold
    • A less robust way to overcome the image overlap issue discussed above, you can specify a threshold as a portion (0 to 1) of the fixed image intensity range that should be used to select fixed image samples for computing the metric. That is, by specifying 0.5, only the pixels in the upper half of the fixed-image's intensity range will be used during random sample selection.
    • Remember, it is important to include pixels inside and outside of the object of interest, otherwise the fixed image histogram may be too homogeneous for mis-registrations to be detected.
  • Random number seed
    • To ensure consistent performance, you can set a seed - repeated runs should produce identical results.
  • Number of threads
    • Number of multi-core/mult-processor threads to use during metric value computations.
  • MimimizeMemory
    • Turns off caching of intermediate values during bspline registration
    • Provides a way to compute bspline registrations using a dense set of control points and a large number of samples on "normal" computers (albeit computation time increases)
    • Rule of thumb, if the BSpline registration crashes - re-run with this option enabled.
  • use windowed sinc for final interpolation
    • If you have time to kill. Extremely slow and only marginally better than bspline resampling (the default).

Registration Testing Parameters

  • Baseline Image
    • Set the image against which the Resampled Image (IO tab) will be compared after registration
  • Number of Failed Pixels Tolerance
    • Registration returns "failure" if this many pixels are different between the Resampled and Baseline images
  • Intensity Tolerance
    • Minimum intensity difference between corresponding Resampled and Baseline pixels for those pixels to be counted as failures
  • Radius Tolerance
    • The program will search this neighborhood size about each Resampled pixel to find the closest matching Baseline pixel. The closest matching pixels are compared using the Intensity Tolerance (above)
  • Baseline Difference Image
    • Result of subtracting the resampled image from the baseline image
  • Baseline Resamples Moving Image
    • resampled image, resampled into the space of the baseline image

Advanced Initial Registration Parameters

  • Fixed / Moving Landmarks
    • A vector string (comma separated base-3 list) of the indexes of corresponding points in the fixed and moving images
    • If supplied, then choose "Landmarks" as the initial registration method (see discussion on registration pipeline)

Advanaced Rigid and Affine Parameters

  • MaxIterations
    • Number of iterations for one-plus-one and for FRPR registration
  • Sampling Ratio
    • Portion of the image pixels to be used when computing the metric

Advanced BSpline Parameters

  • MaxIterations
    • Number of iterations for one-plus-one and for FRPR registration
  • Sampling Ratio
    • Portion of the image pixels to be used when computing the metric
    • Do the math...if you have 40 pixels between control points, then there will be 40^3 (64,000) pixels relevant to each control point. That excessive for directing one control point. Keep the sampling small. For 40 pixels between control points, a sampling density of 0.1 provide 6,400 pixels for metric computation at each control point - more than enough.
    • When in doubt, turn on MinimizeMemory
  • Control point spacing (pixels)
    • Don't think about grid size - instead think about the level of detail that needs to be resolved (see discussion on sampling ratio).
    • When in doubt, turn on MinimizeMemory

Incorporates testing

  • See discussion on the "Registration Testing Parameters" tab.


Class structure

  • Try it, you'll like it.
  • Follows the coding style of itk
  • Limited comments, but meaningful variable names
  • No documentation is provided or planned - don't even ask.

Instructions for Enabling the RegisterImages module

This module should now be built and distributed by default. No special steps are needed to use this module.

Background

Goals

There are two components to this research

  1. Identify registration algorithms that are suitable for non-rigid registration problems that are endemic to NA-MIC
  2. Develop implementations of those algorithms that take advantage of multi-core and multi-processor hardware

Steps involved

  1. Modify ITK's registration framework to support oriented images
  2. Modify ITK's registration framework to be thread safe
  3. Develop multi-threaded versions of select registration modules
  4. Make everything backward compatible with ITK's existing registration methods and framework
  5. Deliver in ITK
  6. Develop helper classes and write IJ article

Target date for these deliverables: Jan 1, 2008

Main Algorithm =

  • For rigid and affine registrations, one-plus-one evoluation optimization is first applied for N iterations, and then FRPR gradient-line-search optimization is applied.
      • For more information, check the code: RegisterImagesModule/itkOptimizedImageToImageRegistrationmethod.h/txx
    • For BSpline registration, a hierarchical registration scheme is used. An image pyramid having 3 levels is used to resample the images and the control grids. Heuristics are used to control the various resampling parameters. At each level, registration is conducted using FRPR gradient-line-search optimization.
      • For more information, check the code: RegisterImagesModule/itkBSplineImageToImageRegistrationMethod.h/txx

Planned follow-on work

Devise a new metric for MI registration

  1. If we always use every voxel for the metric, then we can cache the weights by the voxel's position wrt the adjacent control points. For example, for Kilian's situation of a control point every 2 voxels, then there really are only a few unique weight sets that are repeated throughout the volume. Luis had already brought up a variation on this idea.
  2. This method could also be combined with the rule to not evaluate voxels or control points that fall on background voxels. This too has been discussed, but such a rule makes multi-threading tricky in that we don't want to waste threads by allocating them to image regions that contain only background voxels.
  3. The metric could be closely tied to a multiresolution registration scheme. In fact, the grid and the image resolutions should perhaps be linearly related. That is, we could tie the metric computation to the resolution of the deformation grid by subsampling the image. There are situations where this is not a right thing to do (just because the grid is coarse doesn't mean that a small movement isn't important); HOWEVER, as part of a multiresolution registration strategy, it is perhaps the viable option. This would need to be evaluated on the data.
  4. Have "don't-care" regions in which bspline control points are processed/don't move, e.g., no need to adjust ones that only contain background

Status and News

Thanks (but not your questions or comments) go to

  • Luis Ibanez, Matt Turek, Stephen Aylward

Questions and comments should go to the Slicer Developers' list

Publications

  1. Aylward, Stephen; Jomier, Julien; Barre, Sebastien; Davis, Brad; Ibanez, Luis, "Optimizing ITK’s Registration Methods for Multi-processor, Shared-Memory Systems." MICCAI Open Source and Open Data Workshop, 2007 (Download PDF)
  2. BWH Neuroimaging Analysis Center (NAC), 2007-2008: Grid Enabled ITK
  3. IJ article on oriented images and registration in ITK

Algorithmic Requirements and Use Cases

Hardware Platform Requirements and Use Cases

  • Use-cases
    1. Intel Core2Duo
    2. Intel quad-core Xeon processors, Visual Studio 8, Windows Vista (Kitware: redwall)
    3. 6 CPU Sun, Solaris 8 (SPL: vision)
    4. 12 CPU Sun, Solaris 8 (SPL: forest and ocean)
    5. 16 core Opteron (SPL: john, ringo, paul, george)
    6. 16 core, Sun Fire, AMDOpteron (UNC: Styner)

Historic Results

January 5, 2008 - Note: "Opt" results are not using the OptLinearInterpolateImageFunction.

Historic Events

Related Pages

Notes on Software Profiling Tools

Retrieved from "https://www.na-mic.org/w/index.php?title=Projects:RegistrationDocumentation:ReferenceManual&oldid=44187"