Projects:RegistrationDocumentation:Developer - Revision history

Meier: /* Discussion Hotlist */

2010-04-14T21:27:21Z

Discussion Hotlist

Meier: /* Discussion Hotlist */

2010-04-14T21:24:03Z

Discussion Hotlist

Meier at 21:22, 14 April 2010

2010-04-14T21:22:54Z

Meier at 14:49, 22 February 2010

2010-02-22T14:49:49Z

Meier: /* Parameter GUI */

2010-01-28T15:25:43Z

Parameter GUI

Meier: /* Implementation Hotlist */

2010-01-28T15:18:46Z

Implementation Hotlist

Meier: /* Registration - Related Modules */

2010-01-06T00:19:53Z

Registration - Related Modules

Meier: /* Registration Modules */

2010-01-06T00:16:00Z

Registration Modules

Meier: /* Implementation Hotlist */

2010-01-06T00:12:07Z

Implementation Hotlist

Meier: /* Registration Modules */

2010-01-06T00:05:19Z

Registration Modules

@@ Line 8: / Line 8: @@
 [[Image:BSplResample_ResidualDiff_AnimGif.gif]]
-The residual is on the order of a voxel roundoff and hence would fit Andriy's suggestion:
+The residual is on the order of 1 voxel roundoff and hence would fit Andriy's suggestion:
    When you resample, you lose accuracy due to the unnecessary intermediate conversion of
    point to voxel after the first affine transform T_1. When you apply bspline transform T_2

@@ Line 7: / Line 7: @@
 *BSpline Resampling: Francois implemented a checkbox to choose the direction of interpretation for multiple transforms. I think this resolves the current conflict of definitions nicely without extensive recursion. What remains is a small residual difference between the volume generated by the BSpline module directly and the Resampling:
 [[Image:BSplResample_ResidualDiff_AnimGif.gif]]
 The residual is on the order of a voxel roundoff and hence would fit Andriy's suggestion:
-   When you resample, you lose accuracy due to the unnecessary intermediate conversion of point to voxel after the
+   When you resample, you lose accuracy due to the unnecessary intermediate conversion of
-  first affine transform T_1. When you apply bspline transform T_2 after this, instead of using T_1(input point) as the input to T_2(), you use
+  point to voxel after the first affine transform T_1. When you apply bspline transform T_2
    VoxelToPoint(PointToVoxel(T_1(input point))), which picks the center of the voxel.
 == Implementation Hotlist ==

@@ Line 3: / Line 3: @@
 [[Projects:RegistrationDocumentation|Back to Registration main page]] <br>
 [[Projects:RegistrationDocumentation:UseCaseInventory|Registration Use-case Inventory]] <br>
 == Implementation Hotlist ==

← Older revision		Revision as of 14:49, 22 February 2010
Line 1:		Line 1:
		+	[[Category:Registration]]
	[[Projects:ARRASuplements\|Back to ARRA main page]] <br>		[[Projects:ARRASuplements\|Back to ARRA main page]] <br>
	[[Projects:RegistrationDocumentation\|Back to Registration main page]] <br>		[[Projects:RegistrationDocumentation\|Back to Registration main page]] <br>

@@ Line 43: / Line 43: @@
 ::;[[Projects:RegistrationDocumentation:Evaluation|visualization as a registration submodule]]
-== Parameter GUI ==
+== Parameter GUI Register Images ==
 We want the parameters sufficient to give control over all relevant aspects of the algorithm. We consider highly the clinician user who is willing to convey/deal aspects of image content rather than abstract mathematical concepts, i.e. where possible we seek to translate the mathematical concept/parameter into a interaction with the image content or something that is read from the image. On the other hand we consider the flexibility of the registration tool as vital to the image analysis researcher, i.e. we want to avoid black-box behavior.
 *'''DOF''': radio buttons (3,6,7,9,12)
 *'''Multi-resolution''': check boxes (2x, 4x, 8x, 16x)

@@ Line 7: / Line 7: @@
 #[[Projects:RegistrationDocumentation:Developer#Masking / ROII|ROI box masking: enable use of ROI box as mask for fixed image ]]
 #[[Projects:RegistrationDocumentation:Developer#Presets|Enable Parameter Presets via Load/Save/Add to Menu ]]
 #[[Projects:RegistrationDocumentation:Developer#Registration - Related Modules|Module for Xform Concatenation ]]
 #Add Link to Transforms module to Registration module menu (as: "manual interactive")

@@ Line 35: / Line 35: @@
 == Registration - Related Modules ==
 :;6. ''Xform Concatenation'': combines multiple Xforms
-::;Status: basic "harden transform" exists, but needs to be expanded and obtain more prominent position as separate Registration Submodule, or as an extension of features for the data module for interactions with the MRML tree. Manipulation of Xforms likely will happen there. A graphical representation of the concept of nested Xforms would be useful, also explain terms of 'hardening Xform' etc. Possibility to copy/duplicate a Xform needed for effiient use. A strategic decision (from an object-oriented programming viewpoint, is  where to anticipate the different formats: 1) transforms have the methods to apply themselves to different data (anticipate the different data types), 2) data types have the method to apply a Xform (anticipate the different Xform. It seems the current version 1) is the more feasible one.
+::Status: basic "harden transform" exists, but needs to be expanded and obtain more prominent position as separate Registration Submodule, or as an extension of features for the data module for interactions with the MRML tree. Manipulation of Xforms likely will happen there. A graphical representation of the concept of nested Xforms would be useful, also explain terms of 'hardening Xform' etc. Possibility to copy/duplicate a Xform needed for effiient use. A strategic decision (from an object-oriented programming viewpoint, is  where to anticipate the different formats: 1) transforms have the methods to apply themselves to different data (anticipate the different data types), 2) data types have the method to apply a Xform (anticipate the different Xform. It seems the current version 1) is the more feasible one.
 :;7. ''Interpolator'':applies Affine and/or BSpline Xform and resamples image data
 ::;<small><small> Status: exists, integrated into indiv. registration methods, isolated on ITK level, needs more uniform representation in GUI</small></small>

@@ Line 28: / Line 28: @@
 ::seeks registration via ICP algorithm of two surfaces. Input: 2 segmentation models/surfaces.
 ::Parameters:
 == Registration - Related Modules ==

@@ Line 21: / Line 21: @@
 ::Parameters:  grid size/spacing, multi-res level, sampling %, cost function, stop criterion fail (iteration), mask image or ROI
 :;3. ''Manual Affine'' <small><small> (exists, but not as registration module, needs scale and shear added)</small></small>
-::interactive visual alignment with  6-12 DOF using Transforms module. This is a good tool for cases in need of an initialization.
+::interactive visual alignment with  3-12 DOF using Transforms module. This is a good tool for cases in need of an initialization.
 :;4. ''Fiducials Affine'' <small><small>(exists, needs to become a separate registration submodule) </small></small>
 ::solves Procrustes registration problem with 6-12 DOF using ICP or similar Input: fiducial pairs.