[Insight-developers] Re: [Insight-users] concept checking in
AccumulateImageFilter
Alberto Bert
bert at isi.it
Wed Mar 15 21:02:36 EST 2006
Hi,
I'm one of the people that is using that filter and as Luis poited
out, it would be resonable to have a N-1 output image dimension.
Right now, I'm just casting the output to reduce the dimension.
Are you gus planning to change the code or not?
Cheers
Alberto
On Mar 02, 2006 at 11:22:01AM +0100, Gaetan Lehmann wrote:
>
> Hi,
>
> I have checked the AccumulateImageFilter code, and reduce a dimension will
> work properly only if the dimension is the last one.
>
> The wanted behavior is, I think, the following one: the dimension which is
> removed must take the place of the projection dimension.
>
> For example, for 3D -> 2D:
> . projection dim=0
> 1->1
> 2->0
> . projection dim=1
> 0->0
> 2->1
> . projection dim=2
> 0->0
> 1->1
> in that case, there is nothing special: the projected dimension is the
> removed one
>
> AccumulateImageFilter do not take care of that, and so, for 3D to 2D, only
> the projection on the dimension 2 will work properly.
>
> Gaetan
>
>
>
> On Thu, 02 Mar 2006 01:46:37 +0100, Casey Goodlett <gcasey at gmail.com>
> wrote:
>
> >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
> >>
>
>
>
> --
> 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
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
More information about the Insight-users
mailing list