https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Ibanez&feedformat=atomKitwarePublic - User contributions [en]2024-03-29T15:23:47ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=ITK_Google_Summer_of_Code/2013&diff=52063ITK Google Summer of Code/20132013-03-29T18:46:17Z<p>Ibanez: /* Project: Cloud Enabled Remote ITK Process */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2013<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.itk.org/ ITK]. If you wish to submit a proposal based on these ideas you should contact the community members identified below to find out more about the idea, get to know the community member that will review your proposal, and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors, and ideally have submitted a patch or two to fix bugs in their project (through Gerrit). Kitware makes extensive use of mailing lists, and this would be your best point of initial contact to apply for any of the proposed projects. The mailing lists can be found on the project pages linked in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea<br />
* Expected results/feature additions<br />
* Any prerequisites for working on the project<br />
* Links to any further information, discussions, bug reports etc<br />
* Any special mailing lists if not the standard mailing list for ITK<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor)<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.itk.org/ Project page], [http://www.itk.org/ITK/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=Insight dashboard].<br />
<br />
=== Project: Examples for Coders ===<br />
<br />
'''Brief explanation:''' The [http://itk.org/ITKExamples/ ITKExamples project] is an attempt to bring an improved, collaboratively develop code example documentation system to ITK and the broader open source community. The project brings features such as Git version controlled development, easy regression testing, self-contained, downloadable examples, support for multiple language, HTML, PDF, and EPub archives, acknowledgements through nightly-generated web-based rendering of git-stats, an index, and visualization.<br />
<br />
'''Expected results:''' While the local development capabilities have many advantages, a browser-based contribution system is also desired. This has begun with the [https://github.com/thewtex/vcwebedit vcwebedit] Sphinx Javascript extension project, but a Git-patch server that acts as a broker is still needed. 3D web-visualization of the 3D medical images via OpenGL with a project like [https://github.com/xtk/X Xtk] is also desirable. Finally, more examples are needed.<br />
<br />
'''Prerequisites:''' Experience in Javascript, Python, Sphinx, and C++ desired.<br />
<br />
'''Mentor:''' Matt McCormick (matt dot mccormick at kitware dot com). David Doria (daviddoria at gmail dot com)<br />
<br />
=== Project: Improved ObjectFactory backend with CPPMicroServices ===<br />
<br />
'''Brief explanation:''' ITK implements the object factory design pattern to allow the dynamic registration of specialized class implementations. It is currently used to provide the variety of ImageIO classes, but the toolkit could also benefit from broader adoption. There are also limitations in adding new ImageIO classes that live outside the main repository, which is possible with the new modular infrastructure in ITKv4.<br />
<br />
'''Expected results:''' [https://github.com/saschazelzer/CppMicroServices CPPMicroServices] is a "library provides a dynamic service registry based on the service layer as specified in the OSGi R4.2 specifications. It enables users to realize a service oriented approach within their software stack." This small, cross platform library could be used to greatly improve the capabilities of the ITK ObjectFactory system by extending the situations where objects can be registered into the factory and object priority can be assigned.<br />
<br />
'''Prerequisites:''' Experience in C++ and cross-platform development.<br />
<br />
'''Mentor:''' Matt McCormick (matt dot mccormick at kitware dot com).<br />
<br />
=== Project: A Clang/LLVM based replacement for GCCXML ===<br />
<br />
'''Brief explanation:''' The [http://www.gccxml.org/HTML/Index.html GCCXML] project parses C++ source code to create an XML description that can be worked with by other projects. This backend is used by WrapITK to generate SWIG wrappers for ITK. However, there is a high maintenance burden when migrating to a newer GCC backend and making adjustments for newer versions of Visual Studio. The Clang/LLVM project provides a library that to parse source code. A GCCXML replacement based off [http://clang.llvm.org/doxygen/group__CINDEX.html libclang] would be more maintainable.<br />
<br />
'''Expected results:''' A new project to replace GCCXML based on libclang is created to build WrapITK. A Visual Studio 2010 build of WrapITK.<br />
<br />
'''Prerequisites:''' Experience in C++. Experience in SWIG would be helpful.<br />
<br />
'''Mentor:''' Matt McCormick (matt dot mccormick at kitware dot com).<br />
<br />
<br />
=== Project: Cloud Enabled Remote ITK Process ===<br />
<br />
'''Brief explanation:''' ITK has an extensive set of image image capabilities that are commonly used in desktop and laptop computers. This project will enable web and cloud processing directly in ITK using the python wrapped SimpleITK engine. The resulting application will need to interact with [http://ipython.org/notebook.html IPython Notebooks] to accept user commands and will need to interact with data sources such as JSON, XML and web hosted files/databases for input and output. The benefits of this application are three-fold. First, this will encourage reproducible research by enabling the sharing of the specific algorithms and data. Second, this will enable transparent migration of ITK code from a local installation to the cloud as problem sizes increase. And third, this becomes a powerful teaching tool for algorithms in medical imaging analysis.<br />
<br />
'''Expected results:''' A ITK/python based application suitable for cloud processing of distributed data resources.<br />
<br />
'''Prerequisites:''' Experience in web development, C++, ITK, and Python.<br />
<br />
'''Mentor:''' Matt McCormick (matt dot mccormick at kitware dot com).</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK_Google_Summer_of_Code/2013&diff=52062ITK Google Summer of Code/20132013-03-29T18:41:34Z<p>Ibanez: /* Project: A Clang/LLVM based replacement for GCCXML */</p>
<hr />
<div>Project ideas for the Google Summer of Code 2013<br />
<br />
== Guidelines ==<br />
<br />
=== Students ===<br />
<br />
These ideas were contributed by developers and users of [http://www.itk.org/ ITK]. If you wish to submit a proposal based on these ideas you should contact the community members identified below to find out more about the idea, get to know the community member that will review your proposal, and receive feedback on your ideas.<br />
<br />
The Google Summer of Code program is competitive, and accepted students will usually have thoroughly researched the technologies of their proposed project, been in frequent contact with potential mentors, and ideally have submitted a patch or two to fix bugs in their project (through Gerrit). Kitware makes extensive use of mailing lists, and this would be your best point of initial contact to apply for any of the proposed projects. The mailing lists can be found on the project pages linked in the preceding paragraph. Please see [[GSoC proposal guidelines]] for further guidelines on writing your proposal.<br />
<br />
=== Adding Ideas ===<br />
<br />
When adding a new idea to this page, please try to include the following information:<br />
<br />
* A brief explanation of the idea<br />
* Expected results/feature additions<br />
* Any prerequisites for working on the project<br />
* Links to any further information, discussions, bug reports etc<br />
* Any special mailing lists if not the standard mailing list for ITK<br />
* Your name and email address for contact (if willing to mentor, or nominated mentor)<br />
<br />
== Project Ideas ==<br />
<br />
[http://www.itk.org/ Project page], [http://www.itk.org/ITK/help/mailing.html mailing lists], [http://www.cdash.org/CDash/index.php?project=Insight dashboard].<br />
<br />
=== Project: Examples for Coders ===<br />
<br />
'''Brief explanation:''' The [http://itk.org/ITKExamples/ ITKExamples project] is an attempt to bring an improved, collaboratively develop code example documentation system to ITK and the broader open source community. The project brings features such as Git version controlled development, easy regression testing, self-contained, downloadable examples, support for multiple language, HTML, PDF, and EPub archives, acknowledgements through nightly-generated web-based rendering of git-stats, an index, and visualization.<br />
<br />
'''Expected results:''' While the local development capabilities have many advantages, a browser-based contribution system is also desired. This has begun with the [https://github.com/thewtex/vcwebedit vcwebedit] Sphinx Javascript extension project, but a Git-patch server that acts as a broker is still needed. 3D web-visualization of the 3D medical images via OpenGL with a project like [https://github.com/xtk/X Xtk] is also desirable. Finally, more examples are needed.<br />
<br />
'''Prerequisites:''' Experience in Javascript, Python, Sphinx, and C++ desired.<br />
<br />
'''Mentor:''' Matt McCormick (matt dot mccormick at kitware dot com). David Doria (daviddoria at gmail dot com)<br />
<br />
=== Project: Improved ObjectFactory backend with CPPMicroServices ===<br />
<br />
'''Brief explanation:''' ITK implements the object factory design pattern to allow the dynamic registration of specialized class implementations. It is currently used to provide the variety of ImageIO classes, but the toolkit could also benefit from broader adoption. There are also limitations in adding new ImageIO classes that live outside the main repository, which is possible with the new modular infrastructure in ITKv4.<br />
<br />
'''Expected results:''' [https://github.com/saschazelzer/CppMicroServices CPPMicroServices] is a "library provides a dynamic service registry based on the service layer as specified in the OSGi R4.2 specifications. It enables users to realize a service oriented approach within their software stack." This small, cross platform library could be used to greatly improve the capabilities of the ITK ObjectFactory system by extending the situations where objects can be registered into the factory and object priority can be assigned.<br />
<br />
'''Prerequisites:''' Experience in C++ and cross-platform development.<br />
<br />
'''Mentor:''' Matt McCormick (matt dot mccormick at kitware dot com).<br />
<br />
=== Project: A Clang/LLVM based replacement for GCCXML ===<br />
<br />
'''Brief explanation:''' The [http://www.gccxml.org/HTML/Index.html GCCXML] project parses C++ source code to create an XML description that can be worked with by other projects. This backend is used by WrapITK to generate SWIG wrappers for ITK. However, there is a high maintenance burden when migrating to a newer GCC backend and making adjustments for newer versions of Visual Studio. The Clang/LLVM project provides a library that to parse source code. A GCCXML replacement based off [http://clang.llvm.org/doxygen/group__CINDEX.html libclang] would be more maintainable.<br />
<br />
'''Expected results:''' A new project to replace GCCXML based on libclang is created to build WrapITK. A Visual Studio 2010 build of WrapITK.<br />
<br />
'''Prerequisites:''' Experience in C++. Experience in SWIG would be helpful.<br />
<br />
'''Mentor:''' Matt McCormick (matt dot mccormick at kitware dot com).<br />
<br />
<br />
=== Project: Cloud Enabled Remote ITK Process ===<br />
<br />
'''Brief explanation:''' ITK has an extensive set of image image capabilities that are commonly used in desktop and laptop computers. This project will enable web and cloud processing directly in ITK using the python wrapped SimpleITK engine. The resulting application will need to interact with [http://ipython.org/notebook.html IPython Notebooks] to accept user commands and will need to interact with data sources such as JSON, XML and web hosted files/databases for input and output. The benefits of this application are three-fold. First, this will encourage reproducible research by enabling the sharing of the specific algorithms and data. Second, this will enable transparent migration of ITK code from a local installation to the cloud as problem sizes increase. And third, this becomes a powerful teaching tool for algorithms in medical imaging analysis.<br />
<br />
'''Expected results:''' A ITK/python based application suitable for cloud processing of distributed data resources.<br />
<br />
'''Prerequisites:''' Experience in web development, C++, ITK, and Python.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Statistics&diff=51659ITK/Statistics2013-03-02T22:03:08Z<p>Ibanez: </p>
<hr />
<div>* [http://public.kitware.com/pub/itk/gitstat/ITK-2013-03-02/index.html gitstat ITK Statistics (Generated: 2013-03-02)]<br />
* [http://public.kitware.com/pub/itk/gitstat/ITKv4-2011-12-18/index.html gitstat ITKv4 Effort Statistics (Generated: 2011-12-18)]<br />
* [http://public.kitware.com/pub/itk/gitstat/ITK-2011-12-17/index.html gitstat ITK Statistics (Generated: 2011-12-17)]<br />
* [http://public.kitware.com/pub/itk/gitstat/ITK-2011-05-09/index.html gitstat ITK Statistics (Generated: 2011-05-09)]<br />
* [http://public.kitware.com/pub/itk/gitstat/ITK-2011-03-29/index.html gitstat ITK Statistics (Generated: 2011-03-29)]<br />
* [http://public.kitware.com/pub/itk/gitstat/ITK-2010-11-20/index.html gitstat ITK Statistics (Generated: 2010-11-20)]<br />
* [http://public.kitware.com/pub/itk/InsightStatCVS/index.html StatCVS ITK Statistics (Generated: 2009-11-05)]<br />
* [http://www.itk.org/Testing/StatCVS/ ITK CVS Statistics (Generated: 2008-02-28)]<br />
* [http://www.ohloh.net/projects/3240?p=Insight+Toolkit ITK in Ohloh]<br />
* [[ITK Code Coverage per Developer|Code Coverage per Developer]]<br />
* [[ITK Code Swarms]]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51056ITK/Cross Compiling2012-12-27T21:54:31Z<p>Ibanez: /* Packaging */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51055ITK/Cross Compiling2012-12-27T21:52:52Z<p>Ibanez: /* Packaging */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51054ITK/Cross Compiling2012-12-27T21:52:05Z<p>Ibanez: /* Packaging */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51053ITK/Cross Compiling2012-12-27T21:51:29Z<p>Ibanez: /* Using the Configuration in the Host */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51052ITK/Cross Compiling2012-12-27T21:43:33Z<p>Ibanez: /* Gathering Configuration settings in the target system */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=File:TryRunResults_ITK_RaspberryPi.cmake&diff=51051File:TryRunResults ITK RaspberryPi.cmake2012-12-27T21:42:47Z<p>Ibanez: Cross compilation file populated with native values from the Raspberry Pi</p>
<hr />
<div>Cross compilation file populated with native values from the Raspberry Pi</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51050ITK/Cross Compiling2012-12-27T21:42:12Z<p>Ibanez: /* Gathering Configuration settings in the target system */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51049ITK/Cross Compiling2012-12-27T21:40:48Z<p>Ibanez: /* Gathering Configuration settings in the target system */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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, here is a [[Media:CMakeCache_ITK_RaspberryPi.txt|CMakeCache.txt file from a native configuration in 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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=File:CMakeCache_ITK_RaspberryPi.txt&diff=51048File:CMakeCache ITK RaspberryPi.txt2012-12-27T21:37:33Z<p>Ibanez: CMakeCache resulting from configuring ITK in the Raspberry Pi.</p>
<hr />
<div>CMakeCache resulting from configuring ITK in the Raspberry Pi.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51047ITK/Cross Compiling2012-12-27T21:33:27Z<p>Ibanez: /* Building the ToolChain for ARM */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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 />
<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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51046ITK/Cross Compiling2012-12-27T21:32:45Z<p>Ibanez: /* Major steps */</p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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: http://www.kitware.com/blog/home/post/426<br />
based on the instructions from: 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 />
<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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Cross_Compiling&diff=51045ITK/Cross Compiling2012-12-27T21:28:10Z<p>Ibanez: </p>
<hr />
<div>__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 />
== 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 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-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]<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 Windows.<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 />
= 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 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 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-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]<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 Windows.<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</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Documentation&diff=49218ITK/Documentation2012-11-05T14:52:10Z<p>Ibanez: </p>
<hr />
<div>The following documentation is available for ITK:<br />
<br />
== Doxygen ==<br />
<br />
* [http://www.itk.org/Doxygen/html/index.html Nightly documentation]<br />
* [http://public.kitware.com/pub/itk/NightlyDoxygen/ Raw documentation files]<br />
* [http://www.itk.org/Doxygen42/html/index.html Most recent release documentation]<br />
* [http://www.itk.org/ITK/help/legacy_documentation.html Legacy releases documentation]<br />
<br />
== Examples ==<br />
<br />
* [[ITK/Examples|Examples Wiki: A community-maintained collection of examples of ITK classes and their uses.]]<br />
<br />
== Webinars ==<br />
<br />
* [http://itk.org/ITK/resources/webinars.html '''Kitware Webinars''': Didactic material and overviews of new releases.]<br />
* [http://insightsoftwareconsortium.github.com/ITKBarCamp-doc/index.html '''ITK BarCamp''': Training Grounds for the Next Generation of ITK Community Members]<br />
<br />
== Courses ==<br />
<br />
* [http://www.kitware.com/products/protraining.php '''Kitware Courses''': Multi-day workshops describing basic concepts and practices with interactive exercises and questioning. Available at Kitware or on site. Some example material found in the recorded webinars.]<br />
* [http://www.cs.cmu.edu/~galeotti/methods_course/ '''Carnegie Melon University''': Methods in Medical Image Analysis. Instruction by John Galeotti. Slides available. Video in the process of becoming available.]<br />
<br />
== Conference Workshops ==<br />
<br />
* [[ITK/Release_4/Outreach/Conferences/MICCAI_2011/ITKv4|MICCAI 2011 ITK]]<br />
* [[ITK/Release_4/Outreach/Conferences/MICCAI_2011/SimpleITK|MICCAI 2011 SimpleITK]]<br />
<br />
== Tutorials ==<br />
<br />
* [[ITK/Tutorials|Tutorials]]<br />
<br />
* [http://www.itk.org/HTML/Tutorials.htm '''Insight Toolkit Tutorials''': Presentations used for ITK Tutorials presented in conferences]<br />
<br />
* [http://www.itk.org/CourseWare/Training/GettingStartedI-WebPage/img0.html '''Getting Started Tutorial''': The tutorial that will save you time before you install and build ITK.]<br />
<br />
== Books ==<br />
<br />
* '''Insight Toolkit Software Guide''': A comprehensive 550-page guide to ITK, covering image processing, filters, pipelines, segmentation, and registration. Essential.<br />
** Download [http://www.itk.org/ItkSoftwareGuide.pdf PDF] (5.2Mb)<br />
** [http://www.kitware.com/products/itkguide.html Purchase hard copy]<br />
<br />
* '''Insight into Images''', Terry S. Yoo, editor, AK Peters, 2004, ISBN: 1-56881-217-5. The theory underlying the methods in ITK. As such, it serves as an extended reference for the Toolkit.<br />
** [http://www.akpeters.com/book.asp?bID=206 Hard copy ordering]<br />
<br />
{{ITK/Template/Footer}}</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Job_Opportunities&diff=48255ITK/Job Opportunities2012-06-30T18:17:55Z<p>Ibanez: </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 />
<br> <br />
<br />
-----------------<br />
<br />
== INSIGNEO Institute for in silico Medicine - Sheffield, UK ==<br />
<br />
Department of Mechanical Engineering, University of Sheffield<br />
<br />
Computational Imaging and Simulation Technologies in Biomedicine<br />
<br />
=== Positions Available ===<br />
<br />
Various R&D posts available: Research Fellow, Research Associate (3 posts), Scientific Software Developer (2 posts)<br />
<br />
http://www.jobs.ac.uk/enhanced/linking/sheffield/linkingpage3.html<br />
<br />
<br />
* Research Positions on Computational modelling and Simulation in Angiology: Profile CMSA-100101<br />
* Research Positions on Computational Modelling and Simulation in Cardiology: Profile CMSC-100105<br />
* Research Positions on Biomedical Information Management: Profile BIM-100107<br />
* Research Positions on Statistical Image Analysis: Profile SIA-100112<br />
* Junior Scientific Developers: Profile SSD-100109<br />
* Senior Scientific Developers: Profile SSD-100110<br />
* Research Positions on Musculoskeletal Computational Modelling: Profile IR-100114<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 />
CISTIB seeks proactive and talented junior and senior researchers with proven track record of publications in leading international journals and conferences. Candidates must hold a PhD degree and have expertise in the area of interest. Background or strong interest in biomedical engineering and proficiency in spoken and written English is expected.<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 />
The current open positions are advertised in<br />
<br />
http://www.jobs.ac.uk/enhanced/linking/sheffield/linkingpage3.html<br />
<br />
and each of the indicated positions will fit one of the profiles listed below:<br />
<br />
* Research Positions on Computational modelling and Simulation in Angiology: Profile CMSA-100101<br />
* Research Positions on Computational Modelling and Simulation in Cardiology: Profile CMSC-100105<br />
* Research Positions on Biomedical Information Management: Profile BIM-100107<br />
* Research Positions on Statistical Image Analysis: Profile SIA-100112<br />
* Junior Scientific Developers: Profile SSD-100109<br />
* Senior Scientific Developers: Profile SSD-100110<br />
* Research Positions on Musculoskeletal Computational Modelling: Profile IR-100114<br />
<br />
=== How to apply ===<br />
<br />
For more information or to apply, please email (quoting the Job Reference mentioned) a detailed CV with publication list and a concise description of research interests and future plans to a.frangi@sheffield.ac.uk. You should also apply through the web based system indicating the profile you fit to via the web linke http://www.jobs.ac.uk/enhanced/linking/sheffield/linkingpage3.html.<br />
<br />
<br />
== '''Job - Software Engineer in medical image processing (medInria) - INRIA Rennes - France ''' ==<br />
<br />
Posted June 26, 2012<br />
<br />
<br />
R&D Experienced software engineer / Good knowledge of ITK, VTK and Qt<br />
<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 />
<br />
-----------------<br />
<br />
== '''Job - Software Engineer / Research Specialist Lead - Emory University / Georgia Tech ''' ==<br />
<br />
Posted June 8, 2012<br />
<br />
<br />
Research Specialist Lead / Software Engineer<br />
<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 />
<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 />
<br />
<br />
<br />
-----------------<br />
<br />
== '''Software Developer - University of Utah''' ==<br />
<br />
Posted May 15, 2012<br />
<br />
The [http://www.carmacenter.org CARMA Center] is seeking a full-time C++ software developer. The position involves working with a large, interdisciplinary team of scientists and clinicians to implement and evaluate new image-based computational algorithms and software for the treatment of cardiac disease and the study of its underlying causes.<br />
<br />
The CARMA Center is looking for an individual who is available for a full-time commitment and has completed a Bachelor’s degree in Computer Science, Computer Engineering, or a related field with similar mathematical and computational experience.<br />
<br />
Applicants must demonstrate strong C++ programming skills, be self-motivated, and possess good organizational and communication skills. Image processing experience and familiarity with the ITK and VTK toolkits are especially desirable, but not required, provided the applicant has sufficient technical background and interest to learn.<br />
<br />
Web site: http://www.healthsciences.utah.edu/carma/jobs_volunteer.html<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<br />
C++ programmer to support the development of ITK-SNAP, an interactive<br />
software application for biomedical image segmentation. The programmer will<br />
work with the principal investigator on an NIH-funded grant to develop the<br />
next-generation GUI for ITK-SNAP, accelerate the tool=92s performance, and<br />
incorporate multi-modality image segmentation algorithms. Applicants must<br />
have a Bachelors degree in computer science or related field. Minimal<br />
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<br />
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<br />
biomedical imaging projects, including development of novel analysis<br />
methodologies; application of the state-of-the-art techniques to clinical<br />
studies; and translational research. PICSL is located in Philadelphia, a<br />
vibrant city that offers many professional and cultural opportunities.<br />
PICSL fosters a friendly, noncompetitive, collaborative environment where<br />
each individual member of the laboratory is able to thrive, while also<br />
effectively contributing to the group=92s overall programmatic aims.<br />
<br />
The position is funded by a federal grant. Continued employment is subject<br />
to performance and availability of grant funding. PICSL has an excellent<br />
track record of obtaining research funding and personnel retention. The<br />
position features a competitive compensation package with generous fringe<br />
benefits.<br />
<br />
The University of Pennsylvania is an equal opportunity, affirmative action<br />
employer. Women and minority candidates are strongly encouraged to apply.<br />
<br />
Interested candidates should send an email to the address below. Please<br />
include the words =93snap developer=94 on the subject line. Include a brief<br />
statement of qualifications relevant to the project, a CV or resume, and a<br />
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 />
-----------------<br />
<br />
== '''Software Engineer(s)-Electrical Geodesics, Inc.''' ==<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 />
<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 />
<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 />
<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 />
<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 />
<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 />
The UEB - UR1 seeks research scientist applicants working in the broad<br />
field of biomedical engineering, with particular focus on themes at<br />
the frontiers of ICT and health. Of special interest are the following<br />
topics: model-based bio-signal / bio-imaging processing and<br />
interpretation, integrative modeling, knowledge-based information<br />
representation and interpretation.<br />
The UEB - UR 1 laboratories involved in biomedical engineering have<br />
strong clinical partnerships with a number of medical institutions,<br />
including the Rennes University Hospital and the Centre of Cancer<br />
Eugène Marquis at Rennes.<br />
Qualified candidates working in the broad area of biomedical<br />
engineering, developing computational tools or multiscale<br />
systems-based techniques are encouraged to apply. Required<br />
qualifications include a doctorate in engineering or a related field<br />
with an outstanding record of publications in internationally<br />
recognized journals.<br />
Interested persons should submit detailed curriculum vitae including<br />
academic and professional experience, a list of peer-reviewed<br />
publications and any other technical documents relevant to the<br />
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 />
== 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<br />
Medical School seeks to hire a Software Engineer for participating in the<br />
continued development of GoFigure. The lab’s goal is to understand embryonic<br />
development as the execution of a program in our genome. We seek to upload<br />
embryonic development into a virtual life form called the Digital Fish<br />
through the use of genetics, molecular imaging, and information technology<br />
(www.digitalfish.org). The Software Engineer will be responsible for<br />
participating in the continued development of the principle software<br />
application for this endeavor called GoFigure. GoFigure recognizes and<br />
tracks cells in extremely large 4-dimensional (xyzt) image sets and<br />
digitizes that data into a database. GoFigure is written in C++, is<br />
cross-platform and uses Qt, MySQL, VTK (the Visualization Toolkit), ITK<br />
(Insight Segmentation and Registration Toolkit), CMake. The project is<br />
managed using Subversion, Doxygen for documentation generation, CTest and<br />
CDash for testing. The successful applicant should have a strong background<br />
in programming and work well in an academic environment. Interests in<br />
application development, image processing, microscopy, and systems biology<br />
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 />
== 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 />
== 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><br />
<br />
== Software Engineer, Intuitive Surgical Inc., Sunnyvale California ==<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><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 />
== 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 />
<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 />
<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 />
<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 />
== 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 />
== November 2004: Kitware ==<br />
<br />
Kitware is seeking to fill positions immediately. We are looking for people <br />
who will relocate to the Albany, NY USA area, are willing to work in a <br />
small company, and show flexibility in work assignments. Important skills <br />
include proficiency in C++, scientific software development, medical image <br />
analysis, and/or ITK. Individuals demonstrating expertise in areas that <br />
significantly extend Kitware's software skill base are particularly <br />
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<br />
vision technology for commercial and government applications. We are<br />
particularly interested in recruiting candidates with expertise in one of<br />
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,<br />
NY conducts basic and applied research in computer vision and closely<br />
related areas. With 30 Staff Researchers (most holding a PhD) the lab<br />
develops advanced technologies for GE businesses, including GE Security, GE<br />
Healthcare, GE Aircraft Engines, GE Power Systems and NBC Universal;<br />
Lockheed Martin; and US Government agencies including NIH, DARPA, FBI, AFRL<br />
and NIMA. Areas of active research include image segmentation, deformable<br />
registration, perceptual organization, texture classification, object<br />
detection, event recognition, tracking, camera calibration, optical<br />
metrology, video content extraction, change detection, and superresolution.<br />
<br />
We are active users and contributors to ITK and VXL; experience with either<br />
of these toolkits is desired. Strong C++ skills along with a superior<br />
ability to work in a team environment are essential qualities for successful<br />
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>Ibanezhttps://public.kitware.com/Wiki/index.php?title=User_talk:Kindlmann&diff=48041User talk:Kindlmann2012-06-18T23:42:44Z<p>Ibanez: Deleted Spam</p>
<hr />
<div></div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=47108ITK/Coding Style Guide2012-05-19T20:31:09Z<p>Ibanez: /* Use of Braces */</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 />
<br />
exible 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<br />
* '''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<br />
* '''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 for 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 />
exibility 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 />
==== 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. Unfortuneatly, 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<br />
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 />
==== 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 />
==== 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 100 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<br />
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<br />
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 />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
namespace itk<br />
{<br />
ITK Style Guide 11<br />
template <class TPixel, unsigned int VImageDimension=2,<br />
class TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class ITK_EXPORT Image : public ImageBase<VImageDimension><br />
{<br />
public:<br />
....stuff...<br />
protected:<br />
....stuff...<br />
private:<br />
....stuff...<br />
};<br />
}//end of namespace<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
#endif //end include guard<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<class TPixel, unsigned int VImageDimension, class TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
...<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 (i=0; i<3; i++)<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.<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 />
<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>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=47107ITK/Coding Style Guide2012-05-19T20:30:31Z<p>Ibanez: /* Use of Braces */</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 />
<br />
exible 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<br />
* '''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<br />
* '''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 for 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 />
exibility 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 />
==== 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. Unfortuneatly, 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<br />
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 />
==== 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 />
==== 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 100 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<br />
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<br />
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 />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
namespace itk<br />
{<br />
ITK Style Guide 11<br />
template <class TPixel, unsigned int VImageDimension=2,<br />
class TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class ITK_EXPORT Image : public ImageBase<VImageDimension><br />
{<br />
public:<br />
....stuff...<br />
protected:<br />
....stuff...<br />
private:<br />
....stuff...<br />
};<br />
}//end of namespace<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
#endif //end include guard<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<class TPixel, unsigned int VImageDimension, class TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
...<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 (i=0; i<3; i++)<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 />
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.<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 />
<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>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials/ISBI2012&diff=46581ITK/Tutorials/ISBI20122012-04-17T18:26:04Z<p>Ibanez: /* Abstract */</p>
<hr />
<div>__TOC__<br />
<br />
= Event - ISBI 2012 =<br />
<br />
This tutorial will be presented at the [http://www.biomedicalimaging.org/ ISBI 2012 conference in Barcelona, Spain]<br />
<br />
= Title =<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Tutorial: T-4: Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Time and Place =<br />
<br />
The tutorial will take place<br />
<br />
* Wednesday May 2nd<br />
* 8:30am to 12:30pm<br />
* [https://www.securecms.com/ISBI2012/RegularProgram.asp?location=Room+127 Room 127]<br />
<br />
See here the [https://www.securecms.com/ISBI2012/RegularProgram.asp Conference Program]<br />
<br />
<br />
Full details in the following link:<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Abstract =<br />
<br />
This tutorial will introduce attendees to the new features of ITKv4, including among others: <br />
<br />
* The modularization of the toolkit<br />
* The new frameworks for<br />
** Statistics<br />
** Image registration<br />
** Level sets<br />
* The refactored FEM framework<br />
* The new support for video processing<br />
** ITK Video filters<br />
** ITK-OpenCV Bridge<br />
** ITK-VXL Bridge<br />
* The new simplified layer SimpleITK.<br />
<br />
The tutorial will follow a hands-on format, in which the attendees will receive USB memory sticks with a fully configured Virtual Machine containing an installation of ITKv4, OpenCV, VXL and their respective bridges. Hands on exercises will include a familiarization with the new process by which contributions can be brought back into the toolkit.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials/ISBI2012&diff=46577ITK/Tutorials/ISBI20122012-04-17T18:17:25Z<p>Ibanez: /* Abstract */</p>
<hr />
<div>__TOC__<br />
<br />
= Event - ISBI 2012 =<br />
<br />
This tutorial will be presented at the [http://www.biomedicalimaging.org/ ISBI 2012 conference in Barcelona, Spain]<br />
<br />
= Title =<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Tutorial: T-4: Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Time and Place =<br />
<br />
The tutorial will take place<br />
<br />
* Wednesday May 2nd<br />
* 8:30am to 12:30pm<br />
* [https://www.securecms.com/ISBI2012/RegularProgram.asp?location=Room+127 Room 127]<br />
<br />
See here the [https://www.securecms.com/ISBI2012/RegularProgram.asp Conference Program]<br />
<br />
<br />
Full details in the following link:<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Abstract =<br />
<br />
This tutorial will introduce attendees to the new features of ITKv4, including among others: <br />
<br />
* The modularization of the toolkit<br />
* The new frameworks for<br />
** Statistics<br />
** Image registration<br />
** Level sets<br />
* The refactored FEM framework<br />
* The new support for video processing and<br />
* The new simplified layer SimpleITK.<br />
<br />
The tutorial will follow a hands-on format, in which the attendees will receive USB memory sticks with a fully configured Virtual Machine containing an installation of ITKv4, OpenCV, VXL and their respective bridges. Hands on exercises will include a familiarization with the new process by which contributions can be brought back into the toolkit.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials/ISBI2012&diff=46576ITK/Tutorials/ISBI20122012-04-17T18:12:52Z<p>Ibanez: /* Title */</p>
<hr />
<div>__TOC__<br />
<br />
= Event - ISBI 2012 =<br />
<br />
This tutorial will be presented at the [http://www.biomedicalimaging.org/ ISBI 2012 conference in Barcelona, Spain]<br />
<br />
= Title =<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Tutorial: T-4: Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Time and Place =<br />
<br />
The tutorial will take place<br />
<br />
* Wednesday May 2nd<br />
* 8:30am to 12:30pm<br />
* [https://www.securecms.com/ISBI2012/RegularProgram.asp?location=Room+127 Room 127]<br />
<br />
See here the [https://www.securecms.com/ISBI2012/RegularProgram.asp Conference Program]<br />
<br />
<br />
Full details in the following link:<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Abstract =<br />
<br />
This tutorial will introduce attendees to the new features of ITKv4, including among others: <br />
<br />
* The modularization of the toolkit<br />
* The new frameworks for<br />
** Statistics<br />
** Image registration<br />
** Level sets<br />
* The refactored FEM framework<br />
* The new support for video processing and<br />
* The new simplified layer 'SimpleITK'.<br />
<br />
The tutorial will follow a hands-on format, in which the attendees will receive USB memory sticks with a fully configured Virtual Machine containing an installation of ITKv4, OpenCV, VXL and their respective bridges. Hands on exercises will include a familiarization with the new process by which contributions can be brought back into the toolkit.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials/ISBI2012&diff=46575ITK/Tutorials/ISBI20122012-04-17T18:12:08Z<p>Ibanez: /* Time and Place */</p>
<hr />
<div>__TOC__<br />
<br />
= Event - ISBI 2012 =<br />
<br />
This tutorial will be presented at the [http://www.biomedicalimaging.org/ ISBI 2012 conference in Barcelona, Spain]<br />
<br />
= Title =<br />
<br />
* Tutorial: T-4: Use of ITKv4 (and VTK) in biological imaging<br />
<br />
= Time and Place =<br />
<br />
The tutorial will take place<br />
<br />
* Wednesday May 2nd<br />
* 8:30am to 12:30pm<br />
* [https://www.securecms.com/ISBI2012/RegularProgram.asp?location=Room+127 Room 127]<br />
<br />
See here the [https://www.securecms.com/ISBI2012/RegularProgram.asp Conference Program]<br />
<br />
<br />
Full details in the following link:<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Abstract =<br />
<br />
This tutorial will introduce attendees to the new features of ITKv4, including among others: <br />
<br />
* The modularization of the toolkit<br />
* The new frameworks for<br />
** Statistics<br />
** Image registration<br />
** Level sets<br />
* The refactored FEM framework<br />
* The new support for video processing and<br />
* The new simplified layer 'SimpleITK'.<br />
<br />
The tutorial will follow a hands-on format, in which the attendees will receive USB memory sticks with a fully configured Virtual Machine containing an installation of ITKv4, OpenCV, VXL and their respective bridges. Hands on exercises will include a familiarization with the new process by which contributions can be brought back into the toolkit.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials/ISBI2012&diff=46574ITK/Tutorials/ISBI20122012-04-17T18:11:03Z<p>Ibanez: /* Time and Place */</p>
<hr />
<div>__TOC__<br />
<br />
= Event - ISBI 2012 =<br />
<br />
This tutorial will be presented at the [http://www.biomedicalimaging.org/ ISBI 2012 conference in Barcelona, Spain]<br />
<br />
= Title =<br />
<br />
* Tutorial: T-4: Use of ITKv4 (and VTK) in biological imaging<br />
<br />
= Time and Place =<br />
<br />
The tutorial will take place<br />
<br />
* Wednesday May 2nd<br />
* 8:30am to 12:30pm<br />
* Room 127<br />
<br />
See here the [https://www.securecms.com/ISBI2012/RegularProgram.asp Conference Program]<br />
<br />
<br />
Full details in the following link:<br />
<br />
* [http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
= Abstract =<br />
<br />
This tutorial will introduce attendees to the new features of ITKv4, including among others: <br />
<br />
* The modularization of the toolkit<br />
* The new frameworks for<br />
** Statistics<br />
** Image registration<br />
** Level sets<br />
* The refactored FEM framework<br />
* The new support for video processing and<br />
* The new simplified layer 'SimpleITK'.<br />
<br />
The tutorial will follow a hands-on format, in which the attendees will receive USB memory sticks with a fully configured Virtual Machine containing an installation of ITKv4, OpenCV, VXL and their respective bridges. Hands on exercises will include a familiarization with the new process by which contributions can be brought back into the toolkit.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials/ISBI2012&diff=46573ITK/Tutorials/ISBI20122012-04-17T18:10:18Z<p>Ibanez: /* Event - ISBI 2012 */</p>
<hr />
<div>__TOC__<br />
<br />
= Event - ISBI 2012 =<br />
<br />
This tutorial will be presented at the [http://www.biomedicalimaging.org/ ISBI 2012 conference in Barcelona, Spain]<br />
<br />
= Title =<br />
<br />
* Tutorial: T-4: Use of ITKv4 (and VTK) in biological imaging<br />
<br />
= Time and Place =<br />
<br />
The tutorial will take place<br />
<br />
* Wednesday May 2nd<br />
* 8:30am to 12:30pm<br />
* Room 127<br />
<br />
See here the [https://www.securecms.com/ISBI2012/RegularProgram.asp Ponference Program]<br />
<br />
<br />
[http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
<br />
= Abstract =<br />
<br />
This tutorial will introduce attendees to the new features of ITKv4, including among others: <br />
<br />
* The modularization of the toolkit<br />
* The new frameworks for<br />
** Statistics<br />
** Image registration<br />
** Level sets<br />
* The refactored FEM framework<br />
* The new support for video processing and<br />
* The new simplified layer 'SimpleITK'.<br />
<br />
The tutorial will follow a hands-on format, in which the attendees will receive USB memory sticks with a fully configured Virtual Machine containing an installation of ITKv4, OpenCV, VXL and their respective bridges. Hands on exercises will include a familiarization with the new process by which contributions can be brought back into the toolkit.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials/ISBI2012&diff=46572ITK/Tutorials/ISBI20122012-04-17T18:09:37Z<p>Ibanez: Created page with "__TOC__ = Event - ISBI 2012 = This tutorial will be presented at the ISBI 2012 conference in Barcelona, Spain = Title = * Tutorial: T-4: Use of ITKv4 (and VTK) in biological ..."</p>
<hr />
<div>__TOC__<br />
<br />
= Event - ISBI 2012 =<br />
<br />
This tutorial will be presented at the ISBI 2012 conference in Barcelona, Spain<br />
<br />
= Title =<br />
<br />
* Tutorial: T-4: Use of ITKv4 (and VTK) in biological imaging<br />
<br />
= Time and Place =<br />
<br />
The tutorial will take place<br />
<br />
* Wednesday May 2nd<br />
* 8:30am to 12:30pm<br />
* Room 127<br />
<br />
See here the [https://www.securecms.com/ISBI2012/RegularProgram.asp Ponference Program]<br />
<br />
<br />
[http://www.biomedicalimaging.org/index.php/programme/tutorials/16-tutorials/87-tutorial-03 Use of ITKv4 (and VTK) in biological imaging]<br />
<br />
<br />
= Abstract =<br />
<br />
This tutorial will introduce attendees to the new features of ITKv4, including among others: <br />
<br />
* The modularization of the toolkit<br />
* The new frameworks for<br />
** Statistics<br />
** Image registration<br />
** Level sets<br />
* The refactored FEM framework<br />
* The new support for video processing and<br />
* The new simplified layer 'SimpleITK'.<br />
<br />
The tutorial will follow a hands-on format, in which the attendees will receive USB memory sticks with a fully configured Virtual Machine containing an installation of ITKv4, OpenCV, VXL and their respective bridges. Hands on exercises will include a familiarization with the new process by which contributions can be brought back into the toolkit.</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tutorials&diff=46571ITK/Tutorials2012-04-17T18:01:36Z<p>Ibanez: </p>
<hr />
<div>== General Tutorials ==<br />
<br />
* [http://www.itk.org/HTML/Tutorials.htm Official tutorials]<br />
<br />
* [[ITK/Complete Setup|Quick Tutorial on How to Build ITK+VTK+FLTK]]<br />
<br />
== Developer Tutorials ==<br />
* [[ITK/Tutorials/DOs and DONTs | ITK Do's and Don't's]]<br />
<br />
== External Tutorials ==<br />
* [http://farsight-toolkit.org/wiki/FARSIGHT_Tutorials/Building_Software How to build ITK + WrapITK]<br />
<br />
* [http://farsight-toolkit.org/wiki/FARSIGHT_Tutorials/Just_Installing_Software How to Install a binary of ITK + Python wrapping]<br />
<br />
* [http://farsight-toolkit.org/wiki/FARSIGHT_Tutorials/Quick_Start How to use ITK + Python Wrapping]<br />
<br />
== Technical tutorials ==<br />
* [[ITK/Tutorials/WatershedBasedSegmentation | Watershed-Based Segmentation]]<br />
* [[ITK/Tutorials/ISBI2012 | ISBI 2012]]<br />
<br />
<br />
{{ITK/Template/Footer}}</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_30&diff=46418ITK/Tcons/Minutes/2012 03 302012-03-30T14:51:26Z<p>Ibanez: /* Attendees */</p>
<hr />
<div>= Attendees =<br />
<br />
* Jim Miller<br />
* Brad Lowekamp<br />
* Matt McCormick<br />
* Xiaoxiao Liu<br />
* Nick Tustison<br />
* Brian Avants<br />
<br />
= Project Topics =<br />
<br />
<br />
== Cycles ==<br />
<br />
<br />
= Technical Topics =<br />
<br />
<br />
== Dashboard ==<br />
<br />
<br />
== Gerrit ==<br />
<br />
<br />
== Status ==<br />
<br />
= Action Items =</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_30&diff=46417ITK/Tcons/Agendas/2012 03 302012-03-30T14:47:59Z<p>Ibanez: /* JIRA */</p>
<hr />
<div>= TCON CANCELLED =<br />
<br />
<br />
= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
* Modular Dashboard<br />
** http://open.cdash.org/index.php?project=ITKModular&date=<br />
<br />
== JIRA ==<br />
<br />
* https://itk.icts.uiowa.edu/jira/browse/ITK<br />
* https://issues.itk.org/jira/browse/ITK-2893<br />
<br />
== Gerrit ==<br />
<br />
* http://review.source.kitware.com/#/c/4807/</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_30&diff=46415ITK/Tcons/Agendas/2012 03 302012-03-30T14:27:09Z<p>Ibanez: /* Release Schedule */</p>
<hr />
<div>= TCON CANCELLED =<br />
<br />
<br />
= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
* Modular Dashboard<br />
** http://open.cdash.org/index.php?project=ITKModular&date=<br />
<br />
== JIRA ==<br />
<br />
* https://itk.icts.uiowa.edu/jira/browse/ITK</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_30&diff=46414ITK/Tcons/Agendas/2012 03 302012-03-30T14:20:51Z<p>Ibanez: /* Dashboard */</p>
<hr />
<div>= TCON CANCELLED =<br />
<br />
<br />
= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
* Modular Dashboard<br />
** http://open.cdash.org/index.php?project=ITKModular&date=</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_30&diff=46412ITK/Tcons/Agendas/2012 03 302012-03-30T13:34:45Z<p>Ibanez: Created page with "= TCON CANCELLED = = How to Join the Tcon = == Number to Call == '''Please be patient, due to some unforeseen circumstances, the call may not start on time...''' * 1-800-72..."</p>
<hr />
<div>= TCON CANCELLED =<br />
<br />
<br />
= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_30&diff=46411ITK/Tcons/Minutes/2012 03 302012-03-30T13:34:29Z<p>Ibanez: Created page with "= Attendees = = Project Topics = == Cycles == = Technical Topics = == Dashboard == == Gerrit == == Status == = Action Items ="</p>
<hr />
<div>= Attendees =<br />
<br />
<br />
= Project Topics =<br />
<br />
<br />
== Cycles ==<br />
<br />
<br />
= Technical Topics =<br />
<br />
<br />
== Dashboard ==<br />
<br />
<br />
== Gerrit ==<br />
<br />
<br />
== Status ==<br />
<br />
= Action Items =</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Telephone_Conference_Agendas_and_Minutes&diff=46410ITK/Telephone Conference Agendas and Minutes2012-03-30T13:33:12Z<p>Ibanez: /* March */</p>
<hr />
<div>= ITK Tcons =<br />
<br />
* [[ITK/Tcons]]<br />
* [[ITK/Tcons/Agendas]]<br />
* [[ITK/Tcons/Minutes]]<br />
<br />
= 2012 =<br />
<br />
== March ==<br />
<br />
* Mar 30, 2012 - [[ITK/Tcons/Agendas/2012_03_30|Agenda]] [[ITK/Tcons/Minutes/2012_03_30|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 23, 2012 - [[ITK/Tcons/Agendas/2012_03_23|Agenda]] [[ITK/Tcons/Minutes/2012_03_23|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 16, 2012 - [[ITK/Tcons/Agendas/2012_03_16|Agenda]] [[ITK/Tcons/Minutes/2012_03_16|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 9, 2012 - [[ITK/Tcons/Agendas/2012_03_09|Agenda]] [[ITK/Tcons/Minutes/2012_03_09|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 2, 2012 - [[ITK/Tcons/Agendas/2012_03_02|Agenda]] [[ITK/Tcons/Minutes/2012_03_02|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== February ==<br />
<br />
* Feb 24, 2012 - [[ITK/Tcons/Agendas/2012_02_24|Agenda]] [[ITK/Tcons/Minutes/2012_02_24|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 17, 2012 - [[ITK/Tcons/Agendas/2012_02_17|Agenda]] [[ITK/Tcons/Minutes/2012_02_17|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 10, 2012 - [[ITK/Tcons/Agendas/2012_02_10|Agenda]] [[ITK/Tcons/Minutes/2012_02_10|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 3, 2012 - [[ITK/Tcons/Agendas/2012_02_03|Agenda]] [[ITK/Tcons/Minutes/2012_02_03|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== January ==<br />
<br />
* Jan 27, 2012 - [[ITK/Tcons/Agendas/2012_01_27|Agenda]] [[ITK/Tcons/Minutes/2012_01_27|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Jan 20, 2012 - [[ITK/Tcons/Agendas/2012_01_20|Agenda]] [[ITK/Tcons/Minutes/2012_01_20|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
= Archives 2006-2011 =<br />
<br />
[[ITK Telephone Conference Agendas and Minutes/Archives|Archives 2006-2011]]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_23&diff=46376ITK/Tcons/Minutes/2012 03 232012-03-23T14:07:02Z<p>Ibanez: </p>
<hr />
<div>= TCON WAS CANCELLED =</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_23&diff=46375ITK/Tcons/Agendas/2012 03 232012-03-23T14:06:43Z<p>Ibanez: </p>
<hr />
<div>= TCON CANCELLED =<br />
<br />
<br />
= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
==== Problems Reported in Debian Packaging ====<br />
<br />
* Failing FFT tests in 32 bits.<br />
* https://buildd.debian.org/status/package.php?p=insighttoolkit4&suite=experimental<br />
<br />
==== Summary of Failing Tests ====<br />
<br />
<br />
*[http://open.cdash.org/testSummary.php?project=2&name=DigitallyReconstructedRadiograph1Test&date=2012-03-02 DigitallyReconstructedRadiograph1Test] Failing on a few platforms. Test image look like there is a real bug.<br />
*Failing Tiff Tests<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkTIFFImageIOSpacing&date=2012-03-02 itkTIFFImageIOSpacing] Big Endian issues<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkDiscreteGaussianImageFilterTest2&date=2012-03-02 itkDiscreteGaussianImageFilterTest2] Big Endian Issue<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkLargeTIFFImageWriteReadTest3&date=2012-03-01 itkLargeTIFFImageWriteReadTest3] Large File issue<br />
*[http://open.cdash.org/testSummary.php?project=2&name=itkMeshFileReadWriteTest10&date=2012-03-01 itkMeshFileReadWriteTest10] Failing on windows and Big Endian Likely some real bugs here<br />
<br />
==== Summary of Warnings ====<br />
<br />
* What Warnings?<br />
* [http://open.cdash.org/viewBuildError.php?type=1&buildid=2055808 Warning from try compile?]<br />
* gcc 4.1 ( still standard with Red Hat Enterprise 5.7 )<br />
** [http://open.cdash.org/viewBuildError.php?type=1&buildid=2051588 Lots of warnings]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_23&diff=46374ITK/Tcons/Agendas/2012 03 232012-03-23T14:01:56Z<p>Ibanez: Created page with "= How to Join the Tcon = == Number to Call == '''Please be patient, due to some unforeseen circumstances, the call may not start on time...''' * 1-800-728-9607 (in the US) or..."</p>
<hr />
<div>= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
==== Problems Reported in Debian Packaging ====<br />
<br />
* Failing FFT tests in 32 bits.<br />
* https://buildd.debian.org/status/package.php?p=insighttoolkit4&suite=experimental<br />
<br />
==== Summary of Failing Tests ====<br />
<br />
<br />
*[http://open.cdash.org/testSummary.php?project=2&name=DigitallyReconstructedRadiograph1Test&date=2012-03-02 DigitallyReconstructedRadiograph1Test] Failing on a few platforms. Test image look like there is a real bug.<br />
*Failing Tiff Tests<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkTIFFImageIOSpacing&date=2012-03-02 itkTIFFImageIOSpacing] Big Endian issues<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkDiscreteGaussianImageFilterTest2&date=2012-03-02 itkDiscreteGaussianImageFilterTest2] Big Endian Issue<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkLargeTIFFImageWriteReadTest3&date=2012-03-01 itkLargeTIFFImageWriteReadTest3] Large File issue<br />
*[http://open.cdash.org/testSummary.php?project=2&name=itkMeshFileReadWriteTest10&date=2012-03-01 itkMeshFileReadWriteTest10] Failing on windows and Big Endian Likely some real bugs here<br />
<br />
==== Summary of Warnings ====<br />
<br />
* What Warnings?<br />
* [http://open.cdash.org/viewBuildError.php?type=1&buildid=2055808 Warning from try compile?]<br />
* gcc 4.1 ( still standard with Red Hat Enterprise 5.7 )<br />
** [http://open.cdash.org/viewBuildError.php?type=1&buildid=2051588 Lots of warnings]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_23&diff=46373ITK/Tcons/Minutes/2012 03 232012-03-23T14:01:47Z<p>Ibanez: Created page with "= Attendees = = Project Topics = == Cycles == = Technical Topics = == Dashboard == == Gerrit == == Status == = Action Items ="</p>
<hr />
<div>= Attendees =<br />
<br />
<br />
= Project Topics =<br />
<br />
<br />
== Cycles ==<br />
<br />
<br />
= Technical Topics =<br />
<br />
<br />
== Dashboard ==<br />
<br />
<br />
== Gerrit ==<br />
<br />
<br />
== Status ==<br />
<br />
= Action Items =</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Telephone_Conference_Agendas_and_Minutes&diff=46372ITK/Telephone Conference Agendas and Minutes2012-03-23T14:00:57Z<p>Ibanez: /* March */</p>
<hr />
<div>= ITK Tcons =<br />
<br />
* [[ITK/Tcons]]<br />
* [[ITK/Tcons/Agendas]]<br />
* [[ITK/Tcons/Minutes]]<br />
<br />
= 2012 =<br />
<br />
== March ==<br />
<br />
* Mar 23, 2012 - [[ITK/Tcons/Agendas/2012_03_23|Agenda]] [[ITK/Tcons/Minutes/2012_03_23|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 16, 2012 - [[ITK/Tcons/Agendas/2012_03_16|Agenda]] [[ITK/Tcons/Minutes/2012_03_16|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 9, 2012 - [[ITK/Tcons/Agendas/2012_03_09|Agenda]] [[ITK/Tcons/Minutes/2012_03_09|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 2, 2012 - [[ITK/Tcons/Agendas/2012_03_02|Agenda]] [[ITK/Tcons/Minutes/2012_03_02|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== February ==<br />
<br />
* Feb 24, 2012 - [[ITK/Tcons/Agendas/2012_02_24|Agenda]] [[ITK/Tcons/Minutes/2012_02_24|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 17, 2012 - [[ITK/Tcons/Agendas/2012_02_17|Agenda]] [[ITK/Tcons/Minutes/2012_02_17|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 10, 2012 - [[ITK/Tcons/Agendas/2012_02_10|Agenda]] [[ITK/Tcons/Minutes/2012_02_10|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 3, 2012 - [[ITK/Tcons/Agendas/2012_02_03|Agenda]] [[ITK/Tcons/Minutes/2012_02_03|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== January ==<br />
<br />
* Jan 27, 2012 - [[ITK/Tcons/Agendas/2012_01_27|Agenda]] [[ITK/Tcons/Minutes/2012_01_27|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Jan 20, 2012 - [[ITK/Tcons/Agendas/2012_01_20|Agenda]] [[ITK/Tcons/Minutes/2012_01_20|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
= Archives 2006-2011 =<br />
<br />
[[ITK Telephone Conference Agendas and Minutes/Archives|Archives 2006-2011]]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_16&diff=46312ITK/Tcons/Minutes/2012 03 162012-03-16T15:03:29Z<p>Ibanez: Created page with "= Attendees = * Jim Miller * Brad Lowekamp * Matt McCormick * Xiaoxiao Liu * Luis Ibanez = Project Topics = == Cycles == = Technical Topics = == Dashboard == == Gerrit ..."</p>
<hr />
<div>= Attendees =<br />
<br />
* Jim Miller<br />
* Brad Lowekamp<br />
* Matt McCormick<br />
* Xiaoxiao Liu<br />
* Luis Ibanez<br />
<br />
= Project Topics =<br />
<br />
<br />
== Cycles ==<br />
<br />
<br />
= Technical Topics =<br />
<br />
<br />
== Dashboard ==<br />
<br />
<br />
== Gerrit ==<br />
<br />
<br />
== Status ==<br />
<br />
= Action Items =</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_16&diff=46311ITK/Tcons/Agendas/2012 03 162012-03-16T14:30:09Z<p>Ibanez: Created page with "= How to Join the Tcon = == Number to Call == '''Please be patient, due to some unforeseen circumstances, the call may not start on time...''' * 1-800-728-9607 (in the US) or..."</p>
<hr />
<div>= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
==== Problems Reported in Debian Packaging ====<br />
<br />
* Failing FFT tests in 32 bits.<br />
* https://buildd.debian.org/status/package.php?p=insighttoolkit4&suite=experimental<br />
<br />
==== Summary of Failing Tests ====<br />
<br />
<br />
*[http://open.cdash.org/testSummary.php?project=2&name=DigitallyReconstructedRadiograph1Test&date=2012-03-02 DigitallyReconstructedRadiograph1Test] Failing on a few platforms. Test image look like there is a real bug.<br />
*Failing Tiff Tests<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkTIFFImageIOSpacing&date=2012-03-02 itkTIFFImageIOSpacing] Big Endian issues<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkDiscreteGaussianImageFilterTest2&date=2012-03-02 itkDiscreteGaussianImageFilterTest2] Big Endian Issue<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkLargeTIFFImageWriteReadTest3&date=2012-03-01 itkLargeTIFFImageWriteReadTest3] Large File issue<br />
*[http://open.cdash.org/testSummary.php?project=2&name=itkMeshFileReadWriteTest10&date=2012-03-01 itkMeshFileReadWriteTest10] Failing on windows and Big Endian Likely some real bugs here<br />
<br />
==== Summary of Warnings ====<br />
<br />
* What Warnings?<br />
* [http://open.cdash.org/viewBuildError.php?type=1&buildid=2055808 Warning from try compile?]<br />
* gcc 4.1 ( still standard with Red Hat Enterprise 5.7 )<br />
** [http://open.cdash.org/viewBuildError.php?type=1&buildid=2051588 Lots of warnings]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Telephone_Conference_Agendas_and_Minutes&diff=46310ITK/Telephone Conference Agendas and Minutes2012-03-16T14:10:21Z<p>Ibanez: /* March */</p>
<hr />
<div>= ITK Tcons =<br />
<br />
* [[ITK/Tcons]]<br />
* [[ITK/Tcons/Agendas]]<br />
* [[ITK/Tcons/Minutes]]<br />
<br />
= 2012 =<br />
<br />
== March ==<br />
<br />
* Mar 16, 2012 - [[ITK/Tcons/Agendas/2012_03_16|Agenda]] [[ITK/Tcons/Minutes/2012_03_16|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 9, 2012 - [[ITK/Tcons/Agendas/2012_03_09|Agenda]] [[ITK/Tcons/Minutes/2012_03_09|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 2, 2012 - [[ITK/Tcons/Agendas/2012_03_02|Agenda]] [[ITK/Tcons/Minutes/2012_03_02|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== February ==<br />
<br />
* Feb 24, 2012 - [[ITK/Tcons/Agendas/2012_02_24|Agenda]] [[ITK/Tcons/Minutes/2012_02_24|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 17, 2012 - [[ITK/Tcons/Agendas/2012_02_17|Agenda]] [[ITK/Tcons/Minutes/2012_02_17|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 10, 2012 - [[ITK/Tcons/Agendas/2012_02_10|Agenda]] [[ITK/Tcons/Minutes/2012_02_10|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 3, 2012 - [[ITK/Tcons/Agendas/2012_02_03|Agenda]] [[ITK/Tcons/Minutes/2012_02_03|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== January ==<br />
<br />
* Jan 27, 2012 - [[ITK/Tcons/Agendas/2012_01_27|Agenda]] [[ITK/Tcons/Minutes/2012_01_27|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Jan 20, 2012 - [[ITK/Tcons/Agendas/2012_01_20|Agenda]] [[ITK/Tcons/Minutes/2012_01_20|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
= Archives 2006-2011 =<br />
<br />
[[ITK Telephone Conference Agendas and Minutes/Archives|Archives 2006-2011]]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_09&diff=46273ITK/Tcons/Agendas/2012 03 092012-03-09T15:22:07Z<p>Ibanez: /* Problems Reported in Debian Packaging */</p>
<hr />
<div>= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
==== Problems Reported in Debian Packaging ====<br />
<br />
* Failing FFT tests in 32 bits.<br />
* https://buildd.debian.org/status/package.php?p=insighttoolkit4&suite=experimental<br />
<br />
==== Summary of Failing Tests ====<br />
<br />
<br />
*[http://open.cdash.org/testSummary.php?project=2&name=DigitallyReconstructedRadiograph1Test&date=2012-03-02 DigitallyReconstructedRadiograph1Test] Failing on a few platforms. Test image look like there is a real bug.<br />
*Failing Tiff Tests<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkTIFFImageIOSpacing&date=2012-03-02 itkTIFFImageIOSpacing] Big Endian issues<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkDiscreteGaussianImageFilterTest2&date=2012-03-02 itkDiscreteGaussianImageFilterTest2] Big Endian Issue<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkLargeTIFFImageWriteReadTest3&date=2012-03-01 itkLargeTIFFImageWriteReadTest3] Large File issue<br />
*[http://open.cdash.org/testSummary.php?project=2&name=itkMeshFileReadWriteTest10&date=2012-03-01 itkMeshFileReadWriteTest10] Failing on windows and Big Endian Likely some real bugs here<br />
<br />
==== Summary of Warnings ====<br />
<br />
* What Warnings?<br />
* [http://open.cdash.org/viewBuildError.php?type=1&buildid=2055808 Warning from try compile?]<br />
* gcc 4.1 ( still standard with Red Hat Enterprise 5.7 )<br />
** [http://open.cdash.org/viewBuildError.php?type=1&buildid=2051588 Lots of warnings]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_09&diff=46265ITK/Tcons/Agendas/2012 03 092012-03-08T18:25:38Z<p>Ibanez: Created page with "= How to Join the Tcon = == Number to Call == '''Please be patient, due to some unforeseen circumstances, the call may not start on time...''' * 1-800-728-9607 (in the US) or..."</p>
<hr />
<div>= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk<br />
<br />
==== Problems Reported in Debian Packaging ====<br />
<br />
* Failing FFT tests in 32 bits.<br />
<br />
==== Summary of Failing Tests ====<br />
<br />
<br />
*[http://open.cdash.org/testSummary.php?project=2&name=DigitallyReconstructedRadiograph1Test&date=2012-03-02 DigitallyReconstructedRadiograph1Test] Failing on a few platforms. Test image look like there is a real bug.<br />
*Failing Tiff Tests<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkTIFFImageIOSpacing&date=2012-03-02 itkTIFFImageIOSpacing] Big Endian issues<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkDiscreteGaussianImageFilterTest2&date=2012-03-02 itkDiscreteGaussianImageFilterTest2] Big Endian Issue<br />
**[http://open.cdash.org/testSummary.php?project=2&name=itkLargeTIFFImageWriteReadTest3&date=2012-03-01 itkLargeTIFFImageWriteReadTest3] Large File issue<br />
*[http://open.cdash.org/testSummary.php?project=2&name=itkMeshFileReadWriteTest10&date=2012-03-01 itkMeshFileReadWriteTest10] Failing on windows and Big Endian Likely some real bugs here<br />
<br />
==== Summary of Warnings ====<br />
<br />
* What Warnings?<br />
* [http://open.cdash.org/viewBuildError.php?type=1&buildid=2055808 Warning from try compile?]<br />
* gcc 4.1 ( still standard with Red Hat Enterprise 5.7 )<br />
** [http://open.cdash.org/viewBuildError.php?type=1&buildid=2051588 Lots of warnings]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_09&diff=46264ITK/Tcons/Minutes/2012 03 092012-03-08T18:25:14Z<p>Ibanez: Created page with "= Attendees = = Project Topics = == Cycles == = Technical Topics = == Dashboard == == Gerrit == == Status == = Action Items ="</p>
<hr />
<div>= Attendees =<br />
<br />
<br />
= Project Topics =<br />
<br />
<br />
== Cycles ==<br />
<br />
<br />
= Technical Topics =<br />
<br />
<br />
== Dashboard ==<br />
<br />
<br />
== Gerrit ==<br />
<br />
<br />
== Status ==<br />
<br />
= Action Items =</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Telephone_Conference_Agendas_and_Minutes&diff=46263ITK/Telephone Conference Agendas and Minutes2012-03-08T18:23:10Z<p>Ibanez: /* March */</p>
<hr />
<div>= ITK Tcons =<br />
<br />
* [[ITK/Tcons]]<br />
* [[ITK/Tcons/Agendas]]<br />
* [[ITK/Tcons/Minutes]]<br />
<br />
= 2012 =<br />
<br />
== March ==<br />
<br />
* Mar 9, 2012 - [[ITK/Tcons/Agendas/2012_03_09|Agenda]] [[ITK/Tcons/Minutes/2012_03_09|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Mar 2, 2012 - [[ITK/Tcons/Agendas/2012_03_02|Agenda]] [[ITK/Tcons/Minutes/2012_03_02|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== February ==<br />
<br />
* Feb 24, 2012 - [[ITK/Tcons/Agendas/2012_02_24|Agenda]] [[ITK/Tcons/Minutes/2012_02_24|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 17, 2012 - [[ITK/Tcons/Agendas/2012_02_17|Agenda]] [[ITK/Tcons/Minutes/2012_02_17|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 10, 2012 - [[ITK/Tcons/Agendas/2012_02_10|Agenda]] [[ITK/Tcons/Minutes/2012_02_10|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Feb 3, 2012 - [[ITK/Tcons/Agendas/2012_02_03|Agenda]] [[ITK/Tcons/Minutes/2012_02_03|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
== January ==<br />
<br />
* Jan 27, 2012 - [[ITK/Tcons/Agendas/2012_01_27|Agenda]] [[ITK/Tcons/Minutes/2012_01_27|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
* Jan 20, 2012 - [[ITK/Tcons/Agendas/2012_01_20|Agenda]] [[ITK/Tcons/Minutes/2012_01_20|Minutes]] '''ITK TCON 3.0''' in Tcon and WebEx<br />
<br />
= Archives 2006-2011 =<br />
<br />
[[ITK Telephone Conference Agendas and Minutes/Archives|Archives 2006-2011]]</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_02&diff=46167ITK/Tcons/Minutes/2012 03 022012-03-02T15:02:40Z<p>Ibanez: </p>
<hr />
<div>= Attendees =<br />
<br />
* Jim Miller<br />
* Brad Lowekamp<br />
* Matt McCormick<br />
* Luis Ibanez<br />
<br />
= Project Topics =<br />
<br />
<br />
== Cycles ==<br />
<br />
<br />
= Technical Topics =<br />
<br />
<br />
== Dashboard ==<br />
<br />
<br />
== Gerrit ==<br />
<br />
<br />
== Status ==<br />
<br />
= Action Items =</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Agendas/2012_03_02&diff=46161ITK/Tcons/Agendas/2012 03 022012-03-02T14:15:52Z<p>Ibanez: Created page with "= How to Join the Tcon = == Number to Call == '''Please be patient, due to some unforeseen circumstances, the call may not start on time...''' * 1-800-728-9607 (in the US) or..."</p>
<hr />
<div>= How to Join the Tcon =<br />
<br />
== Number to Call ==<br />
<br />
'''Please be patient, due to some unforeseen circumstances, the call may not start on time...'''<br />
<br />
* 1-800-728-9607 (in the US) or<br />
* +1 9139049873 (international)<br />
* access code 6815251<br />
<br />
== Webex ==<br />
<br />
* Meeting link<br />
* https://emeetings.webex.com/emeetings/j.php?ED=138191182&UID=482060457&PW=NNzJiNDk1ZGU3<br />
<br />
= Status =<br />
<br />
<br />
== Release Schedule ==<br />
<br />
* http://www.itk.org/Wiki/ITK_Release_4/ReleaseSchedules#Plan<br />
<br />
<br />
=== Dashboard ===<br />
<br />
* http://public.kitware.com/dashboard.php?name=itk</div>Ibanezhttps://public.kitware.com/Wiki/index.php?title=ITK/Tcons/Minutes/2012_03_02&diff=46160ITK/Tcons/Minutes/2012 03 022012-03-02T14:15:32Z<p>Ibanez: Created page with "= Attendees = = Project Topics = == Cycles == = Technical Topics = == Dashboard == == Gerrit == == Status == = Action Items ="</p>
<hr />
<div>= Attendees =<br />
<br />
<br />
= Project Topics =<br />
<br />
<br />
== Cycles ==<br />
<br />
<br />
= Technical Topics =<br />
<br />
<br />
== Dashboard ==<br />
<br />
<br />
== Gerrit ==<br />
<br />
<br />
== Status ==<br />
<br />
= Action Items =</div>Ibanez