Hello,<br><br>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.
<br><br>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.
<br><br>I can provide sample code if necessary, but I'd need to extract it from a larger project.<br><br>Casey Goodlett<br><br><div><span class="gmail_quote">On 3/1/06, <b class="gmail_sendername">Luis Ibanez</b> <<a href="mailto:luis.ibanez@kitware.com">
luis.ibanez@kitware.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>Hi Gaetan,<br><br>We agree with you that according to the Doxygen documentation
<br>of the filter, the dimensions of the input image and the output<br>image should be the same.<br><br><br>However, what is a stake here is the conceptual correctness<br>of the filter. (we can fix the Doxygen documentation accordingly).
<br><br><br><br>Since the filter is integrating an image across one dimension,<br>it is equivalent to computing the integral of a function of<br>N-variables along a range of one of those N variables.<br><br><br>Something like:
<br><br><br> Sum{ F(x,y,z) } from Z=-inf to Z=inf<br><br><br>which we would expect to become a function of the remaining<br>variables,<br><br><br>something like<br><br><br> G(x,y).<br><br><br>If you take a CT scan and integrate the values along the Z
<br>direction, conceptually this is close to generating a DRR<br>(an X-Ray) of that 3D CT image, and therefore it seems<br>reasonable to expect that output image to be a 2D image.<br><br><br>Expecting the integral of a 3D function to be a 3D degenerate
<br>function (a 3D image of 1 slice) is a dangerous approach, because<br>then filters that are applied to the accumulated image will<br>assume that is a 3D image. For example a gradient will not work<br>properly on the accumulated image.
<br><br><br><br>I don't see any difficulty on writing the code for a (N) to (N-1)<br>dimensional image. We only need a linear iterator, and a while loop.<br>The GenerateData method shouldn't require more than 50 lines of code.
<br><br><br><br>Have you used this filter ?<br><br><br>Could you post some of the cases for which you use this filter ?<br><br><br><br>That could help us to understand if the output should be a<br>N-dimensional or an (N-1)-dimensional image.
<br><br><br><br> Please let us know,<br><br><br><br> Thanks<br><br><br><br> Luis<br><br><br><br>--------------------<br>Gaetan Lehmann wrote:<br>> Hi,<br>><br>> The check is correct. The output is an image of the same dimension to keep the
<br>> info of the output image on the same dimension (the docstring is surely a lot<br>> more clear than me).<br>> I don't think it will work if you try to build it with a dim=3 in input and<br>> dim=2 in output.
<br>> It would be nice to be able to set the dim=3 or dim=2 in output, but the code<br>> will surely be difficult to write.<br>><br>> Gaetan<br>><br>><br>> On Wednesday 01 March 2006 21:04, Amy Squillacote wrote:
<br>><br>>>Hi all,<br>>><br>>>There is currently a check in the header file of the<br>>>AccumulateImageFilter (in Code/BasicFilters) for whether the input<br>>>and output images have the same dimension. Another ITK developer
<br>>>pointed out to me a couple days ago that this concept check is<br>>>probably wrong. He suggested that the dimension of the output should<br>>>actually be one less than that of the input. Luis and I discussed
<br>>>this earlier today, and we believe that the output's dimension should<br>>>be one less than that of the input. However, if we make this change,<br>>>anyone's code depending on the input and output to have the same
<br>>>dimensionality would break.<br>>><br>>>What has been the experience of other people using this filter? What<br>>>is your opinion about the dimensionality of the input and output of<br>>>this filter?
<br>>><br>>>- Amy<br>>><br>>>_______________________________________________<br>>>Insight-users mailing list<br>>><a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>>>
<a href="http://www.itk.org/mailman/listinfo/insight-users">http://www.itk.org/mailman/listinfo/insight-users</a><br>>><br>>><br>>>------------------------------------------------------------------------
<br>>><br>>>_______________________________________________<br>>>Insight-users mailing list<br>>><a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>>><a href="http://www.itk.org/mailman/listinfo/insight-users">
http://www.itk.org/mailman/listinfo/insight-users</a><br><br>_______________________________________________<br>Insight-developers mailing list<br><a href="mailto:Insight-developers@itk.org">Insight-developers@itk.org</a>
<br><a href="http://www.itk.org/mailman/listinfo/insight-developers">http://www.itk.org/mailman/listinfo/insight-developers</a><br></blockquote></div><br>