ITK/Tutorials/DOs and DONTs: Difference between revisions
From KitwarePublic
Jump to navigationJump to search
No edit summary |
Daviddoria (talk | contribs) |
||
(3 intermediate revisions by one other user not shown) | |||
Line 4: | Line 4: | ||
* Do call Update() before using the pipeline output | * Do call Update() before using the pipeline output | ||
* Do call UpdateLargestPossibleRegion() when reusing a reader. | |||
<PRE> | |||
When reusing a reader you must call: | |||
reader->UpdateLargestPossibleRegion() | |||
instead of the usual: | |||
reader->Update() | |||
Otherwise the extent of the previous image is kept, and in some cases lead to Exceptions | |||
being thrown if the second image is smaller than the first one. | |||
</pre> | |||
= Filter-Specific = | = Filter-Specific = | ||
Line 33: | Line 42: | ||
*** const unsigned int CONST_VALUE_NAME = 3, | *** const unsigned int CONST_VALUE_NAME = 3, | ||
* ITK doesn't define constants with #defines in header files | * ITK doesn't define constants with #defines in header files | ||
* Do not call Delete() in an ITK smart pointer. | |||
** If you want to destroy a smart pointer object itksmartp, do: | |||
itksmartp = NULL; | |||
the ITK smart pointer will determine whether the object should be "deleted". | |||
<pre> Calling Delete() in ITK smart pointers is a common mistake | |||
when combining VTK code (that requires the use of Delete() ) | |||
and ITK code, (that forbids the use of Delete() ). | |||
Using the new vtkSmartPointer class will help in a more consistent mindset when combining ITK and VTK code. | |||
Instead of: | |||
vtkclass * ptr = vtkclass::New(); | |||
do: | |||
vtkSmartPointer< vtkclass > ptr = vtkSmartPointer< vtkclass >::New() | |||
and then you won't need to call Delete() in VTK classes either. | |||
</pre> |
Latest revision as of 13:17, 1 December 2010
PipeLine
DO
- Do call Update() before using the pipeline output
- Do call UpdateLargestPossibleRegion() when reusing a reader.
When reusing a reader you must call: reader->UpdateLargestPossibleRegion() instead of the usual: reader->Update() Otherwise the extent of the previous image is kept, and in some cases lead to Exceptions being thrown if the second image is smaller than the first one.
Filter-Specific
itkConnectedComponentsImageFilter
DO NOT
- Do not assume InputImage->SetRequestedRegion(smallregion) will make the filter faster! The filter will run on the entire InputImage regardless.
DO
- To make it run on a smaller block:
- get a new itkRegionOfInterestImageFilter, say ROIfilter
- ROIfilter->SetInput(InputImage);
- ROIfilter->SetRegionOfInterest(smallregion);
- CCfilter->SetInput (ROIfilter->GetOutput());
Image Creation
DO
- On a newly-manually-created image, do initialize the pixel values if you expect them to be so!
- Example: image->FillBuffer(0); // initialize it to all dark
- ITK doesn't initialize the image buffer when you call Allocate(). It is your responsibility to initialize the pixel values.
Coding Style
DO NOT
- Do not declare constants using
- #define CONST_VALUE_NAME 3
- Use instead
- const unsigned int CONST_VALUE_NAME = 3,
- ITK doesn't define constants with #defines in header files
- Do not call Delete() in an ITK smart pointer.
- If you want to destroy a smart pointer object itksmartp, do:
itksmartp = NULL; the ITK smart pointer will determine whether the object should be "deleted".
Calling Delete() in ITK smart pointers is a common mistake when combining VTK code (that requires the use of Delete() ) and ITK code, (that forbids the use of Delete() ). Using the new vtkSmartPointer class will help in a more consistent mindset when combining ITK and VTK code. Instead of: vtkclass * ptr = vtkclass::New(); do: vtkSmartPointer< vtkclass > ptr = vtkSmartPointer< vtkclass >::New() and then you won't need to call Delete() in VTK classes either.