https://public.kitware.com/Wiki/api.php?action=feedcontributions&user=Dzenanz&feedformat=atomKitwarePublic - User contributions [en]2024-03-28T20:51:02ZUser contributionsMediaWiki 1.38.6https://public.kitware.com/Wiki/index.php?title=ITK/Getting_Started/Obtain/Windows/Git&diff=64723ITK/Getting Started/Obtain/Windows/Git2022-12-27T15:00:47Z<p>Dzenanz: Update git link</p>
<hr />
<div>ITK uses git for its version control system. If you are familiar with git, you can find relevant information [[ITK/Source#2._Git|here]] or [[ITK/Git|here]]. If not, continue reading!<br />
<br />
To get the latest ITK source code, you must use git. If you do not have git installed, please [[Git/Download#MSysGit|install it]]. Once you have git installed, follow these instructions: <br />
<br />
The "clone URL" you will need is:<br />
git clone https://github.com/InsightSoftwareConsortium/ITK.git<br />
<br />
This will create an ITK directory and download the latest ITK source code into that directory. ''Step 1: Obtaining'' is now complete!</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Getting_Started/Obtain/Linux/Git&diff=64722ITK/Getting Started/Obtain/Linux/Git2022-12-27T15:00:28Z<p>Dzenanz: Update git link</p>
<hr />
<div>ITK uses Git for its version control system. If you are familiar with Git, you can find relevant information [[ITK/Source#2._Git|here]] or [[ITK/Git|here]]. If not, continue reading!<br />
<br />
To get the latest ITK source code, you must use git. If you do not have git installed, please install it from your package manager: <br />
sudo apt-get install git <br />
<br />
Once you have git installed, type this command in a terminal window:<br />
<br />
git clone https://github.com/InsightSoftwareConsortium/ITK.git<br />
<br />
This will create an ITK directory and download the latest ITK source code into that directory.<br />
<br />
''Step 1: Obtaining'' is now complete!</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/HelloInsight&diff=63988ITK/HelloInsight2019-12-04T21:01:37Z<p>Dzenanz: /* Write the source code */ Update minimum CMake version</p>
<hr />
<div>= Hello Insight =<br />
<br />
Traditionally, the very first program you learn to write in any given language is the simplest code to print "Hello World!". Following in a similar vein, we demonstrate here a simple ITK program. While simple, it is used to demonstrate that you can build programs against your freshly installed ITK and that you can run them. If this seemingly trivial step succeeds, it means:<br />
<br />
# ITK was built successfully (the build itself succeeded)<br />
# ITK development files were installed successfully (and your compiler can find all the right headers and libraries)<br />
# The ITK runtime is good (since your OS can find the required shared libraries and so on)<br />
<br />
All this working is a good thing.<br />
<br />
So without further ado, fire up your favourite text editor and let's get started!<br />
<br />
== Write the source code ==<br />
<br />
Create a new directory. Be imaginative and call it ''HelloInsight''. Create a file called ''HelloInsight.cxx'' therein, and enter the following code:<br />
<br />
<pre><br />
#include "itkImage.h"<br />
#include <iostream><br />
<br />
int main()<br />
{<br />
typedef itk::Image< unsigned short, 3 > ImageType;<br />
<br />
ImageType::Pointer image = ImageType::New();<br />
<br />
std::cout << "Hello ITK World !" << std::endl;<br />
<br />
return 0;<br />
}<br />
</pre><br />
<br />
Next to ''HelloInsight.cxx'', create a file, ''CMakeLists.txt'', and populate it with:<br />
<br />
<pre><br />
cmake_minimum_required(VERSION 3.10.2)<br />
<br />
project(HelloInsight)<br />
<br />
# Find ITK.<br />
find_package(ITK REQUIRED)<br />
include(${ITK_USE_FILE})<br />
<br />
add_executable(HelloInsight HelloInsight.cxx )<br />
<br />
target_link_libraries(HelloInsight ${ITK_LIBRARIES})<br />
</pre><br />
<br />
== Build the project ==<br />
<br />
Next to the ''HelloInsight'' directory, create a directory to build the project, ''HelloInsight_build''. '''cd''' into that directory:<br />
<br />
cd HelloInsight_build<br />
<br />
Run the CMake executable. You may have to specify the location of the ITK build directory if it was not installed.<br />
<br />
cmake ../HelloInsight<br />
<br />
or<br />
<br />
cmake -DITK_DIR=/path/to/ITK_build ../HelloInsight<br />
<br />
Once the CMake configuration completes successfully, build the project. On Linux or Mac,<br />
<br />
make<br />
<br />
On Windows, open the Visual Studio project file and build it.<br />
<br />
HelloInsight.sln<br />
<br />
== Run the new executable ==<br />
<br />
./HelloInsight<br />
<br />
{{ITK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/How_to_make_a_Release&diff=63977ITK/How to make a Release2019-10-16T14:13:30Z<p>Dzenanz: Deprecate page</p>
<hr />
<div>{{warning|1=The current authoritative resource is [https://github.com/InsightSoftwareConsortium/ITK/blob/master/Documentation/Maintenance/Release.md GitHub release documentation].}}<br />
<br />
= How To Make an ITK Release =<br />
<br />
This page describes the sequence of steps required for making an ITK release. There are typically two feature releases a year, around December and June, and one to three bug fixes between feature releases.<br />
<br />
== Bug fix release general steps ==<br />
# Create tag (with GPG signature) for release. Do not forget to update ITK revision number in CMakeLists.txt.<br />
# Create release notes: <pre>git shortlog --no-merges v4.11.0..release</pre><br />
# Write blog post in a google doc and share it with the Comm’ team.<br />
# Use same text (2) to prepare mailing list message<br />
# Create tarballs and upload them on SourceForge<br />
# Send email to Comm’ team so they can update links to tarballs on [http://www.itk.org www.itk.org]. Verify that links work!<br />
# Send email to mailing list (user, develop, community), add post in the [https://plus.google.com/u/0/communities/111375098792764998322 ITKBarCamp Google+ community] and publish blog post.<br />
<br />
'''For details of each step, refer to the sections below.'''<br />
<br />
== Integrate bug fixes in the release branch ==<br />
* Update master and release branches<br />
<pre>git fetch<br />
git checkout master<br />
git reset --hard origin/master<br />
git checkout release<br />
git reset --hard origin/release</pre><br />
* List differences between last release and current release branch<br />
<pre>git shortlog --no-merges v4.10.0..release</pre><br />
* Merge bug fix commits in release. Topic branch should be named <bug-name>-for-release<br />
** If topic branch was created from release branch, checkout topic in new branch (see command lines on gerrit)<br />
** If topic branch was created on master, cherry-pick commit (see command line on gerrit) on a topic branch created off release. The commit will be visible twice in the history once release in merged into master.<br />
** Merge new branch on release: <pre>git merge <bug-name>-for-release --no-ff</pre><br />
** Update gerrit: write “Merged to release.” in merged topic.<br />
* Merge release into master (so master keeps track of release history)<br />
<pre>git checkout master<br />
git pull<br />
git merge release<br />
git push origin master release</pre><br />
* For patches that need to be merged to the "release-3.20" branch, they are first merged to release-3.20, then release-3.20 is merged to the release branch with 'git merge -s ours' to avoid a huge number of merge conflicts. Then, release is merged into master.<br />
<br />
== Pre-tag activities ==<br />
<br />
* Make sure to update the versions in the top level CMakeLists.txt as described below<br />
** For bugfix releases, this is done before the tag. For feature releases, this is done after the final tag.<br />
* Make sure all new remote modules are built in by the Doxygen build<br />
* Update the WikiExamples and SphinxExamples remote modules.<br />
<br />
== Tag the ITK repository ==<br />
<br />
Tagging the repository should only be done with the agreement of the developers after a tcon.<br />
<br />
=== Update your repository with ===<br />
<br />
use the commmand <br />
<br />
git checkout master<br />
git pull<br />
<br />
to make sure that your source tree is updated. This must correspond<br />
to a source tree that has been fully tested in the Dashboard.<br />
<br />
When tagging a bugfix release on the ''release'' branch, make sure to bump the ''ITK_VERSION_PATCH'' variable in the top level ''CMakeLists.txt'' before tagging. When tagging a feature release, make sure to bump the ''ITK_VERSION_MINOR'' version on the ''master'' branch after tagging.<br />
<br />
=== Tag with a branch point reference ===<br />
<br />
''Note:'' At this time, Brad King, Matt McCormick, Francois Budin, or Jean-Christophe Fillion-Robin are the person to do this because of their trusted GPG key.<br />
<br />
In the source tree that you just updated, use the command<br />
<br />
git tag -m "ITK 4.5-rc03" -s v4.5rc03 f9d99ca3ad00116393c4e2ce899beb00695ebb24<br />
<br />
<br />
where, of course you change v4.5rc03 for the correct release number and the hash to the correct commit.<br />
<br />
Push it to the repository<br />
<br />
git push origin v4.5rc03<br />
<br />
=== Update the release branch ===<br />
<br />
Update the release branch only during features releases after the tag for the release. Perform a fast-forward merge of master into release:<br />
<br />
git checkout release<br />
git reset --hard origin/release<br />
git merge --ff-only <version tag><br />
git push origin release<br />
git checkout master<br />
<br />
This will not create a new commit, only move the release branch to the tag, i.e. it will be fast forward.<br />
<br />
For minor releases, merge release branch into master branch as for a normal commit, and resolve conflict (arising from mismatch in version number) by keeping master branch versions.<br />
<br />
== Mark the release as resolved on the issue tracker ==<br />
<br />
[https://issues.itk.org/jira/plugins/servlet/project-config/ITK/versions Projects -> ITK -> Versions]<br />
<br />
Schedule the next release, and update the [[ITK/Release Schedule | Release Schedule]] page.<br />
<br />
== Prepare Release Notes == <br />
<br />
Release notes are prepared in a Google Doc.<br />
<br />
A list of authors and new authors can be computed with [https://gist.github.com/thewtex/5045b8e13b5d12b8fdcf this script].<br />
<br />
Todo: Add more description of the structure of release notes.<br />
<br />
<br />
== Add New Remote Modules to Nightly Builds == <br />
<br />
Some builds may be difficult to add due to third-party dependencies.<br />
<br />
== Send Contributor Momentos ==<br />
<br />
This file:<br />
<br />
https://github.com/thewtex/vtkGEB/blob/itk/itkgeb.stl<br />
<br />
can be ordered from ShapeWays and sent to contributors. Deb Howell has generated excellent packaging.<br />
<br />
== Archive ExternalData ==<br />
<br />
Set the environmental or CMake variable ''ExternalData_OBJECT_STORES'' to a local directory. E.g.<br />
<br />
export ExternalData_OBJECT_STORES=${HOME}/data<br />
<br />
Pre-populate the store with the contents of the 'InsightData' tarballs from a previous release. Once the tarball extracted, move the content of its subfolder called .ExternalData in your local ExternalData_OBJECT_STORES directory.<br />
<br />
Then, from the ITK build directory, configure ITK, enable ''ITK_WRAP_PYTHON'', ''ITK_LEGACY_SILENT'' , ''BUILD_TESTING'' and ''BUILD_EXAMPLES''.<br />
<br />
If you have previously enabled remote modules using the same ITK source directory, either verify that they are enabled in your<br />
current build, or remove their source directory that has been added inside ITK source directory (Modules/Remote/{name_of_remote_module}).<br />
<br />
Build the ''ITKData'' target<br />
<br />
make ITKData<br />
<br />
This will download new testing data since the previous release.<br />
<br />
Next, run the script from within the ITK source directory:<br />
<br />
./Utilities/Maintenance/ContentLinkSynchronization.sh ${ExternalData_OBJECT_STORES}<br />
<br />
'''Do not use ''--cleanup'' as for the purpose of the GitHub resource, it is important to keep the older files: some are from older revisions of ITK, and people continue to use the older versions of ITK and request the testing data.'''<br />
<br />
This is will verify all contents, fully populate the ''MD5/'' and ''SHA512/'' directories in the object store, and create any missing ''.md5'' or ''.sha512'' content links. If any new content link files are created, commit the result.<br />
<br />
Next, archive the data on data.kitware.com. Create a folder, e.g. ''4.11'', in [https://data.kitware.com/#collection/57b5c9e58d777f126827f5a1/folder/57b672b48d777f10f269651a ITK/ITKTestingData]<br />
<br />
./Utilities/Maintenance/ArchiveTestingDataOnGirder.py --object-store ${HOME}/data --parent-id <the-girder-id-of-the-folder-created> --api-key <your-girder-user-api-key><br />
<br />
This script requires the ''girder-client'' Python package install from Girder master, November 2016 or later, (Girder >2.0.0).<br />
<br />
Run the script<br />
<br />
./Utilities/Maintenance/ArchiveTestingDataOnMidas.py<br />
<br />
to upload the testing data from a local store on the ITK https://midas3.kitware.com/midas/ and http://slicer.kitware.com/midas3/ Community.<br />
<br />
This script requires that [http://pydas.readthedocs.org/en/latest/ pydas] is installed. Note: If you get the following error message: <pre>pydas.exceptions.InvalidPolicy: 'Request failed with HTTP status code 200, Midas Server error code -151, and response content {"stat":"fail","message":"Invalid policy or itemid","code":"-151"}'</pre> make sure you have the permissions to write in the ITK collection on the Midas server.<br />
<br />
<br />
Archive the InsightData contents on ITK's file server at Kitware<br />
<br />
rsync -v -r /tmp/InsightToolkit-4.9.0/.ExternalData/MD5/ public:/projects/Insight/WWW/InsightWeb/files/ExternalData/MD5/<br />
<br />
Update the data archive at https://github.com/InsightSoftwareConsortium/ITKTestingData<br />
<br />
== Prepare tarballs ==<br />
<br />
==== InsightToolkit tarball ====<br />
<br />
Once the repository has been tagged, we use the following script in the repository to create the tarballs:<br />
<br />
Utilities/Maintenance/SourceTarball.bash --tgz --txz --zip<br />
<br />
Note: tarballs can be created from a specific commit. The user can manually specify the version of ITK used to name the output files:<br />
<br />
Utilities/Maintenance/SourceTarball.bash -v 4.10.1 11f687df0347df9c1fee757745c1f1976ec3cbfe<br />
<br />
After the tarballs have been uploaded to SourceForge, check their MD5 sums (the "i" info button on Sourceforge.net and locally with the 'md5sum' command). Also, download them from SourceForge and run an Experimental build on Linux, OSX, and Windows.<br />
<br />
== ITK Software Guide ==<br />
<br />
Bump the ITK version in Superbuild/ExternalITKv4.cmake.<br />
<br />
Set the ''DRAFT_WATERMARK'' CMake varable to OFF to remove the draft watermark.<br />
<br />
Set the ''PDF_QUALITY_LEVEL'' CMake configuration option to "Screen" for the electronic version and "Printer" for the print version.<br />
<br />
Turn on ''GENERATE_HTML''.<br />
<br />
To create ItkSoftwareGuide.pdf to put at itk.org/ItkSoftwareGuide.pdf from InsightSoftwareGuide-Book{1,2}-4.X.0.pdf, use pdftk<br />
<br />
pdftk ITKSoftwareGuide-Book1.pdf ITKSoftwareGuide-Book2.pdf cat output /tmp/ItkSoftwareGuide.pdf<br />
<br />
=== Prepare the print version ===<br />
<br />
Set the ''PDF_QUALITY_LEVEL'' to "Printer", and rebuild.<br />
<br />
Remove the junk initial page, and then also one of the blank pages so pages fall on "left-side / right-side" as formatted.<br />
<br />
pdftk ITKSoftwareGuide-Book1.pdf cat 2-3 5-end output /tmp/ITKSoftwareGuide-Book1.pdf<br />
pdftk ITKSoftwareGuide-Book2.pdf cat 2-3 5-end output /tmp/ITKSoftwareGuide-Book2.pdf<br />
<br />
=== Update the HTML pages ===<br />
<br />
rsync the newly generated pages to the web server.<br />
<br />
<pre><br />
rsync -rt html/ kitware@public:/projects/Insight/WWW/InsightWeb/ITKSoftwareGuide/html<br />
</pre><br />
<br />
== ITK Sphinx Examples ==<br />
<br />
Bump the Superbuild ITK version in Superbuild/External-ITK.cmake.<br />
<br />
Rendered versions (epub, pdf, html) can be downloaded from the [http://itk.org/ITKExamples/Documentation/Download/index.html download page] and rename them.<br />
<br />
Create the source tarballs.<br />
<br />
Set the prefix and tag:<br />
<br />
tag=$(git describe)<br />
prefix=InsightSphinxExamples-4.10.0<br />
<br />
Generate .zip and .tar.gz:<br />
<br />
git archive --format=tar --prefix=${prefix}/ --output=${prefix}.tar ${tag}<br />
gzip -9 ${prefix}.tar<br />
git archive --format=zip -9 --prefix=${prefix}/ --output=${prefix}.zip ${tag}<br />
<br />
== ITK Wiki Examples ==<br />
<br />
Download the latest examples:<br />
<br />
version=4.12.0<br />
<br />
wget -O ITKWikiExamples-master.zip https://github.com/InsightSoftwareConsortium/ITKWikiExamples/archive/master.zip <br />
unzip ITKWikiExamples-master.zip<br />
mv ITKWikiExamples-master InsightWikiExamples-${version}<br />
zip -r InsightWikiExamples-${version}.zip InsightWikiExamples-${version}<br />
tar cvf InsightWikiExamples-${version}.tar InsightWikiExamples-${version}<br />
gzip -9 InsightWikiExamples-${version}.tar<br />
<br />
== Generating Doxygen Documentation ==<br />
<br />
'''Note''': links to the nightly generated Doxygen can be found in the footer of the Doxygen HTML pages.<br />
Use the files to upload and create InsightDoxygenDocTag-4.11.0.gz, InsightDoxygenXml-4.11.0.tar.gz, InsightDoxygenDocHtml-4.11.0.tar.gz.s <br />
<br />
Prior to the release, new Remote Modules should be enabled in the Doxygen build's configuration.<br />
<br />
<br />
* Run CMake in the binary build and enable BUILD_DOXYGEN<br />
* Do Configure and Generate in CMake<br />
* Go to the binary directory<br />
* Type "make Documentation"<br />
* Move into the directory Utilities/ ( cd Utilities/ )<br />
* Rename the Doxygen directory as DoxygenInsightToolkit-3.4.0 (of course with the appropriate release number)<br />
* Tar it with the command: tar -cf DoxygenInsightToolkit-3.4.0.tar DoxygenInsightToolkit-3.4.0<br />
* Compress it with the command: gzip -9 DoxygenInsightToolkit-3.4.0.tar<br />
<br />
Historical note: Before ITK 3.8, The documentation used to be generated in a directory called Documentation/Doxygen.<br />
<br />
* In Public do:<br />
** Copy documentation to: /projects/Insight/Doxygen<br />
*** Create a subdirectory Insight34-doxygen/Documentation/Doxygen<br />
*** The final directory will look like: /projects/Insight/Doxygen/Insight34-doxygen/Documentation/Doxygen<br />
*** and at that level copy the "html" directory and the InsightToolkit.tag file.<br />
** Create symbolic link at: /projects/Insight/WWW/InsightWeb<br />
** ('''DEPRECATED''' - last release 4.1) <s>Create symbolic link at: /projects/Insight/WWW/InsightDocuments/Web </s><br />
<br />
== Copy the files to the FTP directory in public.kitware.com ==<br />
<br />
scp InsightData-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightData-4.12.0.tar.xz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightData-4.12.0.zip kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightToolkit-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightToolkit-4.12.0.tar.xz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightToolkit-4.12.0.zip kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
<s>scp InsightApplications-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12</s><br />
<s>scp InsightApplications-4.12.0.zip kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12</s><br />
scp InsightDoxygenDocHtml-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightDoxygenDocTag-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightDoxygenDocXml-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp ItkSoftwareGuide.pdf kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightSoftwareGuide-Book1-4.12.0.pdf kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightSoftwareGuide-Book2-4.12.0.pdf kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightSoftwareGuideHtml-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightWikiExamples-4.12.0.tar.gz kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
scp InsightWikiExamples-4.12.0.zip kitware@public:/projects/Insight/WWW/InsightWeb/files/v4.12<br />
<br />
ssh kitware@public<br />
cd /projects/Insight/WWW/InsightWeb<br />
rm ItkSoftwareGuide.pdf<br />
ln -s files/v4.12/ItkSoftwareGuide.pdf ItkSoftwareGuide.pdf<br />
<br />
== Copy the files to SourceForge ==<br />
<br />
This is to be done only by <br />
<br />
* Ken Martin at Kitware<br />
* Brad King at Kitware<br />
* Matt McCormick at Kitware<br />
* Francois Budin at Kitware<br />
* Brad Lowekamp at NLM<br />
<br />
=== Using The New (2010) Interface ===<br />
<br />
Go to this page<br />
<br />
https://sourceforge.net/downloads/itk/itk/<br />
<br />
and provide user name and password<br />
<br />
Then <br />
<br />
* Use the "Add Folder" button to create a folder for the release.<br />
* Click on the folder to open it<br />
* Use the "Add File" button to upload files. The interface allows you to select multiple files for simultaneous upload.<br />
<br />
After uploading, make sure to check the hashes on the uploads. These can be shown with the "(i)" button next to the file.<br />
<br />
'''Large files''', like the Doxygen HTML tarball, '''need to be uploaded with scp''', a la:<br />
<br />
scp InsightDoxygenDocHtml-4.7.0.tar.gz mmmccormic@frs.sourceforge.net:/home/frs/project/itk/itk/4.7/InsightDoxygenDocHtml-4.7.0.tar.gz<br />
<br />
== Update the HTML Download page ==<br />
<br />
Contact Communications at Kitware in order to<br />
<br />
* Update the Download HTML page: http://www.itk.org/ITK/resources/software.html<br />
* Produce a press release<br />
* Update http://itk.org/ItkSoftwareGuide.pdf<br />
<br />
== Update the HTML Documentation page ==<br />
<br />
=== Documentation.htm ===<br />
<br />
Contact Communications at Kitware in order to update the page:<br />
<br />
http://www.itk.org/ITK/help/documentation.html<br />
<br />
The content should be updated to point to the Doxygen documentation of the current release<br />
<br />
== Update the Release Notes in the Wiki ==<br />
<br />
=== Add entry for next planned release ===<br />
<br />
Delete the old entry and add a new entry in the [[ITK/Release Schedule| scheduled releases page]]<br />
<br />
=== Update the Releases page ===<br />
<br />
Add the "What's New" and "What's Changed" entries to the [[ITK/Releases| Releases]] page.<br />
<br />
===Update "What's New in Release x.x" Wiki Page ===<br />
<br />
Update this web-page with the e-mail sent to the ITK mailing indicating the notable changes and other important information about the release.<br />
<br />
=== Update "What has Changed since previous release" ===<br />
<br />
From a Linux system, cd into an ITK Git directory and run <br />
<br />
git shortlog --topo-order --no-merges v4.0.0..v4.1.0<br />
<br />
Delete the KWRobot time stamp commits.<br />
<br />
== <s>Update Insight Journal</s> (deprecated)==<br />
<br />
<s>Contact Zack and request to do the following:<br />
<br />
* Install new ITK version in the Insight Journal testing environment<br />
* Update IJMacros.txt: Add the just released version of ITK</s><br />
<br />
== Update JIRA issue tracker ==<br />
<br />
* Create a new version to make possible for users to report bug pertaining to that specific ITK release<br />
** Create the next release target milestone with Administration -> ITK -> Versions -> Add<br />
** Release the current release milestone with Agile -> Classic ... -> Right click the release on the left -> Release<br />
<br />
== Further Testing ==<br />
<br />
The purpose of this testing is to replicate the experience that a user may have when trying the new release.<br />
<br />
This means that a number of ITK developers should download the tarballs or do Git checkouts with the release tag, and build the toolkit in as many configuration as possible.<br />
<br />
== Notes ==<br />
<br />
* ITK minor releases (patch) do not have a tagged release candidate.<br />
{{ITK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Git/Develop/Data&diff=63858ITK/Git/Develop/Data2019-08-13T17:54:01Z<p>Dzenanz: Remove page and leave a link to GitHub</p>
<hr />
<div>{{ Historical }}<br />
<br />
Up to date information can be found on GitHub:<br />
https://github.com/InsightSoftwareConsortium/ITK/blob/master/Documentation/Data.md</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Configuring_and_Building/VisualStudio&diff=63829ITK/Configuring and Building/VisualStudio2019-07-22T15:08:03Z<p>Dzenanz: Link to supported compilers page</p>
<hr />
<div>With Visual Studio 2017 on Windows 10 (64-bit):<br />
<br />
* Launch the CMake GUI (version 3.15) from the start menu<br />
* Next to "Where is the source code:", click "Browse Source..." and navigate to where you cloned the repository with Git.<br />
* Next to "Where to build the binaries:", select "Browse Build..." and select a place to build the ITK library. I like to use c:\build\ITK. This directory should NOT be inside the directory where you cloned the repository.<br />
* Click "Configure", and then specify "Visual Studio 15 2017" as the generator and "x64" as the platform for this project.<br />
* Choose your build options. I like to '''uncheck''' BUILD_EXAMPLES and BUILD_TESTING, because not building them speeds up the build process significantly.<br />
* Click "Generate".<br />
* Click "Open Project". This will start a new Visual Studio instance.<br />
* From the Build menu, choose "Build Solution" (or "Build ALL_BUILD")<br />
<br />
The list of currently supported versions of Visual Studio can be found [https://github.com/InsightSoftwareConsortium/ITK/blob/master/Documentation/SupportedCompilers.md#visual-studio in the repository].</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=VTK/FAQ&diff=63828VTK/FAQ2019-07-22T14:45:57Z<p>Dzenanz: /* Shared builds of VTK and debugging QVTKWidget using Visual Studio */</p>
<hr />
<div>== General information and availability ==<br />
<br />
=== What is the Visualization Toolkit? ===<br />
<br />
The '''Visualization ToolKit (vtk)''' is a software system for 3D Computer<br />
Graphics and Visualization.<br />
<br />
VTK includes a textbook published by Kitware Inc. ([http://www.kitware.com/products/vtktextbook.html The Visualization<br />
Toolkit, An Object-Oriented Approach to 3D Graphics]),<br />
a C++ class library, and Tcl, Python and Java implementations based on<br />
the class library.<br />
<br />
For more information, see http://www.vtk.org and http://www.kitware.com.<br />
<br />
=== What is the current release? ===<br />
<br />
The current release of vtk can be found and downloaded from:<br />
<br />
http://www.vtk.org/VTK/resources/software.html<br />
<br />
Nightly development releases are available at:<br />
<br />
http://www.vtk.org/files/nightly<br />
<br />
=== Can I contribute code or bug fixes? ===<br />
<br />
We encourage people to contribute bug fixes as well as new contributions<br />
to the code. We will try to incorporate these into future releases so<br />
that the entire user community will benefit from them.<br />
<br />
See http://www.vtk.org/contribute.php for information on contributing to<br />
VTK.<br />
<br />
For some ideas take a look at some of the entries in the "Changes to the<br />
VTK API" FAQ section, for example: <br />
[[VTK_FAQ#Roadmap:_What_changes_are_being_considered_for_VTK|What changes are being considered for VTK]]<br />
<br />
We now have a bug tracker that allow keeping track of any bug you could find. See [http://www.vtk.org/Bug BugTracker].<br />
You'll need an email to report a bug.<br />
To improve the chance of a bug being fixed, do not hesitate to add as many details as possible, a demo sample code + sample data is always a good idea.<br />
Providing a patch almost guarantees that your patch will be incorporated into VTK.<br />
<br />
=== Is there a mailing list for VTK? ===<br />
<br />
There is a mailing list: vtkusers@vtk.org<br />
<br />
To subscribe or unsubscribe to the mailing list, go to:<br />
http://www.vtk.org/mailman/listinfo/vtkusers<br />
<br />
To search the list archives go to: http://www.kitware.com/search.html<br />
<br />
=== Is the VTK mailing list archived anywhere? ===<br />
<br />
The mailing list is archived at:<br />
http://www.vtk.org/pipermail/vtkusers/<br />
<br />
You can search the archive at: http://www.kitware.com/search.html<br />
<br />
=== Are answers for the exercises in the VTK book available? ===<br />
<br />
Not anymore.<br />
<br />
The answers to the exercises of the textbook used to be maintained by<br />
Martin Stoufer (kudos).<br />
<br />
=== Is VTK regression tested on a regular basis? Can I help? ===<br />
<br />
Yes, it is.<br />
<br />
You can view the current regression test results at:<br />
http://open.cdash.org/index.php?project=VTK<br />
<br />
VTK uses CTest/CDash to perform builds, run tests, and generate dashboards. You<br />
can find more information about CDash at: http://cdash.org<br />
<br />
=== What's the best way to learn VTK? ===<br />
<br />
There are six things you might want to try:<br />
<br />
# Purchase the book [http://www.kitware.com/products/vtktextbook.html The Visualization Toolkit] from Kitware Inc.<br />
# Purchase the book [http://www.kitware.com/products/vtkguide.html VTK Users Guide] from Kitware Inc. <br />
# Check out some of the material at [[VTK Courses, Classes, Presentations]].<br />
# [http://www.vtk.org/get-software.php Download the source code and/or binaries] (available on Windows) and [[VTK/Examples|look at the examples]] (there are hundreds). <br />
# To learn the innards of VTK, you can attend a [http://www.kitware.com/products/proftrain.html#VTKCourse VTK course] or [http://www.kitware.com/products/proftrain.html sponsor a VTK course at your site] through Kitware. http://www.kitware.com/products/index.html<br />
# Buy Bill a beer and get him talking about VTK<br />
<br />
=== How should I ask questions on the mailing lists? ===<br />
<br />
The best online resource for this question is Eric S. Raymond's<br />
excellent guide on the topic titled [[http://www.catb.org/~esr/faqs/smart-questions.html How to ask questions the smart way]]. [[http://www.mikeash.com/getting_answers.html Getting Answers]] is a good starting point too.<br />
<br />
Please do read it and follow his advice. Thanks!<br />
<br />
Please also remember the following when you post your messages to the<br />
VTK mailing lists.<br />
<br />
* Mention the version of VTK you are using and the version of the compiler or scripting language you are using.<br />
<br />
* Mention your platform, OS and their versions.<br />
<br />
* Include hardware details if relevant.<br />
<br />
* Include all relevant error messages (appropriately trimmed of course).<br />
<br />
* The lists have a very large number of subscribers (in the thousands), so please keep messages to the point.<br />
<br />
* Use a sensible and descriptive subject line.<br />
<br />
* Do NOT post large data files or images to the list. Instead put them in your web page and mention the URLs.<br />
<br />
* Quote the messages you reply to appropriately. Remove unnecessary details.<br />
<br />
When asking a question or reporting a problem try to include a small<br />
example program that demonstrates the problem. Make sure that this<br />
example program is as small as you can make it, simple (and uses VTK<br />
alone), complete and demonstrates the problem adequately. Doing this<br />
will go a *long way* towards getting a quick and meaningful response.<br />
<br />
Sometimes you might not get any acceptable response. This happens<br />
because the others think the question has either been already answered<br />
elsewhere (the archives, FAQ and Google are your friends), or believe<br />
that you have not done enough homework to warrant their attention, or<br />
they don't know the answer or simply don't have the time to answer.<br />
Please do be patient and understanding. Most questions are answered by<br />
people volunteering their time to help you.<br />
<br />
Happy posting!<br />
<br />
=== How NOT to go about a programming assignment ===<br />
<br />
This is really a link you should read before posting to the mailing list. <br />
[This article is an attempt to show these irrational attitudes in an ironical way, <br />
intending to make our students aware of bad habits without admonishing them.]<br />
<br />
http://www.di.uniovi.es/~cernuda/noprog_ENG.html<br />
<br />
=== Where can I obtain test and sample datasets? ===<br />
<br />
See [[VTK Datasets|this page]] for details on downloading datasets that VTK can read.<br />
<br />
== Language bindings ==<br />
<br />
=== Are there bindings to languages other than Tcl? ===<br />
<br />
Aside from C++ (which it's written in) and Tcl, vtk is also bound into<br />
Java as of JDK 1.1 and Python 1.5, 1.6 and 2.X. All of the<br />
Tcl/Java/Python wrapper code is generated from some LEX and YACC code<br />
that parses our classes and extracts the required information to<br />
generate the wrapper code.<br />
<br />
=== What version of Tcl/Tk should I use with VTK? ===<br />
<br />
Currently we recommend that you use Tcl/Tk 8.2.3 with VTK. This is the<br />
best-supported version combination at this time.<br />
<br />
VTK has also been tested with Tcl/Tk 8.3.2 and works well.<br />
<br />
Tcl/Tk 8.3.4 has been tested to a limited extent but seems to have more<br />
memory leaks that Tcl 8.3.2 has.<br />
<br />
Tcl/Tk 8.4.x seems to work well with VTK too, but you might have to<br />
change a couple of configuration settings depending on the version of<br />
VTK you are using. Check the [[VTK_FAQ#Does_VTK_support_Tcl.2FTk_8.4_.3F|Does VTK support Tcl/Tk 8.4?]].<br />
<br />
=== Where can I find Python 2.x binaries? ===<br />
<br />
All of the Python binaries available on the kitware site are built for<br />
Python 1.5.2. This includes the official release VTK3.2 and the nightly<br />
builds (as at 2001-07-16).<br />
<br />
For Python 2.x binaries, you will have to compile your own from source.<br />
It is worth checking the mailing list archives for comments by others<br />
who have been through this process.<br />
<br />
There are some user-contributed binaries available at other sites. Check<br />
the mailing list archives for possible leads. Some win32 binaries for<br />
Python 2.1 are available at;<br />
<br />
http://basic.netmeg.net/godzilla/<br />
<br />
YMMV...<br />
<br />
=== Why do I get the Python error -- ValueError: method requires a VTK object? ===<br />
<br />
You just built VTK with Python support and everything went smoothly.<br />
After you install everything and try running a Python-VTK script you get<br />
a traceback with this error:<br />
<br />
ValueError: method requires a VTK object.<br />
<br />
This error occurs if you have two copies of the VTK libraries on your<br />
system. These copies need not be in your linkers path. The VTK libraries<br />
are usually built with an rpath flag (under *nix). This is necessary to<br />
be able to test the build in place. When you install VTK into another<br />
directory in your linkers path and then run a Python script the Python<br />
modules remember the old path and load the libraries in the build<br />
directory as well. This triggers the above error since the object you<br />
passed the method was instantiated from the other copy.<br />
<br />
So how do you fix it? The easiest solution is to simply delete the copy<br />
of the libraries inside your build directory or move the build directory<br />
to another place. For example, if you build the libraries in VTK/bin<br />
then move VTK/bin to VTK/bin1 or remove all the VTK/bin/*.so files. The<br />
error should no longer occur.<br />
<br />
Another way to fix the error is to turn the CMAKE_SKIP_RPATH boolean to<br />
ON in your CMakeCache.txt file and then rebuild VTK. You shouldn't have<br />
to rebuild all of VTK, just delete the libraries (*.so files) and then<br />
re-run cmake and make. The only trouble with this approach is that you<br />
cannot have BUILD_TESTING to ON when you do this.<br />
<br />
Alternatively, starting with recent VTK CVS versions (post Dec. 6, 2002)<br />
and with VTK versions greater than 4.1 (i.e. 4.2 and beyond) there is a<br />
special VTK-Python interpreter built as part of VTK called 'vtkpython'<br />
that should eliminate this problem. Simply use vtkpython in place of the<br />
usual python interpreter when you use VTK-Python scripts and the problem<br />
should not occur. This is because vtkpython uses the libraries inside<br />
the build directory.<br />
<br />
2002 by Prabhu Ramachandran<br />
<br />
=== Does VTK support Tcl/Tk 8.4 ? ===<br />
<br />
Short answer: yes, but it might require some adjustments, depending on<br />
the VTK and CMake versions you are using.<br />
<br />
# The VTK 4.x CVS nightly/development distribution supports Tcl/Tk 8.4 as long as you use a release version of CMake > 1.4.5. Since VTK 4.2 will require CMake 1.6, the next release version will support Tcl/Tk 8.4.<br />
# The VTK 4.0 release distribution does not support Tcl/Tk 8.4 out-of-the-box.<br />
<br />
In either cases, the following solutions will adress the problem. This<br />
basically involves setting two definition symbols that will make Tcl/Tk<br />
8.4 backward compatible with previous versions of Tcl/Tk (i.e. discard<br />
the "const correctness" and Tk_PhotoPutBlock compositing rule features) :<br />
<br />
a) Edit your C/C++ flags:<br />
<br />
Run your favorite CMake cache editor (i.e. CMakeSetup, or ccmake),<br />
display the advanced values and add the USE_NON_CONST and<br />
USE_COMPOSITELESS_PHOTO_PUT_BLOCK definition symbols to the end of any<br />
of the following CMake variables (if they exist): CMAKE_CXX_FLAGS,<br />
CMAKE_C_FLAGS.<br />
<br />
Example: On Unix your CMAKE_CXX_FLAGS will probably look like:<br />
<br />
-g -O2 -DUSE_NON_CONST -DUSE_COMPOSITELESS_PHOTO_PUT_BLOCK<br />
<br />
On Windows (Microsoft MSDev nmake mode):<br />
<br />
/W3 /Zm1000 /GX /GR /YX /DUSE_NON_CONST /DUSE_COMPOSITELESS_PHOTO_PUT_BLOCK<br />
<br />
b) or a more intrusive solution:<br />
<br />
Edit the top VTK/CMakeList.txt file and the following lines add '''at the<br />
top''' of this file:<br />
<br />
ADD_DEFINITIONS(<br />
-DUSE_NON_CONST<br />
-DUSE_COMPOSITELESS_PHOTO_PUT_BLOCK<br />
)<br />
<br />
<br />
=== When I try to run my program with Java-wrapped VTK, why do I get "java.lang.NoClassDefFoundError: vtk/vtkSomeClassName"? ===<br />
The file '''vtk.jar''' is not in your CLASSPATH in your execution environment.<br />
<br />
<br />
=== When I try to run my program with Java-wrapped VTK, why do I get "java.lang.UnsatisfiedLinkError: no vtkSomeLibraryName"? ===<br />
Some or all of the library (e.g., dll) files cannot be found. Make sure the files exist and that the PATH environment variable of your execution environment points to them.<br />
<br />
<br />
=== When I try to run my program with Java-wrapped VTK, why do I get Exception in thread "main" java.lang.UnsatisfiedLinkError: GetOutput_2 at vtk.vtkPolyDataAlgorithm.GetOutput_2(Native Method) ? ===<br />
<br />
== Using VTK ==<br />
<br />
=== The C++ compiler cannot convert some pointer type to another pointer type in my little program ===<br />
<br />
For instance, the C++ compiler cannot convert a <b><tt>vtkDataSet *</tt></b> type to a <b><tt>vtkImageData *</tt></b> type.<br />
<br />
It means the compiler does not know the relationship between a <b><tt>vtkDataSet</tt></b> and a <b><tt>vtkImageData</tt></b>. This relationship is actually inheritance: <b><tt>vtkImageData</tt></b> is a subclass of <b><tt>vtkDataSet</tt></b>. The only way for the compiler to know this relationship is to include the header file of the subclass, that is:<br />
<br />
#include "vtkImageData.h"<br />
<br />
If you wonder why the compiler did not complain about an unknown type, it is because somewhere (probably in a filter header file) there is a forward class declaration, like:<br />
<br />
class vtkImageData;<br />
<br />
=== Accessing a pointer in Python ===<br />
<br />
If you use VTK code with Python and need to pass some VTK data onto them, there are 2 approaches to wrap your code:<br />
# first, you can use the VTK wrapper (already used for the wrapping of VTK code)<br />
# you can use SWIG, which results in a light-weight module.<br />
<br />
In the second case, you will need to convert some VTK data, say a vtkPolyData, to a void pointer (no, it is not sufficient to just pass the object). For that, you can use the __this__ member variable in Python for the VTK data - see mailing archives:<br />
<br />
* [http://public.kitware.com/pipermail/vtkusers/2003-October/070054.html vtk, Python and SWIG - 'state of the union']<br />
<br />
=== What object/filter should I use to do ??? ===<br />
<br />
Frequently when starting out with a large visualization system people<br />
are not sure what object to use to achieve a desired effect.<br />
<br />
The most up-to-date information can be found in the VTK User's Guide<br />
(http://www.kitware.com/products/vtkguide.html).<br />
<br />
Alternative sources for information are the appendix of the book which<br />
has nice one line descriptions of what the different objects do and the<br />
VTK man pages (http://www.vtk.org/doc/nightly/html/classes.html).<br />
<br />
Additionally, the VTK man pages feature a "Related" section that provide<br />
links from each class to all the examples or tests using that class<br />
(http://www.vtk.org/doc/nightly/html/pages.html). This information is<br />
also provided in each class man page under the "Tests" or "Examples"<br />
sub-section.<br />
<br />
Some useful books are listed at http://www.vtk.org/buy-books.php<br />
<br />
=== What 3D file formats can VTK import and export? ===<br />
<br />
The following table identifies the file formats that VTK can read and<br />
write. Importer and Exporter classes move full scene information into or<br />
out of VTK. Reader and Writer classes move just geometry.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! File Format !! Read !! Write<br />
|-<br />
| 3D Studio || vtk3DSImporter || <br />
|-<br />
| AVS "UCD" format || vtkAVSucdReader || <br />
|-<br />
| Movie BYU || vtkBYUReader || vtkBYUWriter<br />
|-<br />
| Renderman || || vtkRIBExporter<br />
|-<br />
| Open Inventor 2.0 || || vtkIVExporter/vtkIVWriter<br />
|-<br />
| CAD STL || vtkSTLReader || vtkSTLWriter<br />
|-<br />
| Fluent GAMBIT ASCII || vtkGAMBITReader || <br />
|-<br />
| Unigraphics Facet Files || vtkUGFacetReader || <br />
|-<br />
| Marching Cubes || vtkMCubesReader || vtkMCubesWriter<br />
|-<br />
| Wavefront OBJ || || vtkOBJExporter<br />
|-<br />
| VRML 2.0 || || vtkVRMLExporter<br />
|-<br />
| VTK Structured Grid &dagger; || vtkStructuredGridReader || vtkStructuredWriter<br />
|-<br />
| VTK Poly Data &dagger; || vtkPolyDataReader || vtkPolyDataWriter<br />
|-<br />
| PLOT3D || vtkPLOT3DReader || <br />
|-<br />
| CGM || || vtkCGMWriter<br />
|-<br />
| OBJ || vtkOBJReader || <br />
|-<br />
| Particle || vtkParticleReader || <br />
|-<br />
| PDB || vtkPDBReader || <br />
|-<br />
| PLY || vtkPLYReader || vtkPLYWriter<br />
|-<br />
| Gaussian || vtkGaussianCubeReader || <br />
|-<br />
| Facet || vtkFacetReader || vtkFacetWriter<br />
|-<br />
| XYZ || vtkXYZMolReader || <br />
|-<br />
| Ensight &Dagger; || vtkGenericEnSightReader || <br />
|}<br />
<br />
&dagger; See the books [http://www.kitware.com/products/vtktextbook.html The<br />
Visualization Toolkit, An Object-Oriented Approach to 3D Graphics] or<br />
[http://www.kitware.com/products/vtkguide.html the User's Guide] for details<br />
about structured grid and poly data file formats.<br />
<br />
&Dagger; The class vtkGenericEnSightReader allows the user to read an EnSight<br />
data set without a priori knowledge of what type of EnSight data set it<br />
is (among vtkEnSight6BinaryReader, vtkEnSight6Reader,<br />
vtkEnSightGoldBinaryReader, vtkEnSightGoldReader,<br />
vtkEnSightMasterServerReader, vtkEnSightReader).<br />
<br />
For any other file format you may want to search for a converter to a<br />
known VTK file format, more info on:<br />
http://www.tech-edv.co.at/lunix/UTILlinks.html<br />
<br />
=== Why can't I find vtktcl (vtktcl.c)? ===<br />
<br />
In versions of VTK prior to 4.0 VTK Tcl scripts would require a:<br />
<br />
catch {load vtktcl} <br />
<br />
so that they could be executed directly from wish. In VTK 4.0 the<br />
correct mechanism is to use:<br />
<br />
package require vtk<br />
<br />
For people using versions earlier than 4.0, vtktcl is a shared library<br />
that is built only on the PC. Most examples used the "catch" notation so<br />
that they will work on UNIX and on the PC. On UNIX you must use the vtk<br />
executable/shell which should be in vtk/tcl/vtk.<br />
<br />
=== Why does this filter not produce any output? eg. GetPoints()==0 ===<br />
<br />
This is a very common question for VTK users. VTK uses a pipeline mechanism for rendering, which has multiple benefits, including the fact that filters that aren't used don't get called. This means that when you call a function such as x->GetOutput()->GetPoints() this will return 0 if the filter has not yet been executed. Just call x->Update() beforehand to make the pipeline update everything up to that point and it should work. -timh<br />
<br />
=== Problems with vtkDecimate and vtkDecimatePro ===<br />
<br />
''vtkDecimate'' and ''vtkDecimatePro'' have been tested fairly heavily so<br />
all known bugs have been removed. However, there are three situations<br />
where you can encounter weird behavior:<br />
<br />
# The mesh is not all triangles. Solution: use ''vtkTriangleFilter'' to triangulate polygons.<br />
# The mesh consists of independent triangles (i.e., not joined at vertices - no decimation occurs). Solution: use ''vtkCleanPolyData'' to link triangles.<br />
# Bad triangles are present: e.g., triangles with duplicate vertices such as (1,2,1) or (100,100,112), or (57,57,57), and so on. Solution: use ''vtkCleanPolyData''.<br />
<br />
=== How can I read DICOM files ? ===<br />
<br />
Starting with VTK 4.4, you can use the [http://www.vtk.org/doc/nightly/html/classvtkDICOMImageReader.html vtkDICOMImageReader class] to read DICOM files. Note however that DICOM is a huge protocol, and vtkDICOMImageReader is not able to read every DICOM file out there. If it does not meet your needs, we suggest you look for an existing converter before coding your own. Some of them are listed in the [http://www.dclunie.com/medical-image-faq/html/part8.html The Medical Image Format FAQ (Part 8)].<br />
<br />
==== GDCM ====<br />
<br />
For a more elaborate DICOM library that supports more image format, you might try [http://gdcm.sourceforge.net GDCM].<br />
Specifically: [http://gdcm.sourceforge.net/html/classvtkGDCMImageReader.html vtkGDCMImageReader] & [http://gdcm.sourceforge.net/html/classvtkGDCMImageWriter.html vtkGDCMImageWriter]<br />
<br />
Grassroots DiCoM is a C++ library for DICOM medical files. It is automatically wrapped to python/C#/Java (using swig). It supports RAW,JPEG (lossy/lossless),J2K,JPEG-LS,RLE and deflated. It also comes with DICOM Part 3,6 & 7 of the standard as XML files.<br />
<br />
If GDCM is too complex to integrate in your environment you can also consider simply using the command line converter: [http://apps.sourceforge.net/mediawiki/gdcm/index.php?title=Gdcmconv gdcmconv] to convert an unsupported DICOM file into something that vtkDICOMImageReader, can support. Typically you would want:<br />
<br />
gdcmconv --raw compressed_input.dcom uncompressed_output.dcom<br />
<br />
==== dicom2 ====<br />
<br />
Sebastien BARRE wrote a free DICOM converter, named dicom2, that can be<br />
used to convert medical images to raw format. This tool is a command<br />
line program and does not provide any GUI at the moment.<br />
http://dicom2.barre.nom.fr/<br />
<br />
There is a special section dedicated to the VTK:<br />
http://dicom2.barre.nom.fr/how-to.html, then "Convert to raw (vtk)"<br />
<br />
The following page also provide links to several other DICOM converters:<br />
http://www.barre.nom.fr/medical/samples/index.html#links<br />
<br />
==== vtkVolume16Reader ====<br />
<br />
When searching the vtkusers mailing list a lot of posts are still using vtkVolume16Reader to read in DICOM file. It will works in the following case:<br />
* You know the dimension (cols & rows) of your image<br />
* You know the spacing of your image<br />
* You know the pixel type (pixel type & #components) of your image<br />
* You know Pixel Data (7fe0,0010) is the last element in the image<br />
* You know Pixel Data (7fe0,0010) was sent in uncompressed format (not encapsulated)<br />
<br />
All those requirements are a stronger set of requirements than vtkDICOMImageReader, therefore it is encourage to use vtkDICOMImageReader instead.<br />
<br />
==== The spacing in my DICOM files are wrong ====<br />
<br />
Image Position (Patient) (0020,0032) is the only attribute that can be relied on to determine the "reconstruction interval" or "space between the center of slices".<br />
<br />
If the distance between Image Position (Patient) (0020,0032) of two parallel slices along the normal to Image Orientation (Patient) (0020,0037) is not the same as whatever happens to be in the DICOM Spacing Between Slices (0018,0088) attribute, then (0018,0088) is incorrect, without question<br />
<br />
This is a known bug in some scanners.<br />
<br />
When Slice Thickness (0018,0050) + Spacing Between Slices (0018,0088) equals the computed reconstruction interval, then chances are the modality implementor has made the obvious mistake of misinterpreting the definition of<br />
(0018,0088) to mean the distance between edges (gap) rather than the distance between centers.<br />
<br />
Further, one should never use Slice Location (0020,1041) either, an optional and purely annotative attribute, though chances are that the distance between the Slice Location (0020,1041) values of two slices will match the distance along the<br />
normal to the orientation derived from the position.<br />
<br />
The GDCM library simply discard any information present in the (0018,0088) tag and instead recompute the spacing by computing the distance in between two consecutive slices (along the normal).<br />
<br />
GDCM 1.x:<br />
typedef std::vector<gdcm::File *> FileList;<br />
FileList l;<br />
gdcm::SerieHelper sh;<br />
sh.OrderFileList(l); // calls ImagePositionPatientOrdering()<br />
zspacing = sh.GetZSpacing();<br />
<br />
GDCM 2.x:<br />
IPPSorter ipp;<br />
ipp.Sort( filenames );<br />
zspacing = ipp.GetZSpacing();<br />
<br />
=== How to handle large data sets in VTK ===<br />
<br />
One of the challenges in VTK is to efficiently handle large datasets. By<br />
default VTK is tuned towards smaller datasets. For large datasets there<br />
are a couple of changes you can make that should yield a much smaller<br />
memory footprint (less swapping) and also improve rendering performance.<br />
The solution is to:<br />
<br />
# Use ReleaseDataFlag,<br />
# Turn on ImmediateModeRendering<br />
# Use triangle strips via vtkStripper<br />
# Use a different filter or mapper<br />
<br />
Each of these will be discussed below.<br />
<br />
==== Using ReleaseDataFlag ====<br />
<br />
By default VTK keeps a copy of all intermediate results between filters<br />
in a pipeline. For a pipeline with five filters this can result in<br />
having six copies of the data in memory at once. This can be controlled<br />
using ReleaseDataFlag and GlobalReleaseDataFlag. If ReleaseDataFlag is<br />
set to one on a data object, then once a filter has finished using that<br />
data object, it will release its memory. Likewise, if<br />
GlobalReleaseDataFlag is set on ANY data object, all data objects will<br />
release their memory once their dependent filter has finished executing.<br />
For example in Tcl and C++<br />
<br />
# Tcl<br />
vtkPolyDataReader reader<br />
[reader GetOutput] ReleaseDataFlagOn<br />
<br />
// C++<br />
vtkPolyDataReader *reader = vtkPolyDataReader::New();<br />
reader->GetOutput()->ReleaseDataFlagOn();<br />
<br />
or<br />
<br />
// C++<br />
vtkPolyDataReader *reader = vtkPolyDataReader::New();<br />
reader->GetOutput()->GlobalReleaseDataFlagOn();<br />
<br />
While turning on the ReleaseDataFlag will reduce your memory footprint,<br />
the disadvantage is that none of the intermediate results are kept in<br />
memory. So if you interactively change a parameter of a filter (such as<br />
the isosurface value), all the filters will have to re-execute to<br />
produce the new result. When the intermediate results are stored in<br />
memory, only the downstream filters would have to re-execute.<br />
<br />
One hint for good interactive performance. If only one stage of the<br />
pipeline can have its parameters changed interactively (such as the<br />
target reduction in a decimation filter), only retain the data just<br />
prior to that step (which is the default) and turn ReleaseDataFlag on<br />
for all other steps.<br />
<br />
==== Use ImmediateModeRendering ====<br />
<br />
By default, VTK uses OpenGL display lists which results in another copy<br />
of the data being stored in memory. For most large datasets you will be<br />
better off saving memory by not using display lists. You can turn off<br />
display lists by turning on ImmediateModeRendering. This can be<br />
controlled on a mapper by mapper basis using ImmediateModeRendering, or<br />
globally for all mappers in a process by using<br />
GlobalImmediateModeRendering. For example:<br />
<br />
# Tcl<br />
vtkPolyDataMapper mapper<br />
mapper ImmediateModeRenderingOn<br />
<br />
// C++<br />
vtkPolyDataMapper *mapper = vtkPolyDataMapper::New();<br />
mapper->ImmediateModeRenderingOn();<br />
<br />
or<br />
<br />
// C++<br />
vtkPolyDataMapper *mapper = vtkPolyDataMapper::New();<br />
mapper->GlobalImmediateModeRenderingOn();<br />
<br />
The disadvantage to using ImmediateModeRendering is that if memory is<br />
not a problem, your rendering rates will typically be slower with<br />
ImmediateModeRendering turned on.<br />
<br />
==== Use triangle strips via vtkStripper. ====<br />
<br />
Most filters in VTK produce independent triangles or polygons which are<br />
not the most compact or efficient to render. To create triangle strips<br />
from polydata you can first use vtkTriangleFilter to convert any<br />
polygons to triangles (not required if you only have triangles to start<br />
with) then run it through a vtkStipper to convert the triangles into<br />
triangle strips. For example in C++<br />
<br />
vtkPolyDataReader *reader = vtkPolyDataReader::New();<br />
reader->SetFileName("yourdatafile.vtk");<br />
reader->GetOutput()->ReleaseDataFlagOn();<br />
<br />
vtkTriangleFilter *tris = vtkTriangleFilter::New();<br />
tris->SetInput(reader->GetOutput());<br />
tris->GetOutput()->ReleaseDataFlagOn();<br />
<br />
vtkStripper *strip = vtkStripper::New();<br />
strip->SetInput(tris->GetOutput());<br />
strip->GetOutput()->ReleaseDataFlagOn();<br />
<br />
vtkPolyDataMapper *mapper = vtkPolyDataMapper::New();<br />
mapper->ImmediateModeRenderingOn();<br />
mapper->SetInput(tris->GetOutput());<br />
<br />
The only disadvantage to using triangle strips is that they require time<br />
to compute, so if your data is changing every time you render, it could<br />
actually be slower.<br />
<br />
==== Use a different filter or mapper ====<br />
<br />
This is a tough issue. In VTK there are typically a couple of ways to<br />
solve any problem. For example an image can be rendered as a polygon for<br />
each pixel, or it can be rendered as a single polygon with a texture map<br />
on it. For almost all cases the second approach will be much faster than<br />
the first event though VTK supports both. There isn't a single good<br />
answer for how to find the best approach. If you suspect that it is<br />
running more slowly than it should, try posting to the mailing list or<br />
looking for other ways to achieve the same result.<br />
<br />
=== VTK is slow, what is wrong? ===<br />
<br />
We have heard people say that VTK is really slow. In many of these<br />
cases, changing a few parameters can make a huge difference in performance.<br />
<br />
If you find that VTK is slower than other visualization systems running<br />
the same problem first take a look at the FAQ section dealing with large<br />
data: [[VTK_FAQ#How_to_handle_large_data_sets_in_VTK|How to handle large data sets in VTK]]. Many of its suggestions<br />
will improve VTK's performance significantly for many datasets.<br />
<br />
If you still find VTK slow, please let us know and send us an example<br />
(to mailto:kitware@kitware.com). In the past there<br />
have been some filters that simply were not written to be fast. When we<br />
come across one of these we frequently can make minor changes to the<br />
filter that will make it run much more quickly. In fact many changes in<br />
the past couple years have been this type of performance improvement.<br />
<br />
=== Is VTK thread-safe ? ===<br />
<br />
The short answer is no.<br />
<br />
Many VTK sources and filters cache information and will not perform as<br />
expected when used in multiple threads. When writing a multithreaded<br />
filter, the developer has to be very careful about how she accesses data.<br />
<br />
For example, GetXXX() methods which return a pointer should only be used<br />
to read. If the pointer returned by these methods are used to change<br />
data in multiple threads (without mutex locks), the result will most<br />
probably be wrong and unpredictable. In many cases, there are<br />
alternative methods which copy the data referred by the pointer. For<br />
example:<br />
<br />
float* vtkDataArray::GetTuple(const vtkIdType i);<br />
<br />
is thread-safe only for reading whereas:<br />
<br />
void vtkDataArray::GetTuple (const vtkIdType i, float * tuple);<br />
<br />
copies the requested tuple and is thread safe even if tuple is modified<br />
afterwards (as long as the same pointer is not passed as the argument<br />
tuple simultaneously by different threads).<br />
<br />
Unfortunately, only very few methods are clearly marked as<br />
thread-(un)safe and, in many situations, the developer has to dig into<br />
the source code to figure out whether an accessor is thread safe or not.<br />
<br />
''vtkDataSet'' and most of it's sub-classes are well documented and almost<br />
all methods are marked thread-safe or not thread-safe. This might be a<br />
good place to start. Most of the filters in imaging and some filters in<br />
graphics (like ''vtkStreamer'') are good examples of how a multi-threaded<br />
filter can be written in VTK.<br />
<br />
However, if you are not interested in developing multithreaded filters<br />
but want to process some data in parallel using the same (or similar)<br />
pipeline, your job is much easier. To do this, create a different copy<br />
of the pipeline on each thread and execute them in parallel on a<br />
different piece of the data. This is best accomplished by using<br />
''vtkThreadedController'' (instead of ''vtkMultiThreader''). See the<br />
documentation of ''vtkMultiProcessController'' and ''vtkThreadedController''<br />
and the examples in the parallel directory for details on how this can<br />
be done.<br />
<br />
Also, note that most of the OpenGL libraries are not thread-safe.<br />
Therefore, if you are rendering to multiple render windows from<br />
different threads, you are likely to get in trouble, even if you have<br />
mutex locks around the render calls.<br />
<br />
=== Can I use STL with VTK? ===<br />
<br />
As of VTK version 4.2, you can use the STL.<br />
However, see the [[VTK Coding Standards]] for limitations.<br />
Here's an example (from vtkInterpolateVelocityField):<br />
<br />
In the .h file (the PIMPL) forward declare<br />
<br />
class vtkInterpolatedVelocityFieldDataSetsType;<br />
//<br />
class VTK_COMMON_EXPORT vtkInterpolatedVelocityField : public vtkFunctionSet<br />
{<br />
private:<br />
vtkInterpolatedVelocityFieldDataSetsType* DataSets;<br />
};<br />
<br />
In the .cxx file define the class (here deriving from the STL vector<br />
container)<br />
<br />
# include <vtkstd/vector><br />
typedef vtkstd::vector< vtkSmartPointer<vtkDataSet> > DataSetsTypeBase;<br />
class vtkInterpolatedVelocityFieldDataSetsType: public DataSetsTypeBase<br />
{};<br />
<br />
In the .cxx file construct and destruct the class:<br />
<br />
vtkInterpolatedVelocityField::vtkInterpolatedVelocityField()<br />
{<br />
this->DataSets = new vtkInterpolatedVelocityFieldDataSetsType;<br />
}<br />
vtkInterpolatedVelocityField::~vtkInterpolatedVelocityField()<br />
{<br />
delete this->DataSets;<br />
}<br />
<br />
And in the .cxx file use the container as you would any STL container:<br />
<br />
for ( DataSetsTypeBase::iterator i = this->DataSets->begin();<br />
i != this->DataSets->end(); ++i)<br />
{<br />
ds = i->GetPointer();<br />
....<br />
}<br />
<br />
=== What image file formats can VTK read and write? ===<br />
<br />
The following table identifies the image file formats that VTK can read<br />
and write.<br />
<br />
{| border="1" cellpadding="2" cellspacing="0"<br />
|- bgcolor="#abcdef"<br />
! Image File !! Read !! Write<br />
|-<br />
| AVI || || vtkAVIWriter<br />
|-<br />
| Bitmap || vtkBMPReader || vtkBMPWriter<br />
|-<br />
| Digital Elevation Model (DEM) || vtkDEMReader || <br />
|-<br />
| DICOM || vtkDICOMImageReader || <br />
|-<br />
| GE Signal || vtkGESignaReader || <br />
|-<br />
| JPEG || vtkJPEGReader || vtkJPEGWriter<br />
|-<br />
| FFMPEG || || vtkFFMPEGWriter<br />
|-<br />
| MINC (1.1) || vtkMINCImageReader || vtkMINCImageWriter<br />
|-<br />
| Binary UNC meta image data || vtkMetaImageReader || vtkMetaImageWriter<br />
|-<br />
| PNG || vtkPNGReader || vtkPNGWriter<br />
|-<br />
| PNM || vtkPNMReader || vtkPNMWriter<br />
|-<br />
| PostScript || || vtkPostScriptWriter <br />
|-<br />
| SLC || vtkSLCReader || <br />
|-<br />
| TIFF || vtkTIFFReader || vtkTIFFWriter<br />
|-<br />
| RAW files &dagger; || vtkImageReader, vtkVolumeReader || <br />
|}<br />
<br />
&dagger; A typical example of use is:<br />
<br />
# Image pipeline<br />
reader = vtkImageReader()<br />
reader.SetDataByteOrderToBigEndian()<br />
reader.SetDataExtent(0,511,0,511,0,511)<br />
reader.SetFilePrefix("Ser397")<br />
reader.SetFilePattern("%s/I.%03d")<br />
reader.SetDataScalarTypeToUnsignedShort()<br />
reader.SetHeaderSize(5432)<br />
<br />
=== Printing an object. ===<br />
<br />
Sometimes when debugging you need to print an object to a string, either<br />
for logging purposes, or in the case of windows applications, to a window.<br />
<br />
Here is a way to do this:<br />
<br />
std::ostringstream os;<br />
//<br />
// "SomeVTKObject" could be, for example, <br />
// declared somewhere as: vtkCamera *SomeVTKObject;<br />
//<br />
SomeVTKObject->Print(os);<br />
vtkstd::string str = os.str();<br />
//<br />
// Process the string as you want<br />
<br />
=== Writing a simple CMakeLists.txt. ===<br />
<br />
If you get something that looks like:<br />
<br />
undefined reference to<br />
`__imp___ZN13vtkTIFFReader3NewEv'<br />
collect2: ld returned 1 exit status <br />
<br />
You certainly forgot to pass in a library to your executable. The easisest way is to use CMakeLists.txt file.<br />
<br />
For example the minimal project is:<br />
<br />
FIND_PACKAGE(VTK)<br />
IF (VTK_FOUND)<br />
INCLUDE (${VTK_USE_FILE})<br />
ENDIF (VTK_FOUND)<br />
ADD_EXECUTABLE(tiff tiff.cxx )<br />
TARGET_LINK_LIBRARIES (tiff<br />
vtkRendering<br />
)<br />
<br />
Since vtkRendering is link against all other vtk lib. Except if you are building VTK with Hybrid or Parallel in that case you need to explicitely specify which library you want to link against.<br />
<br />
=== Testing for VTK within a configure script ===<br />
<br />
VTK uses CMake as build tool but if you VTK-based application wants to use autoconf and/or automake, then you will find very useful an M4 macro file which detects from your configure script the presence/absence of VTK on the user system. VTK won't add such file into the official distribution but you can always write your own, as I did.<br />
Look in [[VTK_Autoconf]] page for more info.<br />
<br />
=== How do I get my C++ code editor to do VTK-style indentation? ===<br />
<br />
If you are writing code with VTK, you may want to follow the [[VTK Coding Standards]]. This is particularly important if you plan to contribute back to VTK. Most C++ code editors will help you with indenting, but the indenting may differ significantly from that prescribed by the [[VTK Coding Standards]]. Fortunately, most editors have enough options to allow you to change the indention enough to get at least close to the VTK-style indentation.<br />
<br />
Below is a list of C++ editors and some suggestions on getting the indentation VTK compliant. If you use a popular editor that is not listed here, please feel free to contribute.<br />
<br />
==== Microsoft Visual C++ .NET indentation ====<br />
<br />
Under the "Tools" menu, select "Options". Go to the options under "Text Editor" and then "C/C++". Click the "Tabs" options. Set "Indenting" to "Smart", "Indent Size" to 2, and select "Insert spaces". Click the "Formatting" options enable "Indent braces".<br />
<br />
This will make most of the indentation correct. However, it will indent all of the braces. In VTK classes, most of the braces are indented, but those starting a class, method, or function are typically flush left. You will have to correct this on your own.<br />
<br />
==== Emacs indentation ====<br />
<br />
Place the [[Elisp Code for VTK-Style C Indentation]] in your .emacs file.<br />
<br />
==== Vim indentation ====<br />
<br />
[[user talk:Andy|Andy Cedilnik]] has some information on following the VTK coding guidelines using vim. You may place the following in your <code>~/.vimrc</code> file<br />
set tabstop=2 " Tabs are two characters<br />
set shiftwidth=2 " Indents are two charactes too<br />
set expandtab " Do not use tabs<br />
set cinoptions={1s,:0,l1,g0,c0,(0,(s,m1<br />
"Keep tabs in makefiles as they are significant:<br />
:autocmd BufRead,BufNewFile [Mm]akefile :set noexpandtab<br />
<br />
=== How to display transparent objects? ===<br />
(keywords: alpha, correct, depth, geometry, object, opacity, opaque, order, ordering, peel, peeling, sorting, translucent, transparent.)<br />
<br />
When opaque geometry is rendered, there is no need to sort it because the depth buffer (or z-buffer) is used and the sorting is done automatically by keeping the geometry closest to the viewpoint at<br />
a given pixel. (It is easy because it is a MAX/MIN calculation, not a real sorting).<br />
<br />
With translucent geometry the final color of a pixel is the contribution of all the geometry primitives visible through the pixel. The color of the pixel is the result of <b>a</b> blending operation between the colors of all visible primitives. Blending operations themselves are usually order-dependent (ie not commutative). That's why depth sorting is required. There are two ways to fix the ordering in VTK:<br />
<br />
*1. Append all your polygonal geometry with [http://www.vtk.org/doc/nightly/html/classvtkAppendPolyData.html vtkAppendPolyData] and pass it to [http://www.vtk.org/doc/nightly/html/classvtkDepthSortPolyData.html vtkDepthSortPolyData]. See this tcl [http://public.kitware.com/cgi-bin/viewcvs.cgi/*checkout*/Hybrid/Testing/Tcl/depthSort.tcl?root=VTK&content-type=text/plain example]. Depth sorting is done per centroid of geometry primitives, not per pixel. For this reason it is not exact but it solves <b>most</b> of the ordering and gives result usually good enough.<br />
* 2. If the graphics card supports it, use "[[VTK/Depth_Peeling | depth peeling]]". It performs per pixel sorting (better result) but it is really slow.<br />
<br />
=== What's the deal with SetInput() vs. SetInputConnection()? ===<br />
(keywords: SetInput, SetInputConnection, vtkAlgorithm, algorithm, pipeline, source)<br />
<br />
In the transition from VTK 4 to VTK 5, the VTK pipeline executive was completely cleaned up and redesigned. The fundamental idea behind the new pipeline is that the "pipeline" should consist of a chain of "algorithm" objects.<br />
The algorithms are connected together with the familiar b->SetInputConnection(a->GetOutputPort()) methods.<br />
<br />
So how is this different from SetInput()/GetOutput()? The difference between an "OutputPort" and an "Output" is as follows:<br />
<br />
* OutputPort (''vtkAlgorithmOutput''): A trivial object that says "I am output port N of algorithm X" (usually N = 0).<br />
* Output (''subclass of vtkDataObject''): A container for data produced by any VTK code.<br />
<br />
The "OutputPort" method does not presuppose anything about what data (if any) will pass along the pipeline. It could simply signify that algorithm "a" must execute before algorithm "b". This provides enormous flexibility. Trust the VTK designers here, it's better to do things this way than to have the user grab the actual data object from the output of one algorithm and shove it into the input of another.<br />
<br />
However, any newcomer to VTK will quickly notice that the use of SetInputConnection() is not universal. The reason is this: only vtkAlgorithm objects can have a SetInputConnection() or GetOutputPort() method. Some objects that can take inputs are not derived from vtkAlgorithm. For example vtkImageActor is a vtkProp3D and therefore it cannot be a vtkAlgorithm (VTK never uses multiple inheritance). This is a case of an old VTK object that doesn't "fit" the new VTK 5 pipeline. However, the VTK developers did not want to throw away such useful classes when the pipeline was redesigned. Instead, such classes are still served by the backwards-compatible SetInput() method.<br />
<br />
So, use SetInputConnection() whenever you can, but if there is no SetInputConnection(), then go ahead and use SetInput(). There is nothing wrong with doing so. The new pipeline is backwards compatible with the old pipeline methods.<br />
<br />
== Platform-specific questions ==<br />
<br />
=== What platforms does vtk run on? ===<br />
<br />
VTK should compile and run on most versions of Unix, Linux, Windows, and Mac OS X. <br />
<br />
=== What Graphics Cards work with VTK ===<br />
Modern graphics cards that supports OpenGL 2.1 or better typically provide all the functionality that VTK needs. However, there is good deal of variability in results across OS platform and vendor's OpenGL implementation. NVidia cards and drivers work the best. Intel HD integrated graphics and ATI Radeon HD devices and drivers are known to have a few issues. Mesa3D OpenGL although claiming support for a wide range of devices is highly unstable and the overall buggy-ness of their implementation changes daily and by renderer. Mesa's llvmpipe drivers are expected to generally work well. If there's an issue with one of Mesa's renderer's one might be able to work around by exporting the environment variable LIBGL_ALWAYS_SOFTWARE=1. Information about which driver and renderer are being used by VTK, and its capabilities, may be displayed by running "ctest -R LoadOpenGL --verbose" in a terminal from the VTK build/install dir.<br />
<br />
=== How do I build the Java examples on the PC running Windows? ===<br />
One common issue building the examples is missing one or all of vtkPanel, vtkCanvas and AxesActor<br />
classes. For whatever reason these are not in the vtk.jar (at least for 4.2.2).<br />
But you can get them from the source distribution (just unzip the source and extract<br />
these needed .java files, and point your Java-compiler to them).<br />
<br />
Another common issue appears to be class loading dependency errors. Make sure the<br />
directory with the .dll files is in your classpath when you run (default location<br />
is C:\Program Files\vtk42\bin\). Yet this still seems insufficient for some of the<br />
libraries. One possible solution is to copy the Java awt.dll to this directory as<br />
well.<br />
<br />
=== 64-bit System Issues ===<br />
<br />
===== General =====<br />
VTK binary files are not compatible between 32-bit and 64-bit systems. For portability, use the default file type, ASCII, for vtkPolyDataWriter, etc. You may be able to write a binary file on a 64-bit system and read it back in.<br />
<br />
===== Mac OS X Specific =====<br />
Mac OS X 10.3 and earlier have no support for 64 bit. On Mac OS X 10.4, VTK cannot be built as 64 bit because it requires Carbon, Cocoa, or X11, none of which are available to 64 bit processes. On Mac OS X 10.5 and later, Cocoa is available to 64 bit processes, but Carbon is not. VTK is known to work well with 64 bit Cocoa on Mac OS X 10.5 and later.<br />
<br />
===== Windows Specific =====<br />
todo<br />
<br />
=== Are there any benchmarks of VTK and/or the hardware it runs on? ===<br />
<br />
Take a look at the "Simple Sphere Benchmark":<br />
<br />
http://www.barre.nom.fr/vtk/bench.html<br />
<br />
It is not a "real world" benchmark, but provide synthetic results<br />
comparing different hardware running VTK:<br />
<br />
http://purl.oclc.org/NET/rriv/vtk/sphere-bench<br />
<br />
=== Why is XtString undefined when using VTK+Python on Unix? ===<br />
<br />
This is a side effect of dynamic linking on (some?) Unix systems. It<br />
appears often on Linux with the Mesa libraries at least. The solution is<br />
to make sure your Mesa libraries are linked with the Xt library. One way<br />
to do this is to add "-lXt" to MESA_LIB in your user.make file.<br />
<br />
=== How do I get the Python bindings to work when building VTK with Borland C++? ===<br />
<br />
If you've built VTK with the freely downloadable Borland C++ 5.5 (or its<br />
commercial counterpart) and you're using the Python binaries from<br />
http://www.python.org/, you'll note that when you try to run a VTK<br />
Python example you get something similar to the following error message:<br />
<br />
from vtkCommonPython import * <br />
ImportError: dynamic module does not define init function<br />
(initvtkCommonPython)<br />
<br />
This is because BCC32 prepends an underscore ("_") to all exported<br />
functions, so (in this case) the vtkCommonPython.dll contains a symbol<br />
_initvtkCommonPython which Python does not find. All kits (e.g.<br />
Rendering, Filtering, Patented) will suffer from this problem.<br />
<br />
The solution is to create Borland module definition in the VTK binary<br />
(output) directory, in my case VTK/bin. You have to do this for all kits<br />
that you are planning to use in Python. Each .def file must have the<br />
same basename as the DLL, e.g. "vtkCommonPython.def" for<br />
vtkCommonPython.dll and it must be present at VTK link time. The def<br />
file contains an export alias, e.g.:<br />
<br />
EXPORTS<br />
initvtkCommonPython=_initvtkCommonPython<br />
<br />
The Borland compiler will create an underscore-less alias in the DLL<br />
file and Python will be able to load it as a module.<br />
<br />
=== How do I build Python bindings on AIX? ===<br />
<br />
There is a problem with dynamic loading on AIX. Old AIX did not have<br />
dlopen/dlsym, but they used load mechanism. Python still reflects this.<br />
VTK is however not compatible with the old load mechanism.<br />
<br />
The following patch to Python 2.2.2 makes python use dlopen/dlsym on AIX<br />
5 or greater.<br />
<br />
http://www.vtk.org/files/misc/python_aix.diff<br />
<br />
=== How to build VTK for offscreen rendering? ===<br />
<br />
See http://paraview.org/Wiki/ParaView_And_Mesa_3D.<br />
<br />
=== How to get keyboard events working on Mac OS X? ===<br />
<br />
See [[Cocoa_VTK]] for details if you are having trouble getting keyboard events working.<br />
<br />
=== Can VTK be built as a Universal Binary on Mac OS X? ===<br />
<br />
For VTK 5.0.4 and older, the short answer is no. For more recent versions, certainly 5.6 and later, the answer is yes.<br />
<br />
You need to set CMAKE_OSX_ARCHITECTURES to the architectures you want and CMAKE_OSX_SYSROOT to a Mac OS X SDK that supports Universal builds. For example:<br />
<br />
CMAKE_OSX_ARCHITECTURES=ppc;i386 <br />
CMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4u.sdk<br />
<br />
=== How can I stop Java Swing or AWT components from flashing or bouncing between values? ===<br />
<br />
While not strictly a VTK problem, this comes up fairly often when using Java-wrapped VTK. Try the following two JRE arguments to stop the Swing/AWT components flashing:<br />
-Dsun.java2d.ddoffscreen=false -Dsun.java2d.gdiblit=false<br />
Note that these are classified as "unsupported properties," so may not work on all platform or installations (in particular, ddoffscreen refers to DirectDraw and, as such, is specific to Windows).<br />
<br />
=== How can a user process access more than 2 GB of ram in 32-bit Windows? ===<br />
<br />
By default on Windows, the most memory that a user process can access is 2 GB, no matter how much RAM you have installed in your system. With Windows XP Professional you can make it possible for a process to use up to 3 GB of memory by doing two things:<br />
<br />
1) Modify the boot parameters in boot.ini (on my 32 bit WinXP Pro machine, it's in: "C:\boot.ini") to tell the operating system that you want user processes to have access to up to 3GB of RAM (This is a really important file, and if you don't know what you are doing, stop reading this and go back to work!). This is done by adding the /3GB flag to the line of the file that tells the boot loader where the operating system is. My boot.ini file looks like:<br />
<br />
[boot loader]<br />
timeout=30<br />
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS<br />
[operating systems]<br />
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /3GB<br />
<br />
This is a very bad file to make mistakes on, so don't - it may be very difficult to repair your computer to boot if you mess up this file. There is a nice description of this in the Microsoft article <br />
[http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx Memory Support and Windows Operating Systems].<br />
<br />
2) The other thing that you need to do is make your executable LARGEADDRESSAWARE. Assuming that you have a Windows binary that you want to try this on, you can use the 'editbin' utility that comes with Visual Studio to change the setting of one bit (the IMAGE_FILE_LARGE_ADDRESS_AWARE bit) in the image header of the executable. For a program 'prog.exe' you can make the change by<br />
<br />
editbin /LARGEADDRESSAWARE prog.exe<br />
<br />
Of course, depending on how your program handles memory you might find that it crashes when you try to use the extra memory, but that's a separate issue. If you are compiling your program with a version of Visual Studio you should be able to find the switch to make your program /LARGEADDRESSAWARE.<br />
<br />
=== Shared builds of VTK and debugging QVTKWidget using Visual Studio ===<br />
<br />
Assuming that you have built a shared build of VTK and you may or may not have a set it up such that there is a path to the release version of VTK in your PATH statement.<br />
<br />
Then if you debug a project that is using QVTKWidget, you will come across a problem in that if you are debugging a debug version; the application depends upon the debug version of QVTK.dll which will depend upon QtGui4d.dll (among others) and load it. But, because the release version of QVTK.dll is in the path, QtGui4.dll will also be loaded preventing the application from running. You will get a<br />
"QWidget: Must construct a QApplication before a QPaintDevice"<br />
message.<br />
<br />
The solution to this problem is to set the path to the correct build of VTK on the "'''Debugging'''" properties of your project. Right click on your project, bring up the properties dialog, and select "'''Debugging'''" from the list on the left. There should be an "'''Environment'''" line. You can add variables here using key=value pairs.<br />
<br />
For example, add the following line:<br />
PATH=<Path To VTK>\bin\$(OutDir);%PATH%<br />
<br />
You can then add the same line to other configurations, such as the release one, by selecting them from the top left drop down box labelled '''Configuration'''.<br />
<br />
<code>$(OutDir)</code> will be set by Visual Studio to either Debug or Release, depending upon what configuration you have selected. Make sure that <code>;%PATH%</code> is appended so that Qt and other files can be appended to the PATH statement.<br />
<br />
[[File:VisualStudioDebuggingEnvironmentScreenshot.png|800px|Image: Screenshot in Visual Studio 2017]]<br />
<br />
== Changes to the VTK API ==<br />
<br />
=== What is the policy on Changes to the API ===<br />
<br />
Between patch releases maintain the API unless there is a really strong reason not to. <br />
<br />
Between regular releases maintain backwards compatibility to the API with prior releases of VTK when doing so does not increase the complexity or readability of the current VTK or when the benefits of breaking the API are negligible.<br />
<br />
Clearly these statements have a lot of wiggle room. For example in vtkLightKit BackLight and Headlight were used and released. Now BackLight and HeadLight might make more sense and probably will be easier for non-native English speakers, but is it worth breaking the API for it, probably not. Another factor is how long the API has been around and how widely used it is. These all indicate how painful it will be to change the API which is half of the cost/benefit decision.<br />
<br />
=== Change to vtkIdList::IsId() ===<br />
<br />
vtkIdList::IsId(int id) used to return a 0 or 1 to indicate whether the<br />
specified id is in the list. Now it returns -1 if the id is not in the<br />
list; or a non-negative number indicating the position in the list.<br />
<br />
=== Changes vtkEdgeTable ===<br />
<br />
vtkEdgeTable had two changes. The constructor now takes no arguments,<br />
and you use InitEdgeInsertion() to tell the class how many points are in<br />
the dataset. Also, IsEdge(p1,p2) now returns a -1 if the edge (defined<br />
by points p1,p2) is not defined. otherwise a non-negative integer value<br />
is returned.<br />
<br />
These changes were made to support the association of attributes with<br />
edges.<br />
<br />
=== Changes between VTK 4.2 and VTK 4.4 (and how to update) ===<br />
<br />
We have removed the CVS date, revision, and the language from the<br />
copyright on all the files. This information wasn't being used much and<br />
it created extra work for developers. For example you edit vtkObject.h<br />
rebuild all of VTK, check in you change, then you must rebuild all of<br />
VTK again because commiting the header file causes it to be changed by<br />
CVS (because the revision number changed) This change will also make it<br />
easier to compare different branches of VTK since these revision number<br />
differences will no longer show up. The CVS revision number is still in<br />
the cxx file in the RevisionMacro. You don't need to make any changes to<br />
your code for this.<br />
<br />
The DataArray classes now use a templated intermediate class to share<br />
their implementation. Again there is no need for you to make changes to<br />
your code.<br />
<br />
Legacy code has been removed. Specifically none of the old style<br />
callbacks are supported and observers should be used instead. So where<br />
you used a filter->SetStartMethod(myFunc) you should do a<br />
filter->AddObserver(vtkCommand::StartEvent,myCommand) Usually this will<br />
require you to create a small class for the observer.<br />
vtkImageOpenClose3D.cxx has an example of using an observer and there<br />
are a few other examples in VTK. If you switch to using Observers your<br />
code should also work with versions of VTK from 3.2 or later since the<br />
Observers have been in VTK since VTK 3.2.<br />
<br />
Many functions that previously took or returned float now take or return<br />
double. To change your code to work with VTK 4.4 or later you can just<br />
replace float with double for the appropriate calls and variables. If<br />
you want your code to work with both old and new versions of VTK you can<br />
use vtkFloatingPointType which is defined to be double in VTK 4.4 and<br />
later and it is float in vtk 4.2.5. In versions of VTK prior to 4.2.5<br />
you can use something like:<br />
<br />
#ifndef vtkFloatingPointType<br />
#define vtkFloatingPointType vtkFloatingPointType<br />
typedef float vtkFloatingPointType;<br />
#endif<br />
<br />
at the beginning of your code. That will set it to the correct value for<br />
all versions of VTK old and new.<br />
<br />
=== Use of New() and Delete() now enforced (vs. new & delete) ===<br />
<br />
Constructors and destructors in VTK are now protected. This means you<br />
can no longer use little "new" or "delete" to create VTK instances.<br />
You'll have to use the methods ::New() and ::Delete() (as has been<br />
standard practice for some time).<br />
<br />
The reason for this is to enforce the use of New() and Delete(). Not<br />
using New() and Delete() can lead to bad mojo, mainly reference counting<br />
problems or not taking advantage of special procedures incorporated into<br />
the New() method (e.g., selecting the appropriate hardware interface<br />
during instance creation time).<br />
<br />
If you've used New() and Delete() in your code, these changes will not<br />
affect you at all. If you're using little "new" or "delete", your code<br />
will no longer and compile and you'll have to switch to New() and Delete().<br />
<br />
=== Changes between VTK 4.4 and VTK 4.6 ===<br />
<br />
Collection Changes<br />
<br />
Collections have had some small changes (originally started by Chris<br />
Volpe) to better support reentrant iteration. Specifically all the<br />
collection have an InitTraversal(sit) and GetNextFoobar(sit) methods.<br />
(where Foobar is what the collection contains, for example<br />
GetNextActor(sit)) The argument to both of these methods is a<br />
vtkCollectionSimpleIterator. Most of the collection use in VTK has been<br />
modified to use these new methods. The advantage is that these new<br />
methods support having the same collection be iterated through in a<br />
reentrant safe manner. In the past this was not true and led to a number<br />
of problems. In the future for C++ class development please use this<br />
approach to iterating through a collection. These changes are fully<br />
backwards compatible and no old APIs were harmed in the making of these<br />
changes. So in summary, for the future, where you would have written:<br />
<br />
for (actors->InitTraversal();<br />
(actor = actors->GetNextActor());)<br />
<br />
you would now have:<br />
<br />
vtkCollectionSimpleIterator actorIt;<br />
for (actors->InitTraversal(actorIt);<br />
(actor = actors->GetNextActor(actorIt));)<br />
<br />
=== Changes to VTK between 4.0 and 4.2 ===<br />
<br />
* Use of macros to support serialization, standardize the New method, and provide the Superclass typedef.<br />
<br />
* Subclassing of VTK classes in the python wrappers (virtual method hooks are not provided).<br />
<br />
* vtkImageWindow, vtkImager, vtkTkImageWindowWidget and their subclasses have been removed to reduce duplicated code and enable interation in ImageWindows. Now people should use vtkRenderer and vtkRenderWindow instead. vtkImageViewer still works as a turn key image viewing class although it now uses vtkRenderWindow and vtkRenderer internally instead of vtkImageWindow and vtkImager.<br />
<br />
* New class: vtkBandedPolyDataContourFilter. Creates solid colored bands (like you find on maps) of scalar value.<br />
<br />
* Event processing: Several new events to VTK were added (see vtkCommand.h). Also event processing can now be prioritized and aborted. This allows applications to manage who processes which events, and terminates the processing of a particular event if desired.<br />
<br />
* 3D Widgets: A new class vtkInteractorObserver was added to observe events on vtkRenderWindowInteractor. Using the new event processing infrastructure, multiple 3D widgets (subclasses of vtkInteractorObserver) can be used simultaneously to process interactions. Several new 3D widgets have been added including:<br />
** vtkLineWidget<br />
** vtkPlaneWidget<br />
** vtkImagePlaneWidget<br />
** vtkBoxWidget<br />
** vtkSphereWidget<br />
<br />
* Besides providing a representation, widgets also provide auxiliary functionality such as providing transforms, implicit functions, plane normals, sphere radius and center, etc.<br />
<br />
* New class: vtkInstantiator provides a means by which one can create an instance of a VTK class using only the name of the class as a string.<br />
<br />
* New class: vtkXMLParser provides a wrapper around the Expat XML parsing library. A new parser can be written by subclassing from vtkXMLParser and providing a few simple virtual method implementations.<br />
<br />
* TIFF reader is now implemented using libtiff, which makes it capable of reading almost all available TIFF formats. The libtiff is also available internally as vtktiff.<br />
<br />
* New method (all sub-classes of vtkObject): Added a virtual function called NewInstance to vtkTypeMacro. NewInstance creates and returns an object of the same type as the current one. It does not copy any properties. The returned pointer is of the same type as the pointer the method was invoked with. This method should replace all the MakeObject methods scattered through VTK.<br />
<br />
* vtkSetObject macro is depricated for use inside the VTK. It is still a valid construct in projects that use VTK. Instead use vtkCxxSetObjectMacro which does the same thing.<br />
<br />
* vtkPLOT3DReader have been improved. It now supports:<br />
** multigrid (each block is one output)<br />
** ascii<br />
** fortran-style byte counts<br />
** little/big endian<br />
** i-blanking (partial)<br />
<br />
* A new vtkTextProperty class has been created, and duplicated text API s have been obsoleted accordingly. Check the<br />
[[VTK_FAQ#Text_properties_in_VTK_4.2|Text properties in VTK 4.2]] FAQ entry for a full description of the change.<br />
<br />
=== What is the release schedule for VTK ===<br />
<br />
VTK has a formal release every eight to sixteen months. VTK 4.0 was cut in December 2001 and released in March 2002. VTK 4.2 was released in February 2003. VTK 4.4 (which was an interim release) was released at the end of 2003. VTK 5.0 was released in January 2006, 5.0.1 in July 2006, 5.0.2 in September 2006, 5.0.3 in March 2007, and 5.0.4 in January 2008. A bunch more release have happened since then.<br />
<br />
=== Roadmap: What changes are being considered for VTK ===<br />
<br />
This is a list of changes that are being considered for inclusion into<br />
VTK. Some of these changes will happen while other changes we would like<br />
to see happen but may not due to funding or time issues. For each change<br />
we try to list what the change is, when we hope to complete it, if it is<br />
actively being developed. Detailed discussion on changes is limited to<br />
the vtk-developers mailing list.<br />
<br />
# Modify existing image filters to use the new vtkImageIterator etc. Most simple filters have been modified to use ithe iterator in VTK 4.2. It would be nice to have some sort of efficient neighborhood iterators but so far we haven't come up with any.<br />
# Rework the polydata and unstructured grid structures (vtkMesh ??). Related ideas include:<br />
#* Make UnstructuredGrid more compact by removing the cell point count from the vtkCellArray. This will reduce the storage required by each cell by 4 bytes.<br />
#* Make vtkPolyData an empty subclass of vtkUnstructuredGrid. There are a number of good reasons for this but it is a tricky task and backwards compatibility needs to be maintained.<br />
# More parallel support, including parallel compositing algorithms<br />
# Algorithms like LIC (http://www-courses.cs.uiuc.edu/~cs419/lic.pdf), maybe a couple terrain-decimation algorithms<br />
# Further integration of STL and other important C++ constructs (like templates)<br />
<br />
VTK 4.4 (intermediate release, end of 2003)<br />
<br />
* convert APIs to double (done)<br />
* remove old callbacks (done)<br />
* blanking<br />
* ref count observers (done)<br />
* switch collections to use iterators (done)<br />
* improve copyright (done)<br />
<br />
VTK 5.0 (major release, early 2005)<br />
<br />
* new pipeline mechanism (see [[Media:Pipeline.pdf|Pipeline.pdf]])<br />
* time support<br />
* true AMR support<br />
<br />
=== Changes to Interactors ===<br />
<br />
The Interactors have been updated to use the Command/Observer events of<br />
vtk. The vtkRenderWindowInteractor now has ivars for all the event<br />
information. There is a new class called<br />
vtkGenericRenderWindowInteractor that can be used to set up the bindings<br />
from other languages like python, Java or TCl.<br />
<br />
A new class vtkInteractorObserver was also added. It has a<br />
SetInteractor() method. It observes the keypress and delete events<br />
invoked by the render window interactor. The keypress activation value<br />
for a widget is now 'i' (although this can be programmed).<br />
vtkInteractorObserver has the state ivar Enabled. All subclasses must<br />
have the SetEnabled(int) method. Convenience methods like On(), Off(),<br />
EnabledOn(), and EnabledOff() are available. The state of the interactor<br />
observer is obtained using GetEnabled(). The SetEnabled(1) method adds<br />
observers to watch the interactor (appropriate to the particular<br />
interactor observer) ; SetEnabled(0) removes the observers . There are<br />
two new events: EnableEvent and DisableEvent which are invoked by the<br />
SetEnabled() method.<br />
<br />
The events also support the idea of priority now. When you add an<br />
observer, you can specify a priority from 0 to 1. Higher values will be<br />
called back first. An observer can also tell the object not to call any<br />
more observers. This way you can handle an event, and stop further<br />
processing. In this way you can add handlers to InteractorStyles without<br />
sub-classing and from wrapped languages.<br />
<br />
For more information see: vtkGenericRenderWindowInteractor,<br />
vtkRenderWindowInteractor, vtkInteractorObserver.<br />
<br />
=== Header files and vtkSetObjectMacro ===<br />
<br />
On some platforms such as MS Visual Studio .NET, compiler is not capable<br />
of handling too big input files. Some VTK files with all includes do<br />
become big enough to overwhelm the compiler. The solution is to minimize<br />
the amount of includes. This especially goes for header files, because<br />
they propagate to other files. Every class header file should include<br />
only the parent class header file. If there is no other alternative, you<br />
should put a comment next to include file explaining why the file has to<br />
be included.<br />
<br />
The related issue is with vtkSetObjectMacro. This file calles some<br />
methods on an argument class, which implies that the argument class<br />
header file has to be included. The result is bloat on the header files.<br />
The solution is to not use vtkSetObjectMacro but vtkCxxSetObjectMacro.<br />
The difference is that vtkCxxSetObjectMacro goes in the Cxx file and not<br />
in the header file.<br />
<br />
Example: Instead of<br />
<br />
#include "vtkBar.h"<br />
class vtkFoo : public vtkObject<br />
{ ...<br />
vtkSetObjectMacro(Bar, vtkBar);<br />
...<br />
};<br />
<br />
Do:<br />
<br />
class vtkBar;<br />
class vtkFoo : public vtkObject<br />
{<br />
...<br />
virtual void SetBar(vtkBar*);<br />
...<br />
};<br />
<br />
and add the following line to vtkFoo.cxx<br />
<br />
vtkCxxSetObjectMacro(vtkFoo,Bar,vtkBar);<br />
<br />
=== Text properties in VTK 4.2 ===<br />
<br />
A new<br />
[http://public.kitware.com/VTK/doc/nightly/html/classvtkTextProperty.html vtkTextProperty]<br />
class has been added to VTK 4.2.<br />
<br />
This class factorizes text attributes that used to be spread out and<br />
duplicated in many different classes (mostly 2D actors and text<br />
mappers). Among those attributes, font family, font size,<br />
bold/italic/shadow properties, horizontal and vertical justification,<br />
line spacing and offset have been retained, whereas new attributes like<br />
color and opacity have been introduced.<br />
<br />
We tried to make sure that you can use a vtkTextProperty to modify text<br />
properties in the same way a vtkProperty can be used to modify the<br />
surface properties of a geometric object. In that regard, you should be<br />
able to share a vtkTextProperty between different actors or assign the<br />
same vtkTextProperty to an actor that offers multiple vtkTextProperty<br />
attributes ([http://www.vtk.org/doc/nightly/html/classvtkXYPlotActor.html vtkXYPlot]<br />
for example).<br />
<br />
Here is a quick example:<br />
<br />
vtkTextActor *actor0 = vtkTextActor::New();<br />
actor0->GetTextProperty()->SetItalic(1);<br />
//<br />
vtkTextProperty *tprop = vtkTextProperty::New();<br />
tprop->SetBold(1);<br />
//<br />
vtkTextActor *actor1 = vtkTextActor::New();<br />
actor1->SetTextProperty(tprop);<br />
//<br />
vtkTextActor *actor2 = vtkTextActor::New();<br />
actor2->SetTextProperty(tprop);<br />
<br />
*Backward compatibility issues*:<br />
<br />
1) Color and Opacity:<br />
<br />
The text color and text opacity settings are now controlled by the<br />
vtkTextProperty Color and Opacity attributes instead of the<br />
corresponding actor's color and opacity attributes. In the following<br />
example, those settings were controlled by the attributes of the<br />
vtkProperty2D attached to the vtkActor2D (vtkTextActor). The<br />
vtkTextProperty attributes should be used instead:<br />
<br />
vtkTextActor *actor = vtkActor::New();<br />
actor->GetProperty()->SetColor(...);<br />
actor->GetProperty()->SetOpacity(...);<br />
<br />
becomes:<br />
<br />
actor->GetTextProperty()->SetColor(...);<br />
actor->GetTextProperty()->SetOpacity(...);<br />
<br />
To make migration easier for a while, we have set the vtkTextProperty<br />
default color to ''(-1.0, -1.0, -1.0)'' and the default opacity to ''-1.0''.<br />
These "magic" values are checked by the underlying text mappers at<br />
rendering time. If they are found, the color and opacity of the 2D<br />
actor's vtkProperty2D are used, just as it was in VTK 4.1.<br />
<br />
2) API (i.e. SetBold(), SetItalic(), etc)<br />
<br />
Most of the VTK classes involving text used to provide their own text<br />
attributes like Bold, Italic, Shadow, FontFamily. Thus, each of those<br />
classes would duplicate the vtkTextMapper API through methods like<br />
SetItalic(), SetBold(), SetFontFamily(), etc.<br />
<br />
Moreover, if one class had different text elements (say, for example,<br />
the title and the labels of a scalar bar), there was no way to modify<br />
the text properties of these elements separately.<br />
<br />
The vtkTextProperty class has been created to address both issues, by<br />
obsoleting those duplicated attributes and methods and providing a<br />
unified way to access text properties, and by allowing each class to<br />
associate different vtkTextProperty to different text elements.<br />
<br />
Migrating your code basically involves using the old API on your actor's<br />
vtkTextProperty instead of the actor itself. For example:<br />
<br />
actor->SetBold(1);<br />
<br />
becomes:<br />
<br />
actor->GetTextProperty()->SetBold(1);<br />
<br />
When a class provides different vtkTextProperty for different text<br />
elements, the TextProperty attribute is usually prefixed with that<br />
element type. Example: AxisTitleTextProperty, or AxisLabelTextProperty.<br />
This allows you to set different aspect for each text elements. If you<br />
want to use the same properties, you can either set the same values on<br />
each vtkTextProperty, or make both vtkTextProperty point to the same<br />
vtkTextProperty object. Example:<br />
<br />
actor->GetAxisLabelTextProperty()->SetBold(1);<br />
actor->GetAxisTitleTextProperty()->SetBold(1);<br />
<br />
or:<br />
<br />
vtkTextProperty *tprop = vtkTextProperty::New();<br />
tprop->SetBold(1);<br />
actor->SetAxisLabelTextProperty(tprop);<br />
actor->SetAxisTitleTextProperty(tprop);<br />
<br />
or:<br />
<br />
actor->SetAxisLabelTextProperty(actor->GetAxisTitleTextProperty());<br />
actor->GetAxisTitleTextProperty()->SetBold(1);<br />
<br />
The following list specifies the name of the text properties used in the<br />
VTK classes involving text.<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkTextMapper.html vtkTextMapper]:<br />
* you can still use the vtkTextMapper + vtkActor2D combination, but we would advise you to use a single vtkTextActor instead, this will give you maximum flexibility.<br />
* has 1 text prop: TextProperty, but although you have access to it, do not twwak it unless you are using vtkTextMapper with a vtkActor2D. In all other cases, use the text prop provided by the actor (see below).<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkTextActor.html vtkTextActor]:<br />
* has 1 text prop: TextProperty. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkLabeledDataMapper.html vtkLabeledDataMapper]:<br />
* has 1 text prop: LabelTextProperty. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkCaptionActor2D.html vtkCaptionActor2D]:<br />
* has 1 text prop: CaptionTextProperty. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkLegendBoxActor.html vtkLegendBoxActor]:<br />
* has 1 text prop: EntryTextProperty.<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkAxisActor2D.html vtkAxisActor2D],<br />
[http://www.vtk.org/doc/nightly/html/classvtkParallelCoordinatesActor.html vtkParallelCoordinatesActor], and<br />
[http://www.vtk.org/doc/nightly/html/classvtkScalarBarActor.html vtkScalarBarActor]:<br />
* have 2 text props: TitleTextProperty, LabelTextProperty.<br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkXYPlotActor.html vtkXYPlotActor]:<br />
* has 3 text prop: TitleTextProperty (plot title), AxisTitleTextProperty, AxisLabelTextProperty (title and labels of all axes)<br />
* the legend box text prop (i.e. entry text prop) can be retrieved through actor->GetLegendBoxActor()->GetEntryTextProperty()<br />
* the X (or Y) axis text props (i.e. title and label text props) can be retrieved through actor->GetX/YAxisActor2D->GetTitle/LabelTextProperty(), and will override the corresponding AxisTitleTextProperty or AxisLabelTextProperty props as long as they remain untouched. <br />
<br />
[http://www.vtk.org/doc/nightly/html/classvtkCubeAxesActor2D.html vtkCubeAxesActor2D]:<br />
* has 2 text props: AxisTitleTextProperty, AxisLabelTextProperty (title and label of all axes)<br />
* the X (Y or Z) axis text props (i.e. title and label text props) can be retrieved through actor->GetX/Y/ZAxisActor2D->GetTitle/LabelTextProperty(), and will override the corresponding AxisTitleTextProperty or AxisLabelTextProperty props as long as they remain untouched.<br />
<br />
=== Forward declaration in VTK 4.x ===<br />
<br />
Since VTK 4.x all classes have been carefully inspected to only include the necessary headers, and do what is called 'forward declaration' for all other needed classes. Thus, when you compile your projects using a filter that takes as input a dataset and you are passing an imagedata: you need to explicitly include imagedata within your implementation file. This is true for all data types.<br />
<br />
For example, if you get this error:<br />
<br />
no matching function for call to `vtkContourFilter::SetInput(vtkImageData*)'<br />
VTK/Filtering/vtkDataSetToPolyDataFilter.h:44:<br />
candidates are: virtual void vtkDataSetToPolyDataFilter::SetInput(vtkDataSet*)<br />
<br />
This means you need to add in your code : #include "vtkImageData.h"<br />
<br />
=== API Changes in VTK 5.2 ===<br />
<br />
==== <tt>vtkProp::RenderTranslucentGeometry()</tt> is gone ====<br />
<br />
<tt>vtkProp::RenderTranslucentGeometry()</tt> is gone and has been broken down into 3 methods:<br />
* <tt>HasTranslucentPolygonalGeometry()</tt><br />
* <tt>RenderTranslucentPolygonalGeometry()</tt><br />
* <tt>RenderVolumetricGeometry()</tt><br />
<br />
Here is what to change in a vtkProp subclass:<br />
* If <tt>RenderTranslucentGeometry()</tt> was used to render translucent polygonal geometry only, override <tt>HasTranslucentPolygonalGeometry()</tt> and <tt>RenderTranslucentPolygonalGeometry()</tt>. <b>Just renaming <tt>RenderTranslucentGeometry()</tt> as <tt>RenderTranslucentPolygonalGeometry()</tt> is not enough!</b><br />
* If <tt>RenderTranslucentGeometry()</tt> was used to render translucent volumetric geometry only, override <tt>RenderVolumetricGeometry()</tt>. In this case, just renaming <tt>RenderTranslucentGeometry()</tt> as <tt>RenderVolumetricGeometry()</tt> is OK.<br />
* If <tt>RenderTranslucentGeometry()</tt> was used to render translucent polygonal geometry and translucent volumetric geometry, override all 3 methods.<br />
<br />
The reason of this change is that <tt>HasTranslucentPolygonalGeometry()</tt> is used to decide if an expensive initialization of the new rendering algorithm of translucent polygonal geometry (depth peeling) is necessary. <tt>RenderTranslucentPolygonalGeometry()</tt> is called multiple times during the rendering of the translucent polygonal geometry of the scene. <tt>RenderVolumetricGeometry()</tt> is called in an additional pass, after depth peeling. For this reason, <b><tt>RenderTranslucentGeometry()</tt> cannot just be marked as deprecated but had to be removed from the API</b>.<br />
<br />
<br />
<br />
==== <tt>vtkImagePlaneWidget</tt> has action names changed ====<br />
from:<br />
enum<br />
{<br />
CURSOR_ACTION = 0,<br />
SLICE_MOTION_ACTION = 1,<br />
WINDOW_LEVEL_ACTION = 2<br />
};<br />
to:<br />
enum<br />
{<br />
VTK_CURSOR_ACTION = 0,<br />
VTK_SLICE_MOTION_ACTION = 1,<br />
VTK_WINDOW_LEVEL_ACTION = 2<br />
};<br />
<br />
==== <tt>GetOutput()</tt> now returns <tt>vtkDataObject</tt> for some algorithms ====<br />
<br />
The following algorithms now work on <tt>vtkGraph</tt> as well as <tt>vtkDataSet</tt>, so no <tt>GetOutput()</tt> longer returns <tt>vtkDataSet</tt>. To obtain the dataset, use <tt>vtkDataSet::SafeDownCast(filter->GetOutput())</tt><br />
* <tt>vtkArrayCalculator</tt><br />
* <tt>vtkAssignAttribute</tt><br />
* <tt>vtkProgrammableFilter</tt><br />
<br />
=== API Changes in VTK 5.4 ===<br />
* empty right now.<br />
=== API Changes in VTK 5.5 ===<br />
<br />
* vtkStreamTracer<br />
Changed<br />
enum Units <br />
{ <br />
TIME_UNIT, <br />
LENGTH_UNIT, <br />
CELL_LENGTH_UNIT <br />
}<br />
to<br />
enum Units<br />
{ <br />
LENGTH_UNIT = 1, <br />
CELL_LENGTH_UNIT = 2 <br />
}<br />
<br />
<br />
Changed<br />
* OUT_OF_TIME = 4<br />
to<br />
* OUT_OF_LENGTH = 4<br />
in enum ''ReasonForTermination''<br />
<br />
<br />
Changed<br />
* LastUsedTimeStep<br />
to<br />
* LastUsedStepSize<br />
<br />
<br />
Changed<br />
* MaximumPropagation<br />
* MaximumIntegrationStep<br />
* MinimumIntegrationStep<br />
* InitialIntegrationStep <br />
from type ''IntervalInformation'' to type ''double''.<br />
<br />
<br />
Added a member variable to the class<br />
* int IntegrationStepUnit<br />
<br />
<br />
The following APIs were '''removed''' from the class:<br />
* void SetMaximumProgration(int unit, double max)<br />
* void SetMaximumProgrationUnit(int unit)<br />
* int GetMaximumPropagationUnit()<br />
* void SetMaximumPropagationUnitToTimeUnit()<br />
* void SetMaximumPropagationUnitToLengthUnit()<br />
* void SetMaximumPropagationUnitToCellLengthUnit()<br />
* void SetMinimumIntegrationStep(int unit, double step)<br />
* void SetMinimumIntegrationStepUnit(int unit)<br />
* int GetMinimumIntegrationStepUnit()<br />
* void SetMinimumIntegrationStepUnitToTimeUnit()<br />
* void SetMinimumIntegrationStepUnitToLengthUnit()<br />
* void SetMinimumIntegrationStepUnitToCellLengthUnit()<br />
* void SetMaximumIntegrationStep(int unit, double step)<br />
* void SetMaximumIntegrationStepUnit(int unit)<br />
* int GetMaximumIntegrationStepUnit()<br />
* void SetMaximumIntegrationStepUnitToTimeUnit()<br />
* void SetMaximumIntegrationStepUnitToLengthUnit()<br />
* void SetMaximumIntegrationStepUnitToCellLengthUnit()<br />
* void SetInitialIntegrationStep(int unit, double step)<br />
* void SetInitialIntegrationStepUnit(int unit)<br />
* int GetInitialIntegrationStepUnit()<br />
* void SetInitialIntegrationStepUnitToTimeUnit()<br />
* void SetInitialIntegrationStepUnitToLengthUnit()<br />
* void SetInitialIntegrationStepUnitToCellLengthUnit()<br />
* void SetIntervalInformation(int unit, double interval, IntervalInformation& currentValues)<br />
* void SetIntervalInformation(int unit,IntervalInformation& currentValues)<br />
* void ConvertIntervals(double& step, double& minStep, double& maxStep, int direction, double cellLength, double speed)<br />
* static double ConvertToTime(IntervalInformation& interval, double cellLength, double speed)<br />
* static double ConvertToLength(IntervalInformation& interval, double cellLength, double speed)<br />
* static double ConvertToCellLength(IntervalInformation& interval, double cellLength, double speed)<br />
* static double ConvertToUnit(IntervalInformation& interval, int unit, double cellLength, double speed)<br />
<br />
<br />
The following APIs were added to the class:<br />
* int GetIntegrationStepUnit()<br />
* void SetIntegrationStepUnit(int unit)<br />
* void ConvertIntervals(double& step, double& minStep, double& maxStep, int direction, double cellLength)<br />
* static double ConvertToLength(double interval, int unit, double cellLength)<br />
* static double ConvertToLength(IntervalInformation& interval, double cellLength)<br />
<br />
<br />
* vtkInterpolatedVelocityField<br />
Added a new member variable and two associated functions:<br />
* bool NormalizeVector<br />
* vtkSetMacro(NormalizeVector, bool)<br />
* vtkGetMacro(NormalizeVector, bool)<br />
<br />
== OpenGL requirements ==<br />
VTK requires at least OpenGL 1.1. VTK currently (v6.1) makes use of up to OpenGL 2.1 and a handful of extensions. Currently (v6.1) VTK makes use of the compatibility context and is not OpenGL 3.0 core compliant (http://www.opengl.org/wiki/Core_And_Compatibility_in_Contexts). If a given algorithm requires an OpenGL version or extension greater than what's available on a given system then either a fallback algorithm will be employed, as in the case of depth peeling, or an error will be reported indicating the required extension could not be found. One can display information about the system's OpenGL implementation as seen by VTK through the LoadOpenGL ctest. From a terminal in VTK build dir run "ctest -R LoadOpenGL --verbose". This will dump various driver information and list the extensions that VTK can use.<br />
<br />
=== Terminology ===<br />
* a software component using OpenGL (like VTK) <b>requires</b> some minimal version of OpenGL and some minimal set of OpenGL extensions at runtime. At compile time, it <b>requires</b> an OpenGL header file (<tt>gl.h</tt>) compatible with some minimal version of the OpenGL API.<br />
* an OpenGL implementation (software (like Mesa) or hardware (combination of a graphic card and its driver) ) <b>supports</b> some OpenGL versions and a set of extensions.<br />
<br />
=== How do I check which OpenGL versions or extensions are supported by my graphic card or OpenGL implementation? ===<br />
==== Linux/Unix ====<br />
Two ways:<br />
* General method<br />
<pre><br />
$ glxinfo<br />
</pre><br />
* vendor specific tool<br />
if you have an nVidia card and nvidia-settings installed on it, run it and go to the OpenGL/GLX Information item under the X Screen 0 item.<br />
<br />
==== Windows ====<br />
You can download and use GLview http://www.realtech-vr.com/glview<br />
<br />
==== Mac OS X ====<br />
With Xcode installed, Macintosh HD->Developer->Applications->Graphic Tools->OpenGL Driver Monitor.app->Monitors->Renderer Info-><name of the OpenGL driver>->OpenGL Extensions<br />
<br />
=== VTK 5.0 ===<br />
==== What is the minimal OpenGL version of the API required to compile VTK5.0? ====<br />
The <tt>gl.h</tt> file provided by your compiler/system/SDK has to define at least the OpenGL 1.1 API.<br />
<br />
(Note: the functions and macros defined in higher OpenGL API versions or in other OpenGL extensions are provided by <tt>glext.h</tt>, <tt>glxext.h</tt> and <tt>wglext.h</tt>. Those 3 files are official files taken from http://opengl.org/registry/ and already part of the VTK source tree).<br />
<br />
==== What is the minimal OpenGL version required by VTK5.0 at runtime? ====<br />
All the VTK classes using OpenGL require an OpenGL implementation (software or hardware) >=1.1 except for <tt>vtkVolumeTextureMapper3D</tt>.<br />
<br />
If you want to use <tt>vtkVolumeTextureMapper3D</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* extension <tt>GL_EXT_texture3D</tt> or OpenGL>=1.2<br />
and<br />
* extension <tt>GL_ARB_multitexture</tt> or OpenGL>=1.3<br />
and either:<br />
* extensions <tt>GL_ARB_fragment_program</tt> and <tt>GL_ARB_vertex_program</tt><br />
or:<br />
* extensions <tt>GL_NV_texture_shader2</tt> and <tt>GL_NV_register_combiners</tt> and <tt>GL_NV_register_combiners2</tt><br />
<br />
=== VTK 5.2 ===<br />
==== What is the minimal OpenGL version of the API required to compile VTK5.2? ====<br />
Same answer than for VTK 5.0.<br />
<br />
==== What is the minimal OpenGL version required by VTK5.2 at runtime? ====<br />
All the VTK classes using OpenGL require an OpenGL implementation (software or hardware) >=1.1 except for <tt>vtkVolumeTextureMapper3D</tt>, <tt>vtkHAVSVolumeMapper</tt>,<br />
<tt>vtkGLSLShaderProgram</tt>, depth peeling and some hardware offscreen rendering using framebuffer objects (FBO).<br />
<br />
If you want to use <tt>vtkVolumeTextureMapper3D</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* extension <tt>GL_EXT_texture3D</tt> or OpenGL>=1.2<br />
and<br />
* extension <tt>GL_ARB_multitexture</tt> or OpenGL>=1.3<br />
and either:<br />
* extensions <tt>GL_ARB_fragment_program</tt> and <tt>GL_ARB_vertex_program</tt><br />
or:<br />
* extensions <tt>GL_NV_texture_shader2</tt> and <tt>GL_NV_register_combiners</tt> and <tt>GL_NV_register_combiners2</tt><br />
<br />
If you want to use <tt>vtkHAVSVolumeMapper</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* OpenGL>=1.3<br />
* <tt>GL_ARB_draw_buffers</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_fragment_program</tt><br />
* <tt>GL_ARB_vertex_program</tt><br />
* <tt>GL_EXT_framebuffer_object</tt><br />
* either <tt>GL_ARB_texture_float</tt> or <tt>GL_ATI_texture_float</tt><br />
<br />
The following extension or OpenGL version is used by <tt>vtkHAVSVolumeMapper</tt> if provided (at runtime), but it is optional:<br />
* <tt>GL_ARB_vertex_buffer_object</tt> or OpenGL>=1.5<br />
<br />
If you want to use <tt>vtkGLSLShaderProgram</tt>, the following extensions or OpenGL versions are required (at runtime):<br />
* OpenGL>=1.3<br />
* <tt>GL_ARB_shading_language_100</tt> or OpenGL>=2.0,<br />
* <tt>GL_ARB_shader_objects</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_vertex_shader</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_fragment_shader</tt> or OpenGL>=2.0.<br />
<br />
Depth peeling ( see [[VTK/Depth_Peeling | VTK Depth Peeling]] for more information) requires (at runtime):<br />
* <tt>GL_ARB_depth_texture</tt> or OpenGL>=1.4<br />
* <tt>GL_ARB_shadow</tt> or OpenGL>=1.4<br />
* <tt>GL_EXT_shadow_funcs</tt> or OpenGL>=1.5<br />
* <tt>GL_ARB_vertex_shader</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_fragment_shader</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_shader_objects</tt> or OpenGL>=2.0<br />
* <tt>GL_ARB_occlusion_query</tt> or OpenGL>=1.5<br />
* <tt>GL_ARB_multitexture</tt> or OpenGL>=1.3<br />
* <tt>GL_ARB_texture_rectangle</tt><br />
* <tt>GL_SGIS_texture_edge_clamp</tt> or <tt>GL_EXT_texture_edge_clamp</tt> or OpenGL>=1.2<br />
<br />
Hardware-based offscreen rendering using framebuffer object (FBO) will be used as the default offscreen method if the following extensions or OpenGL version are available (at runtime):<br />
* <tt>GL_EXT_framebuffer_object</tt><br />
and either <br />
* <tt>GL_ARB_texture_non_power_of_two</tt> or OpenGL>=2.0<br />
or<br />
* <tt>GL_ARB_texture_rectangle</tt><br />
In addition, if the the framebuffer needs a stencil buffer, extension <tt>GL_EXT_packed_depth_stencil</tt> is required. Even if all those extensions are supported, the chosen FBO format might<br />
not be supported by the card; in this case, this method of offscreen rendering is not used.<br />
<br />
== Miscellaneous questions ==<br />
<br />
=== Can't you split up the data file? ===<br />
<br />
The data is now in one file that is about 15 Megabytes. This is smaller<br />
than the original data files VTK used and we hope that this size is not<br />
a problem for people anymore. If it is please let us know.<br />
<br />
=== Do you have any shared library tips? ===<br />
<br />
VTK version 4.0 and later supports both shared and static libraries on<br />
most all platforms. For development we typically use shared libraries<br />
since they are faster to link when making small changes. You can control<br />
how VTK builds by setting the BUILD_SHARED_LIBS option in CMake.<br />
<br />
== Legal issues ==<br />
<br />
=== Is VTK FDA-Approved ? ===<br />
<br />
Given the fact that VTK is a software toolkit, it cannot be the<br />
subject of FDA approval as a medical device. We have discussed<br />
this topic in several occasions and received advice from FDA<br />
representatives, that can be summarized as follow:<br />
<br />
<br />
VTK is to be considered as an off-the-shelf (OTS) product that<br />
is used for supporting a higher level medical application/product.<br />
The developer of such application/product will be responsible for<br />
performing the validation processes described in FDA published<br />
guidelines for the development of software-related medical devices.<br />
<br />
For mode details see the page [[FDA Guidelines for Software Development]]<br />
<br />
=== What are the legal issues? ===<br />
<br />
The Visualization Toolkit software is provided under the following<br />
copyright. [http://www.vtk.org/VTK/project/license.html]<br />
<br />
=== Can VTK be used as part of a project distributed under a GPL License ? ===<br />
<br />
==== Short Answer ====<br />
<br />
Yes, it is fine to take VTK code and to include it in a project that is distributed under a GPL license.<br />
<br />
==== Long Answer ====<br />
<br />
===== Terms =====<br />
<br />
Let's call project X the larger project that:<br />
<br />
# Will include source code from VTK (in part or as a whole)<br />
# Will be distributed under GPL license<br />
<br />
Note in particular that:<br />
<br />
# The copyright notices in VTK files must be kept.<br />
# If VTK files are modified by the developers of project X, that fact must be clearly indicated.<br />
# Only the modifications of VTK files made by the developers of project X will be covered by a GPL license. The original VTK code remains covered by the VTK license.<br />
# The collection of copyrighted works (project X in this case), that includes VTK (in part or as a whole) and their software will be covered by a GPL license.<br />
<br />
===== Details =====<br />
<br />
As the [http://www.vtk.org/copyright.php VTK license] is a variation of the [http://www.opensource.org/licenses/bsd-license.php Modified BSD license], to which only the following term has been added:<br />
<br />
Modified source versions must be plainly marked as such, <br />
and must not be misrepresented as being the original software.<br />
<br />
and that the Modified BSD license is itself compatible with the GPL <br />
<br />
http://www.gnu.org/philosophy/license-list.html (Modified BSD license)<br />
<br />
Then the VTK license is also compatible with the GPL license. Since the terms of the GPL license do not preclude the additional term of the VTK license from being followed.<br />
<br />
NOTE: The licenses are only '''one way compatible'''.<br />
<br />
* You can use VTK code inside a GPL licensed project.<br />
* You '''can not''' use GPL licensed code inside VTK.<br />
<br />
That is the reason why there are no GPL third party libraries in VTK. Having GPL third party libraries in VTK would prevent closed source projects from being built against VTK.<br />
<br />
== Common problems and their solutions ==<br />
* There are some problems may that arise while building VTK that have very straight forward solutions. [[VTK/BuildingProblems|Here]] they are.<br />
* There are some problems that arise frequently that have very straight forward solutions. [[VTK/CommonProblems|Here]] they are.<br />
<br />
{{VTK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=File:VisualStudioDebuggingEnvironmentScreenshot.png&diff=63827File:VisualStudioDebuggingEnvironmentScreenshot.png2019-07-22T14:40:54Z<p>Dzenanz: Screenshot for "Shared builds of VTK and debugging QVTKWidget using Visual Studio"</p>
<hr />
<div>Screenshot for "Shared builds of VTK and debugging QVTKWidget using Visual Studio"</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Configuring_and_Building/VisualStudio&diff=63826ITK/Configuring and Building/VisualStudio2019-07-18T18:50:12Z<p>Dzenanz: Update to tool versions from mid-2019</p>
<hr />
<div>With Visual Studio 2017 on Windows 10 (64-bit):<br />
<br />
* Launch the CMake GUI (version 3.15) from the start menu<br />
* Next to "Where is the source code:", click "Browse Source..." and navigate to where you cloned the repository with Git.<br />
* Next to "Where to build the binaries:", select "Browse Build..." and select a place to build the ITK library. I like to use c:\build\ITK. This directory should NOT be inside the directory where you cloned the repository.<br />
* Click "Configure", and then specify "Visual Studio 15 2017" as the generator and "x64" as the platform for this project.<br />
* Choose your build options. I like to '''uncheck''' BUILD_EXAMPLES and BUILD_TESTING, because not building them speeds up the build process significantly.<br />
* Click "Generate".<br />
* Click "Open Project". This will start a new Visual Studio instance.<br />
* From the Build menu, choose "Build Solution" (or "Build ALL_BUILD")</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Debug_Visualizers_for_Visual_Studio&diff=62850ITK/Debug Visualizers for Visual Studio2018-05-18T13:56:44Z<p>Dzenanz: New visualizers!</p>
<hr />
<div>__TOC__<br />
<br />
== Visual Studio 2008/2010 ==<br />
<br />
Visual studio has support for custom visualization of user types in debugger (watch window and mouse hover).<br />
<br />
File C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Packages\Debugger\autoexp.dat controls how different datatypes are displayed. The file itself contains instructions on how to modify it. Anyone can add custom definitions for their own classes. The file below contains definitions for some of the ITK's classes. The contents of ''itk_debug_visualizers.dat'' should be merged into ''autoexp.dat''.<br />
<br />
With VS2008 SP1 and newer you don't even have to modify ''autoexp.dat'', you can add environment variable '''_vcee_autoexp''' which points to your own file which will then be combined with the system one on the fly by Visual Studio each time debugging session is started (F5 pressed). <br />
<br />
Watch window displaying itk::Image using enhanced view:<br />
<br />
[[File:WatchImage.png]]<br />
<br />
itk::Image with underlying buffer expanded (limited to first million elements):<br />
<br />
[[File:WatchBuffer.png]]<br />
<br />
I have started building this file, but it only contains support for itk::Image, the classes image contains and basic iterator types. With distributed effort, anyone can contribute a visualizer for a class or two for everyone's benefit.<br />
<br />
=== itk_debug_visualizers.dat ===<br />
<br />
<source lang="lisp"><br />
;InsightToolkit enhanced debugger visualizers for Visual Studio<br />
;I used this: http://www.virtualdub.org/blog/pivot/entry.php?id=120<br />
;as the main guide. This too: http://www.filetolink.com/17ad36ef<br />
;using Notepad++ with LISP/Scheme syntax highlight is better than plain text<br />
;Dženan Zukić<br />
<br />
[ExecutionControl]<br />
;syntax myfunctionname=NoStepInto<br />
<br />
;do not step into any of the SmartPointer's methods<br />
itk::SmartPointer::*=NoStepInto<br />
<br />
[Visualizer]<br />
<br />
;-----------------------------------Size-----------------------------------<br />
itk::Size<*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_Size)[$i],<br />
size : $T1<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_Size)[$i],<br />
size : $T1<br />
),<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------Index-----------------------------------<br />
itk::Index<*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_Index)[$i],<br />
size : $T1<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_Index)[$i],<br />
size : $T1<br />
),<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------FixedArray-----------------------------------<br />
itk::FixedArray<double,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
):[$e,g],<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
itk::FixedArray<*,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
),<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------CovariantVector-----------------------------------<br />
;covariant vector is exactly the same as fixed array, from which it is derived<br />
;because CovariantVector does not introduce any new member variables<br />
<br />
;specialization for double<br />
;otherwise there are too many digits displayed in preview<br />
itk::CovariantVector<double,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
):[$e,g],<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
itk::CovariantVector<*,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
),<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------Point-----------------------------------<br />
;point is exactly the same as fixed array, from which it is derived<br />
;because point does not introduce any new member variables<br />
<br />
;specialization for double<br />
;otherwise there are too many digits displayed in preview<br />
itk::Point<double,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
):[$e,g],<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
itk::Point<*,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
),<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------Vector-----------------------------------<br />
;same as point<br />
<br />
itk::Vector<double,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T1<br />
):[$e,g],<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
itk::Vector<*,*>{<br />
children<br />
(<br />
#(<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"[",<br />
#array(<br />
expr : ($c.m_InternalArray)[$i],<br />
size : $T2<br />
),<br />
"]"<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------ImportImageContainer-----------------------------------<br />
itk::ImportImageContainer<*,*>{ <br />
children<br />
(<br />
#(<br />
size: $c.m_Size,<br />
capacity: $c.m_Capacity,<br />
#(uglyAll: [$c,!]),<br />
#array(<br />
expr : ($c.m_ImportPointer)[$i],<br />
size : $c.m_Size<br />
)<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"Alloc ",<br />
$c.m_Size,<br />
" of ",<br />
$c.m_Capacity<br />
)<br />
)<br />
}<br />
<br />
<br />
;Note: ImageRegion and/or ImageBase(Image) have a bugged preview<br />
;I don't know whether this is a bug in VS or my code is wrong<br />
;It does not impair function but it does look ugly<br />
<br />
;-----------------------------------ImageRegion-----------------------------------<br />
itk::ImageRegion<*>{<br />
children<br />
(<br />
#(<br />
size: $c.m_Size,<br />
index: $c.m_Index<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
"R", $c.m_Size<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------ImageBase-----------------------------------<br />
itk::ImageBase<*>{<br />
children<br />
(<br />
#(<br />
size: $c.m_LargestPossibleRegion,<br />
origin: $c.m_Origin,<br />
spacing: $c.m_Spacing,<br />
#(allMembers: [$c,!])<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
$c.m_LargestPossibleRegion,<br />
"@",<br />
$c.m_Origin<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------Image-----------------------------------<br />
;derived from ImageBase + m_Buffer<br />
;but it is dependent on one more template parameter<br />
<br />
itk::Image<*,*>{<br />
children<br />
(<br />
#(<br />
size: $c.m_LargestPossibleRegion,<br />
origin: $c.m_Origin,<br />
spacing: $c.m_Spacing,<br />
buffer: $c.m_Buffer,<br />
#(allMembers: [$c,!])<br />
)<br />
)<br />
<br />
preview<br />
(<br />
#(<br />
$c.m_LargestPossibleRegion,<br />
"@",<br />
$c.m_Origin<br />
)<br />
)<br />
}<br />
<br />
;for iterators, just define preview (which uses default children)<br />
;for this purpose, we can use the same code for all the basic iterators<br />
<br />
;-----------------------------------ImageConstIterator-----------------------------------<br />
itk::ImageConstIterator<*>{ <br />
preview<br />
(<br />
#(<br />
" [",<br />
$c.m_Offset,<br />
"] ",<br />
*($c.m_Buffer+$c.m_Offset)<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------ImageIterator-----------------------------------<br />
itk::ImageIterator<*>{ <br />
preview<br />
(<br />
#(<br />
" [",<br />
$c.m_Offset,<br />
"] ",<br />
*($c.m_Buffer+$c.m_Offset)<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------ImageRegionConstIterator-----------------------------------<br />
itk::ImageRegionConstIterator<*>{ <br />
preview<br />
(<br />
#(<br />
" [",<br />
$c.m_Offset,<br />
"] ",<br />
*($c.m_Buffer+$c.m_Offset)<br />
)<br />
)<br />
}<br />
<br />
;-----------------------------------ImageRegionIterator-----------------------------------<br />
itk::ImageRegionIterator<*>{ <br />
preview<br />
(<br />
#(<br />
" [",<br />
$c.m_Offset,<br />
"] ",<br />
*($c.m_Buffer+$c.m_Offset)<br />
)<br />
)<br />
}<br />
<br />
;the below visualizer for smart pointer is a worthless "improvement" over the deafult<br />
;-----------------------------------SmartPointer-----------------------------------<br />
;itk::SmartPointer<*>{<br />
; children<br />
; (<br />
; #(<br />
; ptr: *($c.m_Pointer)<br />
; )<br />
; )<br />
;<br />
; preview<br />
; (<br />
; #(<br />
; (void *)$c.m_Pointer,<br />
; " ",<br />
; *($c.m_Pointer)<br />
; )<br />
; )<br />
;}<br />
</source><br />
<br />
== Visual Studio 2012 ==<br />
<br />
Visual Studio 2012 introduces a novel type visualization framework called ''natvis''. A good [http://code.msdn.microsoft.com/windowsdesktop/Writing-type-visualizers-2eae77a2 natvis tutorial] is hosted on MSDN. Natvis files are now defined per user and can be put in following folder: '''%USERPROFILE%/documents/visual studio 2012/visualizers'''<br />
<br />
Support for the new style of debug visualizers is added in this [http://review.source.kitware.com/#/c/23441/ patch].<br />
<br />
[http://visualstudiogallery.msdn.microsoft.com/e682d542-7ef3-402c-b857-bbfba714f78d Image Watch] is a Visual Studio add-on which allows developers to display 2D images during debug sessions. In order to integrate support for the display of 2D ITK images, copy [https://gist.github.com/hauke76/5082634 this natvis file] into the 'visualizers' directory mentioned above.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=Template:ITKVTKCMakeLists&diff=62635Template:ITKVTKCMakeLists2018-04-25T20:59:38Z<p>Dzenanz: Update cmake version to 3.9.5</p>
<hr />
<div>==CMakeLists.txt==<br />
{{#tag:syntaxhighlight<br />
|<br />
cmake_minimum_required(VERSION 3.9.5)<br />
<br />
project({{{1}}})<br />
<br />
find_package(ITK REQUIRED)<br />
include(${ITK_USE_FILE})<br />
if (ITKVtkGlue_LOADED)<br />
find_package(VTK REQUIRED)<br />
include(${VTK_USE_FILE})<br />
else()<br />
find_package(ItkVtkGlue REQUIRED)<br />
include(${ItkVtkGlue_USE_FILE})<br />
set(Glue ItkVtkGlue)<br />
endif()<br />
<br />
add_executable({{{1}}} MACOSX_BUNDLE {{{1}}}.cxx)<br />
target_link_libraries({{{1}}}<br />
${Glue} ${VTK_LIBRARIES} ${ITK_LIBRARIES})<br />
|lang=cmake}}<br />
<br />
==Download and Build {{{1}}}==<br />
Click [https://github.com/lorensen/ITKWikiExamplesTarballs/raw/master/{{{1}}}.tar here to download ''{{{1}}}'']. and its ''CMakeLists.txt'' file.<br />
Once the tarball ''{{{1}}}.tar'' has been downloaded and extracted,<br />
cd {{{1}}}/build <br />
* If ITK is installed:<br />
cmake ..<br />
* If ITK is not installed but compiled on your system, you will need to specify '''the path to your ITK build''':<br />
cmake -DITK_DIR:PATH='''/home/me/itk_build''' ..<br />
Build the project,<br />
make<br />
and run it:<br />
./{{{1}}}<br />
'''WINDOWS USERS PLEASE NOTE:''' Be sure to add the VTK and ITK bin directories to your path. This will resolve the VTK and ITK dll's at run time.<br />
<br />
==Building All of the Examples==<br />
Many of the examples in the ITK Wiki Examples Collection require VTK. You can build all of the the examples by following [[ITK/Examples/Instructions/ForUsers#Build_all_of_the_examples|these instructions]]. If you are a new VTK user, you may want to try the [[ITK/Examples/Instructions/ForUsers#Use_the_Superbuild_to_build_a_proper_VTK_and_ITK|Superbuild]] which will build a proper ITK and VTK.<br />
==ItkVtkGlue==<br />
===ITK >= 4===<br />
For examples that use QuickView (which depends on VTK), you must have built ITK with Module_ITKVtkGlue=ON.<br />
<br />
===ITK < 4===<br />
Some of the ITK Examples require VTK to display the images. If you download the entire ITK Wiki Examples Collection, the ItkVtkGlue directory will be included and configured. If you wish to just build a few examples, then you will need to [https://github.com/InsightSoftwareConsortium/ITKWikiExamples/raw/master/ItkVtkGlue.tar.gz download ItkVtkGlue] and build it. When you run cmake it will ask you to specify the location of the ItkVtkGlue binary directory.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62155ITK Release 5/Wish List2017-12-13T21:11:45Z<p>Dzenanz: /* Requiring CMake >= 3.0 */</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
* Speed up CMake configure time, by doing less compiler testing or by sharing those results between library components<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Support initializer lists in constructors of array like objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.<br />
<br />
== Uncategorized minor wishes ==<br />
* Suport for remote module testing against multiple versions of ITK.<br />
* Being able to compile a remote module against an installed ITK would be nice for this structure.<br />
* We should consider stripping down the toolkit into a set of core modules for ITK 5, and putting less-used modules into Remote Modules<br />
** Measure the code coverage for Remote Modules.<br />
* Measure the code coverage per PR.<br />
* Rolling compiler support. Each new release will support compilers released in the last 3-5 years. This will allow us to gradually adopt newer language versions, as C++ standards committee aims to revise the language every 3 years.<br />
* Better document and advertise tools that seem extremely useful for making the use (configure, build, use) of ITK or the development of new modules [https://github.com/InsightSoftwareConsortium/ITKDevelopmentEnvironment less dependent] on the local computing resources, or more [https://github.com/InsightSoftwareConsortium/ITKModuleTemplate automated] and flexible, improvements to CI, use of cookiecutter, etc. There are other tools/projects such as [https://github.com/InsightSoftwareConsortium/itk-js itk.js] whose adoption seem to be low.<br />
* Update icon in maintenance directory.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62154ITK Release 5/Wish List2017-12-13T21:10:07Z<p>Dzenanz: /* Uncategorized minor wishes */</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Support initializer lists in constructors of array like objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.<br />
<br />
== Uncategorized minor wishes ==<br />
* Suport for remote module testing against multiple versions of ITK.<br />
* Being able to compile a remote module against an installed ITK would be nice for this structure.<br />
* We should consider stripping down the toolkit into a set of core modules for ITK 5, and putting less-used modules into Remote Modules<br />
** Measure the code coverage for Remote Modules.<br />
* Measure the code coverage per PR.<br />
* Rolling compiler support. Each new release will support compilers released in the last 3-5 years. This will allow us to gradually adopt newer language versions, as C++ standards committee aims to revise the language every 3 years.<br />
* Better document and advertise tools that seem extremely useful for making the use (configure, build, use) of ITK or the development of new modules [https://github.com/InsightSoftwareConsortium/ITKDevelopmentEnvironment less dependent] on the local computing resources, or more [https://github.com/InsightSoftwareConsortium/ITKModuleTemplate automated] and flexible, improvements to CI, use of cookiecutter, etc. There are other tools/projects such as [https://github.com/InsightSoftwareConsortium/itk-js itk.js] whose adoption seem to be low.<br />
* Update icon in maintenance directory.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62151ITK Release 5/Wish List2017-12-09T15:01:11Z<p>Dzenanz: /* Uncategorized minor wishes */</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Support initializer lists in constructors of array like objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.<br />
<br />
== Uncategorized minor wishes ==<br />
* Suport for remote module testing against multiple versions of ITK.<br />
* Being able to compile a remote module against an installed ITK would be nice for this structure.<br />
* We should consider stripping down the toolkit into a set of core modules for ITK 5, and putting less-used modules into Remote Modules<br />
* Rolling compiler support. Each new release will support compilers released in the last 3-5 years. This will allow us to gradually adopt newer language versions, as C++ standards committee aims to revise the language every 3 years.<br />
* Better document and advertise tools that seem extremely useful for making the use (configure, build, use) of ITK or the development of new modules [https://github.com/InsightSoftwareConsortium/ITKDevelopmentEnvironment less dependent] on the local computing resources, or more [https://github.com/InsightSoftwareConsortium/ITKModuleTemplate automated] and flexible, improvements to CI, use of cookiecutter, etc. There are other tools/projects such as [https://github.com/InsightSoftwareConsortium/itk-js itk.js] whose adoption seem to be low.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62144ITK Release 5/Wish List2017-12-05T17:03:31Z<p>Dzenanz: /* Uncategorized minor wishes */</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Support initializer lists in constructors of array like objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.<br />
<br />
== Uncategorized minor wishes ==<br />
* Suport for remote module testing against multiple versions of ITK.<br />
* Being able to compile a remote module against an installed ITK would be nice for this structure.<br />
* We should consider stripping down the toolkit into a set of core modules for ITK 5, and putting less-used modules into Remote Modules<br />
* Rolling compiler support. Each new release will support compilers released in the last 3-5 years. This will allow us to gradually adopt newer language versions, as C++ standards committee aims to revise the language every 3 years.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62142ITK Release 5/Wish List2017-12-04T22:34:16Z<p>Dzenanz: /* Uncategorized minor wishes */</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.<br />
<br />
== Uncategorized minor wishes ==<br />
* Suport for remote module testing against multiple versions of ITK.<br />
* Rolling compiler support. Each new release will support compilers released in the last 3-5 years. This will allow us to gradually adopt newer language versions, as C++ standards committee aims to revise the language every 3 years.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62141ITK Release 5/Wish List2017-12-04T22:22:59Z<p>Dzenanz: Uncategorized minor wishes</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.<br />
<br />
== Uncategorized minor wishes ==<br />
Suport for remote module testing against multiple versions of ITK.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=62140ITK Release 5/Wish List2017-12-04T22:18:59Z<p>Dzenanz: /* C++11 throughout */ Usage of C++11</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** Portability issue of "char", "signed char" and "unsigned char" need to be discussed and addressed before using uint8_t and int8_t<br />
*** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== Requiring CMake >= 3.0 ==<br />
* Currently supports CMake >=2.8.9 mostly to support Ubuntu 14.04 LTS (5 year support)<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
Note: Some c++ >= 11 features may not be supported by CastXML (and by pygccxml): https://github.com/CastXML/CastXML/issues/72<br />
Before implementing fancy stuff it should be double-checked if it does not break the Wrappings.<br />
<br />
To justify the change I’d like to see some good use of it in ITK. Some things that first come to mind:<br />
<br />
* Support move semantics for the core ITK objects<br />
* Have implementations that make use of C++11 threads<br />
* Have a FunctorFilter which supports lambda expressions<br />
* Rvalue support<br />
* A updated style guideline which requires less typedefs ( auto keyword )<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.<br />
<br />
== Wrapping ==<br />
* Take into account default template arguments in Python wrappings. See http://review.source.kitware.com/#/c/21606/ for discussion.<br />
<br />
== Filter Refactoring ==<br />
* The current Functor based filters create code bloat because each class instance requires two instantiated classes. An alternative Functor approach should be used where the same class can be used any functor. One approach is to use a "SefFunctor" method which generates the GenerateData method.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/File_Formats&diff=62133ITK/File Formats2017-11-13T18:45:44Z<p>Dzenanz: 64-bit pixel type support on all platforms provided by http://review.source.kitware.com/#/c/21513/</p>
<hr />
<div>ITK features a powerful plugin-based IO mechanism for reading and writing images, which is covered briefly in [[Plugin IO mechanisms]] and in detail in Chapter 7 (PDF page 219) of the [http://www.itk.org/ItkSoftwareGuide.pdf ITK Software Guide]. The discussion in [[Plugin IO mechanisms]] also discusses how new file formats can be added existing compiled applications!<br />
<br />
== File Formats and Pixel Types ==<br />
<br />
The itk::Image<> class can be templated over virtually any pixel type, however not all file formats support all data types for reading and writing. In some cases, it may be necessary to add an itk::CastImageFilter<> to convert the output to a pixel format appropriate for the target file. It is important not to truncate the data by converting to a smaller type (ie. short -> char). In this case, the itk::RescaleIntensityImageFilter<> can be used before casting.<br />
<br />
The following table lists the built-in file format support against each data type:<br />
<br />
* Analyze/NIFTI<br />
char<br />
unsigned char<br />
short<br />
unsigned short<br />
int<br />
unsigned int<br />
long long (on 64-bit platforms)<br />
unsigned long long (on 64-bit platforms)<br />
float<br />
double<br />
RGB<unsigned char><br />
* BMP (2D only)<br />
unsigned char<br />
RGB<unsigned char><br />
* DICOM<br />
float<br />
char<br />
unsigned char<br />
short<br />
unsigned short<br />
RGB<char><br />
RGB<short><br />
* GDCM<br />
unsigned char<br />
char<br />
unsigned short<br />
short<br />
unsigned int<br />
int<br />
double<br />
* GE<br />
???<br />
* GIPL<br />
binary<br />
char<br />
unsigned char<br />
short<br />
unsigned short<br />
int<br />
unsigned int<br />
float<br />
double<br />
surface<br />
polygon<br />
* IPL<br />
short<br />
* JPEG (2D only)<br />
unsigned char<br />
* MetaImage (mhd): raw, compressed<br />
char<br />
unsigned char<br />
short<br />
unsigned short<br />
long<br />
ulong<br />
int<br />
unsigned int<br />
long long (on 64-bit platforms)<br />
unsigned long long (on 64-bit platforms)<br />
float<br />
double<br />
vector<><br />
Also supports reading and writing <br />
- itk's SpatialObjects (i.e., scenes containing ellipses, images, vessels, dti fiber tracks, etc)<br />
- Patient Meta Data (orientation, scan date, comments, modality, etc. - user extensible)<br />
- data stored in multiple files (e.g., a metaImage file could be a text file pointing to a series of<br />
2D images that are stacked to form the 3D metaImage).<br />
Reference: http://www.itk.org/Wiki/MetaIO<br />
* Nrrd (.nhdr, .nrrd): raw or gzip compressed<br />
signed char<br />
unsigned char<br />
short<br />
unsigned short<br />
int<br />
unsigned int<br />
long long (on 64-bit platforms)<br />
unsigned long long (on 64-bit platforms)<br />
float<br />
double<br />
vector<><br />
Also supports reading and writing<br />
- all the pixel types in ImageIOBase, including DIFFUSIONTENSOR3D<br />
- MetaData dictionary, via mapping to key/value pairs<br />
- data from multiple files, using MetaIO conventions<br />
[[Getting Started with the NRRD Format]]<br />
<br />
[http://teem.sourceforge.net/nrrd/format.html NRRD format definition]<br />
<br />
*PNG (2D)<br />
unsigned char<br />
unsigned short<br />
RGB<br />
RGBA<br />
* SiemensVision<br />
???<br />
* Stimulate<br />
char<br />
short<br />
int<br />
float<br />
double<br />
* TIFF (2D only)<br />
unsigned char<br />
unsigned short<br />
RGB<br />
* VTK<br />
float<br />
double<br />
unsigned char<br />
char<br />
unsigned short<br />
short<br />
unsigned int<br />
int<br />
unsigned long long (on 64-bit platforms)<br />
long long (on 64-bit platforms)<br />
RGB<br />
<br />
== Importing other file format ==<br />
<br />
=== Movies as 3D images ===<br />
<br />
From the Insight-User Amadeus:<br />
<br />
I work exclusively in Linux and one can use mplayer - the mother of all<br />
multimedia tools - to dump each frame in a movie clip. MPlayer understands<br />
just about any format under the sun and can use just about any codec as<br />
well. E.g. to dump each frame in an avi clip to a separate png image<br />
<br />
mplayer -vo png movie.avi<br />
<br />
To see to what other formats one can output the frames to, <br />
<br />
mplayer -vo help<br />
<br />
Then, the frames dumped by mplayer can be put together into a volume<br />
using ImageSeriesReadWrite in InsightToolkit-2.0.0/Examples/IO/.<br />
<br />
Of course, in Linux and other unixes the shell understands wildcards, <br />
so with minor changes, it ImageSeriesReadWrite can be modified to work<br />
like this:<br />
<br />
ImageSeriesReadWrite frame*.png output.mha # or e.g. output.mhd<br />
<br />
The input frames need not have the names that the original<br />
ImageSeriesReadWrite expects.<br />
<br />
=== Converting unsupported 2D images to an ITK supported format ===<br />
<br />
[http://www.imagemagick.org ImageMagick] supports conversion between over 90 (typically 2D) image formats as well as some basic image processing. Operates from the command line on PCs and on *nix machines.<br />
<br />
{{ITK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/Statistics/Histogram&diff=61961ITK/Examples/Statistics/Histogram2017-08-30T16:37:21Z<p>Dzenanz: Fixing bug (double assignment)</p>
<hr />
<div>==Histogram.cxx==<br />
<source lang="cpp"><br />
#include "itkHistogram.h"<br />
<br />
int main(int, char *[])<br />
{<br />
typedef float MeasurementType;<br />
typedef itk::Statistics::Histogram< MeasurementType,<br />
itk::Statistics::DenseFrequencyContainer2 > HistogramType;<br />
HistogramType::Pointer histogram = HistogramType::New();<br />
<br />
unsigned int dimension = 3;<br />
HistogramType::SizeType size(dimension);<br />
<br />
unsigned int binsPerDimension = 30;<br />
size.Fill(binsPerDimension);<br />
<br />
HistogramType::MeasurementVectorType lowerBound;<br />
lowerBound.SetSize(binsPerDimension);<br />
lowerBound.Fill(1.1);<br />
<br />
HistogramType::MeasurementVectorType upperBound;<br />
upperBound.SetSize(binsPerDimension);<br />
upperBound.Fill(6.2);<br />
<br />
histogram->SetMeasurementVectorSize(dimension);<br />
histogram->Initialize(size, lowerBound, upperBound );<br />
<br />
histogram->SetFrequency(0UL, 0.0);<br />
histogram->SetFrequency(1UL, 2.0);<br />
histogram->SetFrequency(2UL, 3.0);<br />
histogram->SetFrequency(3UL, 2.0);<br />
histogram->SetFrequency(4UL, 0.5);<br />
histogram->SetFrequency(5UL, 1.0);<br />
histogram->SetFrequency(6UL, 5.0);<br />
histogram->SetFrequency(7UL, 2.5);<br />
histogram->SetFrequency(8UL, 0.0);<br />
<br />
HistogramType::IndexType index(dimension);<br />
index[0] = 0;<br />
index[1] = 2;<br />
index[2] = 4;<br />
std::cout << "Frequency of the bin at index " << index<br />
<< " is " << histogram->GetFrequency(index) << std::endl;<br />
<br />
<br />
std::cout << "Measurement vector at bin " << index << " is "<br />
<< histogram->GetMeasurementVector(index) << std::endl;<br />
<br />
HistogramType::MeasurementVectorType mv(dimension);<br />
mv[0] = 4.1;<br />
mv[1] = 5.6;<br />
mv[2] = 3.6;<br />
<br />
HistogramType::IndexType resultingIndex;<br />
histogram->GetIndex(mv, resultingIndex);<br />
<br />
std::cout << "Index of the measurement vector " << mv<br />
<< " is " << resultingIndex << std::endl;<br />
<br />
index.Fill(100);<br />
if ( histogram->IsIndexOutOfBounds(index) )<br />
{<br />
std::cout << "Index " << index << " is out of bounds." << std::endl;<br />
}<br />
<br />
std::cout << "Number of bins = " << histogram->Size()<br />
<< " Total frequency = " << histogram->GetTotalFrequency()<br />
<< " Dimension sizes = " << histogram->GetSize() << std::endl;<br />
<br />
std::cout << "50th percentile along the first dimension = "<br />
<< histogram->Quantile(0, 0.5) << std::endl;<br />
<br />
return EXIT_SUCCESS;<br />
}<br />
</source><br />
<br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/Statistics/KdTreeBasedKmeansEstimator&diff=61959ITK/Examples/Statistics/KdTreeBasedKmeansEstimator2017-08-30T14:49:53Z<p>Dzenanz: Make the code work</p>
<hr />
<div>==KdTreeBasedKmeansEstimator.cxx==<br />
<source lang="cpp"><br />
#include "itkDecisionRule.h"<br />
#include "itkVector.h"<br />
#include "itkListSample.h"<br />
#include "itkKdTree.h"<br />
#include "itkWeightedCentroidKdTreeGenerator.h"<br />
#include "itkKdTreeBasedKmeansEstimator.h"<br />
#include "itkMinimumDecisionRule.h"<br />
#include "itkEuclideanDistanceMetric.h"<br />
#include "itkDistanceToCentroidMembershipFunction.h"<br />
#include "itkSampleClassifierFilter.h"<br />
#include "itkNormalVariateGenerator.h"<br />
<br />
<br />
int main(int, char *[])<br />
{<br />
typedef itk::Vector< double, 3 > MeasurementVectorType;<br />
typedef itk::Statistics::ListSample< MeasurementVectorType > SampleType;<br />
SampleType::Pointer sample = SampleType::New();<br />
sample->SetMeasurementVectorSize( 3 );<br />
<br />
MeasurementVectorType mv;<br />
mv[0] = 181; mv[1] = 181; mv[2] = 173;<br />
sample->PushBack(mv);<br />
mv[0] = 165.376; mv[1] = 166.376; mv[2] = 160.376;<br />
sample->PushBack(mv);<br />
mv[0] = 139.64; mv[1] = 140.64; mv[2] = 134.64;<br />
sample->PushBack(mv);<br />
mv[0] = 178.688; mv[1] = 181.416; mv[2] = 174.552;<br />
sample->PushBack(mv);<br />
mv[0] = 175.328; mv[1] = 176.328; mv[2] = 168.328;<br />
sample->PushBack(mv);<br />
mv[0] = 180.52; mv[1] = 181.52; mv[2] = 173.52;<br />
sample->PushBack(mv);<br />
mv[0] = 174.456; mv[1] = 176.456; mv[2] = 165.456;<br />
sample->PushBack(mv);<br />
mv[0] = 180; mv[1] = 177; mv[2] = 172;<br />
sample->PushBack(mv);<br />
mv[0] = 179.696; mv[1] = 176.696; mv[2] = 171.696;<br />
sample->PushBack(mv);<br />
<br />
mv[0] = 195.88; mv[1] = 191.88; mv[2] = 188.88;<br />
sample->PushBack(mv);<br />
mv[0] = 207.36; mv[1] = 206.36; mv[2] = 202.36;<br />
sample->PushBack(mv);<br />
mv[0] = 176.672; mv[1] = 176.008; mv[2] = 171.336;<br />
sample->PushBack(mv);<br />
mv[0] = 180.176; mv[1] = 181.176; mv[2] = 174.088;<br />
sample->PushBack(mv);<br />
mv[0] = 171.304; mv[1] = 172.304; mv[2] = 166.304;<br />
sample->PushBack(mv);<br />
mv[0] = 161; mv[1] = 162; mv[2] = 156.032;<br />
sample->PushBack(mv);<br />
mv[0] = 166.96; mv[1] = 167.96; mv[2] = 162.96;<br />
sample->PushBack(mv);<br />
mv[0] = 169; mv[1] = 170; mv[2] = 164.392;<br />
sample->PushBack(mv);<br />
mv[0] = 165.104; mv[1] = 166.104; mv[2] = 160.104;<br />
sample->PushBack(mv);<br />
mv[0] = 170.264; mv[1] = 171.264; mv[2] = 164.896;<br />
sample->PushBack(mv);<br />
mv[0] = 165.472; mv[1] = 165.944; mv[2] = 158.888;<br />
sample->PushBack(mv);<br />
<br />
typedef itk::Statistics::WeightedCentroidKdTreeGenerator< SampleType > TreeGeneratorType;<br />
TreeGeneratorType::Pointer treeGenerator = TreeGeneratorType::New();<br />
<br />
treeGenerator->SetSample( sample );<br />
treeGenerator->SetBucketSize( 16 );<br />
std::cout << "Tree measurement vector size: " << treeGenerator->GetMeasurementVectorSize() << std::endl;<br />
treeGenerator->Update();<br />
<br />
typedef TreeGeneratorType::KdTreeType TreeType;<br />
typedef itk::Statistics::KdTreeBasedKmeansEstimator<TreeType> EstimatorType;<br />
EstimatorType::Pointer estimator = EstimatorType::New();<br />
<br />
EstimatorType::ParametersType initialMeans(2*3);<br />
initialMeans.Fill(165.0f);<br />
initialMeans[3] = 200;<br />
initialMeans[4] = 200;<br />
initialMeans[5] = 200;<br />
<br />
estimator->SetParameters( initialMeans );<br />
estimator->SetKdTree( treeGenerator->GetOutput() );<br />
estimator->SetMaximumIteration( 200 );<br />
estimator->SetCentroidPositionChangesThreshold(0.0);<br />
estimator->StartOptimization();<br />
<br />
EstimatorType::ParametersType estimatedMeans = estimator->GetParameters();<br />
std::cout << "estimatedMeans: " << estimatedMeans << std::endl;<br />
<br />
return EXIT_SUCCESS;<br />
}<br />
</source><br />
<br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=Plugin_IO_mechanisms&diff=60979Plugin IO mechanisms2016-11-02T17:13:12Z<p>Dzenanz: /* Registering a factory */ double word</p>
<hr />
<div>ITK provides a very flexible ImageIO mechanism supporting factories. This allows for a single reader class and a single writer class that can input/output a variety of file formats. When ImageFileReader begins to read a file, it queries the ObjectFactory system for any factory that can supply an ImageIOBase. This subset of factories is queried in turn to locate a factory that can understand the format of the requested file.<br />
<br />
New image file formats can be added to ITK by deriving a class from ImageIOBase that will support reading/writing the new file format. The file format can be added to the factory mechanism by creating a subclass of ObjectFactoryBase for this new ImageIO class. This subclass of ObjectFactoryBase will create an override in the factory mechanism indicating it can create an ImageIOBase. This is done in the constructor of the subclass of ObjectFactoryBase for the new image format:<br />
<br />
MyImageIOFactory::MyImageIOFactory()<br />
{<br />
this->RegisterOverride("itkImageIOBase",<br />
"itkMyImageIO",<br />
"My Image IO",<br />
1,<br />
CreateObjectFunction<MyImageIO>::New()); <br />
}<br />
<br />
== Registering a factory ==<br />
<br />
For the factory mechanism to use the factory for the new image format, the new factory must be "registered" with the factory mechanism. A stock set of such factories are registered automatically by ImageIOFactory. To register additional factories,<br />
<br />
* Add the new format to the list of formats registered by default in ImageIOFactory::RegisterBuiltInFactories().<br />
** This is should only be done if the new format is to be widely adopted by the entire ITK community.<br />
* Register the factory in your application code that uses that factory<br />
** This is reasonable if you only need to use the file format in your own applications.<br />
<br />
ObjectFactoryBase::RegisterFactory( MyImageIOFactory::New() ); <br />
<br />
* Use the factory plugin mechanism to dynamically register the factory.<br />
** This is useful if you have existing ITK applications that you do not wish to recompile (or can recompile) but you would like them to be able to use your new file format.<br />
<br />
== Plugin mechanism ==<br />
<br />
ITK's object factory mechanism supports dynamically loading factories from shared libraries. This mechanism can be used to dynamically load factories for new image file formats. The object factory will look at the ITK_AUTOLOAD_PATH environment variable to locate dynamically loadable factories (plugins).<br />
<br />
export ITK_AUTOLOAD_PATH=/home/me/myplugins<br />
<br />
If the ITK_AUTOLOAD_PATH is set, each shared library in each directory in that path is examined for a "C" method (not a C++ method)<br />
<br />
ObjectFactoryBase* itkLoad()<br />
<br />
If the method itkLoad() is found in the shared library, it is called. itkLoad() must return a pointer to an ObjectFactoryBase. The object factory mechanism then calls ObjectFactoryBase::RegisteryFactory(), passing in the pointer returned by itkLoad(). <br />
<br />
To add a new image file format to an existing application, we can simply wrap the associated ImageIOFactory for the new format inside a shared object that provides the itkLoad() mechanism. Any precompiled ITK application will then be able to read and write this new format.<br />
<br />
=== Caveats ===<br />
<br />
The object factory mechanism will make sure that the dynamically loaded ImageIOFactory was built with the same version of ITK as the application. If they are not a warning will be presented. <br />
<br />
Possible imcompatible factory load.<br />
Running itk version : xx.xx.xx<br />
Loaded Factory versions: yy.yy.yy<br />
Loaded factory: /path/to/factory<br />
<br />
Factories dynamically loaded that were built with a different version of ITK than the application '''may be unstable'''.<br />
<br />
== Example ==<br />
<br />
To add the MyImageIOFactory as a dynamically loaded factory, we need to create a shared library with an itkLoad() method and place that shared library in the ITK_AUTOLOAD_PATH. Here is an example CMakeLists.txt file for creating the plugin shared library<br />
<br />
SET(MYIO_SRCS itkMyImageIO.cxx itkMyImageIOFactory.cxx)<br />
<nowiki></nowiki><br />
#<br />
# Library for all of my image formats<br />
ADD_LIBRARY (MYIO ${MYIO_SRCS})<br />
TARGET_LINK_LIBRARIES(MYIO ITKIO)<br />
<nowiki></nowiki><br />
#<br />
# Shared library that when placed in ITK_AUTOLOAD_PATH, will add MyImageIO<br />
# as an ImageIOFactory. Need to have separate shared library for each new format.<br />
ADD_LIBRARY(MyPlugin SHARED itkMyPlugin.cxx)<br />
TARGET_LINK_LIBRARIES(MyPlugin MYIO)<br />
<br />
MyPlugin will be the shared library that adds support for the MyImageIO file format. The code associated with MyPlugin is<br />
<br />
itkMyPlugin.h<br />
#ifndef __itkMyPlugin_h<br />
#define __itkMyPlugin_h<br />
<nowiki></nowiki><br />
#include "itkObjectFactoryBase.h"<br />
<nowiki></nowiki><br />
#ifdef WIN32<br />
#ifdef MyPlugin_EXPORTS<br />
#define MyPlugin_EXPORT __declspec(dllexport)<br />
#else<br />
#define MyPlugin_EXPORT __declspec(dllimport)<br />
#endif<br />
#else<br />
#define MyPlugin_EXPORT <br />
#endif<br />
<nowiki></nowiki><br />
/**<br />
* Routine that is called when the shared library is loaded by<br />
* itk::ObjectFactoryBase::LoadDynamicFactories().<br />
*<br />
* itkLoad() is C (not C++) function.<br />
*/<br />
extern "C" {<br />
MyPlugin_EXPORT itk::ObjectFactoryBase* itkLoad();<br />
} <br />
#endif <br />
<br />
itkMyPlugin.cxx<br />
#include "itkMyPlugin.h"<br />
#include "itkMyImageIOFactory.h"<br />
<nowiki></nowiki><br />
/**<br />
* Routine that is called when the shared library is loaded by<br />
* itk::ObjectFactoryBase::LoadDynamicFactories().<br />
*<br />
* itkLoad() is C (not C++) function.<br />
*/<br />
itk::ObjectFactoryBase* itkLoad()<br />
{<br />
static itk::MyImageIOFactory::Pointer f = itk::MyImageIOFactory::New();<br />
return f;<br />
}<br />
<br />
== Discussion ==<br />
<br />
* It appears as though ObjectFactoryBase::LoadDynamicFactories() is called multiple times. Putting a print statement in the above itkLoad() method verifies this for a simple program of a single reader connected to a single writer.<br />
** <strike>There '''needs''' to be a mechanism to cause LoadDynamicFactories() to called multiple times if plugins can be added '''while an application is running.'''</strike><br />
** <strike>However, calling LoadDynamicFactories too often will be a performance issue.</strike><br />
** <strike>If LoadDynamicFactories() can be called multiple times, then the factory list must be managed for duplicates and the itkLoad() method probably needs additional memory management and synchronization.</strike><br />
* Implementing itkLoad() could be made simpler if itkLoad() could return a smart pointer to an ObjectFactoryBase instead of a raw pointer to an ObjectFactoryBase.<br />
<br />
=== Update ===<br />
<br />
'''LoadDynamicFactories is only called multiple times if ITK and the new IO format class are compiled static.''' Much of the following discussion may only be pertinent on Windows. The plugin defined above is always compiled shared. But if ITK and IO format class are compiled static, then they do not share the same ObjectFactory. Consider an ITK executable like the example ImageReadWrite. This example just has an ImageFileReader connected to an ImageFileWriter. When the reader is instantiated, the ObjectFactory triggers a call to LoadDynamicFactories(). This causes any plugins to be loaded. When the ImageFileReader needs to read the file, it asks the ObjectFactory for all factories that can create an ImageIOBase. This causes the plugin to instantiate an ImageIO subclass for the new file format. This instantiation is done in the shared library which has its own ObjectFactory since the new file format was compiled static. This ObjectFactory has yet to be initialized and LoadDynamicFactories() is called a second time. <br />
<br />
To use plugins properly, the ITK application must be using a shared build of ITK, the new IO format must be using a shared build of ITK, and of course the plugin itself must be built shared. Then, a single ObjectFactory will be used in the application and the plugin.<br />
<br />
If the application is built with a static build of ITK and the new IO format is built with a static build of ITK, then LoadDynamicFactories() will be called multiple times: once for the application and once for each plugin that instantiates an object. This may '''not''' actually cause a runtime issue other than causing the dynamic libraries to be loaded multiple times. Each plugin and the application will have their own ObjectFactory but they '''should all be configured identically'''.<br />
<br />
{{ITK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=Plugin_IO_mechanisms&diff=60890Plugin IO mechanisms2016-09-25T14:33:04Z<p>Dzenanz: /* Plugin mechanism */ misspell factor -> factory</p>
<hr />
<div>ITK provides a very flexible ImageIO mechanism supporting factories. This allows for a single reader class and a single writer class that can input/output a variety of file formats. When ImageFileReader begins to read a file, it queries the ObjectFactory system for any factory that can supply an ImageIOBase. This subset of factories is queried in turn to locate a factory that can understand the format of the requested file.<br />
<br />
New image file formats can be added to ITK by deriving a class from ImageIOBase that will support reading/writing the new file format. The file format can be added to the factory mechanism by creating a subclass of ObjectFactoryBase for this new ImageIO class. This subclass of ObjectFactoryBase will create an override in the factory mechanism indicating it can create an ImageIOBase. This is done in the constructor of the subclass of ObjectFactoryBase for the new image format:<br />
<br />
MyImageIOFactory::MyImageIOFactory()<br />
{<br />
this->RegisterOverride("itkImageIOBase",<br />
"itkMyImageIO",<br />
"My Image IO",<br />
1,<br />
CreateObjectFunction<MyImageIO>::New()); <br />
}<br />
<br />
== Registering a factory ==<br />
<br />
For the factory mechanism to use the factory for the new image format, the new factory must be "registered" with the factory mechanism. A stock set of such factories are registered automatically by ImageIOFactory. To register additional factories,<br />
<br />
* Add the new format format to the list of formats registered by default in ImageIOFactory::RegisterBuiltInFactories().<br />
** This is should only be done if the new format is to be widely adopted by the entire ITK community.<br />
* Register the factory in your application code that uses that factory<br />
** This is reasonable if you only need to use the file format in your own applications.<br />
<br />
ObjectFactoryBase::RegisterFactory( MyImageIOFactory::New() ); <br />
<br />
* Use the factory plugin mechanism to dynamically register the factory.<br />
** This is useful if you have existing ITK applications that you do not wish to recompile (or can recompile) but you would like them to be able to use your new file format.<br />
<br />
== Plugin mechanism ==<br />
<br />
ITK's object factory mechanism supports dynamically loading factories from shared libraries. This mechanism can be used to dynamically load factories for new image file formats. The object factory will look at the ITK_AUTOLOAD_PATH environment variable to locate dynamically loadable factories (plugins).<br />
<br />
export ITK_AUTOLOAD_PATH=/home/me/myplugins<br />
<br />
If the ITK_AUTOLOAD_PATH is set, each shared library in each directory in that path is examined for a "C" method (not a C++ method)<br />
<br />
ObjectFactoryBase* itkLoad()<br />
<br />
If the method itkLoad() is found in the shared library, it is called. itkLoad() must return a pointer to an ObjectFactoryBase. The object factory mechanism then calls ObjectFactoryBase::RegisteryFactory(), passing in the pointer returned by itkLoad(). <br />
<br />
To add a new image file format to an existing application, we can simply wrap the associated ImageIOFactory for the new format inside a shared object that provides the itkLoad() mechanism. Any precompiled ITK application will then be able to read and write this new format.<br />
<br />
=== Caveats ===<br />
<br />
The object factory mechanism will make sure that the dynamically loaded ImageIOFactory was built with the same version of ITK as the application. If they are not a warning will be presented. <br />
<br />
Possible imcompatible factory load.<br />
Running itk version : xx.xx.xx<br />
Loaded Factory versions: yy.yy.yy<br />
Loaded factory: /path/to/factory<br />
<br />
Factories dynamically loaded that were built with a different version of ITK than the application '''may be unstable'''.<br />
<br />
== Example ==<br />
<br />
To add the MyImageIOFactory as a dynamically loaded factory, we need to create a shared library with an itkLoad() method and place that shared library in the ITK_AUTOLOAD_PATH. Here is an example CMakeLists.txt file for creating the plugin shared library<br />
<br />
SET(MYIO_SRCS itkMyImageIO.cxx itkMyImageIOFactory.cxx)<br />
<nowiki></nowiki><br />
#<br />
# Library for all of my image formats<br />
ADD_LIBRARY (MYIO ${MYIO_SRCS})<br />
TARGET_LINK_LIBRARIES(MYIO ITKIO)<br />
<nowiki></nowiki><br />
#<br />
# Shared library that when placed in ITK_AUTOLOAD_PATH, will add MyImageIO<br />
# as an ImageIOFactory. Need to have separate shared library for each new format.<br />
ADD_LIBRARY(MyPlugin SHARED itkMyPlugin.cxx)<br />
TARGET_LINK_LIBRARIES(MyPlugin MYIO)<br />
<br />
MyPlugin will be the shared library that adds support for the MyImageIO file format. The code associated with MyPlugin is<br />
<br />
itkMyPlugin.h<br />
#ifndef __itkMyPlugin_h<br />
#define __itkMyPlugin_h<br />
<nowiki></nowiki><br />
#include "itkObjectFactoryBase.h"<br />
<nowiki></nowiki><br />
#ifdef WIN32<br />
#ifdef MyPlugin_EXPORTS<br />
#define MyPlugin_EXPORT __declspec(dllexport)<br />
#else<br />
#define MyPlugin_EXPORT __declspec(dllimport)<br />
#endif<br />
#else<br />
#define MyPlugin_EXPORT <br />
#endif<br />
<nowiki></nowiki><br />
/**<br />
* Routine that is called when the shared library is loaded by<br />
* itk::ObjectFactoryBase::LoadDynamicFactories().<br />
*<br />
* itkLoad() is C (not C++) function.<br />
*/<br />
extern "C" {<br />
MyPlugin_EXPORT itk::ObjectFactoryBase* itkLoad();<br />
} <br />
#endif <br />
<br />
itkMyPlugin.cxx<br />
#include "itkMyPlugin.h"<br />
#include "itkMyImageIOFactory.h"<br />
<nowiki></nowiki><br />
/**<br />
* Routine that is called when the shared library is loaded by<br />
* itk::ObjectFactoryBase::LoadDynamicFactories().<br />
*<br />
* itkLoad() is C (not C++) function.<br />
*/<br />
itk::ObjectFactoryBase* itkLoad()<br />
{<br />
static itk::MyImageIOFactory::Pointer f = itk::MyImageIOFactory::New();<br />
return f;<br />
}<br />
<br />
== Discussion ==<br />
<br />
* It appears as though ObjectFactoryBase::LoadDynamicFactories() is called multiple times. Putting a print statement in the above itkLoad() method verifies this for a simple program of a single reader connected to a single writer.<br />
** <strike>There '''needs''' to be a mechanism to cause LoadDynamicFactories() to called multiple times if plugins can be added '''while an application is running.'''</strike><br />
** <strike>However, calling LoadDynamicFactories too often will be a performance issue.</strike><br />
** <strike>If LoadDynamicFactories() can be called multiple times, then the factory list must be managed for duplicates and the itkLoad() method probably needs additional memory management and synchronization.</strike><br />
* Implementing itkLoad() could be made simpler if itkLoad() could return a smart pointer to an ObjectFactoryBase instead of a raw pointer to an ObjectFactoryBase.<br />
<br />
=== Update ===<br />
<br />
'''LoadDynamicFactories is only called multiple times if ITK and the new IO format class are compiled static.''' Much of the following discussion may only be pertinent on Windows. The plugin defined above is always compiled shared. But if ITK and IO format class are compiled static, then they do not share the same ObjectFactory. Consider an ITK executable like the example ImageReadWrite. This example just has an ImageFileReader connected to an ImageFileWriter. When the reader is instantiated, the ObjectFactory triggers a call to LoadDynamicFactories(). This causes any plugins to be loaded. When the ImageFileReader needs to read the file, it asks the ObjectFactory for all factories that can create an ImageIOBase. This causes the plugin to instantiate an ImageIO subclass for the new file format. This instantiation is done in the shared library which has its own ObjectFactory since the new file format was compiled static. This ObjectFactory has yet to be initialized and LoadDynamicFactories() is called a second time. <br />
<br />
To use plugins properly, the ITK application must be using a shared build of ITK, the new IO format must be using a shared build of ITK, and of course the plugin itself must be built shared. Then, a single ObjectFactory will be used in the application and the plugin.<br />
<br />
If the application is built with a static build of ITK and the new IO format is built with a static build of ITK, then LoadDynamicFactories() will be called multiple times: once for the application and once for each plugin that instantiates an object. This may '''not''' actually cause a runtime issue other than causing the dynamic libraries to be loaded multiple times. Each plugin and the application will have their own ObjectFactory but they '''should all be configured identically'''.<br />
<br />
{{ITK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/Utilities/FileOutputWindow&diff=60861ITK/Examples/Utilities/FileOutputWindow2016-09-15T19:23:37Z<p>Dzenanz: /* FileOutputWindow.cxx */ Works even with legacy disabled</p>
<hr />
<div>On linux systems, warning will be reported to the console. On windows system warnings will be reported in a popup. This example illustrates how to redirect warnings to a file.<br />
<br />
==FileOutputWindow.cxx==<br />
<source lang="cpp"><br />
#include <itkFileOutputWindow.h><br />
#include <itkScaleTransform.h><br />
<br />
int main(int argc, char* argv[])<br />
{<br />
typedef itk::FileOutputWindow myFileOutputWindow;<br />
myFileOutputWindow::Pointer window = myFileOutputWindow::New();<br />
<br />
if (argc > 1)<br />
{<br />
window->SetFileName(argv[1]);<br />
}<br />
window->FlushOn();<br />
<br />
// Set the singelton instance<br />
itk::OutputWindow::SetInstance(window);<br />
<br />
// Generic output<br />
itkGenericOutputMacro("This should be in the file: " << window->GetFileName());<br />
// Warning<br />
typedef itk::ScaleTransform<float,2> TransformType;<br />
TransformType::Pointer transform = TransformType::New();<br />
#if defined(ITK_FIXED_PARAMETERS_ARE_DOUBLE) || defined(ITK_LEGACY_REMOVE) // After 4.8.1<br />
TransformType::FixedParametersType parameters(3);<br />
#else //Pre 4.8.1<br />
TransformType::ParametersType parameters(3);<br />
#endif<br />
transform->SetFixedParameters(parameters);<br />
<br />
std::cout << "Look in " << window->GetFileName() << " for the output" << std::endl;<br />
return EXIT_SUCCESS;<br />
}<br />
</source><br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Examples/Meshes/AreaAndVolume&diff=60860ITK/Examples/Meshes/AreaAndVolume2016-09-15T17:22:15Z<p>Dzenanz: /* AreaAndVolume.cxx */ Visual Studio compile fix</p>
<hr />
<div>This example demonstrates how to calculate the area and volume of an itk::Mesh by (a) ensuring that it is triangular and (b) converting it to an itk::SimplexMesh.<br />
<br />
Contributed by: Davis Vigneault<br />
<br />
==AreaAndVolume.cxx==<br />
<br />
<source lang="cpp"><br />
<br />
#define _USE_MATH_DEFINES //needed for Visual Studio (before #include <cmath>)<br />
#include <itkSimplexMesh.h><br />
#include <itkRegularSphereMeshSource.h><br />
#include <itkTriangleMeshToSimplexMeshFilter.h><br />
#include <itkSimplexMeshVolumeCalculator.h><br />
<br />
typedef itk::Mesh< float, 3 > TMesh;<br />
typedef itk::SimplexMesh< float, 3 > TSimplex;<br />
typedef itk::RegularSphereMeshSource< TMesh > TSphere;<br />
typedef itk::TriangleMeshToSimplexMeshFilter< TMesh, TSimplex > TConvert;<br />
typedef itk::SimplexMeshVolumeCalculator< TSimplex > TVolume;<br />
<br />
int main(int, char *[])<br />
{<br />
<br />
// Create a spherical mesh with known radius and resolution.<br />
TSphere::Pointer source = TSphere::New();<br />
TSphere::VectorType scale;<br />
scale.Fill( 5.0 );<br />
source->SetScale( scale );<br />
source->SetResolution( 5 );<br />
source->Update();<br />
<br />
// Ensure that all cells of the mesh are triangles.<br />
for (TMesh::CellsContainerIterator it = source->GetOutput()->GetCells()->Begin();<br />
it != source->GetOutput()->GetCells()->End();<br />
++it)<br />
{ <br />
TMesh::CellAutoPointer cell;<br />
source->GetOutput()->GetCell(it->Index(), cell);<br />
if (3 != cell->GetNumberOfPoints())<br />
{ <br />
std::cerr << "ERROR: All cells must be trianglar." << std::endl; <br />
return EXIT_FAILURE;<br />
} <br />
} <br />
<br />
// Convert the triangle mesh to a simplex mesh.<br />
TConvert::Pointer convert = TConvert::New();<br />
convert->SetInput( source->GetOutput() );<br />
convert->Update();<br />
<br />
// Calculate the volume and area of the simplex mesh.<br />
TVolume::Pointer volume = TVolume::New();<br />
volume->SetSimplexMesh( convert->GetOutput() );<br />
volume->Compute();<br />
<br />
// Compare with the volume and area of an ideal sphere.<br />
std::cout << "Ideal Volume: " << 4.0/3.0*M_PI*pow(5.0,3) << std::endl;<br />
std::cout << "Mesh Volume: " << volume->GetVolume() << std::endl;<br />
std::cout << "Ideal Surface Area: " << 4.0*M_PI*pow(5.0,2) << std::endl;<br />
std::cout << "Mesh Surface Area: " << volume->GetArea() << std::endl;<br />
<br />
return EXIT_SUCCESS;<br />
<br />
}<br />
<br />
</source><br />
{{ITKCMakeLists|{{SUBPAGENAME}}}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=60853ITK Release 5/Wish List2016-09-13T13:34:53Z<p>Dzenanz: /* Image IO */ try->true</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Outstanding wishes ==<br />
A detailed wish list was put together by the community when preparing for ITK v4. Many of the wishes expressed there could not be fulfilled at the time but are still valid:<br />
* https://itk.org/Wiki/ITK_Release_4/Wish_List<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
** ''char'' and ''unsigned char'' would keep being defined as ''char'' and ''unsigned char'' as these types is wildly use image formats.<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially true for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
To take a step further, requiring the latest c++ standard (C++14? C++17?) available when starting a v5 endeavour could also be discussed.<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=60850ITK Release 5/Wish List2016-09-09T21:39:28Z<p>Dzenanz: VNL</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned char -> uint8_t<br />
** char -> int8_t<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially try for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.<br />
<br />
== VNL->Eigen ==<br />
Replace VNL by [http://eigen.tuxfamily.org/ Eigen], which is much more modern.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK_Release_5/Wish_List&diff=60849ITK Release 5/Wish List2016-09-09T21:36:51Z<p>Dzenanz: C++11</p>
<hr />
<div>The wish list is provided by members of the ITK development community.<br />
These requests will not necessarily be included in ITKv5.<br />
<br />
== Image IO ==<br />
* Replacing current integer pixel IO types defined in itk::ImageIOBase by fixed width integer types<br />
** unsigned char -> uint8_t<br />
** char -> int8_t<br />
** unsigned short -> uint16_t<br />
** short -> int16_t<br />
** unsigned int -> uint32_t<br />
** int -> int32_t<br />
** unsigned long -> uint64_t<br />
** long -> int64_t<br />
* Currently, the size of each type may vary from one platform to another.<br />
* This is especially try for 'long' that is 32 bits on Windows/Visual Studio C++ 2013 (64 bits) but 64 bits on 64 bits Unix systems. <br />
* Files saved on one platform should be read the same on a different platform.<br />
* This would avoid having to compare `sizeof(mytype)` to know what type to use on a specific platform.<br />
* This issue was raised in [http://review.source.kitware.com/#/c/21513/ this patch suggestion]<br />
<br />
== C++11 throughout ==<br />
As ITK uses templates heavily, it would greatly benefit from usage of few C++11 goodies, especially '''auto''' and '''decltype'''.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=60789ITK/Coding Style Guide2016-07-22T20:38:30Z<p>Dzenanz: /* Doxygen Documentation System */ Fixing broken link</p>
<hr />
<div>= C++ Code Style =<br />
<br />
The document located [[media:ITKStyle.pdf|HERE]] describes ITK coding conventions. Developers should follow these conventions when submitting contributions.<br />
<br />
ITK Style Guide<br />
Insight Software Consortium<br />
<br />
== Purpose ==<br />
<br />
The following document is a description of the accepted coding style for the NLM Insight Segmentation<br />
and Registration Toolkit (ITK). Developers who wish to contribute code to ITK should read<br />
and adhere to the standards described here.<br />
<br />
== Document Overview ==<br />
This document is organized into the following sections.<br />
<br />
* System Overview & Philosophy | coding methodologies and motivation for the resulting style.<br />
* Copyright | the copyright header to be included in all files and other copyright issues.<br />
* File organization | how to organize source code; a guide to the ITK directory structure.<br />
* Naming conventions | patterns used to name classes, variables, template parameters, and instance variables.<br />
* Namespaces | the use of namespaces.<br />
* Code Layout and Indentation | accepted standards for arranging code including indentation style.<br />
* Doxygen Documentation System | basic Doxygen formatting instructions.<br />
* Using Standard Macros (itkMacro.h) | use of standard macros in header files.<br />
* Exception Handling | how to add exception handling to the system.<br />
* Documentation Style | a brief section describing the documentation philosophy adopted by the Insight consortium.<br />
<br />
This style guide is an evolving document.<br />
<br />
Please dialog with the ITK developers if you wish to add, modify, or delete the rules described in these guidelines.<br />
<br />
See:<br />
<br />
http://www.itk.org/ITK/help/mailing.html<br />
<br />
for more information about joining the ITK developers mailing list. This forum is one of the best venues in which to propose changes to these style guidelines.<br />
<br />
== Style Guidelines ==<br />
<br />
The following coding-style guidelines have been adopted by the ITK community. To a large extent<br />
these guidelines are a result of the fundamental architectural and implementation decisions made<br />
early in the project. For example, the decision was made to implement ITK with a C++ core using<br />
principles of generic programming, so the rules are oriented towards this style of implementation.<br />
Some guidelines are relatively arbitrary, such as indentation levels and style. However, an attempt<br />
was made to find coding styles consistent with accepted practices. The point is to adhere to a<br />
common style to assist developers and users of the future learn, use, maintain, and extend ITK.<br />
(See the ITK Requirements document for more information.)<br />
Please do your best to be a upstanding member of the ITK community. The rules described here<br />
have been developed with the community as a whole in mind. If you consistently violate these rules<br />
you will likely be harassed mercilessly, first privately and then publicly. If this does not result in<br />
correct code layout, your right to CVS write access (if you are developer and wish to contribute<br />
code) may be removed. Similarly, if you wish to contribute code and are not a developer, your code<br />
will not be accepted until the style is consistent with these guidelines.<br />
<br />
=== System Overview & Philosophy ===<br />
The following implementation strategies have been adopted by the ITK community. These directly<br />
and indirectly affect the resulting code style. Understanding these strategies motivate the reasons<br />
for many of the style guidelines described in this document.<br />
<br />
==== Implementation Language ====<br />
<br />
The core implementation language is C++. C++ was chosen for its flexibility, performance, and<br />
familiarity to consortium members. (Auxiliary, interpreted language bindings such as Tcl, Python,<br />
and/or Java are also planned. These are aimply (run-time interpreted) layers on the C++ code.)<br />
ITK uses the full spectrum of C++ features including const and volatile correctness, namespaces,<br />
partial template specialization, operator overloading, traits, and iterators.<br />
<br />
==== Generic Programming and the STL ====<br />
<br />
Compile-time binding using methods of generic programming and template instantiation is the<br />
preferred implementation style. This approach has demonstrated its ability to create efficient,<br />
flexible code. Use of the STL (Standard Template Library) is encouraged. STL is typically used by<br />
a class, rather than as serving as a base class for derivation of ITK classes. Other STL influences<br />
are iterators and traits. ITK defines a large set of iterators; however, the ITK iterator style differs<br />
in many cases from STL because STL iterators follow a linear traversal model; ITK iterators are<br />
often designed for 2D, 3D, and even n-D traversal. Traits are used heavily be ITK. ITK naming<br />
conventions supersede STL naming conventions; this difference is useful in that it indicates to the<br />
developer something of the boundary between ITK and STL.<br />
<br />
==== Portability ====<br />
ITK is designed to compile on a set of target operating system/compiler combinations.<br />
<br />
These combinations include, but are not limited to:<br />
<br />
* Windows 9x/NT/2000/XP running<br />
** Microsoft Visual C++ version 7.1 to 10<br />
* Solaris with SunPro compiler <br />
* Linux running gcc<br />
* MacOSX running gcc<br />
* Intel compiler on Windows and Linux<br />
<br />
For a full list of the compilers supported please see:<br />
<br />
* [[ITK_Release_4/Modern C++|Modern C++]]<br />
<br />
==== Multi-Layer Architecture ====<br />
ITK is designed with a multi-layer architecture in mind. That is, three layers, a templated layer, a<br />
run-time layer, and an application layer. The templated (or generic) layer is written in C++ and<br />
requires significant programming skills and domain knowledge. The run-time layer is generated<br />
automatically using the CableSwig wrapping system to produce language bindings to Tcl, Python,<br />
and Java. The interpreted layer is easier to use than the templated layer, and can be used for<br />
prototyping and smaller-sized application development. Finally, the application layer is not directly<br />
addressed by ITK other than providing simple examples of applications.<br />
<br />
==== CMake Build Environment ====<br />
The ITK build environment is CMake. CMake is an open-source, advanced cross-platform build<br />
system that enables developers to write simple \makefiles" (named CMakeLists.txt) that are processed<br />
to generated native build tools for a particular operating system/compiler combinations.<br />
See the CMake web pages at http://www.cmake.org for more information.<br />
<br />
==== Doxygen Documentation System ====<br />
<br />
The Doxygen open-source system is used to generate on-line documentation. Doxygen requires the<br />
embedding of simple comments in the code which is in turn extracted and formatted into documentation.<br />
<br />
For more information about Doxygen, please see<br />
<br />
http://www.stack.nl/dimitri/doxygen/<br />
<br />
==== vnl Math Library ====<br />
ITK has adopted the vnl math library. Vnl is a portion of the vxl image understanding environment.<br />
See http://www.robots.ox.ac.uk/ vxl/ for more information about vxl and vnl.<br />
<br />
==== Reference Counting ====<br />
<br />
ITK has adopted reference counting via so-called "smart pointers" to manage object references.<br />
While alternative approaches such as automatic garbage collection were considered, their overhead<br />
due to memory requirements, performance, and lack of control as to when to delete memory, precluded<br />
these methods. Smart pointers manage the reference to objects, automatically incrementing<br />
and deleting an instance's reference count, deleting the object when the count goes to zero.<br />
These are the most important factors influencing the coding style found in Insight. Now we will<br />
look at the details.<br />
<br />
=== Copyright ===<br />
<br />
ITK has adopted a standard copyright. This copyright should be placed at the head of every source<br />
code file. The current copyright header and license reads as follows:<br />
<br />
<pre><nowiki><br />
/*========================================================================= <br />
* <br />
* Copyright Insight Software Consortium <br />
* <br />
* Licensed under the Apache License, Version 2.0 (the "License"); <br />
* you may not use this file except in compliance with the License. <br />
* You may obtain a copy of the License at <br />
* <br />
* http://www.apache.org/licenses/LICENSE-2.0.txt <br />
* <br />
* Unless required by applicable law or agreed to in writing, software <br />
* distributed under the License is distributed on an "AS IS" BASIS, <br />
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. <br />
* See the License for the specific language governing permissions and <br />
* limitations under the License. <br />
* <br />
*=========================================================================*/<br />
</nowiki></pre><br />
<br />
[[ITK Copyright Header|Copyright Header]]<br />
<br />
=== File Organization ===<br />
<br />
Classes are created and (usually) organized into a single class per file set. A file set consists of .h<br />
header file, .cxx implementation file, and/or a .hxx templated implementation file. Helper classes<br />
may also be defined in the file set, typically these are not visible to the system at large, or placed<br />
into a special namespace.<br />
<br />
Source files must be placed in the correct directory for logical consistency with the rest of the<br />
system, and to avoid cyclic dependencies. Currently the ITK source directory structure is found in<br />
ITK/Modules and consists of the following subdirectories:<br />
<br />
* Bridge<br />
* Core<br />
* External<br />
* Filtering<br />
* GPU<br />
* IO<br />
* Nonunit<br />
* Numerics<br />
* Registration<br />
* Segmentation<br />
* ThirdParty<br />
<br />
Each one of these directories represent a Group of Modules.<br />
<br />
Please discuss with the ITK Developers about the best Module to place your new code.<br />
<br />
For a full list of Modules, please see:<br />
<br />
http://www.itk.org/Doxygen/html/modules.html<br />
<br />
=== Naming Conventions ===<br />
<br />
In general, <br />
<br />
* Names are constructed by using case change to indicate separate words, as in TimeStamp<br />
(versus Time Stamp).<br />
* Underscores are not used.<br />
* Variable names are chosen carefully with the intention to convey the meaning behind the code.<br />
* Names are generally spelled out; use of abbreviations is discouraged. (Abbreviation are allowable when in common use, and should be in<br />
uppercase as in RGB.) While this does result in long names, it self-documents the code.<br />
* If you learn how to use name completion in your editor (e.g.,Vim, Emacs), this inconvenience can be minimized.<br />
<br />
Depending on whether the name is a<br />
<br />
* class<br />
* file<br />
* variable<br />
* or other name<br />
<br />
variations on this theme result as explained in the following subsections.<br />
<br />
==== Naming Classes ====<br />
<br />
* Classes are named beginning with a capital letter.<br />
* Classes are placed in the appropriate namespace, typically itk:: (see namespaces below).<br />
* Classes are named according to the following general rule:<br />
class name = <algorithm><input><concept><br />
* In this formula, the name of the algorithm or process (possibly with an associated adjective or<br />
adverb) comes first, followed by an input type (if the class is a filter), and completed by a concept<br />
name.<br />
* A concept is an informal classification describing what a class does. There are many<br />
concepts, here are a few of them.<br />
<br />
The more common or important concepts are underlined.<br />
<br />
* '''Accessor''' Access and convert between types.<br />
* '''Adaptor''' Provide access to a portion of a complex pixel type.<br />
* '''Boundary''' The boundary of a cell.<br />
* '''Calculator''' Compute information.<br />
* '''Classifier''' Classify a pixel.<br />
* '''Container''' A container of objects such as points or cells.<br />
* '''Estimator''' Estimate a value or condition.<br />
* '''Factory''' Object factories are used to create instances.<br />
* '''Filter''' A class that participates in the data processing pipeline. Filters typically take one or more inputs and produce one or more outputs.<br />
* '''Function''' Evaluate a function at a given position.<br />
* '''Identifier''' A unique id for accessing points, cells, or other entities.<br />
* '''Interface''' Classes that specify an abstract interface.<br />
* '''Interpolator''' Interpolate data values, for example at non-pixel values.<br />
* '''Iterator''' Traverse data in various ways (e.g., forward, backward, within a region, etc.)<br />
* '''Mapper''' Transform data from one form into another.<br />
* '''Metric''' Compute similarity between two objects.<br />
* '''Operator''' A class that applies a user-specified function to a region.<br />
* '''Optimizer''' A class that performs numerical optimization.<br />
* '''Pointer''' A smart pointer to an instance of a class. Almost all instance in ITK are referred to via smart pointers.<br />
* '''Reader''' A class that reads a single data object (e.g., image or mesh).<br />
* '''Reference''' A type that refers to another object.<br />
* '''Region''' A subset of a data object, such as an image region.<br />
* '''Source''' A filter that initiates the data processing pipeline such as a reader or a procedural data generator.<br />
* '''Threader''' A class that manages multi-threading.<br />
* '''Traits''' A collection of template parameters used to control the instantiation of other classes.<br />
* '''Transform''' Various types of transformations including affine, procedural, and so on.<br />
* '''Writer''' A filter that terminates the data processing pipeline by writing data to disk or to a communicationsport.<br />
<br />
<br />
The naming of classes is an art form; please review existing names to catch the spirit of the naming<br />
convention.<br />
<br />
Example names include:<br />
<br />
* ShrinkImageFilter<br />
* TriangleCell<br />
* ScalarImageRegionIterator<br />
* NeighborhoodIterator<br />
* MapContainer<br />
* DefaultImageTraits<br />
* BackwardDifferenceOperator<br />
<br />
==== Naming Files ====<br />
<br />
* Files should have the same name as the class, with an "itk" prepended.<br />
* Header files are named .h, while implementation files are named either .cxx or .hxx, depending on whether they are implementations of templated classes.<br />
** For example, the class itk::Image <br />
*** is declared in the file itkImage.h and<br />
*** is defined in the file itkImage.hxx (because Image is templated).<br />
** The class itk::Object<br />
*** is declared in the file itkObject.h<br />
*** and is defined in the file itkObject.cxx<br />
<br />
==== Naming Methods and Functions ====<br />
Global functions and class methods, either static or class members, are named beginning with<br />
a capital letter. The biggest challenge when naming methods and functions is to be consistent<br />
with existing names. For example, given the choice between ComputeBoundingBox() and<br />
CalculateBoundingBox() (CalcBoundingBox() is not allowed because it is not spelled out), the<br />
choice is ComputeBoundingBox() because \Compute" is used elsewhere in the system in similar<br />
settings (The concepts described previously should be used whenever possible).<br />
When referring to class methods in code, an explicit this-> pointer should be used, as in this->ComputeBoundingBox().<br />
The use of the explicit this-> pointer helps clarify exactly which method, and where it originates,<br />
is being invoked. Similarly the \::" global namespace should be used when referring to a global<br />
function.<br />
<br />
==== Naming Class Data Members ====<br />
<br />
Class data members are prepended with m as in m_Size. This clearly indicates the origin of data<br />
members, and differentiates them from all other variables.<br />
<br />
==== Naming Local Variables ====<br />
Local variables begin in lowercase. There is more <br />
flexibility in the naming of local variables; please<br />
remember that others will study, maintain, fix, and extend your code. Any bread crumbs that<br />
you can drop in the way of explanatory variable names and comments will go a long way towards<br />
helping other developers.<br />
<br />
==== Naming Template Parameters ====<br />
Template parameters follow the usual rules with naming except that they should start with either<br />
the capital letter T or V. Type parameters begin with the letter T while value template parameters<br />
begin with the letter V.<br />
<br />
* For tempalate parameters the use of "typename" is preferred over "class". Very early c++ compilers did not have a "typename" keyword, and "class" was repurposed for declaring template parameters. It was later discovered that this lead to ambiguity in some valid code constructs, and the "typename" key word was added. It is often agreed (http://blogs.msdn.com/b/slippman/archive/2004/08/11/212768.aspx) that "typename" is marginally more expressive in it's intent and ITK should consistently use "typename" instead of "class".<br />
<br />
==== Naming Typedefs ====<br />
Typedefs are absolutely essential in generic programming. They significantly improve the readibility<br />
of code, and facilitate the declaration of complex syntactic combinations. Unfortunately, creation<br />
of typedefs is tantamount to creating another programming language. Hence typedefs must be used<br />
in a consistent fashion.<br />
The general rule for typedef names is that they end in the word Type. For example<br />
typedef TPixel PixelType;<br />
However, there are many exceptions to this rule that recognize that ITK has several important<br />
concepts that are expressed partially in the names used to implement the concept. An iterator is a<br />
concept, as is a container or pointer. These concepts are used in preference to Type at the end of<br />
a typedef as appropriate. For example<br />
<source lang="cpp"><br />
typedef typename ImageTraits::PixelContainer PixelContainer;<br />
</source><br />
Here Container is a concept used in place of Type.<br />
ITK currently identifies the following concepts used when naming typedefs.<br />
* Self as in typedef Image Self;. All classes should define this typedef.<br />
* Superclass as in typedef ImageBase<VImageDimension> Superclass;. All classes should define the Superclass typedef.<br />
* Pointer as in a smart pointer to an object as in typedef SmartPointer<Self> Pointer;<br />
* Container is a type of container class.<br />
* Iterator an iterator over some container class.<br />
* Identifier or id such as a point or cell id.<br />
<br />
==== Using Underscores ====<br />
Don't use them. The only exception is when defining preprocessor variables and macros (which are<br />
discouraged). In this case, underscores are allowed to separate words.<br />
<br />
==== Preprocessor Directives ====<br />
<br />
* Some of the worst code contains many preprocessor directives and macros. Do not use them except in a very limited sense (to support minor differences in compilers or operating systems). <br />
* If a class makes extensive use of preprocessor directives, it is a candidate for separation into multiple sub-classes.<br />
<br />
==== Header Includes ====<br />
<br />
Header includes use the style<br />
<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
</source><br />
<br />
Only the required headers should be included. If an included header already includes a header for a class also used in the current file, the header for that class should not be included.<br />
<br />
Header includes are preferred over forward declarations. Forward declarations are only used to prevent circular dependencies.<br />
<br />
==== Namespaces ====<br />
<br />
All classes should be placed in the itk:: namespace. Additional sub-namespaces are being designed to support special functionality.<br />
<br />
Please see current documentation to determine if there is a subnamespace is relevant to your situation. Normally sub-namespaces are used for helper ITK classes.<br />
<br />
Code should not use ''using namespace''. This is to avoid namespace conflicts, but, more importantly, to improve readability.<br />
<br />
When declaring or defining members of the "itk" namespace, for example, the 'itk::' namespace prefix should not be added. That is, code within "namespace itk { ... }" should not used "itk::".<br />
<br />
==== Const Correctness ====<br />
<br />
Const correctness is important. Please use it as appropriate to your class or method.<br />
<br />
==== Code Layout and Indentation ====<br />
<br />
The following are the accepted ITK code layout rules and indentation style. After reading this section, you may wish to visit many of the source files found in ITK. This will help crystallize the rules described here.<br />
<br />
==== General Layout ====<br />
<br />
* Each line of code should take no more than 200 characters.<br />
* Break the code across multiple lines as necessary.<br />
* Use lots of whitespace to separate logical blocks of code, intermixed with comments.<br />
* To a large extent the structure of code directly expresses its implementation.<br />
* The appropriate indentation level is '''two spaces''' for each level of indentation.<br />
* '''DO NOT USE TABS.'''<br />
** Set up your editor to insert spaces. Using tabs may look good in your editor but will wreak havoc in others.<br />
* The declaration of variables within classes, methods, and functions should be one declaration per line.<br />
<br />
<source lang="cpp"><br />
int i;<br />
int j;<br />
char* stringname;<br />
</source><br />
<br />
==== Class Layout ====<br />
<br />
Classes are defined using the following guidelines.<br />
* Begin with #include guards.<br />
* Follow with the necessary includes. Include only what is necessary to avoid dependency problems.<br />
* Place the class in the correct namespace.<br />
* Public methods come first.<br />
* Protected methods follow.<br />
* Private members come last.<br />
* Public data members are ''forbidden''.<br />
* Templated classes require a special preprocessor directive to control the manual instantiation of templates. See the example below and look for ITK MANUAL INSTANTIATION.<br />
The class layout looks something like this:<br />
<br />
<source lang="cpp"><br />
#ifndef itkImage_h<br />
#define itkImage_h<br />
<br />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
<br />
namespace itk<br />
{<br />
<br />
/** \class Image<br />
* \brief Templated n-dimensional image class.<br />
*<br />
* .... detailed documentation....<br />
*/<br />
template< typename TPixel, unsigned int VImageDimension=2,<br />
typename TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class Image: public ImageBase< VImageDimension ><br />
{<br />
public:<br />
//....stuff...<br />
protected:<br />
//....stuff...<br />
private:<br />
//....stuff...<br />
};<br />
<br />
} // end namespace itk<br />
<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
<br />
#endif<br />
</source><br />
<br />
==== Method Definition ====<br />
<br />
* Methods are defined across multiple lines. This is to accommodate the extremely long definitions possible when using templates.<br />
* The starting and ending brace should be in column one. For example:<br />
<br />
<source lang="cpp"><br />
template<typename TPixel, unsigned int VImageDimension, typename TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
//...stuff...<br />
}<br />
</source><br />
<br />
* The first line is the template declaration.<br />
* The second line is the method return type.<br />
* The third line is the class qualifier.<br />
* And the fourth line in the example above is the name of the method.<br />
<br />
=== Use of Braces ===<br />
<br />
* Braces must be used to delimit the scope of an if, for, while, switch, or other control structure.<br />
* Braces are placed on a line by themselves:<br />
<br />
<source lang="cpp"><br />
for( unsigned int ii = 0; ii < 3; ++ii )<br />
{<br />
...<br />
}<br />
</source><br />
<br />
<br />
or when using an if:<br />
<br />
<source lang="cpp"><br />
if( condition )<br />
{<br />
...<br />
}<br />
else if( other condition )<br />
{<br />
...<br />
}<br />
else<br />
{<br />
....<br />
}<br />
</source><br />
<br />
<br />
==== Indentation Inside Braces ====<br />
<br />
<br />
Source code in the body of the brackets must be aligned along with the brackets. As in<br />
<br />
<source lang="cpp"><br />
if ( condition )<br />
{<br />
unsigned int numberOfIterations = 100;<br />
filter->SetNumberOfIterations( numberOfIterations );<br />
filter->Update();<br />
filter->Print( std::cout );<br />
}<br />
</source><br />
<br />
=== Doxygen Documentation System ===<br />
<br />
* Doxygen is an open-source, powerful system for automatically generating documentation from source code.<br />
* To use Doxygen effectively, the developer must insert comments, delimited in a special way, that Doxygen extracts to produce the documentation. While there are a large number of options to Doxygen, developers at a minimum should insert the following Doxygen commands.<br />
<br />
See more at<br />
<br />
https://www.stack.nl/~dimitri/doxygen/manual/index.html<br />
<br />
==== Documenting a Class ====<br />
<br />
* Classes should be documented using the '''class''' and '''brief''' Doxygen commands, followed by the detailed class description:<br />
<br />
<source lang="cpp"><br />
/** \class Object<br />
* \brief Base class for most itk classes.<br />
*<br />
* Object is the second-highest level base class for most itk objects.<br />
* It extends the base object functionality of LightObject by<br />
* implementing debug flags/methods and modification time tracking.<br />
*/<br />
</source><br />
<br />
==== Documenting a Method ====<br />
<br />
* Methods should be documented using the following comment block style as shown in the following example. Make sure you use correct English and complete, grammatically correct sentences. Finish your sentences with a period (.).<br />
<br />
<source lang="cpp"><br />
/** Access a pixel at a particular index location.<br />
* This version can be an lvalue. */<br />
TPixel & operator[](const IndexType &index)<br />
{ return this->GetPixel(index); }<br />
</source><br />
<br />
The key here is that the comment starts with /**, each subsequent line has an aligned *, and the comment block terminates with a */.<br />
<br />
* Method documentation should be placed in the '''declaration files''' (*.h): the documentation in the implementation causes ambiguity for Doxygen on which documentation to use, the declaration or definition.<br />
** If there is something that is appropriate for the definition only (*.cxx or *.hxx), it should be placed '''inside the method''', and it could use either the /* */ or the // style comment, but it should not use /** */, which is for Doxygen comments.<br />
<br />
==== Documenting ivars ====<br />
<br />
* Class member variables should be documented using the following comment block style as shown in the following example. Make sure you use correct English and grammatically correct sentences. Finish the documentation line with a period (.).<br />
<br />
<source lang="cpp"><br />
// Standard deviation of the Gaussian used for smoothing.<br />
SigmaArrayType m_Sigma;<br />
</source><br />
<br />
=== Using Standard Macros (itkMacro.h) ===<br />
<br />
* There are several macros defined in the file itkMacro.h.<br />
* These macros should be used because they perform several important operations, that if not done correctly can cause serious, hard to debug problems in the system.<br />
** These operations are:<br />
*** Object modified time is properly managed.<br />
*** Debug information is printed.<br />
*** Reference counting is handled properly.<br />
<br />
Some of the more important object macros are as follows.<br />
<br />
* itkNewMacro(T) Creates the static class method New(void) that interacts with the object factory to instantiate objects. The method returns a SmartPointer<T> properly reference counted.<br />
* itkDebugMacro(x) If debug is set on a subclass of itk::Object, prints debug information to the appropriate output stream.<br />
* itkSetMacro(name,type) Creates a method SetName() that takes argument type type.<br />
* itkGetMacro(name,type) Creates a method GetName() that returns a non-const value of type type.<br />
* itkGetConstMacro(name,type) Creates a method GetName() that returns a const value of type type.<br />
* itkSetStringMacro(name) Creates a method SetName() that takes argument type const char*.<br />
* itkGetStringMacro(name) Creates a method GetName() that returns argument type const char*.<br />
* itkBooleanMacro(name) Creates two methods named NameOn and NameOff that sets true/false boolean values.<br />
* itkSetObjectMacro(name,type) Creates a method SetName() that takes argument type type *.<br />
* itkGetObjectMacro(name,type) Creates a method named GetName() that returns a smart pointer to a type type.<br />
* itkSetConstObjectMacro(name,type) Creates a method SetName() that takes argument type const type *.<br />
* itkGetConstObjectMacro(name,type) Creates a method named GetName() that returns a const smart pointer to a type type.<br />
<br />
Please review this file and become familiar with these macros.<br />
<br />
=== Exception Handling ===<br />
<br />
Indicate that methods throw exceptions in the method declaration as in:<br />
<br />
<source lang="cpp"><br />
const float* foo() const throws itk<br />
</source><br />
<br />
=== Documentation Style ===<br />
<br />
The Insight consortium has adopted the following guidelines for producing supplemental documentation (documentation not produced by Doxygen).<br />
<br />
* The common denominator for documentation is either PDF or HTML. All documents in the system should be available in these formats, even if they are mastered by another system.<br />
* Presentations are acceptable in Microsoft PowerPoint format.<br />
* Administrative and planning documents are acceptable in Microsoft Word format (either .doc or .rtf).<br />
* Larger documents, such as the user's or developer's guide, are written in LATEX.<br />
<br />
== CMake Style ==<br />
<br />
A proposal style guide for CMake variables is presented [[ITK_CMake_Style|HERE]].<br />
<br />
{{ITK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Coding_Style_Guide&diff=60788ITK/Coding Style Guide2016-07-22T20:10:25Z<p>Dzenanz: /* Naming Typedefs */ Fixing copy-paste error</p>
<hr />
<div>= C++ Code Style =<br />
<br />
The document located [[media:ITKStyle.pdf|HERE]] describes ITK coding conventions. Developers should follow these conventions when submitting contributions.<br />
<br />
ITK Style Guide<br />
Insight Software Consortium<br />
<br />
== Purpose ==<br />
<br />
The following document is a description of the accepted coding style for the NLM Insight Segmentation<br />
and Registration Toolkit (ITK). Developers who wish to contribute code to ITK should read<br />
and adhere to the standards described here.<br />
<br />
== Document Overview ==<br />
This document is organized into the following sections.<br />
<br />
* System Overview & Philosophy | coding methodologies and motivation for the resulting style.<br />
* Copyright | the copyright header to be included in all files and other copyright issues.<br />
* File organization | how to organize source code; a guide to the ITK directory structure.<br />
* Naming conventions | patterns used to name classes, variables, template parameters, and instance variables.<br />
* Namespaces | the use of namespaces.<br />
* Code Layout and Indentation | accepted standards for arranging code including indentation style.<br />
* Doxygen Documentation System | basic Doxygen formatting instructions.<br />
* Using Standard Macros (itkMacro.h) | use of standard macros in header files.<br />
* Exception Handling | how to add exception handling to the system.<br />
* Documentation Style | a brief section describing the documentation philosophy adopted by the Insight consortium.<br />
<br />
This style guide is an evolving document.<br />
<br />
Please dialog with the ITK developers if you wish to add, modify, or delete the rules described in these guidelines.<br />
<br />
See:<br />
<br />
http://www.itk.org/ITK/help/mailing.html<br />
<br />
for more information about joining the ITK developers mailing list. This forum is one of the best venues in which to propose changes to these style guidelines.<br />
<br />
== Style Guidelines ==<br />
<br />
The following coding-style guidelines have been adopted by the ITK community. To a large extent<br />
these guidelines are a result of the fundamental architectural and implementation decisions made<br />
early in the project. For example, the decision was made to implement ITK with a C++ core using<br />
principles of generic programming, so the rules are oriented towards this style of implementation.<br />
Some guidelines are relatively arbitrary, such as indentation levels and style. However, an attempt<br />
was made to find coding styles consistent with accepted practices. The point is to adhere to a<br />
common style to assist developers and users of the future learn, use, maintain, and extend ITK.<br />
(See the ITK Requirements document for more information.)<br />
Please do your best to be a upstanding member of the ITK community. The rules described here<br />
have been developed with the community as a whole in mind. If you consistently violate these rules<br />
you will likely be harassed mercilessly, first privately and then publicly. If this does not result in<br />
correct code layout, your right to CVS write access (if you are developer and wish to contribute<br />
code) may be removed. Similarly, if you wish to contribute code and are not a developer, your code<br />
will not be accepted until the style is consistent with these guidelines.<br />
<br />
=== System Overview & Philosophy ===<br />
The following implementation strategies have been adopted by the ITK community. These directly<br />
and indirectly affect the resulting code style. Understanding these strategies motivate the reasons<br />
for many of the style guidelines described in this document.<br />
<br />
==== Implementation Language ====<br />
<br />
The core implementation language is C++. C++ was chosen for its flexibility, performance, and<br />
familiarity to consortium members. (Auxiliary, interpreted language bindings such as Tcl, Python,<br />
and/or Java are also planned. These are aimply (run-time interpreted) layers on the C++ code.)<br />
ITK uses the full spectrum of C++ features including const and volatile correctness, namespaces,<br />
partial template specialization, operator overloading, traits, and iterators.<br />
<br />
==== Generic Programming and the STL ====<br />
<br />
Compile-time binding using methods of generic programming and template instantiation is the<br />
preferred implementation style. This approach has demonstrated its ability to create efficient,<br />
flexible code. Use of the STL (Standard Template Library) is encouraged. STL is typically used by<br />
a class, rather than as serving as a base class for derivation of ITK classes. Other STL influences<br />
are iterators and traits. ITK defines a large set of iterators; however, the ITK iterator style differs<br />
in many cases from STL because STL iterators follow a linear traversal model; ITK iterators are<br />
often designed for 2D, 3D, and even n-D traversal. Traits are used heavily be ITK. ITK naming<br />
conventions supersede STL naming conventions; this difference is useful in that it indicates to the<br />
developer something of the boundary between ITK and STL.<br />
<br />
==== Portability ====<br />
ITK is designed to compile on a set of target operating system/compiler combinations.<br />
<br />
These combinations include, but are not limited to:<br />
<br />
* Windows 9x/NT/2000/XP running<br />
** Microsoft Visual C++ version 7.1 to 10<br />
* Solaris with SunPro compiler <br />
* Linux running gcc<br />
* MacOSX running gcc<br />
* Intel compiler on Windows and Linux<br />
<br />
For a full list of the compilers supported please see:<br />
<br />
* [[ITK_Release_4/Modern C++|Modern C++]]<br />
<br />
==== Multi-Layer Architecture ====<br />
ITK is designed with a multi-layer architecture in mind. That is, three layers, a templated layer, a<br />
run-time layer, and an application layer. The templated (or generic) layer is written in C++ and<br />
requires significant programming skills and domain knowledge. The run-time layer is generated<br />
automatically using the CableSwig wrapping system to produce language bindings to Tcl, Python,<br />
and Java. The interpreted layer is easier to use than the templated layer, and can be used for<br />
prototyping and smaller-sized application development. Finally, the application layer is not directly<br />
addressed by ITK other than providing simple examples of applications.<br />
<br />
==== CMake Build Environment ====<br />
The ITK build environment is CMake. CMake is an open-source, advanced cross-platform build<br />
system that enables developers to write simple \makefiles" (named CMakeLists.txt) that are processed<br />
to generated native build tools for a particular operating system/compiler combinations.<br />
See the CMake web pages at http://www.cmake.org for more information.<br />
<br />
==== Doxygen Documentation System ====<br />
<br />
The Doxygen open-source system is used to generate on-line documentation. Doxygen requires the<br />
embedding of simple comments in the code which is in turn extracted and formatted into documentation.<br />
<br />
For more information about Doxygen, please see<br />
<br />
http://www.stack.nl/dimitri/doxygen/<br />
<br />
==== vnl Math Library ====<br />
ITK has adopted the vnl math library. Vnl is a portion of the vxl image understanding environment.<br />
See http://www.robots.ox.ac.uk/ vxl/ for more information about vxl and vnl.<br />
<br />
==== Reference Counting ====<br />
<br />
ITK has adopted reference counting via so-called "smart pointers" to manage object references.<br />
While alternative approaches such as automatic garbage collection were considered, their overhead<br />
due to memory requirements, performance, and lack of control as to when to delete memory, precluded<br />
these methods. Smart pointers manage the reference to objects, automatically incrementing<br />
and deleting an instance's reference count, deleting the object when the count goes to zero.<br />
These are the most important factors influencing the coding style found in Insight. Now we will<br />
look at the details.<br />
<br />
=== Copyright ===<br />
<br />
ITK has adopted a standard copyright. This copyright should be placed at the head of every source<br />
code file. The current copyright header and license reads as follows:<br />
<br />
<pre><nowiki><br />
/*========================================================================= <br />
* <br />
* Copyright Insight Software Consortium <br />
* <br />
* Licensed under the Apache License, Version 2.0 (the "License"); <br />
* you may not use this file except in compliance with the License. <br />
* You may obtain a copy of the License at <br />
* <br />
* http://www.apache.org/licenses/LICENSE-2.0.txt <br />
* <br />
* Unless required by applicable law or agreed to in writing, software <br />
* distributed under the License is distributed on an "AS IS" BASIS, <br />
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. <br />
* See the License for the specific language governing permissions and <br />
* limitations under the License. <br />
* <br />
*=========================================================================*/<br />
</nowiki></pre><br />
<br />
[[ITK Copyright Header|Copyright Header]]<br />
<br />
=== File Organization ===<br />
<br />
Classes are created and (usually) organized into a single class per file set. A file set consists of .h<br />
header file, .cxx implementation file, and/or a .hxx templated implementation file. Helper classes<br />
may also be defined in the file set, typically these are not visible to the system at large, or placed<br />
into a special namespace.<br />
<br />
Source files must be placed in the correct directory for logical consistency with the rest of the<br />
system, and to avoid cyclic dependencies. Currently the ITK source directory structure is found in<br />
ITK/Modules and consists of the following subdirectories:<br />
<br />
* Bridge<br />
* Core<br />
* External<br />
* Filtering<br />
* GPU<br />
* IO<br />
* Nonunit<br />
* Numerics<br />
* Registration<br />
* Segmentation<br />
* ThirdParty<br />
<br />
Each one of these directories represent a Group of Modules.<br />
<br />
Please discuss with the ITK Developers about the best Module to place your new code.<br />
<br />
For a full list of Modules, please see:<br />
<br />
http://www.itk.org/Doxygen/html/modules.html<br />
<br />
=== Naming Conventions ===<br />
<br />
In general, <br />
<br />
* Names are constructed by using case change to indicate separate words, as in TimeStamp<br />
(versus Time Stamp).<br />
* Underscores are not used.<br />
* Variable names are chosen carefully with the intention to convey the meaning behind the code.<br />
* Names are generally spelled out; use of abbreviations is discouraged. (Abbreviation are allowable when in common use, and should be in<br />
uppercase as in RGB.) While this does result in long names, it self-documents the code.<br />
* If you learn how to use name completion in your editor (e.g.,Vim, Emacs), this inconvenience can be minimized.<br />
<br />
Depending on whether the name is a<br />
<br />
* class<br />
* file<br />
* variable<br />
* or other name<br />
<br />
variations on this theme result as explained in the following subsections.<br />
<br />
==== Naming Classes ====<br />
<br />
* Classes are named beginning with a capital letter.<br />
* Classes are placed in the appropriate namespace, typically itk:: (see namespaces below).<br />
* Classes are named according to the following general rule:<br />
class name = <algorithm><input><concept><br />
* In this formula, the name of the algorithm or process (possibly with an associated adjective or<br />
adverb) comes first, followed by an input type (if the class is a filter), and completed by a concept<br />
name.<br />
* A concept is an informal classification describing what a class does. There are many<br />
concepts, here are a few of them.<br />
<br />
The more common or important concepts are underlined.<br />
<br />
* '''Accessor''' Access and convert between types.<br />
* '''Adaptor''' Provide access to a portion of a complex pixel type.<br />
* '''Boundary''' The boundary of a cell.<br />
* '''Calculator''' Compute information.<br />
* '''Classifier''' Classify a pixel.<br />
* '''Container''' A container of objects such as points or cells.<br />
* '''Estimator''' Estimate a value or condition.<br />
* '''Factory''' Object factories are used to create instances.<br />
* '''Filter''' A class that participates in the data processing pipeline. Filters typically take one or more inputs and produce one or more outputs.<br />
* '''Function''' Evaluate a function at a given position.<br />
* '''Identifier''' A unique id for accessing points, cells, or other entities.<br />
* '''Interface''' Classes that specify an abstract interface.<br />
* '''Interpolator''' Interpolate data values, for example at non-pixel values.<br />
* '''Iterator''' Traverse data in various ways (e.g., forward, backward, within a region, etc.)<br />
* '''Mapper''' Transform data from one form into another.<br />
* '''Metric''' Compute similarity between two objects.<br />
* '''Operator''' A class that applies a user-specified function to a region.<br />
* '''Optimizer''' A class that performs numerical optimization.<br />
* '''Pointer''' A smart pointer to an instance of a class. Almost all instance in ITK are referred to via smart pointers.<br />
* '''Reader''' A class that reads a single data object (e.g., image or mesh).<br />
* '''Reference''' A type that refers to another object.<br />
* '''Region''' A subset of a data object, such as an image region.<br />
* '''Source''' A filter that initiates the data processing pipeline such as a reader or a procedural data generator.<br />
* '''Threader''' A class that manages multi-threading.<br />
* '''Traits''' A collection of template parameters used to control the instantiation of other classes.<br />
* '''Transform''' Various types of transformations including affine, procedural, and so on.<br />
* '''Writer''' A filter that terminates the data processing pipeline by writing data to disk or to a communicationsport.<br />
<br />
<br />
The naming of classes is an art form; please review existing names to catch the spirit of the naming<br />
convention.<br />
<br />
Example names include:<br />
<br />
* ShrinkImageFilter<br />
* TriangleCell<br />
* ScalarImageRegionIterator<br />
* NeighborhoodIterator<br />
* MapContainer<br />
* DefaultImageTraits<br />
* BackwardDifferenceOperator<br />
<br />
==== Naming Files ====<br />
<br />
* Files should have the same name as the class, with an "itk" prepended.<br />
* Header files are named .h, while implementation files are named either .cxx or .hxx, depending on whether they are implementations of templated classes.<br />
** For example, the class itk::Image <br />
*** is declared in the file itkImage.h and<br />
*** is defined in the file itkImage.hxx (because Image is templated).<br />
** The class itk::Object<br />
*** is declared in the file itkObject.h<br />
*** and is defined in the file itkObject.cxx<br />
<br />
==== Naming Methods and Functions ====<br />
Global functions and class methods, either static or class members, are named beginning with<br />
a capital letter. The biggest challenge when naming methods and functions is to be consistent<br />
with existing names. For example, given the choice between ComputeBoundingBox() and<br />
CalculateBoundingBox() (CalcBoundingBox() is not allowed because it is not spelled out), the<br />
choice is ComputeBoundingBox() because \Compute" is used elsewhere in the system in similar<br />
settings (The concepts described previously should be used whenever possible).<br />
When referring to class methods in code, an explicit this-> pointer should be used, as in this->ComputeBoundingBox().<br />
The use of the explicit this-> pointer helps clarify exactly which method, and where it originates,<br />
is being invoked. Similarly the \::" global namespace should be used when referring to a global<br />
function.<br />
<br />
==== Naming Class Data Members ====<br />
<br />
Class data members are prepended with m as in m_Size. This clearly indicates the origin of data<br />
members, and differentiates them from all other variables.<br />
<br />
==== Naming Local Variables ====<br />
Local variables begin in lowercase. There is more <br />
flexibility in the naming of local variables; please<br />
remember that others will study, maintain, fix, and extend your code. Any bread crumbs that<br />
you can drop in the way of explanatory variable names and comments will go a long way towards<br />
helping other developers.<br />
<br />
==== Naming Template Parameters ====<br />
Template parameters follow the usual rules with naming except that they should start with either<br />
the capital letter T or V. Type parameters begin with the letter T while value template parameters<br />
begin with the letter V.<br />
<br />
* For tempalate parameters the use of "typename" is preferred over "class". Very early c++ compilers did not have a "typename" keyword, and "class" was repurposed for declaring template parameters. It was later discovered that this lead to ambiguity in some valid code constructs, and the "typename" key word was added. It is often agreed (http://blogs.msdn.com/b/slippman/archive/2004/08/11/212768.aspx) that "typename" is marginally more expressive in it's intent and ITK should consistently use "typename" instead of "class".<br />
<br />
==== Naming Typedefs ====<br />
Typedefs are absolutely essential in generic programming. They significantly improve the readibility<br />
of code, and facilitate the declaration of complex syntactic combinations. Unfortunately, creation<br />
of typedefs is tantamount to creating another programming language. Hence typedefs must be used<br />
in a consistent fashion.<br />
The general rule for typedef names is that they end in the word Type. For example<br />
typedef TPixel PixelType;<br />
However, there are many exceptions to this rule that recognize that ITK has several important<br />
concepts that are expressed partially in the names used to implement the concept. An iterator is a<br />
concept, as is a container or pointer. These concepts are used in preference to Type at the end of<br />
a typedef as appropriate. For example<br />
<source lang="cpp"><br />
typedef typename ImageTraits::PixelContainer PixelContainer;<br />
</source><br />
Here Container is a concept used in place of Type.<br />
ITK currently identifies the following concepts used when naming typedefs.<br />
* Self as in typedef Image Self;. All classes should define this typedef.<br />
* Superclass as in typedef ImageBase<VImageDimension> Superclass;. All classes should define the Superclass typedef.<br />
* Pointer as in a smart pointer to an object as in typedef SmartPointer<Self> Pointer;<br />
* Container is a type of container class.<br />
* Iterator an iterator over some container class.<br />
* Identifier or id such as a point or cell id.<br />
<br />
==== Using Underscores ====<br />
Don't use them. The only exception is when defining preprocessor variables and macros (which are<br />
discouraged). In this case, underscores are allowed to separate words.<br />
<br />
==== Preprocessor Directives ====<br />
<br />
* Some of the worst code contains many preprocessor directives and macros. Do not use them except in a very limited sense (to support minor differences in compilers or operating systems). <br />
* If a class makes extensive use of preprocessor directives, it is a candidate for separation into multiple sub-classes.<br />
<br />
==== Header Includes ====<br />
<br />
Header includes use the style<br />
<br />
<source lang="cpp"><br />
#include "itkImage.h"<br />
</source><br />
<br />
Only the required headers should be included. If an included header already includes a header for a class also used in the current file, the header for that class should not be included.<br />
<br />
Header includes are preferred over forward declarations. Forward declarations are only used to prevent circular dependencies.<br />
<br />
==== Namespaces ====<br />
<br />
All classes should be placed in the itk:: namespace. Additional sub-namespaces are being designed to support special functionality.<br />
<br />
Please see current documentation to determine if there is a subnamespace is relevant to your situation. Normally sub-namespaces are used for helper ITK classes.<br />
<br />
Code should not use ''using namespace''. This is to avoid namespace conflicts, but, more importantly, to improve readability.<br />
<br />
When declaring or defining members of the "itk" namespace, for example, the 'itk::' namespace prefix should not be added. That is, code within "namespace itk { ... }" should not used "itk::".<br />
<br />
==== Const Correctness ====<br />
<br />
Const correctness is important. Please use it as appropriate to your class or method.<br />
<br />
==== Code Layout and Indentation ====<br />
<br />
The following are the accepted ITK code layout rules and indentation style. After reading this section, you may wish to visit many of the source files found in ITK. This will help crystallize the rules described here.<br />
<br />
==== General Layout ====<br />
<br />
* Each line of code should take no more than 200 characters.<br />
* Break the code across multiple lines as necessary.<br />
* Use lots of whitespace to separate logical blocks of code, intermixed with comments.<br />
* To a large extent the structure of code directly expresses its implementation.<br />
* The appropriate indentation level is '''two spaces''' for each level of indentation.<br />
* '''DO NOT USE TABS.'''<br />
** Set up your editor to insert spaces. Using tabs may look good in your editor but will wreak havoc in others.<br />
* The declaration of variables within classes, methods, and functions should be one declaration per line.<br />
<br />
<source lang="cpp"><br />
int i;<br />
int j;<br />
char* stringname;<br />
</source><br />
<br />
==== Class Layout ====<br />
<br />
Classes are defined using the following guidelines.<br />
* Begin with #include guards.<br />
* Follow with the necessary includes. Include only what is necessary to avoid dependency problems.<br />
* Place the class in the correct namespace.<br />
* Public methods come first.<br />
* Protected methods follow.<br />
* Private members come last.<br />
* Public data members are ''forbidden''.<br />
* Templated classes require a special preprocessor directive to control the manual instantiation of templates. See the example below and look for ITK MANUAL INSTANTIATION.<br />
The class layout looks something like this:<br />
<br />
<source lang="cpp"><br />
#ifndef itkImage_h<br />
#define itkImage_h<br />
<br />
#include "itkImageBase.h"<br />
#include "itkPixelTraits.h"<br />
#include "itkDefaultImageTraits.h"<br />
#include "itkDefaultDataAccessor.h"<br />
<br />
namespace itk<br />
{<br />
<br />
/** \class Image<br />
* \brief Templated n-dimensional image class.<br />
*<br />
* .... detailed documentation....<br />
*/<br />
template< typename TPixel, unsigned int VImageDimension=2,<br />
typename TImageTraits=DefaultImageTraits< TPixel, VImageDimension > ><br />
class Image: public ImageBase< VImageDimension ><br />
{<br />
public:<br />
//....stuff...<br />
protected:<br />
//....stuff...<br />
private:<br />
//....stuff...<br />
};<br />
<br />
} // end namespace itk<br />
<br />
#ifndef ITK_MANUAL_INSTANTIATION<br />
#include "itkImage.hxx"<br />
#endif<br />
<br />
#endif<br />
</source><br />
<br />
==== Method Definition ====<br />
<br />
* Methods are defined across multiple lines. This is to accommodate the extremely long definitions possible when using templates.<br />
* The starting and ending brace should be in column one. For example:<br />
<br />
<source lang="cpp"><br />
template<typename TPixel, unsigned int VImageDimension, typename TImageTraits><br />
const double *<br />
Image<TPixel, VImageDimension, TImageTraits><br />
::GetSpacing() const<br />
{<br />
//...stuff...<br />
}<br />
</source><br />
<br />
* The first line is the template declaration.<br />
* The second line is the method return type.<br />
* The third line is the class qualifier.<br />
* And the fourth line in the example above is the name of the method.<br />
<br />
=== Use of Braces ===<br />
<br />
* Braces must be used to delimit the scope of an if, for, while, switch, or other control structure.<br />
* Braces are placed on a line by themselves:<br />
<br />
<source lang="cpp"><br />
for( unsigned int ii = 0; ii < 3; ++ii )<br />
{<br />
...<br />
}<br />
</source><br />
<br />
<br />
or when using an if:<br />
<br />
<source lang="cpp"><br />
if( condition )<br />
{<br />
...<br />
}<br />
else if( other condition )<br />
{<br />
...<br />
}<br />
else<br />
{<br />
....<br />
}<br />
</source><br />
<br />
<br />
==== Indentation Inside Braces ====<br />
<br />
<br />
Source code in the body of the brackets must be aligned along with the brackets. As in<br />
<br />
<source lang="cpp"><br />
if ( condition )<br />
{<br />
unsigned int numberOfIterations = 100;<br />
filter->SetNumberOfIterations( numberOfIterations );<br />
filter->Update();<br />
filter->Print( std::cout );<br />
}<br />
</source><br />
<br />
=== Doxygen Documentation System ===<br />
<br />
* Doxygen is an open-source, powerful system for automatically generating documentation from source code.<br />
* To use Doxygen effectively, the developer must insert comments, delimited in a special way, that Doxygen extracts to produce the documentation. While there are a large number of options to Doxygen, developers at a minimum should insert the following Doxygen commands.<br />
<br />
See more at<br />
<br />
http://www.stack.nl/dimitri/doxygen/index.html<br />
<br />
==== Documenting a Class ====<br />
<br />
* Classes should be documented using the '''class''' and '''brief''' Doxygen commands, followed by the detailed class description:<br />
<br />
<source lang="cpp"><br />
/** \class Object<br />
* \brief Base class for most itk classes.<br />
*<br />
* Object is the second-highest level base class for most itk objects.<br />
* It extends the base object functionality of LightObject by<br />
* implementing debug flags/methods and modification time tracking.<br />
*/<br />
</source><br />
<br />
==== Documenting a Method ====<br />
<br />
* Methods should be documented using the following comment block style as shown in the following example. Make sure you use correct English and complete, grammatically correct sentences. Finish your sentences with a period (.).<br />
<br />
<source lang="cpp"><br />
/** Access a pixel at a particular index location.<br />
* This version can be an lvalue. */<br />
TPixel & operator[](const IndexType &index)<br />
{ return this->GetPixel(index); }<br />
</source><br />
<br />
The key here is that the comment starts with /**, each subsequent line has an aligned *, and the comment block terminates with a */.<br />
<br />
* Method documentation should be placed in the '''declaration files''' (*.h): the documentation in the implementation causes ambiguity for Doxygen on which documentation to use, the declaration or definition.<br />
** If there is something that is appropriate for the definition only (*.cxx or *.hxx), it should be placed '''inside the method''', and it could use either the /* */ or the // style comment, but it should not use /** */, which is for Doxygen comments.<br />
<br />
==== Documenting ivars ====<br />
<br />
* Class member variables should be documented using the following comment block style as shown in the following example. Make sure you use correct English and grammatically correct sentences. Finish the documentation line with a period (.).<br />
<br />
<source lang="cpp"><br />
// Standard deviation of the Gaussian used for smoothing.<br />
SigmaArrayType m_Sigma;<br />
</source><br />
<br />
=== Using Standard Macros (itkMacro.h) ===<br />
<br />
* There are several macros defined in the file itkMacro.h.<br />
* These macros should be used because they perform several important operations, that if not done correctly can cause serious, hard to debug problems in the system.<br />
** These operations are:<br />
*** Object modified time is properly managed.<br />
*** Debug information is printed.<br />
*** Reference counting is handled properly.<br />
<br />
Some of the more important object macros are as follows.<br />
<br />
* itkNewMacro(T) Creates the static class method New(void) that interacts with the object factory to instantiate objects. The method returns a SmartPointer<T> properly reference counted.<br />
* itkDebugMacro(x) If debug is set on a subclass of itk::Object, prints debug information to the appropriate output stream.<br />
* itkSetMacro(name,type) Creates a method SetName() that takes argument type type.<br />
* itkGetMacro(name,type) Creates a method GetName() that returns a non-const value of type type.<br />
* itkGetConstMacro(name,type) Creates a method GetName() that returns a const value of type type.<br />
* itkSetStringMacro(name) Creates a method SetName() that takes argument type const char*.<br />
* itkGetStringMacro(name) Creates a method GetName() that returns argument type const char*.<br />
* itkBooleanMacro(name) Creates two methods named NameOn and NameOff that sets true/false boolean values.<br />
* itkSetObjectMacro(name,type) Creates a method SetName() that takes argument type type *.<br />
* itkGetObjectMacro(name,type) Creates a method named GetName() that returns a smart pointer to a type type.<br />
* itkSetConstObjectMacro(name,type) Creates a method SetName() that takes argument type const type *.<br />
* itkGetConstObjectMacro(name,type) Creates a method named GetName() that returns a const smart pointer to a type type.<br />
<br />
Please review this file and become familiar with these macros.<br />
<br />
=== Exception Handling ===<br />
<br />
Indicate that methods throw exceptions in the method declaration as in:<br />
<br />
<source lang="cpp"><br />
const float* foo() const throws itk<br />
</source><br />
<br />
=== Documentation Style ===<br />
<br />
The Insight consortium has adopted the following guidelines for producing supplemental documentation (documentation not produced by Doxygen).<br />
<br />
* The common denominator for documentation is either PDF or HTML. All documents in the system should be available in these formats, even if they are mastered by another system.<br />
* Presentations are acceptable in Microsoft PowerPoint format.<br />
* Administrative and planning documents are acceptable in Microsoft Word format (either .doc or .rtf).<br />
* Larger documents, such as the user's or developer's guide, are written in LATEX.<br />
<br />
== CMake Style ==<br />
<br />
A proposal style guide for CMake variables is presented [[ITK_CMake_Style|HERE]].<br />
<br />
{{ITK/Template/Footer}}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Configuring_and_Building/VisualStudio&diff=59200ITK/Configuring and Building/VisualStudio2016-03-08T21:16:11Z<p>Dzenanz: slightly better formatting</p>
<hr />
<div>With Visual Studio 2010 on Windows 7 (32-bit):<br />
<br />
* Launch the CMake GUI by starting a Visual Studio Command Prompt (Start->Programs-> Microsoft Visual Studio 2010->Visual Studio Tools->Visual Studio Command Prompt) and running "cmake-gui"<br />
* Next to "Where is the source code:", click "Browse Source..." and navigate to where you cloned the repository with Git.<br />
* Next to "Where to build the binaries:", select "Browse Build..." and select a place to build the ITK library. I like to use c:\build\ITK. This directory should NOT be inside the directory where you cloned the repository.<br />
* Click "Configure", and then specify "Visual Studio 10" as the generator for this project.<br />
* Choose your build options. I like to '''uncheck''' BUILD_EXAMPLES and BUILD_TESTING, because not building them speeds up the build process significantly.<br />
* Click "Generate".<br />
* Open Visual Studio 2010<br />
* Open Project<br />
* Navigate to the Build directory you specified through CMake<br />
* Open the ALL_BUILD project<br />
* From the Build menu, choose "Build Solution" (or "Build ALL_BUILD")</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=ITK/Contribute&diff=58750ITK/Contribute2016-01-04T16:21:35Z<p>Dzenanz: Update to follow http://www.itk.org/Wiki/ITK/Git/Develop</p>
<hr />
<div>Short guide for best practices process for contributing to ITK.<br />
<br />
== Step by step complete documentation provided at ==<br />
<br />
How to develop new patches http://www.itk.org/Wiki/ITK/Git/Develop<br />
<br />
<br />
<br />
== Bugs/Feature enhancements best practices guide ==<br />
<br />
# Determine if the contribution is already listed in the bug tracker: http://issues.itk.org<br />
# Add proposed contribution (if necessary) and assign it to yourself (NOTE THE BUG ID link i.e. ITK-2287)<br />
# Create a new branch called "ITK-2287" from the updated git ITK master branch<br />
# Make proposed changes on branch "ITK-2287" and thoroughly test the changes<br />
# Commit changes with a comment that includes the BUGID<br />
# Submit the commit to ITK code review using gerrit-push<br />
# Close the JIRA issue, and include the commit hash key as a comment when closing.<br />
<br />
=== Example ===<br />
<br />
To update the ITK version number, the follow process could be followed:<br />
<br />
Create a JIRA issue stating what you want to accomplish.<br />
Assign issue to yourself.<br />
<br />
<pre><br />
git status<br />
git checkout master<br />
git pullall<br />
git checkout -b ITK-2287 origin/master<br />
vim CMakeLists.txt # Edit to change the version number<br />
git add CMakeLists.txt<br />
git commit -m"BUG: Issue resolved for bug ITK-2287"<br />
git prepush<br />
git gerrit-push<br />
</pre><br />
<br />
Close the JIRA issue with reference to the commit hash key.<br />
<br />
== Changing commit history ==<br />
<br />
Git has some powerful tools to refactor the commit history. For example,<br />
<pre><br />
git commit --amend<br />
</pre><br />
can be used to change the content or commit message from the last commit.<br />
<br />
<pre><br />
git rebase -i<br />
</pre><br />
can be used to merge incremental commits into logical units.<br />
<br />
These can be very convenient functions, but they should only be used on a local repository ''before'' the changes have been published to a public location.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Installation/Main&diff=58625PET-CT/Installation/Main2015-12-22T16:53:49Z<p>Dzenanz: /* Pre-compiled binaries */</p>
<hr />
<div>== System requirements ==<br />
SlicerPET requires 1GB of RAM minimum, with more highly recommended. Common data sets may require 4GB or more RAM for processing. A fast graphics card or GPU that supports OpenGL is also recommended.<br />
SlicerPET runs on Microsoft Windows 7 and a variety of Linux distributions.<br />
<br />
== Pre-compiled binaries ==<br />
<br />
* Download packages on [https://data.kitware.com/#collection/567187b68d777f429eac8de6/folder/567197338d777f429eac8dea data.kitware.com]. Short URL: [http://bit.ly/1Inw5LF http://bit.ly/1Inw5LF]<br />
* Install SlicerPET<br />
** Execute SlicerPET-xxx.exe on Windows<br />
** Untar SlicerPET-xxx.tar.gz on Linux<br />
<br />
== Target OS and compiler ==<br />
# Windows operating system<br />
# VS2013<br />
# 64 bit<br />
# CMake >= 3.1<br />
# Qt 4.8.7 or 4.8.6<br />
# Slicer:<br />
## GIT_REPOSITORY git@github.com:dzenanz/Slicer.git<br />
## GIT_TAG v4.5-fix2CLIs</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Development/Main&diff=58611PET-CT/Development/Main2015-12-16T17:01:36Z<p>Dzenanz: Removing instructions on uploading to packages.kitware.com</p>
<hr />
<div>== Source code ==<br />
Source code in Kitware's public [https://gitlab.kitware.com/petct/SlicerPET GitLab]. The project uses [https://cmake.org/ CMake], a cross-platform build configuration system. Particularly, SlicerPET uses superbuild feature of CMake.<br />
<br />
== Dashboard ==<br />
[http://kwcdash.kitware.com/CDash/index.php?project=SlicerPET SlicerPET dashboard]<br />
<br />
==External Projects==<br />
The SlicerPET application is based on Slicer Framework. In addition to the external projects included by Slicer official, SlicerPET includes [https://subversion.assembla.com/svn/plus/trunk/PlusLib PlusLib] revision 3900.<br />
<br />
== Building executable == <br />
* Standard CMake configure/build workflow should be followed. If you are not familiar with it, see [https://cmake.org/runningcmake/ running CMake] or [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Developers/Build_Instructions 3D Slicer 4.5 build instructions]<br />
* The executable is SlicerPET.exe which can be found in BuildDir/S-bld/Slicer-build ( Windows )<br />
<br />
== Generating installers ==<br />
=== Windows ===<br />
* Install NSIS in your system<br />
* Build SlicerPET in a release mode<br />
* When the build finishes, load S-bld/Slicer-build/Slicer.sln project file in Visual Studio<br />
* Build PACKAGE target only to generate the installer. There will be a new installer in S-bld/Slicer-build/ with a filename SlicerPET-2.0.0-*-win-amd64.exe<br />
<br />
==Video Tools==<br />
To produce the videos showing how the different modules work [http://public.kitware.com/Wiki/PET-CT/Images#Videos], we used the following tools:<br />
* On Windows:<br />
** We used [http://camstudio.org/ CamStudio], a tool that allows to record all screen and audio activity on the computer. To improve the quality of the videos, we boosted the video option of the tool to the maximum (Quality 100% and 1000 frame per second).<br />
** We used VLC to record the streaming video from a camera device.<br />
* On Mac:<br />
** We used iMovie for post-production, editing and voice-over</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Installation/Main&diff=58610PET-CT/Installation/Main2015-12-16T17:00:39Z<p>Dzenanz: /* Pre-compiled binaries */ packages->data[.kitware.com]</p>
<hr />
<div>== System requirements ==<br />
SlicerPET requires 1GB of RAM minimum, with more highly recommended. Common data sets may require 4GB or more RAM for processing. A fast graphics card or GPU that supports OpenGL is also recommended.<br />
SlicerPET runs on Microsoft Windows 7 and a variety of Linux distributions.<br />
<br />
== Pre-compiled binaries ==<br />
<br />
* Download packages on [https://data.kitware.com/#collection/567187b68d777f429eac8de6/folder/567197338d777f429eac8dea data.kitware.com]<br />
* Install SlicerPET<br />
** Execute SlicerPET-xxx.exe on Windows<br />
** Untar SlicerPET-xxx.tar.gz on Linux<br />
<br />
== Target OS and compiler ==<br />
# Windows operating system<br />
# VS2013<br />
# 64 bit<br />
# CMake >= 3.1<br />
# Qt 4.8.7 or 4.8.6<br />
# Slicer:<br />
## GIT_REPOSITORY git@github.com:dzenanz/Slicer.git<br />
## GIT_TAG v4.5-fix2CLIs</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Images/Main&diff=58594PET-CT/Images/Main2015-12-10T16:59:25Z<p>Dzenanz: /* Videos */ Adding video for 2.0</p>
<hr />
<div>== Study of the guidance workflow ==<br />
<gallery widths=300px perrow=2><br />
File:PETCTWorkflowSystemDiagram.png<br />
File:PETCTStudyWorkflowChart.png<br />
</gallery><br />
<br />
== Videos ==<br />
<br />
<gallery widths=300px perrow=3><br />
File:PivotCalibration-video.png|[http://vimeo.com/68161539 PivotCalibration demo] (01:35)<br />
File:GuidedInterventionPETCT-video.png|[http://vimeo.com/68161954 Workflow demo - old version] (02:59)<br />
File:GuidedInterventionPETCT-videoNew.png|[http://vimeo.com/113304269 Workflow demo - new version] (03:58)<br />
File:PET-CT Walkthrough 2.0.jpg|[http://vimeo.com/148510664 SlicerPET 2.0 Walkthrough] (02:17)<br />
</gallery><br />
<br />
== Guided Intervention Workflow ==<br />
<br />
<gallery widths=300px perrow=3><br />
Image:GuidedPETCTWorkflowStep1.png|Step 1: Load Data<br />
Image:GuidedPETCTWorkflowStep2.png|Step 2: Registration PET/CT and interventional CT<br />
Image:GuidedPETCTWorkflowStep3.png|Step 3: OpenIGTLinkIF<br />
Image:GuidedPETCTWorkflowStep4.png|Step 4: Pivot Calibration<br />
Image:GuidedPETCTWorkflowStep5.png|Step 5: CT to hardware registration<br />
Image:GuidedPETCTWorkflowStep6.png|Step 6: Path planning<br />
Image:GuidedPETCTWorkflowStep7.png|Step 7: Needle guidance<br />
</gallery></div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=File:PET-CT_Walkthrough_2.0.jpg&diff=58593File:PET-CT Walkthrough 2.0.jpg2015-12-10T14:15:22Z<p>Dzenanz: This video demonstrates the newly released SlicerPET 2.0. In this version, the registration step has been refactored to include an optional second rigid registration phase and a manual interface to tweak initial transform to ensure convergence, even wi...</p>
<hr />
<div>This video demonstrates the newly released SlicerPET 2.0. In this version, the registration step has been refactored to include an optional second rigid registration phase and a manual interface to tweak initial transform to ensure convergence, even with grossly different CT images. The parameters that are rarely used are now removed from the user interface. The application has been rebased on the latest Slicer 4.5 release, bringing along all the bug fixes and improvements done since 4.4. Screenshot and statistical information about the intervention can now be saved in the last step of the workflow. The visualization elements in path planning and needle guidance steps have been improved.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Development/Main&diff=58531PET-CT/Development/Main2015-11-25T14:58:38Z<p>Dzenanz: /* Building executable */</p>
<hr />
<div>== Source code ==<br />
Source code in Kitware's public [https://gitlab.kitware.com/petct/SlicerPET GitLab]. The project uses [https://cmake.org/ CMake], a cross-platform build configuration system. Particularly, SlicerPET uses superbuild feature of CMake.<br />
<br />
== Dashboard ==<br />
[http://kwcdash.kitware.com/CDash/index.php?project=SlicerPET SlicerPET dashboard]<br />
<br />
==External Projects==<br />
The SlicerPET application is based on Slicer Framework. In addition to the external projects included by Slicer official, SlicerPET includes [https://subversion.assembla.com/svn/plus/trunk/PlusLib PlusLib] revision 3900.<br />
<br />
== Building executable == <br />
* Standard CMake configure/build workflow should be followed. If you are not familiar with it, see [https://cmake.org/runningcmake/ running CMake] or [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Developers/Build_Instructions 3D Slicer 4.5 build instructions]<br />
* The executable is SlicerPET.exe which can be found in BuildDir/S-bld/Slicer-build ( Windows )<br />
<br />
== Generating installers ==<br />
=== Windows ===<br />
* Install NSIS in your system<br />
* Build SlicerPET in a release mode<br />
* When the build finishes, load S-bld/Slicer-build/Slicer.sln project file in Visual Studio<br />
* Build PACKAGE target only to generate the installer. There will be a new installer in S-bld/Slicer-build/ with a filename SlicerPET-2.0.0-*-win-amd64.exe<br />
<br />
==Uploading installers to Packages server ==<br />
How to upload packages to [http://packages.kitware.com/packages/application/view?applicationId=19 packages.kitware.com]:<br />
* Create an account and join the PET-CT community<br />
* Download the following script : [http://public.kitware.com/Wiki/File:Upload-SlicerPET-to-packages-kitware-com.cmake Upload-SlicerPET-to-packages-kitware-com.cmake]<br />
** Change the MIDAS_USER and enter you MIDAS_API_KEY that you can generate in your packages.kitware.com profile.<br />
** Modify the following lines if you are uploading windows or linux executables to the appropriate values:<br />
file(GLOB packages "SlicerPET-*.exe")<br />
...<br />
PACKAGE_TYPE "NSIS installer"<br />
* Run the command line "cmake -P Upload-SlicerPET-to-packages-kitware-com.cmake"<br />
<br />
==Video Tools==<br />
To produce the videos showing how the different modules work [http://public.kitware.com/Wiki/PET-CT/Images#Videos], we used the following tools:<br />
* On Windows:<br />
** We used [http://camstudio.org/ CamStudio], a tool that allows to record all screen and audio activity on the computer. To improve the quality of the videos, we boosted the video option of the tool to the maximum (Quality 100% and 1000 frame per second).<br />
** We used VLC to record the streaming video from a camera device.<br />
* On Mac:<br />
** We used iMovie for post-production, editing and voice-over</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Development/Main&diff=58530PET-CT/Development/Main2015-11-25T14:53:40Z<p>Dzenanz: /* Windows */</p>
<hr />
<div>== Source code ==<br />
Source code in Kitware's public [https://gitlab.kitware.com/petct/SlicerPET GitLab]. The project uses [https://cmake.org/ CMake], a cross-platform build configuration system. Particularly, SlicerPET uses superbuild feature of CMake.<br />
<br />
== Dashboard ==<br />
[http://kwcdash.kitware.com/CDash/index.php?project=SlicerPET SlicerPET dashboard]<br />
<br />
==External Projects==<br />
The SlicerPET application is based on Slicer Framework. In addition to the external projects included by Slicer official, SlicerPET includes [https://subversion.assembla.com/svn/plus/trunk/PlusLib PlusLib] revision 3900.<br />
<br />
== Building executable == <br />
* [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Developers/Build_Instructions Follow 3D Slicer 4.5 build instructions]<br />
* The executable is SlicerPET.exe which can be found in BuildDir/S-bld/Slicer-build ( Windows )<br />
<br />
== Generating installers ==<br />
=== Windows ===<br />
* Install NSIS in your system<br />
* Build SlicerPET in a release mode<br />
* When the build finishes, load S-bld/Slicer-build/Slicer.sln project file in Visual Studio<br />
* Build PACKAGE target only to generate the installer. There will be a new installer in S-bld/Slicer-build/ with a filename SlicerPET-2.0.0-*-win-amd64.exe<br />
<br />
==Uploading installers to Packages server ==<br />
How to upload packages to [http://packages.kitware.com/packages/application/view?applicationId=19 packages.kitware.com]:<br />
* Create an account and join the PET-CT community<br />
* Download the following script : [http://public.kitware.com/Wiki/File:Upload-SlicerPET-to-packages-kitware-com.cmake Upload-SlicerPET-to-packages-kitware-com.cmake]<br />
** Change the MIDAS_USER and enter you MIDAS_API_KEY that you can generate in your packages.kitware.com profile.<br />
** Modify the following lines if you are uploading windows or linux executables to the appropriate values:<br />
file(GLOB packages "SlicerPET-*.exe")<br />
...<br />
PACKAGE_TYPE "NSIS installer"<br />
* Run the command line "cmake -P Upload-SlicerPET-to-packages-kitware-com.cmake"<br />
<br />
==Video Tools==<br />
To produce the videos showing how the different modules work [http://public.kitware.com/Wiki/PET-CT/Images#Videos], we used the following tools:<br />
* On Windows:<br />
** We used [http://camstudio.org/ CamStudio], a tool that allows to record all screen and audio activity on the computer. To improve the quality of the videos, we boosted the video option of the tool to the maximum (Quality 100% and 1000 frame per second).<br />
** We used VLC to record the streaming video from a camera device.<br />
* On Mac:<br />
** We used iMovie for post-production, editing and voice-over</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Development/Main&diff=58529PET-CT/Development/Main2015-11-25T14:52:34Z<p>Dzenanz: /* Source code */</p>
<hr />
<div>== Source code ==<br />
Source code in Kitware's public [https://gitlab.kitware.com/petct/SlicerPET GitLab]. The project uses [https://cmake.org/ CMake], a cross-platform build configuration system. Particularly, SlicerPET uses superbuild feature of CMake.<br />
<br />
== Dashboard ==<br />
[http://kwcdash.kitware.com/CDash/index.php?project=SlicerPET SlicerPET dashboard]<br />
<br />
==External Projects==<br />
The SlicerPET application is based on Slicer Framework. In addition to the external projects included by Slicer official, SlicerPET includes [https://subversion.assembla.com/svn/plus/trunk/PlusLib PlusLib] revision 3900.<br />
<br />
== Building executable == <br />
* [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Developers/Build_Instructions Follow 3D Slicer 4.5 build instructions]<br />
* The executable is SlicerPET.exe which can be found in BuildDir/S-bld/Slicer-build ( Windows )<br />
<br />
== Generating installers ==<br />
=== Windows ===<br />
* Install NSIS in your system<br />
* Build SlicerPET in a release mode<br />
* When the build finishes, load S-bld/Slicer-build/Slicer.sln project file in Visual Studio<br />
* Build PACKAGE target only to generate the installer. ( There will be a new installer in S-bld/Slicer-build/ ( With a filename a SlicerPET-2.0.0-*-win-amd64.exe )<br />
<br />
==Uploading installers to Packages server ==<br />
How to upload packages to [http://packages.kitware.com/packages/application/view?applicationId=19 packages.kitware.com]:<br />
* Create an account and join the PET-CT community<br />
* Download the following script : [http://public.kitware.com/Wiki/File:Upload-SlicerPET-to-packages-kitware-com.cmake Upload-SlicerPET-to-packages-kitware-com.cmake]<br />
** Change the MIDAS_USER and enter you MIDAS_API_KEY that you can generate in your packages.kitware.com profile.<br />
** Modify the following lines if you are uploading windows or linux executables to the appropriate values:<br />
file(GLOB packages "SlicerPET-*.exe")<br />
...<br />
PACKAGE_TYPE "NSIS installer"<br />
* Run the command line "cmake -P Upload-SlicerPET-to-packages-kitware-com.cmake"<br />
<br />
==Video Tools==<br />
To produce the videos showing how the different modules work [http://public.kitware.com/Wiki/PET-CT/Images#Videos], we used the following tools:<br />
* On Windows:<br />
** We used [http://camstudio.org/ CamStudio], a tool that allows to record all screen and audio activity on the computer. To improve the quality of the videos, we boosted the video option of the tool to the maximum (Quality 100% and 1000 frame per second).<br />
** We used VLC to record the streaming video from a camera device.<br />
* On Mac:<br />
** We used iMovie for post-production, editing and voice-over</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Documentation/Modules/GuidedInterventionPETCT&diff=58528PET-CT/Documentation/Modules/GuidedInterventionPETCT2015-11-25T14:46:48Z<p>Dzenanz: /* Introduction and Acknowledgements */ email addresses</p>
<hr />
<div>= Introduction and Acknowledgements =<br />
Authors: Andinet Enquobahrie [http://www.kitware.com Kitware], Guillaume Sala, [http://www.kitware.com Kitware], Rahul Khare, [http://www.childrensnational.org ChildrensNational], Julien Finet [http://www.kitware.com Kitware], Dženan Zukić [http://www.kitware.com Kitware]<br><br />
Acknowledgements: This work is supported by NIH grants 2R42CA153488-02A1, R41CA153488-01 and 3R42CA153488-03S1 "Improving liver lesion biopsy in the CT suite through fusion with PET images"<br><br />
Contact: [mailto:andinet.enqu@kitware.com Andinet Enquobahrie], [mailto:dzenan.zukic@kitware.com Dženan Zukić]<br><br />
<br />
= Module Description =<br />
<br />
The GuidedInterventionPETCT is a workflow-based module that guides the user in a step-by-step interface to realize a guided biopsy after fusing respiratory-compensated PET/CT with images in the interventional CT suite.<br><br />
In each step of the workflow we prepare the necessary requirements to fulfill the end goal, following a given pipeline: Registration of the different volumes acquired, establishing the connection between the tracking device and Slicer, registration of the coordinate system of the tracking system and the registered volume and live tracking of the needle in Slicer.<br><br />
This module uses existing modules to accomplish some of the steps:<br><br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/Annotations Annotations]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/FiducialRegistration Fiducial Registration]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/VolumeResliceDriver Volume Reslice Driver]<br />
*[[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]]<br />
<br />
= Use Cases =<br />
<br />
<gallery widths=300px perrow=3><br />
Image:GuidedPETCTWorkflowStep1.png|Step1: Load Data<br />
Image:GuidedPETCTWorkflowStep2.png|Step2: Registration PET/CT and interventional CT<br />
Image:GuidedPETCTWorkflowStep3.png|Step3: OpenIGTLinkIF<br />
Image:GuidedPETCTWorkflowStep4.png|Step4: Pivot Calibration<br />
Image:GuidedPETCTWorkflowStep5.png|Step5: Tracker to CT registration<br />
Image:GuidedPETCTWorkflowStep6.png|Step6: Path planner<br />
Image:GuidedPETCTWorkflowStep7.png|Step6: Guidance<br />
</gallery><br />
<br />
= Panels =<br />
<br />
== Loading Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
The loading step is the first step of the workflow. The user selects the data that is going to be used for the guided biopsy.<br><br />
Read [http://wiki.slicer.org/slicerWiki/index.php/Documentation/4.5/SlicerApplication/LoadingData here] the instructions to load data into Slicer.<br><br />
<br />
* '''MC PET Volume''': This combobox allows selecting the motion-compensated PET scans.<br />
* '''MC CT Volume''': This combobox allows selecting the motion-compensated CT scans.<br />
* '''CBCT Volume''': This combobox allows selecting the interventional CT Scan.<br />
<br />
The volumes in these comboboxes will be used to compute the image registration, between the pre-operative PET/CT acquisition and the interventional CT. The fused PET and interventional CT images will guide the biopsy procedure.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep1Panel.png|thumb|300px|Loading data panel]]<br />
|}<br />
<br />
== Volume Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step we compute the image registration of the motion-compensated PET/CT and interventional CT.<br><br />
The user can tweak initial position and orientation - in case that the automatic registration fail or to make it converge faster.<br><br />
<br />
* '''Sampling percent''': Percentage of voxels which are sampled to calculate registration metric<br />
* '''Precise rigid phase''': Should a higher-resolution rigid registration be conducted in addition to low resolution rigid registration?<br />
* '''BSpline''': Should a BSpline registration be conducted in addition to rigid registration?<br />
* '''Grid Size''': Number of divisions for BSpline registration. Bigger number mean more degrees of freedom, implying slower registration with a potential for higher precision.<br />
<br />
* '''Start Registration''': Push Button to start the registration with the volumes selected in the previous step.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep2Panel.png|thumb|300px|Volume Registration panel]]<br />
|}<br />
<br />
== OpenIGTLinkIF Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step of the workflow we establish the link between Slicer and the tracking system.<br><br />
To establish this connection we import the OpenIGTLinkIF module of Slicer.<br />
For more information about the use of this module please see the [http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF] documentation.<br><br />
One method to establish the connection is using IGSTK:<br><br />
*Run the executable [http://public.kitware.com/IGSTKWIKI/index.php/Using_OpenIGTLink_in_IGSTK#Broadcast_Tracking_data_using_OpenIGTLink OpenIGTLinkTrackerBroadcasting] giving a configuration file for the given tracking system (e.g [[Media:IGSTK_polarisHybridConfiguration.xml|Polaris configuration file]], [[Media:IGSTK_micronConfiguration.xml|Micron configuration file]])<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep3Panel.png|thumb|300px|OpenIGTLinkIF panel]]<br />
|}<br />
<br />
== Pivot Calibration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This section allows the user to run a pivot calibration algorithm on the tracker device (whose connection was establish on the previous step). To accomplish this, we import the existing PivotCalibration module.<br><br />
For more information about the use of this module please see the [[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]] documentation.<br><br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep4Panel.png|thumb|300px|Pivot calibration panel]]<br />
|}<br />
<br />
== Hardware Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This step allows the user to run a fiducial registration to transform the tracker coordinate system to the registered volume (PET/CT scans with the interventional CT scans) coordinate system.<br><br />
To run the fiducial registration we need to create two fiducial lists (TrackerMarkers and CTMarkers) containing respective points in the different coordinate system.<br />
<br />
For more information about the fiducial registration, please see the documentation [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Modules/FiducialRegistration here].<br><br />
<br />
* '''Acquire 1 tracker fiducial''': This button allows the user, by clicking on it, to create a new fiducial at the current position of the tracking device, and adding it to the "TrackerMarkers" list.<br />
<br />
* '''Place 1 image fiducial''': The user needs to place the fiducials on the CT volume (in a position corresponding to TrackerMarkers) to be able to run the registration.<br> <br />
* '''Register''': This button allows the user to call the fiducial registration CLI module with two fiducial lists previously filled.<br />
<br />
|[[File:GuidedPETCTWorkflowStep5Panel.png|thumb|300px|Hardware registration panel]]<br />
|}<br />
<br />
== Path Planner ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step the guidance path can be planned. "Place target" and "Place entry point" buttons allow the user to choose those points in the PET/CT fused image using mouse. "Entry from needle tip" allow entry point to be taken from the current needle tip position (usually after the interventional radiologist has placed it on the skin of the patient). Clicking on positions in the "RAS" row jumps all the slices to that position (target or entry point).<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep6Panel.png|thumb|300px|Path planner panel]]<br />
|}<br />
<br />
<br />
== Guidance ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This is the last step of the workflow. It displays 4 slice views: axial, sagittal, a slice through the needle, and a slice perpendicular to the needle, all according to the position of the tracker device. The panel allows control over visual properties of the needle, rotation of bottom-right slice and saving of statistical data and screenshots. The data is saved to computer user's home folder (''C:\Users\username'', ''/home/username'', etc depending on the operating system).<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep7Panel.png|thumb|300px|Guidance panel]]<br />
|}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Development/Main&diff=58522PET-CT/Development/Main2015-11-23T22:55:47Z<p>Dzenanz: Adding link to source code</p>
<hr />
<div>== Source code ==<br />
[https://gitlab.kitware.com/petct/SlicerPET Source code in Kitware's public GitLab]<br />
<br />
== Dashboard ==<br />
[http://kwcdash.kitware.com/CDash/index.php?project=SlicerPET SlicerPET dashboard]<br />
<br />
==External Projects==<br />
The SlicerPET application is based on Slicer Framework. In addition to the external projects included by Slicer official, SlicerPET includes [https://subversion.assembla.com/svn/plus/trunk/PlusLib PlusLib] revision 3900.<br />
<br />
== Building executable == <br />
* [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Developers/Build_Instructions Follow 3D Slicer 4.5 build instructions]<br />
* The executable is SlicerPET.exe which can be found in BuildDir/S-bld/Slicer-build ( Windows )<br />
<br />
== Generating installers ==<br />
=== Windows ===<br />
* Install NSIS in your system<br />
* Build SlicerPET in a release mode<br />
* When the build finishes, load S-bld/Slicer-build/Slicer.sln project file in Visual Studio<br />
* Build PACKAGE target only to generate the installer. ( There will be a new installer in S-bld/Slicer-build/ ( With a filename a SlicerPET-2.0.0-*-win-amd64.exe )<br />
<br />
==Uploading installers to Packages server ==<br />
How to upload packages to [http://packages.kitware.com/packages/application/view?applicationId=19 packages.kitware.com]:<br />
* Create an account and join the PET-CT community<br />
* Download the following script : [http://public.kitware.com/Wiki/File:Upload-SlicerPET-to-packages-kitware-com.cmake Upload-SlicerPET-to-packages-kitware-com.cmake]<br />
** Change the MIDAS_USER and enter you MIDAS_API_KEY that you can generate in your packages.kitware.com profile.<br />
** Modify the following lines if you are uploading windows or linux executables to the appropriate values:<br />
file(GLOB packages "SlicerPET-*.exe")<br />
...<br />
PACKAGE_TYPE "NSIS installer"<br />
* Run the command line "cmake -P Upload-SlicerPET-to-packages-kitware-com.cmake"<br />
<br />
==Video Tools==<br />
To produce the videos showing how the different modules work [http://public.kitware.com/Wiki/PET-CT/Images#Videos], we used the following tools:<br />
* On Windows:<br />
** We used [http://camstudio.org/ CamStudio], a tool that allows to record all screen and audio activity on the computer. To improve the quality of the videos, we boosted the video option of the tool to the maximum (Quality 100% and 1000 frame per second).<br />
** We used VLC to record the streaming video from a camera device.<br />
* On Mac:<br />
** We used iMovie for post-production, editing and voice-over</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Development/Main&diff=58500PET-CT/Development/Main2015-11-20T16:42:43Z<p>Dzenanz: /* Dashboard */</p>
<hr />
<div>== Dashboard ==<br />
[http://kwcdash.kitware.com/CDash/index.php?project=SlicerPET SlicerPET dashboard]<br />
<br />
==External Projects==<br />
The SlicerPET application is based on Slicer Framework. In addition to the external projects included by Slicer official, SlicerPET includes [https://subversion.assembla.com/svn/plus/trunk/PlusLib PlusLib] revision 3900.<br />
<br />
== Building executable == <br />
* [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Developers/Build_Instructions Follow 3D Slicer 4.5 build instructions]<br />
* The executable is SlicerPET.exe which can be found in BuildDir/S-bld/Slicer-build ( Windows )<br />
<br />
== Generating installers ==<br />
=== Windows ===<br />
* Install NSIS in your system<br />
* Build SlicerPET in a release mode<br />
* When the build finishes, load S-bld/Slicer-build/Slicer.sln project file in Visual Studio<br />
* Build PACKAGE target only to generate the installer. ( There will be a new installer in S-bld/Slicer-build/ ( With a filename a SlicerPET-2.0.0-*-win-amd64.exe )<br />
<br />
==Uploading installers to Packages server ==<br />
How to upload packages to [http://packages.kitware.com/packages/application/view?applicationId=19 packages.kitware.com]:<br />
* Create an account and join the PET-CT community<br />
* Download the following script : [http://public.kitware.com/Wiki/File:Upload-SlicerPET-to-packages-kitware-com.cmake Upload-SlicerPET-to-packages-kitware-com.cmake]<br />
** Change the MIDAS_USER and enter you MIDAS_API_KEY that you can generate in your packages.kitware.com profile.<br />
** Modify the following lines if you are uploading windows or linux executables to the appropriate values:<br />
file(GLOB packages "SlicerPET-*.exe")<br />
...<br />
PACKAGE_TYPE "NSIS installer"<br />
* Run the command line "cmake -P Upload-SlicerPET-to-packages-kitware-com.cmake"<br />
<br />
==Video Tools==<br />
To produce the videos showing how the different modules work [http://public.kitware.com/Wiki/PET-CT/Images#Videos], we used the following tools:<br />
* On Windows:<br />
** We used [http://camstudio.org/ CamStudio], a tool that allows to record all screen and audio activity on the computer. To improve the quality of the videos, we boosted the video option of the tool to the maximum (Quality 100% and 1000 frame per second).<br />
** We used VLC to record the streaming video from a camera device.<br />
* On Mac:<br />
** We used iMovie for post-production, editing and voice-over</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Documentation/Modules/GuidedInterventionPETCT&diff=58498PET-CT/Documentation/Modules/GuidedInterventionPETCT2015-11-19T20:35:43Z<p>Dzenanz: /* Guidance */</p>
<hr />
<div>= Introduction and Acknowledgements =<br />
Authors: Andinet Enquobahrie [http://www.kitware.com Kitware], Guillaume Sala, [http://www.kitware.com Kitware], Rahul Khare, [http://www.childrensnational.org ChildrensNational], Julien Finet [http://www.kitware.com Kitware], Dženan Zukić [http://www.kitware.com Kitware]<br><br />
Acknowledgements: This work is supported by NIH grants 2R42CA153488-02A1, R41CA153488-01 and 3R42CA153488-03S1 "Improving liver lesion biopsy in the CT suite through fusion with PET images"<br><br />
Contact: Andinet Enquobahrie, Dženan Zukić<br><br />
<br />
= Module Description =<br />
<br />
The GuidedInterventionPETCT is a workflow-based module that guides the user in a step-by-step interface to realize a guided biopsy after fusing respiratory-compensated PET/CT with images in the interventional CT suite.<br><br />
In each step of the workflow we prepare the necessary requirements to fulfill the end goal, following a given pipeline: Registration of the different volumes acquired, establishing the connection between the tracking device and Slicer, registration of the coordinate system of the tracking system and the registered volume and live tracking of the needle in Slicer.<br><br />
This module uses existing modules to accomplish some of the steps:<br><br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/Annotations Annotations]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/FiducialRegistration Fiducial Registration]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/VolumeResliceDriver Volume Reslice Driver]<br />
*[[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]]<br />
<br />
= Use Cases =<br />
<br />
<gallery widths=300px perrow=3><br />
Image:GuidedPETCTWorkflowStep1.png|Step1: Load Data<br />
Image:GuidedPETCTWorkflowStep2.png|Step2: Registration PET/CT and interventional CT<br />
Image:GuidedPETCTWorkflowStep3.png|Step3: OpenIGTLinkIF<br />
Image:GuidedPETCTWorkflowStep4.png|Step4: Pivot Calibration<br />
Image:GuidedPETCTWorkflowStep5.png|Step5: Tracker to CT registration<br />
Image:GuidedPETCTWorkflowStep6.png|Step6: Path planner<br />
Image:GuidedPETCTWorkflowStep7.png|Step6: Guidance<br />
</gallery><br />
<br />
= Panels =<br />
<br />
== Loading Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
The loading step is the first step of the workflow. The user selects the data that is going to be used for the guided biopsy.<br><br />
Read [http://wiki.slicer.org/slicerWiki/index.php/Documentation/4.5/SlicerApplication/LoadingData here] the instructions to load data into Slicer.<br><br />
<br />
* '''MC PET Volume''': This combobox allows selecting the motion-compensated PET scans.<br />
* '''MC CT Volume''': This combobox allows selecting the motion-compensated CT scans.<br />
* '''CBCT Volume''': This combobox allows selecting the interventional CT Scan.<br />
<br />
The volumes in these comboboxes will be used to compute the image registration, between the pre-operative PET/CT acquisition and the interventional CT. The fused PET and interventional CT images will guide the biopsy procedure.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep1Panel.png|thumb|300px|Loading data panel]]<br />
|}<br />
<br />
== Volume Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step we compute the image registration of the motion-compensated PET/CT and interventional CT.<br><br />
The user can tweak initial position and orientation - in case that the automatic registration fail or to make it converge faster.<br><br />
<br />
* '''Sampling percent''': Percentage of voxels which are sampled to calculate registration metric<br />
* '''Precise rigid phase''': Should a higher-resolution rigid registration be conducted in addition to low resolution rigid registration?<br />
* '''BSpline''': Should a BSpline registration be conducted in addition to rigid registration?<br />
* '''Grid Size''': Number of divisions for BSpline registration. Bigger number mean more degrees of freedom, implying slower registration with a potential for higher precision.<br />
<br />
* '''Start Registration''': Push Button to start the registration with the volumes selected in the previous step.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep2Panel.png|thumb|300px|Volume Registration panel]]<br />
|}<br />
<br />
== OpenIGTLinkIF Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step of the workflow we establish the link between Slicer and the tracking system.<br><br />
To establish this connection we import the OpenIGTLinkIF module of Slicer.<br />
For more information about the use of this module please see the [http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF] documentation.<br><br />
One method to establish the connection is using IGSTK:<br><br />
*Run the executable [http://public.kitware.com/IGSTKWIKI/index.php/Using_OpenIGTLink_in_IGSTK#Broadcast_Tracking_data_using_OpenIGTLink OpenIGTLinkTrackerBroadcasting] giving a configuration file for the given tracking system (e.g [[Media:IGSTK_polarisHybridConfiguration.xml|Polaris configuration file]], [[Media:IGSTK_micronConfiguration.xml|Micron configuration file]])<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep3Panel.png|thumb|300px|OpenIGTLinkIF panel]]<br />
|}<br />
<br />
== Pivot Calibration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This section allows the user to run a pivot calibration algorithm on the tracker device (whose connection was establish on the previous step). To accomplish this, we import the existing PivotCalibration module.<br><br />
For more information about the use of this module please see the [[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]] documentation.<br><br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep4Panel.png|thumb|300px|Pivot calibration panel]]<br />
|}<br />
<br />
== Hardware Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This step allows the user to run a fiducial registration to transform the tracker coordinate system to the registered volume (PET/CT scans with the interventional CT scans) coordinate system.<br><br />
To run the fiducial registration we need to create two fiducial lists (TrackerMarkers and CTMarkers) containing respective points in the different coordinate system.<br />
<br />
For more information about the fiducial registration, please see the documentation [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Modules/FiducialRegistration here].<br><br />
<br />
* '''Acquire 1 tracker fiducial''': This button allows the user, by clicking on it, to create a new fiducial at the current position of the tracking device, and adding it to the "TrackerMarkers" list.<br />
<br />
* '''Place 1 image fiducial''': The user needs to place the fiducials on the CT volume (in a position corresponding to TrackerMarkers) to be able to run the registration.<br> <br />
* '''Register''': This button allows the user to call the fiducial registration CLI module with two fiducial lists previously filled.<br />
<br />
|[[File:GuidedPETCTWorkflowStep5Panel.png|thumb|300px|Hardware registration panel]]<br />
|}<br />
<br />
== Path Planner ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step the guidance path can be planned. "Place target" and "Place entry point" buttons allow the user to choose those points in the PET/CT fused image using mouse. "Entry from needle tip" allow entry point to be taken from the current needle tip position (usually after the interventional radiologist has placed it on the skin of the patient). Clicking on positions in the "RAS" row jumps all the slices to that position (target or entry point).<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep6Panel.png|thumb|300px|Path planner panel]]<br />
|}<br />
<br />
<br />
== Guidance ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This is the last step of the workflow. It displays 4 slice views: axial, sagittal, a slice through the needle, and a slice perpendicular to the needle, all according to the position of the tracker device. The panel allows control over visual properties of the needle, rotation of bottom-right slice and saving of statistical data and screenshots. The data is saved to computer user's home folder (''C:\Users\username'', ''/home/username'', etc depending on the operating system).<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep7Panel.png|thumb|300px|Guidance panel]]<br />
|}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Documentation/Modules/GuidedInterventionPETCT&diff=58497PET-CT/Documentation/Modules/GuidedInterventionPETCT2015-11-19T20:31:32Z<p>Dzenanz: /* Guidance */</p>
<hr />
<div>= Introduction and Acknowledgements =<br />
Authors: Andinet Enquobahrie [http://www.kitware.com Kitware], Guillaume Sala, [http://www.kitware.com Kitware], Rahul Khare, [http://www.childrensnational.org ChildrensNational], Julien Finet [http://www.kitware.com Kitware], Dženan Zukić [http://www.kitware.com Kitware]<br><br />
Acknowledgements: This work is supported by NIH grants 2R42CA153488-02A1, R41CA153488-01 and 3R42CA153488-03S1 "Improving liver lesion biopsy in the CT suite through fusion with PET images"<br><br />
Contact: Andinet Enquobahrie, Dženan Zukić<br><br />
<br />
= Module Description =<br />
<br />
The GuidedInterventionPETCT is a workflow-based module that guides the user in a step-by-step interface to realize a guided biopsy after fusing respiratory-compensated PET/CT with images in the interventional CT suite.<br><br />
In each step of the workflow we prepare the necessary requirements to fulfill the end goal, following a given pipeline: Registration of the different volumes acquired, establishing the connection between the tracking device and Slicer, registration of the coordinate system of the tracking system and the registered volume and live tracking of the needle in Slicer.<br><br />
This module uses existing modules to accomplish some of the steps:<br><br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/Annotations Annotations]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/FiducialRegistration Fiducial Registration]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/VolumeResliceDriver Volume Reslice Driver]<br />
*[[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]]<br />
<br />
= Use Cases =<br />
<br />
<gallery widths=300px perrow=3><br />
Image:GuidedPETCTWorkflowStep1.png|Step1: Load Data<br />
Image:GuidedPETCTWorkflowStep2.png|Step2: Registration PET/CT and interventional CT<br />
Image:GuidedPETCTWorkflowStep3.png|Step3: OpenIGTLinkIF<br />
Image:GuidedPETCTWorkflowStep4.png|Step4: Pivot Calibration<br />
Image:GuidedPETCTWorkflowStep5.png|Step5: Tracker to CT registration<br />
Image:GuidedPETCTWorkflowStep6.png|Step6: Path planner<br />
Image:GuidedPETCTWorkflowStep7.png|Step6: Guidance<br />
</gallery><br />
<br />
= Panels =<br />
<br />
== Loading Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
The loading step is the first step of the workflow. The user selects the data that is going to be used for the guided biopsy.<br><br />
Read [http://wiki.slicer.org/slicerWiki/index.php/Documentation/4.5/SlicerApplication/LoadingData here] the instructions to load data into Slicer.<br><br />
<br />
* '''MC PET Volume''': This combobox allows selecting the motion-compensated PET scans.<br />
* '''MC CT Volume''': This combobox allows selecting the motion-compensated CT scans.<br />
* '''CBCT Volume''': This combobox allows selecting the interventional CT Scan.<br />
<br />
The volumes in these comboboxes will be used to compute the image registration, between the pre-operative PET/CT acquisition and the interventional CT. The fused PET and interventional CT images will guide the biopsy procedure.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep1Panel.png|thumb|300px|Loading data panel]]<br />
|}<br />
<br />
== Volume Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step we compute the image registration of the motion-compensated PET/CT and interventional CT.<br><br />
The user can tweak initial position and orientation - in case that the automatic registration fail or to make it converge faster.<br><br />
<br />
* '''Sampling percent''': Percentage of voxels which are sampled to calculate registration metric<br />
* '''Precise rigid phase''': Should a higher-resolution rigid registration be conducted in addition to low resolution rigid registration?<br />
* '''BSpline''': Should a BSpline registration be conducted in addition to rigid registration?<br />
* '''Grid Size''': Number of divisions for BSpline registration. Bigger number mean more degrees of freedom, implying slower registration with a potential for higher precision.<br />
<br />
* '''Start Registration''': Push Button to start the registration with the volumes selected in the previous step.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep2Panel.png|thumb|300px|Volume Registration panel]]<br />
|}<br />
<br />
== OpenIGTLinkIF Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step of the workflow we establish the link between Slicer and the tracking system.<br><br />
To establish this connection we import the OpenIGTLinkIF module of Slicer.<br />
For more information about the use of this module please see the [http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF] documentation.<br><br />
One method to establish the connection is using IGSTK:<br><br />
*Run the executable [http://public.kitware.com/IGSTKWIKI/index.php/Using_OpenIGTLink_in_IGSTK#Broadcast_Tracking_data_using_OpenIGTLink OpenIGTLinkTrackerBroadcasting] giving a configuration file for the given tracking system (e.g [[Media:IGSTK_polarisHybridConfiguration.xml|Polaris configuration file]], [[Media:IGSTK_micronConfiguration.xml|Micron configuration file]])<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep3Panel.png|thumb|300px|OpenIGTLinkIF panel]]<br />
|}<br />
<br />
== Pivot Calibration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This section allows the user to run a pivot calibration algorithm on the tracker device (whose connection was establish on the previous step). To accomplish this, we import the existing PivotCalibration module.<br><br />
For more information about the use of this module please see the [[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]] documentation.<br><br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep4Panel.png|thumb|300px|Pivot calibration panel]]<br />
|}<br />
<br />
== Hardware Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This step allows the user to run a fiducial registration to transform the tracker coordinate system to the registered volume (PET/CT scans with the interventional CT scans) coordinate system.<br><br />
To run the fiducial registration we need to create two fiducial lists (TrackerMarkers and CTMarkers) containing respective points in the different coordinate system.<br />
<br />
For more information about the fiducial registration, please see the documentation [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Modules/FiducialRegistration here].<br><br />
<br />
* '''Acquire 1 tracker fiducial''': This button allows the user, by clicking on it, to create a new fiducial at the current position of the tracking device, and adding it to the "TrackerMarkers" list.<br />
<br />
* '''Place 1 image fiducial''': The user needs to place the fiducials on the CT volume (in a position corresponding to TrackerMarkers) to be able to run the registration.<br> <br />
* '''Register''': This button allows the user to call the fiducial registration CLI module with two fiducial lists previously filled.<br />
<br />
|[[File:GuidedPETCTWorkflowStep5Panel.png|thumb|300px|Hardware registration panel]]<br />
|}<br />
<br />
== Path Planner ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step the guidance path can be planned. "Place target" and "Place entry point" buttons allow the user to choose those points in the PET/CT fused image using mouse. "Entry from needle tip" allow entry point to be taken from the current needle tip position (usually after the interventional radiologist has placed it on the skin of the patient). Clicking on positions in the "RAS" row jumps all the slices to that position (target or entry point).<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep6Panel.png|thumb|300px|Path planner panel]]<br />
|}<br />
<br />
<br />
== Guidance ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This is the last step of the workflow. It displays 4 slice views: axial, sagittal, a slice through the needle, and a slice perpendicular to the needle, all according to the position of the tracker device. The panel allows control over size and opacity of target sphere and guidance line thickness.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep7Panel.png|thumb|300px|Guidance panel]]<br />
|}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=PET-CT/Documentation/Modules/GuidedInterventionPETCT&diff=58496PET-CT/Documentation/Modules/GuidedInterventionPETCT2015-11-19T20:29:00Z<p>Dzenanz: Update for version 2.0</p>
<hr />
<div>= Introduction and Acknowledgements =<br />
Authors: Andinet Enquobahrie [http://www.kitware.com Kitware], Guillaume Sala, [http://www.kitware.com Kitware], Rahul Khare, [http://www.childrensnational.org ChildrensNational], Julien Finet [http://www.kitware.com Kitware], Dženan Zukić [http://www.kitware.com Kitware]<br><br />
Acknowledgements: This work is supported by NIH grants 2R42CA153488-02A1, R41CA153488-01 and 3R42CA153488-03S1 "Improving liver lesion biopsy in the CT suite through fusion with PET images"<br><br />
Contact: Andinet Enquobahrie, Dženan Zukić<br><br />
<br />
= Module Description =<br />
<br />
The GuidedInterventionPETCT is a workflow-based module that guides the user in a step-by-step interface to realize a guided biopsy after fusing respiratory-compensated PET/CT with images in the interventional CT suite.<br><br />
In each step of the workflow we prepare the necessary requirements to fulfill the end goal, following a given pipeline: Registration of the different volumes acquired, establishing the connection between the tracking device and Slicer, registration of the coordinate system of the tracking system and the registered volume and live tracking of the needle in Slicer.<br><br />
This module uses existing modules to accomplish some of the steps:<br><br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/Annotations Annotations]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/FiducialRegistration Fiducial Registration]<br />
*[http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/VolumeResliceDriver Volume Reslice Driver]<br />
*[[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]]<br />
<br />
= Use Cases =<br />
<br />
<gallery widths=300px perrow=3><br />
Image:GuidedPETCTWorkflowStep1.png|Step1: Load Data<br />
Image:GuidedPETCTWorkflowStep2.png|Step2: Registration PET/CT and interventional CT<br />
Image:GuidedPETCTWorkflowStep3.png|Step3: OpenIGTLinkIF<br />
Image:GuidedPETCTWorkflowStep4.png|Step4: Pivot Calibration<br />
Image:GuidedPETCTWorkflowStep5.png|Step5: Tracker to CT registration<br />
Image:GuidedPETCTWorkflowStep6.png|Step6: Path planner<br />
Image:GuidedPETCTWorkflowStep7.png|Step6: Guidance<br />
</gallery><br />
<br />
= Panels =<br />
<br />
== Loading Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
The loading step is the first step of the workflow. The user selects the data that is going to be used for the guided biopsy.<br><br />
Read [http://wiki.slicer.org/slicerWiki/index.php/Documentation/4.5/SlicerApplication/LoadingData here] the instructions to load data into Slicer.<br><br />
<br />
* '''MC PET Volume''': This combobox allows selecting the motion-compensated PET scans.<br />
* '''MC CT Volume''': This combobox allows selecting the motion-compensated CT scans.<br />
* '''CBCT Volume''': This combobox allows selecting the interventional CT Scan.<br />
<br />
The volumes in these comboboxes will be used to compute the image registration, between the pre-operative PET/CT acquisition and the interventional CT. The fused PET and interventional CT images will guide the biopsy procedure.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep1Panel.png|thumb|300px|Loading data panel]]<br />
|}<br />
<br />
== Volume Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step we compute the image registration of the motion-compensated PET/CT and interventional CT.<br><br />
The user can tweak initial position and orientation - in case that the automatic registration fail or to make it converge faster.<br><br />
<br />
* '''Sampling percent''': Percentage of voxels which are sampled to calculate registration metric<br />
* '''Precise rigid phase''': Should a higher-resolution rigid registration be conducted in addition to low resolution rigid registration?<br />
* '''BSpline''': Should a BSpline registration be conducted in addition to rigid registration?<br />
* '''Grid Size''': Number of divisions for BSpline registration. Bigger number mean more degrees of freedom, implying slower registration with a potential for higher precision.<br />
<br />
* '''Start Registration''': Push Button to start the registration with the volumes selected in the previous step.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep2Panel.png|thumb|300px|Volume Registration panel]]<br />
|}<br />
<br />
== OpenIGTLinkIF Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step of the workflow we establish the link between Slicer and the tracking system.<br><br />
To establish this connection we import the OpenIGTLinkIF module of Slicer.<br />
For more information about the use of this module please see the [http://www.slicer.org/slicerWiki/index.php/Documentation/4.2/Modules/OpenIGTLinkIF OpenIGTLinkIF] documentation.<br><br />
One method to establish the connection is using IGSTK:<br><br />
*Run the executable [http://public.kitware.com/IGSTKWIKI/index.php/Using_OpenIGTLink_in_IGSTK#Broadcast_Tracking_data_using_OpenIGTLink OpenIGTLinkTrackerBroadcasting] giving a configuration file for the given tracking system (e.g [[Media:IGSTK_polarisHybridConfiguration.xml|Polaris configuration file]], [[Media:IGSTK_micronConfiguration.xml|Micron configuration file]])<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep3Panel.png|thumb|300px|OpenIGTLinkIF panel]]<br />
|}<br />
<br />
== Pivot Calibration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This section allows the user to run a pivot calibration algorithm on the tracker device (whose connection was establish on the previous step). To accomplish this, we import the existing PivotCalibration module.<br><br />
For more information about the use of this module please see the [[PET-CT/Documentation/Modules/Pivot_Calibration | Pivot Calibration]] documentation.<br><br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep4Panel.png|thumb|300px|Pivot calibration panel]]<br />
|}<br />
<br />
== Hardware Registration Step ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This step allows the user to run a fiducial registration to transform the tracker coordinate system to the registered volume (PET/CT scans with the interventional CT scans) coordinate system.<br><br />
To run the fiducial registration we need to create two fiducial lists (TrackerMarkers and CTMarkers) containing respective points in the different coordinate system.<br />
<br />
For more information about the fiducial registration, please see the documentation [http://www.slicer.org/slicerWiki/index.php/Documentation/4.5/Modules/FiducialRegistration here].<br><br />
<br />
* '''Acquire 1 tracker fiducial''': This button allows the user, by clicking on it, to create a new fiducial at the current position of the tracking device, and adding it to the "TrackerMarkers" list.<br />
<br />
* '''Place 1 image fiducial''': The user needs to place the fiducials on the CT volume (in a position corresponding to TrackerMarkers) to be able to run the registration.<br> <br />
* '''Register''': This button allows the user to call the fiducial registration CLI module with two fiducial lists previously filled.<br />
<br />
|[[File:GuidedPETCTWorkflowStep5Panel.png|thumb|300px|Hardware registration panel]]<br />
|}<br />
<br />
== Path Planner ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
In this step the guidance path can be planned. "Place target" and "Place entry point" buttons allow the user to choose those points in the PET/CT fused image using mouse. "Entry from needle tip" allow entry point to be taken from the current needle tip position (usually after the interventional radiologist has placed it on the skin of the patient). Clicking on positions in the "RAS" row jumps all the slices to that position (target or entry point).<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep6Panel.png|thumb|300px|Path planner panel]]<br />
|}<br />
<br />
<br />
== Guidance ==<br />
{| width="100%"<br />
| valign="top"|<br />
<br />
This is the last step of the workflow. It displays 4 slice views: axial, sagittal, a slice through the needle, and a slice perpendicular to the needle, all according to the position of the tracker device.<br />
<br />
| align="right"|<br />
|[[File:GuidedPETCTWorkflowStep7Panel.png|thumb|300px|Guidance panel]]<br />
|}</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=File:GuidedPETCTWorkflowStep7Panel.png&diff=58495File:GuidedPETCTWorkflowStep7Panel.png2015-11-19T19:51:47Z<p>Dzenanz: Guidance step of the workflow module</p>
<hr />
<div>Guidance step of the workflow module</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=File:GuidedPETCTWorkflowStep6Panel.png&diff=58494File:GuidedPETCTWorkflowStep6Panel.png2015-11-19T19:50:50Z<p>Dzenanz: Dzenanz uploaded a new version of &quot;File:GuidedPETCTWorkflowStep6Panel.png&quot;</p>
<hr />
<div>Sixth step of the Guided Intervention PET CT workflow module. Panel View.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=File:GuidedPETCTWorkflowStep5Panel.png&diff=58493File:GuidedPETCTWorkflowStep5Panel.png2015-11-19T19:49:43Z<p>Dzenanz: Dzenanz uploaded a new version of &quot;File:GuidedPETCTWorkflowStep5Panel.png&quot;</p>
<hr />
<div>Fifth step of the Guided Intervention PET CT workflow module. Panel View.</div>Dzenanzhttps://public.kitware.com/Wiki/index.php?title=File:GuidedPETCTWorkflowStep4Panel.png&diff=58492File:GuidedPETCTWorkflowStep4Panel.png2015-11-19T19:48:53Z<p>Dzenanz: Dzenanz uploaded a new version of &quot;File:GuidedPETCTWorkflowStep4Panel.png&quot;</p>
<hr />
<div>Forth step of the Guided Intervention PET CT workflow module. Panel View.</div>Dzenanz