VideoCapture or imshow() bug (Bug #2680)

Added by Zhoucheng Li about 12 years ago. Updated about 12 years ago.

Status:Cancelled Start date:
Priority:Normal Due date:
Assignee:Andrey Pavlenko % Done:

0%
Category:highgui-camera
Target version:2.4.4
Affected version: Operating System:
Difficulty: HW Platform:
Pull request:

Description

Hey guys
I meet a problem which is really weird, and I think it might be a bug.
As soon as the program executes the line "cap >> x" where "x" is a Mat, the imshow() cannot show frames defined before this line.
Here is the test code:
1.The window "test" shows continous frames untill you press the "ENTER" key
2.Keep the last frame in procedure 1 and show it in Window "test frame_ref"
3.Excute "cap >> x", get a new frame
4.Show frame: frame_ref// it actually shows the frame x,however my code wants to show frame_ref

#include <iostream>
#include <opencv2/opencv.hpp>
using namespace cv;
int main(int argc, char * argv[])
{
    VideoCapture cap(0);//open camera
    if( !cap.isOpened())
        return -1;
    Mat frame_test;
    namedWindow( "test", 1 );
    for(;;)
    {
        cap >> frame_test;
        imshow( "test", frame_test );
        if( waitKey(30) == 13) //if press "ENTER" key, jump out the loop
            break;
    } 
    const Mat frame_ref(frame_test);
    namedWindow("test frame_ref");
    imshow("test frame_ref",frame_ref);// show frame: "frame_ref" 
    cvWaitKey(30);
    Mat x;
    cap >> x;//if I comment this line, the problem will be gone
    namedWindow("After cap >> frame");
    imshow("After cap >> frame", frame_ref);// show frame: "frame_ref" 
    cvWaitKey(30);
    system("pause");
}

Associated revisions

Revision 934cb6c4
Added by Vadim Pisarevsky almost 11 years ago

Merge pull request #2680 from adrians:remove_cv_err

History

#1
Updated by Zhoucheng Li about 12 years ago

How can I edit the above composing？

The OpenCV I'm using is ver 2.3.4 on Windows

#2
Updated by Andrey Pavlenko about 12 years ago

  • Category set to highgui-camera
  • Subject changed from cap() or imshow() function bug? to VideoCapture or imshow() bug
  • Start date deleted (2013-01-06)
  • Description changed from Hey guys I meet a problem which is really weird.And I think it might be a bug... to Hey guys I meet a problem which is really weird, and I think it might be a bu... More

#3
Updated by Andrey Pavlenko about 12 years ago

This is not a library bug but just a user misunderstanding (or probably lack of documentation).
Imagine you have:

  VideoCapture cap(0);
  Mat x, y;
When you call 
  cap >> x;
the object "x" (of type Mat) refers to some internal camera memory containing the last image from the camera.
It is valid until the next frame is requested from the camera, i.e. right after the call
  cap >> y;
the object "x" becomes invalid! This is done in the sake of performance (avoiding copying).
If you do need to keep the image "x" even after getting the next frame from the camera, you need to clone it:
  x = x.clone();
before (!!!) getting the next frame from the camera, i.e.
  cap >> x;
  x = x.clone();
  cap >> y;

Please make sure this fixes your problem and close the issue.

  • Assignee set to Zhoucheng Li

#4
Updated by Zhoucheng Li about 12 years ago

Andrey Pavlenko wrote:

This is not a library bug but just a user misunderstanding (or probably lack of documentation).
Imagine you have:
[...]When you call
[...]the object "x" (of type Mat) refers to some internal camera memory containing the last image from the camera.
It is valid until the next frame is requested from the camera, i.e. right after the call
[...]the object "x" becomes invalid! This is done in the sake of performance (avoiding copying).
If you do need to keep the image "x" even after getting the next frame from the camera, you need to clone it:
[...] before (!!!) getting the next frame from the camera, i.e.
[...]
Please make sure this fixes your problem and close the issue.

Thanks.The problem is fixed.

#5
Updated by Zhoucheng Li about 12 years ago

Andrey Pavlenko wrote:

This is not a library bug but just a user misunderstanding (or probably lack of documentation).
Imagine you have:
[...]When you call
[...]the object "x" (of type Mat) refers to some internal camera memory containing the last image from the camera.
It is valid until the next frame is requested from the camera, i.e. right after the call
[...]the object "x" becomes invalid! This is done in the sake of performance (avoiding copying).
If you do need to keep the image "x" even after getting the next frame from the camera, you need to clone it:
[...] before (!!!) getting the next frame from the camera, i.e.
[...]
Please make sure this fixes your problem and close the issue.

However,it seems I'm not authorized to edit this issue or close it.(T.T)

#6
Updated by Andrey Kamaev about 12 years ago

  • Assignee changed from Zhoucheng Li to Andrey Pavlenko
  • Target version set to 2.4.4
  • Status changed from Open to Cancelled

Also available in: Atom PDF