Skip to content
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

Investigate potential overflows in the complex demosaicing definitions. #1

Closed
m0ose opened this issue Oct 5, 2016 · 3 comments
Closed
Labels

Comments

@m0ose
Copy link

m0ose commented Oct 5, 2016

I am using this with a point grey camera, and I get some weird artifacts while using the demosaicing_CFA_Bayer_DDFAPD, demosaicing_CFA_Bayer_Malvar2004, and demosaicing_CFA_Bayer_Menon2007 methods.
The method demosaicing_CFA_Bayer_bilinear doesn't seem to have that problem.

They look like these blue dots. I am thinking that the colors are overflowing the byte.
screen shot 2016-10-05 at 12 57 01 pm

@KelSolaar
Copy link
Member

Hi,

It might be hard to debug without more information, do you have the file to test?

@KelSolaar KelSolaar changed the title possible overflows Investigate potential overflows in the complex demosaicing definitions. Oct 6, 2016
@KelSolaar KelSolaar added the Task label Oct 6, 2016
@m0ose
Copy link
Author

m0ose commented Oct 6, 2016

I think it was my fault.
I found a workaround. It turns out the input data was in uint8 and stringIO was expecting values between 0 and 255. The demosaicing algorithm produced several values that were bigger than 255, which I think got converted into zeros somewhere(probably in stringIO).

    # This is a way to output a good demosaiced uint8, from uint8 input
    m = m.astype('float32')
    m = colour_demosaicing.demosaicing_CFA_Bayer_Menon2007(m)
    print 'negative count:', (m < 0).sum(), ', bigger than 255: ' , (m > 255).sum()
    m = m.clip(0,255)
    m = m.astype('uint8')

Here is a test image, if you are still interested.
shot_bayer

and the messed up version:
shot_problem

and a version that used the floats workaround:
shot_good

@KelSolaar
Copy link
Member

Hi,

I was suspecting something along those lines!

Please be aware that the algorithms were tested with floating point images in [0, 1] domain, not integer [0, 255], integer [0, 65535] or any integer representation. You might want to divide your input to the functions by bit_depth - 1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants