Motioneyeos: Incorporating OpenCV into motioneyeos

[careyer]

Dear Calin,

is it possible to support OpenCV with one of the next releases of motioneyeos? OpenCV offers a huge variety of possibilities and it seems to feature highly optimized and stable code as of today. I think it is even more reliable, faster and less resource hungry in detecting motion events than the ratehr "old" motion and it can do so much more (e.g. determine a room occupied/unoccupied status: https://www.pyimagesearch.com/2015/05/25/basic-motion-detection-and-tracking-with-python-and-opencv/)
Its possibilities are almost limitless (facedetection, skin detection, ... just to name a few)

I have been using motioneyeos for a long long time now and I love it so much for its reliability and simplicity! However it seems that I have reached its end of potential when it comes to my current project which is about indicating the occupied/unoccupied status of birds nesting boxes for scientific research.
Up until now motioneyeos was used for that but the challenge to detect occupied/unoccupied status with motion is almost not possible. This is due to the fact that the birds will on the one hand create lots of motion in the boxes but on the other hand also will sit in there for hours and hours almost without moving e.g. while sleeping or breeding. OpenCV is much better suited in this situation since it can e.g. compare the live feed with a reference picture. This enables for clearly telling if a bird is in the box or not.

To cut a long story short... I hope I could convince you to consider supporting OpenCV in a future version of motioneyeos! =D

Have a good one Calin!
Take care!

[ccrisan]

@careyer unfortunately, the short answer is no.

A relatively longer answer tries to justify the no above. motionEye is and has always been a motion frontend. Every little piece of video processing is done either by the motion daemon or by ffmpeg. There's no video processing at all in motionEye and there are no plans to add such functionality to motionEye.

You could try and convince motion guys to implement functionalities based on OpenCV, but I believe they prefer pull requests to... well, feature requests :)

Third party packages processing those images are not out of the question but it's very unlikely they get UI support in motionEye.

[Felixrising]

Perhaps having a roadmap to potentially support OpenCV instead of Motion in the future would be a way to attract people interested in developing this support... Motion Project itself is almost fully replaced with OpenCV functions... and Motion Project is effectively dead at this stage.

[jasaw]

Motion detection is just a tiny part of motion software. It has more code that deals with various other things. A better way is to replace the tiny motion detection code with OpenCV and keep the rest of it. Float this idea to motion developers, see if they are willing to incorporate OpenCV.