[Insight-developers] Re: [Insight-users] concept checking in AccumulateImageFilter

[Casey Goodlett]

Hello,

I was the person who initially reported this difficulty to Amy.  I have
existing code that uses the AccumulateImageFilter to find the mean of
several volumes stacked into a 4D dataset from the TileImageFilter.  I have
several 3D vector image volumes which I stack into a 4D volume using
TileImageFilter, and then I use the accumulate filter to find the mean 3D
volume.  Requiring the mean image to remain in 4D requires the headache of
further processing to reduce it to a 3D volume.  The AccumulateFilter
already works for me in going from ND to (N-1)D so there are no code changes
required.

Can the concept check allow either the same dimension or one less, because
people may already be using either of these conventions?  I dont think
enforcing either one exclusively is a good idea in terms of backwards
compatibility.

I can provide sample code if necessary, but I'd need to extract it from a
larger project.

Casey Goodlett

On 3/1/06, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>
>
> Hi Gaetan,
>
> We agree with you that according to the Doxygen documentation
> of the filter, the dimensions of the input image and the output
> image should be the same.
>
>
> However, what is a stake here is the conceptual correctness
> of the filter. (we can fix the Doxygen documentation accordingly).
>
>
>
> Since the filter is integrating an image across one dimension,
> it is equivalent to computing the integral of a function of
> N-variables along a range of one of those N variables.
>
>
> Something like:
>
>
>           Sum{ F(x,y,z) }    from Z=-inf to Z=inf
>
>
> which we would expect to become a function of the remaining
> variables,
>
>
> something like
>
>
>           G(x,y).
>
>
> If you take a CT scan and integrate the values along the Z
> direction, conceptually this is close to generating a DRR
> (an X-Ray) of that 3D CT image, and therefore it seems
> reasonable to expect that output image to be a 2D image.
>
>
> Expecting the integral of a 3D function to be a 3D degenerate
> function (a 3D image of 1 slice) is a dangerous approach, because
> then filters that are applied to the accumulated image will
> assume that is a 3D image. For example a gradient will not work
> properly on the accumulated image.
>
>
>
> I don't see any difficulty on writing the code for a (N) to (N-1)
> dimensional image. We only need a linear iterator, and a while loop.
> The GenerateData method shouldn't require more than 50 lines of code.
>
>
>
> Have you used this filter ?
>
>
> Could you post some of the cases for which you use this filter ?
>
>
>
> That could help us to understand if the output should be a
> N-dimensional or an (N-1)-dimensional image.
>
>
>
>     Please let us know,
>
>
>
>         Thanks
>
>
>
>            Luis
>
>
>
> --------------------
> Gaetan Lehmann wrote:
> > Hi,
> >
> > The check is correct. The output is an image of the same dimension to
> keep the
> > info of the output image on the same dimension (the docstring is surely
> a lot
> > more clear than me).
> > I don't think it will work if you try to build it with a dim=3 in input
> and
> > dim=2 in output.
> > It would be nice to be able to set the dim=3 or dim=2 in output, but the
> code
> > will surely be difficult to write.
> >
> > Gaetan
> >
> >
> > On Wednesday 01 March 2006 21:04, Amy Squillacote wrote:
> >
> >>Hi all,
> >>
> >>There is currently a check in the header file of the
> >>AccumulateImageFilter (in Code/BasicFilters) for whether the input
> >>and output images have the same dimension.  Another ITK developer
> >>pointed out to me a couple days ago that this concept check is
> >>probably wrong.  He suggested that the dimension of the output should
> >>actually be one less than that of the input.  Luis and I discussed
> >>this earlier today, and we believe that the output's dimension should
> >>be one less than that of the input.  However, if we make this change,
> >>anyone's code depending on the input and output to have the same
> >>dimensionality would break.
> >>
> >>What has been the experience of other people using this filter?  What
> >>is your opinion about the dimensionality of the input and output of
> >>this filter?
> >>
> >>- Amy
> >>
> >>_______________________________________________
> >>Insight-users mailing list
> >>Insight-users at itk.org
> >>http://www.itk.org/mailman/listinfo/insight-users
> >>
> >>
> >>------------------------------------------------------------------------
> >>
> >>_______________________________________________
> >>Insight-users mailing list
> >>Insight-users at itk.org
> >>http://www.itk.org/mailman/listinfo/insight-users
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/insight-users/attachments/20060301/2bb139b3/attachment.html