Working in C++ ITK 5.2.1, I have been writing a few filter classes, following the guidance of Chapter 8 (“How To Write A Composite Filter”) of the ITK guide book. I think I have a reasonable grasp of the material.
However, one section of the guide confuses me. On Page 207:
The GenerateData() is where the composite magic happens.
First, connect the first component filter to the inputs of the composite filter (the actual input, supplied
by the upstream stage). At a filter’s GenerateData() stage, the input image’s information and
pixel buffer content have been updated by the pipeline. To prevent the mini-pipeline update from
propagating upstream, the input image is disconnected from the pipeline by grafting its contents to
a new itk::Image pointer.
Specifically the last sentence confuses me. Why should one “disconnect” the input image from upstream? Wouldn’t running the mini-pipeline need to propagate the Update() calls upstream before starting its GenerateData() functions?
With the Composite Filter approach the internal mini-pipeline is isolated from the external pipeline. The CompositeFilter is responsible for regions propagation in GenerateInputRequestedRegions and updating the meta-data output in GenerateOutputInformation ( and other responsibilities ). If the mini-pipeline interacts with the external pipeline via requests through the composite filters input data-object, extra call the the pipeline can occur triggering modified object changes information, and unneeded executions.
The mini-pipeline is just a way to create the output for the composite filter, it should not interact with the external pipeline as the proper phases of the pipeline have already been executed and should not be executed again.
In slightly different words, we don’t want an update arriving at the output of the composite filter to directly trigger an update for the input of the composite filter. Instead we want the update triggers to propagate through the individual components within the composite filter before reaching the composite filter’s input.
If you can suggest changes to the guide book to make this clearer… thanks!
I think I have my question answered. I guess I hadn’t earlier really thought through how the composite filter is doing the Update() propagation as a whole; for example, by deriving from ImageToImageFilter.
Now I do see that one doesn’t need the mini-pipeline to call update on the composite filter input.
On the other hand, since the composite filter input is already updated: would calling an extra Update() cause any actual work? I would have thought that the “is it modified?” logic would have short-circuited the Update call.