Allow people to add/remove/invoke observers (callbacks) to any ITK object. This is an implementation of the subject/observer design pattern. An observer is added by specifying an event to respond to and an itk::Command to execute. It returns an unsigned long tag which can be used later to remove the event or retrieve the command. The memory for the Command becomes the responsibility of this object, so don't pass the same instance of a command to two different objects

This method is called when itkExceptionMacro executes. It allows the debugger to break on error.

virtual void itk::ProcessObject::CacheInputReleaseDataFlags

(

)

[protected, virtual, inherited]

Cache the state of any ReleaseDataFlag's on the inputs. While the filter is executing, we need to set the ReleaseDataFlag's on the inputs to false in case the current filter is implemented using a mini-pipeline (which will try to release the inputs). After the filter finishes, we restore the state of the ReleaseDataFlag's before the call to ReleaseInputs().

Create an object from an instance, potentially deferring to a factory. This method allows you to create an instance of an object that is exactly the same type as the referring object. This is useful in cases where an object has been cast back to a base class.

Give the process object a chance to indictate that it will produce more output than it was requested to produce. For example, many imaging filters must compute the entire output at once or can only produce output in complete slices. Such filters cannot handle smaller requested regions. These filters must provide an implementation of this method, setting the output requested region to the size they will produce. By default, a process object does not modify the size of the output requested region.

Requested region of Mesh is specified as i of N unstructured regions. Since all DataObjects should be able to set the requested region in unstructured form, just copy output->RequestedRegion all inputs.

Generate the information decribing the output data. The default implementation of this method will copy information from the input to the output. A filter may override this method if its output will have different information than its input. For instance, a filter that shrinks an image will need to provide an implementation for this method that changes the spacing of the pixels. Such filters should call their superclass' implementation of this method prior to changing the information values they need (i.e. GenerateOutputInformation() should call Superclass::GenerateOutputInformation() prior to changing the information.

Given one output whose requested region has been set, how should the requested regions for the remaining outputs of the process object be set? By default, all the outputs are set to the same requested region. If a filter needs to produce different requested regions for each output, for instance an image processing filter producing several outputs at different resolutions, then that filter may override this method and set the requested regions appropriatedly.

Note that a filter producing multiple outputs of different types is required to override this method. The default implementation can only correctly handle multiple outputs of the same type.

Get the command associated with the given tag. NOTE: This returns a pointer to a Command, but it is safe to asign this to a Command::Pointer. Since Command inherits from LightObject, at this point in the code, only a pointer or a reference to the Command can be used.

Get the size of the input vector. This is merely the size of the input vector, not the number of inputs that have valid DataObject's assigned. Use GetNumberOfValidRequiredInputs() to determine how many inputs are non-null.

Get the number of valid inputs. This is the number of non-null entries in the input vector in the first NumberOfRequiredInputs slots. This method is used to determine whether the necessary required inputs have been set. Subclasses of ProcessObject may override this implementation if the required inputs are not the first slots in input vector.

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() );

Methods invoked by Print() to print information about the object including superclasses. Typically not called by the user (use Print() instead) but used in the hierarchical print process to combine the output of several classes.

Push/Pop an input of this process object. These methods allow a filter to model its input vector as a queue or stack. These routines may not be appropriate for all filters, especially filters with different types of inputs. These routines follow the semantics of STL.

A filter may need to release its input's bulk data after it has finished calculating a new output. The filter may need to release the inputs because the user has turned on the ReleaseDataFlag or it may need to release the inputs because the filter is an "in place" filter and it has overwritten its input with its output data. The implementation here simply checks the ReleaseDataFlag of the inputs. InPlaceImageFilter overrides this method so release the input it has overwritten.

Set the execution progress of a process object. The progress is a floating number in [0,1] with 0 meaning no progress and 1 meaning the filter has completed execution. The ProgressEvent is NOT invoked.

Turn on/off the flags to control whether the bulk data belonging to the outputs of this ProcessObject are released/reallocated during an Update(). In limited memory scenarios, a user may want to force the elements of a pipeline to release any bulk data that is going to be regenerated anyway during an Update() in order to control peak memory allocation. Note that this flag is different from the ReleaseDataFlag. ReleaseDataFlag manages the deallocation of a ProcessObject's bulk output data once that data has been consumed by a downstream ProcessObject. The ReleaseDataBeforeUpdateFlag manages the deallocation/reallocation of bulk data during a pipeline update to control peak memory utilization. Default value is on.

virtual void itk::ProcessObject::SetReleaseDataFlag

(

bool

flag

)

[virtual, inherited]

Turn on/off the flags to control whether the bulk data belonging to the outputs of this ProcessObject are released after being used by a downstream ProcessObject. Default value is off. Another options for controlling memory utilization is the ReleaseDataBeforeUpdateFlag.

Bring this filter up-to-date. Update() checks modified times against last execution times, and re-executes objects if necessary. A side effect of this method is that the whole pipeline may execute in order to bring this filter up-to-date. This method updates the currently prescribed requested region. If no requested region has been set on the output, then the requested region will be set to the largest possible region. Once the requested region is set, Update() will make sure the specified requested region is up-to-date. This is a confusing side effect to users who are just calling Update() on a filter. A first call to Update() will cause the largest possible region to be updated. A second call to Update() will update that same region. If a modification to the upstream pipeline cause a filter to have a different largest possible region, this second call to Update() will not cause the output requested region to be reset to the new largest possible region. Instead, the output requested region will be the same as the last time Update() was called. To have a filter always to produce its largest possible region, users should call UpdateLargestPossibleRegion() instead.

Like Update(), but sets the output requested region to the largest possible region for the output. This is the method users should call if they want the entire dataset to be processed. If a user wants to update the same output region as a previous call to Update() or a previous call to UpdateLargestPossibleRegion(), then they should call the method Update().

Update the information decribing the output data. This method transverses up the pipeline gathering modified time information. On the way back down the pipeline, this method calls GenerateOutputInformation() to set any necessary information about the output data objects. For instance, a filter that shrinks an image will need to provide an implementation for GenerateOutputInformation() that changes the spacing of the pixels. Such filters should call their superclass' implementation of GenerateOutputInformation prior to changing the information values they need (i.e. GenerateOutputInformation() should call Superclass::GenerateOutputInformation() prior to changing the information.