ITK Lecture 11 Filters Part II

1. ITK Lecture 11Filters Part II Methods in Image Analysis CMU Robotics Institute 16-725 U. Pitt Bioengineering 2630 Spring Term, 2006 Damion Shelton

2. What are “advanced” filters? • More than one input • Support progress methods • Output image is a different size than input • Multi-threaded

3. 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!

4. 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

5. 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

6. 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

7. 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::GenerateInputRequestedRegion(); • This ensures that the important framework stuff still happens

8. Multi-threaded • Actually relatively simple • Implement ThreadedGenerateData() instead of GenerateData() • A few things look different…

9. 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

10. 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

11. 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

12. ThreadID, cont. • This could cause major problems! • The software guide suggests: • Don’t do “unsafe” actions in threads -or- • Only let the thread with ID 0 take unsafe actions

13. 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

14. Step 1: Define Number of Inputs • In the constructor, set: this->SetNumberOfRequiredInputs( 2 );

15. 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 <TInputImage1 *>( image1 )); }

16. 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

17. 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

18. Progress reporting • A useful tool for keeping track of what your filters are doing • In GenerateData or ThreadedGenerateData: ProgressReporter progress(this, threadId, outputRegionForThread.GetNumberOfPixels());

19. Progress reporting cont. progress(this, threadId, outputRegionForThread.GetNumberOfPixels()); Pointer to the filter ThreadID, or 0 for ST Total pixels or steps (for iterative filters)

20. Progress reporting, cont. • To update progress, each time you successfully complete operations on one pixel (or one iteration), call: • progress.CompletedPixel();