New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discrepancy with output of nlmeans.py #1011

Closed
riddhishb opened this Issue Mar 23, 2016 · 5 comments

Comments

Projects
None yet
3 participants
@riddhishb
Contributor

riddhishb commented Mar 23, 2016

I am working on adaptive denoising patch for dipy, and I noticed an interesting catch in the current implementation of nlmeans.py. I have discussed this with @Garyfallidis

Following is the output with p=1,b=1 (3x3 block_size and 3x3 patch_size)
1

Following is the output with p=3,b=3 (7x7 block_size and 7x7 patch_size)
2

and the error map between the above two images is
3

Ideally as per the equations (given below) the output should get more smooth on choosing the larger block/patch sizes (if we refer to this or [coupe2008]), but that is not the case. (in fact there is no blockwise approach of averaging in denspeed.pyx)

equation 1 (here B is the block size and V is the Patch size)
screen shot 2016-03-24 at 12 41 15 am

equation 2
screen shot 2016-03-24 at 12 41 25 am

In fact for all cases where patch_size = block_size we get the same output!

I have been working to solve this bug and will make a PR soon with some changes in denspeed.pyx file. I would like to know your comments on the same.

@arokem

This comment has been minimized.

Member

arokem commented Mar 23, 2016

Just to be clear: is the output identical in these two cases?

On Wed, Mar 23, 2016 at 11:20 AM, Riddhish Bhalodia <
notifications@github.com> wrote:

I am working on adaptive denoising patch for dipy, and I noticed an
interesting catch in the current implementation of nlmeans.py. I have
discussed this with @Garyfallidis https://github.com/Garyfallidis

Following is the output with p=1,b=1 (3x3 block_size and 3x3 patch_size)
[image: 1]
https://cloud.githubusercontent.com/assets/7941975/13995710/5af19ef0-f150-11e5-8a73-952523f1b95c.png

Following is the output with p=3,b=3 (7x7 block_size and 7x7 patch_size)
[image: 2]
https://cloud.githubusercontent.com/assets/7941975/13995751/8d5859c4-f150-11e5-8527-86c35d000c03.png

and the error map between the above two images is
[image: 3]
https://cloud.githubusercontent.com/assets/7941975/13995829/f8f8d96a-f150-11e5-9adb-ee9e83440ebd.png

Ideally the output should get more smooth, but that is not the case. In
fact for all cases where patch_size = block_size we get the same output.
I have been working to solve this bug and will make a PR soon with some
changes in denspeed.pyx file. I would like to know your comments on the
same.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#1011

@grlee77

This comment has been minimized.

Contributor

grlee77 commented Mar 24, 2016

@riddhishb

One might reasonably expect that perhaps the "block size" means that the the central pixel of the patch would traverse a region equal to the block size, but that is not what the code actually does.

If you look at the function process_block in denspeed.pyx, the patch is only looped over the locations in the block where no pixels in the patch extend beyond the block edges. So if the block size matches the patch size, the central patch of the block is only compared to itself!
In your first example above, within process_block, P = 3, BS=2*3+1=7, so the loops in process_block are for range(3, 4): which means only a single location is considered!

I would recommended raising an error if the block radius is not strictly greater than the patch radius, otherwise, no denoising is actually being done.

@riddhishb

This comment has been minimized.

Contributor

riddhishb commented Mar 24, 2016

@grlee77 Exactly, I was about to comment that.
@arokem Not just these cases, as @grlee77 mentioned, for all the cases where patch_radius >= block_radius we get no denoising.

@riddhishb

This comment has been minimized.

Contributor

riddhishb commented Jun 3, 2016

@arokem @Garyfallidis I think we can close this issue now.

@arokem

This comment has been minimized.

Member

arokem commented Jun 3, 2016

Closed through #1018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment