ZoneMinder Forums

Hey all,

Ive recently added a camera to the back of my house and all working fine, however as winter is coming Ive discovered Ive placed it too close to the heating system exhaust pipe (condensing boiler most of it is steam)..

So I could move it but I'll still see the steam.. So I was wondering could I use ZM zone settings to ignore the steam?
My current settings are
- "Blob"
- Overload Ignore framecount 10 (5fps)

Im thinking I should use Max Blob size too , right?

A sample image https://photos.app.goo.gl/ufWX7ZyzJeanWsU17

Well, zone configuration and frame filtering is really an art of its own. I'd venture that it can be done (yes, by using "max blob area", but also "max pixel threshold" and pretty much every other "max something" in there), albeit it would require too much manual tinkering with the filters and the result would probably be very finicky, because steam by its very nature spreads all over the place and swirls around and changes its color and thickness, etc, so a filter trained for, say, the steam image profile at the moment it exits the exhaust valve, would possibly fail with that same steam when it's had some time to spread around and get thinner/whiter/whatever-er.

What you could do, though, is to set up an Inclusive zone around the exhaust pipe, so the steam itself will not trigger an alarm unless some other zone produces an alarm first. So, if you then set an overlapping, wider Active zone, someone walking by would trigger still the alarm, while the steam itself will not. Seeing your image, this would still require some tweaking of the pixel filters (so as to not make a large portion of your garden into a "blind spot" where the camera does not respond to movement at all), but it would be much easier. Still, a good result can't be guaranteed even in this case.

Or you could just attach a pipe to that heater and transfer the steam to somewhere else (even just a meter or so higher off the ground would probably do wonders in your case) and be done with it.

Disclaimer: this is just based on my (limited) knowledge of zone configuration, and also without taking into account advanced techniques like using OpenCV filters to detect specific shapes and their changing in time, which would not only require advanced knowledge and IMHO too much time for your particular use case, but would also have you installing additional software (e.g. if I'm not mistaken zmNinja's in its recent versions has preliminary support for using OpenCV in its motion detection algorithms, but it's still in a somewhat experimental stage).

thanks there,

Im currently trying with Max Blob area, the idea being is that the steam is closer to the camera and much larger than a person:-)

The idea of putting a preemptive strike on the top left is a good idea.. Im thinking two zones, if there is a blob on the top left (given the location it can only be steam or an airplane crashing), then prevent alarms for 2seconds... worth a go..
thanks for the comments

Nocifer wrote: ↑Fri Oct 26, 2018 10:24 am Disclaimer: this is just based on my (limited) knowledge of zone configuration, and also without taking into account advanced techniques like using OpenCV filters to detect specific shapes and their changing in time, which would not only require advanced knowledge and IMHO too much time for your particular use case, but would also have you installing additional software (e.g. if I'm not mistaken zmNinja's in its recent versions has preliminary support for using OpenCV in its motion detection algorithms, but it's still in a somewhat experimental stage).

Excuse me for trolling around looking for anyone who says the magic words ("OpenCv" or "machine learning"). I'm a genie who keeps popping up when these words are uttered.

zmeventserver has incorporated machine learning, based on openCV, yes. It's not really only specific to zmNinja, but admittedly, most people who use it also use zmNinja. People using MQTT have also started using it (no zmNinja). More details here (its in the mobile app forum, but really this is not related to the mobile app). Note that zmNinja does not do any motion detection on its own. ZM does. The event server (colocated with ZM) then applies additional intelligence via these techniques.

I've been using it for just around a month now and its made a huge difference to me. I finally have a system I can tell my friends does a better or similar job to others like Nest and Logitech. Most homeowners want to know when people or cars come into their zones.

Status:
1. It's not beta anymore - its very stable at the moment, but yeah, you'll need to see if it can be run on your system. I've published performance results etc.
2. While I've written that I won't support these scripts, that statement is mostly for noobs who send me one-liners. For interested folks who can tinker, know how to install python packages, know how to use the command line and inspect logs, happy to help out.


Situations like these (smoke), or in my case, deep/heavy outdoor shadows make it nigh impossible to do a good job with just zones and blobs. If the OPs interest is to detect people or common objects, by all means, once you have the setup done, detection will be way ahead of what ZM's zones offer.

This is an example of extreme shadows/light my outdoor cameras deal with which makes blob/zones very hard to tweak and which the openCV model had no issues in marking as "person detected" with a timely notification. It's not perfect, of course, but miles ahead of what I expected.






That being said, the "event server" is only for managing notifications. ZM will record anytime a zone is triggered. What the event server will do:

1. Invoke the ML (machine learning scripts) to detect objects of interest. If found, only then will it send a notification out (to zmNinja, or MQTT listeners or any web socket listener)
2. If an object of interest is found, it will also annotate it in the ZM events DB
3. It will _not_ however, stop ZM from recording events that don't have an object detection

Nice!!

I have zmeventserver in my dockerbuild so I'll give that a go... However Im not 100% sure my poor old server will cope with the extra CPU openCV uses, but I'll give it a go!

@asker

Yes, of course I meant zmeventserver and not zmNinja, but seeing as you're the developer of both I managed to mess up the names. And also, it's a good thing that you're trolling these parts because that's actually how I learned about your use of OpenCV for motion detection in the first place

I too think that such a solution would be ideal for the OP's case (that's why I mentioned it, even if in passing) but I thought it as a bit too demanding for the average user out there. But since they seem more than eager to try it, then @asantaga, do go for it! It's certainly miles ahead of ZM's current detection capabilities, no doubt about that.

By the way, @asker, I can't help but notice (I've noticed since a long time ago actually) on your GitHub page that you're in some way or another affiliated with oZone Security and their beautiful oZone project that seemingly died out before it went anywhere (as far as I know). Might I inquire as to what exactly happened with that? I mean, from a theoretical point of view, that thing was pure gold and it's a real shame it died out. Am I right to assume that zmeventserver is in some ways a continuation of oZone?

But even then, that thing you said at the end of your post, that zmeventserver's processing takes place as an extra step AFTER ZM's own detection filters have kicked in and produced an event, made me wish for a solution like oZone was supposed to have been, i.e. a "plugin" that could make it so that alarms are triggered directly by it detecting stuff in a smart, modern way (e.g. with that OpenCV script) INSTEAD of ZM's internal mechanisms; making it essentially a replacement for ZM's motion detection and not an extra step. Not to mention the icing on the cake, i.e. the fact that oZone was also supposed to be NVR-agnostic.

So, yeah. Any info would be much appreciated.

By the way, @asker, I can't help but notice (I've noticed since a long time ago actually) on your GitHub page that you're in some way or another affiliated with oZone Security and their beautiful oZone project that seemingly died out before it went anywhere (as far as I know). Might I inquire as to what exactly happened with that? I mean, from a theoretical point of view, that thing was pure gold and it's a real shame it died out. Am I right to assume that zmeventserver is in some ways a continuation of oZone?

No, zmeventserver is not related to oZone at all. oZone is a modularized approach to the core detection and storage engine that is core to a CCTV solution. I wrote zmeventserver because I needed a way to send push notifications to zmNinja. The machine learning part was a bolt on.

oZone really is pure gold. The code and architecture is absolutely beautiful. However, it is very much still in "plumbing" state while the world of security and surveillance has moved forward with RESTful APIs, cloud and machine learning. A few years ago I reached out to Phil Coombes (the rockstar who first authored ZM) and asked him if he was interested in taking his v2 ideas forward. At that time, he had some very basic code done so we worked together for around 2 years to get it into the shape it is now. In many respects I worked as both a coder for the non-core stuff and the "Product Manager" for the interfaces/use-cases/converting a library of code to a useable product while Phil crafted the beautiful code for the "core engine" that made every idea actually work. That being said, we knew at the start both he and I had limited time to take this forward. He had various consulting assignments and I had (and have) a full day job with lots of travel and a job that has nothing to do with coding. So we beat it into shape, and actually managed to get the interest of 2 large VCs are 1 small VC. But we quickly realized that to make this a business it would take a huge amount of additional effort and we simply had to go to the machine learning route before any of them invested. That was after 2 years of off-time work, so the interest died down on both sides and we MIT licensed it a few months ago. I think it could go far if both of us had the time to carry on, but I already had my labor of love (zmNinja) and he had his work - I couldn't spend a lot of time on another huge project without revenue that did not sizably exceed the effort. As of today, we actually have a very interested investor who wants us to merge this into blockchains for an interesting concept, but we are both busy. And that was it. We decided to have others contribute and switched the license and left it at that. Life moved on. We had a lot of fun. If it wakes up again, we'll be here (I hope). Phil is a bleeping genius, to be honest.

But even then, that thing you said at the end of your post, that zmeventserver's processing takes place as an extra step AFTER ZM's own detection filters have kicked in and produced an event, made me wish for a solution like oZone was supposed to have been, i.e. a "plugin" that could make it so that alarms are triggered directly by it detecting stuff in a smart, modern way (e.g. with that OpenCV script) INSTEAD of ZM's internal mechanisms; making it essentially a replacement for ZM's motion detection and not an extra step. Not to mention the icing on the cake, i.e. the fact that oZone was also supposed to be NVR-agnostic.

Yup. Note that there is an issue with bounty open to integrate OpenCV into ZM's C++ core

thanks guys

Ive been looking at getting my teeth dirty with openCV for another project so I'll use this usecase and your code as a gentle way of learning how it works .

Different question, I was wondering why havent we embedded zmeventserver into the code zoneminder build? Even as is I think it will would significant benefits.

I have it now installed in a docker container but havent gotten around to configuring it to work with zmNinja (cool app BTW).

thanks both for your comments

@asker

Thanks for the info! So in other words, the project is not exactly dead dead but rather on long-term hiatus, with you and Phil still in contact with each other, and with investors still finding the idea interesting enough to invest in it whenever they hear about it. So in theory oZone could still be revived and become a reality in the short/mid/long/far, far away -term future. Great, this actually is more hopeful than it may sound. And talking about hope, here's to hoping that both of you guys will experience a mid-life crisis soon, decide to switch careers, and instead of going fishing you'll decide to take up working on oZone again as a full-time job. Just kidding, of course... or not?