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

[Gaetan Lehmann]

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