[Insight-developers] Re: [Insight-users] concept checking inAccumulateImageFilter

[Miller, James V (GE, Research)]

(I am going to answer in the middle of this thread just because there
is some nomenclature here that is useful)

The AccumulateImageFilter requires the output to be the same dimension
as the input. So an NxMxP volume acculumated along the first dimension
becomes a 1xMxP volume that sits in the same coordinate frame as the
original data.  

So instead of saying the filter calculates

G(x,y) = Sum_z( F(x,y,z) )

it really does

G(x,y,z=z0) = Sum_z( F(x,y,z) )

or 

G(x=x0, y, z) = Sum_x( F(x, y, z) )

As Gaetan points out in a later email, if the accumulation results in an 
image that has dimension N-1, then the image may have to be reoriented
if it is the accumulated direction is not the last direction. So 
accumulating over X, will produce a (Y,Z) image.  Accumulating over
Y will produce a (X, Z) image.  This could be done after the 
AccumulateImageFilter with a Permute and a CastImageFilter (to knock the 
dimension down).

Putting this logic into the AccumulateImageFilter shouldn't impact 
backward compatibility as long the AccumulateImageFilter can produce
a ND image OR an (N-1)D image (spec'd by the template parameters).  The
concept checking would be more difficult because you have to check whether
the dimensions are the same or the output is one dimension less.  Still
sounds doable.

Much of the logic to switch dimensions is already in the 
ExtractImageFilter.  It gets pretty complicated. Particularly in mapping
the Requested/LargestPossible regions through the pipeline. A short putt may be
to use an ExtractImageFilter internally to the AccumulateImageFilter
when needed.

Jim



-----Original Message-----
From: insight-developers-bounces+millerjv=crd.ge.com at itk.org
[mailto:insight-developers-bounces+millerjv=crd.ge.com at itk.org]On Behalf
Of Luis Ibanez
Sent: Wednesday, March 01, 2006 4:08 PM
To: Gaetan Lehmann
Cc: insight-users at itk.org; insight-developers at itk.org
Subject: [Insight-developers] Re: [Insight-users] concept checking
inAccumulateImageFilter



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