[Insight-developers] Add a Convolution module under filtering?

Bradley Lowekamp blowekamp at mail.nih.gov
Tue May 31 17:44:59 EDT 2011 

Hello Cory,
 
I am confused what is going to go into this module. There are a lot of existing filters which are discrete convolutions with a specific kernel or an approximations to. Such as Gaussians, Derivatives, Sobel, and Mean image filters. Are you planning on moving filters which perform convolutions or just the new building blocks to perform convolutions?

Currently, the name leads me to a little confusion.

Brad

On May 31, 2011, at 5:28 PM, Cory Quammen wrote:

> On Tue, May 31, 2011 at 4:51 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>> Hi Nick,
>> 
>> 
>> It certainly sounds wise to specify a kernel in terms of radii
>> and to assume that its full size is going to be odd,...for many
>> applications,... but a convolution filter is more general than
>> just for typical 5x5, 7x7 kernel cases.
>> 
>> Note that the user in the mailing list was making a reasonable
>> use of the filter:  He feed the same image as Kernel as an
>> input image, for what would be the equivalent of computing
>> auto-correlation.
>> 
>> When ones tries to compute the auto-correlation of Lena,
>> the question of whether the image has an odd or even
>> number of pixels may not come to mind as the first thing
>> to check, and it doesn't seem to be an acceptable reason
>> for what a use couldn't compute the convolution of two
>> images.
>> 
>> 
>> We shouldn't assume either that the kernels are symmetric,
>> for example.
>> 
>> --
>> 
>> Here are the typical options:
>> 
>> 1) If odd size is required (expected) for the Kernel image,
>>    then the filter should check the input kernel to verify
>>    that its size is odd, and if it is not, it should throw and
>>    Exception explaining that only odd-size kernels can
>>    be used.
>> 
>>    Currently it is going along and producing an incorrect
>>    output without any warning.
>> 
>> 
>> 2) Convolution with an even-size kernel is certainly
>>    possible (from the math point of view).
>> 
>>    It may require to revisit the implementation though...
>> 
>>    The first question then is whether we want the filter
>>    to support such feature or not.
> 
> There should be no size restriction on kernels.
> 
> Additionally, I think the kernel image should be aligned so that the
> zero index of the kernel image is aligned with the current output
> pixel. That way, the user can specify precisely what happens when a
> kernel has an even size in one of the dimensions. An option to
> recenter the image index automatically would be nice, too, and that
> option should probably be on by default.
> 
> I would also like to ensure that the interface between the
> ConvolutionImageFilter and the FFTConvolutionImageFilter from IJ is as
> similar as possible. This potentially includes specifying boundary
> conditions, etc. I'll create a brief proposal tonight or tomorrow and
> share it with the list.
> 
> Cory
> 
>> --
>> 
>> 
>>  Luis
>> 
>> 
>> ---------------------------------------
>> On Tue, May 31, 2011 at 4:34 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
>>> Hi Luis,
>>> 
>>> Did you get my email regarding that bug?  If you didn't, it's unclear to
>>> me what should be done in the case of an even size image kernel
>>> as such a kernel wouldn't be symmetric with respect to a given voxel.
>>> I think there was wisdom in specifying neighborhoods in terms of radii
>>> but that makes the solution a bit unclear.
>>> 
>>> Nick
>>> 
>>> 
>>> 
>>> 
>>> On May 31, 2011, at 4:28 PM, Luis Ibanez wrote:
>>> 
>>>> Hi Cory,
>>>> 
>>>> Before moving the itkConvolutionImageFilter out of Review...
>>>> 
>>>> Did you do a Code Review of this filter using the Check List ?
>>>> http://www.itk.org/Wiki/ITK_Release_4/Modularization/Code_Reviews/Checklist
>>>> 
>>>> 
>>>> Code from the Review directory can't simply be moved to
>>>> final directories without first verifying that it fits ITK coding
>>>> standards.
>>>> 
>>>> In particular :  Code Coverage.
>>>> 
>>>> In many cases this can be code that was copied directly
>>>> from Insight Journal contributions and may or may not
>>>> have passes through a maturation process in the Review
>>>> directory.   (git log could verify how many changes the
>>>> code have experienced while in Review).
>>>> 
>>>> 
>>>> 
>>>> Please note also that a bug was reported in this filter
>>>> during the weekend:
>>>> 
>>>> http://public.kitware.com/Bug/view.php?id=12236
>>>> 
>>>> http://www.itk.org/pipermail/insight-users/2011-May/041307.html
>>>> 
>>>> 
>>>>    Luis
>>>> 
>>>> 
>>>> ---------------------------------------------------
>>>> On Tue, May 31, 2011 at 12:58 PM, Cory Quammen <cquammen at cs.unc.edu> wrote:
>>>>> A patch for this move has been posted:
>>>>> http://review.source.kitware.com/#change,1756
>>>>> 
>>>>> A later patch will include the submission of the FFT based convolution
>>>>> image filter.
>>>>> 
>>>>> Thanks,
>>>>> Cory
>>>>> 
>>>>> On Sun, May 29, 2011 at 8:55 AM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
>>>>>> Hi Cory,
>>>>>> 
>>>>>> The "Filtering" group seems to be the right place
>>>>>> for this new Convolution module.
>>>>>> 
>>>>>> Moving the classes that you mentioned to this
>>>>>> new modules looks very reasonable.
>>>>>> 
>>>>>> 
>>>>>>     Luis
>>>>>> 
>>>>>> 
>>>>>> -------------------------------------------------------------
>>>>>> On Fri, May 27, 2011 at 4:19 PM, Cory Quammen <cquammen at cs.unc.edu> wrote:
>>>>>>> Dear modularization team,
>>>>>>> 
>>>>>>> In preparation for our A2D2 work on deconvolution, I'd like to create
>>>>>>> a new module under Filtering named Convolution.
>>>>>>> 
>>>>>>> Here's my tentative plan:
>>>>>>> - Move itk::ConvolutionImageFilter and associated tests currently in
>>>>>>> Review to the Convolution module.
>>>>>>> - Add Gaetan Lehmann's FFT based convolution image filter from his
>>>>>>> Insight Journal article into this module.
>>>>>>> 
>>>>>>> If there is a better place to put these classes, please let me know.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Cory
>>>>>>> 
>>>>>>> --
>>>>>>> Cory Quammen
>>>>>>> Computer Integrated Systems for Microscopy and Manipulation (CISMM)
>>>>>>> Department of Computer Science
>>>>>>> University of North Carolina at Chapel Hill
>>>>>>> http://www.cs.unc.edu/~cquammen
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Cory Quammen
>>>>> Computer Integrated Systems for Microscopy and Manipulation (CISMM)
>>>>> Department of Computer Science
>>>>> University of North Carolina at Chapel Hill
>>>>> http://www.cs.unc.edu/~cquammen
>>>>> 
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> 
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Kitware offers ITK Training Courses, for more information visit:
>>>> http://kitware.com/products/protraining.html
>>>> 
>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>> 
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Cory Quammen
> Computer Integrated Systems for Microscopy and Manipulation (CISMM)
> Department of Computer Science
> University of North Carolina at Chapel Hill
> http://www.cs.unc.edu/~cquammen
> _______________________________________________
> Powered by www.kitware.com
> 
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
> 
> Kitware offers ITK Training Courses, for more information visit:
> http://kitware.com/products/protraining.html
> 
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
> 
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers

More information about the Insight-developers mailing list