[Insight-developers] Default boundary condition for WindowedSinc as constant?

Bradley Lowekamp blowekamp at mail.nih.gov
Thu Dec 20 08:30:19 EST 2012


Paul,

Thanks for the information.

What sigma and alpha parameters do you use for the GaussianInterpolator? The frequently used 1*spacing for sigma, and even .8*spacing seem to give a rather soft image after sampling. Do very the parameters based on you task?

I will go ahead and make a patch which changes the default boundary condition for the interpolator.

Thanks,
Brad


On Dec 19, 2012, at 3:55 PM, Paul Yushkevich <pauly2 at mail.med.upenn.edu> wrote:

> Hi Brad,
> 
> I think you are right, the default BC should be changed to use the zero flux. And probably the filter should be changed to integrate the kernel. I haven't actually been using it much myself, the underlying problem with the sinc filter is that it causes ringing at the edges, and these days I tend to use a Gaussian filter when linear/bspline are not sufficient.
> 
> Paul.
> 
> 
> On Wed, Dec 19, 2012 at 10:34 AM, Nicholas Tustison <ntustison at gmail.com> wrote:
> I love that you can just run testing like that with only a couple lines.
> That's really cool.
> 
> Unfortunately, I don't know the answer to your question but Paul might.
> I'm cc'ing him on this and hopefully he'll see it and be able to answer.
> 
> Nick
> 
> 
> On Dec 19, 2012, at 9:22 AM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> 
> > Hello Nick,
> >
> > Thanks for getting back to me on this.
> >
> > I also ran the Sinc interpolators on a constant image, and I got a larger error than expected. The following Python code was run with the ZeroFlux boundary condition and the radius template parameter of 5:
> >
> > # Create a image of all ones
> > img = sitk.Image( 10, 10 , sitk.sitkFloat64 )
> > img += 1
> >
> > iterps = [sitk.sitkNearestNeighbor,
> >          sitk.sitkLinear,
> >          sitk.sitkBSpline,
> >          sitk.sitkGaussian,
> >          sitk.sitkHammingWindowedSinc,
> >          sitk.sitkCosineWindowedSinc,
> >          sitk.sitkWelchWindowedSinc,
> >          sitk.sitkLanczosWindowedSinc,
> >          sitk.sitkBlackmanWindowedSinc]
> >
> > for i in iterps:
> >    eimg= sitk.Expand( img, [10,10], i )
> >    print "RMS:",(sum( (1-eimg)**2)/len(eimg))**.5, "Abs:", max(sitk.Abs(1-eimg))
> >
> > RMS: 0.0 Abs: 0.0
> > RMS: 0.0 Abs: 0.0
> > RMS: 1.90178968104e-16 Abs: 5.55111512313e-16
> > RMS: 0.0 Abs: 0.0
> > RMS: 0.00519432546396 Abs: 0.007170554427
> > RMS: 0.00111584107245 Abs: 0.00190357704047
> > RMS: 0.000697067283848 Abs: 0.00118879124085
> > RMS: 0.00143647177089 Abs: 0.00245097611656
> > RMS: 0.000491351024756 Abs: 0.000833429218405
> >
> > Skimming through the code it looks like the kernel is point sampled and not integrated over the pixel. I wonder if that is the issue.
> >
> > Brad
> >
> > On Dec 18, 2012, at 3:03 PM, Nicholas Tustison <ntustison at gmail.com> wrote:
> >
> >> Hi Brad,
> >>
> >> Yeah, we just use the default.  We've probably never noticed it since,
> >> as you say, we typically are interpolating a blob in the middle of a black
> >> background.
> >>
> >> I think Paul Yushkevich wrote those windowed sinc interpolators.  You
> >> might want to ask him why they're the default.
> >>
> >> Nick
> >>
> >>
> >>
> >> On Dec 18, 2012, at 1:09 PM, Bradley Lowekamp <blowekamp at mail.nih.gov> wrote:
> >>
> >>> Hello,
> >>>
> >>> As I am finally integrating the different interpolators into SimpleITK. I am giving them a close look over.
> >>>
> >>> The set of WindowSincInterpolateImageFunctions takes a Boundary condition template parameter. This defaults to ConstantBoundaryCondition. That is by default the pixels are zero outside the image, and they are not zero flux. This results in quite a bit of ringing and fading around my test images. It seems just wrong.
> >>>
> >>> I can easily specify this parameter as the ZeroFluxNeumannBoundaryCondition (I don't think we have a mirror/reflective boundary, which is another possibility), and things look quite good and as I expect the output to be. I was curious as to what others were doing so I perused BRAINS and ANTS, grepping for the sinc interpolator. And to my surprise they are using the default!
> >>>
> >>> Is there a reason that this default is preferred? Or is it that I am not processing a single blob in the center of a black image (aka a brain)?
> >>>
> >>> Also in terms of consistency across the interpolators, this is the only one which takes a boundary condition template parameters. The other interpolators appear to behave sensibly, and exhibit a zero-flux type boundary condition. I think the default for this may need to be changed.
> >>>
> >>>
> >>> I have this little example I have been working on in SimpleITK with the famed cthead1.png data input. Here is a code snippet:
> >>>
> >>>
> >>> image = image[(size[0]//2-25):(size[0]//2+25),(size[1]//2-25):(size[1]//2+25)]
> >>>
> >>>
> >>> iterps = [sitk.sitkNearestNeighbor,
> >>>        sitk.sitkLinear,
> >>>        sitk.sitkBSpline,
> >>>        sitk.sitkGaussian,
> >>>        sitk.sitkHammingWindowedSinc,
> >>>        sitk.sitkCosineWindowedSinc,
> >>>        sitk.sitkWelchWindowedSinc,
> >>>        sitk.sitkLanczosWindowedSinc,
> >>>        sitk.sitkBlackmanWindowedSinc]
> >>>
> >>> eFactor=5
> >>>
> >>> image_list = []
> >>>
> >>> for i in iterps:
> >>>  image_list.append( sitk.Expand( image, [eFactor]*3, i ))
> >>>
> >>> tiles = sitk.Tile( image_list, [3,0] )
> >>>
> >>> And the following is the output with the different boundary conditions:
> >>>
> >>> http://erie.nlm.nih.gov/~blowek1/images/expand_interp_cbc.png
> >>> http://erie.nlm.nih.gov/~blowek1/images/expand_interp_zfbc.png
> >>>
> >>> Thanks for you feedback,
> >>> Brad
> >>
> >
> 
> 
> 
> 
> -- 
> Paul A. Yushkevich, Ph.D. 
> Assistant Professor
> Penn Image Computing and Science Laboratory
> Department of Radiology
> University of Pennsylvania

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/pipermail/insight-developers/attachments/20121220/b6876389/attachment.htm>


More information about the Insight-developers mailing list