[Insight-developers] Re: [Insight-users] concept checking
inAccumulateImageFilter
Gaëtan Lehmann
gaetan.lehmann at jouy.inra.fr
Tue Dec 5 02:44:54 EST 2006
Hi Todd,
I can't remember how AccumulateImageFilter works with other dimensions
than the last one.
I'm now only using the subclasses of ProjectionImageFilter. I can say that
those filters work for all the dimensions.
http://insight-journal.org/dspace/handle/1926/164
Gaetan
Le Tue, 05 Dec 2006 00:43:39 +0100, Gable, Todd (GE Indust, Security)
<Todd.Gable at ge.com> a écrit:
> Is the AccumulateImageFilter filter supposed to work in any of the N
> dimensions? I see the SetAccumulateDimension() method, but any dimension
> other than the last (2 in the 3D case) seems to just crash (does not
> throw an exception) for me. My code looks essentially like this:
>
>
> reader->SetFileName(argv[1]);
> reader->Update();
> typedef itk::AccumulateImageFilter <InImageType, OutImageType>
> AccumulateType;
> AccumulateType::Pointer accum = AccumulateType::New();
> accum->SetInput(reader->GetOutput());
> accum->SetAverage(true);
> accum->SetAccumulateDimension(2);
> accum->Update();
>
> Thanks,
>
> Todd
>
>
>
> -----Original Message-----
> From: insight-users-bounces+todd.gable=ge.com at itk.org
> [mailto:insight-users-bounces+todd.gable=ge.com at itk.org]On Behalf Of
> Gaetan Lehmann
> Sent: Thursday, March 16, 2006 1:22 AM
> To: Alberto Bert; insight-users at itk.org
> Cc: insight-users at itk.org
> Subject: Re: [Insight-developers] Re: [Insight-users] concept checking
> inAccumulateImageFilter
>
>
>
> Hi,
>
> The code is modified - are perhaps I should say rewritten at this point -
> and now accept both N and N-1 dimensions for output image.
> Please, look at
> http://insight-journal.org/view_reviews.php?back=publications.php%3Fjournalid%3D4%26order%3D%26revision_display%3D&pubid=71
> .
> It would also be nice if you can test the code, and post a review.
>
> Regards,
>
> Gaetan
>
>
> On Thu, 16 Mar 2006 03:02:36 +0100, Alberto Bert <bert at isi.it> wrote:
>
>> 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
>> _______________________________________________
>> Insight-users mailing list
>> Insight-users at itk.org
>> http://www.itk.org/mailman/listinfo/insight-users
>
>
>
--
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-users
mailing list