Hello,
i have two cams at the moment, which are very difficult to configure (heavy environment with reflections on cars, trees and so on).
So I tried to figure out which steps are done in which order till a alarm is created.
So I did:
1. Alarm Threshold:
How much must a pixel differ from a reference pixel to become a candidate for a "alarm pixel".
2. Min/Max Alarmed Area:
How many alarm candidates min/max are allowed to raise an alarm?
3. Filter Width/height:
Filter out all isolated alarm candidates which are smaller than Width/Height.
4. Min/Max Filtered Area
As "2.", but applied to the result of 1., 2., and 3.
5. Min/max Blob area
How min/max % of the zone must a group of pixels be to be concerned as a "blob".
6. Min/Max Blobs
Which range of numbers of blobs is allowed to rise an alarm?
1: Are my conclusions in the right order / generally right?
2: I am unsure with the zone setting "Alarm check method": which of these 6 Filters/Checks are applied in which of the Settings ("AlarmedPixels", "FilteredPixels", "Blobs")?[/b]
Chain of Filters and Checks till a Alarm is generated!
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
You are correct in your first assumption. The AlarmedPixels alarm method will include steps 1 and 2, the FilteredPixels method will go to step 4 and the Blobs method will use all 6 steps. However in all methods if a step fails the test, then no further steps are undertaken. So in most cases only steps 1 and 2 are executed as there will not be enough alarmed pixels to cause the test to go any further.
If you look at the Stats for any alarms that have been generated you should get an idea of what values have been generated. Also you should be aware that the 6 tests you have listed are executed on a per zone basis and not per image so if you had 3 active zones then the steps would be run for one zone first, then the next etc.
If you look at the Stats for any alarms that have been generated you should get an idea of what values have been generated. Also you should be aware that the 6 tests you have listed are executed on a per zone basis and not per image so if you had 3 active zones then the steps would be run for one zone first, then the next etc.
Phil
Thanks Phil, for your answer.
That helps me a lot to understand.
May I ask you another question according debugging? When I enable debug images, I see images generated labeled with "capture" (thats the original image, thats the easiest
), "analyse", "diag14-1", "diag16-2", "diag16-3", "diag16-4", "d" and "r". Ok, I guess that is zoneminder's view how the images are analysed. But I can't understand them at all. What is the information I can draw from it?
Thanks so much!
Simon
That helps me a lot to understand.
May I ask you another question according debugging? When I enable debug images, I see images generated labeled with "capture" (thats the original image, thats the easiest
), "analyse", "diag14-1", "diag16-2", "diag16-3", "diag16-4", "d" and "r". Ok, I guess that is zoneminder's view how the images are analysed. But I can't understand them at all. What is the information I can draw from it?Thanks so much!
Simon
-
zoneminder
- Site Admin
- Posts: 5215
- Joined: Wed Jul 09, 2003 2:07 pm
- Location: Bristol, UK
- Contact:
The capture and analyse images are always generated for an event so are not debug images as such. However diagnostic images are.
There are two kinds of diagnostic images which are and are written (and continuously overwritten) to the top level monitor event directory. If an event occurs then the files are additionally copied to the event directory and renamed with the appropriate frame number as a prefix.
The first set are produced by the monitor on the image as a whole. The diag-r.jpg image is the current reference image against which all individual frames are compared and the diag-d.jpg image is the delta image highlighting the difference between the reference image and the last analysed image. In this images identicial pixels will be black and the more different a pixel is the whiter it will be. Viewing this image and determining the colour of the pixels is a good way of getting a feel for the pixel differences you might expect (often more than you think).
The second set of diag images are labelled as diag-<zoneid>-<stage>.jpg where zoneid is the id of the zone in question (:)) and the stage is where in the alarm check process the image is generated from. So if you have several zones you can expect to see multiple files. Also these files are only interested in what is happening in their zone only and will ignore anything else outside of the zone. The stages that each number represents are as follows,
1: Alarmed Pixels - This image shows all pixels in the zone that are considered to be alarmed as white pixels and all other pixels as black.
2: Filtered Pixels - This is as stage one except that all pixels removed by the filters are now black. The white pixels represent the pixels that are candidates to generate an event.
3: Raw Blobs - This image contains all alarmed pixels from stage 2 but aggrageted into blobs. Each blob will have a different greyscale value (between 1 and 254) so they can be difficult to spot with the naked eye but using a colour picker or photoshop will make it easier to see what blob is what.
4: Filtered Blobs - This image is as stage 3 but under (or over) sized blobs have been removed. This is the final step before determining if an event has occurred, just prior to the number of blobs being counted. Thus this image forms the basis for determining whether an event is generated and outlining on alarmed images is done from the blobs in this image.
Using the above images you should be able to tell at all stages what ZM is doing to determine if an event should happen or not. They are useful diagnostic tools but as is mentioned elsewhere they will massively slow your system down and take up a great deal more space. You should never leave ZM running for any length of time with diagnostic images on.
Phew!! That took a while, and a good bit of research to try and remember what they did! I hope that helps anyway. I must remember to Wiki that article
There are two kinds of diagnostic images which are and are written (and continuously overwritten) to the top level monitor event directory. If an event occurs then the files are additionally copied to the event directory and renamed with the appropriate frame number as a prefix.
The first set are produced by the monitor on the image as a whole. The diag-r.jpg image is the current reference image against which all individual frames are compared and the diag-d.jpg image is the delta image highlighting the difference between the reference image and the last analysed image. In this images identicial pixels will be black and the more different a pixel is the whiter it will be. Viewing this image and determining the colour of the pixels is a good way of getting a feel for the pixel differences you might expect (often more than you think).
The second set of diag images are labelled as diag-<zoneid>-<stage>.jpg where zoneid is the id of the zone in question (:)) and the stage is where in the alarm check process the image is generated from. So if you have several zones you can expect to see multiple files. Also these files are only interested in what is happening in their zone only and will ignore anything else outside of the zone. The stages that each number represents are as follows,
1: Alarmed Pixels - This image shows all pixels in the zone that are considered to be alarmed as white pixels and all other pixels as black.
2: Filtered Pixels - This is as stage one except that all pixels removed by the filters are now black. The white pixels represent the pixels that are candidates to generate an event.
3: Raw Blobs - This image contains all alarmed pixels from stage 2 but aggrageted into blobs. Each blob will have a different greyscale value (between 1 and 254) so they can be difficult to spot with the naked eye but using a colour picker or photoshop will make it easier to see what blob is what.
4: Filtered Blobs - This image is as stage 3 but under (or over) sized blobs have been removed. This is the final step before determining if an event has occurred, just prior to the number of blobs being counted. Thus this image forms the basis for determining whether an event is generated and outlining on alarmed images is done from the blobs in this image.
Using the above images you should be able to tell at all stages what ZM is doing to determine if an event should happen or not. They are useful diagnostic tools but as is mentioned elsewhere they will massively slow your system down and take up a great deal more space. You should never leave ZM running for any length of time with diagnostic images on.
Phew!! That took a while, and a good bit of research to try and remember what they did! I hope that helps anyway. I must remember to Wiki that article
Phil