Opencv imshow() freezes when updating

后端 未结 9 2330
Happy的楠姐
Happy的楠姐 2020-12-09 05:18

For my image processing algorithm I\'m using python / OpenCV. The output of my algorithm shall be updated im the same window over and over again.

However sometimes

相关标签:
9条回答
  • 2020-12-09 05:33

    Increasing the wait time solves this issue. However in my opinion this is unnecessary time spent on sleeping (20 ms / frame), even though it's not much.

    Changing

    cv2.waitKey(1)
    

    to

    cv2.waitKey(20)
    

    prevents the window from freezing in my case. The duration of this required waiting time may vary on different machines.

    0 讨论(0)
  • 2020-12-09 05:35
    try:
        import cv2
    except:
        print("You need to install Opencv \n Run this command \n pip install python-opencv")
        exit()
    print('Press q to quit frame')
    def viewer(name,frame):
        while True:
            cv2.imshow(name,frame)
            if cv2.waitKey(10) & 0xff ==ord('q'):
                break
        return
    cv2.destroyWindow(name)
    

    Save this program and from now onwards, import this and use the function viewer to display any frame/image and your display windows will not hang or crash.

    0 讨论(0)
  • 2020-12-09 05:37

    I have the very same issue and I noticed that the fps the window is updated is getting slower and slower until it freezes completely. Increasing the waitKey(x) to something higher just extends the duration where the images are updated but when the time that cv2.imshow() needs to calculate exceeds the time from wait(Key) it just stops updating.

    (Skip this complainment:) I think the cv2.imshow() with waitKey() combination is a complete design error, why isn't imshow() just blocking until the UI is updated? That would make life so much easier without having to call waitKey() everytime...

    P.S.: There is a possibility to start an own thread for opencv windows inside opencv:

    import cv2
    img = cv2.imread("image.jpg")
    cv2.startWindowThread()
    cv2.namedWindow("preview")
    cv2.imshow("preview", img)
    

    source: cv2.imshow command doesn't work properly in opencv-python

    Well this doesn't work for me because I always get this errors when I run it:

    (python3:1177): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
    Attempt to unlock mutex that was not locked
    Aborted
    

    Maybe you could try it and report if it is working for you?

    Edit: Okay I solved the problem for me by creating a separate script imshow.py:

    import cv2
    import os.path
    
    while True:
        if os.path.exists("image.pgm"):
            image = cv2.imread("image.pgm")
            if not image is None and len(image) > 0:
                cv2.imshow("Frame", image)
                cv2.waitKey(20)
    

    And I am writing the image out in my other program with: cv2.imwrite("image.pgm", image) And I am calling the script like this:

    import subprocess
    subprocess.Popen(["python3", "imshow.py"])
    

    Although this is creating some dirty reads sometimes it is sufficient enough for me, a better solution would be to use pipes or queues between the two processes.

    0 讨论(0)
  • 2020-12-09 05:41

    Just add cv2.destroyAllWindows() just after cv2.waitKey()

    0 讨论(0)
  • 2020-12-09 05:42

    My suggestion is to use Matplotlib pyplot for displaying the image. I do it the following way.

    import matplotlib.pyplot as plt
    # load image using cv2....and do processing.
    plt.imshow(cv2.cvtColor(image, cv2.BGR2RGB))
    # as opencv loads in BGR format by default, we want to show it in RGB.
    plt.show()
    

    I know it does not solve the problem of cv2.imshow, but it solves our problem.

    0 讨论(0)
  • 2020-12-09 05:52

    So what I think is going on here is that the window,(an element of the highGUI) which is still active after the first call to imshow, is waiting for some sort of response from your waitKey function, but is becoming inactive since the program is stuck calculating in either the processImg of loadNextImg functions. If you don't care about a slight waste of efficiency (i.e. you're not running on an embedded system where every operation counts), you should just destroy the window after waitKey, and recreate before imshow. Since the window no longer exists during the time you are processing and loading images, the highGUI wont get stuck waiting for a call from waitKey, and it won't become unresponsive.

    0 讨论(0)
提交回复
热议问题