BackgroundSubtractorMOG glitch - Windows 7 x64 - Python 2.7 x64 - OpenCV 2.4.10 (Bug #3997)
| Status: | Cancelled | Start date: | 2014-11-05 |
|---|---|---|---|
| Priority: | Normal | Due date: | |
| Assignee: | Sebastián Ramírez |
% Done: | 100% |
| Category: | python bindings | ||
| Target version: | 2.4.11 | ||
| Affected version: | 2.4.9 (latest release) | Operating System: | Windows |
| Difficulty: | HW Platform: | x64 | |
| Pull request: |
Description
It seems like there is a glitch in BackgroundSubtractorMOG in Windows from Python.
System:
Windows 7 x64
Anaconda Python 2.7 x64
OpenCV 2.4.10 from precompiled binaries.
When I create a cv2.BackgroundSubtractorMOG object, it is not using the parameters given to the constructor as described in: http://stackoverflow.com/q/26741081/219530
Also, it seems like it's keeping the first frame used to train the object (with the "apply" method) stuck in the background / foreground, as seen when I show it on screen. It keeps the first frame given with "apply" as a constant background and shows as foreground anything different than that frame, instead of having a sequence of the last frames, creating probabilities for each pixel of being background or foreground.
History
Updated by Sebastián Ramírez over 10 years ago
I just compiled by myself cv2.pyd and the gitch persists.
I also compiled the library under linux (CentOS 6.6 x64) and the glitch also shows up there.
I'm changing the assignee because I see Abid in charge of some other Python problems.
I'm not sure if the bug is in the Python bindings or in BackgroundSubtractorMOG.
Maybe my last issue description was not fully understandable, here's an example.
Imagine that the video to analyze is of a ball moving from left to right.
In the first frame, the ball is on the left side of the frame.
The next frame shows the ball a little closer to the center, so, that portion of the frame (at the left side but closer to the center) has a difference in pixels with the background, so, when you show the "foreground mask" given by BackgroundSubtractorMOG, you see where the ball is in white pixels and the background in black pixels.
Also, as the first frame had the ball in the far left, and now the ball is not in the far left but there is just background, that area also has a difference in pixels with the actual frame, so, in that area, there's also a white blob. It's OK, it's normal, once the BackgroundSubtractorMOG gets more frames "it will update it's background knowledge" and know that the real background doesn't have a ball in the far left because it will have more frames accumulated that don't have a ball in the far left.
Here's the problem, by the end of the video, a lot of frames after, the foreground mask given by the BackgroundSubtractor shows in white the ball reaching its destiny, in the far right (that's good), but also shows a white blob in the far left area, having the first frame applied fixed in its model.
I hope that example helps describing the problem.
- Assignee changed from Vadim Pisarevsky to abid rahman
Updated by Sebastián Ramírez over 10 years ago
I was expecting BackgroundSubtractorMOG to set a learning rate to the new frames of 1.0 / history, but the default learning rate was set by default to 0, that's why I was having the issues.
Now I'll have to find out what is the variable "*history*" used for, since it isn't altering the learning rate behaviour.
I solved my problem by calling the apply method with an explicit learningRate parameter assignment.
- Status changed from New to Cancelled
- % Done changed from 0 to 100
- Assignee changed from abid rahman to Sebastián Ramírez