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

Thu Mar 2 11:39:29 EST 2006

After sending the 2 mails this morning, I have a look at implementing both  
the N->N-1 and the N->N features in ProjectionImageFilter. The code is  
nearly ready, but test if InputImageDimension equals OutputImageDimension  
at runtime, while I would be able to do it at build time - perhaps the  
compiler drop the useless part of the code depending on the situation.
That said, it should have only a very small impact on execution time.

On Thu, 02 Mar 2006 14:34:29 +0100, Miller, James V (GE, Research)  
<millerjv at crd.ge.com> wrote:

> (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

-- 
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