ITK/Release 4/Enhancing Image Registration Framework/Tcon 2010-11-23: Difference between revisions
(Created page with "Topic notes: ''' How to distribute / manage a design document ''' E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto but dont use tab...") |
No edit summary |
||
Line 3: | Line 3: | ||
''' How to distribute / manage a design document | ''' How to distribute / manage a design document | ||
''' | ''' | ||
E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto | E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto | ||
but dont use tables. use the class diagrams. | but dont use tables. use the class diagrams. | ||
Line 16: | Line 17: | ||
We are currently leaning toward writing a list of files. why? because you write out a deformation field as nii.gz , an affine as .mat or .txt and a velocity field as .mhd. and it may be easily edited to build concatenated files. problems: windows, etc. also, sometimes headers are in separate files than the binary data they describe. | We are currently leaning toward writing a list of files. why? because you write out a deformation field as nii.gz , an affine as .mat or .txt and a velocity field as .mhd. and it may be easily edited to build concatenated files. problems: windows, etc. also, sometimes headers are in separate files than the binary data they describe. | ||
another tricky thing --- composite transform file names. do we pass prefixes? do we pass the names for all the transforms (too much work)? | |||
invoke a special I/O object for composite transforms? | |||
currently, a transform has 2 arrays of doubles. then the I/O writer will save in either txt or binary. do we add a string or array of strings with each transform to the transform factory? most transforms would not use this. composite transform would populate it. | |||
need ImageTransformIOFactory? | |||
add GetDefaultTransformFileExtension to transform base? alternatively, BinaryType, TextType, ImageType enumerators. | |||
''' DeformationFieldTransform | ''' DeformationFieldTransform | ||
''' | ''' | ||
current deformation field transform only transforms point. still needs to implement jacobian and other elements that are ultimately needed. this is ok for now. the rest will happen later. | |||
''' DeformationFieldTransform I/O | ''' DeformationFieldTransform I/O | ||
''' | ''' | ||
see composite transform notes above. | |||
''' How to remove transforms we dont want anymore? | ''' How to remove transforms we dont want anymore? | ||
''' | ''' | ||
Document? Mark classes as deprecated? How do we avoid breaking somebody's application? | |||
Good solution: create a module for classes that we want to eliminate. Xiaoxiao stuff. E.g. all centered transforms. | |||
Also: create core registration module that is tested most deeply and that we highly recommend. | |||
''' BSpline refactoring + Bug? ( Nick ) | ''' BSpline refactoring + Bug? ( Nick ) | ||
''' | ''' | ||
line 721 bspline transform txx --- Luis says "Wow". we decide we should get rid of the bulk transform b/c it is inconsistent with the rest of the toolkit. CompositeTransform will replace this functionality. Need to discuss / publicize this change with NAMIC, Hans Johnson, Elastix. | |||
first, we'll put the current preliminary composite transform in through gerrit. | |||
''' Transform base class refactoring | ''' Transform base class refactoring | ||
''' | ''' | ||
Enum type that identifies output file type | |||
SpatialJacobian | |||
SpatialHessian and/or Hessian | |||
Eliminate transform vector functions? Kind of. Implement the methods polymorphically then call the polymorphic methods from the TransformVector / TransformTensor function. | |||
''' Metric base class refactoring | ''' Metric base class refactoring | ||
''' | ''' | ||
Remove multi-threading stuff except SetNumberOfThreads. | |||
''' Reorientation standards/approaches. | ''' Reorientation standards/approaches. | ||
''' | ''' | ||
separate reorientation filter ? | |||
it appears to be standard throughout the toolkit that reorientation is performed. as far as we know. |
Revision as of 22:44, 23 November 2010
Topic notes:
How to distribute / manage a design document
E.g. http://www.itk.org/Wiki/Proposals:Refactoring_Statistics_Framework_2007_Class_Manifesto but dont use tables. use the class diagrams.
Is there a different method? maybe latex ....
CompositeTransform ( Michael Stauffer, Nick ) Mike will push later today.
CompositeTransform I/O We are currently leaning toward writing a list of files. why? because you write out a deformation field as nii.gz , an affine as .mat or .txt and a velocity field as .mhd. and it may be easily edited to build concatenated files. problems: windows, etc. also, sometimes headers are in separate files than the binary data they describe.
another tricky thing --- composite transform file names. do we pass prefixes? do we pass the names for all the transforms (too much work)?
invoke a special I/O object for composite transforms?
currently, a transform has 2 arrays of doubles. then the I/O writer will save in either txt or binary. do we add a string or array of strings with each transform to the transform factory? most transforms would not use this. composite transform would populate it.
need ImageTransformIOFactory?
add GetDefaultTransformFileExtension to transform base? alternatively, BinaryType, TextType, ImageType enumerators.
DeformationFieldTransform current deformation field transform only transforms point. still needs to implement jacobian and other elements that are ultimately needed. this is ok for now. the rest will happen later.
DeformationFieldTransform I/O see composite transform notes above.
How to remove transforms we dont want anymore? Document? Mark classes as deprecated? How do we avoid breaking somebody's application?
Good solution: create a module for classes that we want to eliminate. Xiaoxiao stuff. E.g. all centered transforms.
Also: create core registration module that is tested most deeply and that we highly recommend.
BSpline refactoring + Bug? ( Nick ) line 721 bspline transform txx --- Luis says "Wow". we decide we should get rid of the bulk transform b/c it is inconsistent with the rest of the toolkit. CompositeTransform will replace this functionality. Need to discuss / publicize this change with NAMIC, Hans Johnson, Elastix.
first, we'll put the current preliminary composite transform in through gerrit.
Transform base class refactoring Enum type that identifies output file type
SpatialJacobian
SpatialHessian and/or Hessian
Eliminate transform vector functions? Kind of. Implement the methods polymorphically then call the polymorphic methods from the TransformVector / TransformTensor function.
Metric base class refactoring Remove multi-threading stuff except SetNumberOfThreads.
Reorientation standards/approaches. separate reorientation filter ?
it appears to be standard throughout the toolkit that reorientation is performed. as far as we know.