Strange output when using cv2.dft inside loops

asked 2015-05-24 12:05:26 -0600

rom1991 gravatar image

updated 2015-05-26 06:46:01 -0600

Edit: updated with proper working code to reproduce the issue.

Hello everyone! I'm having some very weird issues with the Python bindings of OpenCV. I'm trying to use the dft function (amongst others) to compute operations between long arrays of 1D data (think >=8192 samples).

The issue is, when setting up a certain combination of loops (see code reproducing the problem below), a dft that is supposed to give always the same answer can output different data in different iterations (array_fix_S).

Numerical values are just close to what I really use in practice/arbitrary, not trying to exploit anything:

import cv2
import numpy as np

t = np.r_[0:16384]
#Random vector 1 to test dft repeatability. Will stay the same all the iterations.
array_fix = np.random.rand(16384) 

for i in range (0,10):

    #This print is always the same, which is OK.
    print(np.max(array_fix))
    print(np.min(array_fix)) 
    acum    = np.zeros((np.size(50),np.size(t)))

    ####AT LEAST THE OPERATION BELOW IS GIVING TROUBLE####
    array_fix_S = cv2.dft(array_fix,flags=cv2.DFT_COMPLEX_OUTPUT)

    #The 2 prints below can change each iteration despite coming from the same DFT every time.
    #Pydev's debugger shows that the arrays do change between iterations when it happens.
    print(np.max(array_fix_S))
    print(np.min(array_fix_S))
    for iteration in range(0, 50):

        #I and Q would normally be real/imaginary readings from binary files that change
        #each iteration in my code. You can pull I & Q outside the loops like
        #array_fix and the problem in array_fix_S still persists.
        I=np.random.rand(16384)
        Q=np.random.rand(16384)

        #Channel merging to get cv2-friendly complex array.
        xchan = [I,Q]
        X = cv2.merge(xchan)

        #If I comment the loop below (where the other dft/idft operations appear) the problem
        #in the previous prints is GONE.
        for iteration2 in range(0, 50):
            interm = cv2.dft(X)
            sep = cv2.split(cv2.idft(cv2.mulSpectrums((interm),array_fix_S,0,conjB=True),flags=cv2.DFT_COMPLEX_OUTPUT))

Bear in mind that the equivalent code using numpy.fft does work as intended. The algorithm in principle is correct. I'm starting to think this is an OpenCV bug.

I tried with stock Ubuntu 14.04 and 15.04 64 bits.

Any useful advice? I will provide more information if needed.

Thank you very much!

edit retag flag offensive close merge delete

Comments

unfortunately, your pseudo-code is far too pseudo, to be useful.

could you try to replace it with a real (small) test-case, so that folks here can try to reproduce your problem?

berak gravatar imageberak ( 2015-05-24 23:49:40 -0600 )edit
1

You are right... I'm working on a code to reproduce the issue. I'll update the question as soon as possible.

rom1991 gravatar imagerom1991 ( 2015-05-25 01:53:08 -0600 )edit
1

I added a code that reproduces the issue in my computer. I observed that the min and max readings in my dft just tend to go wild (max becomes orders of magnitude higher, min becomes orders of magnitude lower).

Looks like some nasty initalisation issue perhaps...? I feel a little bit lost.

rom1991 gravatar imagerom1991 ( 2015-05-25 04:29:54 -0600 )edit

I have been able to reproduce it with following code:

import cv2
import numpy as np

A = np.random.rand(16384)
X = np.random.rand(2, 16384)

for i in range (0,5):
    Am = cv2.dft(A, flags=cv2.DFT_COMPLEX_OUTPUT)
    print("DFT min: %f" % np.min(Am))
    cv2.dft(X)

Prints:

DFT min: -100.164089
DFT min: -107.439036
DFT min: -107.439036
DFT min: -139.574893
DFT min: -107.439036

But similar C++ code works well. It can be an error with python bindings. Could you, please, post an issue: http://code.opencv.org/projects/openc...

mshabunin gravatar imagemshabunin ( 2015-05-27 10:04:44 -0600 )edit
1

Done.

http://code.opencv.org/issues/4364

Thanks for the help! Reporting was the next step anyway, but I feel more confident doing it after some peer reviewing.

I'll wait a little bit before I mark the question as answered. I want to see what's the answer in the bug tracker.

rom1991 gravatar imagerom1991 ( 2015-05-27 15:58:48 -0600 )edit