# Why should a Composite Filter disconnect its input?

**URL:** <https://discourse.itk.org/t/why-should-a-composite-filter-disconnect-its-input/5410>\
**Category:** Algorithms\
**Tags:** filter\
**Created:** [October 13, 2022, 12:59pm UTC](https://discourse.itk.org/t/why-should-a-composite-filter-disconnect-its-input/5410 "2022-10-13T12:59:04Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![SteveRobbins](https://discourse.itk.org/user_avatar/discourse.itk.org/steverobbins/32/2446_2.png) [@SteveRobbins](https://discourse.itk.org/u/SteveRobbins)\
**Post date:** [October 13, 2022, 12:59pm UTC](https://discourse.itk.org/t/why-should-a-composite-filter-disconnect-its-input/5410/1 "2022-10-13T12:59:04Z")

</div>

Hello,

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?

---

<div class="post-metadata">

**Author:** ![blowekamp](https://discourse.itk.org/user_avatar/discourse.itk.org/blowekamp/32/79_2.png) [@blowekamp](https://discourse.itk.org/u/blowekamp)\
**Post date:** [October 13, 2022, 1:25pm UTC](https://discourse.itk.org/t/why-should-a-composite-filter-disconnect-its-input/5410/2 "2022-10-13T13:25:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Lee\_Newberg](https://discourse.itk.org/user_avatar/discourse.itk.org/lee_newberg/32/1461_2.png) [@Lee\_Newberg](https://discourse.itk.org/u/Lee_Newberg)\
**Post date:** [October 13, 2022, 1:32pm UTC](https://discourse.itk.org/t/why-should-a-composite-filter-disconnect-its-input/5410/3 "2022-10-13T13:32:17Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![SteveRobbins](https://discourse.itk.org/user_avatar/discourse.itk.org/steverobbins/32/2446_2.png) [@SteveRobbins](https://discourse.itk.org/u/SteveRobbins)\
**Post date:** [October 14, 2022, 8:55pm UTC](https://discourse.itk.org/t/why-should-a-composite-filter-disconnect-its-input/5410/4 "2022-10-14T20:55:04Z")

</div>

Thank you Bradley & Lee!

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.