Different red outline issue...possible broken preclusion zone logic?

Forum for questions and support relating to the 1.30.x releases only.
Locked
Tantamount
Posts: 76
Joined: Wed Feb 03, 2016 7:51 am

Different red outline issue...possible broken preclusion zone logic?

Post by Tantamount »

I followed the instructions and re-built the rpm for centos using the git repository for the other problem with red outlines not getting painted into the frames.

However, I seem to still be having a problem since alarms are triggering, but nothing is showing as outlined.

Here's an example of an alarm frame with the red outlining working:
https://server.zestysoft.com/owncloud/i ... V/download

Here's an example of another alarm frame without the red outlinging working:
https://server.zestysoft.com/owncloud/i ... 7/download

and here's the zone map for that camera:
https://server.zestysoft.com/owncloud/i ... t/download

I /think/ the reason is that a preclusive zone is getting triggered, but for whatever reason the event isn't getting killed.
3 ReoLink RLC-410
2 Annke NC800
Kubernetes 1.22.6 statefulset of 5 Ubuntu 20.04 pods using iconnor's repository
ZoneMinder Version 1.36.12
User avatar
knight-of-ni
Posts: 2404
Joined: Thu Oct 18, 2007 1:55 pm
Location: Shiloh, IL

Re: Different red outline issue...possible broken preclusion zone logic?

Post by knight-of-ni »

There is no way to draw any certain conclusion without knowing how each and every zone you've got is configured. In addition, we also need to see the statistics for the whole event, how many frames, how many alarm frames, etc. A single screenshot isn't going to cut it.

How sensitive did you make the preclusive zones? You will get the results of your screenshot if it is not sensitive enough. Also, keep in mind that preclusive zones were meant to be small, not large like you have them. Perhaps you ought to tell us exactly what kind of events you are trying to record.
Visit my blog for ZoneMinder related projects using the Raspberry Pi, Orange Pi, Odroid, and the ESP8266
All of these can be found at https://zoneminder.blogspot.com/
Tantamount
Posts: 76
Joined: Wed Feb 03, 2016 7:51 am

Re: Different red outline issue...possible broken preclusion zone logic?

Post by Tantamount »

knnniggett,

Interesting, Since you're asking for more information, can it be implied that it's possible to have an alarmed frame, triggered by motion, and not have any red outlines on it? I figured my particular circumstance ruled out a lot of the reasons for any additional information.

Let me see if I can give you all the details you have requested.

Of this particular event in question (125726):
Cause: Motion
Duration: 00:00:12
Frames: 56
Alarm Frames: 6
Total Score: 30
Avg. Score: 5
Max. Score: 5

For the alarmed frame that contains no red outlines (26):
Zone: Sidewalk
Pixel Diff: 62
Alarm Px: 8241 (5%)
Filter Px: 0 (0%)
Blob Px: 0 (0%)
Blobs: 0
Blob Sizes: 0 (0%)
Alarm Limits: 0.0-0.0:
Score: 5

Note that none of the alarmed frames have red outlines for this event.

Triggered zone info (Sidewalk):
Type: Active
Preset: Fast, High Sensitivity

In the example image of the person walking on the sidewalk (without the red outlines), I believe his head may be touching a preclusive zone? Or does ZM only do red outlining for blob based active zones? Hmm, after looking at a number of events, I think this may be the reason for the lack of red outlines -- zones that are not blob based...

I've exported the event too (and made sure to check off all the boxes for information) just in case I didn't give you everything you need. Here's a link to the zip file:
https://server.zestysoft.com/owncloud/i ... R/download

The reason for the preclusive zones is to deal with headlights at night, and for things like fog that drastically change the image during the day. I had a question about this -- You mentioned that these zones should normally be small, however from my understanding of the documentation, the only way to cancel a triggered active zone is to also trigger a preclusive zone - for each frame. However, headlights and fog tend to "sweep" across the frame, and thus I assumed I'd need fairly large preclusive zones to cover all of the places where this sweeping occurs.

Here's an example of headlights sweeping from left to right:
https://server.zestysoft.com/owncloud/i ... 1/download

There are three other headlight patters (right to left, and then there's a cross street where cars can turn left or right onto my street). Finally there are the motion lights from my neighbors house that are super sensitive and turn on and off constantly.
3 ReoLink RLC-410
2 Annke NC800
Kubernetes 1.22.6 statefulset of 5 Ubuntu 20.04 pods using iconnor's repository
ZoneMinder Version 1.36.12
User avatar
knight-of-ni
Posts: 2404
Joined: Thu Oct 18, 2007 1:55 pm
Location: Shiloh, IL

Re: Different red outline issue...possible broken preclusion zone logic?

Post by knight-of-ni »

We here in this technical support forum are mere mortals. We don't have a crystall ball, nor do we have magical powers. Until you produce the data we need, then we can't give you a complete answer. In your case, we can't tell you why something did or did not count as motion until you show us the zone configuration of all of your zones, including the preclusive zones. The screenshots you provided are helpful, but they will not tell us why something did or did not occur.

For the zone information you did provide, you do not have Blob detection enabled, which is why you did not get a red outline. Turn on Blob detection for the motion zone in question and then you will get the red outline. Also, 5% Alarm pixels is probably too high (not sensitive enough) for an outdoor view. Switch your units from Percent to Pixels, to get better precision.

We still can't answer the other question why something did not trip because you did not provide the zone configuration for your other four zones.

However, you have given us enough information to show us you are going about this the wrong way.

For starters, understand that due to the nature of how motion detection works, it is very unlikely (read - near impossible) you are going to completely eliminate things like headlights or fog w/o missing events you want to keep. The shadows cast across your driveway are also going to trip the motion detection. This is common for all outdoor cameras attached to any surveillance software. What you need to do is evaluate for yourself how much time you really want to spend trying to minimize unwanted events. What follows is a general set of steps you should follow:

1) Delete all the preclusive zones. Do not advance w/o first doing this.
2) Read the documentation regarding run states. Your goal will be to set up two run states. One for day and the other for night.
3) With your run state in the "day" run state, tune your motion zone(s) for the day. I recommend you start with just one zone. Intentionally make the zone more sensitive than you need so you can see the motion statistics. Then gradually adjust the zone configuration to be less sensitive.
4) With the system in the "Night" run state, tune your motion zone(s) for the night. I recommend you start with just one zone. Intentionally make the zone more sensitive than you need so you can see the motion statistics. Then gradually adjust the zone configuration to be less sensitive. This zone is expected to be less sensitive than the "day" run state.
5) Instead of using preclusive zones, use the Max Alarm/Filtered/Blob fields to ignore events that are too big since they are likely to be headlights. Keep in mind that, if a car pulls into your driveway at night, then zoneminder will likely not record it as motion if you are using the Max Alarm/Filtered/Blob fields. A preclusive zone will have the same problem. At night, anything large that moves into your active motion zones could get ignored because, with the headlights on, it will have tripped a preclusive zone.
Visit my blog for ZoneMinder related projects using the Raspberry Pi, Orange Pi, Odroid, and the ESP8266
All of these can be found at https://zoneminder.blogspot.com/
Tantamount
Posts: 76
Joined: Wed Feb 03, 2016 7:51 am

Re: Different red outline issue...possible broken preclusion zone logic?

Post by Tantamount »

knnniggett wrote:We here in this technical support forum are mere mortals. We don't have a crystall ball, nor do we have magical powers. Until you produce the data we need, then we can't give you a complete answer.
I imagine you say this often here (I saw it in the READ MY FIRST forum post too). As someone who works in IT, I feel your frustration because it's a common occurrence for me as well. I understand that your time is precious to you, and you want to be able to clean out the "tickets" with a single answer. However, the crystal ball analogy goes both ways. Information is infinite. I've come to realize that users often don't know what information is necessary. In my circumstance, would the /var/log/* files have helped? Include exports of more events? Are there other places with data that I don't even know about? Does ZoneMinder keep logs elsewhere? I don't have magical powers either.

Then there's the flip side. The problem of "TLDR" and not getting any answers because no one wants to spend the time reading through and filtering out what's relevant from what's not from posts with too much information. Long attention spans are in short supply in the internet age. Have you ever seen posts where people dump the entire contents of log files that scroll and scroll and scroll? SKIP!

Finally there's concern for the helpers time. I don't want to waste helpful people's time having them sort through unnecessary crap because answering my question is already a burden -- I want to filter out what I believe to be unnecessary to help the helpers.

Thus the title of this thread-- I thought I had hit a proper middle ground where there could only be a limited set of answers that could be derived from the amount of data provided. I had a problem where I was getting alarmed frames, but some had no red outlines. I thought to myself, "How many possibilities could there be for this?" My assumption was none, and thus it was somehow a bug. So I brought in additional information about the use of preclusive zones, and included screen shots to show where those were placed.

I figured that was enough information to at least start a dialog -- I think it would be unreasonable of me to expect "a complete answer" right off the bat, and as I don't know what I don't know, felt it was a good start.

However, as I've just learned, it turns out my question was answerable with the information I originally provided. Had you asked this question: "Are you using zones with the Alarm Check Method set to 'AlarmedPixels''? Because if you are, you won't see highlighted blobs in those zones."

Going forward, I can think of some changeable things with the ZoneMinder program and the forum software that could greatly reduce your frustration here, or at least save you (and other helpful people) some time:

1) Run forum software that allows uploading images and attachments. People are lazy -- making them create accounts and use pastbin, or create accounts and use external file sharing is like pulling teeth for most people. It hard enough just to get a user to post a screenshot even with attachment support built-in! There are other problems with those methods too -- links expire. This greatly reduces how helpful the threads are to others who search for and find these threads in the future. By retaining all this information in one place, it should lessen the number of people who might otherwise re-ask the same questions (and thus waste your time over and over).
2) From within the ZoneMinder GUI, add the ability to export the information you almost always request when people have problems. Part of the difficulty in giving you the information you've requested is that the data is not only spread out all over the place in ZoneMinder, there's no easy method for getting that data into this forum in readable format.
knnniggett wrote:For the zone information you did provide, you do not have Blob detection enabled, which is why you did not get a red outline. Turn on Blob detection for the motion zone in question and then you will get the red outline. Also, 5% Alarm pixels is probably too high (not sensitive enough) for an outdoor view. Switch your units from Percent to Pixels, to get better precision.
To be clear, when you say "Turn on blob detection", you want me to change the zone's 'Alarm Check Method' from 'AlarmedPixels' to 'Blobs'? I couldn't find anything else about turning on or off "blob detection."

The docs only mention outlining once ( https://zoneminder.readthedocs.io/en/st ... ht=outline ):

"You will notice for the first time that alarm images now contain an overlay outlining the blobs that represent the alarmed area. This outline is in the colour defined for that zone and lets you see what it was that caused the alarm. "

There's no cavat anywhere that the AlarmedPixels detection method doesn't also create the red outline blobs.
knnniggett wrote:We still can't answer the other question why something did not trip because you did not provide the zone configuration for your other four zones.
I never asked why something didn't trip. I only ever asked why something tripped, but didn't leave any trace in the alarmed frame.
knnniggett wrote:However, you have given us enough information to show us you are going about this the wrong way.

For starters, understand that due to the nature of how motion detection works, it is very unlikely (read - near impossible) you are going to completely eliminate things like headlights or fog w/o missing events you want to keep. The shadows cast across your driveway are also going to trip the motion detection. This is common for all outdoor cameras attached to any surveillance software. What you need to do is evaluate for yourself how much time you want really want to spend trying to minimize unwanted events. What follows is a general set of steps you should follow:

1) Delete all the preclusive zones. Do not advance w/o first doing this.
2) Read the documentation regarding run states. Your goal will be to set up two run states. One for day and the other for night.
3) With your run state in the "day" run state, tune your motion zone(s) for the day. I recommend you start with just one zone. Intentionally make the zone more sensitive than you need so you can see the motion statistics. Then you gradually adjust the zone configuration to be less sensitive.
4) With the system in the "Night" run state, tune your motion zone(s) for the night. I recommend you start with just one zone. Intentionally make the zone more sensitive than you need so you can see the motion statistics. Then you gradually adjust the zone configuration to be less sensitive. This zone is expected to be less sensitive than the "day" run state.
5) Instead of using preclusive zones, use the Max Alarm/Filtered/Blob fields to ignore events that are too big since they are likely to be headlights. Keep in mind that, if a car pulls into your driveway at night, then zoneminder will likely not record it as motion if you are using the Max Alarm/Filtered/Blob fields. A preclusive zone will have the same problem. At night, anything large that moves into your active motion zones could get ignored because, with the headlights on, it will have tripped a preclusive zone.
I appreciate this additional advice and I agree approaching this problem has been difficult. To date ZoneMinder is by far the best program for dealing with this situation.

I would like to continue this discussion, but want to create a different thread for it since it's off topic and I want others to be able to find and benefit from it.
3 ReoLink RLC-410
2 Annke NC800
Kubernetes 1.22.6 statefulset of 5 Ubuntu 20.04 pods using iconnor's repository
ZoneMinder Version 1.36.12
User avatar
knight-of-ni
Posts: 2404
Joined: Thu Oct 18, 2007 1:55 pm
Location: Shiloh, IL

Re: Different red outline issue...possible broken preclusion zone logic?

Post by knight-of-ni »

Yeah, it certainly is frustrating when you ask for a specific set of data, and the user responds with a fraction of what you requested, yet the user still expects you to give a detailed response. As someone who works in IT, you should know very well know it simply does not work that way. We don't work on magic, and no one here wants to ask repeatedly for the data one requires in order to respond intelligently.

Please leave your assumptions that less is better at the metaphorical door. This is a technical support forum, and more data is definitely better. The Forum Rules, which you read, quite literally say that. This is not a joke. I have yet to encounter a post with too much data (the search key works quite well). For pages of data, create a Gist and link to it. If you want to shorten a post, then the best thing to leave out are qualitative assumptions as to the cause of the perceived problem and assumptions that something is a bug.
To be clear, when you say "Turn on blob detection", you want me to change the zone's 'Alarm Check Method' from 'AlarmedPixels' to 'Blobs'? I couldn't find anything else about turning on or off "blob detection."

The docs only mention outlining once ( https://zoneminder.readthedocs.io/en/st ... ht=outline ):

"You will notice for the first time that alarm images now contain an overlay outlining the blobs that represent the alarmed area. This outline is in the colour defined for that zone and lets you see what it was that caused the alarm. "

There's no cavat anywhere that the AlarmedPixels detection method doesn't also create the red outline blobs.
I think we can both agree there is a lot of documentation to go through, but you seem to be making the assumption that, just because you did not see what you were looking for, it must not exist.

Please read this entire section of documentation here, which includes blob detection:
https://zoneminder.readthedocs.io/en/st ... ezone.html

This isn't a caveat. It is a definition. The only way to see the blobs outlined in red, is to turn on blob detection. Hence, the name. We can continue to argue about this all you want, but it won't help you get a better understanding of motion detection.
I never asked why something didn't trip. I only ever asked why something tripped, but didn't leave any trace in the alarmed frame.
You most certainly did ask why something did not trip:
viewtopic.php?f=36&t=25365

Is this not regarding the same zoneminder system?

Believe it or not, I really am trying to teach you how to find the answers you seek.
What I need you to do, is to answer any question I ask you, and not skip them, for any reason. If you don't understand the question, then it is fair to ask... just don't ignore the question, because I won't know what that means, and won't be able to give you a decent answer in return.

I am quite sure you will have additional questions concerning motion detection. Many struggle with it. My advice is to start out simple, with a single highly sensitive zone, as mentioned earlier. You then monitor the system over a period of days and tune the zones.
Visit my blog for ZoneMinder related projects using the Raspberry Pi, Orange Pi, Odroid, and the ESP8266
All of these can be found at https://zoneminder.blogspot.com/
Tantamount
Posts: 76
Joined: Wed Feb 03, 2016 7:51 am

Re: Different red outline issue...possible broken preclusion zone logic?

Post by Tantamount »

knnniggett wrote: Please leave your assumptions that less is better at the metaphorical door. This is a technical support forum, and more data is definitely better. The Forum Rules, which you read, quite literally say that. This is not a joke. I have yet to encounter a post with too much data (the search key works quite well).
Understood. If only all technical support forums worked this way. I supposed I'm like that golfer who never took lessons at the beginning and now has to unlearn all kinds of bad things. :)
knnniggett wrote:
To be clear, when you say "Turn on blob detection", you want me to change the zone's 'Alarm Check Method' from 'AlarmedPixels' to 'Blobs'? I couldn't find anything else about turning on or off "blob detection."

The docs only mention outlining once ( https://zoneminder.readthedocs.io/en/st ... ht=outline ):

"You will notice for the first time that alarm images now contain an overlay outlining the blobs that represent the alarmed area. This outline is in the colour defined for that zone and lets you see what it was that caused the alarm. "

There's no cavat anywhere that the AlarmedPixels detection method doesn't also create the red outline blobs.
I think we can both agree there is a lot of documentation to go through, but you seem to be making the assumption that, just because you did not see what you were looking for, it must not exist.

Please read this entire section of documentation here, which includes blob detection:
https://zoneminder.readthedocs.io/en/st ... ezone.html

This isn't a caveat. It is a definition. The only way to see the blobs outlined in red, is to turn on blob detection. Hence, the name. We can continue to argue about this all you want, but it won't help you get a better understanding of motion detection.
Please understand that my discussion here is not about arguing-- when I bring things up like this, it's to explain that one of the users of this program (me), who read the docs (at some point in the past -- pretty sure more information has been added since then), and who at least attempted to search the docs (for the word "outline" which I gave a link to, and for "blob detection" which came up with zero results), came to the wrong conclusion. You've been doing this support stuff here for a while (using the join time stamp of your user account as the measure of this) -- am I the first to make this mistake? Where I'm going with this is that maybe an adjustment to the docs would help add clarification. (Something I'm more than willing to do myself)

The GUI already is very helpful with extra information thanks to those little "?" links next to various settings. Currently the one next to "CREATE_ANALYSIS_IMAGES" has this definition:
"By default during an alarm ZoneMinder records both the raw captured image and one that has been analysed and had areas where motion was detected outlined. This can be very useful during zone configuration or in analysing why events occurred. However it also incurs some overhead and in a stable system may no longer be necessary. This parameter allows you to switch the generation of these images off."

The first sentence strongly suggests that motion should always be outlined -- there is no mention of blobs. The name of the setting also doesn't use "blob."

I'd just like to add some additional information that this only applies to active zones that use blobs as the alarm check method, and maybe take out the "by default" from the first sentence since that's clearly not true.
knnniggett wrote:
I never asked why something didn't trip. I only ever asked why something tripped, but didn't leave any trace in the alarmed frame.
You most certainly did ask why something did not trip:
viewtopic.php?f=36&t=25365

Is this not regarding the same zoneminder system?
Same system, however that question was based on a entirely different problem (not even the same camera). I've elaborated further in that thread. However, even in that thread, my question was not asking for a reason why something did not trip -- I was asking if there was a way to get real-time statistical information. The "not trip" was merely an example for one of the reasons for the information.
knnniggett wrote:Believe it or not, I really am trying to teach you how to find the answers you seek.
What I need you to do, is to answer any question I ask you, and not skip them, for any reason. If you don't understand the question, then it is fair to ask... just don't ignore the question, because I won't know what that means, and won't be able to give you a decent answer in return.
If I had asked the question "Can an alarmed frame contain no red outline even when the CREATE_ANALYSIS_IMAGES setting is enabled", would you have needed any additional information? What do I do when the person answering my question starts to answer a different question? Humor them and knowingly waste their time?

I think the problem here wasn't that I didn't answer all of your questions (after all, I got my answer without doing so) -- it was that I didn't make myself clear enough on the answer I was after.

However, going forward, I will give you all the information you request (at least to the best of my abilities) even if I feel it's going off topic. When it comes to the complexity of this system, I'll take any lesson I can get -- especially if it's free and from an expert of the system!
3 ReoLink RLC-410
2 Annke NC800
Kubernetes 1.22.6 statefulset of 5 Ubuntu 20.04 pods using iconnor's repository
ZoneMinder Version 1.36.12
Locked