|
|
| (55 intermediate revisions by 14 users not shown) |
| Line 1: |
Line 1: |
| = ITK Version 4 = | | = ITK Version 4 = |
| This work is supported by ARRA funding from the NLM. The [http://visual.nlm.nih.gov/itk/itk2010/agenda.html kick-off meeting] for this project took place from June 28-July 2 2010 in Bethesda. A beta version of the software will be available by the end of March 2011. Bug fixes will continue to be contributed to the ITK version 3 code. | | This work is supported by ARRA funding from the NLM. The [http://visual.nlm.nih.gov/itk/itk2010/agenda.html kick-off meeting] for this project took place from June 28-July 2 2010 in Bethesda. A beta version of the software will be available by the end of March 2011. Bug fixes will continue to be contributed to the ITK version 3 code. |
| | == Download == |
| | |
| | * [[ITK_Release_4/Download|Download]] |
| | |
| | == Release Notes == |
| | |
| | * [[ITK_Release_4/Migration Plan/Release Notes|Release Notes]] |
| | |
| | == LICENSE Change == |
| | |
| | Starting with ITKv4-Alpha-01, the ITK toolkit is distributed under the Apache 2.0 License. |
| | |
| | More details here: |
| | |
| | * [[ITK_Release_4/Licensing|Licensing]] |
| | |
| | == Revision Control == |
|
| |
|
| * Adopt a modern revision control system | | * Adopt a modern revision control system |
| ** Move from cvs to git for distributed source code management | | ** Move from cvs to [http://git-scm.com git] for distributed source code management |
| | ** [[ITK/Git|ITK Git Instructions]] |
| | |
| | == Code Review == |
| | |
| | * Adopt a code review system |
| | ** [http://review.source.kitware.com/p/ITK ITK Gerrit] |
| | ** Powered by [http://code.google.com/p/gerrit/ Gerrit Code Review] |
| | |
| | == Modern C++ == |
| | |
| | * [[ITK_Release_4/Modern C++|Modern C++]] |
| | |
| * Take advantage of advances in C++ | | * Take advantage of advances in C++ |
| ** Target popular compilers that are compatible with the C++98 and/or C++03 standard (http://en.wikipedia.org/wiki/C%2B%2B03#Language_standard). | | ** Target popular compilers that are compatible with the C++98 and/or C++03 standard (http://en.wikipedia.org/wiki/C%2B%2B03#Language_standard). |
| ** Specifically remove support for Visual Studio prior to 7.1 (e.g., 6 and 7.0), Borland version 5.5, Sun Studio compilers prior to 5.9, IRIX compilers, MWORKS compilers, and gcc prior to 3.4 | | ** Specifically remove support for Visual Studio prior to 7.1 (e.g., 6 and 7.0), Borland version 5.5, Sun Studio compilers prior to 5.9, IRIX compilers, MWORKS compilers, cygwin 1.5 (newer versions may work, but are not being targeted), and gcc prior to 3.4 |
| * Improved ITK Wrapping | | |
| ** Particularly for Python | | == Wrapping == |
| * Addition of simple ITK layer | | |
| ** A matlab-like interface to ITK
| | * Improved ITK Wrapping at the class level (WrapITK) |
| * Refactor for modularity | | ** [[ITK_Release_4/Wrapping|Wrapping]] |
| | ** Particularly for Python 2.x, Python 3, Java and C# |
| | |
| | == Simplify == |
| | |
| | * Addition of [[ITK_Release_4/SimpleITK|Simple ITK Layer]] |
| | |
| | == Modularize == |
| | |
| | * Refactor for [[ITK_Release_4/Modularization|Modularity]] |
| ** ITKCore, ITKRegistrationModule, and Optional Modules | | ** ITKCore, ITKRegistrationModule, and Optional Modules |
| | |
| | == Testing Crowdsourcing == |
| | |
| | * [[ITK_Release_4/Testing_Crowdsourcing|Testing Crowdsourcing]] |
| | |
| | == Improve Software Process == |
| | |
| * Enhanced project management tools and software processes | | * Enhanced project management tools and software processes |
| | |
| | === Data Management === |
| | |
| | * Better management for [[ITK_Release_4/Testing Data|Testing Data]] |
| | * Data Collection [[ITK_Release_4/Data Collection|MIDAS]] |
| | |
| | === Distributed Testing (cdash@home) === |
| | |
| | * Testing On Demand [[ITK_Release_4/Testing On Demand|cdash@home]] |
| | |
| | === Testing Framework === |
| | |
| | * [[ITK_Release_4/UnitTesting|New unit testing framework]] based on [http://code.google.com/p/googletest/ Google Test] |
| ** Particularly to support module development, testing, and maintenance | | ** Particularly to support module development, testing, and maintenance |
| | |
| | === Coding Style === |
| | |
| | * [[ITK_Release_4/Coding Style|Coding Style]] |
| | |
| | == Revise == |
| | |
| | === FEM === |
| | |
| * [[Refactoring itk::FEM framework - V4]] | | * [[Refactoring itk::FEM framework - V4]] |
| | |
| | === Level Sets === |
| | |
| | * [[Refactoring Level-Set framework - V4]] |
| | |
| | === DICOM === |
| | |
| * Improved DICOM support | | * Improved DICOM support |
| | ** [[ITK_Release_4/DICOM|DICOM]] |
| ** Including communications with PACS | | ** Including communications with PACS |
| * Add streaming for GPU-based data/methods | | ** Support Streaming interface |
| | ** Add filter to support Siemens MOSAIC images |
| | ** Information Object Definition verification |
| | |
| | === Image Registration Framework === |
| | |
| | * [[ITK_Release_4/Enhancing Image Registration Framework|Enhancing Image Registration Framework]] |
| | |
| | === Spatial Objects === |
| | |
| | * [[ITK_Release_4/SpatialObjects | Spatial Object Refactoring project page]] |
| | |
| | === Global Code Review === |
| | |
| | * [[ITK_Release_4/Global_Code_Review | Global Code Review]] |
| | |
| | == Accelerate == |
| | |
| | === GPU === |
| | |
| | |
| | * [[ITK_Release_4/GPU Acceleration|GPU Acceleration - V4]] |
| ** With support for distributed computing in the future | | ** With support for distributed computing in the future |
| * Enhanced image registration framework
| |
|
| |
|
| | * [[GPU_Acceleration_-_V4|GPU Acceleration - V4 (deprecated link)]] |
|
| |
|
| = Wish List =
| |
|
| |
|
| [[ITK_Release_4/Wish List|Wish List]] | | === Numerical Libraries === |
| | |
| | * [[ITK_Release_4/Refactor Numerical Libraries|Refactor Numerical Libraries]] |
|
| |
|
| = Migration Plan = | | == Release schedules == |
|
| |
|
| [[ITK_Release_4/Migration Plan|Migration Plan]] | | * [[ITK Release 4/ReleaseSchedules|Release Schedules]] |
|
| |
|
| = Discussion Points = | | = The Team = |
|
| |
|
| [[ITK_Release_4/Discussion Points|Discussion Points]] | | [[ITK_Release_4/The Team|The Team]] |
|
| |
|
| *Strings are std::strings: Filenames should be std::strings, not const char* _arg
| | = Wish List = |
| ** Set character string. Creates member Set"name"() (e.g., SetFilename(char *)). The macro assumes that the class member (name) is declared a type std::string. */
| |
|
| |
|
| * Threading model modifications:
| | [[ITK_Release_4/Wish List|Wish List]] |
| # Thread pools?
| |
| # Hierarchal thread handlers?
| |
| # Can threads deal with pushing data across hardware units with inconsistent memory models (i.e. 4 core SMP + GPU#1 + GPU#2)
| |
|
| |
|
| * Need Explicit Transition Documentation:
| | = Migration Plan (Developers) = |
| # To facilitate transition from ITK3 to ITK4, a set of migration documents and tools will be beneficial to researchers who will be migrating to their tools to ITK4. As we adapt the reference applications to the changes occurring in ITK4, we will document the necessary source code changes to use the new version of ITK4. When possible, we will write a set of scripting tools that transform ITK3 to ITK4, or identify old code that has become invalidated, and suggest alternative options. We will deliver this documentation both as a standalone document and as an online WIKI-based web resource.
| |
|
| |
|
| *Transforms:
| | [[ITK_Release_4/Migration Plan|Migration Plan]] |
| # Need ability to deal with concatenated physical space mappings (Rigid-»Affine-»BSpline-»Displacement-»Rigid-» etc)
| |
| # Better protocols for reading/writing/ transforms including the ambiguous way that compound (i.e. not concatenated) transforms are represented.
| |
|
| |
|
| *Image Physical Space/Domain:
| | = Migration Guide (for Users) = |
| # There is a need an image layer that does NOT have a physical space representation
| |
| ## ImageBase-»DigitalImage-»ContinuousImage-»[Image(the current interpretation)|GeoSpatialImage|Other physical space]
| |
| ## Most PixelWise filters will be defined over the DigitalImage layer to explicitly identify them as not dealing with physical space
| |
| ## Digital to Continuous conversion API is consistent (TransformIndexToPhysical & PhysicalToIndexTransform), but may be adaptable to address the needs of our expanding user base
| |
| ## The current "Image" designator is explicitly defined as an (LPS anatomical, East|North|Altitude) with Direction cosigns, spacing, origin and appropriate
| |
| ## Units: A designation that can hint to the application level how to interpret physical space. Perhaps the filters would just verify that units are the same. (default being non-existing and therefore the same).
| |
|
| |
|
| *Platform support (a platform is a [Hardware, OS, Compiler, Compiler options] )
| | [[ITK_Release_4/Users Migration Guide|Users Migration Guide]] |
|
| |
|
| # Reduce build burden -- Explicit Templates & Pre-compiled headers:
| | = Software Guide (Update) = |
| ## Under the assumption that the scope of the simple & wrapping frameworks will define a large swath of instantiations that almost all applications also need. By defining and pre-compling those common (perhaps driven by the wrapping choices) tools, compiling the application layers will be significantly faster. This should reduce the burden on application developers by shifting build time costs away form the time of building the applications.
| |
| ## We do have to be careful to limit this (or provide options to limit this) so that the default build does not take 10 hours.
| |
| ## This does imply that the compiler MUST support explicit instantiation of templates
| |
| ## ---- As a side note, perhaps we also need to investigate pre-compiled header support for compilers to lower the development burden
| |
| # An explicit deprecation cycle for ALL compilers
| |
| ## It is CRUCIAL that we define upfront a MINIMUM time frame for how long each version of ITK4 we commit to supporting all platforms. It is expected that these dates will shift into the future, but not earlier.
| |
| ### Windows 7, Visual Studio 2010 will be supported at least until Jan 1, 2017
| |
| ### Windows XP, Visual Studio Express 8 will be supported at least until Jan 1, 2015
| |
| ### Linux gcc version 4 (greater than 4.0.1) will be supported at least until Jan 1, 2012
| |
| # Compilers need to be compliant with the C++03 standards. http://en.wikipedia.org/wiki/C%2B%2B
| |
|
| |
|
| *IO interface changes:
| | [[ITK_Release_4/Software Guide Update|Software Guide Update]] |
| # Transforms components "Can be written", but there is insufficient information to un-ambiguously derive the intent and appropriate use of those transform parameters. In particular, the parameters for BSpline are written to disk in two components, and the BSpline parameters are linearly written, but the implied grid for those parameters is not specified in the output file. As a use case, the BSpline transform type SHOULD be able to be instantiated from just the information in the file.
| |
| # Are there IO factory simplifications that could be done? i.e. remove separatedFactories for each type
| |
|
| |
|
| *Meta Data Dictionary:
| | = A2D2 Projects = |
| # MetaData Dictionary items need "Traits" to help identify the "social status" of the element (such as ITK_SUPPORTED_PUBLIC, ITK_SUPPORTED_PRIVATE, UNSUPPORTED_PRIVATE, UNSUPPORTED_PUBLIC).
| |
| # The first contribution of the Iowa ITK development team was to introduce the “MetaDataDictionary” storage mechanism to all ITK Objects that could contain arbitrary key-value pairs of data. The MetaDataDictionary was not part of the original ITK framework definition, and has therefore not been consistently implemented throughout the ITK toolkit. We propose to revisit the implementation of the MetaDataDictionary to improve and simplify the ABI so that it is easier to use. In particular, the Encapsulate() and Expose() functions can now be simplified when using standards-compliant C++ compilers, and new features for describing a dynamically created dictionary at run time will be introduced. A common use of the MetaDataDictionary has been to temporally append features that were missing in the initial ITK framework. In many cases, the use of the MetaDataDictionary was subsequently followed by addition of formal support of the feature to ITK, and this lead to redundancy of information that was not always kept synchronized. Additionally, as new developers adopted the MetaDataDictionary for different uses, they each created inconsistent definitions for similar uses of the dictionary. We will review the internal ITK uses of the MetaDataDictionary, remove uses that are now redundant with formal accepted functionality, and consolidate similar uses of the Dictionary. The MetaDataDictionary is most commonly used to pass additional information to or from the Input/Output mechanisms. We will define a protocol so that data object histories can be tracked through consistent instrumentation of ITK process objects to tag output objects. We will review the Input/Output and develop a standard practices guideline for how to map the extra data to and from ITK in a consistent way. Wherever possible, we will use tags and definitions consistent with the dictionaries specified in the DICOM standard.
| |
|
| |
|
| * ITK Orientation
| | [[ITK_Release_4/A2D2_Projects|A2D2 Projects]] |
| # Instrument the itk::ImageIO methods to record spatial image orientation in the MetaDataDictionary prior to it’s inclusion as a formal feature. This solution allowed representation of which of 48 possible 3D orientations the image was in. This was represented symbolically by 3 letter combinations, based on permuting (A)nterior/(Posterier), (I)nferior/(S)uperior, (L)eft/(R)ight. For example RAS meant that the voxels are oriented Right-to-Left, Anterior-to-Posterior, Superior to Inferior, corresponding to Row/Column/Slice. This method of specifying orientation is useful but very limited; many anatomical scanners allow scanning at oblique angles with respect to anatomy. So after long discussion in the ITK developer community, a more general method was developed, which represented the orientation as a direction cosine matrix (DCM). The direction cosines specify a general 3D rotation of the image voxels with respect to the anatomy being scanned. The long experience with brain imaging research at Iowa will inform our implementation of these changes. However, we also recognize and highly value the expertise of the other members of the ITK developer community, and the implementation will be guided by the consensus judgment of the community as a whole. We will enhance the code infrastructure of ITK with respect to issues of position and orientation of images. Deliverables will comprise both changes to the core ITK library code, and extensive regression tests to verify correct operation with the rest of the ITK Library. There are three ways in which the handling of orientation in ITK needs to be improved:
| |
| # Currently the size of the direction cosines is linked to the number of dimensions in the image – for a 2D Image, they comprise a 2x2 DCM, for a 3D Image 3x3, etc. Conceptually, the use of the current orientation description is most suited for describing images with exactly 3 spatial dimensions. We believe this needs to be changed and generalized to accommodate describing data sets within a higher dimensional space, or with respect measurement direction that is different from scanning direction. First, any 2D scan of anatomy will have an implied third axes, parallel to the direction of image acquisition. In particular, 2D DICOM slice images always report the three-dimensional image position of the scan with respect to the patient. At present, when ITK reads a single 2D DICOM image, there is no way to preserve it’s relationship to 3D-space. Finally, the orientation of a measurement frame with respect to sub-volumes is necessary to properly represent complex acquisition types (such as diffusion weighted imaging). Similarly, 2D Images can have a three-dimensional image origin with a well-defined anatomical meaning. Discarding that when reading the image is a loss of information. In both cases (orientation and origin) it will be necessary to enforce backwards compatibility. This will be achieved in two ways: by adding new class methods that are explicitly three-dimensional, and by careful testing of all ITK classes to ensure their continued correct operation.
| |
|
| |
|
| *Need more FFT adaptors, and a slight refactoring of FFT adaptor base to meet several platform
| | = New Fields = |
|
| |
|
| # It would be nice to have a compliant FFT built in with reasonable performance (vnl does not work)
| | ITKv4 will provide improved support for |
| # Mac Accelerate framework, Intel MLK,
| |
|
| |
|
| * Need adaptors for some subsets of (SVD/LAPACK/BLAS) numerics: | | * [[ITK_Release_4/Video|Video]] |
| # Should be able to take advantage of the Mac Acclerate, Intel MLK, Atlas or others with minimal end user configuration
| | * [[ITK_Release_4/Microscopy|Microscopy]] |
| | * [[ITK_Release_4/Remote Sensing|Remote Sensing]] |
|
| |
|
| *Remove NeuralNetwork
| | = Discussion Points = |
| # The current implementation in ITK requires that the network architecture and Input/Output routines be completely defined at compile-time. This severely limits the utility of the current implementation. The Input/Output mechanism of the current Neural Network currently only supports a proprietary network file format. This limits the ability to analyze the networks with complex external tools such as Matlab Neural Network toolkit.
| |
|
| |
|
| * Coding style, and enforcement:
| | [[ITK_Release_4/Discussion Points|Discussion Points]] |
| # There should be some system somewhere that is compliant with the ITK coding style. It would be preferable if the primary development editors (VS, vim, emacs) could all be configured to support the style consistently.
| |
| # The uncrustify program MAY allow a conduit for helping new developers format to be KWSTYLE compliant.
| |
|
| |
|
| * All process object outputs should be available as data objects (including native types)
| | = Outreach = |
| # There are times when a filter computes a value that is used as input into later stages of the pipeline, there needs to be a way to easily link filters and have the pipeline work properly even when the linkage is a simple integer.
| |
|
| |
|
| * Should the default behavior of all filters be to release their input data
| | [[ITK_Release_4/Outreach|Outreach]] |
| # This may address the complaint that ITK has unacceptable memory usage.
| |
|
| |
|
| * All class objects that end in "2" as a mechanism to fix bugs, and not break backwards compatibility should be removed.
| | = New Code Contribution Process = |
|
| |
|
| * itk_hashtable.h should be investigated to determine if a more standard implementation could replace the existing version. The current version has many different implementations for dealing with different compiler bases.
| | [[ITK_Release_4/New_Code_Contribution_Process|New Code Contribution Process]] |
