[Insight-developers] Re: [Insight-users] concept checking
inAccumulateImageFilter
Gaetan Lehmann
gaetan.lehmann at jouy.inra.fr
Thu Mar 2 04:32:56 EST 2006
Hi,
I agree that it would be logical to have one dimension less in the output
image, and I'm not using the feature of keeping the same info on the same
dimension number.
Implementing N dims -> N-1 dims is not difficult. What seem difficult is
to implement both N dims -> N dims and N dims -> N-1 dims in the same
filter.
If nobody can say why it is useful, I propose to keep
AccumulateImageFilter as is it is currently, and to implement the N dims
-> N-1 dims algorithm in ProjectionImageFilter (see my article in the
insight journal) which already break the API.
Also, during the projection, there will be an orientation problem we don't
have if we keep the number of dimensions.
________
/ /| /|
/ / | / |
1 /_______/. | 2 /. |
--> | | |<-- | |
| | / | /
| | / | /
|_______|/ |/
On the volume above, the image is projected on the horizontal dimension.
If the number of dimension is not modified, no problem, we create a thin
volume with size=1 on projection dim.
If we reduce the number of dimensions, we have to choose the direction,
and the result will not be the same.
_______
| .|
1 | |
| |
|_______|
_______
|. |
2 | |
| |
|_______|
Gaetan
On Thu, 02 Mar 2006 04:08:16 +0100, Lorensen, William E (GE, Research)
<lorensen at crd.ge.com> wrote:
> We use this filter frequently. I assume this will not be changed before
> the release.
>
> After the release, if we change it to generate n-1 d images, our code
> will no longer compiler, breaking backward compatibility. We need to
> look carefully at this.
>
> Bill
>
> -----Original Message-----
> From: insight-developers-bounces+lorensen=crd.ge.com at itk.org
> [mailto:insight-developers-bounces+lorensen=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
More information about the Insight-developers
mailing list