Transcript ITK Lecture 9 - Potpourri
ITK Lecture 11 Filters Part II
Damion Shelton Methods in Image Analysis CMU Robotics Institute 16-725 U. Pitt Bioengineering 2630 Spring Term, 2006 1
What are
“
advanced
”
filters?
More than one input Support progress methods Output image is a different size than input Multi-threaded 2
Details, details
In the interests of time I’m going to gloss over some of the finer details I’d like to make you aware of some of the more complicated filter issues, but not scare you away See chapter 13 of the software guide!
3
Diff
’
t output size
Overload GenerateOutputInformation This allows you to set the origin, spacing, and size of the output image By default, the output image is the same size as the input See itkShrinkImageFilter.txx
4
Propagation of output region size
Remember that requested regions propagate back
up
the pipeline from output to input Therefore, it’s likely that if we’re messing with the output image size we’ll also need to alter in the input requested region 5
Changing the requested input size
Overload GenerateInputRequestedRegion() The gist of this function is that you use what you know about the output region to generate a requested region for the input 6
An aside: base class implementations
In general, when overloading base class functionality you should first call the base class function You do this by a line that looks like: Superclass::GenerateInputRequestedRegi on(); This ensures that the important framework stuff still happens 7
Multi-threaded
Actually relatively simple Implement ThreadedGenerateData() instead of GenerateData() A few things look different… 8
Multi-threaded, cont.
The output target is now
OutputImageRegionType& outputRegionForThread
You iterate over this rather than over the entire output image Other than that, the mechanics are pretty similar to the single-threaded case 9
What happens in threading
The pipeline framework “chunks” the output image into regions for each thread to process Each thread gets its own region and thread ID Keep in mind that this can’t/won’t work in all cases, some filters can’t be MT 10
ThreadID
This deserves a special note… In the naïve case a thread would not know how many other threads were out there If a thread takes a non thread-safe action (file writing) it’s possible other threads would do the same thing 11
ThreadID, cont.
1.
This could cause major problems!
The software guide suggests: Don’t do “unsafe” actions in threads -or 2. Only let the thread with ID 0 take unsafe actions 12
Multiple inputs
It’s fairly straightforward to create filter that has multiple inputs we’ll use 2 as an example For additional reference see BinaryFunctorImageFilter 13
Step 1: Define Number of Inputs
In the constructor, set: this->SetNumberOfRequiredInputs( 2 ); 14
Step 2:
Write functions to set inputs 1 and 2, they look something like:
SetInput1( const TInputImage1 * image1 ) { // Process object is not const-correct // so the const casting is required.
SetNthInput(0, const_cast
15
Step 3
Implement GenerateData() or ThreadedGenerateData() Caveat: you now have to deal with input regions for both inputs, or N inputs in the arbitrary case 16
Multiple outputs?
I couldn’t find any examples of multiple output filters Why? ImageToImage filter only defines one output ProcessObject supports multiple outputs You could probably write a filter with N outputs by going back to ProcessObject 17
Progress reporting
A useful tool for keeping track of what your filters are doing In GenerateData or ThreadedGenerateData: ProgressReporter progress(this, threadId, outputRegionForThread.GetNumberOfPixels( )); 18
Progress reporting cont.
progress(this, threadId, outputRegionForThread.GetNumberOfPixels( )); Pointer to the filter ThreadID, or 0 for ST Total pixels or steps (for iterative filters) 19
Progress reporting, cont.
To update progress, each time you successfully complete operations on one pixel (or one iteration), call: progress.CompletedPixel(); 20