[Insight-users] Problems with bilateral filtering

[Stuart Golodetz]

Ok, thanks - I'll try it and find out :)

Stu

Bill Lorensen wrote:
> You should get the same results, but I have not checked this.
>
> Bill
>
> On Wed, Jun 23, 2010 at 6:03 AM, Stuart Golodetz <itk at gxstudios.net> wrote:
>   
>> Ah ok - thanks. Would you otherwise expect the 2D and 3D versions to produce
>> exactly the same output? (If so, I might switch to using the 2D version when
>> the volume I'm smoothing is essentially 2D.)
>>
>> Cheers,
>> Stu
>>
>> Bill Lorensen wrote:
>>     
>>> Yes, boundary checking slows it down.
>>>
>>> On Tue, Jun 22, 2010 at 3:18 PM, Stuart Golodetz <itk at gxstudios.net>
>>> wrote:
>>>
>>>       
>>>> Stuart Golodetz wrote:
>>>>
>>>>         
>>>>> Hi,
>>>>>
>>>>> I think I may be having some trouble using BilateralImageFilter
>>>>> appropriately and just thought I should check. Essentially, I'm trying
>>>>> it
>>>>> out as a replacement to multiple iterations of anisotropic diffusion
>>>>> filtering for edge-preserving smoothing of my input image, using the
>>>>> following code:
>>>>>
>>>>> ###
>>>>> ...
>>>>> typedef itk::BilateralImageFilter<RealImage,RealImage> BilateralFilter;
>>>>> BilateralFilter::Pointer bilateralFilter = BilateralFilter::New();
>>>>> bilateralFilter->SetInput(realImage);
>>>>> double domainSigmas[] = {6.0,6.0,6.0};   // test values (not connected
>>>>> to
>>>>> the GUI yet)
>>>>> double rangeSigma = 5.0;   // ditto
>>>>> bilateralFilter->SetDomainSigma(domainSigmas);
>>>>> bilateralFilter->SetRangeSigma(rangeSigma);
>>>>> bilateralFilter->Update();
>>>>> realImage = bilateralFilter->GetOutput();
>>>>>
>>>>> if(is_aborted()) return;
>>>>> increment_progress();
>>>>> ...
>>>>> ###
>>>>>
>>>>> I was hoping it was going to be faster than the anisotropic filtering
>>>>> I'm
>>>>> currently doing, as that takes about a second per iteration per 512x512
>>>>> slice (i.e. 30 seconds per slice for 30 iterations, which is not ideal):
>>>>>
>>>>> ###
>>>>> ...
>>>>> // Smooth this real image using anisotropic diffusion filtering.
>>>>> typedef
>>>>> itk::GradientAnisotropicDiffusionImageFilter<RealImage,RealImage>
>>>>> ADFilter;
>>>>> for(int i=0; i<m_segmentationOptions.adfIterations; ++i)
>>>>> {
>>>>>  ADFilter::Pointer adFilter = ADFilter::New();
>>>>>  adFilter->SetInput(realImage);
>>>>>  adFilter->SetConductanceParameter(1.0);   // test value (not connected
>>>>> to the GUI yet)
>>>>>  adFilter->SetNumberOfIterations(1);   // done this way so that I can
>>>>> update the progress after each iteration
>>>>>  adFilter->SetTimeStep(0.0625);
>>>>>  adFilter->Update();
>>>>>  realImage = adFilter->GetOutput();
>>>>>
>>>>>  if(is_aborted()) return;
>>>>>  increment_progress();
>>>>> }
>>>>> ...
>>>>> ###
>>>>>
>>>>> Unfortunately, it takes 3 minutes for a 512x512 slice, whilst producing
>>>>> "worse" results (in my context) than the anisotropic diffusion filtering
>>>>> I
>>>>> was doing before. So I have three questions:
>>>>>
>>>>> 1) Would you expect bilateral image filtering to take this long? If not,
>>>>> do you have any idea what I might be doing wrong please? (If not, is
>>>>> there
>>>>> anything I can investigate to try and track down the problem myself?)
>>>>> 2) Are the domain and range parameters having any effect on this, and
>>>>> how
>>>>> should I go about setting them appropriately please?
>>>>> 3) Am I barking up the wrong tree by trying to use bilateral image
>>>>> filtering as a drop-in alternative to anisotropic diffusion filtering
>>>>> like
>>>>> this?
>>>>>
>>>>> Cheers,
>>>>> Stu
>>>>>
>>>>>           
>>>> A separate (but related) question I have is: why would 3D anisotropic
>>>> diffusion filtering on a 512x512x1 volume be substantially slower than 2D
>>>> anisotropic diffusion filtering on a 512x512 slice? I know the time step
>>>> has
>>>> to be smaller for the 3D version, but I recall it still being
>>>> substantially
>>>> slower than before. However, 3D anisotropic diffusion filtering on a
>>>> larger
>>>> volume e.g. 512x512x20 wasn't all that slow considering what it was
>>>> doing. I
>>>> was wondering whether boundary checking might be slowing it down? Or is
>>>> there actually some other reason I haven't thought of?
>>>>
>>>> Cheers,
>>>> Stu
>>>> _____________________________________
>>>> 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://www.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-users
>>>>         
>> _____________________________________
>> 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://www.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-users