https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Jhlegarreta&feedformat=atomKitwarePublic - User contributions [en]2024-03-28T21:40:44ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=ITK&diff=65226ITK2023-11-09T13:56:00Z<p>Jhlegarreta: Update the ITK CDash dashboard URL address</p>
<hr />
<div>[[File:Itk.png|center|150x100px]] <br />
<br />
The National Library of Medicine '''[http://www.itk.org/ Insight Segmentation and Registration Toolkit]''' (ITK) is an open-source software system for medical image processing in two, three and more dimensions. <br />
<br />
This is the '''''ITK Wiki''''', a collaborative hypertext database of information, documentation and resources.<br />
<br />
__TOC__<br />
<br />
== Overview ==<br />
<br />
* <big><strong>[[ITK/Getting Started|Getting Started with ITK]]</strong></big><br />
* [[ITK/About|About the Insight Toolkit]]<br />
* [[ITK/FAQ|Frequently Asked Questions (FAQ)]]<br />
* [[ITK/License Information| License Information]]<br />
<br />
== Software Process ==<br />
* [https://github.com/InsightSoftwareConsortium/ITK Git repository] : The version controlled repository.<br />
* [http://review.source.kitware.com/#/q/status:open+project:ITK,n,z Gerrit code review] : Our code review system.<br />
* [http://issues.itk.org/ Issue tracking system] : Where we report and browse bugs.<br />
* [https://open.cdash.org/index.php?project=Insight Nightly build dashboard] : View the build status on a variety of platforms.<br />
* [[ITK/Development | Development]]<br />
<br />
== Resources ==<br />
<br />
* [[ITK/Documentation| Documentation]]<br />
* [[ITK/Community | Community Corner]]<br />
* [[ITK/Academic | Academic Corner]]<br />
* [[ITK/Professional | Professional Corner]]<br />
* [[ITK/Open_Science| Open Science]]<br />
* [[ITK/Other_Software| Other Software]]<br />
<br />
{{ITKRegister}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Third_Party_Applications&diff=65225ITK/Third Party Applications2023-11-08T13:12:15Z<p>Jhlegarreta: Fix Python(x,y) link</p>
<hr />
<div>This page lists all the applications that are known to use the Insight Toolkit. Feel free to add your own project details. The only criteria for being listed is that the software uses the ITK libraries in some way (whether built in or by plugin).<br />
<br />
===Applications===<br />
<br />
* '''[http://www.analyzedirect.com/ Analyze]''' Analyze Software from Mayo Clinic BIR<br />
* '''[http://www.bioimagesuite.org/ BioImage Suite]''' integrated image analysis software suite developed at Yale University<br />
* '''[http://www.bioimagexd.net/ BioimageXD]'''<br />
* '''[http://gofigure2.sourceforge.net/ GoFigure2]''' Software to "visualize and navigate into 4D multichannels bio-images, extract objects, track sub-cellular structures, cell division and generate and visualize lineage"<br />
* '''[http://www-sop.inria.fr/asclepios/software.php MedINRIA]''' and associated libraries and software developed within the Asclepios research project, at INRIA Sophia-Antipolis. <br />
* '''[http://www.osirix-viewer.com/ Osirix]''' Medical imaging navigation and visualization tool that supports DICOM. Native Mac OS X Cocoa. Open Source. <br />
* '''[http://www.sci.utah.edu/cibc/software/42-seg3d.html Seg3D]'''<br />
* '''[http://www.slicer.org/ 3D Slicer]''' Application and framework for medical image analysis, visualization, and surgical navigation. (BSD License)<br />
* '''[http://www.itksnap.org ITK-SNAP]''' Level Sets Segmentation Tool<br />
* '''[http://penglab.janelia.org/proj/v3d/ V3D]''' "A Swiss army knife for bioimage visualization & analysis"<br />
* '''[http://www.kitware.com/products/volview.html VolView]''' An intuitive, interactive system for volume visualization that allows researchers and clinicians to quickly explore complex 3D medical or scientific images. <br />
* '''[http://www.creatis.insa-lyon.fr/rio/vv VV]''' "the 4D Slicer .. fast, simple viewer .. designed for qualitative evaluation of image registration."<br />
<br />
===Visual/dataflow programming===<br />
<br />
* '''[http://visualisation.tudelft.nl/Projects/DeVIDE DeVIDE]''' Delft Visualization Development Environment (rapid prototyping package with Python+VTK+ITK+more).<br />
* '''[http://www.mevislab.de/ MeVisLab]''' modular framework for the development of image processing algorithms, visualization, interaction methods, with a special focus on medical imaging.<br />
* '''[http://software.sci.utah.edu/scirun.html SCIRun]''' "SCIRun is a Problem Solving Environment (PSE), for modeling, simulation and visualization of scientific problems."<br />
* '''[http://www.vistrails.org/ VisTrails]''' "VisTrails is an open-source scientific workflow and provenance management system"<br />
* '''[http://voreen.uni-muenster.de/ Voreen]''' is an open source rapid application development framework for the interactive visualization and analysis of multi-modal volumetric data sets.<br />
<br />
===Frameworks===<br />
<br />
* '''[http://elastix.isi.uu.nl/ Elastix]''' A toolkit for the (elastic) registration of images. <br />
* '''[http://www.gimias.org/ GIMIAS]'''<br />
* '''[http://co-me.ch/internal/marvin/index.en.html MARVIN]''' C++ application framework for rapid and simple development of medical applications. Part of [http://co-me.ch/ CO-ME Computer Aided and Image Guided Medical Interventions Network].<br />
* '''[http://www.mitk.org/ MITK]''' free open-source software system for development of interactive medical image processing software<br />
* '''[http://www.igstk.org/ IGSTK]''' free open-source toolkit for development of image guided interventions software<br />
* '''[http://www.orfeo-toolbox.org/otb/ Orfeo Toolbox]'''<br />
<br />
===Packages===<br />
<br />
* '''[https://python-xy.github.io/ Python(x,y)]''' "Scientific-oriented Python distribution" including ITK, VTK, and Qt.<br />
* '''[http://www.paulnovo.org/repository Ubuntu ITK]''' ITK packages for Ubuntu (includes compiled wrappings)<br />
<br />
===Utilities/helpers===<br />
* '''[http://matitk.cs.sfu.ca/ MATITK]''' With the help of MATITK, biomedical image computing researchers familiar with MATLAB can harness the power of ITK algorithms while avoiding learning C++ and dealing with low-level programming issues. See also on [http://www.mathworks.com/matlabcentral/fileexchange/12297 MW File exchange]<br />
* '''[http://github.com/thewtex/matlab-itk-import/tree/master Matlab ITK Import]''' : Import any file supported by ITK into The Mathworks Matlab. See also [[CMake:MatlabMex]]<br />
* '''[[ITK/Insight Applications|Insight Applications]]'''<br />
* '''[[ITK/CommandLineTools|Command line wrappers of ITK functionality]]'''<br />
<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=User:Jhlegarreta&diff=63171User:Jhlegarreta2019-04-28T19:16:22Z<p>Jhlegarreta: DOC: Update user info</p>
<hr />
<div>M.Sc. in Telecommunications Engineering, M.Sc. in Medical Physics, currently Ph.D. student in diffusion MRI.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Configuring_and_Building&diff=63170ITK/Configuring and Building2019-04-28T19:12:23Z<p>Jhlegarreta: STYLE: Fix typo</p>
<hr />
<div>== Configuring And Building ==<br />
<br />
This page describes the various ways of configuring and building ITK in common configurations. The build instructions are generally the same across platforms. Nuances will be noted.<br />
<br />
=== CMake ===<br />
<br />
ITK is configured with the cross-platform configuration tool, [http://cmake.org/ CMake]. CMake will create project files for your build system of choice, e.g. Makefile's, Visual Studio project files, KDevelop project files, etc. The content of these project files is based on a domain specific language kept in ''CMakeLists.txt'' files distributed with the source code, the results of introspecting of the software and hardware features available on a system, and the preferences of the user building the system.<br />
<br />
There are three executables used to perform a CMake:<br />
<br />
# '''cmake''': A command line interface.<br />
# '''ccmake''': An ncurses (terminal) GUI. (only available on Unix-like systems).<br />
# '''cmake-gui''': A Qt-based GUI.<br />
<br />
To perform a CMake configuration, we need three things:<br />
<br />
# [[ITK/Source | The source code directory]].<br />
# A different directory to perform the build (make this directory manually).<br />
# One of the three CMake executables.<br />
<br />
Configuration variables can have different types, e.g. a boolean, a string, a filepath, etc. By convention, most persistent configuration variable names are composed of all capital letters and underscores such as ''BUILD_SHARED_LIBS''. For this reason, they may resemble environmental variables, but they are not environmental variables.<br />
<br />
Persistent configuration variables are stored in a file called ''CMakeCache.txt'' that lives at the top level of the build directory. It is possible to edit these variables by hand before re-running the CMake executable. Any variable can be changed at any time '''except''' the path to the C and C++ compiler. Since changing compiler in the middle of a build will often result in an unusable build, this is not allowed. To specify a different compiler other than the first one that is found by the system, it must be specified at the initial CMake configuration. This is performed with the dialog box that pops up when the build tree is empty for ''cmake-gui''. The paths to the desired C compiler and C++ compiler can be specified with the ''CC'' and ''CXX'' environmental variables for the ''cmake'' and ''ccmake'' executables.<br />
<br />
==== Configuration with the '''cmake''' executable ====<br />
<br />
The ''cmake'' executable is the simplest executable, and it is appropriate for shell use or scripting. To use the executable, first change your current working directory to the build directory. For example,<br />
<br />
cd ~/bin/ITK<br />
<br />
Next, run the ''cmake'' executable. For a first time configuration, the required argument is the path to the top level of the source tree. For example,<br />
<br />
cmake ~/src/ITK<br />
<br />
Configuration variables can be specified with the ''-D'' option. For instance,<br />
<br />
cmake -DBUILD_SHARED_LIBS=ON ~/src/ITK<br />
<br />
Make sure configuration completes successfully without any errors. Fix an errors and re-run <br />
<br />
Once the project has been configured, it can be built with your build system of choice. For a list of build systems available, see the list of "Generators" at the end of the ''cmake --help'' output. A different generator can be specified with the ''-G'' flag to ''cmake''.<br />
<br />
On Linux and Mac, the default generator is ''Unix Makefiles'', so the build can be started by invoking the ''make'' executable:<br />
<br />
make<br />
<br />
On Windows, the default generator is a Visual Studio project file, so this file can be opened and the build started.<br />
<br />
==== Configuration with the '''ccmake''' executable ====<br />
<br />
Again, the curses interface, ''ccmake'', is only available on Linux on Mac. Command line arguments are largely the same as the ''cmake'' executable. After startup, though, a curses interface will present an interface to edit the CMake variables. Pressing '''h''' will show the following help:<br />
<br />
CMake is used to configure and generate build files for software projects. The<br />
basic steps for configuring a project with ccmake are as follows:<br />
<br />
1. Run ccmake in the directory where you want the object and executable files to<br />
be placed (build directory). If the source directory is not the same as this build<br />
directory, you have to specify it as an argument on the command line.<br />
<br />
2. When ccmake is run, it will read the configuration files and display the<br />
current build options. If you have run CMake before and have updated the<br />
configuration files since then, any new entries will be displayed on top and will<br />
be marked with a *. On the other hand, the first time you run ccmake, all build<br />
options will be new and will be marked as such. At this point, you can modify any<br />
options (see keys below) you want to change. When you are satisfied with your<br />
changes, press 'c' to have CMake process the configuration files. Please note that<br />
changing some options may cause new ones to appear. These will be shown on top and<br />
will be marked with *. Repeat this procedure until you are satisfied with all the<br />
options and there are no new entries. At this point, a new command will appear:<br />
Generate and Exit. You can now hit 'g' to have CMake generate all the build files<br />
(i.e. makefiles or project files) and exit. At any point during the process, you<br />
can exit ccmake with 'q'. However, this will not generate/change any build files.<br />
<br />
ccmake KEYS:<br />
<br />
Navigation: You can use the arrow keys and page up, down to navigate the options.<br />
Alternatively, you can use the following keys:<br />
* C-n : next option<br />
* C-p : previous options<br />
* C-d : down one page<br />
* C-u : up one page<br />
<br />
Editing options: To change an option press enter or return. If the current<br />
options is a boolean, this will toggle it's value. Otherwise, ccmake will enter<br />
edit mode. In this mode you can edit an option using arrow keys and backspace.<br />
Alternatively, you can use the following keys:<br />
* C-b : back one character<br />
* C-f : forward one character<br />
* C-a : go to the beginning of the field<br />
* C-e : go to the end of the field<br />
* C-d : delete previous character<br />
* C-k : kill the rest of the field<br />
* Esc : Restore field (discard last changes)<br />
* Enter : Leave edit mode<br />
You can also delete an option by pressing 'd'<br />
<br />
Commands:<br />
* q : quit ccmake without generating build files<br />
* h : help, shows this screen<br />
* c : process the configuration files with the current options<br />
* g : generate build files and exit, only available when there are no new options<br />
and no errors have been detected during last configuration.<br />
* l : shows last errors<br />
* t : toggles advanced mode. In normal mode, only the most important options are<br />
shown. In advanced mode, all options are shown. We recommend using normal mode<br />
unless you are an expert.<br />
* / : search for a variable name.<br />
<br />
==== Configuration with the '''cmake-gui''' executable ====<br />
<br />
The cross-platform Qt GUI is a convenient platform for performing configuration. First, enter the location of the source and build directories. Next hit the ''Configure'' button. You will be prompted to choose the compiler and the program will perform the initial configuration. Configuration variables can be edited with the user interface. You may need to hit the ''Configure'' button multiple times as new configuration options may result from previous runs. Finally, hit the ''Generate'' button to produce the files for your build system of choice. Execute the project file or Makefile generated in the build directory.<br />
<br />
=== Using a predefined Configuration ===<br />
<br />
CMake can be run interactively to configure a build, in which case all settings begin with system defaults (as determined by <tt>CMakeLists.txt</tt>) and the user customises them.<br />
<br />
Alternatively, a predefined configuration (such as those shown above) can be provided, which will provide initial settings for the build (also known as ''priming''). By creating a file called <tt>CMakeCache.txt</tt> in the top level of the build directory, the settings defined therein will be used to override the default settings for the build.<br />
<br />
== Platform Specific Guides ==<br />
=== Windows ===<br />
* [[ITK/Configuring_and_Building/VisualStudio|Visual Studio]]<br />
* [[ITK/Configuring_and_Building/QtCreator|QtCreator]]<br />
* [[ITK/Configuring_and_Building/MinGW|MinGW]]<br />
<br />
== Wrapping ITK ==<br />
<br />
ITK can be wrapped for several different languages such as Python, Tcl and Java. <br />
<br />
* [[ITK/Java Wrapping|Java wrapping]] guide<br />
* [[ITK/Python Wrapping|Python wrapping]] guide<br />
* [[ITK/WrapITK Status|WrapITK status]]<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=File:GitITKCheatSheet.pdf&diff=62964File:GitITKCheatSheet.pdf2018-11-13T01:47:48Z<p>Jhlegarreta: Jhlegarreta uploaded a new version of &quot;File:GitITKCheatSheet.pdf&quot;</p>
<hr />
<div>ITK cheat sheet for development of project using branchy workflow, Gerrit, topic stage etc.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Template:ITKCMakeLists&diff=62631Template:ITKCMakeLists2018-04-25T17:25:30Z<p>Jhlegarreta: /* CMakeLists.txt */ Update the cmake_minimum_required version to match ITK's current</p>
<hr />
<div>==CMakeLists.txt==<br />
{{#tag:syntaxhighlight<br />
|<br />
cmake_minimum_required(VERSION 3.9.5)<br />
<br />
project({{{1}}})<br />
<br />
find_package(ITK REQUIRED)<br />
include(${ITK_USE_FILE})<br />
if (ITKVtkGlue_LOADED)<br />
find_package(VTK REQUIRED)<br />
include(${VTK_USE_FILE})<br />
endif()<br />
<br />
add_executable({{{1}}} MACOSX_BUNDLE {{{1}}}.cxx)<br />
<br />
if( "${ITK_VERSION_MAJOR}" LESS 4 )<br />
target_link_libraries({{{1}}} ITKReview ${ITK_LIBRARIES})<br />
else( "${ITK_VERSION_MAJOR}" LESS 4 )<br />
target_link_libraries({{{1}}} ${ITK_LIBRARIES})<br />
endif( "${ITK_VERSION_MAJOR}" LESS 4 )<br />
<br />
|lang=cmake}}<br />
<br />
==Download and Build {{{1}}}==<br />
Click [https://github.com/lorensen/ITKWikiExamplesTarballs/raw/master/{{{1}}}.tar here to download ''{{{1}}}''] and its ''CMakeLists.txt'' file.<br />
Once the tarball ''{{{1}}}.tar'' has been downloaded and extracted,<br />
cd {{{1}}}/build<br />
* If ITK is installed:<br />
cmake ..<br />
* If ITK is not installed but compiled on your system, you will need to specify '''the path to your ITK build''':<br />
cmake -DITK_DIR:PATH='''/home/me/itk_build''' ..<br />
Build the project:<br />
make<br />
and run it:<br />
./{{{1}}}<br />
'''WINDOWS USERS PLEASE NOTE:''' Be sure to add the ITK bin directory to your path. This will resolve the ITK dll's at run time.<br />
<br />
==Building All of the Examples==<br />
Many of the examples in the ITK Wiki Examples Collection require VTK. You can build all of the the examples by following [[ITK/Examples/Instructions/ForUsers#Build_all_of_the_examples|these instructions]]. If you are a new VTK user, you may want to try the [[ITK/Examples/Instructions/ForUsers#Use_the_Superbuild_to_build_a_proper_VTK_and_ITK|Superbuild]] which will build a proper ITK and VTK.<br />
==ItkVtkGlue==<br />
===ITK >= 4===<br />
For examples that use QuickView (which depends on VTK), you must have built ITK with Module_ITKVtkGlue=ON.<br />
<br />
===ITK < 4===<br />
Some of the ITK Examples require VTK to display the images. If you download the entire ITK Wiki Examples Collection, the ItkVtkGlue directory will be included and configured. If you wish to just build a few examples, then you will need to [https://github.com/InsightSoftwareConsortium/ITKWikiExamples/raw/master/ItkVtkGlue.tar.gz download ItkVtkGlue] and build it. When you run cmake it will ask you to specify the location of the ItkVtkGlue binary directory.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/SimpleOperations/Offset&diff=62630ITK/Examples/SimpleOperations/Offset2018-04-25T05:52:53Z<p>Jhlegarreta: Update according to PR #12: https://github.com/InsightSoftwareConsortium/ITKWikiExamples/pull/12/files</p>
<hr />
<div>==Offset.cxx==<br />
<br />
<source lang="cpp"><br />
<br />
#include "itkIndex.h"<br />
#include "itkOffset.h"<br />
<br />
#include <iostream><br />
<br />
int main( int, char* [] )<br />
{<br />
itk::Index<2> index;<br />
index[0] = 5;<br />
index[1] = 5;<br />
<br />
itk::Offset<2> offset;<br />
offset[0] = 1;<br />
offset[1] = 1;<br />
<br />
std::cout << offset << std::endl;<br />
<br />
std::cout << index + offset << std::endl;<br />
<br />
return EXIT_SUCCESS;<br />
}<br />
<br />
</source><br />
<br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/Segmentation/VoronoiDiagram2DGenerator&diff=62629ITK/Examples/Segmentation/VoronoiDiagram2DGenerator2018-04-25T05:51:31Z<p>Jhlegarreta: /* VoronoiDiagram2DGenerator.cxx */ Update according to PR #12: https://github.com/InsightSoftwareConsortium/ITKWikiExamples/pull/12/files</p>
<hr />
<div>==VoronoiDiagram2DGenerator.cxx==<br />
<br />
<source lang="cpp"><br />
<br />
#include "itkVoronoiDiagram2DGenerator.h"<br />
#include "itkImageFileWriter.h"<br />
#include "itkVTKPolyDataWriter.h"<br />
<br />
int main( int, char* [] )<br />
{<br />
constexpr double height = 100;<br />
constexpr double width = 100;<br />
<br />
using VoronoiDiagramType = itk::VoronoiDiagram2D<double>;<br />
using VoronoiGeneratorType = itk::VoronoiDiagram2DGenerator<double>;<br />
<br />
using PointType = VoronoiDiagramType::PointType;<br />
using CellType = VoronoiDiagramType::CellType;<br />
using CellAutoPointer = VoronoiDiagramType::CellAutoPointer;<br />
using PointIdIterator = CellType::PointIdIterator;<br />
using NeighborIdIterator = VoronoiDiagramType::NeighborIdIterator;<br />
<br />
VoronoiDiagramType::Pointer voronoiDiagram = VoronoiDiagramType::New();<br />
VoronoiGeneratorType::Pointer voronoiGenerator = VoronoiGeneratorType::New();<br />
<br />
PointType insize;<br />
insize[0] = width;<br />
insize[1] = height;<br />
voronoiGenerator->SetBoundary(insize);<br />
<br />
// Create a list of seeds<br />
std::vector<PointType> seeds;<br />
PointType seed0;<br />
seed0[0] = 50;<br />
seed0[1] = 50;<br />
seeds.push_back(seed0);<br />
<br />
PointType seed1;<br />
seed1[0] = 25;<br />
seed1[1] = 25;<br />
seeds.push_back(seed1);<br />
<br />
PointType seed2;<br />
seed2[0] = 75;<br />
seed2[1] = 25;<br />
seeds.push_back(seed2);<br />
<br />
PointType seed3;<br />
seed3[0] = 25;<br />
seed3[1] = 75;<br />
seeds.push_back(seed3);<br />
<br />
PointType seed4;<br />
seed4[0] = 75;<br />
seed4[1] = 75;<br />
seeds.push_back(seed4);<br />
<br />
for(const auto & seed : seeds)<br />
{<br />
voronoiGenerator->AddOneSeed(seed);<br />
}<br />
<br />
voronoiGenerator->Update();<br />
voronoiDiagram = voronoiGenerator->GetOutput();<br />
<br />
for(unsigned int i = 0; i < seeds.size(); i++)<br />
{<br />
PointType currP = voronoiDiagram->GetSeed(i);<br />
std::cout << "Seed No." << i << ": At (" << currP[0] << "," << currP[1] << ")" << std::endl;<br />
std::cout << " Boundary Vertices List (in order):";<br />
CellAutoPointer currCell;<br />
voronoiDiagram->GetCellId(i, currCell);<br />
PointIdIterator currCellP;<br />
for(currCellP = currCell->PointIdsBegin(); currCellP != currCell->PointIdsEnd(); ++currCellP)<br />
{<br />
std::cout << (*currCellP) << ",";<br />
}<br />
std::cout << std::endl;<br />
std::cout << " Neighbors (Seed No.):";<br />
NeighborIdIterator currNeibor;<br />
for(currNeibor = voronoiDiagram->NeighborIdsBegin(i); currNeibor != voronoiDiagram->NeighborIdsEnd(i); ++currNeibor)<br />
{<br />
std::cout << (*currNeibor) << ",";<br />
}<br />
std::cout << std::endl << std::endl;<br />
}<br />
<br />
std::cout << "Vertices Informations:" << std::endl;<br />
VoronoiDiagramType::VertexIterator allVerts;<br />
int j = 0;<br />
for(allVerts = voronoiDiagram->VertexBegin(); allVerts != voronoiDiagram->VertexEnd(); ++allVerts)<br />
{<br />
std::cout << "Vertices No." << j;<br />
j++;<br />
#if ITK_VERSION_MAJOR < 4<br />
std::cout << ": At (" << (*allVerts)[0] << "," << (*allVerts)[1] << ")" << std::endl;<br />
#else<br />
std::cout << ": At (" << (allVerts.Value())[0] << "," << (allVerts.Value())[1] << ")" << std::endl;<br />
#endif<br />
}<br />
<br />
// Write the resulting mesh<br />
using WriterType = itk::VTKPolyDataWriter<VoronoiDiagramType::Superclass>;<br />
WriterType::Pointer vtkPolyDataWriter = WriterType::New();<br />
vtkPolyDataWriter->SetInput(voronoiDiagram);<br />
vtkPolyDataWriter->SetFileName("voronoi.vtk");<br />
vtkPolyDataWriter->Update();<br />
<br />
// Setup an image to visualize the input<br />
{<br />
using ImageType = itk::Image< unsigned char, 2>;<br />
<br />
ImageType::IndexType start;<br />
start.Fill(0);<br />
<br />
ImageType::SizeType size;<br />
size.Fill(100);<br />
<br />
ImageType::RegionType region(start,size);<br />
<br />
ImageType::Pointer image = ImageType::New();<br />
image->SetRegions(region);<br />
image->Allocate();<br />
image->FillBuffer(0);<br />
<br />
ImageType::IndexType ind;<br />
ind[0] = 50;<br />
ind[1] = 50;<br />
image->SetPixel(ind, 255);<br />
<br />
ind[0] = 25;<br />
ind[1] = 25;<br />
image->SetPixel(ind, 255);<br />
<br />
ind[0] = 75;<br />
ind[1] = 25;<br />
image->SetPixel(ind, 255);<br />
<br />
ind[0] = 25;<br />
ind[1] = 75;<br />
image->SetPixel(ind, 255);<br />
<br />
ind[0] = 75;<br />
ind[1] = 75;<br />
image->SetPixel(ind, 255);<br />
<br />
using ImageWriterType = itk::ImageFileWriter< ImageType >;<br />
ImageWriterType::Pointer imageFileWriter = ImageWriterType::New();<br />
imageFileWriter->SetFileName("image.png");<br />
imageFileWriter->SetInput(image);<br />
imageFileWriter->Update();<br />
}<br />
<br />
return EXIT_SUCCESS;<br />
}<br />
<br />
</source><br />
<br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/Iterators/ImageRandomConstIteratorWithIndex&diff=62628ITK/Examples/Iterators/ImageRandomConstIteratorWithIndex2018-04-25T05:49:15Z<p>Jhlegarreta: Update example according to PR #10: https://github.com/InsightSoftwareConsortium/ITKWikiExamples/pull/10/files</p>
<hr />
<div>==ImageRandomConstIteratorWithIndex.cxx==<br />
<br />
<source lang="cpp"><br />
<br />
#include "itkImage.h"<br />
#include "itkImageFileReader.h"<br />
#include "itkImageRandomConstIteratorWithIndex.h"<br />
<br />
int main(int, char *[])<br />
{<br />
using ImageType = itk::Image<unsigned char, 2>;<br />
ImageType::Pointer image = ImageType::New();<br />
<br />
ImageType::SizeType regionSize;<br />
regionSize[0] = 5;<br />
regionSize[1] = 4;<br />
<br />
ImageType::IndexType regionIndex;<br />
regionIndex[0] = 0;<br />
regionIndex[1] = 0;<br />
<br />
ImageType::RegionType region;<br />
region.SetSize(regionSize);<br />
region.SetIndex(regionIndex);<br />
<br />
image->SetRegions(region);<br />
image->Allocate();<br />
image->FillBuffer(0);<br />
<br />
itk::ImageRandomConstIteratorWithIndex<ImageType> imageIterator(image, image->GetLargestPossibleRegion());<br />
imageIterator.SetNumberOfSamples(200);<br />
imageIterator.GoToBegin();<br />
<br />
while(!imageIterator.IsAtEnd())<br />
{<br />
std::cout << imageIterator.GetIndex() << std::endl;<br />
<br />
++imageIterator;<br />
}<br />
<br />
return EXIT_SUCCESS;<br />
}<br />
<br />
</source><br />
<br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=62220ITK/Coding Style Guide2018-03-17T12:11:21Z<p>Jhlegarreta: Add the historical label/banner. This information was added to the ITK Software Guide.</p>
<hr />
<div>{{ Historical }}<br />
<br />
= C++ Code Style =<br />
<br />
The document located [[media:ITKStyle.pdf|HERE]] describes ITK coding conventions. Developers should follow these conventions when submitting contributions.<br />
<br />
ITK Style Guide<br />
Insight Software Consortium<br />
<br />
== Purpose ==<br />
<br />
The following document is a description of the accepted coding style for the NLM Insight Segmentation<br />
and Registration Toolkit (ITK). Developers who wish to contribute code to ITK should read<br />
and adhere to the standards described here.<br />
<br />
== Document Overview ==<br />
This document is organized into the following sections.<br />
<br />
* System Overview & Philosophy | coding methodologies and motivation for the resulting style.<br />
* Copyright | the copyright header to be included in all files and other copyright issues.<br />
* File organization | how to organize source code; a guide to the ITK directory structure.<br />
* Naming conventions | patterns used to name classes, variables, template parameters, and instance variables.<br />
* Namespaces | the use of namespaces.<br />
* Code Layout and Indentation | accepted standards for arranging code including indentation style.<br />
* Doxygen Documentation System | basic Doxygen formatting instructions.<br />
* Using Standard Macros (itkMacro.h) | use of standard macros in header files.<br />
* Exception Handling | how to add exception handling to the system.<br />
* Documentation Style | a brief section describing the documentation philosophy adopted by the Insight consortium.<br />
<br />
This style guide is an evolving document.<br />
<br />
Please dialog with the ITK developers if you wish to add, modify, or delete the rules described in these guidelines.<br />
<br />
See:<br />
<br />
http://www.itk.org/ITK/help/mailing.html<br />
<br />
for more information about joining the ITK developers mailing list. This forum is one of the best venues in which to propose changes to these style guidelines.<br />
<br />
== Style Guidelines ==<br />
<br />
The following coding-style guidelines have been adopted by the ITK community. To a large extent<br />
these guidelines are a result of the fundamental architectural and implementation decisions made<br />
early in the project. For example, the decision was made to implement ITK with a C++ core using<br />
principles of generic programming, so the rules are oriented towards this style of implementation.<br />
Some guidelines are relatively arbitrary, such as indentation levels and style. However, an attempt<br />
was made to find coding styles consistent with accepted practices. The point is to adhere to a<br />
common style to assist developers and users of the future learn, use, maintain, and extend ITK.<br />
(See the ITK Requirements document for more information.)<br />
Please do your best to be a upstanding member of the ITK community. The rules described here<br />
have been developed with the community as a whole in mind. If you consistently violate these rules<br />
you will likely be harassed mercilessly, first privately and then publicly. If this does not result in<br />
correct code layout, your right to CVS write access (if you are developer and wish to contribute<br />
code) may be removed. Similarly, if you wish to contribute code and are not a developer, your code<br />
will not be accepted until the style is consistent with these guidelines.<br />
<br />
=== System Overview & Philosophy ===<br />
The following implementation strategies have been adopted by the ITK community. These directly<br />
and indirectly affect the resulting code style. Understanding these strategies motivate the reasons<br />
for many of the style guidelines described in this document.<br />
<br />
==== Implementation Language ====<br />
<br />
The core implementation language is C++. C++ was chosen for its flexibility, performance, and<br />
familiarity to consortium members. (Auxiliary, interpreted language bindings such as Tcl, Python,<br />
and/or Java are also planned. These are aimply (run-time interpreted) layers on the C++ code.)<br />
ITK uses the full spectrum of C++ features including const and volatile correctness, namespaces,<br />
partial template specialization, operator overloading, traits, and iterators.<br />
<br />
==== Generic Programming and the STL ====<br />
<br />
Compile-time binding using methods of generic programming and template instantiation is the<br />
preferred implementation style. This approach has demonstrated its ability to create efficient,<br />
flexible code. Use of the STL (Standard Template Library) is encouraged. STL is typically used by<br />
a class, rather than as serving as a base class for derivation of ITK classes. Other STL influences<br />
are iterators and traits. ITK defines a large set of iterators; however, the ITK iterator style differs<br />
in many cases from STL because STL iterators follow a linear traversal model; ITK iterators are<br />
often designed for 2D, 3D, and even n-D traversal. Traits are used heavily be ITK. ITK naming<br />
conventions supersede STL naming conventions; this difference is useful in that it indicates to the<br />
developer something of the boundary between ITK and STL.<br />
<br />
==== Portability ====<br />
ITK is designed to compile on a set of target operating system/compiler combinations.<br />
<br />
These combinations include, but are not limited to:<br />
<br />
* Windows 9x/NT/2000/XP running<br />
** Microsoft Visual C++ version 7.1 to 10<br />
* Solaris with SunPro compiler <br />
* Linux running gcc<br />
* MacOSX running gcc<br />
* Intel compiler on Windows and Linux<br />
<br />
For a full list of the compilers supported please see:<br />
<br />
* [[ITK_Release_4/Modern C++|Modern C++]]<br />
<br />
==== Multi-Layer Architecture ====<br />
ITK is designed with a multi-layer architecture in mind. That is, three layers, a templated layer, a<br />
run-time layer, and an application layer. The templated (or generic) layer is written in C++ and<br />
requires significant programming skills and domain knowledge. The run-time layer is generated<br />
automatically using the CableSwig wrapping system to produce language bindings to Tcl, Python,<br />
and Java. The interpreted layer is easier to use than the templated layer, and can be used for<br />
prototyping and smaller-sized application development. Finally, the application layer is not directly<br />
addressed by ITK other than providing simple examples of applications.<br />
<br />
==== CMake Build Environment ====<br />
The ITK build environment is CMake. CMake is an open-source, advanced cross-platform build<br />
system that enables developers to write simple \makefiles" (named CMakeLists.txt) that are processed<br />
to generated native build tools for a particular operating system/compiler combinations.<br />
See the CMake web pages at http://www.cmake.org for more information.<br />
<br />
==== Doxygen Documentation System ====<br />
<br />
The Doxygen open-source system is used to generate on-line documentation. Doxygen requires the<br />
embedding of simple comments in the code which is in turn extracted and formatted into documentation.<br />
<br />
For more information about Doxygen, please see<br />
<br />
http://www.stack.nl/dimitri/doxygen/<br />
<br />
==== vnl Math Library ====<br />
ITK has adopted the vnl math library. Vnl is a portion of the vxl image understanding environment.<br />
See http://www.robots.ox.ac.uk/ vxl/ for more information about vxl and vnl.<br />
<br />
==== Reference Counting ====<br />
<br />
ITK has adopted reference counting via so-called "smart pointers" to manage object references.<br />
While alternative approaches such as automatic garbage collection were considered, their overhead<br />
due to memory requirements, performance, and lack of control as to when to delete memory, precluded<br />
these methods. Smart pointers manage the reference to objects, automatically incrementing<br />
and deleting an instance's reference count, deleting the object when the count goes to zero.<br />
These are the most important factors influencing the coding style found in Insight. Now we will<br />
look at the details.<br />
<br />
=== Copyright ===<br />
<br />
ITK has adopted a standard copyright. This copyright should be placed at the head of every source<br />
code file. The current copyright header and license reads as follows:<br />
<br />
<pre><nowiki><br />
/*========================================================================= <br />
* <br />
* Copyright Insight Software Consortium <br />
* <br />
* Licensed under the Apache License, Version 2.0 (the "License"); <br />
* you may not use this file except in compliance with the License. <br />
* You may obtain a copy of the License at <br />
* <br />
* http://www.apache.org/licenses/LICENSE-2.0.txt <br />
* <br />
* Unless required by applicable law or agreed to in writing, software <br />
* distributed under the License is distributed on an "AS IS" BASIS, <br />
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. <br />
* See the License for the specific language governing permissions and <br />
* limitations under the License. <br />
* <br />
*=========================================================================*/<br />
</nowiki></pre><br />
<br />
[[ITK Copyright Header|Copyright Header]]<br />
<br />
=== File Organization ===<br />
<br />
Classes are created and (usually) organized into a single class per file set. A file set consists of .h<br />
header file, .cxx implementation file, and/or a .hxx templated implementation file. Helper classes<br />
may also be defined in the file set, typically these are not visible to the system at large, or placed<br />
into a special namespace.<br />
<br />
Source files must be placed in the correct directory for logical consistency with the rest of the<br />
system, and to avoid cyclic dependencies. Currently the ITK source directory structure is found in<br />
ITK/Modules and consists of the following subdirectories:<br />
<br />
* Bridge<br />
* Core<br />
* External<br />
* Filtering<br />
* GPU<br />
* IO<br />
* Nonunit<br />
* Numerics<br />
* Registration<br />
* Segmentation<br />
* ThirdParty<br />
<br />
Each one of these directories represent a Group of Modules.<br />
<br />
Please discuss with the ITK Developers about the best Module to place your new code.<br />
<br />
For a full list of Modules, please see:<br />
<br />
http://www.itk.org/Doxygen/html/modules.html<br />
<br />
=== Naming Conventions ===<br />
<br />
In general, <br />
<br />
* Names are constructed by using case change to indicate separate words, as in TimeStamp<br />
(versus Time Stamp).<br />
* Underscores are not used.<br />
* Variable names are chosen carefully with the intention to convey the meaning behind the code.<br />
* Names are generally spelled out; use of abbreviations is discouraged. (Abbreviation are allowable when in common use, and should be in<br />
uppercase as in RGB.) While this does result in long names, it self-documents the code.<br />
* If you learn how to use name completion in your editor (e.g.,Vim, Emacs), this inconvenience can be minimized.<br />
<br />
Depending on whether the name is a<br />
<br />
* class<br />
* file<br />
* variable<br />
* or other name<br />
<br />
variations on this theme result as explained in the following subsections.<br />
<br />
==== Naming Classes ====<br />
<br />
* Classes are named beginning with a capital letter.<br />
* Classes are placed in the appropriate namespace, typically itk:: (see namespaces below).<br />
* Classes are named according to the following general rule:<br />
class name = <algorithm><input><concept><br />
* In this formula, the name of the algorithm or process (possibly with an associated adjective or<br />
adverb) comes first, followed by an input type (if the class is a filter), and completed by a concept<br />
name.<br />
* A concept is an informal classification describing what a class does. There are many<br />
concepts, here are a few of them.<br />
<br />
The more common or important concepts are underlined.<br />
<br />
* '''Accessor''' Access and convert between types.<br />
* '''Adaptor''' Provide access to a portion of a complex pixel type.<br />
* '''Boundary''' The boundary of a cell.<br />
* '''Calculator''' Compute information.<br />
* '''Classifier''' Classify a pixel.<br />
* '''Container''' A container of objects such as points or cells.<br />
* '''Estimator''' Estimate a value or condition.<br />
* '''Factory''' Object factories are used to create instances.<br />
* '''Filter''' A class that participates in the data processing pipeline. Filters typically take one or more inputs and produce one or more outputs.<br />
* '''Function''' Evaluate a function at a given position.<br />
* '''Identifier''' A unique id for accessing points, cells, or other entities.<br />
* '''Interface''' Classes that specify an abstract interface.<br />
* '''Interpolator''' Interpolate data values, for example at non-pixel values.<br />
* '''Iterator''' Traverse data in various ways (e.g., forward, backward, within a region, etc.)<br />
* '''Mapper''' Transform data from one form into another.<br />
* '''Metric''' Compute similarity between two objects.<br />
* '''Operator''' A class that applies a user-specified function to a region.<br />
* '''Optimizer''' A class that performs numerical optimization.<br />
* '''Pointer''' A smart pointer to an instance of a class. Almost all instance in ITK are referred to via smart pointers.<br />
* '''Reader''' A class that reads a single data object (e.g., image or mesh).<br />
* '''Reference''' A type that refers to another object.<br />
* '''Region''' A subset of a data object, such as an image region.<br />
* '''Source''' A filter that initiates the data processing pipeline such as a reader or a procedural data generator.<br />
* '''Threader''' A class that manages multi-threading.<br />
* '''Traits''' A collection of template parameters used to control the instantiation of other classes.<br />
* '''Transform''' Various types of transformations including affine, procedural, and so on.<br />
* '''Writer''' A filter that terminates the data processing pipeline by writing data to disk or to a communicationsport.<br />
<br />
<br />
The naming of classes is an art form; please review existing names to catch the spirit of the naming<br />
convention.<br />
<br />
Example names include:<br />
<br />
* ShrinkImageFilter<br />
* TriangleCell<br />
* ScalarImageRegionIterator<br />
* NeighborhoodIterator<br />
* MapContainer<br />
* DefaultImageTraits<br />
* BackwardDifferenceOperator<br />
<br />
==== Naming Files ====<br />
<br />
* Files should have the same name as the class, with an "itk" prepended.<br />
* Header files are named .h, while implementation files are named either .cxx or .hxx, depending on whether they are implementations of templated classes.<br />
** For example, the class itk::Image <br />
*** is declared in the file itkImage.h and<br />
*** is defined in the file itkImage.hxx (because Image is templated).<br />
** The class itk::Object<br />
*** is declared in the file itkObject.h<br />
*** and is defined in the file itkObject.cxx<br />
<br />
==== Naming Methods and Functions ====<br />
Global functions and class methods, either static or class members, are named beginning with<br />
a capital letter. The biggest challenge when naming methods and functions is to be consistent<br />
with existing names. For example, given the choice between ComputeBoundingBox() and<br />
CalculateBoundingBox() (CalcBoundingBox() is not allowed because it is not spelled out), the<br />
choice is ComputeBoundingBox() because \Compute" is used elsewhere in the system in similar<br />
settings (The concepts described previously should be used whenever possible).<br />
When referring to class methods in code, an explicit this-> pointer should be used, as in this->ComputeBoundingBox().<br />
The use of the explicit this-> pointer helps clarify exactly which method, and where it originates,<br />
is being invoked. Similarly the \::" global namespace should be used when referring to a global<br />
function.<br />
<br />
==== Naming Class Data Members ====<br />
<br />
Class data members are prepended with m as in m_Size. This clearly indicates the origin of data<br />
members, and differentiates them from all other variables.<br />
<br />
==== Naming Local Variables ====<br />
Local variables begin in lowercase. There is more <br />
flexibility in the naming of local variables; please<br />
remember that others will study, maintain, fix, and extend your code. Any bread crumbs that<br />
you can drop in the way of explanatory variable names and comments will go a long way towards<br />
helping other developers.<br />
<br />
==== Naming Template Parameters ====<br />
Template parameters follow the usual rules with naming except that they should start with either<br />
the capital letter T or V. Type parameters begin with the letter T while value template parameters<br />
begin with the letter V.<br />
<br />
* For template parameters the use of "typename" is preferred over "class". Very early c++ compilers did not have a "typename" keyword, and "class" was repurposed for declaring template parameters. It was later discovered that this lead to ambiguity in some valid code constructs, and the "typename" key word was added. It is often agreed (http://blogs.msdn.com/b/slippman/archive/2004/08/11/212768.aspx) that "typename" is marginally more expressive in its intent and ITK should consistently use "typename" instead of "class".<br />
<br />
==== Naming Typedefs ====<br />
Typedefs are absolutely essential in generic programming. They significantly improve the readibility<br />
of code, and facilitate the declaration of complex syntactic combinations. Unfortunately, creation<br />
of typedefs is tantamount to creating another programming language. Hence typedefs must be used<br />
in a consistent fashion.<br />
The general rule for typedef names is that they end in the word Type. For example<br />
typedef TPixel PixelType;<br />
However, there are many exceptions to this rule that recognize that ITK has several important<br />
concepts that are expressed partially in the names used to implement the concept. An iterator is a<br />
concept, as is a container or pointer. These concepts are used in preference to Type at the end of<br />
a typedef as appropriate. For example<br />
<source lang="cpp"><br />
typedef typename ImageTraits::PixelContainer PixelContainer;<br />
</source><br />
Here Container is a concept used in place of Type.<br />
ITK currently identifies the following concepts used when naming typedefs.<br />
* Self as in typedef Image Self;. All classes should define this typedef.<br />
* Superclass as in typedef ImageBase<VImageDimension> Superclass;. All classes should define the Superclass typedef.<br />
* Pointer as in a smart pointer to an object as in typedef SmartPointer<Self> Pointer;<br />
* Container is a type of container class.<br />
* Iterator an iterator over some container class.<br />
* Identifier or id such as a point or cell id.<br />
<br />
==== Using Underscores ====<br />
Don't use them. The only exception is when defining preprocessor variables and macros (which are<br />
discouraged). In this case, underscores are allowed to separate words.<br />
<br />
==== Preprocessor Directives ====<br />
<br />
* Some of the worst code contains many preprocessor directives and macros. Do not use them except in a very limited sense (to support minor differences in compilers or operating systems). <br />
* If a class makes extensive use of preprocessor directives, it is a candidate for separation into multiple sub-classes.<br />
<br />
==== Header Includes ====<br />
<br />
Header includes use the style<br />
<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
</source><br />
<br />
Only the required headers should be included. If an included header already includes a header for a class also used in the current file, the header for that class should not be included.<br />
<br />
Header includes are preferred over forward declarations. Forward declarations are only used to prevent circular dependencies.<br />
<br />
==== Namespaces ====<br />
<br />
All classes should be placed in the itk:: namespace. Additional sub-namespaces are being designed to support special functionality.<br />
<br />
Please see current documentation to determine if there is a subnamespace is relevant to your situation. Normally sub-namespaces are used for helper ITK classes.<br />
<br />
Code should not use ''using namespace''. This is to avoid namespace conflicts, but, more importantly, to improve readability.<br />
<br />
When declaring or defining members of the "itk" namespace, for example, the 'itk::' namespace prefix should not be added. That is, code within "namespace itk { ... }" should not used "itk::".<br />
<br />
==== Const Correctness ====<br />
<br />
Const correctness is important. Please use it as appropriate to your class or method.<br />
<br />
==== Code Layout and Indentation ====<br />
<br />
The following are the accepted ITK code layout rules and indentation style. After reading this section, you may wish to visit many of the source files found in ITK. This will help crystallize the rules described here.<br />
<br />
==== General Layout ====<br />
<br />
* Each line of code should take no more than 200 characters.<br />
* Break the code across multiple lines as necessary.<br />
* Use lots of whitespace to separate logical blocks of code, intermixed with comments.<br />
* To a large extent the structure of code directly expresses its implementation.<br />
* The appropriate indentation level is '''two spaces''' for each level of indentation.<br />
* '''DO NOT USE TABS.'''<br />
** Set up your editor to insert spaces. Using tabs may look good in your editor but will wreak havoc in others.<br />
* The declaration of variables within classes, methods, and functions should be one declaration per line.<br />
<br />
<source lang="cpp"><br />
int i;<br />
int j;<br />
char* stringname;<br />
</source><br />
<br />
==== Class Layout ====<br />
<br />
Classes are defined using the following guidelines.<br />
* Begin with #include guards.<br />
* Follow with the necessary includes. Include only what is necessary to avoid dependency problems.<br />
* Place the class in the correct namespace.<br />
* Public methods come first.<br />
* Protected methods follow.<br />
* Private members come last.<br />
* Public data members are ''forbidden''.<br />
* Templated classes require a special preprocessor directive to control the manual instantiation of templates. See the example below and look for ITK MANUAL INSTANTIATION.<br />
The class layout looks something like this:<br />
<br />
<source lang="cpp"><br />
#ifndef itkImage_h<br />
#define itkImage_h<br />
<br />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
<br />
namespace itk<br />
{<br />
<br />
/** \class Image<br />
* \brief Templated n-dimensional image class.<br />
*<br />
* .... detailed documentation....<br />
*/<br />
template< typename TPixel, unsigned int VImageDimension=2,<br />
typename TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class Image: public ImageBase< VImageDimension ><br />
{<br />
public:<br />
//....stuff...<br />
protected:<br />
//....stuff...<br />
private:<br />
//....stuff...<br />
};<br />
<br />
} // end namespace itk<br />
<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
<br />
#endif<br />
</source><br />
<br />
==== Method Definition ====<br />
<br />
* Methods are defined across multiple lines. This is to accommodate the extremely long definitions possible when using templates.<br />
* The starting and ending brace should be in column one. For example:<br />
<br />
<source lang="cpp"><br />
template<typename TPixel, unsigned int VImageDimension, typename TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
//...stuff...<br />
}<br />
</source><br />
<br />
* The first line is the template declaration.<br />
* The second line is the method return type.<br />
* The third line is the class qualifier.<br />
* And the fourth line in the example above is the name of the method.<br />
<br />
=== Use of Braces ===<br />
<br />
* Braces must be used to delimit the scope of an if, for, while, switch, or other control structure.<br />
* Braces are placed on a line by themselves:<br />
<br />
<source lang="cpp"><br />
for( unsigned int ii = 0; ii < 3; ++ii )<br />
{<br />
...<br />
}<br />
</source><br />
<br />
<br />
or when using an if:<br />
<br />
<source lang="cpp"><br />
if( condition )<br />
{<br />
...<br />
}<br />
else if( other condition )<br />
{<br />
...<br />
}<br />
else<br />
{<br />
....<br />
}<br />
</source><br />
<br />
<br />
==== Indentation Inside Braces ====<br />
<br />
<br />
Source code in the body of the brackets must be aligned along with the brackets. As in<br />
<br />
<source lang="cpp"><br />
if ( condition )<br />
{<br />
unsigned int numberOfIterations = 100;<br />
filter->SetNumberOfIterations( numberOfIterations );<br />
filter->Update();<br />
filter->Print( std::cout );<br />
}<br />
</source><br />
<br />
=== Doxygen Documentation System ===<br />
<br />
* Doxygen is an open-source, powerful system for automatically generating documentation from source code.<br />
* To use Doxygen effectively, the developer must insert comments, delimited in a special way, that Doxygen extracts to produce the documentation. While there are a large number of options to Doxygen, developers at a minimum should insert the following Doxygen commands.<br />
<br />
See more at<br />
<br />
https://www.stack.nl/~dimitri/doxygen/manual/index.html<br />
<br />
==== Documenting a Class ====<br />
<br />
* Classes should be documented using the '''class''' and '''brief''' Doxygen commands, followed by the detailed class description:<br />
<br />
<source lang="cpp"><br />
/** \class Object<br />
* \brief Base class for most itk classes.<br />
*<br />
* Object is the second-highest level base class for most itk objects.<br />
* It extends the base object functionality of LightObject by<br />
* implementing debug flags/methods and modification time tracking.<br />
*/<br />
</source><br />
<br />
==== Documenting a Method ====<br />
<br />
* Methods should be documented using the following comment block style as shown in the following example. Make sure you use correct English and complete, grammatically correct sentences. Finish your sentences with a period (.).<br />
<br />
<source lang="cpp"><br />
/** Access a pixel at a particular index location.<br />
* This version can be an lvalue. */<br />
TPixel & operator[](const IndexType &index)<br />
{ return this->GetPixel(index); }<br />
</source><br />
<br />
The key here is that the comment starts with /**, each subsequent line has an aligned *, and the comment block terminates with a */.<br />
<br />
* Method documentation should be placed in the '''declaration files''' (*.h): the documentation in the implementation causes ambiguity for Doxygen on which documentation to use, the declaration or definition.<br />
** If there is something that is appropriate for the definition only (*.cxx or *.hxx), it should be placed '''inside the method''', and it could use either the /* */ or the // style comment, but it should not use /** */, which is for Doxygen comments.<br />
<br />
==== Documenting ivars ====<br />
<br />
* Class member variables should be documented through their corresponding Set/Get methods, using a comment block style shown in the following example. Make sure you use correct English and grammatically correct sentences. Finish the documentation line with a period (.).<br />
<br />
<source lang="cpp"><br />
<br />
public:<br />
<br />
/** Set/Get the standard deviation of the Gaussian used for smoothing. */<br />
itkSetMacro( Sigma, SigmaArrayType );<br />
itkGetConstMacro( Sigma, SigmaArrayType );<br />
<br />
private:<br />
<br />
SigmaArrayType m_Sigma;<br />
<br />
</source><br />
<br />
=== Using Standard Macros (itkMacro.h) ===<br />
<br />
* There are several macros defined in the file itkMacro.h.<br />
* These macros should be used because they perform several important operations, that if not done correctly can cause serious, hard to debug problems in the system.<br />
** These operations are:<br />
*** Object modified time is properly managed.<br />
*** Debug information is printed.<br />
*** Reference counting is handled properly.<br />
<br />
Some of the more important object macros are as follows.<br />
<br />
* itkNewMacro(T) Creates the static class method New(void) that interacts with the object factory to instantiate objects. The method returns a SmartPointer<T> properly reference counted.<br />
* itkDebugMacro(x) If debug is set on a subclass of itk::Object, prints debug information to the appropriate output stream.<br />
* itkSetMacro(name,type) Creates a method SetName() that takes argument type type.<br />
* itkGetMacro(name,type) Creates a method GetName() that returns a non-const value of type type.<br />
* itkGetConstMacro(name,type) Creates a method GetName() that returns a const value of type type.<br />
* itkSetStringMacro(name) Creates a method SetName() that takes argument type const char*.<br />
* itkGetStringMacro(name) Creates a method GetName() that returns argument type const char*.<br />
* itkBooleanMacro(name) Creates two methods named NameOn and NameOff that sets true/false boolean values.<br />
* itkSetObjectMacro(name,type) Creates a method SetName() that takes argument type type *.<br />
* itkGetObjectMacro(name,type) Creates a method named GetName() that returns a smart pointer to a type type.<br />
* itkSetConstObjectMacro(name,type) Creates a method SetName() that takes argument type const type *.<br />
* itkGetConstObjectMacro(name,type) Creates a method named GetName() that returns a const smart pointer to a type type.<br />
<br />
Please review this file and become familiar with these macros.<br />
<br />
=== Exception Handling ===<br />
<br />
Indicate that methods throw exceptions in the method declaration as in:<br />
<br />
<source lang="cpp"><br />
const float* foo() const throws itk<br />
</source><br />
<br />
=== Documentation Style ===<br />
<br />
The Insight consortium has adopted the following guidelines for producing supplemental documentation (documentation not produced by Doxygen).<br />
<br />
* The common denominator for documentation is either PDF or HTML. All documents in the system should be available in these formats, even if they are mastered by another system.<br />
* Presentations are acceptable in Microsoft PowerPoint format.<br />
* Administrative and planning documents are acceptable in Microsoft Word format (either .doc or .rtf).<br />
* Larger documents, such as the user's or developer's guide, are written in LATEX.<br />
<br />
== CMake Style ==<br />
<br />
A proposal style guide for CMake variables is presented [[ITK_CMake_Style|HERE]].<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/InsightCommunityMailingList&diff=62219ITK/InsightCommunityMailingList2018-03-17T12:09:29Z<p>Jhlegarreta: Change references to the mailing list for references to discourse</p>
<hr />
<div>The main forum for community discussion and support is the [https://discourse.itk.org/ ITK discourse space]. It is an incredibly valuable discussion forum, with very low noise and very high signal. It is frequented by the core ITK developers, regular users and new users alike.<br />
<br />
== Subscribing ==<br />
<br />
To subscribe to the civilized discussion, follow the instructions at [https://discourse.itk.org/t/getting-started-with-discourse/22 getting started guide].<br />
<br />
== Archives ==<br />
<br />
ITK transitioned from a traditional mailing list to the [https://www.discourse.org/ discourse platform] on September, 21 2017.<br />
<br />
The full archives of the previous mailing lists are available from:<br />
<br />
* List archives: http://www.itk.org/pipermail/insight-users/<br />
* [http://www.google.com/advanced_search?as_sitesearch=www.itk.org&as_epq=insight%2Dusers Google search archives]<br />
* Gmane interface: http://news.gmane.org/gmane.comp.lib.itk.user<br />
<br />
== Asking Questions ==<br />
<br />
It is a good idea to search here first before asking questions, to make sure it hasn't come up before. There are many detailed explanations and discussions contained in the archive, so it is well worth reading. It is also a good idea to check the FAQ and do a search on this site.<br />
<br />
If you are asking a question about building ITK, please include the following information at a minimum:<br />
<br />
* Platform (e.g. Windows, Linux, Solaris, Mac OS X, etc)<br />
* Compiler (e.g. gcc 3.3)<br />
* CMake version (e.g. 1.8.3)<br />
* CMake settings<br />
* Complete output of the error message<br />
<br />
The more information you include in your original post, the easier it will be for us to help you.<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK&diff=62218ITK2018-03-17T11:58:13Z<p>Jhlegarreta: Switch from GitWeb to GitHub as the Git repository URL where the ITK code dwells</p>
<hr />
<div>[[File:Itk.png|center|150x100px]] <br />
<br />
The National Library of Medicine '''[http://www.itk.org/ Insight Segmentation and Registration Toolkit]''' (ITK) is an open-source software system for medical image processing in two, three and more dimensions. <br />
<br />
This is the '''''ITK Wiki''''', a collaborative hypertext database of information, documentation and resources.<br />
<br />
__TOC__<br />
<br />
== Overview ==<br />
<br />
* <big><strong>[[ITK/Getting Started|Getting Started with ITK]]</strong></big><br />
* [[ITK/About|About the Insight Toolkit]]<br />
* [[ITK/FAQ|Frequently Asked Questions (FAQ)]]<br />
* [[ITK/License Information| License Information]]<br />
<br />
== Software Process ==<br />
* [https://github.com/InsightSoftwareConsortium/ITK Git repository] : The version controlled repository.<br />
* [http://review.source.kitware.com/#/q/status:open+project:ITK,n,z Gerrit code review] : Our code review system.<br />
* [http://issues.itk.org/ Issue tracking system] : Where we report and browse bugs.<br />
* [http://www.cdash.org/CDash/index.php?project=Insight&date= Nightly build dashboard] : View the build status on a variety of platforms.<br />
* [[ITK/Development | Development]]<br />
<br />
== Resources ==<br />
<br />
* [[ITK/Documentation| Documentation]]<br />
* [[ITK/Community | Community Corner]]<br />
* [[ITK/Academic | Academic Corner]]<br />
* [[ITK/Professional | Professional Corner]]<br />
* [[ITK/Open_Science| Open Science]]<br />
* [[ITK/Other_Software| Other Software]]<br />
<br />
{{ITKRegister}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Git/Publish&diff=62206Git/Publish2018-02-05T21:07:37Z<p>Jhlegarreta: Add the historical label after PR#21 to https://github.com/InsightSoftwareConsortium/ITKSoftwareGuide was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
=Push Access=<br />
<br />
Authorized developers may publish work directly to a <code>public.kitware.com</code> repository using Git's SSH protocol.<br />
<br />
Note that ''we may not grant all contributors push access'' to any given repository.<br />
The distributed nature of Git allows contributors to retain authorship credit even if they do not publish changes directly.<br />
<br />
==Authentication==<br />
<br />
All publishers share the <code>git@public.kitware.com</code> account but each uses a unique ssh key for authentication.<br />
If you do not have a public/private ssh key pair, generate one:<br />
<br />
$ ssh-keygen -C 'you@yourdomain.com'<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key ($HOME/.ssh/id_rsa):<br />
Enter passphrase (empty for no passphrase): (use-a-passphrase!!)<br />
Enter same passphrase again: (use-same-passphrase!!)<br />
Your identification has been saved in $HOME/.ssh/id_rsa.<br />
Your public key has been saved in $HOME/.ssh/id_rsa.pub.<br />
<br />
To request access, fill out the [https://www.kitware.com/Admin/SendPassword.cgi Kitware Password] form.<br />
Include your ssh public key, '''<code>id_rsa.pub</code>''', and a reference to someone our administrators may contact to verify your privileges.<br />
<br />
===SSH on Windows===<br />
<br />
If you are familiar with generating an ssh key on Linux or Mac, you can follow the same procedure on Windows in a "Git Bash" prompt. There is an ssh-keygen program installed with msysGit to help you set up an ssh identity on a Windows machine. By default it puts the ".ssh" directory in the HOME directory, which is typically "/c/Users/Username" on Vista and Windows 7; on XP, it's "/c/Documents and Settings/Username".<br />
<br />
Alternatively, you can also set up a "normal" Windows command prompt shell such that it will work with msysGit, without ever invoking the Git Bash prompt if you like. If you install msysGit and accept all its default options, "git" will not be in the PATH. However, if you add "C:\Program Files (x86)\Git\cmd" to your PATH, then only the two commands '''git''' and '''gitk''' are available to use via *.cmd script wrappers installed by msysGit. Or, if you add "C:\Program Files (x86)\Git\bin" to your PATH, then '''all''' of the command line tools that git installs are available.<br />
<br />
The full PuTTY suite of tools includes an application called PuTTYgen. If you already have a private key created with PuTTYgen, you may export it to an OpenSSH identity file. Open the key using PuTTYgen and choose "Conversions > Export OpenSSH key" from the menu bar. That will allow you to save an "id_rsa" file for use in the ".ssh" directory. You can also copy and paste the public key portion of the key from the PuTTYgen text field to save into an "id_rsa.pub" file if you like. Or email it to whoever needs the public side of your key pair.<br />
<br />
If you routinely set up your own command prompt environment on Windows, using msysGit from that envrionment is a cinch: just add the full path to either Git\cmd or Git\bin to your PATH. (Or, write your own git.cmd wrapper that is in your PATH that simply calls the git.cmd installed with msysGit.) And make sure you have a HOME environment variable that points to the place where the .ssh directory is.<br />
<br />
===Authentication Test===<br />
<br />
When your ssh public key has been installed for <code>git@public.kitware.com</code>, you may test your ssh key setup by running<br />
<br />
$ ssh git@public.kitware.com info<br />
<br />
If your key is correctly configured you should see a message reporting your email address followed by a list of access permissions.<br />
If you get something like "<code>Permission denied</code>" then add <code>-v</code> options to your ssh command line to diagnose the problem:<br />
<br />
$ ssh -v git@public.kitware.com info<br />
<br />
Do not attempt to <code>git push</code> until the ssh-only test succeeds.<br />
<br />
==Pushing==<br />
<br />
Git automatically configures a new clone to refer to its origin through a [http://www.kernel.org/pub/software/scm/git/docs/git-remote.html remote] called <code>origin</code>.<br />
Initially one may [http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html fetch] or [http://www.kernel.org/pub/software/scm/git/docs/git-pull.html pull] changes from <code>origin</code>,<br />
but may not [http://www.kernel.org/pub/software/scm/git/docs/git-push.html push] changes to it.<br />
<br />
In order to publish new commits in a <code>public.kitware.com</code> repository, developers must configure a ''push URL'' for the <code>origin</code>.<br />
Use [http://www.kernel.org/pub/software/scm/git/docs/git-config.html git config] to specify an ssh-protocol URL:<br />
<br />
$ git config remote.origin.pushurl git@public.kitware.com:''repo''.git<br />
<br />
The actual URL will vary from project to project.<br />
(Note that 'pushurl' requires Git >= 1.6.4. Use just 'url' for Git < 1.6.4.)<br />
<br />
Failing to do so with result in the following error message: "fatal: The remote end hung up unexpectedly".<br />
<br />
Once your push URL is configured and your key is installed for <code>git@public.kitware.com</code> then you can try pushing changes.<br />
Note that many repositories use an <code>update</code> hook to check commit as documented [[Git/Hooks#update|here]].<br />
<br />
=Patches=<br />
<br />
Git allows anyone to be a first-class developer on any published project.<br />
One can clone a public repository, commit locally, and publish these commits for inclusion upstream.<br />
One method of sending commits upstream is to supply them as patches.<br />
<br />
See these links for more help:<br />
<br />
* [http://progit.org/book/ch5-2.html Pro Git Book, Chapter 5: Distributed Git]<br />
* [http://www.kernel.org/pub/software/scm/git/docs/everyday.html#Integrator Everyday GIT: Integrator]<br />
<br />
==Creating Patches==<br />
<br />
Construct your commits on a local topic branch, typically started from the upstream '''master''':<br />
<br />
$ git checkout -b my-cool-feature origin/master<br />
$ edit ''files''<br />
$ git add -- ''files''<br />
$ git commit<br />
<br />
Begin each commit message with a short ''one-line'' summary of its change, suitable for use as an email subject line.<br />
Then leave a blank line and describe the change in detail as one might write in an email body.<br />
<br />
When the patch(es) are ready for publication to upstream developers, use the [http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html git format-patch] command to construct the patch files:<br />
<br />
$ git format-patch -M origin/master<br />
<br />
Git will write out one patch file per commit.<br />
Each patch file is formatted like a raw email message and includes enough information to reconstruct the commit message and author.<br />
<br />
==Sending Patches==<br />
<br />
The patch files created in the preceding step will be named with the form<br />
<br />
NNNN-Subject-line-of-commit-message.patch<br />
<br />
where <code>NNNN</code> is an index for the patch within the series.<br />
These files may be attached in bug trackers or attached to email messages.<br />
<br />
A patch series may also be sent directly as email.<br />
Use [http://www.kernel.org/pub/software/scm/git/docs/git-config.html git config] <code>--global</code> to set <code>sendemail.*</code> configuration entries that tell Git how to send email from your computer<br />
(one-time setup per user per machine).<br />
Then use the [http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html git send-email] command:<br />
<br />
$ git send-email *.patch --to='Some One <someone@somewhere.com>' --cc='Someone Else <someoneelse@somewhereelse.com>'<br />
<br />
==Applying Patches==<br />
<br />
One may receive patches as attachments in a bug tracker or as attachments to email messages.<br />
Save these files to your local disk.<br />
One may also receive patches inlined in email messages.<br />
In this case, save the whole message to your local disk (typically as .eml files).<br />
(If your local mail client uses "maildir" format mailboxes each message is already its own file.)<br />
<br />
Create a local topic branch on which to replay the patch series:<br />
<br />
$ git checkout -b cool-feature origin/master<br />
<br />
Now use [http://www.kernel.org/pub/software/scm/git/docs/git-am.html git am] to apply the patch series as local commits:<br />
<br />
$ git am --whitespace=fix /path/to/*.patch<br />
<br />
Review the changes using<br />
<br />
$ git log -p origin/master..<br />
<br />
or the method of your choice.<br />
Note that the author of each commit is the contributor rather than yourself.<br />
Build, test, and publish the changes normally.<br />
<br />
If the "<code>git am</code>" command fails with a message like<br />
<br />
Patch format detection failed.<br />
<br />
this means that the patch was not generated with <code>git format-patch</code> and transmitted correctly.<br />
Either ask the contributor to try again using the above patch creation instructions, or apply each patch separately using<br />
[http://www.kernel.org/pub/software/scm/git/docs/git-apply.html git apply]:<br />
<br />
$ git apply --whitespace=fix /path/to/0001-First-change.patch<br />
$ git commit --author='Contributor Name <contributor@theirdomain.com>'</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Git/WorkflowPrimer&diff=62205Git/WorkflowPrimer2018-02-05T21:06:51Z<p>Jhlegarreta: Add the historical label after PR#21 to https://github.com/InsightSoftwareConsortium/ITKSoftwareGuide was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
This primer details a possible workflow for using git and ITK. There are many ways to use git and it is a very flexible tool. This page details my particular way of working with git, and is certainly not the last word. It is also a rambling collection of tips and experiences that I've picked up in the last few years of using git.<br />
<br />
== Basics ==<br />
It's worth trying to explain some high-level git concepts. A [http://carthik.net/blog/vault/2007/08/21/its-a-feature-not-a-bug/ feature] ([http://www.codinghorror.com/blog/2008/11/thats-not-a-bug-its-a-feature-request.html or a bug]) that sets git apart from Subversion is it's distributed nature. In practice that means that ITK needs to "bless" a repo for it to be the "official" source of ITK. This [http://itk.org/gitweb?p=ITK.git;a=summary has already been done].<br />
<br />
Another git concept is that of a commit. git uses a [http://en.wikipedia.org/wiki/Sha1 SHA1 hash] to uniquely identify a change set. The hash is (almost) guaranteed to be unique across your project, and even across all projects everywhere and for all time. Quoting from the excellent Pro Git book:<br />
<br />
<quote><br />
A lot of people become concerned at some point that they will, by random happenstance, have two objects in their repository that hash to the same SHA-1 value. What then?<br />
<br />
If you do happen to commit an object that hashes to the same SHA-1 value as a previous object in your repository, GIt will see the previous object already in your Git database and assume it was already written. If you try to check out that object again at some point, you’ll always get the data of the first object.<br />
<br />
However, you should be aware of how ridiculously unlikely this scenario is. The SHA-1 digest is 20 bytes or 160 bits. The number of randomly hashed objects needed to ensure a 50% probability of a single collision is about 2^80 (the formula for determining collision probability is p = (n(n-1)/2) * (1/2^160)). 2^80 is 1.2 x 10^24 or 1 million billion billion. That’s 1,200 times the number of grains of sand on the earth.<br />
<br />
Here’s an example to give you an idea of what it would take to get a SHA-1 collision. If all 6.5 billion humans on Earth were programming, and every second, each one was producing code that was the equivalent of the entire Linux kernel history (1 million Git objects) and pushing it into one enormous Git repository, it would take 5 years until that repository contained enough objects to have a 50% probability of a single SHA-1 object collision. A higher probability exists that every member of your programming team will be attacked and killed by wolves in unrelated incidents on the same night.<br />
</quote></div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Git/Workflow/Stage&diff=62204Git/Workflow/Stage2018-02-05T21:03:09Z<p>Jhlegarreta: Add the historical label after PR#21 to https://github.com/InsightSoftwareConsortium/ITKSoftwareGuide was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
=Introduction=<br />
<br />
Our ''Topic Stage'' repositories provide a central staging area for<br />
topic branches under development. Unlike an official repository a<br />
topic stage may have any number of branches. Developers are free to<br />
create, update, and delete topics in the stage through Git's ssh<br />
protocol.<br />
<br />
=Tutorial=<br />
<br />
==Initial Setup==<br />
<br />
Add a remote called "<code>stage</code>" to refer to the topic stage.<br />
In general the stage for some upstream repository <code>''repo''.git</code> is <code>stage/''repo''.git</code>:<br />
<br />
$ git remote add stage git://public.kitware.com/stage/''repo''.git<br />
$ git config remote.stage.pushurl git@public.kitware.com:stage/''repo''.git<br />
<br />
One may fetch from the stage at any time:<br />
<br />
$ git fetch stage --prune<br />
<br />
Use the "<code>--prune</code>" option to remove local references to remote topic branches that have been deleted.<br />
<br />
==Staging a Topic==<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Create a local topic branch and develop on it.<br />
Here we use the placeholder ''topic-name'' for the branch name.<br />
|-<br />
|<br />
:<code>$ </code>[[Git/Workflow/Topic#Creating_a_New_Topic_Branch|Create a Topic]]<br />
|<br />
...o----o master,<br />
^ *'''''topic-name'''''<br />
|-<br />
|<br />
:<code>$ </code>[[Git/Workflow/Topic#Making_Commits.2FWorking|Commit Changes]]<br />
|<br />
...o----o master<br />
\<br />
o----o *'''''topic-name'''''<br />
|-<br />
|colspan="2"|<br />
When the topic is ready for publication push it to the stage.<br />
Fetch from the stage just before pushing to help git compute a minimal set of objects to push.<br />
Pushing <code>HEAD</code> will automatically use the ''topic-name'':<br />
|-<br />
|<br />
:{|<br />
|<br />
$ git fetch stage --prune<br />
$ git push stage HEAD<br />
To git@public.kitware.com:stage/''repo''.git<br />
* [new branch] HEAD -> ''topic-name''<br />
|}<br />
|<br />
...o----o master, stage/master<br />
\<br />
o----o *'''''topic-name''''', stage/''topic-name''<br />
|}<br />
<br />
==Viewing all Topics==<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Print the current stage topic table:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' print<br />
... | ...<br />
''topic-name'' | master=0 next=0<br />
''other-topic'' | master=0 next=1<br />
... | ...<br />
|}<br />
|<br />
...o----o stage/master<br />
. \ \<br />
. \ o----o stage/''topic-name''<br />
. \<br />
. o----o stage/''other-topic''<br />
. \<br />
........o stage/next<br />
|-<br />
|colspan="2"|<br />
Each row represents one topic.<br />
The first column names the topic, the rest name each integration branch with a 0 or 1 indicating whether it can reach the topic.<br />
|-<br />
|colspan="2"|<br />
One may also get machine-readable output:<br />
:<code>$ ssh git@public.kitware.com stage ''repo'' state</code><br><br />
{| cellpadding="0" cellspacing="0" border="0"<br />
!width=30|<br />
|<br />
branch 9138476e64ec082d7d507c430c7d3fb0d6a6b586 next<br />
branch b78573d359b74e11f1233a55ee3a0a257973dfa1 master<br />
topic 171b4573096612971f3b8d227a5b372be3281ca4 ''topic-name''<br />
topic f68c277ddb11780c560d376a864cc5706eb7cc62 ''other-topic''<br />
merged 9138476e64ec082d7d507c430c7d3fb0d6a6b586 f68c277ddb11780c560d376a864cc5706eb7cc62<br />
...<br />
|}<br />
|}<br />
<br />
==Merging a Topic==<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Tell the stage to merge the topic into '''next'''.<br />
It automatically computes a merge commit based on the latest upstream '''next'''.<br />
If merging fails with conflicts the stage will print instructions.<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' merge -b next ''topic-name''<br />
Fetching upstream next<br />
Merge branch ''topic-name''<br />
Pushing upstream next<br />
To ../../''repo''.git<br />
|}<br />
|-<br />
|colspan="2"|<br />
Print the new state of the stage:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' print<br />
... | ...<br />
''topic-name'' | master=0 next=1<br />
''other-topic'' | master=0 next=1<br />
... | ...<br />
|}<br />
|<br />
...o----o stage/master<br />
. \ \<br />
. \ o----o stage/''topic-name''<br />
. \ \<br />
. o----o \ stage/''other-topic''<br />
. \ \<br />
........o----o stage/next<br />
|}<br />
<br />
==Updating a Topic==<br />
<br />
Perhaps after merging to '''next''' you discover that an additional change is needed.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Since the merge was done by the topic stage repository we never switched branches locally.<br />
Just continue development:<br />
|-<br />
|<br />
:<code>$ edit files</code><br><br />
:<code>$ git commit</code><br><br />
|<br />
...o----o master<br />
\<br />
o----o----o *'''''topic-name'''''<br />
^ stage/''topic-name''<br />
|-<br />
|colspan="2"|<br />
Push the topic to the stage.<br />
|-<br />
|<br />
:{|<br />
|<br />
$ git fetch stage<br />
$ git push stage HEAD<br />
To git@public.kitware.com:stage/''repo''.git<br />
171b457..27c71e8 HEAD -> ''topic-name''<br />
|}<br />
|<br />
...o----o master<br />
\<br />
o----o----o *'''''topic-name''''', stage/''topic-name''<br />
|-<br />
|colspan="2"|<br />
The stage's reference to the topic will fast-forward.<br />
We can see that the topic head is no longer reachable from '''next''':<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' print<br />
... | ...<br />
''topic-name'' | master=0 next=0<br />
''other-topic'' | master=0 next=1<br />
... | ...<br />
|}<br />
|<br />
...o----o stage/master<br />
. \ \<br />
. \ o----o----o stage/''topic-name''<br />
. \ \<br />
. o----o \ stage/''other-topic''<br />
. \ \<br />
........o----o stage/next<br />
|-<br />
|colspan="2"|<br />
Merge the topic into '''next''' again:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' merge -b next ''topic-name''<br />
Fetching upstream next<br />
Merge branch ''topic-name''<br />
Pushing upstream next<br />
To ../../''repo''.git<br />
|}<br />
|-<br />
|colspan="2"|<br />
Now '''next''' can see the whole topic again:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' print<br />
... | ...<br />
''topic-name'' | master=0 next=1<br />
''other-topic'' | master=0 next=1<br />
... | ...<br />
|}<br />
|<br />
...o----o stage/master<br />
. \ \<br />
. \ o----o----o stage/''topic-name''<br />
. \ \ \<br />
. o----o \ \ stage/''other-topic''<br />
. \ \ \<br />
........o----o----o stage/next<br />
|}<br />
<br />
==Finishing a Topic==<br />
<br />
After development of the topic has been finished and it is considered stable.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Merge it to master:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' merge -b master ''topic-name''<br />
Fetching upstream master<br />
Merge branch ''topic-name''<br />
Pushing upstream master<br />
To ../../''repo''.git<br />
Deleting fully merged topic ''topic-name'' (27c71e8) from stage.<br />
|}<br />
|-<br />
|colspan="2"|<br />
The "Deleting ..." line occurs when the topic is reachable from all integration branches.<br />
Fear not, the deletion is safe even during a race condition when someone else updates it with a new commit at the same time as your merge completes.<br />
<br />
The stage no longer references the topic explicitly:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' print<br />
... | ...<br />
''other-topic'' | master=0 next=1<br />
... | ...<br />
|}<br />
|<br />
...o----o-------------o stage/master<br />
. \ \ /<br />
. \ o----o----o<br />
. \ \ \<br />
. o----o \ \ stage/''other-topic''<br />
. \ \ \<br />
........o----o----o stage/next<br />
|}<br />
<br />
==Abandoning a Topic==<br />
<br />
Sometimes a topic proves to be unusable and should never be merged to master.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Add a commit to the topic that reverts all its changes, such as using git revert.<br />
|-<br />
|<br />
:<code>$ git revert -n origin/master..HEAD</code><br><br />
:''(If the topic has merges this may not work. Ask on the project mailing list.)''<br />
:<code>$ git commit</code><br><br />
|<br />
...o----o master<br />
\<br />
o----o----o----o *'''''topic-name'''''<br />
^ stage/''topic-name''<br />
|-<br />
|colspan="2"|<br />
Push the topic to the stage.<br />
|-<br />
|<br />
:{|<br />
|<br />
$ git push stage HEAD<br />
To git@public.kitware.com:stage/''repo''.git<br />
27c71e8..7892e6b HEAD -> ''topic-name''<br />
|}<br />
|<br />
...o----o master<br />
\<br />
o----o----o----o *'''''topic-name''''', stage/''topic-name''<br />
|-<br />
|colspan="2"|<br />
Merge the topic into '''next''' again:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' merge -b next ''topic-name''<br />
Fetching upstream next<br />
Merge branch ''topic-name''<br />
Pushing upstream next<br />
To ../../''repo''.git<br />
|}<br />
|-<br />
|colspan="2"|<br />
Now '''next''' can see the whole topic but none of its changes:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' print<br />
... | ...<br />
''topic-name'' | master=0 next=1<br />
''other-topic'' | master=0 next=1<br />
... | ...<br />
|}<br />
|<br />
...o----o stage/master<br />
. \ \<br />
. \ o----o----o----o stage/''topic-name''<br />
. \ \ \ \<br />
. o----o \ \ \ stage/''other-topic''<br />
. \ \ \ \<br />
........o----o----o----o stage/next<br />
|-<br />
|colspan="2"|<br />
Finally, push an empty ref to the stage to delete the topic:<br />
|-<br />
|<br />
:<code>$ git push stage :''topic-name''</code><br><br />
|-<br />
|colspan="2"|<br />
The stage no longer references the topic explicitly:<br />
|-<br />
|<br />
:{|<br />
|<br />
$ ssh git@public.kitware.com stage ''repo'' print<br />
... | ...<br />
''other-topic'' | master=0 next=1<br />
... | ...<br />
|}<br />
|<br />
...o----o stage/master<br />
. \ \<br />
. \ o----o----o----o<br />
. \ \ \ \<br />
. o----o \ \ \ stage/''other-topic''<br />
. \ \ \ \<br />
........o----o----o----o stage/next<br />
|}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Git/Workflow/Topic/Conflicts&diff=62203Git/Workflow/Topic/Conflicts2018-02-05T21:02:11Z<p>Jhlegarreta: Add the historical label after PR#21 to https://github.com/InsightSoftwareConsortium/ITKSoftwareGuide was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
This page documents conflict resolution in a [[Git/Workflow/Topic|topic-based branchy workflow]].<br />
__TOC__<br />
Whenever two paths of development make different changes to the same initial content conflicts may occur when merging the branches.<br />
<br />
= Single Integration Branch =<br />
<br />
Consider two conflicting topic branches, ''topic'' and ''other-topic'', with the latter already merged to '''master''':<br />
<br />
...o----o-------o master<br />
\ \ /<br />
\ o---o ''other-topic''<br />
\<br />
o----o ''topic''<br />
<br />
An attempt to merge ''topic'' into '''master''' will fail with conflicts.<br />
One may use the following approaches to resolve the situation:<br />
* Merge the [[#Topic-to-Single-Branch|topic to the branch]]<br />
* Merge the [[#Branch-to-Topic|branch to the topic]]<br />
<br />
== Topic-to-Single-Branch ==<br />
<br />
If one performs the merge in a local work tree it is possible to simply resolve the conflicts and complete the merge:<br />
<br />
...o----o-------o----o master<br />
\ \ / /<br />
\ o---o / ''other-topic''<br />
\ /<br />
o---------o ''topic''<br />
<br />
This approach does not work when using a [[Git/Workflow/Stage|topic stage]].<br />
It cannot resolve the conflicts automatically and may print instructions to follow the [[#Branch-to-Topic|next approach]].<br />
<br />
== Branch-to-Topic ==<br />
<br />
Since a developer works on a topic branch locally one may simply merge the conflicting integration branch into the topic and resolve the conflicts:<br />
<br />
...o----o-------o master<br />
\ \ / \<br />
\ o---o \ ''other-topic''<br />
\ \<br />
o----o-------o ''topic''<br />
<br />
<br />
In order to maintain a good [[Git/Workflow/Topic#History_Shape|shape of history]] one may then<br />
merge the topic into the integration branch without allowing a fast-forward (<code>merge --no-ff</code>):<br />
<br />
...o----o-------o-------o master<br />
\ \ / \ /<br />
\ o---o \ / ''other-topic''<br />
\ \ /<br />
o----o-------o ''topic''<br />
<br />
Our [[Git/Workflow/Stage|topic stages]] use this approach when working with a single integration branch.<br />
<br />
= Multiple Integration Branches =<br />
<br />
In a workflow using multiple integration branches one must deal differently with conflicting topics.<br />
Consider two conflicting topic branches, ''topic'' and ''other-topic'', with the latter already merged to '''next''':<br />
<br />
...o----o master<br />
. \ \<br />
. \ o---o ''topic''<br />
. \<br />
. o--------o ''other-topic''<br />
. \<br />
............o next<br />
<br />
An attempt to merge ''topic'' into '''next''' will fail with conflicts.<br />
One may use the following approaches to resolve the situation:<br />
* Merge the [[#Topic-to-Branch|topic to the branch]]<br />
* Merge [[#Topic-to-Topic|one topic into the other]]<br />
* Merge both topics into a [[#Resolution_Topic|resolution topic]]<br />
Note that one may ''not'' merge the [[#Branch-to-Topic|branch into the topic]] as in the single-integration-branch case because '''next''' may never be merged into a topic.<br />
<br />
== Topic-to-Branch ==<br />
<br />
If one performs the merge in a local work tree it is possible to simply resolve the conflicts and complete the merge:<br />
<br />
...o----o master<br />
. \ \<br />
. \ o--------o ''topic''<br />
. \ \<br />
. o--------o \ ''other-topic''<br />
. \ \<br />
............o----o next<br />
<br />
However, the topics eventually must be merged to '''master'''.<br />
Assume ''topic'' is merged first:<br />
<br />
...o----o------------o master<br />
. \ \ /<br />
. \ o--------o ''topic''<br />
. \ \<br />
. o--------o \ ''other-topic''<br />
. \ \<br />
............o----o next<br />
<br />
An attempt to merge ''other-topic'' into '''master''' will fail with the same conflicts!<br />
<br />
...o----o------------o-----? master<br />
. \ \ / /<br />
. \ o--------o / ''topic''<br />
. \ \ /<br />
. o--------o----\-- ''other-topic''<br />
. \ \<br />
............o----o next<br />
<br />
The only branch that contains a resolution to these conflicts is '''next''', but that may not be merged to '''master'''.<br />
Therefore one must resolve the conflicts a second time.<br />
<br />
If the second resolution is not byte-for-byte identical to the first then the new '''master''' will not merge cleanly into '''next''':<br />
<br />
...o----o------------o-----o master<br />
. \ \ / / \<br />
. \ o--------o / \ ''topic''<br />
. \ \ / \<br />
. o--------o----\-- \ ''other-topic''<br />
. \ \ \<br />
............o----o---------? next<br />
<br />
Then one must resolve conflicts a third time!<br />
<br />
This approach works with manual merging but requires care.<br />
It does not work when using a [[Git/Workflow/Stage|topic stage]] that cannot resolve the conflicts automatically and may print instructions to follow the [[#Topic-to-Topic|next approach]].<br />
<br />
== Topic-to-Topic ==<br />
<br />
The [[Git/Workflow/Topic#Design|design]] of our topic-based workflow guarantees that work is always committed on topic branches and never directly on an integration branch.<br />
If conflicts occur while merging a topic into an integration branch it means that the topic conflics with ''another topic'' that has already been merged.<br />
<br />
One may manually merge the conflicting ''other-topic'' into one's own ''topic'' and resolve the conflicts:<br />
<br />
...o----o master<br />
. \ \<br />
. \ o---o---o ''topic''<br />
. \ /<br />
. o--------o ''other-topic''<br />
. \<br />
............o next<br />
<br />
Then ''topic'' will merge cleanly into '''next''':<br />
<br />
...o----o master<br />
. \ \<br />
. \ o---o---o ''topic''<br />
. \ / \<br />
. o--------o \ ''other-topic''<br />
. \ \<br />
............o---o next<br />
<br />
Later ''topic'' may be merged cleanly into '''master''' to bring in both topics (or just ''topic'' if ''other-topic'' has already been merged):<br />
<br />
...o----o-----------o master<br />
. \ \ /<br />
. \ o---o---o ''topic''<br />
. \ / \<br />
. o--------o \ ''other-topic''<br />
. \ \<br />
............o---o next<br />
<br />
Finally, '''master''' may be merged cleanly into '''next''':<br />
<br />
...o----o-----------o master<br />
. \ \ / \<br />
. \ o---o---o \ ''topic''<br />
. \ / \ \<br />
. o--------o \ \ ''other-topic''<br />
. \ \ \<br />
............o---o---o next<br />
<br />
Note that this produces an artificial [[Git/Workflow/Topic#Dependent_Topic|topic dependency]] introduced by the conflict resolution commit.<br />
See the [[#Resolution-Topic|next approach]] to avoid this problem.<br />
<br />
== Resolution Topic ==<br />
<br />
The [[#Topic-to-Topic|above approach]] introduces an artificial topic dependency because it asymmetrically favors one topic over another.<br />
Instead one may use a third topic to resolve the conflicts.<br />
<br />
One may start a new resolve/''topic''/''other-topic'' branch from ''topic'', merge ''other-topic'' into it, and resolve the conflicts:<br />
<br />
...o----o master<br />
. \ \<br />
. \ o---o ''topic''<br />
. \ \<br />
. \ o resolve/''topic''/''other-topic''<br />
. \ /<br />
. o----o ''other-topic''<br />
. \<br />
........o next<br />
<br />
The resolution topic will merge cleanly into '''next''' to bring in the changes from ''topic'' through the conflict resolution commit:<br />
<br />
...o----o master<br />
. \ \<br />
. \ o---o ''topic''<br />
. \ \<br />
. \ o resolve/''topic''/''other-topic''<br />
. \ / \<br />
. o----o \ ''other-topic''<br />
. \ \<br />
........o---o next<br />
<br />
Since ''topic'' and ''other-topic'' are still independent either may be merged to '''master''' first.<br />
Assume ''topic'' is merged first:<br />
<br />
...o----o-------o master<br />
. \ \ /<br />
. \ o---o ''topic''<br />
. \ \<br />
. \ o resolve/''topic''/''other-topic''<br />
. \ / \<br />
. o----o \ ''other-topic''<br />
. \ \<br />
........o---o next<br />
<br />
As [[#Topic-to-Branch|above]] an attempt to merge ''other-topic'' directly into '''master''' will fail with the original conflicts but now we have a topic containing the resolution commit independent of '''next'''.<br />
One may merge the resolution topic to '''master''' to bring in the changes from ''other-topic'' and the conflict resolution:<br />
<br />
...o----o-------o---o master<br />
. \ \ / /<br />
. \ o---o / ''topic''<br />
. \ \ /<br />
. \ o resolve/''topic''/''other-topic''<br />
. \ / \<br />
. o----o \ ''other-topic''<br />
. \ \<br />
........o---o next<br />
<br />
Finally, '''master''' may be merged cleanly into '''next''':<br />
<br />
...o----o-------o---o master<br />
. \ \ / / \<br />
. \ o---o / \ ''topic''<br />
. \ \ / \<br />
. \ o \ resolve/''topic''/''other-topic''<br />
. \ / \ \<br />
. o----o \ \ ''other-topic''<br />
. \ \ \<br />
........o---o-------o next</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Git/Workflow/Topic&diff=62202Git/Workflow/Topic2018-02-05T21:01:07Z<p>Jhlegarreta: Add the historical label after PR#21 to https://github.com/InsightSoftwareConsortium/ITKSoftwareGuide was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
=Introduction=<br />
<br />
This workflow is based on the branchy development workflow documented by [http://schacon.github.com/git/gitworkflows.html <code>git help workflows</code>].<br />
<br />
==Motivation==<br />
<br />
The primary goal of this workflow is to make release preparation and maintenance easier.<br />
We set the following requirements, of which some are themselves worthwhile goals:<br />
<br />
* Amortize the effort of release preparation throughout development<br />
* Support granular selection of features for release<br />
* Allow immature features to be published without delaying release<br />
* '''Keep unrelated development paths (''topics'') independent of one another'''<br />
* Maintain a clean [[#History_Shape|shape of history]]<br />
<br />
==Design==<br />
<br />
The design of this workflow is based on the observation that meeting the highlighted goal makes the other goals easy.<br />
It is based on branchy development in which each branch has a well-defined purpose.<br />
<br />
We define two branch types:<br />
<br />
* '''Topic Branch'''<br />
** Commits represent ''changes'' (real work)<br />
** Distinguished by ''feature'' (one topic per feature or fix)<br />
** Named locally by each developer (describe purpose of work)<br />
** Heads not published (no named branch on server)<br />
* '''Integration Branch'''<br />
** Commits represent ''merges'' (merge topics together)<br />
** Distinguished by ''stability'' (release maintenance, release preparation, development edge)<br />
** Named everywhere<br />
** Heads published on server<br />
<br />
==Notation==<br />
<br />
This document uses ascii-art to depict commit history:<br />
<br />
{|<br />
|-<br />
|<br />
Branch name<br />
|<br />
master<br />
|-<br />
|<br />
Current branch<br />
|<br />
*'''master'''<br />
|-<br />
|<br />
Commit with parent in same branch<br />
|<br />
----o<br />
|-<br />
|<br />
Commit with parent in another branch<br />
|<br />
\<br />
o<br />
|-<br />
|<br />
Commit with two parents (merge)<br />
|<br />
----o<br />
/<br />
|-<br />
|<br />
Commit with arbitrary ancestry<br />
|<br />
...o<br />
|}<br />
<br />
Topic branches generally consist of a linear sequence of commits forked off an integration branch:<br />
<br />
...o master<br />
\<br />
o----o----o----o ''topic''<br />
<br />
Integration branches generally consist of a sequence of merge commits:<br />
<br />
...o ...o<br />
\ \<br />
...o----o----o----o----o master<br />
/ /<br />
...o ...o<br />
<br />
==Published Branches==<br />
<br />
We publish an ''integration'' branch for each stage of development:<br />
<br />
* '''main''': Release maintenance (high stability). Only bug fixes should be published here. Only the release manager can push here.<br />
* '''master''': Release preparation (medium stability). Only mature features and bug fixes should be published here.<br />
* '''next''': Development (low stability). New features should be published here.<br />
<br />
Topic branches are not published directly; their names exist only in each developer's local repositories.<br />
<br />
=Development=<br />
<br />
We cover below the steps to take during each phase of development.<br />
<br />
==Initial Setup==<br />
<br />
These instructions generally provide all arguments to "<code>git push</code>" commands.<br />
Some people prefer to use "<code>git push</code>" with no additional arguments to push the current tracking branch.<br />
Run the command<br />
<br />
$ git config --global push.default tracking<br />
<br />
to establish this behavior.<br />
See the [http://schacon.github.com/git/git-config.html git config] man-page for details.<br />
<br />
==New Topic==<br />
<br />
Create a new topic branch for each separate feature or bug fix.<br />
Always start the topic from a stable integration branch, usually '''master'''.<br />
If the topic fixes a bug in the current release, use '''maint'''.<br />
''Never'' start a topic from '''next'''!<br />
In the following table we review the steps and commands to create,<br />
develop, and publish a ''topic'' branch based on '''master'''.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Update '''master''' to base work on the most recently integrated features.<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
|<br />
...o *'''master'''<br />
|-<br />
|<br />
:<code>$ git pull</code><br />
|<br />
...o----o *'''master'''<br />
|-<br />
|colspan="2"|<br />
Create the local ''topic'' branch. [[#Naming_Topics|'''Use a meaningful name for''' "'''''topic'''''"]].<br />
|-<br />
|<br />
:<code>$ git checkout -b ''topic''</code><br />
|<br />
...o----o master<br />
^ *'''''topic'''''<br />
|-<br />
|colspan="2"|<br />
This is where the real work happens.<br />
Edit, stage, and commit files repeatedly as needed for your work.<br />
<br />
During this step, [[#Urge_to_Merge|'''avoid the "urge to merge"''']] from an integration branch.<br />
Keep your commits focused on the topic at hand.<br />
|-<br />
|<br />
:<code>$ edit ''files''</code><br><br />
:<code>$ git add -- ''files''</code><br><br />
:<code>$ git commit</code><br />
|<br />
...o----o master<br />
\<br />
o *'''''topic'''''<br />
|-<br />
|<br />
:<code>$ edit ''files''</code><br><br />
:<code>$ git add -- ''files''</code><br><br />
:<code>$ git commit</code><br />
|<br />
...o----o master<br />
\<br />
o----o *'''''topic'''''<br />
|-<br />
|colspan="2"|<br />
When the topic is ready for publication it must be merged into '''next'''.<br />
Do ''not'' merge ''from'' '''next'''!<br />
It should be the current local branch when you merge.<br />
<br />
Switch to '''next''' and update it.<br />
Use "<code>git checkout -b next origin/next</code>" to create a local '''next''' the first time.<br />
|-<br />
|<br />
:<code>$ git checkout next</code><br><br />
:<code>$ git pull</code><br />
|<br />
...o----o master<br />
. \<br />
. o----o ''topic''<br />
.<br />
........o *'''next'''<br />
|-<br />
|colspan="2"|<br />
Merge the ''topic'' and test it.<br />
|-<br />
|<br />
:<code>$ git merge ''topic''</code><br />
|<br />
...o----o master<br />
. \<br />
. o----o ''topic''<br />
. \<br />
........o----o *'''next'''<br />
|align="center"|<br />
[[Git/Workflow/Topic/Conflicts#Multiple_Integration_Branches|conflicts?]]<br />
|-<br />
|colspan="2"|<br />
Finally, publish the change.<br />
|-<br />
|<br />
:<code>$ git push origin next</code><br />
|<br />
...o----o master<br />
. \<br />
. o----o ''topic''<br />
. \<br />
........o----o *'''next''' (and origin/next)<br />
|align="center"|<br />
[[#remote_end_hung_up_unexpectedly|remote end hung up unexpectedly]]?<br />
<br />
[[#non-fast-forward|non-fast-forward]]?<br />
|}<br />
<br />
==Mature Topic==<br />
<br />
When a topic is ready for inclusion in the next release, we merge it into '''master'''.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan=2|<br />
Update '''master''' to get the latest work by others.<br />
We will merge the topic into it.<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
|<br />
...o----o *'''master'''<br />
. \<br />
. o----o ''topic''<br />
. \<br />
........o----o next<br />
|-<br />
|<br />
:<code>$ git pull</code><br />
|<br />
..........<br />
. \<br />
...o----o----o *'''master'''<br />
. \<br />
. o----o ''topic''<br />
. \<br />
........o----o next<br />
|-<br />
|colspan=2|<br />
Merge the ''topic'' and test it.<br />
|-<br />
|<br />
:<code>$ git merge ''topic''</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o *'''master'''<br />
. \ /<br />
. o----o ''topic''<br />
. \<br />
........o----o next<br />
|align="center"|<br />
[[Git/Workflow/Topic/Conflicts#Multiple_Integration_Branches|conflicts?]]<br />
|-<br />
|colspan=2|<br />
Delete the local branch.<br />
|-<br />
|<br />
:<code>$ git branch -d ''topic''</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o *'''master'''<br />
. \ /<br />
. o----o<br />
. \<br />
........o----o next<br />
|-<br />
|colspan="2"|<br />
Finally, publish the change.<br />
|-<br />
|<br />
:<code>$ git push origin master</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o *'''master''', origin/master<br />
\ /<br />
o----o<br />
|align="center"|<br />
[[#remote_end_hung_up_unexpectedly|remote end hung up unexpectedly]]?<br />
<br />
[[#non-fast-forward|non-fast-forward]]?<br />
|}<br />
<br />
Note that '''master''' sees only the topics that have been merged into it.<br />
It cannot reach any of the merges into '''next''':<br />
<br />
..........<br />
. \<br />
...o----o----o---o *'''master'''<br />
\ /<br />
o----o (''topic'')<br />
<br />
==Old Topic==<br />
<br />
Sometimes we need to continue work on an old topic that has already been merged to an integration branch and for which we no longer have a local ''topic'' branch.<br />
To revive an old topic, we create a local branch based on the last commit from the topic (this is ''not'' one of the merges into an integration branch).<br />
<br />
First we need to identify the commit by its hash.<br />
It is an ancestor of the integration branch into which it was once merged, say '''next'''.<br />
Run <code>git log</code> with the <code>--first-parent</code> option to view the integration history:<br />
<br />
$ git log --first-parent next<br />
commit 9057863...<br />
Merge: 2948732 a348901<br />
...<br />
Merge branch ''topicA''<br />
<br />
commit 2948732...<br />
Merge: 1094687 b235725<br />
...<br />
Merge branch ''topicB''<br />
<br />
commit 1094687...<br />
Merge: 8267263 c715789<br />
...<br />
Merge branch ''topicC''<br />
<br />
Locate the merge commit for the topic of interest, say ''topicB''.<br />
It's ''second'' parent is the commit from which we will restart work (<code>b235725</code> in this example).<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan=2|<br />
Create a local ''topic'' branch starting from the commit identified above.<br />
|-<br />
|<br />
:<code>$ git checkout -b ''topic'' b235725</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o master<br />
. \ /<br />
. o----o *'''''topic''''' (b235725)<br />
. \<br />
........o----o----o next<br />
/ /<br />
...o ...o<br />
(c715789) (a348901)<br />
|-<br />
|colspan=2|<br />
Continue development on the topic.<br />
|-<br />
|<br />
:<code>$ edit ''files''</code><br><br />
:<code>$ git add -- ''files''</code><br><br />
:<code>$ git commit</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o master<br />
. \ /<br />
. o----o----o *'''''topic'''''<br />
. \<br />
........o----o----o next<br />
/ /<br />
...o ...o<br />
|-<br />
|<br />
:<code>$ edit ''files''</code><br><br />
:<code>$ git add -- ''files''</code><br><br />
:<code>$ git commit</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o master<br />
. \ /<br />
. o----o----o----o *'''''topic'''''<br />
. \<br />
........o----o----o next<br />
/ /<br />
...o ...o<br />
|-<br />
|colspan=2|<br />
When the new portion of the topic is ready, merge it into '''next''' and test.<br />
|-<br />
|<br />
:<code>$ git checkout next</code><br />
:<code>$ git pull</code><br />
:<code>$ git merge ''topic''</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o master<br />
. \ /<br />
. o----o----o----o ''topic''<br />
. \ \<br />
........o----o----o----o *'''next'''<br />
/ /<br />
...o ...o<br />
|-<br />
|colspan=2|<br />
Publish '''next'''.<br />
|-<br />
|<br />
:<code>$ git push origin next</code><br />
|-<br />
|colspan=2|<br />
Optionally repeat the above, publishing to next, to continue development based on feedback from initial publication.<br />
Finally, when the new changes are mature, merge to '''master''' and publish.<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pull</code><br />
:<code>$ git merge ''topic''</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o---------o *'''master'''<br />
. \ / /<br />
. o----o----o----o topic<br />
. \ \<br />
........o----o----o----o next<br />
/ /<br />
...o ...o<br />
|-<br />
|<br />
:<code>$ git branch -d ''topic''</code><br />
:<code>$ git push origin master</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o---------o *'''master'''<br />
. \ / /<br />
. o----o----o----o<br />
. \ \<br />
........o----o----o----o next<br />
/ /<br />
...o ...o<br />
|}<br />
<br />
Again, note that '''master''' sees only the topics that have been merged into it.<br />
It cannot reach any of the merges into '''next''':<br />
<br />
..........<br />
. \<br />
...o----o----o---o---------o *'''master'''<br />
\ / /<br />
o----o----o----o (''topic'')<br />
<br />
==Dependent Topic==<br />
<br />
Occasionally you may realize that you need the work from another topic to complete work on your topic.<br />
In this case your topic ''depends'' on the other topic, so merging the other topic into yours is [[#Legitimate_Merges|legitimate]].<br />
''Do not'' merge an integration branch that has the other topic.<br />
Use the instructions below to merge ''only the other topic'' without getting everything else.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan="2"|<br />
Fetch the upstream integration branch that has the ''other-topic'' branch, say '''master'''.<br />
|-<br />
|<br />
:<code>$ git fetch origin</code><br />
|<br />
...o (''extra-topic'')<br />
\ \<br />
...o----o-----o----o origin/master<br />
\ \ /^ "Merge branch '<i>other-topic</i>'"<br />
\ o------o 0a398e5<br />
\<br />
o----o *'''''topic'''''<br />
|-<br />
|colspan="2"|<br />
Use <code>git log --first-parent origin/master</code> to find the commit that merges ''other-topic''.<br />
The commit message gives you the name of the other topic branch (we use "''other-topic''" here as a placeholder).<br />
The second parent of the commit (<code>0a398e5</code> in this example) is the end of the ''other-topic'' branch.<br />
Create a local branch from that commit.<br />
|-<br />
|<br />
:<code>$ git branch ''other-topic'' 0a398e5</code><br />
|<br />
...o (''extra-topic'')<br />
\ \<br />
...o----o-----o----o origin/master<br />
\ \ /<br />
\ o------o ''other-topic''<br />
\<br />
o----o *'''''topic'''''<br />
|-<br />
|colspan="2"|<br />
Merge the other branch into your topic.<br />
|-<br />
|<br />
:<code>$ git merge ''other-topic''</code><br />
:<code>$ git branch -d ''other-topic''</code><br />
|<br />
...o (''extra-topic'')<br />
\ \<br />
...o----o-----o----o origin/master<br />
\ \ /<br />
\ o------o<br />
\ \<br />
o----o------o *'''''topic'''''<br />
^ "Merge branch '<i>other-topic</i>' into ''topic''"<br />
|}<br />
(It is also possible to run <code>git merge 0a398e5</code> and then use <code>git commit --amend</code> to write a nice commit message.)<br />
<br />
The ''topic'' branch now looks like this:<br />
<br />
\<br />
...o----o<br />
\ \<br />
\ o------o (''other-topic'')<br />
\ \<br />
o----o------o *'''''topic'''''<br />
<br />
Note that after the merge, the ''other-topic'' is reachable from your ''topic'' but the ''extra-topic'' has not been included.<br />
By not merging from the integration branch we avoided bringing in an unnecessary dependency on the ''extra-topic''.<br />
Furthermore, the message "<code>Merge branch '<i>other-topic</i>' into ''topic''</code>" is very informative about the purpose of the merge.<br />
Merging the whole integration branch would not be so clear.<br />
<br />
==Merge Integration Branches==<br />
<br />
Each [[#Published_Branches|published integration branch]] has a defined level of stability.<br />
Express this relationship by merging more-stable branches into less-stable branches to ensure that they do not diverge.<br />
After merging a mature topic to '''master''', we merge '''master''' into '''next''':<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!Troubleshooting<br />
|-<br />
|colspan=2|<br />
Update '''master''' and then '''next''':<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pull</code><br />
:<code>$ git checkout next</code><br />
:<code>$ git pull</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o master<br />
. \ /<br />
. o----o<br />
. \<br />
........o----o *'''next'''<br />
|-<br />
|colspan=2|<br />
Merge '''master''' into '''next''':<br />
|-<br />
|<br />
:<code>$ git merge master</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o master<br />
. \ / \<br />
. o----o \<br />
. \ \<br />
........o----o---o *'''next'''<br />
|-<br />
|colspan="2"|<br />
Finally, publish the change.<br />
|-<br />
|<br />
:<code>$ git push origin next</code><br />
|<br />
..........<br />
. \<br />
...o----o----o---o master, origin/master<br />
. \ / \<br />
. o----o \<br />
. \ \<br />
........o----o---o *'''next''', origin/next<br />
|align="center"|<br />
[[#remote_end_hung_up_unexpectedly|remote end hung up unexpectedly]]?<br />
<br />
[[#non-fast-forward|non-fast-forward]]?<br />
|}<br />
<br />
=Discussion=<br />
<br />
==History Shape==<br />
<br />
The history graphs produced by this workflow may look complex compared to the fully linear history produced by a rebase workflow (used by CVS and Subversion):<br />
<br />
..........<br />
. \<br />
...o----o----o---o---------o master<br />
. \ / /<br />
. o----o----o----o topic<br />
. \ \<br />
........o----o----o----o next<br />
/ /<br />
...o ...o<br />
<br />
However, consider the shape of history along each branch.<br />
We can view it using Git's <code>--first-parent</code> option.<br />
It traverses history by following only the ''first parent'' of each merge.<br />
The first parent is the commit that was currently checked out when the <code>git merge</code> command was invoked to create the merge commit.<br />
By following only the first parent, we see commits that logically belong to a specific branch.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Command<br />
!width=30%|View<br />
!<br />
|-<br />
|<br />
:<code>$ git log --first-parent ''topic''</code><br />
|<br />
...<br />
\<br />
o----o----o----o topic<br />
|-<br />
|<br />
:<code>$ git log --first-parent master</code><br />
|<br />
\<br />
...o----o----o---o---------o master<br />
/ /<br />
|-<br />
|<br />
:<code>$ git log --first-parent next</code><br />
|<br />
\ \<br />
...o----o----o----o next<br />
/ /<br />
|}<br />
<br />
Each branch by itself looks linear and has only commits with a specific purpose.<br />
The history behind each commit is unique to that purpose.<br />
Topic branches are independent, containing only commits for their specific feature or fix.<br />
Integration branches consist of merge commits that integrate topics together.<br />
<br />
Note that achieving the nice separation of branches requires understanding of the above development procedure and strict adherence to it.<br />
<br />
==Naming Topics==<br />
<br />
This document uses the italicized placeholder "''topic''" in place of a real topic name.<br />
In practice, substitute a meaningful name.<br />
Name topics like you might name functions: concise but precise.<br />
A reader should have a general idea of the feature or fix to be developed given just the branch name.<br />
<br />
Note that topic names are not published as branch heads on the server, so no one will ever see a branch by your topic name unless they create it themselves.<br />
However, the names ''do'' appear in the default merge commit message:<br />
<br />
$ git checkout next<br />
$ git merge ''topic''<br />
$ git show<br />
...<br />
Merge branch '<i>topic</i>' into next<br />
...<br />
<br />
These merge commits appear on the integration branches and should therefore describe the changes they integrate.<br />
Running <code>git log --first-parent</code> as described [[#History_Shape|here]] will show only these merge commits, so their messages should be descriptive of the changes made on their topics.<br />
If you did not choose a good branch name, or feel that the merge needs more explanation than the branch name provides, amend the commit to update the message by hand:<br />
<br />
$ git commit --amend<br />
Merge branch '<i>topic</i>' into next<br />
''(edit the message)''<br />
<br />
==Urge to Merge==<br />
<br />
Avoid the "urge to merge" from an integration branch into your topic.<br />
Keep commits on your topic focused on the feature or fix under development.<br />
<br />
===Habitual Merges===<br />
<br />
Merge your work with others when you are finished with it by merging ''into'' an integration branch as documented above.<br />
Avoid habitual merges ''from'' an integration branch; doing so introduces unnecessary dependencies and complicates the [[#History_Shape|shape of history]].<br />
<br />
Many developers coming from centralized version control systems have trained themselves to regularly update their work tree from the central repository (e.g. "<code>cvs update</code>").<br />
With those version control systems this was a good habit because they did not allow you to commit without first integrating your work with the latest from the server.<br />
When integrating the local and remote changes resulted in conflicts, developers were forced to resolve the conflicts before they could commit.<br />
A mistake during conflict resolution could result in loss of work because the local changes might have been lost.<br />
By regularly updating from the server, developers hoped to avoid this loss of work by resolving conflicts incrementally.<br />
<br />
Developers using Git do not face this problem.<br />
Instead, one should follow a simple motto: "commit first, integrate later".<br />
There is no risk that your work will be lost during conflict resolution because all your changes have been safely committed ''before'' attempting to merge.<br />
If you make a mistake while merging, you always have the option to throw away the merge attempt and start over with a clean tree.<br />
<br />
===Legitimate Merges===<br />
<br />
One reason to merge other work ''into'' your topic is when you realize that your topic depends on it.<br />
See [[#Dependent_Topic|above]] for help with this case.<br />
<br />
Occasionally one may merge directly from '''master''' if there is a good reason.<br />
This is rare, so bring up the reason on your project mailing list first.<br />
''Never merge '''next''' into a topic under any circumstances!!!''<br />
<br />
=Troubleshooting=<br />
<br />
Here we document problems one might encounter while following the workflow instructions above.<br />
This is ''not'' a general Git troubleshooting page.<br />
<br />
==Trouble Merging==<br />
<br />
''TODO: Write this sub-section and link sub-sub-sections from <code>git merge</code> commands above.''<br />
<br />
==Trouble Pushing==<br />
<br />
===remote end hung up unexpectedly===<br />
<br />
Pushing may fail with this error:<br />
<br />
$ git push<br />
fatal: The remote end hung up unexpectedly<br />
<br />
This likely means that you have set a ''push URL'' for the remote repository.<br />
You can see the URL to which it tries to push using <code>-v</code>:<br />
<br />
$ git push -v<br />
Pushing to ''git://public.kitware.com/Project.git''<br />
fatal: The remote end hung up unexpectedly<br />
<br />
The <code>git://</code> repository URL may not be used for pushing; it is meant for efficient read-only anonymous access only.<br />
Instead you need to configure a ssh-protocol URL for pushing:<br />
<br />
$ git config remote.origin.pushurl ''git@public.kitware.com:Project.git''<br />
<br />
(Note that 'pushurl' requires Git >= 1.6.4. Use just 'url' for Git < 1.6.4.) <br />
The URL in the above example is a placeholder.<br />
In practice, '''use the push URL documented for your repository'''.<br />
<br />
The above assumes that you want to push to the same repository that you originally cloned.<br />
To push elsewhere, see help for [http://schacon.github.com/git/git-push.html git push] and [http://schacon.github.com/git/git-remote.html git remote].<br />
<br />
===non-fast-forward===<br />
<br />
When trying to publish new merge commits on an integration branch, perhaps '''next''', the final push may fail:<br />
<br />
$ git push origin next<br />
To ...<br />
! [rejected] next -> next (non-fast-forward)<br />
error: failed to push some refs to '...'<br />
To prevent you from losing history, non-fast-forward updates were rejected<br />
Merge the remote changes before pushing again. See the 'Note about<br />
fast-forwards' section of 'git push --help' for details.<br />
<br />
This means that the server's '''next''' refers to a commit that is not reachable from the '''next''' you are trying to push:<br />
<br />
...o----o master<br />
. \<br />
. o----o topic<br />
. \<br />
. .----o *'''next'''<br />
. .<br />
....o----o origin/next<br />
/<br />
...o (''other-topic'')<br />
<br />
This is the Git equivalent to when <code>cvs commit</code> complains that your file is not up-to-date, but now it applies to the whole project and not just one file.<br />
Git is telling you that it cannot update '''next''' on the server to point at your merge commit because that would throw away someone else's work (such as ''other-topic'').<br />
There are a few possible causes, all of which mean you have not yet integrated your work with the latest from upstream:<br />
<br />
* You forgot to run <code>git pull</code> before <code>git merge</code> so you didn't have everything from upstream<br />
* Someone else managed to merge and push something into '''next''' since you last ran <code>git pull</code><br />
<br />
''Some Git guides may tell you to just <code>git pull</code> again to merge upstream work into yours.''<br />
''That approach is '''not compatible''' with the goals of this workflow.''<br />
We want to preserve a clean [[#History_Shape|shape of history]].<br />
<br />
The solution is to throw away your previous merge and try again, but this time start from the latest upstream work:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!<br />
|-<br />
|<br />
:<code>$ git reset --hard origin/next</code><br />
|<br />
...o----o master<br />
. \<br />
. o----o topic<br />
.<br />
...o----o *'''next''', origin/next<br />
/<br />
...o (''other-topic'')<br />
|-<br />
|<br />
:<code>$ git merge topic</code><br />
|<br />
...o----o master<br />
. \<br />
. o----o topic<br />
. \<br />
...o----o----o *'''next'''<br />
/<br />
...o (''other-topic'')<br />
|-<br />
|colspan="2"|<br />
Now your '''next''' can reach the upstream work as well as yours.<br />
Publish it.<br />
|-<br />
|<br />
:<code>$ git push origin next</code><br />
|<br />
...o----o master<br />
. \<br />
. o----o topic<br />
. \<br />
...o----o----o *'''next''', origin/next<br />
/<br />
...o (''other-topic'')<br />
|}<br />
<br />
See [http://schacon.github.com/git/git-rerere.html git rerere] to help avoid resolving the same conflicts on each merge attempt.<br />
<br />
===first-parent sequence not preserved===<br />
<br />
One goal of this workflow is to preserve a clean [[#History_Shape|shape of history]].<br />
This means that a <code>--first-parent</code> traversal of an integration branch, such as '''master''', should see only the merge commits that integrate topics into the branch:<br />
<br />
\ \<br />
...o----o----o----o master<br />
/ /<br />
<br />
The commits on the individual topic branches are not included in the traversal.<br />
This provides a medium-level overview of the development of the project.<br />
<br />
We enforce the shape of history on the server's integration branches using an update hook at push-time.<br />
Each update must point its branch at a new commit from which a first-parent traversal reaches the old head of the branch:<br />
<br />
master@{1}<br />
\ \ \v<br />
...o----D----C----B----A----M master<br />
/ / \ /<br />
U-----T (''topic'')<br />
<br />
A first-parent traversal of '''master''' from before the update (<code>master@{1}</code>) sees <code>A B C D</code>:<br />
<br />
\ \ \<br />
...o----D----C----B----A master@{1}<br />
/ /<br />
<br />
A first-parent traversal of '''master''' from after the update sees <code>M A B C D</code>:<br />
<br />
\ \ \<br />
...o----D----C----B----A----M master<br />
/ / /<br />
<br />
The above assumes correct history shape.<br />
Now, consider what happens if merge <code>M</code> is incorrectly made on the ''topic'' branch:<br />
<br />
master@{1}<br />
\ \ \v<br />
...o----D----C----B---------A<br />
/ / \ \<br />
U----T----M' master<br />
^ (''topic'')<br />
<br />
Now a first-parent traversal of '''master''' from after the update sees <code>M' T U B C D</code>:<br />
<br />
\ \<br />
...o----D----C----B<br />
/ / \ \<br />
U----T----M' master<br />
^ (''topic'')<br />
<br />
This not only shows details of the ''topic'' branch, but skips over <code>A</code> altogether!<br />
Our update hooks will reject the push in this case because the new '''master''' cannot see the old one in a first-parent traversal.<br />
<br />
There are a few possible causes and solutions to the above problem, but all involve non-strict compliance with the workflow instructions.<br />
A likely cause is that you did not create a local ''topic'' branch but instead committed directly on '''master''' and then pulled from upstream before pushing:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|(Wrong) Actions<br />
!width=30%|Results<br />
!<br />
|-<br />
|<br />
:<code>wrong$ git checkout master</code><br />
|<br />
\ \<br />
...o----D----C----B *'''master''', origin/master<br />
/ /<br />
|-<br />
|<br />
:<code>wrong$ edit ''files''</code><br />
:<code>wrong$ git add ''files''</code><br />
:<code>wrong$ git commit</code><br />
|<br />
\ \<br />
...o----D----C----B origin/master<br />
/ / \<br />
U *'''master'''<br />
|-<br />
|<br />
:<code>wrong$ edit ''files''</code><br />
:<code>wrong$ git add ''files''</code><br />
:<code>wrong$ git commit</code><br />
|<br />
\ \<br />
...o----D----C----B origin/master<br />
/ / \<br />
U----T *'''master'''<br />
|-<br />
|<br />
:<code>wrong$ git push origin master</code><br />
|<br />
Rejected as [[#non-fast-forward|non-fast-forward]].<br />
|-<br />
|<br />
:<code>wrong$ git pull</code><br />
|<br />
\ \<br />
...o----D----C----B---------A origin/master<br />
/ / \ \<br />
U----T----M' *'''master'''<br />
|-<br />
|<br />
:<code>wrong$ git push origin master</code><br />
|<br />
Rejected with [[#first-parent_sequence_not_preserved|this error]].<br />
|}<br />
<br />
The solution in this case is to recreate the merge on the proper branch.<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
!width=30%|Actions<br />
!width=30%|Results<br />
!<br />
|-<br />
|colspan="2"|<br />
First, create a nicely-named ''topic'' branch starting from the first-parent of the incorrect merge.<br />
|-<br />
|<br />
:<code>$ git branch ''topic'' 'master^1'</code><br />
|<br />
\ \<br />
...o----D----C----B---------A origin/master<br />
/ / \ \<br />
U----T----M' *'''master'''<br />
^ ''topic''<br />
|-<br />
|colspan="2"|<br />
Then reset your local '''master''' to that from upstream.<br />
|-<br />
|<br />
:<code>$ git reset --hard origin/master</code><br />
|<br />
\ \<br />
...o----D----C----B----A *'''master''', origin/master<br />
/ / \<br />
U-----T ''topic''<br />
|-<br />
|colspan="2"|<br />
Now create the correct merge commit as described in the workflow instructions above.<br />
|-<br />
|<br />
:<code>$ git merge ''topic''</code><br />
|<br />
\ \<br />
...o----D----C----B----A----M *'''master'''<br />
/ / \ /<br />
U-----T ''topic''<br />
|-<br />
|<br />
:<code>$ git push origin master</code><br />
:<code>$ git branch -d ''topic''</code><br />
|<br />
\ \<br />
...o----D----C----B----A----M *'''master''', origin/master<br />
/ / \ /<br />
U-----T<br />
|}<br />
<br />
===topics must be merged===<br />
<br />
''TODO''<br />
<br />
Note: I was referred to this documentation when my merge to master failed a pre-commit hook. The fix was to add "--no-ff" arg when merging the topic.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Git/Download&diff=62201Git/Download2018-02-05T20:55:00Z<p>Jhlegarreta: Add the historical label after Change-Id: I5b79451da962c95614c65e09679bc8b5c12b6dea was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
==Generic==<br />
<br />
Visit the main Git [http://www.git-scm.com/download download site].<br />
<br />
==Windows==<br />
<br />
Git comes in two flavors on Windows:<br />
<br />
* A Windows native application installer<br />
* A Cygwin package<br />
<br />
Choose one and stick with it.<br />
They do not get along well in a given work tree on disk<br />
(the repository formats are compatible but the "stat cache" of the work tree is not unless <code>core.filemode</code> is <code>false</code>).<br />
<br />
===MSysGit===<br />
<br />
Download the "Full installer for official Git" from [http://code.google.com/p/msysgit/downloads/list here]. You want to download the file that is named something like<br />
<br />
Git-1.8.3-preview20130601.exe<br />
''If you notice that the filename has changed (because a new version was released or something similar), please update this wiki!''<br />
<br />
Run the installer. When prompted, choose to ''not'' modify the <code>PATH</code> and choose the <code>core.autocrlf=true</code> option.<br />
Launch the "Git Bash" tool to get a command line shell with Git.<br />
<br />
===Cygwin===<br />
<br />
Install packages:<br />
<br />
* '''git''': Git command-line tool<br />
* '''gitk''': Graphical history browser<br />
* '''git-completion''': Bash shell completion rules<br />
<br />
Launch a Cygwin command prompt to get a command line shell with Git.<br />
<br />
==Mac==<br />
<br />
===Xcode 4===<br />
<br />
If you have Xcode 4 installed, you already have git installed.<br />
<br />
Verify with:<br />
<br />
$ which git<br />
/usr/bin/git<br />
<br />
$ git --version<br />
git version 1.7.4.4<br />
<br />
===OS X Installer===<br />
<br />
Download an installer from [http://code.google.com/p/git-osx-installer/ here].<br />
<br />
===MacPorts===<br />
<br />
Enter these commands:<br />
<br />
$ sudo port selfupdate<br />
$ sudo port install git-core +doc<br />
<br />
==Linux==<br />
<br />
Popular Linux distributions already come with packages for Git.<br />
Typically the packages are called:<br />
<br />
* '''git-core''': Git command-line tool<br />
* '''git-doc''': Git documentation<br />
* '''gitk''': Graphical history browser</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=62200ITK/Cross Compiling2018-02-05T20:45:19Z<p>Jhlegarreta: Add the historical label after Change-Id Ic1ef99376d11722b1df5a86fb984ae9565d6dbe9 was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
__TOC__<br />
<br />
This page describes the procedure to follow when cross compiling ITK for another system.<br />
<br />
In this page, we will refer to the system as:<br />
<br />
* Target System: The system where the executables are intended to run.<br />
* Build System: The system where the executables are built.<br />
<br />
= In Linux Host for Mac Target =<br />
<br />
In this particular case we illustrate<br />
<br />
* Target System = Mac<br />
* Build System = Linux<br />
<br />
== Major steps ==<br />
<br />
# Build your tool chain in the build system<br />
#* This is the set of compiler and linker that must be build in the '''build''' system, but will know how to generate code for the Target system.<br />
# Create a TryRun ... file in the '''native''' system<br />
#* This could be generated (as a skeleton) with the following commands<br />
<br />
=== Building the ToolChain for Darwin ===<br />
<br />
The following is a script developed by Johannes Schindelin (originally intended for [http://pacific.mpi-cbg.de/wiki/index.php/Fiji FIJI])<br />
<br />
[[Media:Build-macosx-cross-compiler.sh.gz|Script for Building the Darwing Toolchain in Linux]]<br />
<br />
=== Gathering Configuration settings in the target system ===<br />
<br />
Following the advice of the CMake Wiki [http://www.cmake.org/Wiki/CMake_Cross_Compiling]<br />
<br />
Put the following in a file called ToolChain.cmake<br />
<br />
# this one is important<br />
SET(CMAKE_SYSTEM_NAME Linux)<br />
#this one not so much<br />
SET(CMAKE_SYSTEM_VERSION 1)<br />
# specify the cross compiler<br />
SET(CMAKE_C_COMPILER /usr/bin/gcc)<br />
SET(CMAKE_CXX_COMPILER /usr/bin/g++)<br />
# where is the target environment<br />
SET(CMAKE_FIND_ROOT_PATH /usr)<br />
# search for programs in the build host directories<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)<br />
# for libraries and headers in the target directories<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)<br />
<br />
and run it with CMake using the command (in an empty directory)<br />
<br />
cmake -DCMAKE_TOOLCHAIN_FILE=./ToolChain.cmake ~/src/ITK<br />
<br />
This will generate (among many other things) a File called <br />
<br />
TryRunResults.cmake<br />
<br />
Then, manually populate, the values of each one of the fields.<br />
<br />
The values to be put in this file can be taken from the CMakeCache.txt file of a native build in Darwin.<br />
<br />
<br />
Finally, copy this file to the build system.<br />
<br />
=== Using the Configuration in the Host ===<br />
<br />
Now that you have copied the TryRunResuls.cmake file to the host system, you can use it as an initial cache for configuring the build.<br />
<br />
Do the command in the build system.<br />
<br />
cmake -C ~/TryRunResults.cmake ~/src/ITK<br />
<br />
once the configuration is completed you can proceed to build ITK by simply typing<br />
<br />
make<br />
<br />
== The full process scripted ==<br />
<br />
The process as a whole has been scripted in the file below<br />
<br />
[[Media:ITK-cross-compiling-for-macosx.sh.gz|Script for configuring a cross-compilation build]]<br />
<br />
Thanks to Johannes Schindelin for contributing the script.<br />
<br />
= In Linux Host for Windows Target =<br />
<br />
In this particular case we illustrate<br />
<br />
* Target System = Windows<br />
* Build System = Linux<br />
<br />
''Note:'' the [http://mxe.cc/ MXE] project has an ITK package! Just<br />
<br />
cd mxe<br />
make itk<br />
<br />
<br />
== Major steps ==<br />
<br />
# Build your tool chain in the build system<br />
#* This is the set of compiler and linker that must be build in the '''build''' system, but will know how to generate code for the Target system.<br />
#* In this case we use MinGW as the tool chain<br />
# Create a TryRun ... file in the '''native''' system<br />
#* This could be generated (as a skeleton) with the following commands<br />
<br />
=== Building the ToolChain for Windows ===<br />
<br />
The [http://mxe.cc/ MXE] project will build the toolchain nicely, and it even creates a CMake toolchain file.<br />
<br />
The following is a script developed by Johannes Schindelin (originally intended for [http://pacific.mpi-cbg.de/wiki/index.php/Fiji FIJI]).<br />
[[Media:Build-windows-cross-compiler.sh.gz|Script for Building the Windows (MinGW) Toolchain in Linux]]<br />
<br />
=== Gathering Configuration settings in the target system ===<br />
<br />
Following the advice of the CMake Wiki [http://www.cmake.org/Wiki/CMake_Cross_Compiling], put the following in a file called ToolChain.cmake<br />
<br />
# this one is important<br />
SET(CMAKE_SYSTEM_NAME Linux)<br />
#this one not so much<br />
SET(CMAKE_SYSTEM_VERSION 1)<br />
# specify the cross compiler<br />
SET(CMAKE_C_COMPILER /usr/bin/gcc)<br />
SET(CMAKE_CXX_COMPILER /usr/bin/g++)<br />
# where is the target environment<br />
SET(CMAKE_FIND_ROOT_PATH /usr)<br />
# search for programs in the build host directories<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)<br />
# for libraries and headers in the target directories<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)<br />
<br />
Note that if you are using MXE, it already comes with a toolchain file at<br />
<br />
mxe/usr/i686-pc-mingw32/share/cmake/mxe-conf.cmake<br />
<br />
Run CMake using the command (in an empty directory)<br />
<br />
cmake -DCMAKE_TOOLCHAIN_FILE=./ToolChain.cmake ~/src/ITK<br />
<br />
This will generate (among many other things) a File called <br />
<br />
TryRunResults.cmake<br />
<br />
The values to be put in this file can be taken from the CMakeCache.txt file of a native build in Windows. The CMakeCache.txt can be created by manually running a CMake configuration on Windows. Use [https://gist.github.com/thewtex/5931775 this script] to populate the TryRun results with the Windows CMakeCache.txt contents.<br />
<br />
=== Using the Configuration in the Host ===<br />
<br />
Now that you have copied the TryRunResuls.cmake file to the host system, you can use it as an initial cache for configuring the build.<br />
<br />
Do the command in the build system.<br />
<br />
cmake -C ~/TryRunResults.cmake ~/src/ITK<br />
<br />
once the configuration is completed you can proceed to build ITK by simply typing<br />
<br />
make<br />
<br />
The build process will fail when trying to create the HDF5 library.<br />
<br />
[ 73%] Building C object Modules/ThirdParty/HDF5/src/itkhdf5/src/CMakeFiles/H5make_libsettings.dir/H5make_libsettings.c.obj<br />
Linking C executable ../../../../../../bin/H5make_libsettings.exe<br />
[ 73%] Built target H5make_libsettings<br />
Scanning dependencies of target H5detect<br />
[ 73%] Building C object Modules/ThirdParty/HDF5/src/itkhdf5/src/CMakeFiles/H5detect.dir/H5detect.c.obj<br />
Linking C executable ../../../../../../bin/H5detect.exe<br />
[ 73%] Built target H5detect<br />
[ 73%] Generating ../H5lib_settings.c<br />
/bin/sh: ../../../../../../bin/H5make_libsettings.exe: cannot execute binary file<br />
make[2]: *** [Modules/ThirdParty/HDF5/src/itkhdf5/H5lib_settings.c] Error 126<br />
make[1]: *** [Modules/ThirdParty/HDF5/src/itkhdf5/src/CMakeFiles/itkhdf5.dir/all] Error 2<br />
make: *** [all] Error 2<br />
<br />
Copy the executables that were created on the host system, ''bin/H5detect.exe'' and ''bin/H5make_libsettings.exe'' to the Windows target and run them,<br />
<br />
H5detect > H5Tinit.c<br />
H5make_libsettings.exe > H5lib_settings.c<br />
<br />
Then copy the results *.c files to ''Modules/ThirdParty/HDF5/src/itkhdf5/'' in the host build tree. Restart the build,<br />
<br />
make<br />
<br />
= In Linux Host for ARM Target =<br />
<br />
In this particular case we illustrate<br />
<br />
* Target System = Raspberry Pi (ARMv6)<br />
* Build System = Linux (Ubuntu 12.10)<br />
<br />
== Major steps ==<br />
<br />
# Build your tool chain in the build system<br />
#* This is the set of compiler and linker that must be build in the '''build''' system, but will know how to generate code for the Target system.<br />
#* In this case we use crosstool-ng to build the tool chain<br />
# Create a TryRun ... file in the '''native''' system<br />
#* This could be generated (as a skeleton) with the following commands<br />
<br />
=== Building the ToolChain for ARM ===<br />
<br />
* The process is described in detail here: <br />
** http://www.kitware.com/blog/home/post/426<br />
* based on the instructions from: <br />
** http://www.bootc.net/archives/2012/05/26/how-to-build-a-cross-compiler-for-your-raspberry-pi/<br />
<br />
=== Gathering Configuration settings in the target system ===<br />
<br />
Following the advice of the CMake Wiki [http://www.cmake.org/Wiki/CMake_Cross_Compiling]<br />
<br />
Put the following in a file called ToolChain.cmake<br />
<br />
# this one is important<br />
SET(CMAKE_SYSTEM_NAME Linux)<br />
#this one not so much<br />
SET(CMAKE_SYSTEM_VERSION 1)<br />
# specify the cross compiler<br />
SET(CMAKE_C_COMPILER<br />
/home/ibanez/local/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gcc)<br />
SET(CMAKE_CXX_COMPILER<br />
/home/ibanez/local/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-g++)<br />
# where is the target environment<br />
SET(CMAKE_FIND_ROOT_PATH<br />
/home/ibanez/local/x-tools/arm-unknown-linux-gnueabi)<br />
# search for programs in the build host directories<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)<br />
# for libraries and headers in the target directories<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)<br />
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)<br />
<br />
<br />
and run it with CMake using the command (in an empty directory)<br />
<br />
cmake -DCMAKE_TOOLCHAIN_FILE=./ToolChain.cmake ~/src/ITK<br />
<br />
This will generate (among many other things) a File called<br />
<br />
TryRunResults.cmake<br />
<br />
Then, manually populate, the values of each one of the fields.<br />
<br />
The values to be put in this file can be taken from the CMakeCache.txt file of a native build in the Raspberry Pi.<br />
<br />
For reference, <br />
<br />
* Here is a [[Media:CMakeCache_ITK_RaspberryPi.txt|CMakeCache.txt file]] from a native configuration in the Raspberry Pi.<br />
* Here is the corresponding [[Media:TryRunResults_ITK_RaspberryPi.cmake|TryRunResults.cmake file]] after updating values from the Raspberry Pi.<br />
<br />
=== Using the Configuration in the Host ===<br />
<br />
Now that you have copied the TryRunResuls.cmake file to the host system, you can use it as an initial cache for configuring the build.<br />
<br />
Do the command in the build system.<br />
<br />
cmake -C ~/TryRunResults.cmake -DCMAKE_TOOLCHAIN_FILE=./ToolChain.cmake ~/src/ITK<br />
<br />
once the configuration is completed you can proceed to build ITK by simply typing<br />
<br />
make<br />
<br />
=== Dealing with TIFF bootstrapping ===<br />
<br />
The build process of the TIFF library requires to first build an executable file called:<br />
<br />
* mkg3states (renamed as itkmkg3states in ITK)<br />
<br />
in order to generate a file called:<br />
<br />
* tif_fax2sm.c<br />
<br />
Since, during the cross-compilation process we generate executables that are for a different target architecture, the itkmkg3states file that we built, can't be run in the host to generate the tif_fax2sm.c file.<br />
<br />
One way around this is to build the executable for the architecture of the host (e.g. taking it from any other local build of ITK in the host), and use it to replace the itkmkg3states file. Then using it to generate the .c file.<br />
<br />
This can be done with the following commands:<br />
<br />
* cd ITK_CROSS_COMPILED_BINARY_DIR/Modules/ThirdParty/TIFF/src/itktiff<br />
* cp ITK_NATIVE_BINARY_DIR/Modules/ThirdParty/TIFF/src/itktiff/itkmkg3states .<br />
* ./itkmkg3states -c const ITK_CROSS_COMPILED_BINARY_DIR/Modules/ThirdParty/TIFF/src/itktiff/tif_fax3sm.c<br />
<br />
Then it is possible to continue with the "make" process.<br />
<br />
=== Packaging ===<br />
<br />
Once the build finishes, we can package ITK with the command:<br />
<br />
* make package<br />
<br />
this will produce three files (that are independent of each other)<br />
<br />
* ITK-4.4.0-Linux.sh<br />
* ITK-4.4.0-Linux.tar.gz<br />
* ITK-4.4.0-Linux.tar.Z<br />
<br />
For example, copying the ITK-4.4.0-Linux.tar.gz file to the target, and expanding it there will provide a local installation of ITK against which it is possible to build ITK applications.<br />
<br />
=== Extra Links ===<br />
<br />
* http://www.kitware.com/blog/home/post/422<br />
* http://www.kitware.com/blog/home/post/426<br />
* http://www.kitware.com/blog/home/post/428</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62152ITK Release 5/Wish List2017-12-10T10:00:53Z<p>Jhlegarreta: Add code coverage-related aspects to the "Uncategorized minor wishes" items</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Support initializer lists in constructors of array like objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.<br />
<br />
== Uncategorized minor wishes ==<br />
* Suport for remote module testing against multiple versions of ITK.<br />
* Being able to compile a remote module against an installed ITK would be nice for this structure.<br />
* We should consider stripping down the toolkit into a set of core modules for ITK 5, and putting less-used modules into Remote Modules<br />
** Measure the code coverage for Remote Modules.<br />
* Measure the code coverage per PR.<br />
* Rolling compiler support. Each new release will support compilers released in the last 3-5 years. This will allow us to gradually adopt newer language versions, as C++ standards committee aims to revise the language every 3 years.<br />
* Better document and advertise tools that seem extremely useful for making the use (configure, build, use) of ITK or the development of new modules [https://github.com/InsightSoftwareConsortium/ITKDevelopmentEnvironment less dependent] on the local computing resources, or more [https://github.com/InsightSoftwareConsortium/ITKModuleTemplate automated] and flexible, improvements to CI, use of cookiecutter, etc. There are other tools/projects such as [https://github.com/InsightSoftwareConsortium/itk-js itk.js] whose adoption seem to be low.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK&diff=62146ITK2017-12-06T15:45:15Z<p>Jhlegarreta: Resize ITK logo to a reasonable size</p>
<hr />
<div>[[File:Itk.png|center|150x100px]] <br />
<br />
The National Library of Medicine '''[http://www.itk.org/ Insight Segmentation and Registration Toolkit]''' (ITK) is an open-source software system for medical image processing in two, three and more dimensions. <br />
<br />
This is the '''''ITK Wiki''''', a collaborative hypertext database of information, documentation and resources.<br />
<br />
__TOC__<br />
<br />
== Overview ==<br />
<br />
* <big><strong>[[ITK/Getting Started|Getting Started with ITK]]</strong></big><br />
* [[ITK/About|About the Insight Toolkit]]<br />
* [[ITK/FAQ|Frequently Asked Questions (FAQ)]]<br />
* [[ITK/License Information| License Information]]<br />
<br />
== Software Process ==<br />
* [http://itk.org/gitweb?p=ITK.git Git repository] : The version controlled repository.<br />
* [http://review.source.kitware.com/#/q/status:open+project:ITK,n,z Gerrit code review] : Our code review system.<br />
* [http://issues.itk.org/ Issue tracking system] : Where we report and browse bugs.<br />
* [http://www.cdash.org/CDash/index.php?project=Insight&date= Nightly build dashboard] : View the build status on a variety of platforms.<br />
* [[ITK/Development | Development]]<br />
<br />
== Resources ==<br />
<br />
* [[ITK/Documentation| Documentation]]<br />
* [[ITK/Community | Community Corner]]<br />
* [[ITK/Academic | Academic Corner]]<br />
* [[ITK/Professional | Professional Corner]]<br />
* [[ITK/Open_Science| Open Science]]<br />
* [[ITK/Other_Software| Other Software]]<br />
<br />
{{ITKRegister}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=File:Itk.png&diff=62145File:Itk.png2017-12-06T15:40:48Z<p>Jhlegarreta: Jhlegarreta uploaded a new version of &quot;File:Itk.png&quot;</p>
<hr />
<div>itk logo</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Git/Develop/Data&diff=62061ITK/Git/Develop/Data2017-10-08T10:49:24Z<p>Jhlegarreta: Add the historical label after Change-Id I5b79451da962c95614c65e09679bc8b5c12b6dea was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
This page documents how to add test data while developing ITK.<br />
See our [[ITK/Git|table of contents]] for more information.<br />
__TOC__<br />
= Setup =<br />
<br />
The workflow below depends on local hooks to function properly.<br />
Follow the main [[ITK/Git/Develop#Setup|developer setup instructions]] before proceeding.<br />
In particular, run<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/SetupForDevelopment.sh;hb=HEAD <code>SetupForDevelopment.sh</code>]:<br />
<br />
$ ./Utilities/SetupForDevelopment.sh<br />
<br />
= Workflow =<br />
<br />
Our workflow for adding data integrates with our standard Git [[ITK/Git/Develop|development process]].<br />
Start by [[ITK/Git/Develop#Create_a_Topic|creating a topic]].<br />
Return here when you reach the "edit files" step.<br />
<br />
These instructions follow a typical use case of adding a new test with a baseline image.<br />
<br />
== Add Data ==<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Copy the data file into your local source tree.<br />
|-<br />
|<br />
:<code>$ mkdir -p Modules/.../test/Baseline</code><br />
:<code>$ cp ~/''MyTest.png'' Modules/.../test/Baseline/''MyTest.png''</code><br />
|<br />
|}<br />
<br />
== Add Test ==<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Edit the test CMakeLists.txt file and reference the data file in an <code>itk_add_test</code> call.<br />
Specify the file inside <code>DATA{...}</code> using a path relative to the test directory:<br />
:<code>$ edit Modules/.../test/CMakeLists.txt</code><br />
:{|<br />
|<br />
itk_add_test(NAME MyTest COMMAND ... --compare DATA{Baseline/''MyTest.png'',:} ...)<br />
|}<br />
* Files in <code>Testing/Data</code> may be referenced as <code>DATA{${ITK_DATA_ROOT}/Input/''MyInput.png''}</code>.<br />
* If the data file references other data files, e.g. <code>.mhd -> .raw</code>, follow the link to the ExternalData module on the right and read the documentation on "associated" files.<br />
* Multiple baseline images and other series are handled automatically when the reference ends in the ",:" option; follow the link to the ExternalData module on the right for details.<br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ExternalData.cmake;hb=HEAD <code>ExternalData.cmake</code>]<br />
|}<br />
<br />
== Run CMake ==<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
''CMake will [[#ExternalData|move the original file]]. Keep your own copy if necessary.''<br />
<br />
Run cmake on the build tree:<br />
:<code>$ cd ../ITK-build</code><br />
:<code>$ cmake .</code><br />
:''(Or just run "make" to do a full configuration and build.)''<br />
:<code>$ cd ../ITK</code><br />
|align="center"|<br />
[[#Recover_Data_File|Need to recover the original file]]?<br />
|-<br />
|<br />
During configuration CMake will display a message such as:<br />
:{|<br />
|<br />
Linked Modules/.../test/Baseline/''MyTest.png''.md5 to ExternalData MD5/...<br />
|}<br />
This means that CMake converted the file into a data object referenced by a "content link".<br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ExternalData.cmake;hb=HEAD <code>ExternalData.cmake</code>]<br />
|}<br />
<br />
== Commit ==<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Continue to [[ITK/Git/Develop#Create_a_Topic|create the topic]] and edit other files as necessary.<br />
Add the content link and commit it along with the other changes:<br />
:<code>$ git add Modules/.../test/Baseline/''MyTest.png''.md5</code><br />
:<code>$ git add Modules/.../test/CMakeLists.txt</code><br />
:<code>$ git commit</code><br />
|align="center"|<br />
[http://www.kernel.org/pub/software/scm/git/docs/git-add.html <code>git help add</code>]<br />
<br/><br />
[http://www.kernel.org/pub/software/scm/git/docs/git-commit.html <code>git help commit</code>]<br />
|-<br />
|<br />
The local <code>pre-commit</code> hook will display a message such as:<br />
:{|<br />
|<br />
Modules/.../test/Baseline/''MyTest.png''.md5: Added content to Git at refs/data/MD5/...<br />
Modules/.../test/Baseline/''MyTest.png''.md5: Added content to local store at .ExternalData/MD5/...<br />
Content link Modules/.../test/Baseline/''MyTest.png''.md5 -> .ExternalData/MD5/...<br />
|}<br />
This means that the pre-commit hook recognized that the content link references a new data object and [[#pre-commit|prepared it for upload]].<br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/Hooks/pre-commit;hb=HEAD <code>pre-commit</code>]<br />
|}<br />
<br />
== Push ==<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Follow the instructions to [[ITK/Git/Develop#Share_a_Topic|share the topic]].<br />
When you push it to Gerrit for review using<br />
:<code>$ git gerrit-push</code><br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/Git/git-gerrit-push;hb=HEAD <code>git-gerrit-push</code>]<br />
|-<br />
|<br />
part of the output will be of the form<br />
:{|<br />
|<br />
* ...:refs/data/commits/... [new branch]<br />
* HEAD:refs/for/master/''my-topic'' [new branch]<br />
Pushed refs/data and removed local copy:<br />
MD5/...<br />
|}<br />
This means that the git-gerrit-push script pushed the topic and [[#git-gerrit-push|uploaded the data]] it references.<br />
<br />
Options for <code>gerrit-push</code>:<br />
* <code>--dry-run</code>: Report push that would occur without actually doing it<br />
* <code>--no-topic</code>: Push the data referenced by the topic but not the topic itself<br />
|}<br />
<br />
= Building =<br />
<br />
== Download ==<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
For the test data to be downloaded and made available to the tests in your build tree the <code>ITKData</code> target must be built.<br />
One may build the target directly, e.g. <code>make ITKData</code>, to obtain the data without a complete build.<br />
The output will be something like<br />
:{|<br />
|<br />
-- Fetching ".../ExternalData/MD5/..." <br />
-- [download 100% complete] <br />
-- Downloaded object: "''ITK-build''/ExternalData/Objects/MD5/..."<br />
|}<br />
|-<br />
|<br />
The downloaded files appear in <code>''ITK-build''/ExternalData</code> by default.<br />
|<br />
|}<br />
<br />
== Local Store ==<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
It is possible to configure one or more local ExternalData object stores shared among multiple builds.<br />
Configure for each build the advanced cache entry <code>ExternalData_OBJECT_STORES</code> to a directory on your local disk outside all build trees, e.g. "<code>/home/user/.ExternalData</code>":<br />
:<code>$ cmake -DExternalData_OBJECT_STORES=/home/user/.ExternalData ../ITK</code><br />
The ExternalData module will store downloaded objects in the local store instead of the build tree.<br />
Once an object has been downloaded by one build it will persist in the local store for re-use by other builds without downloading again.<br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ExternalData.cmake;hb=HEAD <code>ExternalData.cmake</code>]<br />
|}<br />
<br />
= Discussion =<br />
<br />
An ITK test data file is not stored in the main source tree under version control.<br />
Instead the source tree contains a "content link" that refers to a data object by a hash of its content.<br />
At build time the the<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ExternalData.cmake;hb=HEAD <code>ExternalData.cmake</code>]<br />
module fetches data needed by enabled tests.<br />
This allows arbitrarily large data to be added and removed without bloating the version control history.<br />
<br />
The above [[#Workflow|workflow]] allows developers to add a new data file almost as if committing it to the source tree.<br />
The following subsections discuss details of the workflow implementation.<br />
<br />
== ExternalData ==<br />
<br />
While [[#Run_CMake|CMake runs]] the<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ExternalData.cmake;hb=HEAD ExternalData]<br />
module evaluates [[#Add_Test|DATA{} references]].<br />
ITK [http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ITKExternalData.cmake;hb=HEAD sets]<br />
the <code>ExternalData_LINK_CONTENT</code> option to <code>MD5</code> to enable automatic conversion of raw data files into content links.<br />
When the module detects a real data file in the source tree it performs the following transformation as specified in the module documentation:<br />
* Compute the MD5 hash of the file<br />
* Store the <code>${hash}</code> in a file with the original name plus <code>.md5</code><br />
* Rename the original file to <code>.ExternalData_MD5_${hash}</code><br />
The real data now sit in a file that we [http://itk.org/gitweb?p=ITK.git;a=blob;f=.gitignore;hb=HEAD tell Git to ignore].<br />
For example:<br />
<br />
$ '''cat Modules/.../test/Baseline/.ExternalData_MD5_477e602800c18624d9bc7a32fa706b97 |md5sum'''<br />
477e602800c18624d9bc7a32fa706b97 -<br />
$ '''cat Modules/.../test/Baseline/''MyTest.png''.md5'''<br />
477e602800c18624d9bc7a32fa706b97<br />
<br />
=== Recover Data File ===<br />
<br />
To recover the original file after running CMake but before committing, undo the operation:<br />
<br />
$ '''cd Modules/.../test/Baseline'''<br />
$ '''mv .ExternalData_MD5_$(cat MyTest.png.md5) MyTest.png'''<br />
<br />
== pre-commit ==<br />
<br />
While [[#Commit|committing]] a new or modified content link the<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/Hooks/pre-commit;hb=HEAD <code>pre-commit</code>]<br />
hook moves the real data object from the <code>.ExternalData_MD5_${hash}</code> file left by the ExternalData module<br />
to a local object repository stored in a <code>.ExternalData</code> directory at the top of the source tree.<br />
<br />
The hook also uses Git plumbing commands to store the data object as a blob in the local Git repository.<br />
The blob is not referenced by the new commit but instead by <code>refs/data/MD5/${hash}</code>.<br />
This keeps the blob alive in the local repository but does not add it to the project history.<br />
For example:<br />
$ '''git for-each-ref --format="%(refname)" refs/data'''<br />
refs/data/MD5/477e602800c18624d9bc7a32fa706b97<br />
$ '''git cat-file blob refs/data/MD5/477e602800c18624d9bc7a32fa706b97 | md5sum'''<br />
477e602800c18624d9bc7a32fa706b97 -<br />
<br />
== git gerrit-push ==<br />
<br />
The "<code>git gerrit-push</code>" command is actually an<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD alias]<br />
for the<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/Git/git-gerrit-push;hb=HEAD <code>Utilities/Git/git-gerrit-push</code>]<br />
script.<br />
In addition to pushing the topic branch to Gerrit the script also detects content links added or modified by the commits in the topic.<br />
It reads the data object hashes from the content links and looks for matching <code>refs/data/</code> entries in the local Git repository.<br />
<br />
The script pushes the matching data objects to Gerrit inside a temporary commit object disjoint from the rest of history.<br />
For example:<br />
<br />
$ '''git gerrit-push --dry-run --no-topic'''<br />
* f59717cfb68a7093010d18b84e8a9a90b6b42c11:refs/data/commits/f59717cfb68a7093010d18b84e8a9a90b6b42c11 [new branch]<br />
Pushed refs/data and removed local copy:<br />
MD5/477e602800c18624d9bc7a32fa706b97<br />
$ '''git ls-tree -r --name-only f59717cf'''<br />
MD5/477e602800c18624d9bc7a32fa706b97<br />
$ '''git log --oneline f59717cf'''<br />
f59717c data<br />
<br />
A robot runs every few minutes to fetch the objects from Gerrit and upload them to a<br />
[http://www.itk.org/files/ExternalData location] that we<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=CMake/ITKExternalData.cmake;hb=HEAD tell ExternalData to search]<br />
at build time.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Source&diff=62060ITK/Source2017-10-06T15:06:49Z<p>Jhlegarreta: Add the historical label after Change-Id I5b79451da962c95614c65e09679bc8b5c12b6dea was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
The source distribution for ITK can be obtained in two ways:<br />
<br />
# Official release tarballs<br />
# Git SCM checkout.<br />
<br />
== 1. Official Releases ==<br />
<br />
=== Source code ===<br />
<br />
* http://itk.org/ITK/resources/software.html<br />
<br />
Note that the software must be compiled from source using CMake and your favorite C++ compiler. The toolkit can be installed, but it is not necessary -- it can be used directly from its build directory.<br />
<br />
=== Linux Package Distributions ===<br />
<br />
==== Debian ====<br />
<br />
sudo apt-get install libinsighttoolkit4-dev<br />
<br />
==== Ubuntu ====<br />
<br />
sudo apt-get install libinsighttoolkit4-dev<br />
<br />
This will give you the libraries and development headers.<br />
<br />
For information on other ITK packages and packages for other distributions, see [https://blog.kitware.com/itk-packages-in-linux-distributions/ this blog post].<br />
<br />
== 2. Git ==<br />
<br />
=== Development ===<br />
<br />
git clone https://itk.org/ITK.git<br />
<br />
=== Latest Stable Release ===<br />
<br />
git clone -b release https://itk.org/ITK.git ITKLatestRelease<br />
<br />
=== Previous Releases ===<br />
<br />
You can get specific releases by using the tags,<br />
for example:<br />
<br />
git clone -b v4.10.0 https://itk.org/ITK.git ITK-4.10.0<br />
<br />
<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Git/Download&diff=62059ITK/Git/Download2017-10-06T14:54:11Z<p>Jhlegarreta: Add the historical label after Change-Id I5b79451da962c95614c65e09679bc8b5c12b6dea was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
This page documents how to download ITK through [http://git-scm.com Git].<br />
See our [[ITK/Git|table of contents]] for more information.<br />
<br />
Follow our [[Git/Download|Git download instructions]] to install Git.<br />
<br />
=Clone=<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Clone ITK using the commands<br />
|-<br />
|<br />
:<code>$ git clone git://itk.org/ITK.git</code><br />
:<code>$ cd ITK</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-clone.html <code>git help clone</code>]<br />
<br />
[[Git/Trouble#Firewall_Blocks_Port_9418|Connection refused]]?<br />
|-<br />
|<br />
Clone ITKApps using the commands<br />
|-<br />
|<br />
:<code>$ cd ..</code><br />
:<code>$ git clone git://itk.org/ITKApps.git</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-clone.html <code>git help clone</code>]<br />
|}<br />
<br />
=Update=<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Users that have made no local changes and simply want to update a<br />
clone with the latest changes may run<br />
|-<br />
|<br />
:<code>$ git pull</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-pull.html <code>git help pull</code>]<br />
<br />
|-<br />
|<br />
Avoid making local changes unless you have read our [[ITK/Git/Develop|developer instructions]].<br />
|}<br />
<br />
=Release=<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
After cloning your local repository will be configured to follow the<br />
upstream '''master''' branch by default. This means you will have access to cutting edge features, but along with these may come cutting edge bugs :). One may create a local branch to track the upstream '''release''' branch instead, which should guarantee only bug fixes to the functionality available in the latest release:<br />
|-<br />
|<br />
:<code>$ git checkout --track -b release origin/release</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br />
|-<br />
|<br />
This local branch will always follow the latest release.<br />
Use the [[#Update|above instructions]] to update it.<br />
Alternatively one may checkout a specific release tag:<br />
|-<br />
|<br />
:<code>$ git checkout v3.20.0</code><br />
:<code>$ git submodule update</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br />
[http://schacon.github.com/git/git-submodule.html <code>git help submodule</code>]<br />
|-<br />
|<br />
Release tags never move.<br />
Repeat the command with a different tag to get a different release.<br />
One may list available tags:<br />
|-<br />
|<br />
:<code>$ git tag</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-tag.html <code>git help tag</code>]<br />
|}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Git/Develop&diff=62058ITK/Git/Develop2017-10-06T14:53:51Z<p>Jhlegarreta: Add the historical label after Change-Id I5b79451da962c95614c65e09679bc8b5c12b6dea was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
__NOTOC__<br />
<br />
This page documents how to develop ITK through [http://git-scm.com Git].<br />
See our [[ITK/Git|table of contents]] for more information.<br />
<br />
<i><br />
Git is an extremely powerful version control tool that supports many different "workflows" for indivudal development and collaboration.<br />
Here we document procedures used by the ITK development community.<br />
In the interest of simplicity and brevity we do '''not''' provide an explanation of why we use this approach.<br />
Furthermore, this is '''not''' a Git tutorial.<br />
Please see our [[Git/Resources|Git resource links]] for third-party documentation, such as the [http://git-scm.com/book/ ProGit Book].<br />
</i><br />
<br />
==Setup==<br />
<br />
Before you begin, perform initial setup:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
|-<br />
|width=60%|<br />
1.<br />
Register [[ITK/Git/Account#Gerrit|Gerrit access]] and possibly [[ITK/Git/Account#Git|Git push access]].<br />
|-<br />
|<br />
2.<br />
Optionally download our [[Media:GitITKCheatSheet.pdf|one page PDF desk reference]].<br />
|-<br />
|<br />
3.<br />
Follow the [[ITK/Git/Download#Clone|download instructions]] to create a local ITK clone:<br />
|-<br />
|<br />
:<code>$ git clone git://itk.org/ITK.git</code><br />
|align="center"|<br />
[[Git/Trouble#Firewall_Blocks_Port_9418|Connection refused]]?<br />
|-<br />
|<br />
4.<br />
Run the developer setup script to prepare your ITK work tree and create Git command aliases used below:<br />
|-<br />
|<br />
:<code>$ ./Utilities/SetupForDevelopment.sh</code><br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/SetupForDevelopment.sh;hb=HEAD <code>SetupForDevelopment.sh</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Getting-Started-First-Time-Git-Setup Pro Git: Setup]<br />
|}<br />
Note that if you answer 'y' to the question "Do you want to test push access to itk.org? [y/N]:", you will most likely receive the following error message: "Permission denied (publickey). fatal: Could not read from remote repository.". Only a few experienced contributors have push access. Having push access is not necessary to contribute to ITK.<br />
<br />
==Workflow==<br />
<br />
ITK development uses a [[Git/Workflow/Topic|branchy workflow]] based on topic branches.<br />
Our collaboration workflow consists of three main steps:<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
|-<br />
|width=60%|<br />
1.<br />
Local Development<br />
|-<br />
|<br />
:* [[#Update|Update]]<br />
|-<br />
|<br />
:* [[#Create_a_Topic|Create a Topic]]<br />
|-<br />
|<br />
2.<br />
Code Review<br />
|-<br />
|<br />
:* [[#Share_a_Topic|Share a Topic]] (requires [[ITK/Git/Account#Gerrit|Gerrit access]])<br />
|align="center"|<br />
[http://code.google.com/p/gerrit/ Gerrit Code Review]<br />
|-<br />
|<br />
:* [[#Revise_a_Topic|Revise a Topic]]<br />
|-<br />
|<br />
3.<br />
Integrate Changes<br />
|-<br />
|<br />
:* [[#Merge_a_Topic|Merge a Topic]] (requires [[ITK/Git/Account#Git|Git push access]])<br />
|-<br />
|<br />
:* [[#Delete_a_Topic|Delete a Topic]]<br />
|}<br />
<br />
==Update==<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Update your local '''master''' branch:<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pullall</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.pullall</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-pull.html <code>pull</code>] and<br />
[http://schacon.github.com/git/git-submodule.html <code>submodule</code>] <code>update</code>)<br />
|}<br />
<br />
==Create a Topic==<br />
<br />
All new work must be committed on topic branches.<br />
Name topics like you might name functions: concise but precise.<br />
A reader should have a general idea of the feature or fix to be developed given just the branch name.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
To start a new topic branch:<br />
|-<br />
|<br />
:<code>$ git fetch origin</code><br />
:{|<br />
|-<br />
|<br />
For new development, start the topic from <code>origin/master</code>:<br />
:<code>$ git checkout -b ''my-topic'' origin/master</code><br />
|-<br />
|<br />
For release branch fixes, start the topic from <code>origin/release</code>, and by convention use a topic name starting in "<code>release-</code>":<br />
:<code>$ git checkout -b ''my-topic'' origin/release</code><br />
|}<br />
|align="center"|<br />
[http://schacon.github.com/git/git-fetch.html <code>git help fetch</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-submodule.html <code>git help submodule</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging Pro Git: Basic Branching]<br />
|-<br />
|<br />
Edit files and create commits (repeat as needed). Add a prefix to your commit message (see below).<br />
|-<br />
|<br />
:<code>$ edit ''file1'' ''file2'' ''file3''</code><br />
:''(To add data follow [[ITK/Git/Develop/Data#Add_Data|these instructions]].)''<br />
:<code>$ git add ''file1'' ''file2'' ''file3''</code><br />
:<code>$ git commit</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-add.html <code>git help add</code>]<br />
<br/><br />
[http://schacon.github.com/git/git-commit.html <code>git help commit</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Basics-Recording-Changes-to-the-Repository Pro Git: Recording Changes]<br />
|-<br />
|<br />
''(If your change modifies the "<code>Modules/ThirdParty/KWSys/src/KWSys</code>" directory please contribute directly to [[KWSys/Git|KWSys]] instead.)''<br />
|-<br />
|<br />
Standard prefixes for ITK commit messages :<br />
* BUG: Fix for runtime crash or incorrect result<br />
* COMP: Compiler error or warning fix<br />
* DOC: Documentation change<br />
* ENH: New functionality<br />
* PERF: Performance improvement<br />
* STYLE: No logic impact (indentation, comments)<br />
* WIP: Work In Progress not ready for merge<br />
|<br />
|}<br />
<br />
==Share a Topic==<br />
<br />
When a topic is ready for review and possible inclusion, share it by pushing to Gerrit.<br />
Be sure you have registered for [[ITK/Git/Account#Gerrit|Gerrit access]].<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
Check what commits will be pushed to Gerrit for review:<br />
|-<br />
|<br />
:<code>$ git prepush</code><br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.prepush</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-log.html <code>log</code>] <code>origin/master..</code>)<br />
|-<br />
|<br />
Push commits in your topic branch for review by the community:<br />
|-<br />
|<br />
:<code>$ git gerrit-push</code><br />
:''(If the topic adds data see [[ITK/Git/Develop/Data#Push|this note]].)''<br />
or if you started the topic from the release branch:<br />
:<code>$ git push gerrit HEAD:refs/for/release/''my-topic'' </code> <br />
|align="center"|<br />
[[ITK/Git/Account#Firewall_blocks_SSH_traffic|Connection refused]]?<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.gerrit-push</code>]<br />
<br/><br />
([http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/Git/git-gerrit-push;hb=HEAD <code>Utilities/Git/git-gerrit-push</code>])<br />
|}<br />
Find your change in the [http://review.source.kitware.com/p/ITK ITK Gerrit] instance and add [[ITK/Gerrit/Reviewers|reviewers]].<br />
<br />
==Revise a Topic==<br />
<br />
If a topic is approved during Gerrit review, skip to the [[#Merge_a_Topic|next step]].<br />
Otherwise, revise the topic and push it back to Gerrit for another review.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
To revise the most recent commit on the topic edit files and add changes normally and then amend the commit:<br />
|-<br />
|<br />
:<code>$ git commit --amend</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-commit.html <code>git help commit</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-the-Last-Commit Pro Git: Changing the Last Commit]<br />
|-<br />
|<br />
To revise commits further back on the topic, say the <code>3</code>rd commit back:<br />
|-<br />
|<br />
:<code>$ git rebase -i HEAD~3</code><br />
''(Substitute the correct number of commits back, as low as ''<code>1</code>''.)''<br />
<br />
Follow Git's interactive instructions.<br />
Preserve the <code>Change-Id:</code> line at the bottom of each commit message.<br />
|align="center"|<br />
[http://schacon.github.com/git/git-rebase.html <code>git help rebase</code>]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages Pro Git: Changing Multiple Commits]<br />
<br/><br />
[http://git-scm.com/book/en/Git-Branching-Rebasing Pro Git: Rebasing]<br />
|-<br />
|<br />
Return to the [[#Share_a_Topic|previous step]] to share the revised topic.<br />
|}<br />
<br />
==Test a Topic==<br />
<br />
When a patch is submitted, it is tested across the three major platforms<br />
before being merged and tested on many platforms and configurations on the <br />
[https://open.cdash.org/index.php?project=Insight nightly dashboard]. <br />
<br />
If tests fail on a submitted topic, see the [[#Revise_a_Topic|previous step]]<br />
on how to submit a revised version. After a topic is merged, please<br />
check the next day's nightly dashboard to ensure there are not any regressions. <br />
If there are any new warnings or errors, submit a follow-up patch as soon<br />
as possible. <br />
<br />
When a patch is submitted, MacOSX-Clang, Windows-MSVC, and Linux-GCC builds will<br />
start. Once they have finished, the build robots will make a comment on the patch<br />
with a link to their results visualized in CDash and mark the patch set as <br />
''Verified +1'' or ''Not Verified -1''. The results are submitted by the<br />
Kitware Build Robot Gerrit user. <br />
<br />
Builds can be spawned by adding the following comments to a<br />
patch set in Gerrit.<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
|-<br />
|<br />
:<code>request build: all</code><br />
|align="center"|<br />
MacOSX, Linux, Windows<br />
|-<br />
|<br />
:<code>request build: osx</code><br />
|align="center"|<br />
MacOSX<br />
|-<br />
|<br />
:<code>request build: linux</code><br />
|align="center"|<br />
Linux<br />
|-<br />
|<br />
:<code>request build: windows</code><br />
|align="center"|<br />
Windows<br />
|-<br />
|<br />
:<code>request build: python</code><br />
|align="center"|<br />
Python Wrapping (Linux, MacOSX, Windows)<br />
|-<br />
|<br />
:<code>request build: power8</code><br />
|align="center"|<br />
[https://en.wikipedia.org/wiki/POWER8 POWER8]<br />
|-<br />
|<br />
:<code>request build: cpp11</code><br />
|align="center"|<br />
C++11 (Linux, MacOSX, Windows)<br />
|-<br />
|<br />
:<code>request build: cpp14</code><br />
|align="center"|<br />
C++14 (Linux, MacOSX, Windows)<br />
|-<br />
|}<br />
<br />
==Merge a Topic==<br />
'''Only authorized developers with [[ITK/Git/Account#Git|Git push access]] to <code>itk.org</code> may perform this step.'''<br />
<br />
After a feature topic has been reviewed and approved in Gerrit, merge it into the upstream repository.<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout the topic if it is not your current branch:<br />
|-<br />
|<br />
:<code>$ git checkout ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
|-<br />
|<br />
Merge the topic, which is originally forked off the master branch, to master branch:<br />
|-<br />
|<br />
:<code>$ git gerrit-merge</code><br />
<br />
:''(If the merge conflicts follow the printed instructions to resolve them.)''<br />
|align="center"|<br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.gerrit-merge</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-push.html <code>push</code>] to [[Git/Workflow/Stage|topic stage]] and<br />
<br/><br />
<code>stage ITK merge ''my-topic''</code>)<br />
<br/><br />
[[Git/Workflow/Topic/Conflicts#Branch-to-Topic|Branch-to-Topic Conflict Resolution]]<br />
|}<br />
<br />
For bug fixes that are ready to be included in the next patch release, please email the release manager,<br />
[[User:Matt.mccormick| Matt McCormick]], for assistance.<br />
<br />
Here are the recommended steps to merge a topic to both release and master branches, assuming the topic<br />
branch is forked off the release branch:<br />
:<code>$ git checkout release</code><br />
:<code>$ git merge --no-ff ''my-topic''</code><br />
:<code>$ git push origin release</code><br />
and do:<br />
:<code>$ git checkout master</code><br />
:<code>$ git merge --no-ff release</code><br />
:<code>$ git push origin master</code><br />
to merge the release branch back to master.<br />
<br />
==Delete a Topic==<br />
<br />
After a topic has been merged upstream, delete your local branch for the topic.<br />
<br />
{| style="width: 100%"<br />
|-<br />
|width=60%|<br />
Checkout and update the '''master''' branch:<br />
|-<br />
|<br />
:<code>$ git checkout master</code><br />
:<code>$ git pullall</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-checkout.html <code>git help checkout</code>]<br />
<br/><br />
[http://itk.org/gitweb?p=ITK.git;a=blob;f=Utilities/DevelopmentSetupScripts/SetupGitAliases.sh;hb=HEAD <code>alias.pullall</code>]<br />
<br/><br />
([http://schacon.github.com/git/git-pull.html <code>pull</code>] and<br />
[http://schacon.github.com/git/git-submodule.html <code>submodule</code>] <code>update</code>)<br />
|-<br />
|<br />
Delete the local topic branch:<br />
|-<br />
|<br />
:<code>$ git branch -d ''my-topic''</code><br />
|align="center"|<br />
[http://schacon.github.com/git/git-branch.html <code>git help branch</code>]<br />
|-<br />
|<br />
The <code>branch -d</code> command works only when the topic branch has been correctly merged.<br />
Use <code>-D</code> instead of <code>-d</code> to force the deletion of an unmerged topic branch<br />
(warning - you could lose commits).<br />
|}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Git/Dashboard&diff=62057ITK/Git/Dashboard2017-10-06T14:53:48Z<p>Jhlegarreta: Add the historical label after Change-Id I5b79451da962c95614c65e09679bc8b5c12b6dea was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
__NOTOC__<br />
<br />
This page documents how to use the ITK '''dashboard''' branch in [http://git-scm.com Git].<br />
See our [[ITK/Git|table of contents]] for more information.<br />
<br />
==Using the dashboard scripts==<br />
<br />
{| style="width: 100%" cellspacing="0" cellpadding="0"<br />
|-<br />
|width=60%|<br />
The [[ITK/Git#Branches| dashboard]] branch contains a dashboard client helper script.<br />
Use these commands to track it:<br />
|-<br />
|<br />
:<code>$ mkdir -p ~/Dashboards/ITKScripts</code><br />
:<code>$ cd ~/Dashboards/ITKScripts</code><br />
:<code>$ git init</code><br />
:<code>$ git remote add -t dashboard origin http://itk.org/ITK.git</code><br />
:<code>$ git pull origin</code><br />
|-<br />
|<br />
The <code>itk_common.cmake</code> script contains setup instructions in its top comments.<br />
<br />
Update the '''dashboard''' branch to get the latest version of this script by simply running<br />
|-<br />
|<br />
:<code>$ git pull origin</code><br />
|}<br />
<br />
Here is a link to the script as it appears today: [http://itk.org/gitweb?p=ITK.git;a=blob;f=itk_common.cmake;hb=dashboard itk_common.cmake]<br />
<br />
==Making changes to the dashboard scripts==<br />
<br />
If you find bugs in the hooks themselves or would like to add new features, the can be edited in the usual Git manner.<br />
<br />
$ git checkout -b my_topic_branch<br />
<br />
Make your edits, test it, and commit the result. Create a patch file with:<br />
<br />
$ git format-patch origin/dashboard<br />
<br />
And email the results to the developer's mailing list.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Git&diff=62056ITK/Git2017-10-06T14:51:49Z<p>Jhlegarreta: Add the historical label after Change Id I5b79451da962c95614c65e09679bc8b5c12b6dea was merged</p>
<hr />
<div>{{ Historical }}<br />
<br />
==Introduction==<br />
<br />
ITK version tracking and development is hosted by [http://git-scm.com Git].<br />
Please select a task for further instructions:<br />
<br />
{|border="0"<br />
|-<br />
|width=70%|<br />
Main Tasks:<br />
|-<br />
|<br />
:*<span style="font-size: 1.5em">[[Git/Download|Install Git]]</span> - Git 1.6.6 or greater is preferred (required for development)<br />
|-<br />
|<br />
:*<span style="font-size: 1.5em">[[ITK/Git/Download|Download ITK]] - Users start here</span><br />
|-<br />
|<br />
:*<span style="font-size: 1.5em">[[ITK/Git/Develop|Develop ITK]] - Contributors start here</span><br />
|-<br />
|<br />
Other Tasks:<br />
|-<br />
|<br />
:*<span style="font-size: 1.5em">[[ITK/Git/Dashboard|Test ITK]]</span> - CDash client setup<br />
|-<br />
|<br />
:*<span style="font-size: 1.5em">[[Git/Resources|Learn Git]]</span> - Third-party documentation<br />
|}<br />
<br />
''The remainder of this page provides reference information and links. It is not intended to provide instructions.''<br />
<br />
==Repositories==<br />
<br />
One may browse the repositories online using the [https://git.wiki.kernel.org/index.php/Gitweb Gitweb] interface at http://itk.org/gitweb.<br />
<br />
{|border="1" cellspacing="0" cellpadding="3"<br />
!Repository<br />
!Purpose<br />
!Access<br />
!URL<br />
|-<br />
|rowspan=3|<code>ITK.git</code><br />
|rowspan=3|Insight Toolkit<br />
|clone (git)<br />
|<code>git://itk.org/ITK.git</code><br />
|-<br />
|clone (http)<br />
|<code>http://itk.org/ITK.git</code><br />
|-<br />
|push (ssh)<br />
|<code>git@itk.org:ITK.git</code><br />
|-<br />
|rowspan=3|<code>stage/ITK.git</code><br />
|rowspan=3|ITK Topic Stage<br />
|clone (git)<br />
|<code>git://itk.org/stage/ITK.git</code><br />
|-<br />
|clone (http)<br />
|<code>http://itk.org/stage/ITK.git</code><br />
|-<br />
|push (ssh)<br />
|<code>git@itk.org:stage/ITK.git</code><br />
|-<br />
|rowspan=3|<code>ITKApps.git</code><br />
|rowspan=3|Insight Applications<br />
|clone (git)<br />
|<code>git://itk.org/ITKApps.git</code><br />
|-<br />
|clone (http)<br />
|<code>http://itk.org/ITKApps.git</code><br />
|-<br />
|push (ssh)<br />
|<code>git@itk.org:ITKApps.git</code><br />
|-<br />
|rowspan=3|<code>ITKData.git</code><br />
|rowspan=3|ITK <code>Testing/Data</code> Submodule<br />
|clone (git)<br />
|<code>git://itk.org/ITKData.git</code><br />
|-<br />
|clone (http)<br />
|<code>http://itk.org/ITKData.git</code><br />
|-<br />
|push (ssh)<br />
|<code>git@itk.org:ITKData.git</code><br />
|}<br />
<br />
==Branches==<br />
<br />
At the time of this writing the <code>ITK.git</code> repository has the following branches:<br />
<br />
* '''master''': Development (default)<br />
* '''release''': Maintenance of latest release<br />
* '''release-3.20''': Maintenance of the ITKv3 series<br />
* '''nightly-master''': Follows '''master''', updated at 01:00 UTC<br />
* '''hooks''': Local commit hooks ([[Git/Hooks#Local|place]] in .git/hooks)<br />
* '''dashboard''': Dashboard script ([[ITK/Git/Dashboard|setup]] a CDash client)<br />
<br />
Release branches converted from CVS have been artificially merged into master.<br />
Actual releases have tags named by the release version number.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_Schedule&diff=62047ITK/Release Schedule2017-10-02T10:26:54Z<p>Jhlegarreta: Update the current release number and next release number and forecast</p>
<hr />
<div>The next feature release is 4.13 scheduled for December, 2017.<br />
<br />
== Release Life Cycle ==<br />
<br />
=== Last period for adding classes and features ===<br />
<br />
* New classes will be selected from good reviews from the Insight Journal<br />
* New features and new methods can be added during this period.<br />
<br />
=== Feature Freeze ===<br />
<br />
* Increase code coverage<br />
** address any UNTESTED files<br />
** address files with code coverage lower than 80%<br />
* Address Run-time memory issues<br />
** Purify reports<br />
** Valgrind reports<br />
<br />
=== RC process ===<br />
<br />
* No new features should merged during the feature freeze, i.e. ''ENH:'' commits, although they can be prepared in Gerrit.<br />
* Release candidates (RC's) will be tagged weekly.<br />
* RC's will be tagged after dashboard examination and discussion at the Friday TCon.<br />
* The repository will be hard frozen to only allow merging by gatekeepers on Wednesday evening before the dashboards start. The freeze will be released after tagging.<br />
* For the final RC, only gatekeeper merges will occur.<br />
<br />
=== Posting Tarballs ===<br />
<br />
* Tarballs are posted to SourceForge<br />
* Tarballs are linked from the ITK Download Page<br />
<br />
== Release Schedule ==<br />
<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Release Number !! Date <br />
|-<br />
| 4.12.2 || September 14th, 2017<br />
|-<br />
| 4.13 RC Cycles|| December 4th, 2017<br />
|-<br />
| 4.13 Final Release || December 18th, 2017<br />
|}<br />
<br />
== Check-list for Moving Code from IJ to Gerrit and from Gerrit ==<br />
<br />
=== For IJ Articles To Gerrit ===<br />
<br />
* Responsible developer should add a review '''before''' moving into local copy of Gerrit. Please provide authors with feedback regarding changes that were made to conform to ITK style/documentation etc.<br />
<br />
=== For Adding Images to Input or Baseline ===<br />
<br />
* Images should be '''SMALL'''.<br />
** The source tree is not an image database, but a source code repository.<br />
** Adding an image larger than 50Kb should be justified by a discussion in the Developers list<br />
* Regression images should not use Analyze format unless the test is for the AnalyzeImageIO and related classes.<br />
* Images should use non-trivial Metadata.<br />
** Origin should be different form zeros<br />
** Spacing should be different from ones, and it should be anisotropic<br />
** Direction should be different from Identity<br />
<br />
=== For Moving Code From Review ===<br />
* At least one independent (other than contributor) should sign off on the API<br />
* Coverage should be as close to 100% as possible.<br />
** and never lower than 90%.<br />
** For example, itkTransformIOBase.cxx is only at 63% coverage. Should be easily fixed by adding a Print() to one of the tests.<br />
<br />
=== For All ===<br />
* Check all comments for proper English<br />
* Should pass KWStyle. IJ articles should be checked with KWStyle before checking into repository.<br />
* Should pass PrintSelf. IJ articles should pass PrintSelf check before checking into repository.<br />
* Replace itkGetMacro with itkGetConstMacro.<br />
* Header file should contain Insight Journal citation<br />
** Using the "handle" link.<br />
* Progress should be present for all filters. Use itk::SimplerFilterWatcher to exercise progress and PrintSelfs.<br />
* When appropriate, class should handle image directions. Tests should use non-default values for origin, spacing and dimension.<br />
** GaborImageSource did not provide methods to set/get directions.<br />
* Regression tests' names should, when possible, have the same name as the class tested (plus the ''Test'' keyword: e.g. ''itkGaborKernelFunctionTest.cxx'').<br />
* Exceptions should be descriptive and provide as much information as possible<br />
* Member data should be private with access if required through Get methods.<br />
<br />
== Release Changelogs ==<br />
<br />
[[ITK/Releases|Release Changelogs]]</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK_Release_4/Modern_C%2B%2B&diff=61996ITK Release 4/Modern C++2017-09-18T17:55:27Z<p>Jhlegarreta: Specified supported clang versions</p>
<hr />
<div>= Goal =<br />
<br />
* Take advantage of advances in C++<br />
<br />
= Path =<br />
<br />
* 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). <br />
<br />
= Specifics =<br />
<br />
The following lists specify what compilers will be supported and what compilers will not be supported in the first release of ITKv4.<br />
<br />
== Will Not Support ==<br />
<br />
Specifically remove support for <br />
<br />
* Visual Studio 6.0<br />
* Visual Studio 7.0<br />
* 7.1 (Until 2012) <br />
* 8 SP 1 (Until 2015)<br />
* Borland version 5.5<br />
* Sun Studio compilers prior to 5.9<br />
* IRIX compilers<br />
* Metrowerks Codewarrior compilers<br />
* cygwin 1.5 (newer versions may work, but are not being targeted)<br />
* gcc prior to 3.4<br />
* Darwin ppc (Until 2015)<br />
<br />
== Will Support ==<br />
As a general statement, we support compilers that submit nightly to the [http://www.cdash.org/CDash/index.php?project=Insight ITK dashboard]. Currently these include:<br />
<br />
=== Fully Committed to Support ===<br />
<br />
* GCC 4.x<br />
* Visual Studio<br />
** 9 (Until 2018)<br />
** 10 (Until 2020)<br />
** 11 (Until 2022)<br />
** 12 (Until 2023)<br />
** 13 (Until 2025)<br />
* Intel Compiler Suite<br />
** 11.x<br />
** 12.x<br />
* MacOSX-icc-rel <br />
* Win32-mingw-gcc-4.5<br />
* Apple clang-600.0.56<br />
* Clang 3.3 and later<br />
<br />
<br />
The following table illustrate the phase-out schedule of multiple compilers.<br />
<br />
The stage "If community supported" means that ITK will only support that compiler if volunteers from the community commit to submitting Nightly Dashboard builds and to address/fix any problem that may arise in those platforms.<br />
<br />
{| border="0"<br />
|Compiler<br />
|2011<br />
|2012<br />
|2013<br />
|2014<br />
|2015<br />
|2016<br />
|2017<br />
|2018<br />
|2019<br />
|2020<br />
|2021<br />
|2022<br />
|2023<br />
|2024<br />
|2025<br />
|2026<br />
|-<br />
|[[http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Version_history|"VisualStudio 7.1"]]<br />
|colspan="1" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|Visual Studio 8<br />
|colspan="3" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|Visual Studio 9<br />
|colspan="8" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|Visual Studio 10<br />
|colspan="10" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="3" bgcolor="red"|<br />
|-<br />
|GCC 3.4<br />
|colspan="1" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|GCC 4.2<br />
|colspan="5" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|GCC 4.4<br />
|colspan="8" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|GCC 4.9<br />
|colspan="14" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|}<br />
<br />
=== Legend ===<br />
<br />
{| border="0"<br />
|Label|<br />
|-<br />
|colspan="2" bgcolor="green"|Fully Supported<br />
|-<br />
|colspan="2" bgcolor="yellow"|Phase Out<br />
|-<br />
|colspan="2" bgcolor="red"|If community supported<br />
|}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK_Release_4/Modern_C%2B%2B&diff=61995ITK Release 4/Modern C++2017-09-18T17:53:38Z<p>Jhlegarreta: Removed Darwin; added Apple clang</p>
<hr />
<div>= Goal =<br />
<br />
* Take advantage of advances in C++<br />
<br />
= Path =<br />
<br />
* 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). <br />
<br />
= Specifics =<br />
<br />
The following lists specify what compilers will be supported and what compilers will not be supported in the first release of ITKv4.<br />
<br />
== Will Not Support ==<br />
<br />
Specifically remove support for <br />
<br />
* Visual Studio 6.0<br />
* Visual Studio 7.0<br />
* 7.1 (Until 2012) <br />
* 8 SP 1 (Until 2015)<br />
* Borland version 5.5<br />
* Sun Studio compilers prior to 5.9<br />
* IRIX compilers<br />
* Metrowerks Codewarrior compilers<br />
* cygwin 1.5 (newer versions may work, but are not being targeted)<br />
* gcc prior to 3.4<br />
* Darwin ppc (Until 2015)<br />
<br />
== Will Support ==<br />
As a general statement, we support compilers that submit nightly to the [http://www.cdash.org/CDash/index.php?project=Insight ITK dashboard]. Currently these include:<br />
<br />
=== Fully Committed to Support ===<br />
<br />
* GCC 4.x<br />
* Visual Studio<br />
** 9 (Until 2018)<br />
** 10 (Until 2020)<br />
** 11 (Until 2022)<br />
** 12 (Until 2023)<br />
** 13 (Until 2025)<br />
* Intel Compiler Suite<br />
** 11.x<br />
** 12.x<br />
* MacOSX-icc-rel <br />
* Win32-mingw-gcc-4.5<br />
* Apple clang-600.0.56<br />
* clang<br />
<br />
<br />
The following table illustrate the phase-out schedule of multiple compilers.<br />
<br />
The stage "If community supported" means that ITK will only support that compiler if volunteers from the community commit to submitting Nightly Dashboard builds and to address/fix any problem that may arise in those platforms.<br />
<br />
{| border="0"<br />
|Compiler<br />
|2011<br />
|2012<br />
|2013<br />
|2014<br />
|2015<br />
|2016<br />
|2017<br />
|2018<br />
|2019<br />
|2020<br />
|2021<br />
|2022<br />
|2023<br />
|2024<br />
|2025<br />
|2026<br />
|-<br />
|[[http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Version_history|"VisualStudio 7.1"]]<br />
|colspan="1" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|Visual Studio 8<br />
|colspan="3" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|Visual Studio 9<br />
|colspan="8" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|Visual Studio 10<br />
|colspan="10" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="3" bgcolor="red"|<br />
|-<br />
|GCC 3.4<br />
|colspan="1" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|GCC 4.2<br />
|colspan="5" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|GCC 4.4<br />
|colspan="8" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|-<br />
|GCC 4.9<br />
|colspan="14" bgcolor="green"|<br />
|colspan="1" bgcolor="yellow"|<br />
|colspan="5" bgcolor="red"|<br />
|}<br />
<br />
=== Legend ===<br />
<br />
{| border="0"<br />
|Label|<br />
|-<br />
|colspan="2" bgcolor="green"|Fully Supported<br />
|-<br />
|colspan="2" bgcolor="yellow"|Phase Out<br />
|-<br />
|colspan="2" bgcolor="red"|If community supported<br />
|}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Testing&diff=61518ITK/Testing2017-03-05T11:07:55Z<p>Jhlegarreta: Add further explanations on the testing infrastructure: substitute dart by CDash, described the tested components, the platforms, referenced the SW guide for how to write a test, etc.</p>
<hr />
<div>Testing plays a vital role in the ITK development process. We use the open source, web-based CDash Dashboard Server to display test results.<br />
<br />
=== Is ITK tested regularly? ===<br />
ITK is tested throughout the day on machines distributed around the world. You can view the results at:<br />
<br />
http://open.cdash.org/index.php?project=Insight<br />
<br />
ITK is tested on a variety of platforms and configurations. Nightlies and gerrit submissions are ensured to be tested on Windows, OS X and Linux OS. A wide range of compiler versions are tested. Despite intensive testing, note that '''not all possible compilers and configurations (i.e. external modules, third party-dependent modules, other CMake flags, etc.)''' are tested.<br />
<br />
The ITK components that get tested on a regular basis include:<br />
* The '''ITK code'''.<br />
* The '''Python wrap'''.<br />
* The '''Software Guide'''.<br />
* The '''Examples'''.<br />
* The '''Remote''' modules (non-exhaustive).<br />
<br />
ITK uses CDash to perform builds, run tests and generate dashboards. You can find more information about CDash at http://www.cdash.org.<br />
<br />
=== What is the testing schedule? ===<br />
CDash opens a daily dashboard at 9:00PM Eastern Daylight Time (EDT) and keeps that dashbooard open for 24 hours. Build/Test results submitted as "nightlies" ('''Expected Nightly''') will appear on the currently opened dashboard. Each test site can select a convenient time to run tests.<br />
<br />
Fresh dashboards are generated every hour, on the hour.<br />
<br />
In addition to nightly testing, several sites run '''Continuous''' build/tests. These sites monitor git repository activity and begin a build/test sequence if there are updates to the repository. If a compile error is detected, the Dashboard server sends an email to the "offending" party (author).<br />
<br />
For patches submitted for review to gerrit, the Kitware Build Robot gerrit user automatically builds and tests every patch set on Windows, OS X and Linux OS platforms. These are listed under the '''Gerrit''' section.<br />
<br />
[http://valgrind.org/ Valgrind] is used to identify dynamic analysis defects (e.g. uninitialized variables, memory leaks, etc.) and is run nightly. Its results are displayed under the '''Dynamic Analysis''' section. If a defect is found, the Dashboard server sends an email to the "offending" party (author).<br />
<br />
Finally, '''Experimental''' builds can also be submitted any time by developers around the world.<br />
<br />
=== What kind of testing is performed? ===<br />
ITK has three types of tests:<br />
<br />
# Unit Tests. Also called white box tests. These tests reside inside each module's ''test'' directory. There are meant to exercise a class's methods and verify that the code compiles, links and produces expected results. These tests do not need to produce results that are useful to a user. If a test returns a 0 status, it passes. A test fails if it returns a non-zero status.<br />
# Blackbox Tests. These tests are automatically (or semi-automatically) generated. For example, each Code directory has a test called itkXXXHeaderTest. This test is automatically created and has a "#include" for each file in the directory.<br />
# Regression Tests. These tests generate results and compare them with a known result. The purpose of regression testing is to detect changes in the output of the system. <br />
<br />
=== How Do I Add a Test? ===<br />
<br />
The [https://itk.org/ItkSoftwareGuide.pdf ITK Software Guide] Section 9.4 provides detailed explanations on how to create a test.<br />
<br />
=== What is a continuous build and how can I contribute one? ===<br />
Continuous builds run throughout the day and report their output in the Continuous Builds portion of the dashboard. The most recent build is at the top of the list. The builds run periodically and check the status of the repository. If a file is added or changed since the last build, the working repository of the continuous build is updated, the code compiled and tests executed. Optional e-mail notifications can be sent if there are errors, warnings or test failures.<br />
<br />
You can set up a continuous build. This entails writing some small shell scripts and setting up a scheduler (Scheduler for Windows, cron for Linux/Unix). You will also need to install tcl, checkout Dart and configure your build for testing.<br />
<br />
For Windows 2000, here are three batch files that can be modified for your own environment.<br />
<br />
AllowInsightContinuous.bat<br />
BuildInsightContinuous.bat<br />
PreventInsightContinuous.bat<br />
<br />
The batch files use a lock to prevent/allow the continuous<br />
<br />
rem ************* AllowInsightContinuous.bat<br />
rem Allow the Continuous to run<br />
rem<br />
c:<br />
cd c:\lorensen\InsightContinuous\Insight-VC6<br />
if EXIST continuous.lock (<br />
del continuous.lock<br />
)<br />
cd ..<br />
rem ************* BuildInsightContinuous.bat<br />
rem DO a C++ Build Continuously<br />
rem<br />
c:<br />
rem Setup proxy it behind a firewall<br />
set HTTP_PROXY=webcache<br />
set HTTP_PROXY_PORT=8080<br />
rem<br />
rem Setup the path<br />
rem<br />
set PATH=c:/lorensen/InsightContinuous/Insight-VC6/bin/Release;%PATH%<br />
rem<br />
rem Tell cvs where .cvspass resides<br />
set HOME=c:/lorensen<br />
cd c:\lorensen\InsightContinuous\Insight-VC6<br />
if EXIST continuous.lock (<br />
exit /B<br />
) else (<br />
date /T > continuous.lock<br />
time /T >> continuous.lock<br />
cd c:\lorensen\InsightContinuous\Insight-VC6<br />
tclsh83 c:/lorensen/Dart/Source/Client/DashboardManager.tcl DartConfiguration.tcl Continuous Start Update Configure Build Test Submit<br />
cd c:\lorensen\InsightContinuous\Insight-VC6<br />
del continuous.lock<br />
cd ..<br />
)<br />
rem ***************** PreventInsightContinuous.bat<br />
rem Prevent the Continuous<br />
rem<br />
c:<br />
cd c:\lorensen\InsightContinuous\Insight-VC6<br />
if EXIST continuous.lock (<br />
exit /B<br />
) else (<br />
echo "Prevent continuous for nightly" > continuous.lock<br />
)<br />
cd ..<br />
<br />
Now you need to establish a schedule for the three batch jobs. Use the "Scheduled Tasks" on the "Control Panel" to access the Schedule Task Wizard. The following schedule runs the continuous every 10 minutes from 6:05AM until 12:00AM. The Allow and Prevent scripts turn the build ON/OFF at the appropriate time. Schedule each batch file as follows:<br />
<br />
AllowInsightContinuous.bat - Daily, Start 6:00AM<br />
BuildInsightContinuous.bat - Daily, Start 6:05AM, Advanced: Repeat Task every 10 minutes, duration 17 hours and 55 minutes<br />
PreventContinuous.bat - Daily, Start 12:00AM<br />
<br />
Supporting ITK development process can be as easy as contributing testing results from your platform.<br />
<br />
* Submit testing results using [[CMake Testing With CTest|CTest]]<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=61486ITK/Coding Style Guide2017-02-18T18:08:02Z<p>Jhlegarreta: /* Documenting ivars */ Correct where the ivar documentation should be placed.</p>
<hr />
<div>= C++ Code Style =<br />
<br />
The document located [[media:ITKStyle.pdf|HERE]] describes ITK coding conventions. Developers should follow these conventions when submitting contributions.<br />
<br />
ITK Style Guide<br />
Insight Software Consortium<br />
<br />
== Purpose ==<br />
<br />
The following document is a description of the accepted coding style for the NLM Insight Segmentation<br />
and Registration Toolkit (ITK). Developers who wish to contribute code to ITK should read<br />
and adhere to the standards described here.<br />
<br />
== Document Overview ==<br />
This document is organized into the following sections.<br />
<br />
* System Overview & Philosophy | coding methodologies and motivation for the resulting style.<br />
* Copyright | the copyright header to be included in all files and other copyright issues.<br />
* File organization | how to organize source code; a guide to the ITK directory structure.<br />
* Naming conventions | patterns used to name classes, variables, template parameters, and instance variables.<br />
* Namespaces | the use of namespaces.<br />
* Code Layout and Indentation | accepted standards for arranging code including indentation style.<br />
* Doxygen Documentation System | basic Doxygen formatting instructions.<br />
* Using Standard Macros (itkMacro.h) | use of standard macros in header files.<br />
* Exception Handling | how to add exception handling to the system.<br />
* Documentation Style | a brief section describing the documentation philosophy adopted by the Insight consortium.<br />
<br />
This style guide is an evolving document.<br />
<br />
Please dialog with the ITK developers if you wish to add, modify, or delete the rules described in these guidelines.<br />
<br />
See:<br />
<br />
http://www.itk.org/ITK/help/mailing.html<br />
<br />
for more information about joining the ITK developers mailing list. This forum is one of the best venues in which to propose changes to these style guidelines.<br />
<br />
== Style Guidelines ==<br />
<br />
The following coding-style guidelines have been adopted by the ITK community. To a large extent<br />
these guidelines are a result of the fundamental architectural and implementation decisions made<br />
early in the project. For example, the decision was made to implement ITK with a C++ core using<br />
principles of generic programming, so the rules are oriented towards this style of implementation.<br />
Some guidelines are relatively arbitrary, such as indentation levels and style. However, an attempt<br />
was made to find coding styles consistent with accepted practices. The point is to adhere to a<br />
common style to assist developers and users of the future learn, use, maintain, and extend ITK.<br />
(See the ITK Requirements document for more information.)<br />
Please do your best to be a upstanding member of the ITK community. The rules described here<br />
have been developed with the community as a whole in mind. If you consistently violate these rules<br />
you will likely be harassed mercilessly, first privately and then publicly. If this does not result in<br />
correct code layout, your right to CVS write access (if you are developer and wish to contribute<br />
code) may be removed. Similarly, if you wish to contribute code and are not a developer, your code<br />
will not be accepted until the style is consistent with these guidelines.<br />
<br />
=== System Overview & Philosophy ===<br />
The following implementation strategies have been adopted by the ITK community. These directly<br />
and indirectly affect the resulting code style. Understanding these strategies motivate the reasons<br />
for many of the style guidelines described in this document.<br />
<br />
==== Implementation Language ====<br />
<br />
The core implementation language is C++. C++ was chosen for its flexibility, performance, and<br />
familiarity to consortium members. (Auxiliary, interpreted language bindings such as Tcl, Python,<br />
and/or Java are also planned. These are aimply (run-time interpreted) layers on the C++ code.)<br />
ITK uses the full spectrum of C++ features including const and volatile correctness, namespaces,<br />
partial template specialization, operator overloading, traits, and iterators.<br />
<br />
==== Generic Programming and the STL ====<br />
<br />
Compile-time binding using methods of generic programming and template instantiation is the<br />
preferred implementation style. This approach has demonstrated its ability to create efficient,<br />
flexible code. Use of the STL (Standard Template Library) is encouraged. STL is typically used by<br />
a class, rather than as serving as a base class for derivation of ITK classes. Other STL influences<br />
are iterators and traits. ITK defines a large set of iterators; however, the ITK iterator style differs<br />
in many cases from STL because STL iterators follow a linear traversal model; ITK iterators are<br />
often designed for 2D, 3D, and even n-D traversal. Traits are used heavily be ITK. ITK naming<br />
conventions supersede STL naming conventions; this difference is useful in that it indicates to the<br />
developer something of the boundary between ITK and STL.<br />
<br />
==== Portability ====<br />
ITK is designed to compile on a set of target operating system/compiler combinations.<br />
<br />
These combinations include, but are not limited to:<br />
<br />
* Windows 9x/NT/2000/XP running<br />
** Microsoft Visual C++ version 7.1 to 10<br />
* Solaris with SunPro compiler <br />
* Linux running gcc<br />
* MacOSX running gcc<br />
* Intel compiler on Windows and Linux<br />
<br />
For a full list of the compilers supported please see:<br />
<br />
* [[ITK_Release_4/Modern C++|Modern C++]]<br />
<br />
==== Multi-Layer Architecture ====<br />
ITK is designed with a multi-layer architecture in mind. That is, three layers, a templated layer, a<br />
run-time layer, and an application layer. The templated (or generic) layer is written in C++ and<br />
requires significant programming skills and domain knowledge. The run-time layer is generated<br />
automatically using the CableSwig wrapping system to produce language bindings to Tcl, Python,<br />
and Java. The interpreted layer is easier to use than the templated layer, and can be used for<br />
prototyping and smaller-sized application development. Finally, the application layer is not directly<br />
addressed by ITK other than providing simple examples of applications.<br />
<br />
==== CMake Build Environment ====<br />
The ITK build environment is CMake. CMake is an open-source, advanced cross-platform build<br />
system that enables developers to write simple \makefiles" (named CMakeLists.txt) that are processed<br />
to generated native build tools for a particular operating system/compiler combinations.<br />
See the CMake web pages at http://www.cmake.org for more information.<br />
<br />
==== Doxygen Documentation System ====<br />
<br />
The Doxygen open-source system is used to generate on-line documentation. Doxygen requires the<br />
embedding of simple comments in the code which is in turn extracted and formatted into documentation.<br />
<br />
For more information about Doxygen, please see<br />
<br />
http://www.stack.nl/dimitri/doxygen/<br />
<br />
==== vnl Math Library ====<br />
ITK has adopted the vnl math library. Vnl is a portion of the vxl image understanding environment.<br />
See http://www.robots.ox.ac.uk/ vxl/ for more information about vxl and vnl.<br />
<br />
==== Reference Counting ====<br />
<br />
ITK has adopted reference counting via so-called "smart pointers" to manage object references.<br />
While alternative approaches such as automatic garbage collection were considered, their overhead<br />
due to memory requirements, performance, and lack of control as to when to delete memory, precluded<br />
these methods. Smart pointers manage the reference to objects, automatically incrementing<br />
and deleting an instance's reference count, deleting the object when the count goes to zero.<br />
These are the most important factors influencing the coding style found in Insight. Now we will<br />
look at the details.<br />
<br />
=== Copyright ===<br />
<br />
ITK has adopted a standard copyright. This copyright should be placed at the head of every source<br />
code file. The current copyright header and license reads as follows:<br />
<br />
<pre><nowiki><br />
/*========================================================================= <br />
* <br />
* Copyright Insight Software Consortium <br />
* <br />
* Licensed under the Apache License, Version 2.0 (the "License"); <br />
* you may not use this file except in compliance with the License. <br />
* You may obtain a copy of the License at <br />
* <br />
* http://www.apache.org/licenses/LICENSE-2.0.txt <br />
* <br />
* Unless required by applicable law or agreed to in writing, software <br />
* distributed under the License is distributed on an "AS IS" BASIS, <br />
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. <br />
* See the License for the specific language governing permissions and <br />
* limitations under the License. <br />
* <br />
*=========================================================================*/<br />
</nowiki></pre><br />
<br />
[[ITK Copyright Header|Copyright Header]]<br />
<br />
=== File Organization ===<br />
<br />
Classes are created and (usually) organized into a single class per file set. A file set consists of .h<br />
header file, .cxx implementation file, and/or a .hxx templated implementation file. Helper classes<br />
may also be defined in the file set, typically these are not visible to the system at large, or placed<br />
into a special namespace.<br />
<br />
Source files must be placed in the correct directory for logical consistency with the rest of the<br />
system, and to avoid cyclic dependencies. Currently the ITK source directory structure is found in<br />
ITK/Modules and consists of the following subdirectories:<br />
<br />
* Bridge<br />
* Core<br />
* External<br />
* Filtering<br />
* GPU<br />
* IO<br />
* Nonunit<br />
* Numerics<br />
* Registration<br />
* Segmentation<br />
* ThirdParty<br />
<br />
Each one of these directories represent a Group of Modules.<br />
<br />
Please discuss with the ITK Developers about the best Module to place your new code.<br />
<br />
For a full list of Modules, please see:<br />
<br />
http://www.itk.org/Doxygen/html/modules.html<br />
<br />
=== Naming Conventions ===<br />
<br />
In general, <br />
<br />
* Names are constructed by using case change to indicate separate words, as in TimeStamp<br />
(versus Time Stamp).<br />
* Underscores are not used.<br />
* Variable names are chosen carefully with the intention to convey the meaning behind the code.<br />
* Names are generally spelled out; use of abbreviations is discouraged. (Abbreviation are allowable when in common use, and should be in<br />
uppercase as in RGB.) While this does result in long names, it self-documents the code.<br />
* If you learn how to use name completion in your editor (e.g.,Vim, Emacs), this inconvenience can be minimized.<br />
<br />
Depending on whether the name is a<br />
<br />
* class<br />
* file<br />
* variable<br />
* or other name<br />
<br />
variations on this theme result as explained in the following subsections.<br />
<br />
==== Naming Classes ====<br />
<br />
* Classes are named beginning with a capital letter.<br />
* Classes are placed in the appropriate namespace, typically itk:: (see namespaces below).<br />
* Classes are named according to the following general rule:<br />
class name = <algorithm><input><concept><br />
* In this formula, the name of the algorithm or process (possibly with an associated adjective or<br />
adverb) comes first, followed by an input type (if the class is a filter), and completed by a concept<br />
name.<br />
* A concept is an informal classification describing what a class does. There are many<br />
concepts, here are a few of them.<br />
<br />
The more common or important concepts are underlined.<br />
<br />
* '''Accessor''' Access and convert between types.<br />
* '''Adaptor''' Provide access to a portion of a complex pixel type.<br />
* '''Boundary''' The boundary of a cell.<br />
* '''Calculator''' Compute information.<br />
* '''Classifier''' Classify a pixel.<br />
* '''Container''' A container of objects such as points or cells.<br />
* '''Estimator''' Estimate a value or condition.<br />
* '''Factory''' Object factories are used to create instances.<br />
* '''Filter''' A class that participates in the data processing pipeline. Filters typically take one or more inputs and produce one or more outputs.<br />
* '''Function''' Evaluate a function at a given position.<br />
* '''Identifier''' A unique id for accessing points, cells, or other entities.<br />
* '''Interface''' Classes that specify an abstract interface.<br />
* '''Interpolator''' Interpolate data values, for example at non-pixel values.<br />
* '''Iterator''' Traverse data in various ways (e.g., forward, backward, within a region, etc.)<br />
* '''Mapper''' Transform data from one form into another.<br />
* '''Metric''' Compute similarity between two objects.<br />
* '''Operator''' A class that applies a user-specified function to a region.<br />
* '''Optimizer''' A class that performs numerical optimization.<br />
* '''Pointer''' A smart pointer to an instance of a class. Almost all instance in ITK are referred to via smart pointers.<br />
* '''Reader''' A class that reads a single data object (e.g., image or mesh).<br />
* '''Reference''' A type that refers to another object.<br />
* '''Region''' A subset of a data object, such as an image region.<br />
* '''Source''' A filter that initiates the data processing pipeline such as a reader or a procedural data generator.<br />
* '''Threader''' A class that manages multi-threading.<br />
* '''Traits''' A collection of template parameters used to control the instantiation of other classes.<br />
* '''Transform''' Various types of transformations including affine, procedural, and so on.<br />
* '''Writer''' A filter that terminates the data processing pipeline by writing data to disk or to a communicationsport.<br />
<br />
<br />
The naming of classes is an art form; please review existing names to catch the spirit of the naming<br />
convention.<br />
<br />
Example names include:<br />
<br />
* ShrinkImageFilter<br />
* TriangleCell<br />
* ScalarImageRegionIterator<br />
* NeighborhoodIterator<br />
* MapContainer<br />
* DefaultImageTraits<br />
* BackwardDifferenceOperator<br />
<br />
==== Naming Files ====<br />
<br />
* Files should have the same name as the class, with an "itk" prepended.<br />
* Header files are named .h, while implementation files are named either .cxx or .hxx, depending on whether they are implementations of templated classes.<br />
** For example, the class itk::Image <br />
*** is declared in the file itkImage.h and<br />
*** is defined in the file itkImage.hxx (because Image is templated).<br />
** The class itk::Object<br />
*** is declared in the file itkObject.h<br />
*** and is defined in the file itkObject.cxx<br />
<br />
==== Naming Methods and Functions ====<br />
Global functions and class methods, either static or class members, are named beginning with<br />
a capital letter. The biggest challenge when naming methods and functions is to be consistent<br />
with existing names. For example, given the choice between ComputeBoundingBox() and<br />
CalculateBoundingBox() (CalcBoundingBox() is not allowed because it is not spelled out), the<br />
choice is ComputeBoundingBox() because \Compute" is used elsewhere in the system in similar<br />
settings (The concepts described previously should be used whenever possible).<br />
When referring to class methods in code, an explicit this-> pointer should be used, as in this->ComputeBoundingBox().<br />
The use of the explicit this-> pointer helps clarify exactly which method, and where it originates,<br />
is being invoked. Similarly the \::" global namespace should be used when referring to a global<br />
function.<br />
<br />
==== Naming Class Data Members ====<br />
<br />
Class data members are prepended with m as in m_Size. This clearly indicates the origin of data<br />
members, and differentiates them from all other variables.<br />
<br />
==== Naming Local Variables ====<br />
Local variables begin in lowercase. There is more <br />
flexibility in the naming of local variables; please<br />
remember that others will study, maintain, fix, and extend your code. Any bread crumbs that<br />
you can drop in the way of explanatory variable names and comments will go a long way towards<br />
helping other developers.<br />
<br />
==== Naming Template Parameters ====<br />
Template parameters follow the usual rules with naming except that they should start with either<br />
the capital letter T or V. Type parameters begin with the letter T while value template parameters<br />
begin with the letter V.<br />
<br />
* For template parameters the use of "typename" is preferred over "class". Very early c++ compilers did not have a "typename" keyword, and "class" was repurposed for declaring template parameters. It was later discovered that this lead to ambiguity in some valid code constructs, and the "typename" key word was added. It is often agreed (http://blogs.msdn.com/b/slippman/archive/2004/08/11/212768.aspx) that "typename" is marginally more expressive in its intent and ITK should consistently use "typename" instead of "class".<br />
<br />
==== Naming Typedefs ====<br />
Typedefs are absolutely essential in generic programming. They significantly improve the readibility<br />
of code, and facilitate the declaration of complex syntactic combinations. Unfortunately, creation<br />
of typedefs is tantamount to creating another programming language. Hence typedefs must be used<br />
in a consistent fashion.<br />
The general rule for typedef names is that they end in the word Type. For example<br />
typedef TPixel PixelType;<br />
However, there are many exceptions to this rule that recognize that ITK has several important<br />
concepts that are expressed partially in the names used to implement the concept. An iterator is a<br />
concept, as is a container or pointer. These concepts are used in preference to Type at the end of<br />
a typedef as appropriate. For example<br />
<source lang="cpp"><br />
typedef typename ImageTraits::PixelContainer PixelContainer;<br />
</source><br />
Here Container is a concept used in place of Type.<br />
ITK currently identifies the following concepts used when naming typedefs.<br />
* Self as in typedef Image Self;. All classes should define this typedef.<br />
* Superclass as in typedef ImageBase<VImageDimension> Superclass;. All classes should define the Superclass typedef.<br />
* Pointer as in a smart pointer to an object as in typedef SmartPointer<Self> Pointer;<br />
* Container is a type of container class.<br />
* Iterator an iterator over some container class.<br />
* Identifier or id such as a point or cell id.<br />
<br />
==== Using Underscores ====<br />
Don't use them. The only exception is when defining preprocessor variables and macros (which are<br />
discouraged). In this case, underscores are allowed to separate words.<br />
<br />
==== Preprocessor Directives ====<br />
<br />
* Some of the worst code contains many preprocessor directives and macros. Do not use them except in a very limited sense (to support minor differences in compilers or operating systems). <br />
* If a class makes extensive use of preprocessor directives, it is a candidate for separation into multiple sub-classes.<br />
<br />
==== Header Includes ====<br />
<br />
Header includes use the style<br />
<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
</source><br />
<br />
Only the required headers should be included. If an included header already includes a header for a class also used in the current file, the header for that class should not be included.<br />
<br />
Header includes are preferred over forward declarations. Forward declarations are only used to prevent circular dependencies.<br />
<br />
==== Namespaces ====<br />
<br />
All classes should be placed in the itk:: namespace. Additional sub-namespaces are being designed to support special functionality.<br />
<br />
Please see current documentation to determine if there is a subnamespace is relevant to your situation. Normally sub-namespaces are used for helper ITK classes.<br />
<br />
Code should not use ''using namespace''. This is to avoid namespace conflicts, but, more importantly, to improve readability.<br />
<br />
When declaring or defining members of the "itk" namespace, for example, the 'itk::' namespace prefix should not be added. That is, code within "namespace itk { ... }" should not used "itk::".<br />
<br />
==== Const Correctness ====<br />
<br />
Const correctness is important. Please use it as appropriate to your class or method.<br />
<br />
==== Code Layout and Indentation ====<br />
<br />
The following are the accepted ITK code layout rules and indentation style. After reading this section, you may wish to visit many of the source files found in ITK. This will help crystallize the rules described here.<br />
<br />
==== General Layout ====<br />
<br />
* Each line of code should take no more than 200 characters.<br />
* Break the code across multiple lines as necessary.<br />
* Use lots of whitespace to separate logical blocks of code, intermixed with comments.<br />
* To a large extent the structure of code directly expresses its implementation.<br />
* The appropriate indentation level is '''two spaces''' for each level of indentation.<br />
* '''DO NOT USE TABS.'''<br />
** Set up your editor to insert spaces. Using tabs may look good in your editor but will wreak havoc in others.<br />
* The declaration of variables within classes, methods, and functions should be one declaration per line.<br />
<br />
<source lang="cpp"><br />
int i;<br />
int j;<br />
char* stringname;<br />
</source><br />
<br />
==== Class Layout ====<br />
<br />
Classes are defined using the following guidelines.<br />
* Begin with #include guards.<br />
* Follow with the necessary includes. Include only what is necessary to avoid dependency problems.<br />
* Place the class in the correct namespace.<br />
* Public methods come first.<br />
* Protected methods follow.<br />
* Private members come last.<br />
* Public data members are ''forbidden''.<br />
* Templated classes require a special preprocessor directive to control the manual instantiation of templates. See the example below and look for ITK MANUAL INSTANTIATION.<br />
The class layout looks something like this:<br />
<br />
<source lang="cpp"><br />
#ifndef itkImage_h<br />
#define itkImage_h<br />
<br />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
<br />
namespace itk<br />
{<br />
<br />
/** \class Image<br />
* \brief Templated n-dimensional image class.<br />
*<br />
* .... detailed documentation....<br />
*/<br />
template< typename TPixel, unsigned int VImageDimension=2,<br />
typename TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class Image: public ImageBase< VImageDimension ><br />
{<br />
public:<br />
//....stuff...<br />
protected:<br />
//....stuff...<br />
private:<br />
//....stuff...<br />
};<br />
<br />
} // end namespace itk<br />
<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
<br />
#endif<br />
</source><br />
<br />
==== Method Definition ====<br />
<br />
* Methods are defined across multiple lines. This is to accommodate the extremely long definitions possible when using templates.<br />
* The starting and ending brace should be in column one. For example:<br />
<br />
<source lang="cpp"><br />
template<typename TPixel, unsigned int VImageDimension, typename TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
//...stuff...<br />
}<br />
</source><br />
<br />
* The first line is the template declaration.<br />
* The second line is the method return type.<br />
* The third line is the class qualifier.<br />
* And the fourth line in the example above is the name of the method.<br />
<br />
=== Use of Braces ===<br />
<br />
* Braces must be used to delimit the scope of an if, for, while, switch, or other control structure.<br />
* Braces are placed on a line by themselves:<br />
<br />
<source lang="cpp"><br />
for( unsigned int ii = 0; ii < 3; ++ii )<br />
{<br />
...<br />
}<br />
</source><br />
<br />
<br />
or when using an if:<br />
<br />
<source lang="cpp"><br />
if( condition )<br />
{<br />
...<br />
}<br />
else if( other condition )<br />
{<br />
...<br />
}<br />
else<br />
{<br />
....<br />
}<br />
</source><br />
<br />
<br />
==== Indentation Inside Braces ====<br />
<br />
<br />
Source code in the body of the brackets must be aligned along with the brackets. As in<br />
<br />
<source lang="cpp"><br />
if ( condition )<br />
{<br />
unsigned int numberOfIterations = 100;<br />
filter->SetNumberOfIterations( numberOfIterations );<br />
filter->Update();<br />
filter->Print( std::cout );<br />
}<br />
</source><br />
<br />
=== Doxygen Documentation System ===<br />
<br />
* Doxygen is an open-source, powerful system for automatically generating documentation from source code.<br />
* To use Doxygen effectively, the developer must insert comments, delimited in a special way, that Doxygen extracts to produce the documentation. While there are a large number of options to Doxygen, developers at a minimum should insert the following Doxygen commands.<br />
<br />
See more at<br />
<br />
https://www.stack.nl/~dimitri/doxygen/manual/index.html<br />
<br />
==== Documenting a Class ====<br />
<br />
* Classes should be documented using the '''class''' and '''brief''' Doxygen commands, followed by the detailed class description:<br />
<br />
<source lang="cpp"><br />
/** \class Object<br />
* \brief Base class for most itk classes.<br />
*<br />
* Object is the second-highest level base class for most itk objects.<br />
* It extends the base object functionality of LightObject by<br />
* implementing debug flags/methods and modification time tracking.<br />
*/<br />
</source><br />
<br />
==== Documenting a Method ====<br />
<br />
* Methods should be documented using the following comment block style as shown in the following example. Make sure you use correct English and complete, grammatically correct sentences. Finish your sentences with a period (.).<br />
<br />
<source lang="cpp"><br />
/** Access a pixel at a particular index location.<br />
* This version can be an lvalue. */<br />
TPixel & operator[](const IndexType &index)<br />
{ return this->GetPixel(index); }<br />
</source><br />
<br />
The key here is that the comment starts with /**, each subsequent line has an aligned *, and the comment block terminates with a */.<br />
<br />
* Method documentation should be placed in the '''declaration files''' (*.h): the documentation in the implementation causes ambiguity for Doxygen on which documentation to use, the declaration or definition.<br />
** If there is something that is appropriate for the definition only (*.cxx or *.hxx), it should be placed '''inside the method''', and it could use either the /* */ or the // style comment, but it should not use /** */, which is for Doxygen comments.<br />
<br />
==== Documenting ivars ====<br />
<br />
* Class member variables should be documented through their corresponding Set/Get methods, using a comment block style shown in the following example. Make sure you use correct English and grammatically correct sentences. Finish the documentation line with a period (.).<br />
<br />
<source lang="cpp"><br />
<br />
public:<br />
<br />
/** Set/Get the standard deviation of the Gaussian used for smoothing. */<br />
itkSetMacro( Sigma, SigmaArrayType );<br />
itkGetConstMacro( Sigma, SigmaArrayType );<br />
<br />
private:<br />
<br />
SigmaArrayType m_Sigma;<br />
<br />
</source><br />
<br />
=== Using Standard Macros (itkMacro.h) ===<br />
<br />
* There are several macros defined in the file itkMacro.h.<br />
* These macros should be used because they perform several important operations, that if not done correctly can cause serious, hard to debug problems in the system.<br />
** These operations are:<br />
*** Object modified time is properly managed.<br />
*** Debug information is printed.<br />
*** Reference counting is handled properly.<br />
<br />
Some of the more important object macros are as follows.<br />
<br />
* itkNewMacro(T) Creates the static class method New(void) that interacts with the object factory to instantiate objects. The method returns a SmartPointer<T> properly reference counted.<br />
* itkDebugMacro(x) If debug is set on a subclass of itk::Object, prints debug information to the appropriate output stream.<br />
* itkSetMacro(name,type) Creates a method SetName() that takes argument type type.<br />
* itkGetMacro(name,type) Creates a method GetName() that returns a non-const value of type type.<br />
* itkGetConstMacro(name,type) Creates a method GetName() that returns a const value of type type.<br />
* itkSetStringMacro(name) Creates a method SetName() that takes argument type const char*.<br />
* itkGetStringMacro(name) Creates a method GetName() that returns argument type const char*.<br />
* itkBooleanMacro(name) Creates two methods named NameOn and NameOff that sets true/false boolean values.<br />
* itkSetObjectMacro(name,type) Creates a method SetName() that takes argument type type *.<br />
* itkGetObjectMacro(name,type) Creates a method named GetName() that returns a smart pointer to a type type.<br />
* itkSetConstObjectMacro(name,type) Creates a method SetName() that takes argument type const type *.<br />
* itkGetConstObjectMacro(name,type) Creates a method named GetName() that returns a const smart pointer to a type type.<br />
<br />
Please review this file and become familiar with these macros.<br />
<br />
=== Exception Handling ===<br />
<br />
Indicate that methods throw exceptions in the method declaration as in:<br />
<br />
<source lang="cpp"><br />
const float* foo() const throws itk<br />
</source><br />
<br />
=== Documentation Style ===<br />
<br />
The Insight consortium has adopted the following guidelines for producing supplemental documentation (documentation not produced by Doxygen).<br />
<br />
* The common denominator for documentation is either PDF or HTML. All documents in the system should be available in these formats, even if they are mastered by another system.<br />
* Presentations are acceptable in Microsoft PowerPoint format.<br />
* Administrative and planning documents are acceptable in Microsoft Word format (either .doc or .rtf).<br />
* Larger documents, such as the user's or developer's guide, are written in LATEX.<br />
<br />
== CMake Style ==<br />
<br />
A proposal style guide for CMake variables is presented [[ITK_CMake_Style|HERE]].<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_Schedule&diff=59435ITK/Release Schedule2016-05-08T18:28:57Z<p>Jhlegarreta: /* For All */ Add an e.g. for the regression test name</p>
<hr />
<div>The next feature release is 4.9 scheduled for December, 2015.<br />
<br />
== Release Life Cycle ==<br />
<br />
=== Last period for adding classes and features ===<br />
<br />
* New classes will be selected from good reviews from the Insight Journal<br />
* New features and new methods can be added during this period.<br />
<br />
=== Feature Freeze ===<br />
<br />
* Increase code coverage<br />
** address any UNTESTED files<br />
** address files with code coverage lower than 80%<br />
* Address Run-time memory issues<br />
** Purify reports<br />
** Valgrind reports<br />
<br />
=== RC process ===<br />
<br />
* No new features should merged during the feature freeze, i.e. ''ENH:'' commits, although they can be prepared in Gerrit.<br />
* Release candidates (RC's) will be tagged weekly.<br />
* RC's will be tagged after dashboard examination and discussion at the Friday TCon.<br />
* The repository will be hard frozen to only allow merging by gatekeepers on Wednesday evening before the dashboards start. The freeze will be released after tagging.<br />
* For the final RC, only gatekeeper merges will occur.<br />
<br />
=== Posting Tarballs ===<br />
<br />
* Tarballs are posted to SourceForge<br />
* Tarballs are linked from the ITK Download Page<br />
<br />
== Release 4.10 Schedule ==<br />
<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Release Number !! Date <br />
|-<br />
| RC Cycles|| May 9th, 2016<br />
|-<br />
| Final Release || May 24th, 2016<br />
|}<br />
<br />
== Release 4.11 Schedule ==<br />
<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Release Number !! Date <br />
|-<br />
| RC Cycles|| November 28th, 2016<br />
|-<br />
| Final Release || December 15th, 2016<br />
|}<br />
<br />
<br />
== Check-list for Moving Code from IJ to Gerrit and from Gerrit ==<br />
<br />
=== For IJ Articles To Gerrit ===<br />
<br />
* Responsible developer should add a review '''before''' moving into local copy of Gerrit. Please provide authors with feedback regarding changes that were made to conform to ITK style/documentation etc.<br />
<br />
=== For Adding Images to Input or Baseline ===<br />
<br />
* Images should be '''SMALL'''.<br />
** The source tree is not an image database, but a source code repository.<br />
** Adding an image larger than 50Kb should be justified by a discussion in the Developers list<br />
* Regression images should not use Analyze format unless the test is for the AnalyzeImageIO and related classes.<br />
* Images should use non-trivial Metadata.<br />
** Origin should be different form zeros<br />
** Spacing should be different from ones, and it should be anisotropic<br />
** Direction should be different from Identity<br />
<br />
=== For Moving Code From Review ===<br />
* At least one independent (other than contributor) should sign off on the API<br />
* Coverage should be as close to 100% as possible.<br />
** and never lower than 90%.<br />
** For example, itkTransformIOBase.cxx is only at 63% coverage. Should be easily fixed by adding a Print() to one of the tests.<br />
<br />
=== For All ===<br />
* Check all comments for proper English<br />
* Should pass KWStyle. IJ articles should be checked with KWStyle before checking into repository.<br />
* Should pass PrintSelf. IJ articles should pass PrintSelf check before checking into repository.<br />
* Replace itkGetMacro with itkGetConstMacro.<br />
* Header file should contain Insight Journal citation<br />
** Using the "handle" link.<br />
* Use vcl versions of all transcendental functions.<br />
** For example, itkGaborKernelFunction used sin() and cos() rather than vcl_sin() and vcl_cos().<br />
* Progress should be present for all filters. Use itk::SimplerFilterWatcher to exercise progress and PrintSelfs.<br />
* When appropriate, class should handle image directions. Tests should use non-default values for origin, spacing and dimension.<br />
** GaborImageSource did not provide methods to set/get directions.<br />
* Regression tests' names should, when possible, have the same name as the class tested (plus the ''Test'' keyword: e.g. ''itkGaborKernelFunctionTest.cxx'').<br />
* Exceptions should be descriptive and provide as much information as possible<br />
* Member data should be private with access if required through Get methods.<br />
<br />
== Release Changelogs ==<br />
<br />
[[ITK/Releases|Release Changelogs]]</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_Schedule&diff=59434ITK/Release Schedule2016-05-08T18:26:53Z<p>Jhlegarreta: /* For All */ Correct a typo and develop the regression test name explanation</p>
<hr />
<div>The next feature release is 4.9 scheduled for December, 2015.<br />
<br />
== Release Life Cycle ==<br />
<br />
=== Last period for adding classes and features ===<br />
<br />
* New classes will be selected from good reviews from the Insight Journal<br />
* New features and new methods can be added during this period.<br />
<br />
=== Feature Freeze ===<br />
<br />
* Increase code coverage<br />
** address any UNTESTED files<br />
** address files with code coverage lower than 80%<br />
* Address Run-time memory issues<br />
** Purify reports<br />
** Valgrind reports<br />
<br />
=== RC process ===<br />
<br />
* No new features should merged during the feature freeze, i.e. ''ENH:'' commits, although they can be prepared in Gerrit.<br />
* Release candidates (RC's) will be tagged weekly.<br />
* RC's will be tagged after dashboard examination and discussion at the Friday TCon.<br />
* The repository will be hard frozen to only allow merging by gatekeepers on Wednesday evening before the dashboards start. The freeze will be released after tagging.<br />
* For the final RC, only gatekeeper merges will occur.<br />
<br />
=== Posting Tarballs ===<br />
<br />
* Tarballs are posted to SourceForge<br />
* Tarballs are linked from the ITK Download Page<br />
<br />
== Release 4.10 Schedule ==<br />
<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Release Number !! Date <br />
|-<br />
| RC Cycles|| May 9th, 2016<br />
|-<br />
| Final Release || May 24th, 2016<br />
|}<br />
<br />
== Release 4.11 Schedule ==<br />
<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Release Number !! Date <br />
|-<br />
| RC Cycles|| November 28th, 2016<br />
|-<br />
| Final Release || December 15th, 2016<br />
|}<br />
<br />
<br />
== Check-list for Moving Code from IJ to Gerrit and from Gerrit ==<br />
<br />
=== For IJ Articles To Gerrit ===<br />
<br />
* Responsible developer should add a review '''before''' moving into local copy of Gerrit. Please provide authors with feedback regarding changes that were made to conform to ITK style/documentation etc.<br />
<br />
=== For Adding Images to Input or Baseline ===<br />
<br />
* Images should be '''SMALL'''.<br />
** The source tree is not an image database, but a source code repository.<br />
** Adding an image larger than 50Kb should be justified by a discussion in the Developers list<br />
* Regression images should not use Analyze format unless the test is for the AnalyzeImageIO and related classes.<br />
* Images should use non-trivial Metadata.<br />
** Origin should be different form zeros<br />
** Spacing should be different from ones, and it should be anisotropic<br />
** Direction should be different from Identity<br />
<br />
=== For Moving Code From Review ===<br />
* At least one independent (other than contributor) should sign off on the API<br />
* Coverage should be as close to 100% as possible.<br />
** and never lower than 90%.<br />
** For example, itkTransformIOBase.cxx is only at 63% coverage. Should be easily fixed by adding a Print() to one of the tests.<br />
<br />
=== For All ===<br />
* Check all comments for proper English<br />
* Should pass KWStyle. IJ articles should be checked with KWStyle before checking into repository.<br />
* Should pass PrintSelf. IJ articles should pass PrintSelf check before checking into repository.<br />
* Replace itkGetMacro with itkGetConstMacro.<br />
* Header file should contain Insight Journal citation<br />
** Using the "handle" link.<br />
* Use vcl versions of all transcendental functions.<br />
** For example, itkGaborKernelFunction used sin() and cos() rather than vcl_sin() and vcl_cos().<br />
* Progress should be present for all filters. Use itk::SimplerFilterWatcher to exercise progress and PrintSelfs.<br />
* When appropriate, class should handle image directions. Tests should use non-default values for origin, spacing and dimension.<br />
** GaborImageSource did not provide methods to set/get directions.<br />
* Regression tests' names should, when possible, have the same name as the class tested (plus the ''*Test'' keyword).<br />
* Exceptions should be descriptive and provide as much information as possible<br />
* Member data should be private with access if required through Get methods.<br />
<br />
== Release Changelogs ==<br />
<br />
[[ITK/Releases|Release Changelogs]]</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=Plugin_IO_mechanisms&diff=59433Plugin IO mechanisms2016-05-08T18:18:55Z<p>Jhlegarreta: Correct a typo.</p>
<hr />
<div>ITK provides a very flexible ImageIO mechanism supporting factories. This allows for a single reader class and a single writer class that can input/output a variety of file formats. When ImageFileReader begins to read a file, it queries the ObjectFactory system for any factory that can supply an ImageIOBase. This subset of factories is queried in turn to locate a factory that can understand the format of the requested file.<br />
<br />
New image file formats can be added to ITK by deriving a class from ImageIOBase that will support reading/writing the new file format. The file format can be added to the factory mechanism by creating a subclass of ObjectFactoryBase for this new ImageIO class. This subclass of ObjectFactoryBase will create an override in the factory mechanism indicating it can create an ImageIOBase. This is done in the constructor of the subclass of ObjectFactoryBase for the new image format:<br />
<br />
MyImageIOFactory::MyImageIOFactory()<br />
{<br />
this->RegisterOverride("itkImageIOBase",<br />
"itkMyImageIO",<br />
"My Image IO",<br />
1,<br />
CreateObjectFunction<MyImageIO>::New()); <br />
}<br />
<br />
== Registering a factory ==<br />
<br />
For the factory mechanism to use the factory for the new image format, the new factory must be "registered" with the factory mechanism. A stock set of such factories are registered automatically by ImageIOFactory. To register additional factories,<br />
<br />
* Add the new format format to the list of formats registered by default in ImageIOFactory::RegisterBuiltInFactories().<br />
** This is should only be done if the new format is to be widely adopted by the entire ITK community.<br />
* Register the factory in your application code that uses that factory<br />
** This is reasonable if you only need to use the file format in your own applications.<br />
<br />
ObjectFactoryBase::RegisterFactory( MyImageIOFactory::New() ); <br />
<br />
* Use the factory plugin mechanism to dynamically register the factory.<br />
** This is useful if you have existing ITK applications that you do not wish to recompile (or can recompile) but you would like them to be able to use your new file format.<br />
<br />
== Plugin mechanism ==<br />
<br />
ITK's object factory mechanism supports dynamically loading factories from shared libraries. This mechanism can be used to dynamically load factories for new image file formats. The object factory will look at the ITK_AUTOLOAD_PATH environment variable to locate dynamically loadable factories (plugins).<br />
<br />
export ITK_AUTOLOAD_PATH=/home/me/myplugins<br />
<br />
If the ITK_AUTOLOAD_PATH is set, each shared library in each directory in that path is examined for a "C" method (not a C++ method)<br />
<br />
ObjectFactorBase* itkLoad()<br />
<br />
If the method itkLoad() is found in the shared library, it is called. itkLoad() must return a pointer to an ObjectFactoryBase. The object factory mechanism then calls ObjectFactoryBase::RegisteryFactory(), passing in the pointer returned by itkLoad(). <br />
<br />
To add a new image file format to an existing application, we can simply wrap the associated ImageIOFactory for the new format inside a shared object that provides the itkLoad() mechanism. Any precompiled ITK application will then be able to read and write this new format.<br />
<br />
=== Caveats ===<br />
<br />
The object factory mechanism will make sure that the dynamically loaded ImageIOFactory was built with the same version of ITK as the application. If they are not a warning will be presented. <br />
<br />
Possible imcompatible factory load.<br />
Running itk version : xx.xx.xx<br />
Loaded Factory versions: yy.yy.yy<br />
Loaded factory: /path/to/factory<br />
<br />
Factories dynamically loaded that were built with a different version of ITK than the application '''may be unstable'''.<br />
<br />
<br />
== Example ==<br />
<br />
To add the MyImageIOFactory as a dynamically loaded factory, we need to create a shared library with an itkLoad() method and place that shared library in the ITK_AUTOLOAD_PATH. Here is an example CMakeLists.txt file for creating the plugin shared library<br />
<br />
SET(MYIO_SRCS itkMyImageIO.cxx itkMyImageIOFactory.cxx)<br />
<nowiki></nowiki><br />
#<br />
# Library for all of my image formats<br />
ADD_LIBRARY (MYIO ${MYIO_SRCS})<br />
TARGET_LINK_LIBRARIES(MYIO ITKIO)<br />
<nowiki></nowiki><br />
#<br />
# Shared library that when placed in ITK_AUTOLOAD_PATH, will add MyImageIO<br />
# as an ImageIOFactory. Need to have separate shared library for each new format.<br />
ADD_LIBRARY(MyPlugin SHARED itkMyPlugin.cxx)<br />
TARGET_LINK_LIBRARIES(MyPlugin MYIO)<br />
<br />
MyPlugin will be the shared library that adds support for the MyImageIO file format. The code associated with MyPlugin is<br />
<br />
itkMyPlugin.h<br />
#ifndef __itkMyPlugin_h<br />
#define __itkMyPlugin_h<br />
<nowiki></nowiki><br />
#include "itkObjectFactoryBase.h"<br />
<nowiki></nowiki><br />
#ifdef WIN32<br />
#ifdef MyPlugin_EXPORTS<br />
#define MyPlugin_EXPORT __declspec(dllexport)<br />
#else<br />
#define MyPlugin_EXPORT __declspec(dllimport)<br />
#endif<br />
#else<br />
#define MyPlugin_EXPORT <br />
#endif<br />
<nowiki></nowiki><br />
/**<br />
* Routine that is called when the shared library is loaded by<br />
* itk::ObjectFactoryBase::LoadDynamicFactories().<br />
*<br />
* itkLoad() is C (not C++) function.<br />
*/<br />
extern "C" {<br />
MyPlugin_EXPORT itk::ObjectFactoryBase* itkLoad();<br />
} <br />
#endif <br />
<br />
itkMyPlugin.cxx<br />
#include "itkMyPlugin.h"<br />
#include "itkMyImageIOFactory.h"<br />
<nowiki></nowiki><br />
/**<br />
* Routine that is called when the shared library is loaded by<br />
* itk::ObjectFactoryBase::LoadDynamicFactories().<br />
*<br />
* itkLoad() is C (not C++) function.<br />
*/<br />
itk::ObjectFactoryBase* itkLoad()<br />
{<br />
static itk::MyImageIOFactory::Pointer f = itk::MyImageIOFactory::New();<br />
return f;<br />
}<br />
<br />
== Discussion ==<br />
<br />
* It appears as though ObjectFactoryBase::LoadDynamicFactories() is called multiple times. Putting a print statement in the above itkLoad() method verifies this for a simple program of a single reader connected to a single writer.<br />
** <strike>There '''needs''' to be a mechanism to cause LoadDynamicFactories() to called multiple times if plugins can be added '''while an application is running.'''</strike><br />
** <strike>However, calling LoadDynamicFactories too often will be a performance issue.</strike><br />
** <strike>If LoadDynamicFactories() can be called multiple times, then the factory list must be managed for duplicates and the itkLoad() method probably needs additional memory management and synchronization.</strike><br />
* Implementing itkLoad() could be made simpler if itkLoad() could return a smart pointer to an ObjectFactoryBase instead of a raw pointer to an ObjectFactoryBase.<br />
<br />
=== Update ===<br />
<br />
'''LoadDynamicFactories is only called multiple times if ITK and the new IO format class are compiled static.''' Much of the following discussion may only be pertinent on Windows. The plugin defined above is always compiled shared. But if ITK and IO format class are compiled static, then they do not share the same ObjectFactory. Consider an ITK executable like the example ImageReadWrite. This example just has an ImageFileReader connected to an ImageFileWriter. When the reader is instantiated, the ObjectFactory triggers a call to LoadDynamicFactories(). This causes any plugins to be loaded. When the ImageFileReader needs to read the file, it asks the ObjectFactory for all factories that can create an ImageIOBase. This causes the plugin to instantiate an ImageIO subclass for the new file format. This instantiation is done in the shared library which has its own ObjectFactory since the new file format was compiled static. This ObjectFactory has yet to be initialized and LoadDynamicFactories() is called a second time. <br />
<br />
To use plugins properly, the ITK application must be using a shared build of ITK, the new IO format must be using a shared build of ITK, and of course the plugin itself must be built shared. Then, a single ObjectFactory will be used in the application and the plugin.<br />
<br />
If the application is built with a static build of ITK and the new IO format is built with a static build of ITK, then LoadDynamicFactories() will be called multiple times: once for the application and once for each plugin that instantiates an object. This may '''not''' actually cause a runtime issue other than causing the dynamic libraries to be loaded multiple times. Each plugin and the application will have their own ObjectFactory but they '''should all be configured identically'''.<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=59336ITK/Coding Style Guide2016-04-16T15:32:06Z<p>Jhlegarreta: /* Doxygen Documentation System */ Added details about documentation in declaration vs. implementation files</p>
<hr />
<div>= C++ Code Style =<br />
<br />
The document located [[media:ITKStyle.pdf|HERE]] describes ITK coding conventions. Developers should follow these conventions when submitting contributions.<br />
<br />
ITK Style Guide<br />
Insight Software Consortium<br />
<br />
== Purpose ==<br />
<br />
The following document is a description of the accepted coding style for the NLM Insight Segmentation<br />
and Registration Toolkit (ITK). Developers who wish to contribute code to ITK should read<br />
and adhere to the standards described here.<br />
<br />
== Document Overview ==<br />
This document is organized into the following sections.<br />
<br />
* System Overview & Philosophy | coding methodologies and motivation for the resulting style.<br />
* Copyright | the copyright header to be included in all files and other copyright issues.<br />
* File organization | how to organize source code; a guide to the ITK directory structure.<br />
* Naming conventions | patterns used to name classes, variables, template parameters, and instance variables.<br />
* Namespaces | the use of namespaces.<br />
* Code Layout and Indentation | accepted standards for arranging code including indentation style.<br />
* Doxygen Documentation System | basic Doxygen formatting instructions.<br />
* Using Standard Macros (itkMacro.h) | use of standard macros in header files.<br />
* Exception Handling | how to add exception handling to the system.<br />
* Documentation Style | a brief section describing the documentation philosophy adopted by the Insight consortium.<br />
<br />
This style guide is an evolving document.<br />
<br />
Please dialog with the ITK developers if you wish to add, modify, or delete the rules described in these guidelines.<br />
<br />
See:<br />
<br />
http://www.itk.org/ITK/help/mailing.html<br />
<br />
for more information about joining the ITK developers mailing list. This forum is one of the best venues in which to propose changes to these style guidelines.<br />
<br />
== Style Guidelines ==<br />
<br />
The following coding-style guidelines have been adopted by the ITK community. To a large extent<br />
these guidelines are a result of the fundamental architectural and implementation decisions made<br />
early in the project. For example, the decision was made to implement ITK with a C++ core using<br />
principles of generic programming, so the rules are oriented towards this style of implementation.<br />
Some guidelines are relatively arbitrary, such as indentation levels and style. However, an attempt<br />
was made to find coding styles consistent with accepted practices. The point is to adhere to a<br />
common style to assist developers and users of the future learn, use, maintain, and extend ITK.<br />
(See the ITK Requirements document for more information.)<br />
Please do your best to be a upstanding member of the ITK community. The rules described here<br />
have been developed with the community as a whole in mind. If you consistently violate these rules<br />
you will likely be harassed mercilessly, first privately and then publicly. If this does not result in<br />
correct code layout, your right to CVS write access (if you are developer and wish to contribute<br />
code) may be removed. Similarly, if you wish to contribute code and are not a developer, your code<br />
will not be accepted until the style is consistent with these guidelines.<br />
<br />
=== System Overview & Philosophy ===<br />
The following implementation strategies have been adopted by the ITK community. These directly<br />
and indirectly affect the resulting code style. Understanding these strategies motivate the reasons<br />
for many of the style guidelines described in this document.<br />
<br />
==== Implementation Language ====<br />
<br />
The core implementation language is C++. C++ was chosen for its flexibility, performance, and<br />
familiarity to consortium members. (Auxiliary, interpreted language bindings such as Tcl, Python,<br />
and/or Java are also planned. These are aimply (run-time interpreted) layers on the C++ code.)<br />
ITK uses the full spectrum of C++ features including const and volatile correctness, namespaces,<br />
partial template specialization, operator overloading, traits, and iterators.<br />
<br />
==== Generic Programming and the STL ====<br />
<br />
Compile-time binding using methods of generic programming and template instantiation is the<br />
preferred implementation style. This approach has demonstrated its ability to create efficient,<br />
flexible code. Use of the STL (Standard Template Library) is encouraged. STL is typically used by<br />
a class, rather than as serving as a base class for derivation of ITK classes. Other STL influences<br />
are iterators and traits. ITK defines a large set of iterators; however, the ITK iterator style differs<br />
in many cases from STL because STL iterators follow a linear traversal model; ITK iterators are<br />
often designed for 2D, 3D, and even n-D traversal. Traits are used heavily be ITK. ITK naming<br />
conventions supersede STL naming conventions; this difference is useful in that it indicates to the<br />
developer something of the boundary between ITK and STL.<br />
<br />
==== Portability ====<br />
ITK is designed to compile on a set of target operating system/compiler combinations.<br />
<br />
These combinations include, but are not limited to:<br />
<br />
* Windows 9x/NT/2000/XP running<br />
** Microsoft Visual C++ version 7.1 to 10<br />
* Solaris with SunPro compiler <br />
* Linux running gcc<br />
* MacOSX running gcc<br />
* Intel compiler on Windows and Linux<br />
<br />
For a full list of the compilers supported please see:<br />
<br />
* [[ITK_Release_4/Modern C++|Modern C++]]<br />
<br />
==== Multi-Layer Architecture ====<br />
ITK is designed with a multi-layer architecture in mind. That is, three layers, a templated layer, a<br />
run-time layer, and an application layer. The templated (or generic) layer is written in C++ and<br />
requires significant programming skills and domain knowledge. The run-time layer is generated<br />
automatically using the CableSwig wrapping system to produce language bindings to Tcl, Python,<br />
and Java. The interpreted layer is easier to use than the templated layer, and can be used for<br />
prototyping and smaller-sized application development. Finally, the application layer is not directly<br />
addressed by ITK other than providing simple examples of applications.<br />
<br />
==== CMake Build Environment ====<br />
The ITK build environment is CMake. CMake is an open-source, advanced cross-platform build<br />
system that enables developers to write simple \makefiles" (named CMakeLists.txt) that are processed<br />
to generated native build tools for a particular operating system/compiler combinations.<br />
See the CMake web pages at http://www.cmake.org for more information.<br />
<br />
==== Doxygen Documentation System ====<br />
<br />
The Doxygen open-source system is used to generate on-line documentation. Doxygen requires the<br />
embedding of simple comments in the code which is in turn extracted and formatted into documentation.<br />
<br />
For more information about Doxygen, please see<br />
<br />
http://www.stack.nl/dimitri/doxygen/<br />
<br />
==== vnl Math Library ====<br />
ITK has adopted the vnl math library. Vnl is a portion of the vxl image understanding environment.<br />
See http://www.robots.ox.ac.uk/ vxl/ for more information about vxl and vnl.<br />
<br />
==== Reference Counting ====<br />
<br />
ITK has adopted reference counting via so-called "smart pointers" to manage object references.<br />
While alternative approaches such as automatic garbage collection were considered, their overhead<br />
due to memory requirements, performance, and lack of control as to when to delete memory, precluded<br />
these methods. Smart pointers manage the reference to objects, automatically incrementing<br />
and deleting an instance's reference count, deleting the object when the count goes to zero.<br />
These are the most important factors influencing the coding style found in Insight. Now we will<br />
look at the details.<br />
<br />
=== Copyright ===<br />
<br />
ITK has adopted a standard copyright. This copyright should be placed at the head of every source<br />
code file. The current copyright header and license reads as follows:<br />
<br />
<pre><nowiki><br />
/*========================================================================= <br />
* <br />
* Copyright Insight Software Consortium <br />
* <br />
* Licensed under the Apache License, Version 2.0 (the "License"); <br />
* you may not use this file except in compliance with the License. <br />
* You may obtain a copy of the License at <br />
* <br />
* http://www.apache.org/licenses/LICENSE-2.0.txt <br />
* <br />
* Unless required by applicable law or agreed to in writing, software <br />
* distributed under the License is distributed on an "AS IS" BASIS, <br />
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. <br />
* See the License for the specific language governing permissions and <br />
* limitations under the License. <br />
* <br />
*=========================================================================*/<br />
</nowiki></pre><br />
<br />
[[ITK Copyright Header|Copyright Header]]<br />
<br />
=== File Organization ===<br />
<br />
Classes are created and (usually) organized into a single class per file set. A file set consists of .h<br />
header file, .cxx implementation file, and/or a .hxx templated implementation file. Helper classes<br />
may also be defined in the file set, typically these are not visible to the system at large, or placed<br />
into a special namespace.<br />
<br />
Source files must be placed in the correct directory for logical consistency with the rest of the<br />
system, and to avoid cyclic dependencies. Currently the ITK source directory structure is found in<br />
ITK/Modules and consists of the following subdirectories:<br />
<br />
* Bridge<br />
* Core<br />
* External<br />
* Filtering<br />
* GPU<br />
* IO<br />
* Nonunit<br />
* Numerics<br />
* Registration<br />
* Segmentation<br />
* ThirdParty<br />
<br />
Each one of these directories represent a Group of Modules.<br />
<br />
Please discuss with the ITK Developers about the best Module to place your new code.<br />
<br />
For a full list of Modules, please see:<br />
<br />
http://www.itk.org/Doxygen/html/modules.html<br />
<br />
=== Naming Conventions ===<br />
<br />
In general, <br />
<br />
* Names are constructed by using case change to indicate separate words, as in TimeStamp<br />
(versus Time Stamp).<br />
* Underscores are not used.<br />
* Variable names are chosen carefully with the intention to convey the meaning behind the code.<br />
* Names are generally spelled out; use of abbreviations is discouraged. (Abbreviation are allowable when in common use, and should be in<br />
uppercase as in RGB.) While this does result in long names, it self-documents the code.<br />
* If you learn how to use name completion in your editor (e.g.,Vim, Emacs), this inconvenience can be minimized.<br />
<br />
Depending on whether the name is a<br />
<br />
* class<br />
* file<br />
* variable<br />
* or other name<br />
<br />
variations on this theme result as explained in the following subsections.<br />
<br />
==== Naming Classes ====<br />
<br />
* Classes are named beginning with a capital letter.<br />
* Classes are placed in the appropriate namespace, typically itk:: (see namespaces below).<br />
* Classes are named according to the following general rule:<br />
class name = <algorithm><input><concept><br />
* In this formula, the name of the algorithm or process (possibly with an associated adjective or<br />
adverb) comes first, followed by an input type (if the class is a filter), and completed by a concept<br />
name.<br />
* A concept is an informal classification describing what a class does. There are many<br />
concepts, here are a few of them.<br />
<br />
The more common or important concepts are underlined.<br />
<br />
* '''Accessor''' Access and convert between types.<br />
* '''Adaptor''' Provide access to a portion of a complex pixel type.<br />
* '''Boundary''' The boundary of a cell.<br />
* '''Calculator''' Compute information.<br />
* '''Classifier''' Classify a pixel.<br />
* '''Container''' A container of objects such as points or cells.<br />
* '''Estimator''' Estimate a value or condition.<br />
* '''Factory''' Object factories are used to create instances.<br />
* '''Filter''' A class that participates in the data processing pipeline. Filters typically take one or more inputs and produce one or more outputs.<br />
* '''Function''' Evaluate a function at a given position.<br />
* '''Identifier''' A unique id for accessing points, cells, or other entities.<br />
* '''Interface''' Classes that specify an abstract interface.<br />
* '''Interpolator''' Interpolate data values, for example at non-pixel values.<br />
* '''Iterator''' Traverse data in various ways (e.g., forward, backward, within a region, etc.)<br />
* '''Mapper''' Transform data from one form into another.<br />
* '''Metric''' Compute similarity between two objects.<br />
* '''Operator''' A class that applies a user-specified function to a region.<br />
* '''Optimizer''' A class that performs numerical optimization.<br />
* '''Pointer''' A smart pointer to an instance of a class. Almost all instance in ITK are referred to via smart pointers.<br />
* '''Reader''' A class that reads a single data object (e.g., image or mesh).<br />
* '''Reference''' A type that refers to another object.<br />
* '''Region''' A subset of a data object, such as an image region.<br />
* '''Source''' A filter that initiates the data processing pipeline such as a reader or a procedural data generator.<br />
* '''Threader''' A class that manages multi-threading.<br />
* '''Traits''' A collection of template parameters used to control the instantiation of other classes.<br />
* '''Transform''' Various types of transformations including affine, procedural, and so on.<br />
* '''Writer''' A filter that terminates the data processing pipeline by writing data to disk or to a communicationsport.<br />
<br />
<br />
The naming of classes is an art form; please review existing names to catch the spirit of the naming<br />
convention.<br />
<br />
Example names include:<br />
<br />
* ShrinkImageFilter<br />
* TriangleCell<br />
* ScalarImageRegionIterator<br />
* NeighborhoodIterator<br />
* MapContainer<br />
* DefaultImageTraits<br />
* BackwardDifferenceOperator<br />
<br />
==== Naming Files ====<br />
<br />
* Files should have the same name as the class, with an "itk" prepended.<br />
* Header files are named .h, while implementation files are named either .cxx or .hxx, depending on whether they are implementations of templated classes.<br />
** For example, the class itk::Image <br />
*** is declared in the file itkImage.h and<br />
*** is defined in the file itkImage.hxx (because Image is templated).<br />
** The class itk::Object<br />
*** is declared in the file itkObject.h<br />
*** and is defined in the file itkObject.cxx<br />
<br />
==== Naming Methods and Functions ====<br />
Global functions and class methods, either static or class members, are named beginning with<br />
a capital letter. The biggest challenge when naming methods and functions is to be consistent<br />
with existing names. For example, given the choice between ComputeBoundingBox() and<br />
CalculateBoundingBox() (CalcBoundingBox() is not allowed because it is not spelled out), the<br />
choice is ComputeBoundingBox() because \Compute" is used elsewhere in the system in similar<br />
settings (The concepts described previously should be used whenever possible).<br />
When referring to class methods in code, an explicit this-> pointer should be used, as in this->ComputeBoundingBox().<br />
The use of the explicit this-> pointer helps clarify exactly which method, and where it originates,<br />
is being invoked. Similarly the \::" global namespace should be used when referring to a global<br />
function.<br />
<br />
==== Naming Class Data Members ====<br />
<br />
Class data members are prepended with m as in m_Size. This clearly indicates the origin of data<br />
members, and differentiates them from all other variables.<br />
<br />
==== Naming Local Variables ====<br />
Local variables begin in lowercase. There is more <br />
flexibility in the naming of local variables; please<br />
remember that others will study, maintain, fix, and extend your code. Any bread crumbs that<br />
you can drop in the way of explanatory variable names and comments will go a long way towards<br />
helping other developers.<br />
<br />
==== Naming Template Parameters ====<br />
Template parameters follow the usual rules with naming except that they should start with either<br />
the capital letter T or V. Type parameters begin with the letter T while value template parameters<br />
begin with the letter V.<br />
<br />
* For tempalate parameters the use of "typename" is preferred over "class". Very early c++ compilers did not have a "typename" keyword, and "class" was repurposed for declaring template parameters. It was later discovered that this lead to ambiguity in some valid code constructs, and the "typename" key word was added. It is often agreed (http://blogs.msdn.com/b/slippman/archive/2004/08/11/212768.aspx) that "typename" is marginally more expressive in it's intent and ITK should consistently use "typename" instead of "class".<br />
<br />
==== Naming Typedefs ====<br />
Typedefs are absolutely essential in generic programming. They significantly improve the readibility<br />
of code, and facilitate the declaration of complex syntactic combinations. Unfortunately, creation<br />
of typedefs is tantamount to creating another programming language. Hence typedefs must be used<br />
in a consistent fashion.<br />
The general rule for typedef names is that they end in the word Type. For example<br />
typedef TPixel PixelType;<br />
However, there are many exceptions to this rule that recognize that ITK has several important<br />
concepts that are expressed partially in the names used to implement the concept. An iterator is a<br />
concept, as is a container or pointer. These concepts are used in preference to Type at the end of<br />
a typedef as appropriate. For example<br />
ITK Style Guide 9<br />
typedef typename ImageTraits::PixelContainer PixelContainer;<br />
Here Container is a concept used in place of Type.<br />
ITK currently identifies the following concepts used when naming typedefs.<br />
* Self as in typedef Image Self;. All classes should define this typedef.<br />
* Superclass as in typedef ImageBase<VImageDimension> Superclass;. All classes should define the Superclass typedef.<br />
* Pointer as in a smart pointer to an object as in typedef SmartPointer<Self> Pointer;<br />
* Container is a type of container class.<br />
* Iterator an iterator over some container class.<br />
* Identifier or id such as a point or cell id.<br />
<br />
==== Using Underscores ====<br />
Don't use them. The only exception is when defining preprocessor variables and macros (which are<br />
discouraged). In this case, underscores are allowed to separate words.<br />
<br />
==== Preprocessor Directives ====<br />
<br />
* Some of the worst code contains many preprocessor directives and macros. Do not use them except in a very limited sense (to support minor differences in compilers or operating systems). <br />
* If a class makes extensive use of preprocessor directives, it is a candidate for separation into multiple sub-classes.<br />
<br />
==== Header Includes ====<br />
<br />
Header includes use the style<br />
<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
</source><br />
<br />
Only the required headers should be included. If an included header already includes a header for a class also used in the current file, the header for that class should not be included.<br />
<br />
Header includes are preferred over forward declarations. Forward declarations are only used to prevent circular dependencies.<br />
<br />
==== Namespaces ====<br />
<br />
All classes should be placed in the itk:: namespace. Additional sub-namespaces are being designed to support special functionality.<br />
<br />
Please see current documentation to determine if there is a subnamespace is relevant to your situation. Normally sub-namespaces are used for helper ITK classes.<br />
<br />
Code should not use ''using namespace''. This is to avoid namespace conflicts, but, more importantly, to improve readability.<br />
<br />
When declaring or defining members of the "itk" namespace, for example, the 'itk::' namespace prefix should not be added. That is, code within "namespace itk { ... }" should not used "itk::".<br />
<br />
==== Const Correctness ====<br />
<br />
Const correctness is important. Please use it as appropriate to your class or method.<br />
<br />
==== Code Layout and Indentation ====<br />
<br />
The following are the accepted ITK code layout rules and indentation style. After reading this section, you may wish to visit many of the source files found in ITK. This will help crystallize the rules described here.<br />
<br />
==== General Layout ====<br />
<br />
* Each line of code should take no more than 200 characters.<br />
* Break the code across multiple lines as necessary.<br />
* Use lots of whitespace to separate logical blocks of code, intermixed with comments.<br />
* To a large extent the structure of code directly expresses its implementation.<br />
* The appropriate indentation level is '''two spaces''' for each level of indentation.<br />
* '''DO NOT USE TABS.'''<br />
** Set up your editor to insert spaces. Using tabs may look good in your editor but will wreak havoc in others.<br />
* The declaration of variables within classes, methods, and functions should be one declaration per line.<br />
<br />
<source lang="cpp"><br />
int i;<br />
int j;<br />
char* stringname;<br />
</source><br />
<br />
==== Class Layout ====<br />
<br />
Classes are defined using the following guidelines.<br />
* Begin with #include guards.<br />
* Follow with the necessary includes. Include only what is necessary to avoid dependency problems.<br />
* Place the class in the correct namespace.<br />
* Public methods come first.<br />
* Protected methods follow.<br />
* Private members come last.<br />
* Public data members are ''forbidden''.<br />
* Templated classes require a special preprocessor directive to control the manual instantiation of templates. See the example below and look for ITK MANUAL INSTANTIATION.<br />
The class layout looks something like this:<br />
<br />
<source lang="cpp"><br />
#ifndef itkImage_h<br />
#define itkImage_h<br />
<br />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
<br />
namespace itk<br />
{<br />
<br />
/** \class Image<br />
* \brief Templated n-dimensional image class.<br />
*<br />
* .... detailed documentation....<br />
*/<br />
template< typename TPixel, unsigned int VImageDimension=2,<br />
typename TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class Image: public ImageBase< VImageDimension ><br />
{<br />
public:<br />
//....stuff...<br />
protected:<br />
//....stuff...<br />
private:<br />
//....stuff...<br />
};<br />
<br />
} // end namespace itk<br />
<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
<br />
#endif<br />
</source><br />
<br />
==== Method Definition ====<br />
<br />
* Methods are defined across multiple lines. This is to accommodate the extremely long definitions possible when using templates.<br />
* The starting and ending brace should be in column one. For example:<br />
<br />
<source lang="cpp"><br />
template<typename TPixel, unsigned int VImageDimension, typename TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
//...stuff...<br />
}<br />
</source><br />
<br />
* The first line is the template declaration.<br />
* The second line is the method return type.<br />
* The third line is the class qualifier.<br />
* And the fourth line in the example above is the name of the method.<br />
<br />
=== Use of Braces ===<br />
<br />
* Braces must be used to delimit the scope of an if, for, while, switch, or other control structure.<br />
* Braces are placed on a line by themselves:<br />
<br />
<source lang="cpp"><br />
for( unsigned int ii = 0; ii < 3; ++ii )<br />
{<br />
...<br />
}<br />
</source><br />
<br />
<br />
or when using an if:<br />
<br />
<source lang="cpp"><br />
if( condition )<br />
{<br />
...<br />
}<br />
else if( other condition )<br />
{<br />
...<br />
}<br />
else<br />
{<br />
....<br />
}<br />
</source><br />
<br />
<br />
==== Indentation Inside Braces ====<br />
<br />
<br />
Source code in the body of the brackets must be aligned along with the brackets. As in<br />
<br />
<source lang="cpp"><br />
if ( condition )<br />
{<br />
unsigned int numberOfIterations = 100;<br />
filter->SetNumberOfIterations( numberOfIterations );<br />
filter->Update();<br />
filter->Print( std::cout );<br />
}<br />
</source><br />
<br />
=== Doxygen Documentation System ===<br />
<br />
* Doxygen is an open-source, powerful system for automatically generating documentation from source code.<br />
* To use Doxygen effectively, the developer must insert comments, delimited in a special way, that Doxygen extracts to produce the documentation. While there are a large number of options to Doxygen, developers at a minimum should insert the following Doxygen commands.<br />
<br />
See more at<br />
<br />
http://www.stack.nl/dimitri/doxygen/index.html<br />
<br />
==== Documenting a Class ====<br />
<br />
* Classes should be documented using the '''class''' and '''brief''' Doxygen commands, followed by the detailed class description:<br />
<br />
<source lang="cpp"><br />
/** \class Object<br />
* \brief Base class for most itk classes.<br />
*<br />
* Object is the second-highest level base class for most itk objects.<br />
* It extends the base object functionality of LightObject by<br />
* implementing debug flags/methods and modification time tracking.<br />
*/<br />
</source><br />
<br />
==== Documenting a Method ====<br />
<br />
* Methods should be documented using the following comment block style as shown in the following example. Make sure you use correct English and complete, grammatically correct sentences. Finish your sentences with a period (.).<br />
<br />
<source lang="cpp"><br />
/** Access a pixel at a particular index location.<br />
* This version can be an lvalue. */<br />
TPixel & operator[](const IndexType &index)<br />
{ return this->GetPixel(index); }<br />
</source><br />
<br />
The key here is that the comment starts with /**, each subsequent line has an aligned *, and the comment block terminates with a */.<br />
<br />
* Method documentation should be placed in the '''declaration files''' (*.h): the documentation in the implementation causes ambiguity for Doxygen on which documentation to use, the declaration or definition.<br />
** If there is something that is appropriate for the definition only (*.cxx or *.hxx), it should be placed '''inside the method''', and it could use either the /* */ or the // style comment, but it should not use /** */, which is for Doxygen comments.<br />
<br />
==== Documenting ivars ====<br />
<br />
* Class member variables should be documented using the following comment block style as shown in the following example. Make sure you use correct English and grammatically correct sentences. Finish the documentation line with a period (.).<br />
<br />
<source lang="cpp"><br />
// Standard deviation of the gaussian used for smoothing.<br />
SigmaArrayType m_Sigma;<br />
</source><br />
<br />
=== Using Standard Macros (itkMacro.h) ===<br />
<br />
* There are several macros defined in the file itkMacro.h.<br />
* These macros should be used because they perform several important operations, that if not done correctly can cause serious, hard to debug problems in the system.<br />
** These operations are:<br />
*** Object modified time is properly managed.<br />
*** Debug information is printed.<br />
*** Reference counting is handled properly.<br />
<br />
Some of the more important object macros are as follows.<br />
<br />
* itkNewMacro(T) Creates the static class method New(void) that interacts with the object factory to instantiate objects. The method returns a SmartPointer<T> properly reference counted.<br />
* itkDebugMacro(x) If debug is set on a subclass of itk::Object, prints debug information to the appropriate output stream.<br />
* itkSetMacro(name,type) Creates a method SetName() that takes argument type type.<br />
* itkGetMacro(name,type) Creates a method GetName() that returns a non-const value of type type.<br />
* itkGetConstMacro(name,type) Creates a method GetName() that returns a const value of type type.<br />
* itkSetStringMacro(name) Creates a method SetName() that takes argument type const char*.<br />
* itkGetStringMacro(name) Creates a method GetName() that returns argument type const char*.<br />
* itkBooleanMacro(name) Creates two methods named NameOn and NameOff that sets true/false boolean values.<br />
* itkSetObjectMacro(name,type) Creates a method SetName() that takes argument type type *.<br />
* itkGetObjectMacro(name,type) Creates a method named GetName() that returns a smart pointer to a type type.<br />
* itkSetConstObjectMacro(name,type) Creates a method SetName() that takes argument type const type *.<br />
* itkGetConstObjectMacro(name,type) Creates a method named GetName() that returns a const smart pointer to a type type.<br />
<br />
Please review this file and become familiar with these macros.<br />
<br />
=== Exception Handling ===<br />
<br />
Indicate that methods throw exceptions in the method declaration as in:<br />
<br />
<source lang="cpp"><br />
const float* foo() const throws itk<br />
</source><br />
<br />
=== Documentation Style ===<br />
<br />
The Insight consortium has adopted the following guidelines for producing supplemental documentation (documentation not produced by Doxygen).<br />
<br />
* The common denominator for documentation is either PDF or HTML. All documents in the system should be available in these formats, even if they are mastered by another system.<br />
* Presentations are acceptable in Microsoft PowerPoint format.<br />
* Administrative and planning documents are acceptable in Microsoft Word format (either .doc or .rtf).<br />
* Larger documents, such as the user's or developer's guide, are written in LATEX.<br />
<br />
== CMake Style ==<br />
<br />
A proposal style guide for CMake variables is presented [[ITK_CMake_Style|HERE]].<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_4/Modularization/_Add_tests&diff=59335ITK/Release 4/Modularization/ Add tests2016-04-16T15:01:50Z<p>Jhlegarreta: Added section "Writing tests"</p>
<hr />
<div>The safe assumption behind testing is that "if it is not tested, it is broken".<br />
<br />
== Non-regression tests ==<br />
<br />
The same way it used to be, except the newer syntax in "add_test" command:<br />
<br />
{{#tag:syntaxhighlight<br />
|<br />
<br />
add_executable(itkBinaryThresholdFilterTest itkBinaryThresholdFilterTest.cxx)<br />
<br />
target_link_libraries(itkBinaryThresholdFilterTest ${ITK-BinaryThreshold_LIBRARIES})<br />
<br />
# adopt the modern CMake syntax :[NAME, COMMAND]<br />
<br />
itk_add_test(NAME itkBinaryThresholdFilterTest <br />
COMMAND itkBinaryThresholdFilterTest input.png output.png)<br />
|lang=cmake}}<br />
<br />
<br />
<br />
== Regression tests ==<br />
<br />
=== Approach A ===<br />
<br />
Using the test driver macro<br />
The CMake macro "CreateTestDriver" defined in <br />
<br />
Module/Core/TestKernal/CreateTestDriver.cmake<br />
<br />
is designed for grouped regression tests in ITK. <br />
<br />
All the tests in one module share one test driver.<br />
<br />
{{#tag:syntaxhighlight<br />
|<br />
<br />
set(ITKFooFilterTests<br />
itkFooFilterTest1.cxx<br />
itkFooFilterTest2.cxx)<br />
<br />
CreateTestDriver(ITKFooFilter "${ITK_FooFilter-Test_LIBRARIES}" "${ITK-FooFilterTest}")<br />
<br />
itk_add_test(NAME itkFooFilterTest1<br />
COMMAND ITKFooFilterTestDriver itkFooFilterTest1)<br />
<br />
itk_add_test(NAME itkFooFilterTest2<br />
COMMAND ITKFooFilterTestDriver itkFooFilterTest2)<br />
<br />
<br />
|lang=cmake}}<br />
<br />
<br />
You can find Approach A used in most of the ITK modules.<br />
for example in<br />
<br />
ITK/Modules/IO/BMP/test/CMakeLists.txt<br />
<br />
=== Approach B ===<br />
<br />
Stand-alone regression tests<br />
<br />
There is also a test driver executable("itkTestdriver") designed for stand-alone regression tests. For instance, all the tests in Examples are stand-alone programs each has its own main function call, in which case, the approach A is not appropriate.<br />
<br />
<br />
{{#tag:syntaxhighlight<br />
|<br />
add_exectuable(itkFooTest itkFooTest.cxx)<br />
<br />
target_line_libraries( itkFooTest ${ITK_LIBRARIES})<br />
<br />
itk_add_test(NAME itkFooTest<br />
COMMAND itkTestDriver<br />
--compare outputBaseline.png output.png<br />
'''$<TARGET_FILE:'''itkFooFilterTest'''>''' input.png output.png)<br />
|lang=cmake}}<br />
<br />
<br />
The new syntax<br />
<br />
$<TARGET_FILE: xxx> <br />
<br />
in the add_test command triggers CMake to locate the executable automatically. No need to specify the path for the executable here.<br />
<br />
You can find Approach B used in Examples.<br />
<br />
For example in<br />
<br />
ITK/Examples/Filtering/test/CMakeLists.txt<br />
<br />
<br />
== Add testing data to ITK ==<br />
Please refer to: [http://www.itk.org/Wiki/index.php?title=ITK/Git/Develop/Data&oldid=41775 | Add Data]<br />
<br />
== Writing tests ==<br />
<br />
=== Unit tests ===<br />
Writing a unit test helps ensuring that the class being exercised<br />
* works as expected,<br />
* works invariably along time,<br />
* works invariably across different platforms.<br />
It also helps in detecting potential issues, and checking how a given class is affected by changes introduced in the code.<br />
<br />
A direct consequence of writing and executing a test is that the [http://www.vtk.org/Wiki/Special:WhatLinksHere/ITK/Code_Coverage_Practices code coverage] is improved.<br />
When writing a unit test you should consider the following principles:<br />
* Make sure that all methods of the class being tested are exercised.<br />
* Make sure that if the class is templated, a number of different instances with different arguments are created so that the class is thoroughly tested.<br />
* Make sure your test returns an EXIT_SUCCESS value when succeeding and an EXIT_FAILURE value when failing.<br />
** When a test checks multiple features that individually may return either an EXIT_SUCCESS or an EXIT_FAILURE code, make sure that the whole test is run, and return the code in the end. This will help in locating more issues in the same run.<br />
<br />
<source lang="cpp"><br />
// appropriate include files<br />
<br />
int main( int, char *[] )<br />
{<br />
int testPassStatus = EXIT_SUCCESS;<br />
<br />
//<br />
// ...<br />
//<br />
<br />
if( itk::Math::FloatDifferenceULP( floatRepresentationfx1.asFloat, floatRepresentationfx2.asFloat ) != -1 )<br />
{<br />
std::cout << "Unexpected float distance." << std::endl;<br />
testPassStatus = EXIT_FAILURE;<br />
}<br />
if( itk::Math::FloatAlmostEqual( floatRepresentationfx1.asFloat, floatRepresentationfx2.asFloat ) )<br />
{<br />
std::cout << "floatRepresentationfx1 is almost equal to floatRepresentationfx2\n" << std::endl;<br />
}<br />
else<br />
{<br />
std::cout << "floatRepresentationfx1 is NOT almost equal to floatRepresentationfx2\n" << std::endl;<br />
testPassStatus = EXIT_FAILURE;<br />
}<br />
<br />
return testPassStatus;<br />
}<br />
</source><br />
<br />
instead of <br />
<br />
<source lang="cpp"><br />
// appropriate include files<br />
<br />
int main( int, char *[] )<br />
{<br />
int testPassStatus = EXIT_SUCCESS;<br />
<br />
//<br />
// ...<br />
//<br />
<br />
if( itk::Math::FloatDifferenceULP( floatRepresentationfx1.asFloat, floatRepresentationfx2.asFloat ) != -1 )<br />
{<br />
std::cout << "Unexpected float distance." << std::endl;<br />
return EXIT_FAILURE;<br />
}<br />
if( itk::Math::FloatAlmostEqual( floatRepresentationfx1.asFloat, floatRepresentationfx2.asFloat ) )<br />
{<br />
std::cout << "floatRepresentationfx1 is almost equal to floatRepresentationfx2\n" << std::endl;<br />
}<br />
else<br />
{<br />
std::cout << "floatRepresentationfx1 is NOT almost equal to floatRepresentationfx2\n" << std::endl;<br />
return EXIT_FAILURE;<br />
}<br />
<br />
return testPassStatus;<br />
}<br />
</source><br />
<br />
* When an exception can be thrown by a class, write a condition (in a try/catch block) in the test that is able to reproduce the exception condition.<br />
* When appropriate, exercise a given method a number of times (with different arguments) so that the method is thoroughly tested.<br />
* When required, print messages to the standard output (or error output) so that any errors happened can be checked by a human reader.<br />
* Whenever possible, test against a baseline (ground truth): if an object is not tested against a baseline, we will not know whether it is working as expected, even if its code coverage is 100%.<br />
* Use the testing macros defined in itkTestingMacros.h. Particularly, make sure that the macro EXERCISE_BASIC_OBJECT_METHODS is called right after the creation of the object whose class is being tested.</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=59334ITK/Coding Style Guide2016-04-16T14:13:17Z<p>Jhlegarreta: /* Doxygen Documentation System */ Added section " Documenting ivars "</p>
<hr />
<div>= C++ Code Style =<br />
<br />
The document located [[media:ITKStyle.pdf|HERE]] describes ITK coding conventions. Developers should follow these conventions when submitting contributions.<br />
<br />
ITK Style Guide<br />
Insight Software Consortium<br />
<br />
== Purpose ==<br />
<br />
The following document is a description of the accepted coding style for the NLM Insight Segmentation<br />
and Registration Toolkit (ITK). Developers who wish to contribute code to ITK should read<br />
and adhere to the standards described here.<br />
<br />
== Document Overview ==<br />
This document is organized into the following sections.<br />
<br />
* System Overview & Philosophy | coding methodologies and motivation for the resulting style.<br />
* Copyright | the copyright header to be included in all files and other copyright issues.<br />
* File organization | how to organize source code; a guide to the ITK directory structure.<br />
* Naming conventions | patterns used to name classes, variables, template parameters, and instance variables.<br />
* Namespaces | the use of namespaces.<br />
* Code Layout and Indentation | accepted standards for arranging code including indentation style.<br />
* Doxygen Documentation System | basic Doxygen formatting instructions.<br />
* Using Standard Macros (itkMacro.h) | use of standard macros in header files.<br />
* Exception Handling | how to add exception handling to the system.<br />
* Documentation Style | a brief section describing the documentation philosophy adopted by the Insight consortium.<br />
<br />
This style guide is an evolving document.<br />
<br />
Please dialog with the ITK developers if you wish to add, modify, or delete the rules described in these guidelines.<br />
<br />
See:<br />
<br />
http://www.itk.org/ITK/help/mailing.html<br />
<br />
for more information about joining the ITK developers mailing list. This forum is one of the best venues in which to propose changes to these style guidelines.<br />
<br />
== Style Guidelines ==<br />
<br />
The following coding-style guidelines have been adopted by the ITK community. To a large extent<br />
these guidelines are a result of the fundamental architectural and implementation decisions made<br />
early in the project. For example, the decision was made to implement ITK with a C++ core using<br />
principles of generic programming, so the rules are oriented towards this style of implementation.<br />
Some guidelines are relatively arbitrary, such as indentation levels and style. However, an attempt<br />
was made to find coding styles consistent with accepted practices. The point is to adhere to a<br />
common style to assist developers and users of the future learn, use, maintain, and extend ITK.<br />
(See the ITK Requirements document for more information.)<br />
Please do your best to be a upstanding member of the ITK community. The rules described here<br />
have been developed with the community as a whole in mind. If you consistently violate these rules<br />
you will likely be harassed mercilessly, first privately and then publicly. If this does not result in<br />
correct code layout, your right to CVS write access (if you are developer and wish to contribute<br />
code) may be removed. Similarly, if you wish to contribute code and are not a developer, your code<br />
will not be accepted until the style is consistent with these guidelines.<br />
<br />
=== System Overview & Philosophy ===<br />
The following implementation strategies have been adopted by the ITK community. These directly<br />
and indirectly affect the resulting code style. Understanding these strategies motivate the reasons<br />
for many of the style guidelines described in this document.<br />
<br />
==== Implementation Language ====<br />
<br />
The core implementation language is C++. C++ was chosen for its flexibility, performance, and<br />
familiarity to consortium members. (Auxiliary, interpreted language bindings such as Tcl, Python,<br />
and/or Java are also planned. These are aimply (run-time interpreted) layers on the C++ code.)<br />
ITK uses the full spectrum of C++ features including const and volatile correctness, namespaces,<br />
partial template specialization, operator overloading, traits, and iterators.<br />
<br />
==== Generic Programming and the STL ====<br />
<br />
Compile-time binding using methods of generic programming and template instantiation is the<br />
preferred implementation style. This approach has demonstrated its ability to create efficient,<br />
flexible code. Use of the STL (Standard Template Library) is encouraged. STL is typically used by<br />
a class, rather than as serving as a base class for derivation of ITK classes. Other STL influences<br />
are iterators and traits. ITK defines a large set of iterators; however, the ITK iterator style differs<br />
in many cases from STL because STL iterators follow a linear traversal model; ITK iterators are<br />
often designed for 2D, 3D, and even n-D traversal. Traits are used heavily be ITK. ITK naming<br />
conventions supersede STL naming conventions; this difference is useful in that it indicates to the<br />
developer something of the boundary between ITK and STL.<br />
<br />
==== Portability ====<br />
ITK is designed to compile on a set of target operating system/compiler combinations.<br />
<br />
These combinations include, but are not limited to:<br />
<br />
* Windows 9x/NT/2000/XP running<br />
** Microsoft Visual C++ version 7.1 to 10<br />
* Solaris with SunPro compiler <br />
* Linux running gcc<br />
* MacOSX running gcc<br />
* Intel compiler on Windows and Linux<br />
<br />
For a full list of the compilers supported please see:<br />
<br />
* [[ITK_Release_4/Modern C++|Modern C++]]<br />
<br />
==== Multi-Layer Architecture ====<br />
ITK is designed with a multi-layer architecture in mind. That is, three layers, a templated layer, a<br />
run-time layer, and an application layer. The templated (or generic) layer is written in C++ and<br />
requires significant programming skills and domain knowledge. The run-time layer is generated<br />
automatically using the CableSwig wrapping system to produce language bindings to Tcl, Python,<br />
and Java. The interpreted layer is easier to use than the templated layer, and can be used for<br />
prototyping and smaller-sized application development. Finally, the application layer is not directly<br />
addressed by ITK other than providing simple examples of applications.<br />
<br />
==== CMake Build Environment ====<br />
The ITK build environment is CMake. CMake is an open-source, advanced cross-platform build<br />
system that enables developers to write simple \makefiles" (named CMakeLists.txt) that are processed<br />
to generated native build tools for a particular operating system/compiler combinations.<br />
See the CMake web pages at http://www.cmake.org for more information.<br />
<br />
==== Doxygen Documentation System ====<br />
<br />
The Doxygen open-source system is used to generate on-line documentation. Doxygen requires the<br />
embedding of simple comments in the code which is in turn extracted and formatted into documentation.<br />
<br />
For more information about Doxygen, please see<br />
<br />
http://www.stack.nl/dimitri/doxygen/<br />
<br />
==== vnl Math Library ====<br />
ITK has adopted the vnl math library. Vnl is a portion of the vxl image understanding environment.<br />
See http://www.robots.ox.ac.uk/ vxl/ for more information about vxl and vnl.<br />
<br />
==== Reference Counting ====<br />
<br />
ITK has adopted reference counting via so-called "smart pointers" to manage object references.<br />
While alternative approaches such as automatic garbage collection were considered, their overhead<br />
due to memory requirements, performance, and lack of control as to when to delete memory, precluded<br />
these methods. Smart pointers manage the reference to objects, automatically incrementing<br />
and deleting an instance's reference count, deleting the object when the count goes to zero.<br />
These are the most important factors influencing the coding style found in Insight. Now we will<br />
look at the details.<br />
<br />
=== Copyright ===<br />
<br />
ITK has adopted a standard copyright. This copyright should be placed at the head of every source<br />
code file. The current copyright header and license reads as follows:<br />
<br />
<pre><nowiki><br />
/*========================================================================= <br />
* <br />
* Copyright Insight Software Consortium <br />
* <br />
* Licensed under the Apache License, Version 2.0 (the "License"); <br />
* you may not use this file except in compliance with the License. <br />
* You may obtain a copy of the License at <br />
* <br />
* http://www.apache.org/licenses/LICENSE-2.0.txt <br />
* <br />
* Unless required by applicable law or agreed to in writing, software <br />
* distributed under the License is distributed on an "AS IS" BASIS, <br />
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. <br />
* See the License for the specific language governing permissions and <br />
* limitations under the License. <br />
* <br />
*=========================================================================*/<br />
</nowiki></pre><br />
<br />
[[ITK Copyright Header|Copyright Header]]<br />
<br />
=== File Organization ===<br />
<br />
Classes are created and (usually) organized into a single class per file set. A file set consists of .h<br />
header file, .cxx implementation file, and/or a .hxx templated implementation file. Helper classes<br />
may also be defined in the file set, typically these are not visible to the system at large, or placed<br />
into a special namespace.<br />
<br />
Source files must be placed in the correct directory for logical consistency with the rest of the<br />
system, and to avoid cyclic dependencies. Currently the ITK source directory structure is found in<br />
ITK/Modules and consists of the following subdirectories:<br />
<br />
* Bridge<br />
* Core<br />
* External<br />
* Filtering<br />
* GPU<br />
* IO<br />
* Nonunit<br />
* Numerics<br />
* Registration<br />
* Segmentation<br />
* ThirdParty<br />
<br />
Each one of these directories represent a Group of Modules.<br />
<br />
Please discuss with the ITK Developers about the best Module to place your new code.<br />
<br />
For a full list of Modules, please see:<br />
<br />
http://www.itk.org/Doxygen/html/modules.html<br />
<br />
=== Naming Conventions ===<br />
<br />
In general, <br />
<br />
* Names are constructed by using case change to indicate separate words, as in TimeStamp<br />
(versus Time Stamp).<br />
* Underscores are not used.<br />
* Variable names are chosen carefully with the intention to convey the meaning behind the code.<br />
* Names are generally spelled out; use of abbreviations is discouraged. (Abbreviation are allowable when in common use, and should be in<br />
uppercase as in RGB.) While this does result in long names, it self-documents the code.<br />
* If you learn how to use name completion in your editor (e.g.,Vim, Emacs), this inconvenience can be minimized.<br />
<br />
Depending on whether the name is a<br />
<br />
* class<br />
* file<br />
* variable<br />
* or other name<br />
<br />
variations on this theme result as explained in the following subsections.<br />
<br />
==== Naming Classes ====<br />
<br />
* Classes are named beginning with a capital letter.<br />
* Classes are placed in the appropriate namespace, typically itk:: (see namespaces below).<br />
* Classes are named according to the following general rule:<br />
class name = <algorithm><input><concept><br />
* In this formula, the name of the algorithm or process (possibly with an associated adjective or<br />
adverb) comes first, followed by an input type (if the class is a filter), and completed by a concept<br />
name.<br />
* A concept is an informal classification describing what a class does. There are many<br />
concepts, here are a few of them.<br />
<br />
The more common or important concepts are underlined.<br />
<br />
* '''Accessor''' Access and convert between types.<br />
* '''Adaptor''' Provide access to a portion of a complex pixel type.<br />
* '''Boundary''' The boundary of a cell.<br />
* '''Calculator''' Compute information.<br />
* '''Classifier''' Classify a pixel.<br />
* '''Container''' A container of objects such as points or cells.<br />
* '''Estimator''' Estimate a value or condition.<br />
* '''Factory''' Object factories are used to create instances.<br />
* '''Filter''' A class that participates in the data processing pipeline. Filters typically take one or more inputs and produce one or more outputs.<br />
* '''Function''' Evaluate a function at a given position.<br />
* '''Identifier''' A unique id for accessing points, cells, or other entities.<br />
* '''Interface''' Classes that specify an abstract interface.<br />
* '''Interpolator''' Interpolate data values, for example at non-pixel values.<br />
* '''Iterator''' Traverse data in various ways (e.g., forward, backward, within a region, etc.)<br />
* '''Mapper''' Transform data from one form into another.<br />
* '''Metric''' Compute similarity between two objects.<br />
* '''Operator''' A class that applies a user-specified function to a region.<br />
* '''Optimizer''' A class that performs numerical optimization.<br />
* '''Pointer''' A smart pointer to an instance of a class. Almost all instance in ITK are referred to via smart pointers.<br />
* '''Reader''' A class that reads a single data object (e.g., image or mesh).<br />
* '''Reference''' A type that refers to another object.<br />
* '''Region''' A subset of a data object, such as an image region.<br />
* '''Source''' A filter that initiates the data processing pipeline such as a reader or a procedural data generator.<br />
* '''Threader''' A class that manages multi-threading.<br />
* '''Traits''' A collection of template parameters used to control the instantiation of other classes.<br />
* '''Transform''' Various types of transformations including affine, procedural, and so on.<br />
* '''Writer''' A filter that terminates the data processing pipeline by writing data to disk or to a communicationsport.<br />
<br />
<br />
The naming of classes is an art form; please review existing names to catch the spirit of the naming<br />
convention.<br />
<br />
Example names include:<br />
<br />
* ShrinkImageFilter<br />
* TriangleCell<br />
* ScalarImageRegionIterator<br />
* NeighborhoodIterator<br />
* MapContainer<br />
* DefaultImageTraits<br />
* BackwardDifferenceOperator<br />
<br />
==== Naming Files ====<br />
<br />
* Files should have the same name as the class, with an "itk" prepended.<br />
* Header files are named .h, while implementation files are named either .cxx or .hxx, depending on whether they are implementations of templated classes.<br />
** For example, the class itk::Image <br />
*** is declared in the file itkImage.h and<br />
*** is defined in the file itkImage.hxx (because Image is templated).<br />
** The class itk::Object<br />
*** is declared in the file itkObject.h<br />
*** and is defined in the file itkObject.cxx<br />
<br />
==== Naming Methods and Functions ====<br />
Global functions and class methods, either static or class members, are named beginning with<br />
a capital letter. The biggest challenge when naming methods and functions is to be consistent<br />
with existing names. For example, given the choice between ComputeBoundingBox() and<br />
CalculateBoundingBox() (CalcBoundingBox() is not allowed because it is not spelled out), the<br />
choice is ComputeBoundingBox() because \Compute" is used elsewhere in the system in similar<br />
settings (The concepts described previously should be used whenever possible).<br />
When referring to class methods in code, an explicit this-> pointer should be used, as in this->ComputeBoundingBox().<br />
The use of the explicit this-> pointer helps clarify exactly which method, and where it originates,<br />
is being invoked. Similarly the \::" global namespace should be used when referring to a global<br />
function.<br />
<br />
==== Naming Class Data Members ====<br />
<br />
Class data members are prepended with m as in m_Size. This clearly indicates the origin of data<br />
members, and differentiates them from all other variables.<br />
<br />
==== Naming Local Variables ====<br />
Local variables begin in lowercase. There is more <br />
flexibility in the naming of local variables; please<br />
remember that others will study, maintain, fix, and extend your code. Any bread crumbs that<br />
you can drop in the way of explanatory variable names and comments will go a long way towards<br />
helping other developers.<br />
<br />
==== Naming Template Parameters ====<br />
Template parameters follow the usual rules with naming except that they should start with either<br />
the capital letter T or V. Type parameters begin with the letter T while value template parameters<br />
begin with the letter V.<br />
<br />
* For tempalate parameters the use of "typename" is preferred over "class". Very early c++ compilers did not have a "typename" keyword, and "class" was repurposed for declaring template parameters. It was later discovered that this lead to ambiguity in some valid code constructs, and the "typename" key word was added. It is often agreed (http://blogs.msdn.com/b/slippman/archive/2004/08/11/212768.aspx) that "typename" is marginally more expressive in it's intent and ITK should consistently use "typename" instead of "class".<br />
<br />
==== Naming Typedefs ====<br />
Typedefs are absolutely essential in generic programming. They significantly improve the readibility<br />
of code, and facilitate the declaration of complex syntactic combinations. Unfortunately, creation<br />
of typedefs is tantamount to creating another programming language. Hence typedefs must be used<br />
in a consistent fashion.<br />
The general rule for typedef names is that they end in the word Type. For example<br />
typedef TPixel PixelType;<br />
However, there are many exceptions to this rule that recognize that ITK has several important<br />
concepts that are expressed partially in the names used to implement the concept. An iterator is a<br />
concept, as is a container or pointer. These concepts are used in preference to Type at the end of<br />
a typedef as appropriate. For example<br />
ITK Style Guide 9<br />
typedef typename ImageTraits::PixelContainer PixelContainer;<br />
Here Container is a concept used in place of Type.<br />
ITK currently identifies the following concepts used when naming typedefs.<br />
* Self as in typedef Image Self;. All classes should define this typedef.<br />
* Superclass as in typedef ImageBase<VImageDimension> Superclass;. All classes should define the Superclass typedef.<br />
* Pointer as in a smart pointer to an object as in typedef SmartPointer<Self> Pointer;<br />
* Container is a type of container class.<br />
* Iterator an iterator over some container class.<br />
* Identifier or id such as a point or cell id.<br />
<br />
==== Using Underscores ====<br />
Don't use them. The only exception is when defining preprocessor variables and macros (which are<br />
discouraged). In this case, underscores are allowed to separate words.<br />
<br />
==== Preprocessor Directives ====<br />
<br />
* Some of the worst code contains many preprocessor directives and macros. Do not use them except in a very limited sense (to support minor differences in compilers or operating systems). <br />
* If a class makes extensive use of preprocessor directives, it is a candidate for separation into multiple sub-classes.<br />
<br />
==== Header Includes ====<br />
<br />
Header includes use the style<br />
<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
</source><br />
<br />
Only the required headers should be included. If an included header already includes a header for a class also used in the current file, the header for that class should not be included.<br />
<br />
Header includes are preferred over forward declarations. Forward declarations are only used to prevent circular dependencies.<br />
<br />
==== Namespaces ====<br />
<br />
All classes should be placed in the itk:: namespace. Additional sub-namespaces are being designed to support special functionality.<br />
<br />
Please see current documentation to determine if there is a subnamespace is relevant to your situation. Normally sub-namespaces are used for helper ITK classes.<br />
<br />
Code should not use ''using namespace''. This is to avoid namespace conflicts, but, more importantly, to improve readability.<br />
<br />
When declaring or defining members of the "itk" namespace, for example, the 'itk::' namespace prefix should not be added. That is, code within "namespace itk { ... }" should not used "itk::".<br />
<br />
==== Const Correctness ====<br />
<br />
Const correctness is important. Please use it as appropriate to your class or method.<br />
<br />
==== Code Layout and Indentation ====<br />
<br />
The following are the accepted ITK code layout rules and indentation style. After reading this section, you may wish to visit many of the source files found in ITK. This will help crystallize the rules described here.<br />
<br />
==== General Layout ====<br />
<br />
* Each line of code should take no more than 200 characters.<br />
* Break the code across multiple lines as necessary.<br />
* Use lots of whitespace to separate logical blocks of code, intermixed with comments.<br />
* To a large extent the structure of code directly expresses its implementation.<br />
* The appropriate indentation level is '''two spaces''' for each level of indentation.<br />
* '''DO NOT USE TABS.'''<br />
** Set up your editor to insert spaces. Using tabs may look good in your editor but will wreak havoc in others.<br />
* The declaration of variables within classes, methods, and functions should be one declaration per line.<br />
<br />
<source lang="cpp"><br />
int i;<br />
int j;<br />
char* stringname;<br />
</source><br />
<br />
==== Class Layout ====<br />
<br />
Classes are defined using the following guidelines.<br />
* Begin with #include guards.<br />
* Follow with the necessary includes. Include only what is necessary to avoid dependency problems.<br />
* Place the class in the correct namespace.<br />
* Public methods come first.<br />
* Protected methods follow.<br />
* Private members come last.<br />
* Public data members are ''forbidden''.<br />
* Templated classes require a special preprocessor directive to control the manual instantiation of templates. See the example below and look for ITK MANUAL INSTANTIATION.<br />
The class layout looks something like this:<br />
<br />
<source lang="cpp"><br />
#ifndef itkImage_h<br />
#define itkImage_h<br />
<br />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
<br />
namespace itk<br />
{<br />
<br />
/** \class Image<br />
* \brief Templated n-dimensional image class.<br />
*<br />
* .... detailed documentation....<br />
*/<br />
template< typename TPixel, unsigned int VImageDimension=2,<br />
typename TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class Image: public ImageBase< VImageDimension ><br />
{<br />
public:<br />
//....stuff...<br />
protected:<br />
//....stuff...<br />
private:<br />
//....stuff...<br />
};<br />
<br />
} // end namespace itk<br />
<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
<br />
#endif<br />
</source><br />
<br />
==== Method Definition ====<br />
<br />
* Methods are defined across multiple lines. This is to accommodate the extremely long definitions possible when using templates.<br />
* The starting and ending brace should be in column one. For example:<br />
<br />
<source lang="cpp"><br />
template<typename TPixel, unsigned int VImageDimension, typename TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
//...stuff...<br />
}<br />
</source><br />
<br />
* The first line is the template declaration.<br />
* The second line is the method return type.<br />
* The third line is the class qualifier.<br />
* And the fourth line in the example above is the name of the method.<br />
<br />
=== Use of Braces ===<br />
<br />
* Braces must be used to delimit the scope of an if, for, while, switch, or other control structure.<br />
* Braces are placed on a line by themselves:<br />
<br />
<source lang="cpp"><br />
for( unsigned int ii = 0; ii < 3; ++ii )<br />
{<br />
...<br />
}<br />
</source><br />
<br />
<br />
or when using an if:<br />
<br />
<source lang="cpp"><br />
if( condition )<br />
{<br />
...<br />
}<br />
else if( other condition )<br />
{<br />
...<br />
}<br />
else<br />
{<br />
....<br />
}<br />
</source><br />
<br />
<br />
==== Indentation Inside Braces ====<br />
<br />
<br />
Source code in the body of the brackets must be aligned along with the brackets. As in<br />
<br />
<source lang="cpp"><br />
if ( condition )<br />
{<br />
unsigned int numberOfIterations = 100;<br />
filter->SetNumberOfIterations( numberOfIterations );<br />
filter->Update();<br />
filter->Print( std::cout );<br />
}<br />
</source><br />
<br />
=== Doxygen Documentation System ===<br />
<br />
* Doxygen is an open-source, powerful system for automatically generating documentation from source code.<br />
* To use Doxygen effectively, the developer must insert comments, delimited in a special way, that Doxygen extracts to produce the documentation. While there are a large number of options to Doxygen, developers at a minimum should insert the following Doxygen commands.<br />
<br />
See more at<br />
<br />
http://www.stack.nl/dimitri/doxygen/index.html<br />
<br />
==== Documenting a Class ====<br />
<br />
* Classes should be documented using the '''class''' and '''brief''' Doxygen commands, followed by the detailed class description:<br />
<br />
<source lang="cpp"><br />
/** \class Object<br />
* \brief Base class for most itk classes.<br />
*<br />
* Object is the second-highest level base class for most itk objects.<br />
* It extends the base object functionality of LightObject by<br />
* implementing debug flags/methods and modification time tracking.<br />
*/<br />
</source><br />
<br />
==== Documenting a Method ====<br />
<br />
Methods should be documented using the following comment block style as shown in the following<br />
example. Make sure you use correct English and complete, grammatically correct sentences. Finish your sentences with a period (.).<br />
<br />
<br />
<source lang="cpp"><br />
/** Access a pixel at a particular index location.<br />
* This version can be an lvalue. */<br />
TPixel & operator[](const IndexType &index)<br />
{ return this->GetPixel(index); }<br />
</source><br />
<br />
The key here is that the comment starts with /**, each subsequent line has an aligned *, and the<br />
comment block terminates with a */.<br />
<br />
==== Documenting ivars ====<br />
<br />
Class member variables should be documented using the following comment block style as shown in the following example. Make sure you use correct English and grammatically correct sentences. Finish the documentation line with a period (.).<br />
<br />
<source lang="cpp"><br />
// Standard deviation of the gaussian used for smoothing.<br />
SigmaArrayType m_Sigma;<br />
</source><br />
<br />
=== Using Standard Macros (itkMacro.h) ===<br />
<br />
* There are several macros defined in the file itkMacro.h.<br />
* These macros should be used because they perform several important operations, that if not done correctly can cause serious, hard to debug problems in the system.<br />
** These operations are:<br />
*** Object modified time is properly managed.<br />
*** Debug information is printed.<br />
*** Reference counting is handled properly.<br />
<br />
Some of the more important object macros are as follows.<br />
<br />
* itkNewMacro(T) Creates the static class method New(void) that interacts with the object factory to instantiate objects. The method returns a SmartPointer<T> properly reference counted.<br />
* itkDebugMacro(x) If debug is set on a subclass of itk::Object, prints debug information to the appropriate output stream.<br />
* itkSetMacro(name,type) Creates a method SetName() that takes argument type type.<br />
* itkGetMacro(name,type) Creates a method GetName() that returns a non-const value of type type.<br />
* itkGetConstMacro(name,type) Creates a method GetName() that returns a const value of type type.<br />
* itkSetStringMacro(name) Creates a method SetName() that takes argument type const char*.<br />
* itkGetStringMacro(name) Creates a method GetName() that returns argument type const char*.<br />
* itkBooleanMacro(name) Creates two methods named NameOn and NameOff that sets true/false boolean values.<br />
* itkSetObjectMacro(name,type) Creates a method SetName() that takes argument type type *.<br />
* itkGetObjectMacro(name,type) Creates a method named GetName() that returns a smart pointer to a type type.<br />
* itkSetConstObjectMacro(name,type) Creates a method SetName() that takes argument type const type *.<br />
* itkGetConstObjectMacro(name,type) Creates a method named GetName() that returns a const smart pointer to a type type.<br />
<br />
Please review this file and become familiar with these macros.<br />
<br />
=== Exception Handling ===<br />
<br />
Indicate that methods throw exceptions in the method declaration as in:<br />
<br />
<source lang="cpp"><br />
const float* foo() const throws itk<br />
</source><br />
<br />
=== Documentation Style ===<br />
<br />
The Insight consortium has adopted the following guidelines for producing supplemental documentation (documentation not produced by Doxygen).<br />
<br />
* The common denominator for documentation is either PDF or HTML. All documents in the system should be available in these formats, even if they are mastered by another system.<br />
* Presentations are acceptable in Microsoft PowerPoint format.<br />
* Administrative and planning documents are acceptable in Microsoft Word format (either .doc or .rtf).<br />
* Larger documents, such as the user's or developer's guide, are written in LATEX.<br />
<br />
== CMake Style ==<br />
<br />
A proposal style guide for CMake variables is presented [[ITK_CMake_Style|HERE]].<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Release_Schedule&diff=56378ITK/Release Schedule2014-06-04T06:25:27Z<p>Jhlegarreta: /* RC process */ Minor ortography correction</p>
<hr />
<div>The next feature release is 4.6 scheduled for June, 2014.<br />
<br />
== Release Life Cycle ==<br />
<br />
=== Last period for adding classes and features ===<br />
<br />
* New classes will be selected from good reviews from the Insight Journal<br />
* New features and new methods can be added during this period.<br />
<br />
=== Feature Freeze ===<br />
<br />
* Increase code coverage<br />
** address any UNTESTED files<br />
** address files with code coverage lower than 80%<br />
* Address Run-time memory issues<br />
** Purify reports<br />
** Valgrind reports<br />
<br />
=== RC process ===<br />
<br />
* No new features should merged during the feature freeze, i.e. ''ENH:'' commits, although they can be prepared in Gerrit.<br />
* Release candidates (RC's) will be tagged weekly.<br />
* RC's will be tagged after dashboard examination and discussion at the Friday TCon.<br />
* The repository will be hard frozen to only allow merging by gatekeepers on Wednesday evening before the dashboards start. The freeze will be released after tagging.<br />
* For the final RC, only gatekeeper merges will occur.<br />
<br />
=== Posting Tarballs ===<br />
<br />
* Tarballs are posted to SourceForge<br />
* Tarballs are linked from the ITK Download<br />
<br />
== Release 4.6 Schedule ==<br />
<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Release Number !! Date <br />
|-<br />
| RC Cycles|| June 9, 2014<br />
|-<br />
| Final Release || June 30, 2014<br />
|}<br />
<br />
== Release 4.7 Schedule ==<br />
<br />
{| border="1"<br />
|- bgcolor="#abcdef"<br />
! Release Number !! Date <br />
|-<br />
| RC Cycles|| November 28, 2014<br />
|-<br />
| Final Release || December 15, 2014<br />
|}<br />
<br />
== Check-list for Moving Code from IJ to Gerrit and from Gerrit ==<br />
<br />
=== For IJ Articles To Gerrit ===<br />
<br />
* Responsible developer should add a review '''before''' moving into local copy of Gerrit. Please provide authors with feedback regarding changes that were made to conform to ITK style/documentation etc.<br />
<br />
=== For Adding Images to Input or Baseline ===<br />
<br />
* Images should be '''SMALL'''.<br />
** The source tree is not an image database, but a source code repository.<br />
** Adding an image larger than 50Kb should be justified by a discussion in the Developers list<br />
* Regression images should not use Analyze format unless the test is for the AnalyzeImageIO and related classes.<br />
* Images should use non-trivial Metadata.<br />
** Origin should be different form zeros<br />
** Spacing should be different from ones, and it should be anisotropic<br />
** Direction should be different from Identity<br />
<br />
=== For Moving Code From Review ===<br />
* At least one independent (other than contributor) should sign off on the API<br />
* Coverage should be as close to 100% as possible.<br />
** and never lower than 90%.<br />
** For example, itkTransformIOBase.cxx is only at 63% coverage. Should be easily fixed by adding a Print() to one of the tests.<br />
<br />
=== For All ===<br />
* Check all comments for proper English<br />
* Should pass KWStyle. IJ articles should be checked with KWStyle before checking into repository.<br />
* Should pass PrintSelf. IJ articles should pass PrintSelf check before checking into repository.<br />
* Replace itkGetMacro with itkGetConstMacro.<br />
* Header file should contain Insight Journal citation<br />
** Using the "handle" link.<br />
* Use vcl verions of all transcendental functions.<br />
** For example, itkGaborKernelFunction used sin() and cos() rather than vcl_sin() and vcl_cos().<br />
* Progress should be present for all filters. Use itk::SimplerFilterWatcher to exercise progress and PrintSelfs.<br />
* When appropriate, class should handle image directions. Tests should use non-default values for origin, spacing and dimension.<br />
** GaborImageSource did not provide methods to set/get directions.<br />
* Regression tests names should when possible have the same name as the test.<br />
* Exceptions should be descriptive and provide as much information as possible<br />
* Member data should be private with access if required through Get methods.<br />
<br />
== Release History ==<br />
* [[ITK_Previous_Releases|ITK Release History]]</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Original_Developers&diff=56248ITK/Original Developers2014-05-03T10:49:23Z<p>Jhlegarreta: /* Original ITK Developers */ Added note about Bill; still active in ITK</p>
<hr />
<div>== Original ITK Developers ==<br />
<br />
Most of the early developers are listed in the following.<br />
<br />
* Elsa Angelini - Columbia; segmentation algorithms<br />
* Brian Avants - UPenn; FEM classes, registration algorithms<br />
* Stephen Aylward - UNC; architecture, algorithms<br />
* Dan Blezek - GE CRD; testing infrastructure<br />
* Josh Cates - Utah; imaging and segmentation classes and filters<br />
* Ting Chen - UPenn; segmentation algorithms<br />
* Jeffrey Duda - UPenn; FEM classes, registration algorithms<br />
* James Gee - UPenn; FEM architecture, registration algorithms<br />
* Bill Hoffman - Kitware; CMake (build process); vxl/vnl numerics; infrastructure (smart pointers, object factories, callback mechanism)<br />
* Paul Hughett - UPenn; quality, algorithms<br />
* Luis Ibanez - UNC (now at Kitware); imaging classes and filters<br />
* Celina Imielinska - Columbia; segmentation algorithms<br />
* Yinpeng Jin - Columbia; segmentation algorithms<br />
* Brad King - Kitware; Mesh class, autowrapping of C++ code<br />
* Bill Lorensen - formerly at GE CRD, retired - still active in ITK; testing, requirements, architecture<br />
* Ken Martin - Kitware; Build process, architecture, infrastructure<br />
* Dimitris Metaxas - UPenn; segmentation algorithms<br />
* Jim Miller - GE CRD; Image classes, iterators, pipeline update mechanism<br />
* Lydia Ng - Mathsoft (now at the Allen Institute for Brain Science); Image filters, clustering/segmentation algorithms<br />
* Aljaz Noe - UPenn; FEM classes<br />
* Sayan Pathak – MathSoft (now at Insightful); image clustering/segementation algorithms<br />
* Will Schroeder - Kitware; architecture, Mesh classes, documentation, algorithms, core classes<br />
* Marcelo Siqueira - UPenn; FEM classes<br />
* George Stetton - UPittsburgh; image filters, algorithms<br />
* Tessa Sundaram - UPenn; FEM classes, registration algorithms<br />
* Jayaram Udupa - UPenn; segmentation algorithms<br />
* Ross Whitaker - Utah; architecture, algorithms<br />
* Ying Zhuge - UPenn; segmentation algorithms</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Original_Developers&diff=56075ITK/Original Developers2014-04-16T16:44:22Z<p>Jhlegarreta: Updated Bill Lorensen's current status</p>
<hr />
<div>== Original ITK Developers ==<br />
<br />
Most of the early developers are listed in the following.<br />
<br />
* Elsa Angelini - Columbia; segmentation algorithms<br />
* Brian Avants - UPenn; FEM classes, registration algorithms<br />
* Stephen Aylward - UNC; architecture, algorithms<br />
* Dan Blezek - GE CRD; testing infrastructure<br />
* Josh Cates - Utah; imaging and segmentation classes and filters<br />
* Ting Chen - UPenn; segmentation algorithms<br />
* Jeffrey Duda - UPenn; FEM classes, registration algorithms<br />
* James Gee - UPenn; FEM architecture, registration algorithms<br />
* Bill Hoffman - Kitware; CMake (build process); vxl/vnl numerics; infrastructure (smart pointers, object factories, callback mechanism)<br />
* Paul Hughett - UPenn; quality, algorithms<br />
* Luis Ibanez - UNC (now at Kitware); imaging classes and filters<br />
* Celina Imielinska - Columbia; segmentation algorithms<br />
* Yinpeng Jin - Columbia; segmentation algorithms<br />
* Brad King - Kitware; Mesh class, autowrapping of C++ code<br />
* Bill Lorensen - retired (formerly at GE CRD); testing, requirements, architecture<br />
* Ken Martin - Kitware; Build process, architecture, infrastructure<br />
* Dimitris Metaxas - UPenn; segmentation algorithms<br />
* Jim Miller - GE CRD; Image classes, iterators, pipeline update mechanism<br />
* Lydia Ng - Mathsoft (now at the Allen Institute for Brain Science); Image filters, clustering/segmentation algorithms<br />
* Aljaz Noe - UPenn; FEM classes<br />
* Sayan Pathak – MathSoft (now at Insightful); image clustering/segementation algorithms<br />
* Will Schroeder - Kitware; architecture, Mesh classes, documentation, algorithms, core classes<br />
* Marcelo Siqueira - UPenn; FEM classes<br />
* George Stetton - UPittsburgh; image filters, algorithms<br />
* Tessa Sundaram - UPenn; FEM classes, registration algorithms<br />
* Jayaram Udupa - UPenn; segmentation algorithms<br />
* Ross Whitaker - Utah; architecture, algorithms<br />
* Ying Zhuge - UPenn; segmentation algorithms</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Original_Developers&diff=56074ITK/Original Developers2014-04-16T16:41:22Z<p>Jhlegarreta: Corrected Lydia Ng's current affiliation</p>
<hr />
<div>== Original ITK Developers ==<br />
<br />
Most of the early developers are listed in the following.<br />
<br />
* Elsa Angelini - Columbia; segmentation algorithms<br />
* Brian Avants - UPenn; FEM classes, registration algorithms<br />
* Stephen Aylward - UNC; architecture, algorithms<br />
* Dan Blezek - GE CRD; testing infrastructure<br />
* Josh Cates - Utah; imaging and segmentation classes and filters<br />
* Ting Chen - UPenn; segmentation algorithms<br />
* Jeffrey Duda - UPenn; FEM classes, registration algorithms<br />
* James Gee - UPenn; FEM architecture, registration algorithms<br />
* Bill Hoffman - Kitware; CMake (build process); vxl/vnl numerics; infrastructure (smart pointers, object factories, callback mechanism)<br />
* Paul Hughett - UPenn; quality, algorithms<br />
* Luis Ibanez - UNC (now at Kitware); imaging classes and filters<br />
* Celina Imielinska - Columbia; segmentation algorithms<br />
* Yinpeng Jin - Columbia; segmentation algorithms<br />
* Brad King - Kitware; Mesh class, autowrapping of C++ code<br />
* Bill Lorensen - GE CRD; testing, requirements, architecture<br />
* Ken Martin - Kitware; Build process, architecture, infrastructure<br />
* Dimitris Metaxas - UPenn; segmentation algorithms<br />
* Jim Miller - GE CRD; Image classes, iterators, pipeline update mechanism<br />
* Lydia Ng - Mathsoft (now at the Allen Institute for Brain Science); Image filters, clustering/segmentation algorithms<br />
* Aljaz Noe - UPenn; FEM classes<br />
* Sayan Pathak – MathSoft (now at Insightful); image clustering/segementation algorithms<br />
* Will Schroeder - Kitware; architecture, Mesh classes, documentation, algorithms, core classes<br />
* Marcelo Siqueira - UPenn; FEM classes<br />
* George Stetton - UPittsburgh; image filters, algorithms<br />
* Tessa Sundaram - UPenn; FEM classes, registration algorithms<br />
* Jayaram Udupa - UPenn; segmentation algorithms<br />
* Ross Whitaker - Utah; architecture, algorithms<br />
* Ying Zhuge - UPenn; segmentation algorithms</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Original_Developers&diff=56073ITK/Original Developers2014-04-16T16:29:43Z<p>Jhlegarreta: Minor ortography correction</p>
<hr />
<div>== Original ITK Developers ==<br />
<br />
Most of the early developers are listed in the following.<br />
<br />
* Elsa Angelini - Columbia; segmentation algorithms<br />
* Brian Avants - UPenn; FEM classes, registration algorithms<br />
* Stephen Aylward - UNC; architecture, algorithms<br />
* Dan Blezek - GE CRD; testing infrastructure<br />
* Josh Cates - Utah; imaging and segmentation classes and filters<br />
* Ting Chen - UPenn; segmentation algorithms<br />
* Jeffrey Duda - UPenn; FEM classes, registration algorithms<br />
* James Gee - UPenn; FEM architecture, registration algorithms<br />
* Bill Hoffman - Kitware; CMake (build process); vxl/vnl numerics; infrastructure (smart pointers, object factories, callback mechanism)<br />
* Paul Hughett - UPenn; quality, algorithms<br />
* Luis Ibanez - UNC (now at Kitware); imaging classes and filters<br />
* Celina Imielinska - Columbia; segmentation algorithms<br />
* Yinpeng Jin - Columbia; segmentation algorithms<br />
* Brad King - Kitware; Mesh class, autowrapping of C++ code<br />
* Bill Lorensen - GE CRD; testing, requirements, architecture<br />
* Ken Martin - Kitware; Build process, architecture, infrastructure<br />
* Dimitris Metaxas - UPenn; segmentation algorithms<br />
* Jim Miller - GE CRD; Image classes, iterators, pipeline update mechanism<br />
* Lydia Ng - Mathsoft (now at Insightful); Image filters, clustering/segmentation algorithms<br />
* Aljaz Noe - UPenn; FEM classes<br />
* Sayan Pathak – MathSoft (now at Insightful); image clustering/segementation algorithms<br />
* Will Schroeder - Kitware; architecture, Mesh classes, documentation, algorithms, core classes<br />
* Marcelo Siqueira - UPenn; FEM classes<br />
* George Stetton - UPittsburgh; image filters, algorithms<br />
* Tessa Sundaram - UPenn; FEM classes, registration algorithms<br />
* Jayaram Udupa - UPenn; segmentation algorithms<br />
* Ross Whitaker - Utah; architecture, algorithms<br />
* Ying Zhuge - UPenn; segmentation algorithms</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/FAQ&diff=56000ITK/FAQ2014-04-01T06:42:41Z<p>Jhlegarreta: /* How do I cite the use of ITK in a publication? */ Added 'In press' note to the Third Edition of the manual</p>
<hr />
<div>== General information and availability ==<br />
<br />
=== Do I need VTK to build ITK ? ===<br />
With the default configuration, ITK does not require VTK. However, some optional modules (ITKVTKGlue) do require VTK.<br />
<br />
ITK does not provide any visualization functionalities. Applications requiring visualization should implement those functionalities from internal code or libraries like OpenGL, GLUT or VTK.<br />
<br />
=== What 3D file formats can ITK import and export? ===<br />
<br />
The following table identifies the file formats that ITK can read/write via a factory mechanism based on the file extension (itk::ImageIOFactory). Some proprietary files format are only imported. More information on [[ITK File Formats]] is available, including data types supported.<br />
<br />
A very nice tool for viewing all of these images is ImageViewer which can be found in the ITKApps repository.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! File Format<br />
! Read/Write<br />
! Import<br />
|-<br />
| Analyze 7.5 || AnalyzeImageIO ||<br />
|-<br />
| BMP &dagger; || BMPImageIO ||<br />
|-<br />
| DICOM || GDCMImageIO || Using DicomImageIO is backward compatible, but user should prefer GDCMImageIO<br />
|-<br />
| GE 4x || || GE4ImageIO<br />
|-<br />
| GE 5x || || GE5ImageIO<br />
|-<br />
| GE Advantage Windows || || GEAdwImageIO<br />
|-<br />
| Gipl (.gipl) || GiplImageIO ||<br />
|-<br />
| IPLCommon || || IPLCommonImageIO<br />
|-<br />
| JPEG &dagger; || JPEGImageIO ||<br />
|-<br />
| MetaImage (.mha/.mhd) || MetaImageIO ||<br />
|-<br />
| PNG &dagger; || PNGImageIO ||<br />
|-<br />
| Raw &Dagger; || RawImageIO ||<br />
|-<br />
| Siemens Vision || || SiemensVisionImageIO<br />
|-<br />
| Stimulate (spr/sdt) || StimulateImageIO ||<br />
|-<br />
| TIFF || TIFFImageIO ||<br />
|-<br />
| VTK Structured Points || VTKImageIO ||<br />
|}<br />
<br />
&dagger; BMP, PNG and JPEG are not very good formats for 3D medical images. They only support 2D images and a limited set of pixel types such as unsigned char, and unsigned short. The great advantage of BMP, PNG and JPEG is that you can view them with almost any image viewer. It is possible to read/write 3D datasets as collections of 2D slices each one in an independent BMP, PNG or JPEG file by using the ImageSerierReader and ImageSeriesWriter.<br />
<br />
&Dagger; It is higly recommended not using this format. RAW is not a format, it is insufficient, inconsistent and simply dangerous. A RAW file without a header is useless, and once you add a header, it is not RAW anymore.<br />
<br />
=== What if my file format is not supported by ITK? ===<br />
If ITK doesn't have a specific file format reader at this point, you may try converting this specific file format image to a format like PNG, for which ITK has readers.<br />
<br />
A good set of tools for performing such conversions is available in ImageMagick. It can be downloaded it for free from: http://www.imagemagick.org/<br />
<br />
You can also take advantage of the VTK readers/importers. All you need is then use the VTKImageToImage adaptor in order to convert the vtkImageData into an itk::Image.<br />
<br />
Supported VTK file formats can be found here: [[VTK_FAQ#What_image_file_formats_can_VTK_read_and_write.3F|What image file formats can VTK read and write?]] and [[VTK_FAQ#What_3D_file_formats_can_VTK_import_and_export.3F|What 3D file formats can VTK import and export]]<br />
<br />
=== How do I read a volume from a DICOM series? ===<br />
The following are alternative options for reading DICOM series. The first one in the list is the recommended option. The others are provided in case of desperation.<br />
<br />
# Use the itk::ImageSeriesReader<> in combination with the DicomSeriesFileNames<>. For a full example on how to do this, please look at the source code under Insight/Code/Examples/IO/DicomSeriesReadImageWrite.cxx.<br />
# Write a MetaImageHeader<br>This is a small text file holding information about the image: spacing, dimensions, pixelt type... This header can hold the list of dicom files you want to read. The only restriction is that the files must be uncompressed.<br>The easy way to create a MetaImage header is to use the application: MetaImageImporter that is available in: InsightApplications/MetaImageImporter. you can also take an existing metaimage reader and modify it in order to fit your needs. Please find attached one file that you can edit it with your favorite text editor.<br />
# Use MRIConvert<br>Jolinda Smith from the Lewis Center for Neuroimaging at the University of Oregon has developed a nice application that allows you to load DICOM series and export them in MetaImage and Analyze format (among others).<br>She graciously has made this application publicly available at: http://lcni.uoregon.edu/~jolinda/MRIConvert There is a fresh version updated in april 14th.<br />
# Jeff Brubaker and Stephen R. Aylward, at the UNC<br>CADDLab developed a DICOM query/move application called "MIND" (whit the motto: "MIND is not DICOM"). This application loads DICOM files over the network and export them in MetaImage format. This application is open source and it is available at: http://www.jeffro.net/mind/ and http://caddlab.rad.unc.edu/software/MIND/<br />
<br />
=== How do I write a volume as DICOM series? ===<br />
Use ITK in combination with gdcm <br />
<br />
http://gdcm.sourceforge.net/<br />
<br />
GDCM is an open source package developed by the Creatis team at INSA-Lyon. It is distributed under a license similar to ITK.<br />
<br />
http://gdcm.sourceforge.net/Copyright.html<br />
<br />
GCDM uses CMake in order to configure its build process, so you will find a familiar setup. Once you download, configure and buid GDCM, you can reconfigure ITK by running CMake in your ITK build, going into the Advanced options and enabling USE_GDCM. <br />
<br />
For a code example on how to use GDCM for reading and writing DICOM series, please refer to the source code in<br />
<br />
Insight/Examples/IO/DicomSeriesReadImageWrite2.cxx<br />
<br />
<font color="red">UPDATE:</font> As of ITK 2.4 this option: USE_GDCM has disapear since GDCM is now the default toolkit for reading DICOM image. See also [[Proposals:Make_GDCM_the_default_DICOM]].<br />
<br />
You can always use the latest and greatest of GDCM, simply use an installed version of GDCM and link ITK to it using ITK_USE_SYSTEM_GDCM<br />
<br />
=== Which interpreted languages are supported by ITK? ===<br />
Currently ITK supports the following language bindings:<br />
<br />
* Python <br />
* Java<br />
<br />
=== How do I cite the use of ITK in a publication? ===<br />
The Insight software may be cited by referencing the paper, the books, and/or the web site.<br />
<br />
A) '''The paper'''<br />
<br />
T.S. Yoo, M. J. Ackerman, W. E. Lorensen, W. Schroeder, V. Chalana, S. Aylward, D. Metaxas, R. Whitaker. Engineering and Algorithm Design for an Image Processing API: A Technical Report on ITK - The Insight Toolkit. In Proc. of Medicine Meets Virtual Reality, J. Westwood, ed., IOS Press Amsterdam pp 586-592 (2002).<br />
<br />
B) '''The books'''<br />
<br />
"Insight into Images"<br />
edited by Terry Yoo<br />
published by A.K. Peters 2004<br />
ISBN: 1-56881-217-5<br />
<br />
"The ITK Software Guide"<br />
Second Edition<br />
Ibanez, Schroeder, Ng, Cates.<br />
published by Kitware Inc.<br />
2005<br />
ISBN: 1-930934-15-7<br />
<br />
"The ITK Software Guide"<br />
First Edition<br />
Ibanez, Schroeder, Ng, Cates.<br />
published by Kitware Inc.<br />
2003<br />
ISBN: 1-930934-10-6<br />
<br />
"Mastering CMake,<br />
A Cross-Platform Build System"<br />
K. Martin and B. Hoffman<br />
published by Kitware Inc.<br />
ISBN: 1-930934-09-2<br />
<br />
'''BibTtex citations'''<br />
<br />
@Manual{ITKSoftwareGuide,<br />
Title = {The {ITK} {S}oftware {G}uide},<br />
Author = {Ibanez, L. and Schroeder, W. and Ng, L. and Cates, J.},<br />
Organization = "Kitware, Inc.",<br />
Edition = {First},<br />
year = {2003},<br />
note = {ISBN 1-930934-10-6},<br />
url = \href{[http://www.itk.org/ItkSoftwareGuide.pdf http://www.itk.org/ItkSoftwareGuide.pdf]}{<nowiki>http://www.itk.org/ItkSoftwareGuide.pdf</nowiki>},<br />
}<br />
<br />
@Manual{ITKSoftwareGuideSecondEdition,<br />
Title = {The {ITK} {S}oftware {G}uide},<br />
Author = {Ibanez, L. and Schroeder, W. and Ng, L. and Cates, J.},<br />
Organization = "Kitware, Inc.",<br />
Edition = {Second},<br />
year = {2005},<br />
note = {ISBN 1-930934-15-7},<br />
url = \href{[http://www.itk.org/ItkSoftwareGuide.pdf http://www.itk.org/ItkSoftwareGuide.pdf]}{<nowiki>http://www.itk.org/ItkSoftwareGuide.pdf</nowiki>},<br />
}<br />
<br />
@Manual{ITKSoftwareGuideThirdEdition,<br />
Title = {The {ITK} {S}oftware {G}uide},<br />
Author = {Johnson, Hans J. and McCormick, M. and Ib\'{a}{\~n}ez, L. and The Insight Software Consortium},<br />
Organization = "Kitware, Inc.",<br />
Edition = {Third},<br />
year = {2013},<br />
note = {\textit{''In press''}},<br />
url = \href{[http://www.itk.org/ItkSoftwareGuide.pdf http://www.itk.org/ItkSoftwareGuide.pdf]}{<nowiki>http://www.itk.org/ItkSoftwareGuide.pdf</nowiki>},<br />
}<br />
<br />
C) '''The Web sites'''<br />
<br />
"The Insight Segmentation and Registration Toolkit"<br />
www.itk.org<br />
<br />
"CMake: Cross Platform Make"<br />
www.cmake.org<br />
<br />
If you want to include ITK in an acknowledgment section, a phrase similar to the following may be used:<br />
<br />
"This work benefited from the use of the Insight Segmentation<br />
and Registration Toolkit (ITK), an open source software<br />
developed as an initiative of the U.S. National Library<br />
of Medicine and available at www.itk.org."<br />
<br />
and<br />
<br />
"The multi-platform configuration tool CMake was used for<br />
configuring ITK and facilitating its use from our project.<br />
CMake was partially funded by the U.S. National Library of<br />
Medicine as part of the Insight Toolkit project. CMake is an <br />
open source system and it is freely available at www.cmake.org."<br />
<br />
=== What does "Could not create IO object for file" mean? ===<br />
When trying to read or write a file using the ImageFileReader or the ImageFileWriter I got an exception with the following message:<br />
<br />
itk::ImageFileReaderException (00F7F494)<br />
Location: "Unknown"<br />
File: C:\ITK\InsightToolkit-1.6.0\Code\IO\itkImageFileReader.hxx<br />
Line: 101<br />
Description: Could not create IO object for file c:\t1.mnc<br />
<br />
This exception is thrown when ITK does not recognize the fileformat that you are trying to read or write. When reading, ITK recognize file formats by asking a set of internal readers to attempt to read your file. If none of the registered readers accept your file, then the exception above is thrown. When writing, ITK uses the extension of the filename in order to chose the fileformat to be used. You must make sure that you use one of the filename extensions recognized by ITK. Please look at FAQ entry 1.7 for a full list of those extensions and associated fileformats.<br />
<br />
Additional details on the ITK Input/Output architecture are available in the ITK Software Guide: http://www.itk.org/ItkSoftwareGuide.pdf.<br />
<br />
=== Is ITK FDA-Approved? ===<br />
<br />
Given the fact that ITK is a software toolkit, it cannot be the<br />
subject of FDA approval as a medical device. We have discussed<br />
this topic in several occasions and received advice from FDA<br />
representatives, that can be summarized as follow:<br />
<br />
<br />
ITK is to be considered as an off-the-shelf (OTS) product that<br />
is used for supporting a higher level medical application/product.<br />
The developer of such application/product will be responsible for<br />
performing the validation processes described in FDA published<br />
guidelines for the development of software-related medical devices.<br />
<br />
For mode details see the page [[FDA Guidelines for Software Developement]]<br />
<br />
== Language bindings ==<br />
=== What does "Error opening hint file NOTFOUND" mean? ===<br />
When you enable "USE_VTK" in the CMake configuration of ITK, and VTK was built with wrapping, CMake looks for a "hints" file.<br />
<br />
The "hints" file is on the VTK source tree under: VTK/Wrapping/hints<br />
<br />
Please switch CMake to "advanced", look for the VTK_WRAP_HINTS variable and set it to the full path to the "hints" file including the "hints" filename itself.<br />
<br />
here is how it looks in the CMakeCache.txt of a typical ITK installation:<br />
<br />
//Where can the hints file be found<br />
VTK_WRAP_HINTS:FILEPATH=/home/johndoe/src/VTK/Wrapping/hints<br />
<br />
=== How do I use ITK with WrapITK? ===<br />
<br />
* [[ITK/Java_Wrapping|Java]]<br />
* [[ITK/Python_Wrapping|Python]]<br />
* [[ITK/WrapITK Status|Wrapping status]]<br />
<br />
=== How do I use ITK from C# .NET? ===<br />
<br />
There are currently three options:<br />
# Use [http://code.google.com/p/manageditk ManagedITK]<br />
#* '''NOTE: This option is not recommended as the project is no longer supported'''<br />
# Use the [http://www.simpleitk.org/ SimpleITK] [http://sourceforge.net/projects/simpleitk/files/SimpleITK C# language bindings]<br />
#* SimpleITK is great, but it does not support all filters (e.g. no support for registration in version 0.5.1)<br />
#* A list of available filters can be found [http://www.itk.org/SimpleITKDoxygen/html/Filter_Coverage.html here] (valid Sept 2012)<br />
# Manually wrap the desired functionality<br />
#* This option requires the most work, but is the most flexible, allowing you to use any ITK functionality you desire<br />
#* An example can be found [[ITK/Using ITK from .NET|here]]<br />
<br />
NOTE: WrapITK does not currently support C# language bindings, but could be made to do so.<br />
<br />
== Using the Insight Toolkit ==<br />
<br />
=== How do I combine ITK and VTK in my application? ===<br />
<br />
A full tutorial on how to combine ITK and VTK is available at<br />
<br />
"Getting Started with ITK and VTK"<br />
http://www.itk.org/CourseWare/Training/GettingStarted-II.pdf<br />
<br />
You will need the auxiliary classes available at<br />
<br />
ITKApps<br />
<br />
For example, for converting ITK images into VTK images and back, you will find useful the files from the ITKVTKGlue module:<br />
<br />
itkImageToVTKImageFilter.h<br />
itkImageToVTKImageFilter.hxx<br />
itkVTKImageToImageFilter.h<br />
itkVTKImageToImageFilter.hxx<br />
<br />
=== How do I configure Emacs for ITK coding style? ===<br />
You can add the following codes into your .emacs file<br />
<br />
;;;;;;;;;;;;;;<br />
(c-add-style "itk"<br />
'("stroustrup" <br />
(c-basic-offset . 2)<br />
(c-offsets-alist<br />
(c . c-lineup-dont-change)<br />
(innamespace . 0)<br />
(inline-open . 0) <br />
(substatement-open . +)<br />
(statement-block-intro . 0) ) ) )<br />
(add-hook 'c++-mode-hook (function (lambda ()<br />
(c-set-style "itk")(turn-on-auto-fill))))<br />
(add-to-list 'auto-mode-alist '("\\.txx\\'" . c++-mode)) (add-to-list 'auto-mode-alist '("\\.h\\'" . c++-mode))<br />
;;;;;;;;;;;<br />
<br />
=== How do I configure VIM for ITK coding style? ===<br />
<br />
set tabstop=2 " Tabs are two characters<br />
set shiftwidth=2 " Indents are two charactes too<br />
set expandtab " Do not use tabs<br />
set matchpairs+=<:> " To mach arguments of templates<br />
set cinoptions={1s,:0,l1,g0,c0,(0,(s,m1 " ITK/VTK style indenting<br />
<br />
You can also use CMake indentation and syntax file which are available on www.vim.org.<br />
<br />
This was contributed by Andy Cedilnik @kitware.com<br />
<br />
If you'd like to enable c++ style syntax highlight for *.txx files, put the following lines in your .vimrc file:<br />
syntax on<br />
au BufNewFile,BufRead *.txx set filetype=cpp<br />
<br />
== Platform-specific questions ==<br />
=== How do I avoid multiple prompts to reload all projects in Microsoft Visual Studio? ===<br />
When the CMake source changes, you may see multiple prompts to reload many projects.<br />
<br />
DO NOT USE "Rebuild All" or "Batch Build". Use the following recommended procedure.<br />
<br />
There is an ALL_BUILD target available in the MSVC++ workspace. The best way to build ITK is to set ALL_BUILD as the active project, then select the active configuration you want (DEBUG, etc).<br />
<br />
This can also be done from the command line like this: msdev ITK.dsw /MAKE "ALL_BUILD - Debug" /REBUILD<br />
<br />
=== How do I fix Visual Studio 7 (2002) Compiler Issues? ===<br />
<br />
The Visual Studio 7.0 compiler is more similar to the version 6 compiler than the version 7.1 compiler from the C++ conformance perspective. While it does not crash as frequently as version 6, there are some code patterns that still cause an INTERNAL COMPILER ERROR. Here is one example:<br />
<br />
<pre><nowiki><br />
// Define a class template that has a data member of the template type.<br />
template <class T> struct A { T v; };<br />
<br />
// Define a primary template with no members.<br />
template <class T> struct B {};<br />
<br />
// Define a specialization that defines a type.<br />
// This line is not actually necessary to cause the ICE but will be present when this problem is encountered in practice.<br />
//template <> struct B<int> { typedef int Type; };<br />
<br />
template <class T> struct C<br />
{<br />
// Lookup the "Type" member of B<T>. In practice this will reference a specialization.<br />
typedef typename B<T>::Type Type;<br />
<br />
// Use the result of the lookup to instantiate A<> and its data member.<br />
typedef typename A<Type>::A AType;<br />
};<br />
</nowiki></pre><br />
<br />
This will cause an ICE in msc1.cpp, line 2844. The work-around is to define the "Type" member in the primary template of B even though it will not be used:<br />
<br />
<pre><nowiki><br />
template <class T> struct A { T v; };<br />
template <class T> struct B { typedef T Type; };<br />
template <class T> struct C<br />
{<br />
typedef typename B<T>::Type Type;<br />
typedef typename A<Type>::A AType;<br />
};<br />
</nowiki></pre><br />
<br />
=== How do I fix prolems with MipsPro Compilers (7.3.3.1m and 7.4.2m) on IRIX? ===<br />
<br />
There have been reports of problems building ITK on IRIX platform. Here are the compiler flags that are used to build ITK and submit nightly dashboard results. SGI Flags for both 7.3.3.1m and 7.4.2m compilers that are working for the kraepelin.uiowa nightly builds.<br />
<br />
DEBUG BUILD:<br />
//No help, variable specified on the command line.<br />
CMAKE_CXX_FLAGS:STRING= -n32 -g -DUDEBUG -G0 -multigot -no_auto_include -xansi -LANG:std -LANG:ansi-for-init-scope=ON -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
//No help, variable specified on the command line.<br />
CMAKE_C_FLAGS:STRING= -n32 -g -DUDEBUG -G0 -multigot -xansi -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
OPTIMIZED BUILD:<br />
CMAKE_CXX_FLAGS:STRING= -n32 -O3 -DNDEBUG -G0 -multigot -no_auto_include -xansi -LANG:std -LANG:ansi-for-init-scope=ON -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
//No help, variable specified on the command line.<br />
CMAKE_C_FLAGS:STRING= -n32 -O3 -DNDEBUG -G0 -multigot -xansi -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
== Contribute ==<br />
=== How do I make code contributions to ITK? ===<br />
Please see this page: [[ITKContribute]].<br />
<br />
== Testing ==<br />
=== Is ITK tested? ===<br />
Please see this page: [[ITK/Testing]]<br />
<br />
== Working with Image Data ==<br />
<br />
===How do I iterate through all the pixels in an image?===<br />
<br />
Please see this example: http://www.itk.org/Wiki/ITK/Examples/Iterators/ImageRegionIterator of itkImageRegionIterator.<br />
<br />
===What are Hounsfield Units?===<br />
<br />
Hounsfield units were defined by Sir Godfrey N. Hounsfield, on of the pioneers of Computer Tomography for clinical applications.<br />
<br />
The units represent the linear attenuation of X-Rays for a particular material. <br />
<br />
The units scale is defined in such a way that level for Water is 0 and the level for Air is -1000. <br />
<br />
The attenuation of any other material is mapped linearly into this range.<br />
<br />
A table of Hounsfield units for common human tissues is avalable in the following link [[ITK Hounsfield Units]]<br />
<br />
===What are MRI T1 / T2 Units?===<br />
<br />
MRI images measure two types of relaxation times. <br />
<br />
The units are millisecons and the two relaxation concepts relate to how long it takes for the molecules in the tissue to realign themselves with a magentic field after being perturbed.<br />
<br />
Details on the MRI units are available in the Wikipedia:<br />
<br />
[http://en.wikipedia.org/wiki/Relaxation_%28NMR%29 Relaxation (NMR)]<br />
<br />
=== DICOM: Bits Allocated, Bits Stored and High Bit ===<br />
<br />
A question that is often asked on insight-users is :<br />
I am trying to read/write a DICOM image, but some of the DICOM fields have changed after I write it back on disk.<br />
<br />
Here is what you have on disk:<br />
<pre><br />
Bits Allocated = 16<br />
Bits Stored = 12<br />
High Bit = 11<br />
<br />
|<------------------ pixel ----------------->|<br />
______________ ______________ ______________ ______________<br />
|XXXXXXXXXXXXXX| | | |<br />
|______________|______________|______________|______________|<br />
15 12 11 8 7 4 3 0<br />
</pre><br />
<br />
Here is what you generally get after writing by GDCM:<br />
<pre><br />
Bits Allocated = 16<br />
Bits Stored = 16<br />
High Bit = 15<br />
<br />
|<------------------------- pixel ------------------------>|<br />
______________ ______________ ______________ ______________<br />
| | | | |<br />
|______________|______________|______________|______________|<br />
15 12 11 8 7 4 3 0<br />
</pre><br />
<br />
Since DICOM V3, you '''cannot''' store any overlay in the unused bits of the Pixel Data (0x7fe0,0x0010), thus it imply that the unused bits are '''zeros'''.<br />
In ITK, there is no such thing as 12bits Pixel Type, thus when instanciating your reader you declare a 16bits Pixel Type. This buffer is then passed back to GDCM which sees an array of 16bits values and then simply used the simpliest way to store this buffer back on disk: Bits Stored = 16 and High Bit = 15.<br />
In case you have not made any change to your pixel buffer, implicitely the first 4 bits will be zero again. The only difference being that they are not as clearly declared as 12bits.<br />
<br />
=== I'm working with DICOM images, where can I find more information? ===<br />
[[ITK/DICOM]]<br />
<br />
== Data Display ==<br />
<br />
===What imaging software is available for displaying medical image files?===<br />
<br />
Please see the [[ITK/Third_Party_Applications | third party applications]] page for visualization applications that used ITK to perform Image reading/writing.<br />
<br />
===When I view the output of my program, all I see is a black image. What went wrong?===<br />
<br />
ITK is capable of reading and writing data in a variety of formats and bit depths. However many 'consumer' image programs only work with 8-bit data, so when you try to display a 16-bit data file the image will appear black. The solution is to use an image display program that correctly handles these types of files. A small selection is listed above.<br />
<br />
[http://www.imagemagick.org/ ImageMagick] is a particularly useful set of tools for image display, manipulation and conversion.<br />
<br />
The `ImageViewer` program, part of InsightApplications, is capable of correctly loading and displaying all file types supported by ITK (including anisotropic images).<br />
<br />
(Gavin Baker, 24-Jun-2004)<br />
<br />
== Registration ==<br />
<br />
===Can ITK be used for multi-modal registration? For example, CT-MRI, or MRI-fMRI?===<br />
<br />
ITK provides several method for performing Multi-Modality registration. These methods are described in detail in the SoftwareGuide Chapter 8, pdf-page 241 to 340. In particular you will find interesting Section 8.4 in pdf-page 255 where the Mutual Information metrics are described.<br />
<br />
Examples on multimodality registration are available in `Insight/Examples/Registration`. A demo application using Mutual Information is available under `InsightApplications/LandmarkInitializedMutualInformationRegistration`.<br />
<br />
It is strongly recommended that you read the chapter on image resampling (Section 6.9.4 of the pdf) before you get involved with image registration methods. That will save you a lot of misunderstandings that are common in new users.<br />
<br />
You will also find useful the tutorial sessions, in particular [http://www.itk.org/CourseWare/Training/RegistrationMethodsOverview.pdf the overview].<br />
<br />
(Luis Ibanez, 7-June-2004)<br />
<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/Job_Opportunities&diff=55977ITK/Job Opportunities2014-03-31T11:00:36Z<p>Jhlegarreta: Page structure/organization reworking; created current/past positions sections</p>
<hr />
<div>Please feel free to post announcements for jobs and positions that are related to ITK and applicants with ITK experience. Once the position has been fulfilled, please update the entry accordingly.<br />
<br />
Please note that they are '''listed according to their post date''', and not their deadline, as this information is missing in some cases. Past positions are kept for the sake of maintaining a small history of them.<br />
<br />
= Current positions (2014) =<br />
<br />
<br />
<br />
= Past positions =<br />
<br />
<br />
== Year 2013 ==<br />
<br />
<br />
=== Internship position for developing a MR CAD tool ===<br />
Posted: Oct. 29th 2013<br />
<br />
Eigen is making a difference in patient outcomes and care with our innovative medical imaging products, and we’re looking for a software engineer to join our team.<br />
ProFuse, our MRI image fusion product, is being used on patients daily to provide accurate, repeatable biopsies, with the assistance of Eigen’s mechanical guidance. We have a list of improvements in mind to make the system even better, and that’s where you can help us. We need a quality-focused software intern who’s familiar with C++ - if you know the QT framework, so much the better. You’ll be working with our existing team to add features, and lay the foundation for our next generation of products.<br />
<br />
Requirements:<br />
-In progress degree in Computer Science, Mathematics, Physics, Engineering, Medical Imaging or related discipline.<br />
-UI/UX programming experience.<br />
-Strong interpersonal and communication skills.<br />
-Knowledgeable and experienced with C++ language.<br />
<br />
Desirable but not required:<br />
-Experience with medical devices, avionics, or other regulated technical products.<br />
-Familiarity with ITK and VTK libraries.<br />
-Experience with CMake build system.<br />
-Image processing background strongly preferred.<br />
-Strong mathematics background.<br />
-GPU programming experience (CUDA).<br />
<br />
This is a 6 month internship, on-site at our Grass Valley, CA location, but could lead to a full time W2 position.<br />
<br />
Please send your resumes to hr@eigen.com.<br />
<br />
=== PhD position in multi-modal image processing, b<>com Brest, France ===<br />
<br />
Posted: Oct. 28th 2013<br />
<br />
It is increasingly common to combine multiple methods of treatment, i.e., treatment modalities, with the intention to improve patient outcomes and reduce complications. Each treatment modality may consist of (1) multiple images acquired by one or more modalities (e.g. PET and CT) and (2) contextual information (e.g. clinical reports). To improve patient outcome, one approach is to unify the imaging information and the context information so that the therapy planning, therapy guidance and post-treatment evaluation are simplified. In practice, whereas Picture Archive and Communication Systems (PACS), employed in hospital, store multi-modal images and contextual information, simultaneous re-use of both information cannot be done in a simple fashion.<br />
<br />
This Ph.D. will focus on the integration of multi-modal imaging information accrued by contextual information extracted from a PACS.<br />
<br />
A first problem to address is the analysis of multi-modal images (e.g., PET/CT). This analysis requires, for example, image processing (image quality improvement or image artifact reduction) followed by image analysis (segmentation or biomarker extraction). A second problem to investigate is the association of quantitative parameters extracted from multi-modal images with other contextual information. This also involves the automatic generation of clinical reports both associating results of multi-parameter image analysis and contextual information, with the goal of assisting physicians with clinical decisions. It is intended that this Ph.D. will lead to a Clinical Decision Support System demonstrator dedicated to a specific context/pathology (e.g. oncology or neurology).<br />
<br />
The PhD fellowship is funded by b<>com (http://b-com.com) which is a Technology Research Institute located in Brest, Rennes and Lannion (France). This Ph.D thesis will be carried out under the supervision of M. Hatt (research associate, INSERM) and G. Coatrieux, Assistant Professor (Telecom Bretagne) and located at b<>com on the Brest-Iroise Science and Technology Park.<br />
<br />
Expected qualifications:<br />
- Minimum MSc degree (Computer Science)<br />
- Experience in developing medical imaging applications is desirable<br />
- Prior experience in image analysis, pattern recognition and computer vision<br />
- Programming experience in C++<br />
<br />
Contact: Please send your resume to job@b-com.com<br />
<br />
== Year 2012 ==<br />
<br />
=== Technology Officer in Biomedical Image Computing & Modelling, University of Sheffield, UK ===<br />
<br />
''' Computational Imaging and Simulation Technologies in Biomedicine (CISTIB), University of Sheffield, UK ''' <br />
<br />
Posted: Nov 5th 2012 \<br />
Closes: Nov 21st 2012<br />
<br />
''* About Sheffield ''<br />
<br />
Mechanical Engineering has been a major discipline in the University of Sheffield since its foundation in 1905. In the most recent Research Assessment Exercise the Department came second in the country in the league table of Mechanical Engineering departments, and achieved an "Excellent" rating in the last Teaching Quality Assessment. The Department currently has 41 members of academic staff who support the learning and development of an ever-growing undergraduate and postgraduate student body. For more information on the Department please see our web site http://www.shef.ac.uk/mecheng/.<br />
<br />
The INSIGNEO Institute for in silico Medicine is an initiative between the Faculty of Engineering and the Faculty of Medicine at the University of Sheffield and the Sheffield Teaching Hospitals Foundation Trust. INSIGNEO will realise the scientific ambition behind the Virtual Physiological Human (VPH), producing a transformational impact on healthcare. INSIGNEO performs cutting edge research in areas of fundamental and applied biomedical modelling, imaging and informatics. It will pursue the research agenda of the VPH initiative; in particular, in the first five years it will focus on the Digital Patient, In Silico Clinical Trials, and Personal Health Forecasting. It will achieve transformational impact on healthcare through multidisciplinary collaboration in strategic areas, which initially will include personalised treatments and independent, active and healthy ageing.<br />
<br />
The Computational Imaging and Simulation Technologies in Biomedicine (CISTIB) Group at the University of Sheffield is part of INSIGNEO. CISTIB focuses on algorithmic and applied research in the areas of computational imaging, modeling and simulation. CISTIB is working in different areas of medical image segmentation, statistical shape analysis, pattern recognition and image-based personalized computational electro-mechanics and fluid dynamics, and modeling of virtual interventions with endovascular and cardiac rhythm management devices. The centre hosts academic members from the University of Sheffield as well as research fellows, research associates, PhD Students and scientific software developers forming a cross-disciplinary team of biomedical engineers, computer scientists, electrical engineers, mechanical engineers, physicists, and mathematicians. <br />
<br />
The main objective of CISTIB is to contribute to the development of technologies for advanced screening, diagnostics, interventional guidance and therapy planning of cardio- and neurovascular diseases as well as growing activity in the musculo-skeletal system. Converging technologies such as computational imaging, computational physiology and virtual implantation of medical devices are integrated with state of the art multimodal acquisition systems to achieve an enhanced interpretation of human physiology and pathology and supply integrative approaches for in silico medical device customization, optimization and image-based efficacy assessment. Core technologies include spatial and temporal image segmentation, non-rigid image registration, multimodal image fusion, pattern recognition, statistical shape analysis, multi-view geometry, image-based tissue property estimation, tissue deformation quantification, computational geometry, image-based mesh generation, computational fluid dynamics and electro-mechanical simulation.<br />
<br />
CISTIB fosters basic and applied research and promotes technology transfer to industry. It participates to a number of national and international research projects funded by the European Commission, and holds collaborations with several national and international companies. CISTIB also very close cooperation with clinical centers at the local level and worldwide and has a strong clinically-oriented translational vision.<br />
<br />
'' * Open positions ''<br />
<br />
You will lead and coordinate a team of Scientific Software Developers that will produce prototypes for applied research projects, clinical translation projects, and technology assessment studies. Your work will also support the research program within CISTIB by enabling its researchers to effectively implement new methods and algorithms. Those prototype technologies that are found to be effective will be translated into commercially available products and services, by means of IPR exploitation agreements with existing companies, or by creating dedicated spin-off companies. The ideal candidate has a considerable experience in managing Technical teams. Previous experience in the area of software development related to the Virtual Physiological Human initiative would be an advantage. Your skill set should be properly balanced between experience on research projects and software management to act as an interface between the needs of the technological and clinical researchers of the centre, and the software developers. All development activities should be steered toward the establishment of a portfolio of methods and technologies (i.e. libraries, software frameworks, etc.). You will play a key role in attracting significant research and technological development funding, in collaboration with other CISTIB members, both from public and private sources.<br />
<br />
We are interested in individuals with excellent communication and leadership skills, able to work in a multidisciplinary and international team and contribute to the visibility of the centre in the international scientific community. The ability to interact with other disciplines is essential. The candidate will cooperate with members of the lab working on related topics as well as with our collaborators at several academic institutions in UK and across Europe.<br />
<br />
'' * How to apply ''<br />
<br />
More information and application through http://sheffield.ac.uk/jobs reference UOS005565.<br />
<br />
=== Job - Software Engineer in medical image processing (medInria) - INRIA Rennes - France ===<br />
<br />
Posted June 26, 2012<br />
<br />
R&D Experienced software engineer / Good knowledge of ITK, VTK and Qt<br />
<br />
As part of the development of medInria ([http://med.inria.fr med.inria.fr]), we are proposing a new position for an experienced engineer at Inria Rennes, France (Visages team), starting from october 2012. The recruited person will work among the national team developing medInria, to develop core features and specific medical image processing plugins from the Visages team. More details on the position are available on [https://www.irisa.fr/visages/_media/positions/position_medinria_nt_2012.pdf the position sheet].<br />
<br />
<br />
=== Job - Software Engineer / Research Specialist Lead - Emory University / Georgia Tech ===<br />
<br />
Posted June 8, 2012<br />
<br />
Research Specialist Lead / Software Engineer<br />
<br />
This position offers great opportunities to work in a high-quality academic environment at Emory University and Georgia Institute of Technology, Atlanta, Georgia, USA. The joint Department of Biomedical Engineering (BME) of Emory University and Georgia Institute of Technology provides one of the top BME programs to foster the next generation of leaders in biomedical engineering worldwide. The Department of Radiology and Imaging Sciences at Emory University School of Medicine provides one of the best education, training and research programs in the country. Successful applicant would work under the supervision of the principal investigator and will collaborate with other faculty members, clinicians, researchers, post-doctoral fellows, graduate and undergraduate students in a research team. This person would be involved in projects focused on multimodality medical imaging (ultrasound, PET/CT, and MRI) with emphasis on medical image analysis and image-guided interventions. As a regular staff of Emory University, this person and her/his family would be eligible for a full range of Emory benefits including health and dental insurance, tuition, and other benefits. <br />
<br />
JOB DESCRIPTION: Under minimal supervision, modifies and writes software programs for image processing and analysis. Develops requirements and specifications and implements computer algorithms in software programs. Performs image quantification using commercial software systems or home-made software programs. Uses independent judgment in applying or adapting scientific techniques. Assists in planning and scheduling research procedures. Performs a variety of laboratory tests and procedures. Analyzes and interprets results of studies. Reviews literature for related research developments and techniques and compiles findings. Monitors laboratory processes to maintain quality assurance standards. Records results of studies, compiles and analyzes data and prepares charts and graphs. Performs related responsibilities as required. <br />
<br />
MINIMUM QUALIFICATIONS: Bachelor's or Master’s degree in computer science, mathematics, electrical engineering, biomedical engineering, or other related fields, and two years of working experience, or equivalent combination of experience, education, and training. Two years of experience in software programming is required. Programming experience with IDL, C++, and MATLAB is preferred. Basic knowledge in medical image processing and analysis is required. Knowledge in medical imaging such as MRI, PET, CT, and ultrasound is a plus but not required. <br />
<br />
CONTACT:<br />
Baowei Fei, PhD, EngD,<br />
Georgia Cancer Coalition Distinguished Scholar<br />
Director of Quantitative BioImaging Laboratory (QBIL)<br />
Emory University and Georgia Institute of Technology<br />
1841 Clifton Road NE, Atlanta, GA 30329, USA<br />
Email: bfei@gatech.edu<br />
<br />
<br />
To apply for the position, send CV and Personal Statement to bfei@gatech.edu <br />
<br />
<br />
== Year 2011 ==<br />
<br />
=== ITK-SNAP Software Developer - University of Pennsylvania ===<br />
<br />
Posted Dec 5, 2011<br />
<br />
The Penn Image Computing and Science Laboratory (PICSL) seeks a qualified C++ programmer to support the development of ITK-SNAP, an interactive software application for biomedical image segmentation. The programmer will work with the principal investigator on an NIH-funded grant to develop the next-generation GUI for ITK-SNAP, accelerate the tool=92s performance, and incorporate multi-modality image segmentation algorithms. Applicants must have a Bachelors degree in computer science or related field. Minimal qualifications are<br />
<br />
* C++ programming (4 years experience)<br />
* Experience with user interface programming, preferably Qt<br />
* Strong interpersonal and communication skills, and ability to work<br />
independently<br />
<br />
Applicants with expertise in the following ares are particularly encouraged to apply:<br />
<br />
* Familiarity with ITK and VTK libraries, and CMake build system<br />
* Image processing, computer vision, and computer graphics<br />
* Strong mathematics background<br />
* GPU programming experience (CUDA, OpenCL)<br />
* Experience working in a research environment<br />
* Advanced degree in related field<br />
<br />
PICSL is a dynamic and growing research group involved in many exciting biomedical imaging projects, including development of novel analysis methodologies; application of the state-of-the-art techniques to clinical studies; and translational research. PICSL is located in Philadelphia, a vibrant city that offers many professional and cultural opportunities. PICSL fosters a friendly, noncompetitive, collaborative environment where each individual member of the laboratory is able to thrive, while also effectively contributing to the group=92s overall programmatic aims.<br />
<br />
The position is funded by a federal grant. Continued employment is subject to performance and availability of grant funding. PICSL has an excellent track record of obtaining research funding and personnel retention. The position features a competitive compensation package with generous fringe benefits.<br />
<br />
The University of Pennsylvania is an equal opportunity, affirmative action employer. Women and minority candidates are strongly encouraged to apply.<br />
<br />
Interested candidates should send an email to the address below. Please include the words =93snap developer=94 on the subject line. Include a brief statement of qualifications relevant to the project, a CV or resume, and a list of 3 references.<br />
<br />
Paul Yushkevich, Ph.D.<br />
Assistant Professor<br />
Penn Image Computing and Science Laboratory (PICSL)<br />
Department of Radiology<br />
University of Pennsylvania<br />
<br />
Email: pauly2 [at] mail [.] med [.] upenn [.] edu<br />
http://picsl.upenn.edu<br />
http://itksnap.org<br />
<br />
<br />
=== Software Engineer(s)-Electrical Geodesics, Inc. ===<br />
<br />
Electrical Geodesics, Inc. (www.egi.com), an international medical device company in the neurology/neuroscience field, is seeking to fill “three” software engineer position. The Software Engineer is responsible for software related product development, product engineering activities, and grant support.<br />
<br />
Opening 1Requirements:<br />
• Bachelor's degree in Computer Science, Mathematics, or strongly related field<br />
• C++ (Objective-C a plus)<br />
Make, CMake, and other build environment expertise.<br />
<br />
• VTK, ITK, Tcl/Tk<br />
<br />
Desired Experiences:<br />
<br />
• MRI Processing<br />
• Cross platform development (Mac, Linux, Windows) experience a plus.<br />
<br />
Opening 2 Requirements:<br />
• Bachelor's degree in Computer Science, Mathematics, or strongly related field<br />
• 2 years experience in a multi-platform environment.<br />
• Java, C, C++ (Objective-C a plus).<br />
<br />
Opening 3 Requirements:<br />
• Bachelor's degree in Computer Science, Mathematics, or strongly related field<br />
• 2 years experience in a multi-platform environment.<br />
• Java (principle), C, C++ (Objective-C a plus)<br />
• Strong knowledge of application server environments.<br />
• Strong profiency in database engineering, and demonstrable knowledge of SQL.<br />
• Experience with Netbeans or Eclipse (and comfortable to use either).<br />
<br />
Full Time, exempt, salary position with benefits.<br />
<br />
To apply for any of the above openings, resume and cover letter should be sent to dmarquez@egi.com<br />
<br />
<br />
=== Master training position, INRIA Sophia Antipolis, France: Prediction of Cardiac Electrophysiology Signal Characteristics from Image Features ===<br />
<br />
<br />
The aim of this project is to analyse both cardiac images and electrophysiology signals in order to explore correlations. Developped features will be mapped on a 3D mesh and overlaid on anatomical images of the heart in order to guide interventions. This project will require image analysis, registration for correlating anatomical and functional information, and machine learning. This project will be in collaboration with Bordeaux University Hospital.<br />
<br />
More information can be found in the detailed job description: <br />
<br />
http://www-sop.inria.fr/asclepios/recrutement/MasterTrainingINRIA2011.pdf<br />
<br />
<br />
== Year 2010 ==<br />
<br />
=== Postdoctoral Position: MIT/Harvard Medical School, Cambridge/Boston, MA ===<br />
<br />
* Posted on December 3rd 2010<br />
<br />
Location: Cambridge/Boston, MA<br />
Type: Postdoctoral position in Medical Robotics<br />
Expires:January 01, 2011<br />
<br />
Job description: We are currently seeking an engineer/computer scientist to join our dynamic team that is developing image-guided robots for accurate and efficient tumor ablation. The person will ideally have medical image processing experience and will be developing user interfaces for controlling robots using information in the medical imaging data.<br />
<br />
Our group involves a collaboration between the Massachusetts Institute of Technology, Massachusetts General Hospital and Brigham and Women's Hospital and has a large amount of technical and clinical expertise in this area.<br />
<br />
Information regarding the open positions and desired qualifications can be provided upon request. Graduate students, post-doc and recent graduates will all be considered. Interested candidates should send a CV and a brief paragraph along to Dr. Conor Walsh at walshcj@mit.edu.<br />
<br />
<br />
=== Two Postdoctoral Positions: Harvard Medical School, Boston, MA ===<br />
<br />
* Posted on November 30th 2010<br />
<br />
Website:http://http://vcp.med.harvard<br />
Location: Boston, MA<br />
Type: Postdoctoral<br />
Expires:January 22, 2011<br />
<br />
Job description: Applications are invited for two postdoctoral-level positions on a collaborative project funded by the European Human Frontiers Programme between the laboratories of Alfonso Martinez-Arias in the Department of Genetics at the University of Cambridge, UK, Kat Hadjantonakis in the Developmental Biology Program at Memorial Sloan Kettering Cancer Center in New York and Jeremy Gunawardena in the Department of Systems Biology at Harvard Medical School in Boston. The project centres on analysing signalling and gene regulation networks in the pre-implantation mouse embryo and in mouse embryonic stem cells, using quantitative measurements, 4D whole-embryo imaging, microfluidic devices and mathematical modelling. The first position is with Hadjantonakis in New York to develop a quantitative image analysis platform for 4D mouse embryo imaging. The successful applicant will need strong technical capabilities in live-cell image analysis, familiarity with software tool development with a focus on usability and the desire to work in close collaboration with experimentalists. The second position is with Gunawardena in Boston to analyse mouse ES cells using microfluidic devices and modelling. The successful applicant will have experience studying mammalian cells in culture using quantitative experimental methods, an interest in exploiting microfluidic technologies and an ability to work with mathematical models of molecular networks. Both positions will require occasional travel between the sites and an annual visit to Cambridge, UK. Interested candidates are asked to send a CV and the contact details of two referees to one of the two addresses below, along with a cover letter stating clearly why his or her background is appropriate for the corresponding position. The deadline for applications is 31 December 2010.<br />
<br />
Kat Hadjantonakis<br />
Developmental Biology Program<br />
Sloan-Kettering Institute<br />
New York, NY 10065,<br />
USA<br />
http://www.ski.edu/hadjantonakis<br />
<br />
Jeremy Gunawardena<br />
Department of Systems Biology<br />
Harvard Medical School<br />
200 Longwood Avenue<br />
Boston, MA 02115<br />
USA<br />
<br />
By e-mail to Nicole Wong, Nicole_Wong@hms.harvard.edu<br />
<br />
http://vcp.med.harvard.edu/<br />
<br />
=== Research Scientist (Junior) - Image and Signal Processing - Rennes,France ===<br />
<br />
* Posted on September 14th 2010<br />
<br />
Bruce Junior Chair position<br />
<br />
http://www.rbucewest.ueb.eu/<br />
<br />
R-Buce Junior Chair position in Biomedical Engineering.<br />
<br />
The UEB - UR1 seeks research scientist applicants working in the broad field of biomedical engineering, with particular focus on themes at the frontiers of ICT and health. Of special interest are the following topics: model-based bio-signal / bio-imaging processing and interpretation, integrative modeling, knowledge-based information representation and interpretation.<br />
<br />
The UEB - UR 1 laboratories involved in biomedical engineering have strong clinical partnerships with a number of medical institutions, including the Rennes University Hospital and the Centre of Cancer Eugène Marquis at Rennes.<br />
<br />
Qualified candidates working in the broad area of biomedical engineering, developing computational tools or multiscale systems-based techniques are encouraged to apply. Required qualifications include a doctorate in engineering or a related field with an outstanding record of publications in internationally recognized journals.<br />
<br />
Interested persons should submit detailed curriculum vitae including academic and professional experience, a list of peer-reviewed publications and any other technical documents relevant to the application.<br />
<br />
salary range : ~40kE/year + relocation<br />
<br />
Please send cover letter and resume to Oscar Acosta / Lotfi Senhadji <br />
(Oscar.Acosta@univ-rennes1.fr, Lotfi.Senhadji@univ-rennes1.fr) <br />
<br />
<br />
== Year 2009 ==<br />
<br />
=== Software Engineer (Junior) - Harvard Medical School ===<br />
<br />
* Posted on August 14th 2009<br />
<br />
The Megason Laboratory in the Department of Systems Biology at Harvard Medical School seeks to hire a Software Engineer for participating in the continued development of GoFigure. The lab’s goal is to understand embryonic development as the execution of a program in our genome. We seek to upload embryonic development into a virtual life form called the Digital Fish through the use of genetics, molecular imaging, and information technology (www.digitalfish.org). The Software Engineer will be responsible for participating in the continued development of the principle software application for this endeavor called GoFigure. GoFigure recognizes and tracks cells in extremely large 4-dimensional (xyzt) image sets and digitizes that data into a database. GoFigure is written in C++, is cross-platform and uses Qt, MySQL, VTK (the Visualization Toolkit), ITK (Insight Segmentation and Registration Toolkit), CMake. The project is managed using Subversion, Doxygen for documentation generation, CTest and CDash for testing. The successful applicant should have a strong background in programming and work well in an academic environment. Interests in application development, image processing, microscopy, and systems biology are also a plus.<br />
<br />
'''Job Duties'''<br />
<br />
* Participate in software development project for GoFigure. GoFigure is developed by a team of ~4 which is lead by a Senior Research Engineer<br />
* Responsible for the development and testing of code as specified by management (senior software engineer and lab director). Incumbent will write code and will assist management in integration of code into GoFigure<br />
* Performs ongoing modifications and solution alternatives to accomplish research requirements of GoFigure software<br />
* Collaborates with researchers to define new strategies, approaches, methods and techniques to enhance research efforts<br />
* Participate in regular lab meetings, journal club presentations, and retreats<br />
* Other duties as assigned<br />
<br />
Please send cover letter and resume to Sean Megason<br />
(megason@hms.harvard.edu) <br />
<br />
=== Computer Programming - Image Guided Intervention ===<br />
<br />
* Posted Aug 2009,<br />
<br />
Department of Medicine at Harvard Medical School and Beth Israel Deaconess Medical Center is looking to hire a full time software engineer with strong background in computer vision and ITK/VTK. Intrested applicant should send a CV to :<br />
<br />
Reza Nezafat, Ph.D. rnezafat@bidmc.harvard.edu<br />
<br />
<br />
== Year 2008 ==<br />
<br />
=== Staff Scientist - Medical Image Processing ===<br />
<br />
* Posted: November, 2008<br />
<br />
The Department of Radiology is seeking a Staff Scientist to support our research and clinical efforts in image processing (virtual endoscopy, volumetric visualization, segmentation, registration and algorithm development) and computer-aided diagnosis (feature extraction, classification, database development). In particular, advanced skills in image segmentation (level sets, active shape/appearance models, etc.) and machine learning are sought. The incumbent will work closely with a team of computer scientists and engineers. Applicants with a proven track record as evidenced by peer-reviewed publications on medical applications of image processing and having advanced mathematical and computer skills are encouraged to apply. Demonstrated expertise in C++ and ITK (NLM’s Insight Toolkit) are required. The candidate should have a Ph.D. in Computer Science, Electrical or Biomedical Engineering, Mathematics, Biophysics or Physics. Salary commensurate with experience. Applications should include a CV, brief statement of research interests, and three letters of reference. Applications are due 4 weeks after posting of this announcement. DHHS and NIH are Equal Opportunity Employers.<br />
<br />
Address applications to:<br />
<br />
Ronald Summers, M.D., Ph.D.<br />
Chief, Clinical Image Processing Service <br />
and Virtual Endoscopy and Computer-Aided Diagnosis Laboratory<br />
Radiology and Imaging Sciences<br />
National Institutes of Health Clinical Center<br />
Building 10 Room 1C368X MSC 1182<br />
Bethesda, MD 20892-1182<br />
E-mail: rms@nih.gov<br />
Web site: http://www.cc.nih.gov/drd/summers.html<br />
<br />
<br />
=== Research Developer - Medical Imaging ===<br />
<br />
'''About Calgary Scientific'''<br />
<br />
Calgary Scientific Inc. (CSI) is a software and intellectual property (IP) development company specializing in sophisticated digital signal, image processing and analysis technology. Our current product line includes customer focused applications for medical imaging and seismic data imaging. These applications offer innovative tools to help professionals to better interpret and analyze data through core innovations around which CSI applications are developed.<br />
<br />
Calgary Scientific is a privately held company with offices in Calgary, Alberta, Canada. The company was formed in 2003 to commercialize leading edge intellectual property into market leading software applications.<br />
<br />
Calgary Scientific works with research teams and individuals across multiple Universities to generate, refine, test, and commercialize breakthrough innovation into market driven commercial applications.<br />
<br />
'''Research Developer – Medical Imaging Role'''<br />
<br />
We are looking for several full-time Research Developers with Medical Image Processing skills who are willing to relocate to Calgary, Alberta, Canada. Duties will include:<br />
<br />
* Incorporating cutting edge research code from around the world into our production quality, C++ core technologies<br />
<br />
* Working with Research Scientists and Research Associates on various medical image processing algorithms<br />
<br />
* Working with QA to design and develop unit and validation tests that meet our ISO 13485 and ISO 14971 requirements<br />
<br />
* Working directly with Agile Product Teams to ensure the rapid integration of new technologies into various medical applications<br />
<br />
This is an excellent opportunity to contribute to the commercialization of market-driven medical imaging applications.<br />
<br />
'''Required Experience/Skills:'''<br />
<br />
* Degree in Engineering, Physics, Computer Science, or related fields<br />
<br />
* 5 or more years of experience in C++ development<br />
<br />
* 1 or more years of matlab and OpenGL experience<br />
<br />
* Applied or advanced math training, particularly in medical image processing or artificial intelligence<br />
<br />
* Demonstrated ability to learn new technologies<br />
<br />
* Desire to contribute to the successful commercialization of leading-edge technology<br />
<br />
'''Beneficial Experience/Skills:'''<br />
<br />
* Algorithm development using ITK<br />
<br />
* Working within an ISO certified environment<br />
<br />
Applications can be sent to careers@calgaryscientific.com<br />
<br />
Please see http://www.calgaryscientific.com/company/careers.html for additional opportunities.<br />
<br />
=== Post-doctoral Research Openings at Rensselaer Polytechnic Institute ===<br />
<br />
The FARSIGHT project has openings for several post-doctoral associates (or experienced individuals with a Masters degree), starting May 1, 2008. This project is developing an open-source 4-D/5-D image analysis toolkit for advanced biological microscopy of brain tissue, tumors, and immune system components. The required skills include <br />
<br />
* High-quality C++ programming, <br />
* 3-D image processing (segmentation, classification, registration), and <br />
* 3-D graphics programming. <br />
<br />
Prior exposure to ITK and/or VTK, and disciplined software development processes is highly desirable. <br />
<br />
These positions are renewable annually. <br />
<br />
Please contact <br />
Prof. Roysam <br />
by email: Roysam@ecse.rpi.edu.<br />
<br />
Badri Roysam<br />
Professor, Department of Electrical, Computer and Systems Engineering<br />
Associate Director, NSF Center for Subsurface Sensing & Imaging Systems (CenSSIS ERC)<br />
Rensselaer Polytechnic Institute<br />
110 8th Street, Troy, New York 12180-3590.<br />
Office(JEC 7010): 518-276-8067, Lab(JEC 6308): 518-276-8207, Fax: 518-276-8715<br />
Web: http://www.ecse.rpi.edu/~roysam<br />
<br />
=== Senior Developer - Medical Image Processing ===<br />
<br />
Status: Filled<br />
<br />
Please see http://www.calgaryscientific.com/company/careers.html for additional opportunities.<br />
<br />
<br />
=== Software Engineer, Intuitive Surgical Inc., Sunnyvale California ===<br />
<br />
The da Vinci(r) Surgical system includes six manipulator arms with a total of 41 degrees of freedom, along with a stereo endoscope and 3D video display, with over 600 installations worldwide. Surgeons use it to perform tens of thousands of minimally invasive surgeries per year. da Vinci represents an outstanding platform for the development and application of new technologies to surgery. This position offers an opportunity for a candidate with exceptional software development skills to work on projects ranging from blue-sky research to those ready for transition to product development groups. A successful candidate will be equally comfortable leading architecture development and producing high-quality implementations that lend themselves to re-use, testing, and productization. He or she must excel in a high energy team, must have excellent communication skills and must be able to balance independent production of results with the need to collaborate during planning, system integration, and testing of larger projects. This engineer will work closely with other members of the Applied Research Group and several product development groups on algorithm development, implementation, and systems integration.<br />
<br />
For more details, as well as to upload a resume, please visit our OpenHire listing:<br />
* Position: Software Engineer<br />
* Tracking Code: 220333-609<br />
* Posted: November, 2007<br />
* URL: http://hostedjobs.openhire.com/epostings/jobs/submit.cfm?fuseaction=dspjob&id=23&jobid=220333&company_id=15609&version=1&source=ONLINE&JobOwner=956377&level=levelid1&levelid1=10630&parent=Engineering&startflag=2&CFID=8647986&CFTOKEN=46344848<br />
<br />
<br />
=== Research Scientist Position in Medical Imaging in Brisbane, Australia ===<br />
<br />
CSIRO ICT centre is seeking to fill several positions at the scientist and post-doctoral level to work on neuro-degenerative diseases and brain tumour characterization.<br />
The Biomedical Imaging team part of the Australian e-Health Research centre is a leading Australian medical imaging research group, with a well developed expertise in image registration, extraction of quantitative information (shape, volume, texture), morphometry, soft-tissue modelling (3D meshing, visual and haptic interaction) and data classification. The successful applicants will be involved in activities focused on the development and application of novel techniques for segmentation, registration and analysis of PET and MR images. These positions offer the opportunity to work in a high quality research environment, with strong clinical collaboration. The research scientists and post-doctoral fellows will join a large team (>20 scientists, post-doctoral fellows, and students) in an exciting working environment ideally located in one of the fastest growing city in Australia close to many attractions and beautiful beaches.<br />
More details can be found on the CSIRO career website: <br />
https://recruitment.csiro.au/asp/job_details.asp?RefNo=2008%2F487<br />
https://recruitment.csiro.au/asp/job_details.asp?RefNo=2008%2F9<br />
For further information please contact <br />
Olivier Salvado, PhD<br />
Team Leader Biomedical Imaging<br />
olivier.salvado@csiro.au<br />
<br />
CSIRO ICT Centre<br />
Australian e-Health Research Centre (AEHRC)<br />
Phone: +61 7 3024 1658<br />
Fax: +61 7 3024 1690<br />
Mobile: +61 4 0388 2249<br />
web: http://www.aehrc.net/<br />
<br />
== Year 2007 ==<br />
<br />
=== Summer 2007: National Institutes of Health Postdoc ===<br />
<br />
Post-doctoral fellowships are available in clinical image processing. Specific interest areas are image processing (virtual endoscopy, volumetric visualization, image segmentation, registration, fusion, and algorithm development) and computer-aided diagnosis (feature extraction, classification, and databases). Fellows have access to state-of-the-art whole body MRI, multi-row detector CT and advanced graphics workstations. Candidates must have or soon expect to receive doctorates in applied mathematics or computer science. Applicants with a proven track record as evidenced by peer-reviewed publications on image processing or computer visualization and having strong software development and C++ skills are encouraged to apply. Initial appointment is for two years and is renewable thereafter on a periodic basis. NIH is an equal opportunity employer.<br />
<br />
Address applications to: <br />
Jianhua Yao, Ph.D. <br />
Clinical Image Processing Service <br />
Department of Radiology <br />
National Institutes of Health <br />
10 Center Drive Bethesda, MD 20892-1182 <br />
E-mail: jyao@cc.nih.gov <br />
<br />
<br />
=== August 2007 to sept. 2008: Caltech & Harvard Medical School ===<br />
<br />
The Caltech Center of Excellence in Genomic Science (CEGS) is a newly funded initiative that’s driven to digitize life. Our goal is to understand embryonic development as the execution of a program in our genome. We seek to upload embryonic development into a virtual life form called the Digital Fish through the use of genetics, molecular imaging, and information technology. Our approach called “in toto imaging” is to use confocal/2-photon imaging to image all the cells in developing transgenic zebrafish embryos and special software we are developing called GoFigure to extract complete cell lineages and gene expression patterns.<br />
<br />
We are looking for people with strong experience in C++ programming and VTK/ITK to join our GoFigure development team. There are a number of significant image analysis problems we are addressing including: segmenting cells in space, across time, and across cell division; quantitating protein expression patterns and subcellular localization; developing a standard, cell-based, 4-d atlas of embryonic development; and registering molecular data from thousands of different embryos onto this atlas.<br />
<br />
There are opportunities at the graduate, post-doc, and staff levels. The successful applicant would join our team at Caltech in Pasadena/LA soon and then move with us to my new lab in the Department of Systems Biology at Harvard Medical School in Boston in summer 2008. To apply, please send a cover letter, CV, and letters of reference to me by email (megason@caltech.edu).<br />
<br />
For more information please see below:<br />
www.digitalfish.org <http://www.digitalfish.org/> <br />
or talk to Alexandre Gouaillard or myself at the upcoming NAMIC meeting in Boston ( june 2007 ).<br />
http://www.na-mic.org/Wiki/index.php/NA-MIC_NCBC_Collaboration:3D%2Bt_Cells_Lineage:GoFigure<br />
<br />
Sean Megason<br />
<br />
=== Spring 2007: University of Texas - M. D. Anderson Cancer Center ===<br />
<br />
The Image Processing & Visualization Laboratory (IPVL) has opened positions for a Programmer Analyst, Post Doctorate and Research Scientist to support its core mission in America’s largest cancer center.<br />
<br />
Images handled by the IPVL span the full spectrum of human and animal (small to large) imaging instrumentation for applications that range from research to clinic, all in direct and close interaction with departments and investigators throughout the institution. Computer equipment includes high-end clinical workstations and software, as well as high-end platforms under Windows, Linux or OSX for developments with OpenSource toolkits, IDL or MatLab. Other available equipment include database and compute servers (Windows, Unix/Solaris/Linux), as well as a state-of-the-art 512 CPUs cluster and 32 CPUs SMP, both shared with the institution and entirely dedicated to research.<br />
<br />
The successful candidates will need to demonstrate – in various capacities that depend on the targeted position - expertise and interest in the design, development, implementation or exploitation of advanced imaging applications, ideally in a biomedical setting and with multidimensional, multimodality and quantitative imaging for clinical and research applications. Topics of particular interests are 3D+ imaging (e.g., rendering, segmentation, navigation), non-rigid registration, parametric and quantitative imaging, kinetic modeling, etc. Expertise in modern and relevant languages and toolkits (e.g., C/C++, VTK, ITK, IGSTK) as well as in matching development tools and environments is considered an asset.<br />
<br />
If you believe your experience matches any of these profiles, please send your CV and other relevant information (e.g., three references, statement of interest/qualification for the specific position) to:<br />
<br />
Dr. Luc Bidaut, Ph.D.<br />
Director of the IPVL<br />
E-mail: lbidaut at mdanderson dot org<br />
<br />
== Year 2006 ==<br />
<br />
=== May 2006: National Institutes of Health Staff Scientist Position ===<br />
<br />
'''Staff Scientist'''<br />
Medical Image Processing<br />
Warren G. Magnuson Clinical Center Department of Radiology<br />
National Institutes of Health<br />
U.S. Department of Health and Human Services<br />
<br />
The Department of Radiology is seeking a Staff Scientist to support our research and clinical efforts in image processing (virtual endoscopy, volumetric visualization, segmentation, registration and algorithm development) and computer-aided diagnosis (feature extraction, classification, database development). In particular, advanced skills in image segmentation (level sets, active shape/appearance models, etc.) and machine learning are sought. The incumbent will work closely with a team of computer scientists and engineers. Applicants with a proven track record as evidenced by peer-reviewed publications on medical applications of image processing and having advanced mathematical and computer skills are encouraged to apply. Demonstrated expertise in C++ and ITK (NLM’s Insight Toolkit) are required. The candidate should have a Ph.D. in Computer Science, Electrical or Biomedical Engineering, Mathematics, Biophysics or Physics. Salary commensurate with experience. Applicati!<br />
ons should include a CV, brief statement of research interests, and three letters of reference. Applications are due 6 weeks after posting of this announcement. DHHS and NIH are Equal Opportunity Employers.<br />
<br />
*Address applications to:<br />
<br />
Ronald Summers, M.D., Ph.D.<br />
Chief, Clinical Image Processing Service<br />
and Virtual Endoscopy and Computer-Aided Diagnosis Laboratory<br />
Department of Radiology<br />
National Institutes of Health<br />
Building 10 Room 1C660<br />
Bethesda, MD 20892-1182<br />
E-mail: rms at nih dot gov<br />
Web site: http://www.cc.nih.gov/drd/summers.html <br />
<br />
=== Spring 2006: National Institutes of Health Postdoc ===<br />
<br />
'''Post-doctoral Fellowship'''<br />
Medical Image Processing – Computer-Aided Detection<br />
Warren G. Magnuson Clinical Center <br />
Department of Radiology<br />
National Institutes of Health<br />
U.S. Department of Health and Human Services<br />
<br />
A post-doctoral fellowship is available in three-dimensional radiology image processing. Specific interest areas are virtual endoscopy, volumetric visualization, image segmentation, registration and computer-aided detection (including feature extraction, classification, image databases and observer performance analysis [ROC]). In particular, advanced skills in image segmentation (level sets, active shape/appearance models, etc.) are sought. Fellows have access to state-of-the-art whole body MRI, multi-detector helical CT, advanced graphics workstations (Windows PC) and Beowulf massively parallel processing cluster. Candidates must have or soon expect to receive doctorates in physics, biophysics, mathematics, statistics, biomedical engineering or computer science. Applicants with a proven track record as evidenced by peer-reviewed publications on medical applications of computer visualization and image processing and having advanced mathematical and computer skills are encouraged to apply. Initial appointment is for one to two years and is renewable thereafter on a periodic basis. Applications should include a CV, brief statement of research interests and three letters of reference. Applications are due 6 weeks after posting of this announcement. DHHS and NIH are Equal Opportunity Employers.<br />
<br />
*Address applications to:<br />
<br />
Ronald Summers, M.D., Ph.D.<br />
Chief, Clinical Image Processing Service<br />
and Virtual Endoscopy and Computer-Aided Diagnosis Laboratory<br />
Department of Radiology<br />
National Institutes of Health<br />
Building 10 Room 1C660<br />
Bethesda, MD 20892-1182<br />
E-mail: rms at nih dot gov<br />
Web site: http://www.cc.nih.gov/drd/summers.html<br />
<br />
<br />
== Year 2005 ==<br />
<br />
=== Spring/Summer 2005: National Institutes of Health Postdoc ===<br />
<br />
'''Post-doctoral Fellowship'''<br />
Medical Image Processing<br />
Department of Radiology<br />
National Institutes of Health<br />
Department of Health and Human Services<br />
<br />
A Post-doctoral fellowship is available in three-dimensional medical<br />
imaging. Specific interest areas are image processing (virtual endoscopy,<br />
volumetric visualization, image segmentation, registration, fusion, and<br />
algorithm development) and computer-aided diagnosis (feature extraction,<br />
classification, and databases). Fellows have access to state-of-the-art<br />
whole body MRI, 16-row detector CT+PET and advanced graphics workstations (PC and Beowulf cluster). Candidates must have or soon expect to receive<br />
doctorates in applied mathematics or computer science. Applicants with a<br />
proven track record as evidenced by peer-reviewed publications on image <br />
processing and having strong software development and C++ skills are encouraged to apply. GPU shader programming experience is a plus. Applications should include a CV and a brief statement of research interests. NIH is an equal opportunity employer. If a US work permit is not available, then the only visa the NIH can provide for this position is a J visa.<br />
<br />
* Address applications to:<br />
<br />
Ingmar Bitter, Ph.D.<br />
Clinical Image Processing Services<br />
Diagnostic Radiology Department<br />
National Institutes of Health<br />
Building 10 Room 1C660<br />
Bethesda, MD 20892-1182<br />
E-mail: ibitter at nih dot gov<br />
<br />
<br />
== Year 2004 ==<br />
<br />
=== November 2004: Kitware ===<br />
<br />
Kitware is seeking to fill positions immediately. We are looking for people who will relocate to the Albany, NY USA area, are willing to work in a small company, and show flexibility in work assignments. Important skills include proficiency in C++, scientific software development, medical image analysis, and/or ITK. Individuals demonstrating expertise in areas that significantly extend Kitware's software skill base are particularly favored. Please send your resume to kitware at kitware.com.<br />
<br />
Will<br />
<br />
William J. Schroeder, Ph.D.<br />
Kitware, Inc.<br />
28 Corporate Drive, Suite 204<br />
Clifton Park, NY 12065<br />
will.schroeder at kitware.com<br />
1-518-371-3971 x102 (phone)<br />
1-518-371-3971 (fax) <br />
<br />
([http://public.kitware.com/pipermail/insight-users/2004-July/009562.html Original post])<br />
<br />
<br />
=== Nov 2004: National Institutes of Health Staff Scientist ===<br />
<br />
Warren G. Magnuson Clinical Center<br />
National Institutes of Health<br />
U.S. Department of Health and Human Services<br />
<br />
'''Staff Scientist'''<br />
'''Medical Image Processing'''<br />
<br />
<br />
The Department of Radiology is seeking a Staff Scientist to support our research efforts in image processing (virtual endoscopy, volumetric visualization, segmentation, registration and algorithm development) and computer-aided diagnosis (feature extraction, classification, database development). In particular, advanced skills in image segmentation (level sets, active shape/appearance models, etc.) are sought. The incumbent will work closely with a team of computer scientists and engineers. Applicants with a proven track record as evidenced by peer-reviewed publications on medical applications of image processing and having advanced mathematical and computer skills are encouraged to apply. Demonstrated expertise in C++ and ITK (NLM’s Insight Toolkit) are required. The candidate should have a Ph.D. in Electrical or Biomedical Engineering, Computer Science, Mathematics, Biophysics or Physics. Salary commensurate with experience. Applications should include a CV, brief statement of research interests, and three letters of reference. Applications are due 6 weeks after posting of this announcement. DHHS and NIH are Equal Opportunity Employers.<br />
<br />
Address applications to:<br />
Ronald Summers, M.D., Ph.D.<br />
Chief, Clinical Image Processing Service<br />
and Virtual Endoscopy and Computer-Aided Diagnosis Laboratory<br />
Department of Radiology<br />
National Institutes of Health<br />
Building 10 Room 1C660<br />
Bethesda, MD 20892-1182<br />
E-mail: RobertsonS at cc dot nih dot gov<br />
Web site: http://www.cc.nih.gov/drd/summers.html<br />
<br />
<br />
=== June 2004: Computer Vision Research Position ===<br />
<br />
'''Computer Vision Research Positions at GE Global Research'''<br />
Visualization and Computer Vision Lab<br />
<br />
We are seeking highly qualified candidates to innovate and develop computer vision technology for commercial and government applications. We are particularly interested in recruiting candidates with expertise in one of the following areas:<br />
<br />
* Machine Learning - applying semantic knowledge to practical vision problems <br />
* Deformable Registration / Deformable Modeling<br />
* Segmentation<br />
* Object Detection and Tracking<br />
<br />
The Visualization & Computer Vision Lab at GE Global Research in Niskayuna, NY conducts basic and applied research in computer vision and closely related areas. With 30 Staff Researchers (most holding a PhD) the lab develops advanced technologies for GE businesses, including GE Security, GE Healthcare, GE Aircraft Engines, GE Power Systems and NBC Universal; Lockheed Martin; and US Government agencies including NIH, DARPA, FBI, AFRL and NIMA. Areas of active research include image segmentation, deformable registration, perceptual organization, texture classification, object detection, event recognition, tracking, camera calibration, optical metrology, video content extraction, change detection, and superresolution.<br />
<br />
We are active users and contributors to ITK and VXL; experience with either of these toolkits is desired. Strong C++ skills along with a superior ability to work in a team environment are essential qualities for successful candidates.<br />
<br />
Interested? Please contact Jim Miller at `millerjv at research.ge.com`<br />
<br />
Visualization & Computer Vision<br />
GE Research<br />
Bldg. KW, Room C218B<br />
P.O. Box 8, Schenectady NY 12301<br />
<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarretahttps://public.kitware.com/Wiki/index.php?title=ITK/FAQ&diff=55976ITK/FAQ2014-03-31T09:29:24Z<p>Jhlegarreta: /* How do I cite the use of ITK in a publication? */ Added the bibtex for the SW Guide Third Edition and made some changes to other bibtex entries</p>
<hr />
<div>== General information and availability ==<br />
<br />
=== Do I need VTK to build ITK ? ===<br />
With the default configuration, ITK does not require VTK. However, some optional modules (ITKVTKGlue) do require VTK.<br />
<br />
ITK does not provide any visualization functionalities. Applications requiring visualization should implement those functionalities from internal code or libraries like OpenGL, GLUT or VTK.<br />
<br />
=== What 3D file formats can ITK import and export? ===<br />
<br />
The following table identifies the file formats that ITK can read/write via a factory mechanism based on the file extension (itk::ImageIOFactory). Some proprietary files format are only imported. More information on [[ITK File Formats]] is available, including data types supported.<br />
<br />
A very nice tool for viewing all of these images is ImageViewer which can be found in the ITKApps repository.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! File Format<br />
! Read/Write<br />
! Import<br />
|-<br />
| Analyze 7.5 || AnalyzeImageIO ||<br />
|-<br />
| BMP &dagger; || BMPImageIO ||<br />
|-<br />
| DICOM || GDCMImageIO || Using DicomImageIO is backward compatible, but user should prefer GDCMImageIO<br />
|-<br />
| GE 4x || || GE4ImageIO<br />
|-<br />
| GE 5x || || GE5ImageIO<br />
|-<br />
| GE Advantage Windows || || GEAdwImageIO<br />
|-<br />
| Gipl (.gipl) || GiplImageIO ||<br />
|-<br />
| IPLCommon || || IPLCommonImageIO<br />
|-<br />
| JPEG &dagger; || JPEGImageIO ||<br />
|-<br />
| MetaImage (.mha/.mhd) || MetaImageIO ||<br />
|-<br />
| PNG &dagger; || PNGImageIO ||<br />
|-<br />
| Raw &Dagger; || RawImageIO ||<br />
|-<br />
| Siemens Vision || || SiemensVisionImageIO<br />
|-<br />
| Stimulate (spr/sdt) || StimulateImageIO ||<br />
|-<br />
| TIFF || TIFFImageIO ||<br />
|-<br />
| VTK Structured Points || VTKImageIO ||<br />
|}<br />
<br />
&dagger; BMP, PNG and JPEG are not very good formats for 3D medical images. They only support 2D images and a limited set of pixel types such as unsigned char, and unsigned short. The great advantage of BMP, PNG and JPEG is that you can view them with almost any image viewer. It is possible to read/write 3D datasets as collections of 2D slices each one in an independent BMP, PNG or JPEG file by using the ImageSerierReader and ImageSeriesWriter.<br />
<br />
&Dagger; It is higly recommended not using this format. RAW is not a format, it is insufficient, inconsistent and simply dangerous. A RAW file without a header is useless, and once you add a header, it is not RAW anymore.<br />
<br />
=== What if my file format is not supported by ITK? ===<br />
If ITK doesn't have a specific file format reader at this point, you may try converting this specific file format image to a format like PNG, for which ITK has readers.<br />
<br />
A good set of tools for performing such conversions is available in ImageMagick. It can be downloaded it for free from: http://www.imagemagick.org/<br />
<br />
You can also take advantage of the VTK readers/importers. All you need is then use the VTKImageToImage adaptor in order to convert the vtkImageData into an itk::Image.<br />
<br />
Supported VTK file formats can be found here: [[VTK_FAQ#What_image_file_formats_can_VTK_read_and_write.3F|What image file formats can VTK read and write?]] and [[VTK_FAQ#What_3D_file_formats_can_VTK_import_and_export.3F|What 3D file formats can VTK import and export]]<br />
<br />
=== How do I read a volume from a DICOM series? ===<br />
The following are alternative options for reading DICOM series. The first one in the list is the recommended option. The others are provided in case of desperation.<br />
<br />
# Use the itk::ImageSeriesReader<> in combination with the DicomSeriesFileNames<>. For a full example on how to do this, please look at the source code under Insight/Code/Examples/IO/DicomSeriesReadImageWrite.cxx.<br />
# Write a MetaImageHeader<br>This is a small text file holding information about the image: spacing, dimensions, pixelt type... This header can hold the list of dicom files you want to read. The only restriction is that the files must be uncompressed.<br>The easy way to create a MetaImage header is to use the application: MetaImageImporter that is available in: InsightApplications/MetaImageImporter. you can also take an existing metaimage reader and modify it in order to fit your needs. Please find attached one file that you can edit it with your favorite text editor.<br />
# Use MRIConvert<br>Jolinda Smith from the Lewis Center for Neuroimaging at the University of Oregon has developed a nice application that allows you to load DICOM series and export them in MetaImage and Analyze format (among others).<br>She graciously has made this application publicly available at: http://lcni.uoregon.edu/~jolinda/MRIConvert There is a fresh version updated in april 14th.<br />
# Jeff Brubaker and Stephen R. Aylward, at the UNC<br>CADDLab developed a DICOM query/move application called "MIND" (whit the motto: "MIND is not DICOM"). This application loads DICOM files over the network and export them in MetaImage format. This application is open source and it is available at: http://www.jeffro.net/mind/ and http://caddlab.rad.unc.edu/software/MIND/<br />
<br />
=== How do I write a volume as DICOM series? ===<br />
Use ITK in combination with gdcm <br />
<br />
http://gdcm.sourceforge.net/<br />
<br />
GDCM is an open source package developed by the Creatis team at INSA-Lyon. It is distributed under a license similar to ITK.<br />
<br />
http://gdcm.sourceforge.net/Copyright.html<br />
<br />
GCDM uses CMake in order to configure its build process, so you will find a familiar setup. Once you download, configure and buid GDCM, you can reconfigure ITK by running CMake in your ITK build, going into the Advanced options and enabling USE_GDCM. <br />
<br />
For a code example on how to use GDCM for reading and writing DICOM series, please refer to the source code in<br />
<br />
Insight/Examples/IO/DicomSeriesReadImageWrite2.cxx<br />
<br />
<font color="red">UPDATE:</font> As of ITK 2.4 this option: USE_GDCM has disapear since GDCM is now the default toolkit for reading DICOM image. See also [[Proposals:Make_GDCM_the_default_DICOM]].<br />
<br />
You can always use the latest and greatest of GDCM, simply use an installed version of GDCM and link ITK to it using ITK_USE_SYSTEM_GDCM<br />
<br />
=== Which interpreted languages are supported by ITK? ===<br />
Currently ITK supports the following language bindings:<br />
<br />
* Python <br />
* Java<br />
<br />
=== How do I cite the use of ITK in a publication? ===<br />
The Insight software may be cited by referencing the paper, the books, and/or the web site.<br />
<br />
A) '''The paper'''<br />
<br />
T.S. Yoo, M. J. Ackerman, W. E. Lorensen, W. Schroeder, V. Chalana, S. Aylward, D. Metaxas, R. Whitaker. Engineering and Algorithm Design for an Image Processing API: A Technical Report on ITK - The Insight Toolkit. In Proc. of Medicine Meets Virtual Reality, J. Westwood, ed., IOS Press Amsterdam pp 586-592 (2002).<br />
<br />
B) '''The books'''<br />
<br />
"Insight into Images"<br />
edited by Terry Yoo<br />
published by A.K. Peters 2004<br />
ISBN: 1-56881-217-5<br />
<br />
"The ITK Software Guide"<br />
Second Edition<br />
Ibanez, Schroeder, Ng, Cates.<br />
published by Kitware Inc.<br />
2005<br />
ISBN: 1-930934-15-7<br />
<br />
"The ITK Software Guide"<br />
First Edition<br />
Ibanez, Schroeder, Ng, Cates.<br />
published by Kitware Inc.<br />
2003<br />
ISBN: 1-930934-10-6<br />
<br />
"Mastering CMake,<br />
A Cross-Platform Build System"<br />
K. Martin and B. Hoffman<br />
published by Kitware Inc.<br />
ISBN: 1-930934-09-2<br />
<br />
'''BibTtex citations'''<br />
<br />
@Manual{ITKSoftwareGuide,<br />
Title = {The {ITK} {S}oftware {G}uide},<br />
Author = {Ibanez, L. and Schroeder, W. and Ng, L. and Cates, J.},<br />
Organization = "Kitware, Inc.",<br />
Edition = {First},<br />
year = {2003},<br />
note = {ISBN 1-930934-10-6},<br />
url = \href{[http://www.itk.org/ItkSoftwareGuide.pdf http://www.itk.org/ItkSoftwareGuide.pdf]}{<nowiki>http://www.itk.org/ItkSoftwareGuide.pdf</nowiki>},<br />
}<br />
<br />
@Manual{ITKSoftwareGuideSecondEdition,<br />
Title = {The {ITK} {S}oftware {G}uide},<br />
Author = {Ibanez, L. and Schroeder, W. and Ng, L. and Cates, J.},<br />
Organization = "Kitware, Inc.",<br />
Edition = {Second},<br />
year = {2005},<br />
note = {ISBN 1-930934-15-7},<br />
url = \href{[http://www.itk.org/ItkSoftwareGuide.pdf http://www.itk.org/ItkSoftwareGuide.pdf]}{<nowiki>http://www.itk.org/ItkSoftwareGuide.pdf</nowiki>},<br />
}<br />
<br />
@Manual{ITKSoftwareGuideThirdEdition,<br />
Title = {The {ITK} {S}oftware {G}uide},<br />
Author = {Johnson, Hans J. and McCormick, M. and Ib\'{a}{\~n}ez, L. and The Insight Software Consortium},<br />
Organization = "Kitware, Inc.",<br />
Edition = {Third},<br />
year = {2013},<br />
url = \href{[http://www.itk.org/ItkSoftwareGuide.pdf http://www.itk.org/ItkSoftwareGuide.pdf]}{<nowiki>http://www.itk.org/ItkSoftwareGuide.pdf</nowiki>},<br />
}<br />
<br />
C) '''The Web sites'''<br />
<br />
"The Insight Segmentation and Registration Toolkit"<br />
www.itk.org<br />
<br />
"CMake: Cross Platform Make"<br />
www.cmake.org<br />
<br />
If you want to include ITK in an acknowledgment section, a phrase similar to the following may be used:<br />
<br />
"This work benefited from the use of the Insight Segmentation<br />
and Registration Toolkit (ITK), an open source software<br />
developed as an initiative of the U.S. National Library<br />
of Medicine and available at www.itk.org."<br />
<br />
and<br />
<br />
"The multi-platform configuration tool CMake was used for<br />
configuring ITK and facilitating its use from our project.<br />
CMake was partially funded by the U.S. National Library of<br />
Medicine as part of the Insight Toolkit project. CMake is an <br />
open source system and it is freely available at www.cmake.org."<br />
<br />
=== What does "Could not create IO object for file" mean? ===<br />
When trying to read or write a file using the ImageFileReader or the ImageFileWriter I got an exception with the following message:<br />
<br />
itk::ImageFileReaderException (00F7F494)<br />
Location: "Unknown"<br />
File: C:\ITK\InsightToolkit-1.6.0\Code\IO\itkImageFileReader.hxx<br />
Line: 101<br />
Description: Could not create IO object for file c:\t1.mnc<br />
<br />
This exception is thrown when ITK does not recognize the fileformat that you are trying to read or write. When reading, ITK recognize file formats by asking a set of internal readers to attempt to read your file. If none of the registered readers accept your file, then the exception above is thrown. When writing, ITK uses the extension of the filename in order to chose the fileformat to be used. You must make sure that you use one of the filename extensions recognized by ITK. Please look at FAQ entry 1.7 for a full list of those extensions and associated fileformats.<br />
<br />
Additional details on the ITK Input/Output architecture are available in the ITK Software Guide: http://www.itk.org/ItkSoftwareGuide.pdf.<br />
<br />
=== Is ITK FDA-Approved? ===<br />
<br />
Given the fact that ITK is a software toolkit, it cannot be the<br />
subject of FDA approval as a medical device. We have discussed<br />
this topic in several occasions and received advice from FDA<br />
representatives, that can be summarized as follow:<br />
<br />
<br />
ITK is to be considered as an off-the-shelf (OTS) product that<br />
is used for supporting a higher level medical application/product.<br />
The developer of such application/product will be responsible for<br />
performing the validation processes described in FDA published<br />
guidelines for the development of software-related medical devices.<br />
<br />
For mode details see the page [[FDA Guidelines for Software Developement]]<br />
<br />
== Language bindings ==<br />
=== What does "Error opening hint file NOTFOUND" mean? ===<br />
When you enable "USE_VTK" in the CMake configuration of ITK, and VTK was built with wrapping, CMake looks for a "hints" file.<br />
<br />
The "hints" file is on the VTK source tree under: VTK/Wrapping/hints<br />
<br />
Please switch CMake to "advanced", look for the VTK_WRAP_HINTS variable and set it to the full path to the "hints" file including the "hints" filename itself.<br />
<br />
here is how it looks in the CMakeCache.txt of a typical ITK installation:<br />
<br />
//Where can the hints file be found<br />
VTK_WRAP_HINTS:FILEPATH=/home/johndoe/src/VTK/Wrapping/hints<br />
<br />
=== How do I use ITK with WrapITK? ===<br />
<br />
* [[ITK/Java_Wrapping|Java]]<br />
* [[ITK/Python_Wrapping|Python]]<br />
* [[ITK/WrapITK Status|Wrapping status]]<br />
<br />
=== How do I use ITK from C# .NET? ===<br />
<br />
There are currently three options:<br />
# Use [http://code.google.com/p/manageditk ManagedITK]<br />
#* '''NOTE: This option is not recommended as the project is no longer supported'''<br />
# Use the [http://www.simpleitk.org/ SimpleITK] [http://sourceforge.net/projects/simpleitk/files/SimpleITK C# language bindings]<br />
#* SimpleITK is great, but it does not support all filters (e.g. no support for registration in version 0.5.1)<br />
#* A list of available filters can be found [http://www.itk.org/SimpleITKDoxygen/html/Filter_Coverage.html here] (valid Sept 2012)<br />
# Manually wrap the desired functionality<br />
#* This option requires the most work, but is the most flexible, allowing you to use any ITK functionality you desire<br />
#* An example can be found [[ITK/Using ITK from .NET|here]]<br />
<br />
NOTE: WrapITK does not currently support C# language bindings, but could be made to do so.<br />
<br />
== Using the Insight Toolkit ==<br />
<br />
=== How do I combine ITK and VTK in my application? ===<br />
<br />
A full tutorial on how to combine ITK and VTK is available at<br />
<br />
"Getting Started with ITK and VTK"<br />
http://www.itk.org/CourseWare/Training/GettingStarted-II.pdf<br />
<br />
You will need the auxiliary classes available at<br />
<br />
ITKApps<br />
<br />
For example, for converting ITK images into VTK images and back, you will find useful the files from the ITKVTKGlue module:<br />
<br />
itkImageToVTKImageFilter.h<br />
itkImageToVTKImageFilter.hxx<br />
itkVTKImageToImageFilter.h<br />
itkVTKImageToImageFilter.hxx<br />
<br />
=== How do I configure Emacs for ITK coding style? ===<br />
You can add the following codes into your .emacs file<br />
<br />
;;;;;;;;;;;;;;<br />
(c-add-style "itk"<br />
'("stroustrup" <br />
(c-basic-offset . 2)<br />
(c-offsets-alist<br />
(c . c-lineup-dont-change)<br />
(innamespace . 0)<br />
(inline-open . 0) <br />
(substatement-open . +)<br />
(statement-block-intro . 0) ) ) )<br />
(add-hook 'c++-mode-hook (function (lambda ()<br />
(c-set-style "itk")(turn-on-auto-fill))))<br />
(add-to-list 'auto-mode-alist '("\\.txx\\'" . c++-mode)) (add-to-list 'auto-mode-alist '("\\.h\\'" . c++-mode))<br />
;;;;;;;;;;;<br />
<br />
=== How do I configure VIM for ITK coding style? ===<br />
<br />
set tabstop=2 " Tabs are two characters<br />
set shiftwidth=2 " Indents are two charactes too<br />
set expandtab " Do not use tabs<br />
set matchpairs+=<:> " To mach arguments of templates<br />
set cinoptions={1s,:0,l1,g0,c0,(0,(s,m1 " ITK/VTK style indenting<br />
<br />
You can also use CMake indentation and syntax file which are available on www.vim.org.<br />
<br />
This was contributed by Andy Cedilnik @kitware.com<br />
<br />
If you'd like to enable c++ style syntax highlight for *.txx files, put the following lines in your .vimrc file:<br />
syntax on<br />
au BufNewFile,BufRead *.txx set filetype=cpp<br />
<br />
== Platform-specific questions ==<br />
=== How do I avoid multiple prompts to reload all projects in Microsoft Visual Studio? ===<br />
When the CMake source changes, you may see multiple prompts to reload many projects.<br />
<br />
DO NOT USE "Rebuild All" or "Batch Build". Use the following recommended procedure.<br />
<br />
There is an ALL_BUILD target available in the MSVC++ workspace. The best way to build ITK is to set ALL_BUILD as the active project, then select the active configuration you want (DEBUG, etc).<br />
<br />
This can also be done from the command line like this: msdev ITK.dsw /MAKE "ALL_BUILD - Debug" /REBUILD<br />
<br />
=== How do I fix Visual Studio 7 (2002) Compiler Issues? ===<br />
<br />
The Visual Studio 7.0 compiler is more similar to the version 6 compiler than the version 7.1 compiler from the C++ conformance perspective. While it does not crash as frequently as version 6, there are some code patterns that still cause an INTERNAL COMPILER ERROR. Here is one example:<br />
<br />
<pre><nowiki><br />
// Define a class template that has a data member of the template type.<br />
template <class T> struct A { T v; };<br />
<br />
// Define a primary template with no members.<br />
template <class T> struct B {};<br />
<br />
// Define a specialization that defines a type.<br />
// This line is not actually necessary to cause the ICE but will be present when this problem is encountered in practice.<br />
//template <> struct B<int> { typedef int Type; };<br />
<br />
template <class T> struct C<br />
{<br />
// Lookup the "Type" member of B<T>. In practice this will reference a specialization.<br />
typedef typename B<T>::Type Type;<br />
<br />
// Use the result of the lookup to instantiate A<> and its data member.<br />
typedef typename A<Type>::A AType;<br />
};<br />
</nowiki></pre><br />
<br />
This will cause an ICE in msc1.cpp, line 2844. The work-around is to define the "Type" member in the primary template of B even though it will not be used:<br />
<br />
<pre><nowiki><br />
template <class T> struct A { T v; };<br />
template <class T> struct B { typedef T Type; };<br />
template <class T> struct C<br />
{<br />
typedef typename B<T>::Type Type;<br />
typedef typename A<Type>::A AType;<br />
};<br />
</nowiki></pre><br />
<br />
=== How do I fix prolems with MipsPro Compilers (7.3.3.1m and 7.4.2m) on IRIX? ===<br />
<br />
There have been reports of problems building ITK on IRIX platform. Here are the compiler flags that are used to build ITK and submit nightly dashboard results. SGI Flags for both 7.3.3.1m and 7.4.2m compilers that are working for the kraepelin.uiowa nightly builds.<br />
<br />
DEBUG BUILD:<br />
//No help, variable specified on the command line.<br />
CMAKE_CXX_FLAGS:STRING= -n32 -g -DUDEBUG -G0 -multigot -no_auto_include -xansi -LANG:std -LANG:ansi-for-init-scope=ON -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
//No help, variable specified on the command line.<br />
CMAKE_C_FLAGS:STRING= -n32 -g -DUDEBUG -G0 -multigot -xansi -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
OPTIMIZED BUILD:<br />
CMAKE_CXX_FLAGS:STRING= -n32 -O3 -DNDEBUG -G0 -multigot -no_auto_include -xansi -LANG:std -LANG:ansi-for-init-scope=ON -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
//No help, variable specified on the command line.<br />
CMAKE_C_FLAGS:STRING= -n32 -O3 -DNDEBUG -G0 -multigot -xansi -woff 15,84,1110,1209,1424,1468,3102,3210,3439<br />
<br />
== Contribute ==<br />
=== How do I make code contributions to ITK? ===<br />
Please see this page: [[ITKContribute]].<br />
<br />
== Testing ==<br />
=== Is ITK tested? ===<br />
Please see this page: [[ITK/Testing]]<br />
<br />
== Working with Image Data ==<br />
<br />
===How do I iterate through all the pixels in an image?===<br />
<br />
Please see this example: http://www.itk.org/Wiki/ITK/Examples/Iterators/ImageRegionIterator of itkImageRegionIterator.<br />
<br />
===What are Hounsfield Units?===<br />
<br />
Hounsfield units were defined by Sir Godfrey N. Hounsfield, on of the pioneers of Computer Tomography for clinical applications.<br />
<br />
The units represent the linear attenuation of X-Rays for a particular material. <br />
<br />
The units scale is defined in such a way that level for Water is 0 and the level for Air is -1000. <br />
<br />
The attenuation of any other material is mapped linearly into this range.<br />
<br />
A table of Hounsfield units for common human tissues is avalable in the following link [[ITK Hounsfield Units]]<br />
<br />
===What are MRI T1 / T2 Units?===<br />
<br />
MRI images measure two types of relaxation times. <br />
<br />
The units are millisecons and the two relaxation concepts relate to how long it takes for the molecules in the tissue to realign themselves with a magentic field after being perturbed.<br />
<br />
Details on the MRI units are available in the Wikipedia:<br />
<br />
[http://en.wikipedia.org/wiki/Relaxation_%28NMR%29 Relaxation (NMR)]<br />
<br />
=== DICOM: Bits Allocated, Bits Stored and High Bit ===<br />
<br />
A question that is often asked on insight-users is :<br />
I am trying to read/write a DICOM image, but some of the DICOM fields have changed after I write it back on disk.<br />
<br />
Here is what you have on disk:<br />
<pre><br />
Bits Allocated = 16<br />
Bits Stored = 12<br />
High Bit = 11<br />
<br />
|<------------------ pixel ----------------->|<br />
______________ ______________ ______________ ______________<br />
|XXXXXXXXXXXXXX| | | |<br />
|______________|______________|______________|______________|<br />
15 12 11 8 7 4 3 0<br />
</pre><br />
<br />
Here is what you generally get after writing by GDCM:<br />
<pre><br />
Bits Allocated = 16<br />
Bits Stored = 16<br />
High Bit = 15<br />
<br />
|<------------------------- pixel ------------------------>|<br />
______________ ______________ ______________ ______________<br />
| | | | |<br />
|______________|______________|______________|______________|<br />
15 12 11 8 7 4 3 0<br />
</pre><br />
<br />
Since DICOM V3, you '''cannot''' store any overlay in the unused bits of the Pixel Data (0x7fe0,0x0010), thus it imply that the unused bits are '''zeros'''.<br />
In ITK, there is no such thing as 12bits Pixel Type, thus when instanciating your reader you declare a 16bits Pixel Type. This buffer is then passed back to GDCM which sees an array of 16bits values and then simply used the simpliest way to store this buffer back on disk: Bits Stored = 16 and High Bit = 15.<br />
In case you have not made any change to your pixel buffer, implicitely the first 4 bits will be zero again. The only difference being that they are not as clearly declared as 12bits.<br />
<br />
=== I'm working with DICOM images, where can I find more information? ===<br />
[[ITK/DICOM]]<br />
<br />
== Data Display ==<br />
<br />
===What imaging software is available for displaying medical image files?===<br />
<br />
Please see the [[ITK/Third_Party_Applications | third party applications]] page for visualization applications that used ITK to perform Image reading/writing.<br />
<br />
===When I view the output of my program, all I see is a black image. What went wrong?===<br />
<br />
ITK is capable of reading and writing data in a variety of formats and bit depths. However many 'consumer' image programs only work with 8-bit data, so when you try to display a 16-bit data file the image will appear black. The solution is to use an image display program that correctly handles these types of files. A small selection is listed above.<br />
<br />
[http://www.imagemagick.org/ ImageMagick] is a particularly useful set of tools for image display, manipulation and conversion.<br />
<br />
The `ImageViewer` program, part of InsightApplications, is capable of correctly loading and displaying all file types supported by ITK (including anisotropic images).<br />
<br />
(Gavin Baker, 24-Jun-2004)<br />
<br />
== Registration ==<br />
<br />
===Can ITK be used for multi-modal registration? For example, CT-MRI, or MRI-fMRI?===<br />
<br />
ITK provides several method for performing Multi-Modality registration. These methods are described in detail in the SoftwareGuide Chapter 8, pdf-page 241 to 340. In particular you will find interesting Section 8.4 in pdf-page 255 where the Mutual Information metrics are described.<br />
<br />
Examples on multimodality registration are available in `Insight/Examples/Registration`. A demo application using Mutual Information is available under `InsightApplications/LandmarkInitializedMutualInformationRegistration`.<br />
<br />
It is strongly recommended that you read the chapter on image resampling (Section 6.9.4 of the pdf) before you get involved with image registration methods. That will save you a lot of misunderstandings that are common in new users.<br />
<br />
You will also find useful the tutorial sessions, in particular [http://www.itk.org/CourseWare/Training/RegistrationMethodsOverview.pdf the overview].<br />
<br />
(Luis Ibanez, 7-June-2004)<br />
<br />
<br />
{{ITK/Template/Footer}}</div>Jhlegarreta