[Insight-developers] itkChannelByChannelVectorImageFilter

[Gaëtan Lehmann]

Le 5 mai 11 à 19:30, David Doria a écrit :

> Hi all,
>
> I was thinking about this some more (as I need this a LOT) - I don't  
> understand why it is so complicated (there are 10 required classes  
> in ORFEO).
>
> What about something like this:
>
> https://github.com/daviddoria/itkChannelByChannelVectorImageFilter
>
> It simply uses itkVectorIndexSelectionCastImageFilter to decompose  
> the vector image and then itkImageToVectorImageFilter to reassemble  
> it.
>
> Thoughts?
>
> David


Hi David,

After the development of the SliceBySliceImageFilter, I began to work  
on this kind of filter some time ago - filter of filters.

   http://mima2.jouy.inra.fr/darcs/contrib-itk/fof/

As you can see, it is in very very early stage of development :-)

I think that we should define what we exactly want of those filters.  
Here are a few thoughts I had at that time.

There are several use cases where we want to run a filter or a  
pipeline of filters on an image repetitively:

   a. apply a transform on each slice

       SliceBySliceImageFilter

   b. apply a transform on each channel

       ChannelByChannelImageFilter

   c. make streamable a non streamable transform by approximating the  
result

       ApproximateStreamedImageFilter

   d. make multithreaded a non multithreaded transform by  
approximating the result

       ApproximateThreadedImageFilter

   e. apply a filter iteratively

       IterativeImageFilter

   f. make a non separable transform separable by approximating the  
result

       SeparableImageFilter

And probably others...

a. and b. are quite similar in the principle, but different in the  
implementation because of ITK API.
c. and d. are also quite similar, but again different in the  
implementation because of the API.

To make those filters convenient to use, including in other languages  
than C++, I think it is important to:

   1. make them able to run a pipeline and not only a single filter
   2. make them able to take different kind of inner filters/pipeline  
at run time
   3. make easy to change the parameters on the inner filters

and to make them efficient, especially for non multithreaded filters,  
those filters should

   4. be able to instantiate several inner filters to speed up the  
execution
   5. make them able to run a pipeline and not only a single filter  
(ok, this is 1. again)

Unfortunately, I don't think that we can implement 1, 2, 3 and 4 in a  
single filter with what is currently available in ITK, because we  
don't have any way to duplicate a filter with it's parameters. If the  
inner filter is instantiated by the filter, then it's parameter can't  
be (easily) changed.
So I think that we would need two implementations for most of those  
filters (not sure about the name):

       SliceBySliceImageFilter
       GenericSliceBySliceImageFilter

       ChannelByChannelImageFilter
       GenericChannelByChannelImageFilter

       ApproximateStreamedImageFilter
       GenericApproximateStreamedImageFilter

       ApproximateThreadedImageFilter -- this one would require to  
pass one inner filter per thread
       GenericApproximateThreadedImageFilter

       IterativeImageFilter
       GenericIterativeImageFilter

       SeparableImageFilter
       GenericSeparableImageFilter

The Generic version would take the filter type as template parameter,  
like the channel by channel filter you have implemented. The generic  
version is more useful as a superclass -- the subclass would pass the  
required parameters to the inner filters.
The other version would take an ImageToImageFilter as input, and it  
would be able to get it at run time.

What do you think?

Le 5 mai 11 à 19:47, David Doria a écrit :

> On Thu, May 5, 2011 at 1:44 PM, Julien Malik <julien.malik at c-s.fr>  
> wrote:
> Hello,
>
> Seeing the Update() inside GenerateData() makes me think your filter  
> is not streamable.
> Am I wrong ?
>
> Julien
>
> I don't know anything about streaming, so I can't really comment :)
>
> If the problem is the Update() calls on each Filter, we could make a  
> std::vector<Filter> and hook them all up. Would that help? I think  
> you'd still have to call update though before the Graft() at the  
> end, right?
>
> David

This is not easy to make a filter which can stream and which work in  
all the cases. The problem is that some filters, like  
MedianImageFilter, are requesting more input than they are producing  
output.
The safest approach is to make the filter require all the input, but  
of course in that case it can't stream at all.

Gaëtan

-- 
Gaëtan Lehmann
Biologie du Développement et de la Reproduction
INRA de Jouy-en-Josas (France)
tel: +33 1 34 65 29 66    fax: 01 34 65 29 09
http://voxel.jouy.inra.fr  http://www.itk.org
http://www.mandriva.org  http://www.bepo.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 203 bytes
Desc: Ceci est une signature ?lectronique PGP
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110510/397fbf1d/attachment.pgp>