#include <itkImageSource.h>
Inheritance diagram for itk::ImageSource:
Public Types | |
| typedef ImageSource | Self |
| typedef ProcessObject | Superclass |
| typedef SmartPointer< Self > | Pointer |
| typedef SmartPointer< const Self > | ConstPointer |
| typedef DataObject::Pointer | DataObjectPointer |
| typedef TOutputImage | OutputImageType |
| typedef OutputImageType::Pointer | OutputImagePointer |
| typedef OutputImageType::RegionType | OutputImageRegionType |
| typedef OutputImageType::PixelType | OutputImagePixelType |
Public Methods | |
| virtual const char * | GetClassName () const |
| void | SetOutput (OutputImageType *output) |
| virtual void | GraftOutput (OutputImageType *output) |
| virtual void | GraftNthOutput (unsigned int idx, OutputImageType *output) |
| virtual DataObjectPointer | MakeOutput (unsigned int idx) |
| OutputImageType * | GetOutput (void) |
| OutputImageType * | GetOutput (unsigned int idx) |
Protected Methods | |
| ImageSource () | |
| virtual | ~ImageSource () |
| virtual void | GenerateData () |
| virtual void | ThreadedGenerateData (const OutputImageRegionType &outputRegionForThread, int threadId) |
| virtual void | PrepareOutputs () |
| virtual void | AllocateOutputs () |
| virtual void | BeforeThreadedGenerateData () |
| virtual void | AfterThreadedGenerateData () |
| virtual int | SplitRequestedRegion (int i, int num, OutputImageRegionType &splitRegion) |
Static Protected Methods | |
| ITK_THREAD_RETURN_TYPE | ThreaderCallback (void *arg) |
ImageSource is the base class for all process objects that output image data. Specifically, this class defines the GetOutput() method that returns a pointer to the output image. The class also defines some internal private data members that are used to manage streaming of data.
Definition at line 40 of file itkImageSource.h.
|
|||||
|
|||||
|
Smart Pointer type to a DataObject. Reimplemented from itk::ProcessObject. Reimplemented in itk::StreamingImageFilter< TInputImage, TOutputImage >. Definition at line 50 of file itkImageSource.h. |
|
|||||
|
|||||
|
|||||
|
|||||
|
|||||
|
|||||
|
|||||
|
|||||||||
|
|
|
|||||||||
|
Definition at line 172 of file itkImageSource.h. |
|
|||||||||
|
If an imaging filter needs to perform processing after all processing threads have completed, the filter can can provide an implementation for AfterThreadedGenerateData(). The execution flow in the default GenerateData() method will be: 1) Allocate the output buffer 2) Call BeforeThreadedGenerateData() 3) Spawn threads, calling ThreadedGenerateData() in each thread. 4) Call AfterThreadedGenerateData() Note that this flow of control is only available if a filter provides a ThreadedGenerateData() method and NOT a GenerateData() method. Reimplemented in itk::DirectedHausdorffDistanceImageFilter< TInputImage1, TInputImage2 >, itk::InterpolateImageFilter< TInputImage, TOutputImage >, itk::ShiftScaleImageFilter< TInputImage, TOutputImage >, itk::SimilarityIndexImageFilter< TInputImage1, TInputImage2 >, itk::StatisticsImageFilter< TInputImage >, and itk::DifferenceImageFilter< TInputImage, TOutputImage >. Definition at line 254 of file itkImageSource.h. |
|
|||||||||
|
The GenerateData method normally allocates the buffers for all of the outputs of a filter. Some filters may want to override this default behavior. For example, a filter may have multiple outputs with varying resolution. Or a filter may want to process data in place by grafting its input to its output. Reimplemented in itk::DirectedHausdorffDistanceImageFilter< TInputImage1, TInputImage2 >, itk::HausdorffDistanceImageFilter< TInputImage1, TInputImage2 >, itk::SimilarityIndexImageFilter< TInputImage1, TInputImage2 >, and itk::StatisticsImageFilter< TInputImage >. |
|
||||||||||
|
|||||||||
|
|||||||||
|
||||||||||
|
Get the output data of this process object. The output of this function is not valid until an appropriate Update() method has been called, either explicitly or implicitly. Both the filter itself and the data object have Update() methods, and both methods update the data. Here are three ways to use GetOutput() and make sure the data is valid. In these examples, image is a pointer to some Image object, and the particular ProcessObjects involved are filters. The same examples apply to non-image (e.g. Mesh) data as well.
anotherFilter->SetInput( someFilter->GetOutput() ); anotherFilter->Update(); In this situation, someFilter and anotherFilter are said to constitute a pipeline.
image = someFilter->GetOutput(); image->Update();
someFilter->Update(); image = someFilter->GetOutput(); Note that Update() is not called automatically except within a pipeline as in the first example. When streaming (using a StreamingImageFilter) is activated, it may be more efficient to use a pipeline than to call Update() once for each filter in turn. For an image, the data generated is for the requested Region, which can be set using ImageBase::SetRequestedRegion(). By default, the largest possible region is requested. Reimplemented from itk::ProcessObject. |
|
||||||||||
|
Get the output data of this process object. The output of this function is not valid until an appropriate Update() method has been called, either explicitly or implicitly. Both the filter itself and the data object have Update() methods, and both methods update the data. Here are three ways to use GetOutput() and make sure the data is valid. In these examples, image is a pointer to some Image object, and the particular ProcessObjects involved are filters. The same examples apply to non-image (e.g. Mesh) data as well.
anotherFilter->SetInput( someFilter->GetOutput() ); anotherFilter->Update(); In this situation, someFilter and anotherFilter are said to constitute a pipeline.
image = someFilter->GetOutput(); image->Update();
someFilter->Update(); image = someFilter->GetOutput(); Note that Update() is not called automatically except within a pipeline as in the first example. When streaming (using a StreamingImageFilter) is activated, it may be more efficient to use a pipeline than to call Update() once for each filter in turn. For an image, the data generated is for the requested Region, which can be set using ImageBase::SetRequestedRegion(). By default, the largest possible region is requested. |
|
||||||||||||||||
|
Graft the specified data object onto this ProcessObject's idx'th output. This is the similar to GraftOutput method except is allows you specify which output is affected. The specified index must be a valid output number (less than ProcessObject::GetNumberOfOutputs()). See the GraftOutput for general usage information. |
|
||||||||||
|
Graft the specified DataObject onto this ProcessObject's output. This method grabs a handle to the specified DataObject's bulk data to used as its output's own bulk data. It also copies the region ivars (RequestedRegion, BufferedRegion, LargestPossibleRegion) and meta-data (Spacing, Origin) from the specified data object into this filter's output data object. Most importantly, however, it leaves the Source ivar untouched so the original pipeline routing is intact. This method is used when a process object is implemented using a mini-pipeline which is defined in its GenerateData() method. The usage is:
// setup the mini-pipeline to process the input to this filter
firstFilterInMiniPipeline->SetInput( this->GetInput() );
// setup the mini-pipeline to calculate the correct regions
// and write to the appropriate bulk data block
lastFilterInMiniPipeline->GraftOutput( this->GetOutput() );
// execute the mini-pipeline
lastFilterInMiniPipeline->Update();
// graft the mini-pipeline output back onto this filter's output.
// this is needed to get the appropriate regions passed back.
this->GraftOutput( lastFilterInMiniPipeline->GetOutput() );
For proper pipeline execution, a filter using a mini-pipeline must implement the GenerateInputRequestedRegion(), GenerateOutputRequestedRegion(), GenerateOutputInformation() and EnlargeOutputRequestedRegion() methods as necessary to reflect how the mini-pipeline will execute (in other words, the outer filter's pipeline mechanism must be consistent with what the mini-pipeline will do). |
|
||||||||||
|
Make a DataObject of the correct type to used as the specified output. Every ProcessObject subclass must be able to create a DataObject that can be used as a specified output. This method is automatically called when DataObject::DisconnectPipeline() is called. DataObject::DisconnectPipeline, disconnects a data object from being an output of its current source. When the data object is disconnected, the ProcessObject needs to construct a replacement output data object so that the ProcessObject is in a valid state. So DataObject::DisconnectPipeline eventually calls ProcessObject::MakeOutput. Note that MakeOutput always returns a SmartPointer to a DataObject. If a subclass of ImageSource has multiple outputs of different types, then that class must provide an implementation of MakeOutput(). Reimplemented from itk::ProcessObject. Reimplemented in itk::EigenAnalysis2DImageFilter< TInputImage, TEigenValueImage, TEigenVectorImage >. |
|
|||||||||
|
This method is intentionally left blank. ImageSource's need not Initialize their containers. The Image::Allocate() method (called from GenerateData()) will resize the container if more memory is needed. Otherwise, the memory can be reused. Reimplemented from itk::ProcessObject. Definition at line 223 of file itkImageSource.h. |
|
||||||||||
|
Set the image output of this process object. This call is slated to be removed from ITK. You should GraftOutput() and possible DataObject::DisconnectPipeline() to properly change the output. |
|
||||||||||||||||||||
|
Split the output's RequestedRegion into "num" pieces, returning region "i" as "splitRegion". This method is called "num" times. The regions must not overlap. The method returns the number of pieces that the routine is capable of splitting the output RequestedRegion, i.e. return value is less than or equal to "num". |
|
||||||||||||||||
|
||||||||||
|
Static function used as a "callback" by the MultiThreader. The threading library will call this routine for each thread, which will delegate the control to ThreadedGenerateData(). |
1.2.15 written by Dimitri van Heesch,
© 1997-2000