7

I've got a problem with cv::imshow. It normally consumes about 1-2 ms processing time for my image size but at some point in my processing-pipeline it uses 4-8 ms for the same kind of images.

I have a method 

void Tool::displayImage()
{
   startTimeMeasure();
   cv::imshow("output",image);
   evaluateTimeMeasure();
}

image is a member variable and the highgui window is created somewhere else. Time measurement works with boost::posix_time ptime and time_duration.

cvStartWindowThread();

was called.

The point is, that if displayImage() is called within a complex processing chain (loading image from videofile, some preprocessing etc), cv::imshow becomes very slow, while a call in a "paused" video to redraw an updated image is very fast.

If I add a cv::waitKey(10) before the time measurement's beginning, cv::imshow becomes fast, too. So there might be some (gui?) things which have to be processed which block cv::imshow? cv::waitKey(40) is called in a separate thread in loop which waits for keyboard input to control (e.g. pause/resume) the video. As far as I know, cv::imshow is performed in some kind of queue which is processed during cv::waitKey times?!? Where can I find information about all the tasks which are performed during that times? Maybe I can rearrange some parts of my code (really complex by now) to allow faster imshow all the time.

So what happens in a cv::imshow call and what might be the reasons for the slow/fast execution of the same call in different situations?

EDIT: one difference I recognized between regular execution and processing in 'pause' mode is, that in pause mode the method is started from a bound mouse callback function (that's from within the windowThread?) while in regular mode it's started from the main processing thread.

the swine
  • 10,713
  • 7
  • 58
  • 100
Micka
  • 19,585
  • 4
  • 56
  • 74

1 Answers1

3

This is a typical problem with OpenGL, and the OpenCV windows can be created using OpenGL. There is a problem with SwapBuffers (see SDL_GL_SwapBuffers() is intermittently slow and others), which is often solved by adding a small sleep before it.

  • Disabling vertical synchronization in the video drivers may help.
  • Not having too many image windows opened (a typical plague of many OpenCV programs) helps.
  • Using a different API than OpenGL to create the windows may help (will likely require recompiling highgui).
Community
  • 1
  • 1
the swine
  • 10,713
  • 7
  • 58
  • 100
  • wrong answer. opengl is only used for 3d content, not for 2d image blitting – berak Oct 20 '14 at 10:47
  • 2
    @berak are you sure? I'm looking at `void cv::imshow( const string& winname, InputArray _img )` in `window.cpp` right now, and it sure as hell calls `setOpenGlDrawCallback(winname, glDrawTextureCallback, &tex);` (OpenCV 2.4.7). Please, do not downvote the post unless you are sure. – the swine Oct 20 '14 at 10:56
  • How exactly does that "3D content" look? This will just draw a textured quad / use `glDrawPixels`! – the swine Oct 20 '14 at 10:58
  • blitting an image on e.g. win will take you [here](https://github.com/Itseez/opencv/blob/master/modules/highgui/src/window_w32.cpp#L1139) - so that's plain GDI used. – berak Oct 20 '14 at 11:03
  • That is somehow inside an `#if 0` block. Totally gets called. My OpenCV has a lot of `#ifdef HAVE_OPENGL` in there, [try this](https://github.com/Itseez/opencv/blob/master/modules/highgui/src/window_w32.cpp#L1057), that finally ends [here](https://github.com/Itseez/opencv/blob/master/modules/core/include/opencv2/core/opengl.hpp#L255). – the swine Oct 20 '14 at 11:10
  • 1
    Also, the question is related to performance. If OpenGL was used (that is speculative on my part), there are some pretty similar patterns to what Micka is asking. Might be worth to someone. – the swine Oct 20 '14 at 11:11
  • so, sorry, you're right, i'm wrong. (had to edit it to revoke the dv) – berak Oct 20 '14 at 11:17
  • Sure, no problem. Happens to me all the time. – the swine Oct 20 '14 at 11:19
  • 2
    should we remove the comments ? – berak Oct 20 '14 at 11:21
  • 2
    Nah, might be useful to someone following the same chain of thought. – the swine Oct 20 '14 at 11:22
  • sorry to interrupt but how would you go about using a different API and disabling vertical sync in the video drivers? also, my program (One Window) is not simply slow but hangs altogether, could that still be the same mistake? – user1862770 Feb 28 '16 at 07:57
  • 1
    @user1862770 a different API is selected somewhere in OpenCV configuration, using a macro. Disabling vsync in video drivers for nvidia and windows - start nvidia control panel, go to "manage 3D settings" and in the list select vertical sync = off. Unlikely the same issue, more likely the image you are trying to display is damaged. – the swine Feb 29 '16 at 08:59