ITK/Release 4/Modularization/Use Cases: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
 
(3 intermediate revisions by one other user not shown)
Line 57: Line 57:


== For Contributing back to ITK ==
== For Contributing back to ITK ==
* A graduate student has been writing ITK code for a while
* Decides to be a good citizen and contribute the code back to the ITK community.
* How can she organize and package this code to make easier to share it with the community.
** E.g. to make easier to submit it to the Insight Journal
** And then when an IJ reader downloads the paper, the code will already be configured as a ready-to-use module (including the dependencies on existing modules).
= Researcher Developing New Code =
* Hosted in a separate Git repository
* Potentially to rework existing ITK code (improve performance, or debug)
* How should this researcher structure her code into a repository (separate from ITK)
* How should that repository be integrated into the ITK checkout
** For the purpose of testing and distribution

Latest revision as of 16:00, 9 December 2011

This page lists typical use cases of the ITK modularization

BioFormats

  • Goal: Distribute a binary build of the BioFormats ITK binding
  • Requirement: Include on it only the pieces of ITK that are used.
  • In practice:
    • Enable only the "kernel" and "io-base" modules
    • make
    • make package


RITK

The R-Package that contains SimpleITK should only carry with it the source code of ITK that is needed for the build.

  • Goal: Distribute a source package that CRAN can build for many platforms
  • Requirement: It must be self-contained. It must be as small as possible
  • In practice:
    • Enable only the modules used by SimpleITK

Medical Device

In order to facilitate the FDA approval process for a medical device whose software uses ITK, it is desirable and convenient to extract from ITK only the source code used by the medical device software.

  • Goal: Package the source code of ITK that is used by a medical device
  • Requirement: It must be minimal, and self-sufficient.
  • In practice:
    • During the development process of the medical device the ITK modules will be identified, and enabled
    • A customized package of ITK source code will be generated, tagged and tested for regulatory compliance.

Linux Packaging

When packaging ITK for Linux, some of the typical tasks that the packager must do are

  • Remove all the third party libraries (png, jpeg, tiff, vxl, zlib...)
  • Remove the "Review" directory

Once ITK is modularized, these two tasks should become a lot simpler.

A Linux packager will be able to

  • Start from a full ITK source tree,
  • Configure it with CMake and
    • enable / disable the proper set of modules
  • Build it for testing
  • Package it with CPack

The resulting binary and source packages will contain only the modules that were enabled at configuration time.

Graduate Student Writing ITK Extensions

For Private Use

  • A graduate student gets introduced to ITK and needs to write new customized code intended to support her dissertation
  • What is the easiest starting process to get her code to build along with ITK.

For Contributing back to ITK

  • A graduate student has been writing ITK code for a while
  • Decides to be a good citizen and contribute the code back to the ITK community.
  • How can she organize and package this code to make easier to share it with the community.
    • E.g. to make easier to submit it to the Insight Journal
    • And then when an IJ reader downloads the paper, the code will already be configured as a ready-to-use module (including the dependencies on existing modules).

Researcher Developing New Code

  • Hosted in a separate Git repository
  • Potentially to rework existing ITK code (improve performance, or debug)
  • How should this researcher structure her code into a repository (separate from ITK)
  • How should that repository be integrated into the ITK checkout
    • For the purpose of testing and distribution