# About introducing ImageLists

**URL:** <https://discourse.itk.org/t/about-introducing-imagelists/1365>\
**Category:** Community\
**Created:** [October 23, 2018, 12:47am UTC](https://discourse.itk.org/t/about-introducing-imagelists/1365 "2018-10-23T00:47:18Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![phcerdan](https://discourse.itk.org/user_avatar/discourse.itk.org/phcerdan/32/286_2.png) [@phcerdan](https://discourse.itk.org/u/phcerdan)\
**Post date:** [October 23, 2018, 12:47am UTC](https://discourse.itk.org/t/about-introducing-imagelists/1365/1 "2018-10-23T00:47:18Z")

</div>

After dealing with image pyramids which generate a list of images, and the inverse filters which get a list of inputs and generate an output. I was wondering if we could introduce a base class similar to how ImageToImageFilter works, but in this case ImageToImageListFilter, or ImageListToImage.  
[OrfeoToolBox has the ObjectList module](https://github.com/orfeotoolbox/OTB/tree/b3e93bf9dd37ef770f8abaa70db587c4a48ac688/Modules/Core/ObjectList/include) doing exactly this, and seems like a good idea.

I wonder what is your opinion of introducing it into ITK. In my use case, it would be nice to have a Pyramid base class, where all the metadata, and output information of the list of images is abstracted away. What do you think?

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [October 23, 2018, 3:42pm UTC](https://discourse.itk.org/t/about-introducing-imagelists/1365/2 "2018-10-23T15:42:09Z")

</div>

@phcerdan awesome idea 💡 !

In my experience, image pyramids commonly need support, and explicit support for their characteristics could help us perform multi-resolution processing and processing of very large images.

Ideally, we would have a new data structure, `itk::ImagePyramid`. And corresponding to this data structure would be filters, `itk::ImageToImagePyramid`, `itk::ImagePyramidToImagePyramid`, and `itk::ImagePyramidToImage` that would generate the desired outputs by default and facilitate streaming over the pyramid.

---

<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 23, 2018, 3:49pm UTC](https://discourse.itk.org/t/about-introducing-imagelists/1365/3 "2018-10-23T15:49:51Z")

</div>

I would think that an ImageList class may be parent of a more specific ImagePyramid class. I see use in representing a large number of channels as an ImageList instead of a VectorImage. Then having a meta-filter which execute another filter or mini-pipeline on each image in the list ( or image in the pyramid ).

This sounds like a great effort to start in a remote module!

---

<div class="post-metadata">

**Author:** ![jhlegarreta](https://discourse.itk.org/user_avatar/discourse.itk.org/jhlegarreta/32/476_2.png) [@jhlegarreta](https://discourse.itk.org/u/jhlegarreta)\
**Post date:** [October 23, 2018, 11:14pm UTC](https://discourse.itk.org/t/about-introducing-imagelists/1365/4 "2018-10-23T23:14:40Z")

</div>

Looks a great idea.

As for the naming, I’d say that `Pyramid` conveys the idea of multi-resolution whereas `ImageList` does not, so as Brad says, may be the latter can be the parent of the former.