Would it be possible to get a dumbed-down description of how the various zone parameters interact? I really don't understand how altering the properties (outside of the zone size, which thankfully is shown on the picture) affects sensitivity to motion in the zone, and what their relationship to one another is.
Also, I get lots of consecutive events; is there a setting that says if two events happen within so many seconds of one another that they're to be treated as the same event?
Thanks,
B
Dumbing down of zone parameters
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Re: Dumbing down of zone parameters
Hi Brian,
I'm not exactly sure which parameters you mean but I'll try and briefly describe the ones that might not be obvious. In general the tests for motion detection cascade so if an image fails one of the tests or thresholds it passes to the next one, if not then the process terminates.
Alarm Threshold
===========
This is used to determine how 'different' a particular pixel has to be to register as a potential candidate for motion or other difference.
In black and white images each pixel is represented by a number from 0 to 255 where 0 is black and 255 is white so if your image went from black to white each pixel would be different by 255 and if your alarm threshold was say 15 all the pixels would have exceeded this threshold and would pass onto the next test. In reality the amount of change is rarely this much and so the value you use here depends on what your image normally contains. If it is facing a light background then the change if someone walks in front of it would be large and so the threshold could be high to avoid alarms from subtle lighting changes whereas for a dark backgound you might want to set your threshold lower. Experimentation is the only way to determine what is best for you but a starting value of about 15 would probably be as low as you'd want to go.
Of course the above is just for black and white images, for colour images each pixel is represented by three numbers, one each for red green and blue, each of which can go from 0 to 255 as before. So how do you figure out what the difference is then? Well, ZoneMinder lets you choose between two methods. The first is just to add all the individual colour differences up and divide the result by three to get the average. This is nice and fast and reasonably accurate. The other option is to use a more sophisticated algorithm to calculate the brightness component of the pixel as a whole and compare that. Which it does depends on the ZM_FAST_RGB_DIFFS option in the 'Video' tab of the options and there is a bit more on this in the help for that (click on the '?').
So in essence this parameter just lets you define how much a pixel must have changed to be initially considered 'alarmed', at this early stage in the process.
Just in case the site is playing up, I'll post this and address the other parameters in the next post.
Phil,
I'm not exactly sure which parameters you mean but I'll try and briefly describe the ones that might not be obvious. In general the tests for motion detection cascade so if an image fails one of the tests or thresholds it passes to the next one, if not then the process terminates.
Alarm Threshold
===========
This is used to determine how 'different' a particular pixel has to be to register as a potential candidate for motion or other difference.
In black and white images each pixel is represented by a number from 0 to 255 where 0 is black and 255 is white so if your image went from black to white each pixel would be different by 255 and if your alarm threshold was say 15 all the pixels would have exceeded this threshold and would pass onto the next test. In reality the amount of change is rarely this much and so the value you use here depends on what your image normally contains. If it is facing a light background then the change if someone walks in front of it would be large and so the threshold could be high to avoid alarms from subtle lighting changes whereas for a dark backgound you might want to set your threshold lower. Experimentation is the only way to determine what is best for you but a starting value of about 15 would probably be as low as you'd want to go.
Of course the above is just for black and white images, for colour images each pixel is represented by three numbers, one each for red green and blue, each of which can go from 0 to 255 as before. So how do you figure out what the difference is then? Well, ZoneMinder lets you choose between two methods. The first is just to add all the individual colour differences up and divide the result by three to get the average. This is nice and fast and reasonably accurate. The other option is to use a more sophisticated algorithm to calculate the brightness component of the pixel as a whole and compare that. Which it does depends on the ZM_FAST_RGB_DIFFS option in the 'Video' tab of the options and there is a bit more on this in the help for that (click on the '?').
So in essence this parameter just lets you define how much a pixel must have changed to be initially considered 'alarmed', at this early stage in the process.
Just in case the site is playing up, I'll post this and address the other parameters in the next post.
Phil,
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Re: Dumbing down of zone parameters
... contd.
(Note: I use the term 'image' in these descriptions. This actually applies only to the parts of the captured image contained within the zone only and not the whole image, unless your zone is large enough to contain the whole captured image. Alarm checking on zones only takes place on image areas contained within the zone so in effect each zone has it's own mini-image and this is what the term 'image' refers to in these descriptions.)
So at this point in the alarm detection process we may have a number of pixels in the image that have exceeded our initial threshold. In fact most images will have several for various practical and electrical reasons so we need a way to separate those images that truly represent motion from those that just have a bit of static on them. This takes us onto the next parameter(s).
Min/Maximum Alarmed Area
===================
These parameters define the bounds inside which we consider that change to be most representative of motion or some notable event. In simple terms we're basically saying "if there are more than X alarmed pixels and less than Y alarmed pixels then it _could_ be an event we're interested in, if not then forget it". The purpose of this test is to quickly filter out potential events that don't have enough alarmed pixels or those that may have too many.
Events with too few alarmed pixels are easy to understand, perhaps a leaf being blown across the field of view, but too many alarmed pixels can be a little harder to grasp as a concept. The most likely reason why this may occur is a wholesale lighting change such as that when the sun comes out or a light goes on. In this circumstance potentially every pixel may exceed the alarm threshold and be triggered, perhaps frequently. If you don't which this kind of event to be considered as an alarm then setting the maximum alarmed area allows you to specify what you want to be the maximum amount of alarmed pixels that may still constitute an event. You do not need to specify a setting for the maximum (or the minimum for that matter) in which case there will be no upper limit.
These parameters are specified either in pixel terms, as an area so the maximum would be equal to the image width multipled by the height or as an area percentage of the image. Using pixels is more precise but if you change the capture size of the monitor then you will have to manually adjust the values to match. Using percentages is better and more flexible unless you need pixel precision. Percentages are also easier to understand and calculate.
Back shortly with more....
(Note: I use the term 'image' in these descriptions. This actually applies only to the parts of the captured image contained within the zone only and not the whole image, unless your zone is large enough to contain the whole captured image. Alarm checking on zones only takes place on image areas contained within the zone so in effect each zone has it's own mini-image and this is what the term 'image' refers to in these descriptions.)
So at this point in the alarm detection process we may have a number of pixels in the image that have exceeded our initial threshold. In fact most images will have several for various practical and electrical reasons so we need a way to separate those images that truly represent motion from those that just have a bit of static on them. This takes us onto the next parameter(s).
Min/Maximum Alarmed Area
===================
These parameters define the bounds inside which we consider that change to be most representative of motion or some notable event. In simple terms we're basically saying "if there are more than X alarmed pixels and less than Y alarmed pixels then it _could_ be an event we're interested in, if not then forget it". The purpose of this test is to quickly filter out potential events that don't have enough alarmed pixels or those that may have too many.
Events with too few alarmed pixels are easy to understand, perhaps a leaf being blown across the field of view, but too many alarmed pixels can be a little harder to grasp as a concept. The most likely reason why this may occur is a wholesale lighting change such as that when the sun comes out or a light goes on. In this circumstance potentially every pixel may exceed the alarm threshold and be triggered, perhaps frequently. If you don't which this kind of event to be considered as an alarm then setting the maximum alarmed area allows you to specify what you want to be the maximum amount of alarmed pixels that may still constitute an event. You do not need to specify a setting for the maximum (or the minimum for that matter) in which case there will be no upper limit.
These parameters are specified either in pixel terms, as an area so the maximum would be equal to the image width multipled by the height or as an area percentage of the image. Using pixels is more precise but if you change the capture size of the monitor then you will have to manually adjust the values to match. Using percentages is better and more flexible unless you need pixel precision. Percentages are also easier to understand and calculate.
Back shortly with more....
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Re: Dumbing down of zone parameters
... contd.
So now we've gone through two stages of the alarm determination tests. We have a number of alarm pixels that are greater than our alarm threshold and there are more than our minimum valid alarmed area but less than our maximum (if defined) so it still looks like it could be a real event of some sort. These first two tests were reasonably quick and dirty but now we need to start to look at the alarmed pixels in more detail.
Generally speaking an event that we might be interested in is likely to contain one or more discrete bodies of changed pixels in the same region of the image and probably mostly adjacent to each other. So the next thing we need to try and do to our image is eliminate any alarmed pixels that may be isolated or discontinuous and which may be the result of electrical interference and which may be skewing the count of alarmed pixels and creating a false indication of an event.
Filter Width/Height
=============
This parameter allows the specification of a filter that is passed over the image and used to eliminate these isolated individual, or small blocks of, pixels. This parameter is specified in pixels and the value given represents a box which is used as the minimum size below which alarmed pixels are disregarded. So putting a value of 3 for this parameter means that the filter is a 3x3 pixel box and any pixels which do not form part of a block at least this size are switched from an alarmed state to a non-alarmed state. So an isolated pixel will be switched off as will two pixels next to each other, or all pixels in a block of 2x3 pixels but none in a block of 3x4 pixels.
In this regard this parameter does not represent a test itself but rather an action that is applied to the image so the alarm detection process will not terminate at this point but the actions applied may cause it to terminate at the next stage.
Essentially you can think of this filter as a way of removing all the fiddly little individual pixels or small blocks and leaving only those larger blocks of alarmed pixels which are likely to be caused by actual motion or other significant events and not a wasp flying by.
So now we've gone through two stages of the alarm determination tests. We have a number of alarm pixels that are greater than our alarm threshold and there are more than our minimum valid alarmed area but less than our maximum (if defined) so it still looks like it could be a real event of some sort. These first two tests were reasonably quick and dirty but now we need to start to look at the alarmed pixels in more detail.
Generally speaking an event that we might be interested in is likely to contain one or more discrete bodies of changed pixels in the same region of the image and probably mostly adjacent to each other. So the next thing we need to try and do to our image is eliminate any alarmed pixels that may be isolated or discontinuous and which may be the result of electrical interference and which may be skewing the count of alarmed pixels and creating a false indication of an event.
Filter Width/Height
=============
This parameter allows the specification of a filter that is passed over the image and used to eliminate these isolated individual, or small blocks of, pixels. This parameter is specified in pixels and the value given represents a box which is used as the minimum size below which alarmed pixels are disregarded. So putting a value of 3 for this parameter means that the filter is a 3x3 pixel box and any pixels which do not form part of a block at least this size are switched from an alarmed state to a non-alarmed state. So an isolated pixel will be switched off as will two pixels next to each other, or all pixels in a block of 2x3 pixels but none in a block of 3x4 pixels.
In this regard this parameter does not represent a test itself but rather an action that is applied to the image so the alarm detection process will not terminate at this point but the actions applied may cause it to terminate at the next stage.
Essentially you can think of this filter as a way of removing all the fiddly little individual pixels or small blocks and leaving only those larger blocks of alarmed pixels which are likely to be caused by actual motion or other significant events and not a wasp flying by.
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Re: Dumbing down of zone parameters
... contd.
Two stages ago we had tested that the number of alarmed pixels fell within our thresholds and in the previous step we removed any small blocks or likely bogus pixels from the alarmed image. So we now need to determine whether those removed pixels made any difference to our view of the image as a whole.
Min/Maximum Filtered Area
===================
These parameters are identical to the the Min/Maximum Alarmed Area parameters except that they are tested after the filtering process. As filtering can only remove pixels it makes no sense for these parameters be less restrictive than the Alarmed Area ones, in other words the Minimum Filtered Area should be equal to or less than the Minimum Alarmed Area and the same applies to the Maximum equivalents. The use of these parameters allows an easy way of eliminating circumstances (e.g. radio interference) that cause a lot of alarmed but discontinuous pixels from causing events. You may have started with 1500 alarmed pixels originally but being mostly isolated or in small groups only 200 remain after filtering. At this stage, if your Minimum Filtered Area was set to 800 pixels, the alarm would be disregarded and the testing process terminated. Whereas for an event caused by a body moving across the image perhaps 1200 of the original 1500 would remain alarmed and the process would continue.
...back after these words......
Two stages ago we had tested that the number of alarmed pixels fell within our thresholds and in the previous step we removed any small blocks or likely bogus pixels from the alarmed image. So we now need to determine whether those removed pixels made any difference to our view of the image as a whole.
Min/Maximum Filtered Area
===================
These parameters are identical to the the Min/Maximum Alarmed Area parameters except that they are tested after the filtering process. As filtering can only remove pixels it makes no sense for these parameters be less restrictive than the Alarmed Area ones, in other words the Minimum Filtered Area should be equal to or less than the Minimum Alarmed Area and the same applies to the Maximum equivalents. The use of these parameters allows an easy way of eliminating circumstances (e.g. radio interference) that cause a lot of alarmed but discontinuous pixels from causing events. You may have started with 1500 alarmed pixels originally but being mostly isolated or in small groups only 200 remain after filtering. At this stage, if your Minimum Filtered Area was set to 800 pixels, the alarm would be disregarded and the testing process terminated. Whereas for an event caused by a body moving across the image perhaps 1200 of the original 1500 would remain alarmed and the process would continue.
...back after these words......
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Re: Dumbing down of zone parameters
... contd.
At this point we have a number of alarmed pixels that we can be fairly sure are aggregated into a number of groups of a size at least as large as our filter. This in itself may be sufficient for us to consider the event to be an alarm, however we may want even more evidence before we push the big red button.
The next stage in the process is a further analysis of the image which continues the style of processing that the filtering began. This stage is concerned with the detection and analysis of image 'blobs'. Blobs in this context are continguous regions of alarmed pixels. They can be any shape but any series of alarmed pixels that join onto others are considered to be in the same blob, bearing in mind that at this point we have eliminated regions of alarmed pixels smaller than say 3x3 pixels. An image that contains someone standing at the door however is likely to consist of one large blob whereas a flock of pigeons flying past would more often be represented as a number of smaller blobs even if the total number of alarmed pixels was the same.
In essence blob analysis allows us to get some idea of the distribution of alarmed pixels in the image and draw some conclusions which we can use to decide whether the image represents somethign we wish to know about. Blob analysis does not have to be used and setting all the following parameters to zero will disable it if you feel it is unnecessary in your situation.
Min/Maximum Blob Area
=================
These parameters define the minimum and maximum sizes of any blobs that you consider important enough to form part of the alarm. As with the other min/max parameters they are expressed in pixels or percentage area of the whole image.
This is an important point that I may not have made earlier, despite the fact that the tests take place only on that part of the image encompassed by the zone, any sizes expressed in percentage terms relates to the whole image and not to just the restricted area visible to the zone. This may not be the best approach and will probably be changed (optionally) in a future version.
You will probably unlikely to use the Maximum Blob Area parameter as generally larger blobs are significant and wholesale lighting changes will have be detected and eliminated by eariler tests. However using the Minimum Blob Area allows you to specify a minimum size that you consider a blob has to be before it becomes significant. This can be used to prevents cats or small animals from triggering alarms etc.
Min/Maximum Blobs
==============
These parameters are used in conjunction with the Blob Area ones above and specify the minimum or maximum number of blobs that are required to finally make the detection image change into a bona-fide alarm. If you have a minimum blob area specified above if generally makes sense to set the minimum blob count to at least 1 to eliminate events that end up with no qualifying blobs. Otherwise if you set it to zero then an alarm will be generated regardless but blobs smalled than the specified minimum area will be eliminated. This may only have the effect of reducing the final alarmed area which may be highlighted but it could leave no qualifying blobs at all and an alarm generated in this circumstance could be considered to be bogus.
...
At this point we have a number of alarmed pixels that we can be fairly sure are aggregated into a number of groups of a size at least as large as our filter. This in itself may be sufficient for us to consider the event to be an alarm, however we may want even more evidence before we push the big red button.
The next stage in the process is a further analysis of the image which continues the style of processing that the filtering began. This stage is concerned with the detection and analysis of image 'blobs'. Blobs in this context are continguous regions of alarmed pixels. They can be any shape but any series of alarmed pixels that join onto others are considered to be in the same blob, bearing in mind that at this point we have eliminated regions of alarmed pixels smaller than say 3x3 pixels. An image that contains someone standing at the door however is likely to consist of one large blob whereas a flock of pigeons flying past would more often be represented as a number of smaller blobs even if the total number of alarmed pixels was the same.
In essence blob analysis allows us to get some idea of the distribution of alarmed pixels in the image and draw some conclusions which we can use to decide whether the image represents somethign we wish to know about. Blob analysis does not have to be used and setting all the following parameters to zero will disable it if you feel it is unnecessary in your situation.
Min/Maximum Blob Area
=================
These parameters define the minimum and maximum sizes of any blobs that you consider important enough to form part of the alarm. As with the other min/max parameters they are expressed in pixels or percentage area of the whole image.
This is an important point that I may not have made earlier, despite the fact that the tests take place only on that part of the image encompassed by the zone, any sizes expressed in percentage terms relates to the whole image and not to just the restricted area visible to the zone. This may not be the best approach and will probably be changed (optionally) in a future version.
You will probably unlikely to use the Maximum Blob Area parameter as generally larger blobs are significant and wholesale lighting changes will have be detected and eliminated by eariler tests. However using the Minimum Blob Area allows you to specify a minimum size that you consider a blob has to be before it becomes significant. This can be used to prevents cats or small animals from triggering alarms etc.
Min/Maximum Blobs
==============
These parameters are used in conjunction with the Blob Area ones above and specify the minimum or maximum number of blobs that are required to finally make the detection image change into a bona-fide alarm. If you have a minimum blob area specified above if generally makes sense to set the minimum blob count to at least 1 to eliminate events that end up with no qualifying blobs. Otherwise if you set it to zero then an alarm will be generated regardless but blobs smalled than the specified minimum area will be eliminated. This may only have the effect of reducing the final alarmed area which may be highlighted but it could leave no qualifying blobs at all and an alarm generated in this circumstance could be considered to be bogus.
...
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
Re: Dumbing down of zone parameters
Summary
=======
The above process is completed for separately for each zone you have defined, except for inactive ones which just blank their entire encompassed area. As this process continues then the zone will either drop out as a particular condition is not satisfied or if it reaches the end then the zone will consider itself to be 'alarmed'. Whether this translates to a full monitor alarm or not depends on the zone type, as preclusive zones for example will prevent a monitor alarm if they are alarmed whereas inclusive zones cannot cause a monitor to go into an alarm state alone but will participate in a greater alarm if another active zone if is alarmed.
As most of the time you might just use a regular 'active' zone in conjunction with one or more inactive zones to blank out areas it is safe to assume that this zone being alarmed will generate a full monitor alarm and that if the zone stops being alarms then the monitor will go initially to alert state and then to idle if not other alarm indications are received.
This addressed your second question to some extent. There is no 'timer' that you can use to join events that occur closer than that time together however you can simulate this. The 'post event buffer' that you specified when you created your monitor allows you to specify how many frames are captured and appended to an event after the monitor has left the alarm state and before it returns to idle. In this circumstance the monitor is in 'alert' state as it is neither alarmed nor idle. If the monitor is alarmed again whilst in alert state then the original event is just continued on and eventually the monitor might go to alert and then idle state.
So, changing the size of the 'post event' buffer allows you to control this trailing lag. In order to translate it into a time you will need to know what the capture rate of your monitor it but if it was 10 frames per second and you wanted a 5 second time period where new events would be appended you would make the 'post event' buffer 50 (10*5). In reality it is likely that this will map to slightly longer than 5 seconds as the frame rate can during during alarms. If you were to limit your monitor's frame rate to 5 frames per second then the same value of 50 would now represent 10 seconds of trailing lag. Although called the 'post event buffer' it is not strictly a buffer in the same way that the 'pre event' and 'ring' buffers are. Thus it has no practical limit and can be as large as you like.
I hope that answers some of your questions. I'm all typed out now!
Cheers,
Phil,
=======
The above process is completed for separately for each zone you have defined, except for inactive ones which just blank their entire encompassed area. As this process continues then the zone will either drop out as a particular condition is not satisfied or if it reaches the end then the zone will consider itself to be 'alarmed'. Whether this translates to a full monitor alarm or not depends on the zone type, as preclusive zones for example will prevent a monitor alarm if they are alarmed whereas inclusive zones cannot cause a monitor to go into an alarm state alone but will participate in a greater alarm if another active zone if is alarmed.
As most of the time you might just use a regular 'active' zone in conjunction with one or more inactive zones to blank out areas it is safe to assume that this zone being alarmed will generate a full monitor alarm and that if the zone stops being alarms then the monitor will go initially to alert state and then to idle if not other alarm indications are received.
This addressed your second question to some extent. There is no 'timer' that you can use to join events that occur closer than that time together however you can simulate this. The 'post event buffer' that you specified when you created your monitor allows you to specify how many frames are captured and appended to an event after the monitor has left the alarm state and before it returns to idle. In this circumstance the monitor is in 'alert' state as it is neither alarmed nor idle. If the monitor is alarmed again whilst in alert state then the original event is just continued on and eventually the monitor might go to alert and then idle state.
So, changing the size of the 'post event' buffer allows you to control this trailing lag. In order to translate it into a time you will need to know what the capture rate of your monitor it but if it was 10 frames per second and you wanted a 5 second time period where new events would be appended you would make the 'post event' buffer 50 (10*5). In reality it is likely that this will map to slightly longer than 5 seconds as the frame rate can during during alarms. If you were to limit your monitor's frame rate to 5 frames per second then the same value of 50 would now represent 10 seconds of trailing lag. Although called the 'post event buffer' it is not strictly a buffer in the same way that the 'pre event' and 'ring' buffers are. Thus it has no practical limit and can be as large as you like.
I hope that answers some of your questions. I'm all typed out now!
Cheers,
Phil,