Release 3.6

Release 3.6 Schedule

Release Number	Start Date	End Date
Moving code from ITK Review Directory to final destination	Jan 5 2008	Jan 25 2008
Reviewing Insight Journal (IJ)	Jan 5 2008	Jan 18 2008
Selecting best IJ papers	Jan 18 2008	Jan 18 2008
Bug triage	Jan 18 2008	Jan 18 2008
Moving IJ code into ITK Review Directory	Jan 19 2008	Jan 31 2008
Feature freeze, fixing tests, code coverage	Feb 1 2008	Feb 27 2008
CVS Tagging	Feb 28, 2008	Feb 28, 2008
Testing tarballs	Feb 28, 2008	Feb 28, 2008
Posting tarballs	Feb 29 2008	Feb 29 2008

Deprecated code to be removed

• Alpha parameter from the Kernel Transforms

Code to be moved from Review to final destination

• Transform Readers Writers
  • Pick a filename extension
  • Do code reviews
• VTKPolyData Reader Writer (Not Yet: doesn't support QMesh)
  • Check tests
• Label filters
  • Label Overlay
  • Labet RGB
• Morphology Filters
• ConformalFlattening
• ContourExtractor
• FlatStructuringElement
• ProjectionFilters
• MINC ImageIO support
• NeuralNetworks (Not Ready)
  • It can't create arbitrary Neural Networks.
  • In its current form, the user must know the structure of the Neural Network, and must instantiate it, before she/he can read it from a file.
  • (Discussed at tcon Feb 22 2008): Minutes 022208

Contributions from IJ

High Priority

1. Digital Topology [1] (Shepherd: )
2. vtkINRIA3D: A VTK Extension for Spatiotemporal Data Synchronization, Visualization and Management [2] (Shepherd: )
3. Using a Mask to Decrease Computation Time for SpatialObject to Image Conversions [3] (Shepherd: )
4. FFT Complex to Complex filters and helper classes [4] (Shepherd: )
5. itkEllipseBoundaryToImageFilter [5] ( Shepherd: )
6. Implementing the Automatic Generation of 3D Statistical Shape Models with ITK [6] (Shepherd: )
7. Optimizing ITK’s Registration Methods for Multi-processor, Shared-Memory Systems [7] (Shepherd: )[Done]
8. I-DO: A Deformable Organisms framework for ITK [8] (Shepherd: )
9. Diffeomorphic Demons Using ITK's Finite Difference Solver Hierarchy [9] (Shepherd: )
10. Multidimensional Arrays and the nArray Package [10] (Shepherd: )
11. A Generalized Squared Euclidean Distance Transform with Voronoi Maps [11] (Shepherd: )
12. A support for "cub" image format [12] (Shepherd: )[Done]
13. Binary morphological closing and opening image filters [13] (Shepherd: )
14. MinimaImpositionImageFilter [14] (Shepherd: )

Low Priority

1. Non-rigid Groupwise Registration using B-Spline Deformation Model [15] (Shepherd: )
2. Generalizing vesselness with respect to dimensionality and shape [16] (Shepherd: )
3. Incorporating Metric Flows and Sparse Jacobian Transformations in ITK [17] (Shepherd: )
4. Class for Serial Transformations [18] (Shepherd: )
5. Kappa Sigma Clipping [19] (Shepherd: )
6. Radial Thickness Calculation and Visualization for Volumetric Layers [20] (Shepherd: )
7. Label object representation and manipulation with ITK [21] (Shepherd: )
8. Cumulative Gaussian Curve Fitter for Boundary Parameterization [22] (Shepherd: )
9. Optimized image iterators [23] (Shepherd: )
10. Slice by slice filtering with ITK [24] (Shepherd: )
11. Consolidated morphology [25] (Shepherd: )
12. Reader/Writer for Analyze Object Maps for ITK [26] (Shepherd: )
13. A small rework for the Gaussian Derivative Image Function [27] (Shepherd: )

---

ITK: [Welcome | Site Map]

Comment (Feb. 2, 2008, R Brooks)

With regard to the class for serial transformations, this is an excellent and useful idea. However, the paper linked to here does not support the registration framework, where as another paper on the same topic does. [28] That paper, however, has its own set of limitations. I think that a class for serial or combined transforms is a valuable addition. However, I worry that if done prematurely, we would be stuck with a limited interface due to ITKs backwards compatibility policies. I think some serious thought should be put into how this interface should work before committing to a particular implementation.

At the very least i think that any such class should support:

1. The registration framework - ie - proper Jacobians
2. An arbitrarily long chain of transformations
3. The ability to have some fixed and some parameterized transforms - by this i mean that some transformation parameters do not appear in the GetParameters and Jacobian methods.
4. Some sort of intelligent interaction with the transform reader and writer classes.

I suppose that I should kick myself a bit, for not having reviewed either of these papers. I'll post this to the list as well and see if it spawns discussion.