This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DMVA1IPNC Tamper Detection Questions

Hello,

I am working with a DMVA1IPNC-MT5 camera using Version_02.00.00 software package.

I am trying to understand the behaviour of the Tamper Detection (TD) functionality available in the DMVAL.

As far as I understand, there are 2 user defined parameters that affect the outcome of the TD:
    1. 'Sensitivity' - controls the response of the algorithm to changes in the scene;
    2. 'Reset Sec' - controls the amount of time after which an 'altered' scene will go back to be considered 'normal' and thus reset the scene model characteristics.
    
Also, I understand that the TD application is an aggregation of 5 different detectors: 'scene change', 'camera move', 'scene darken', 'scene brighten' and 'camera defocus'.    

I have modified the videoDmvaAppThr.c file to allow the output of these various event trigers into the console in such a way that I can identify the timing of the triggered events.

I run a number of experiments where with various 'sensitivity' levels and 'Reset Sec' set to 20. I obscured the camera either with my hand or an object and I am not able to reconcile the results with the behaviour I was expecting.

Finally, here are a collection of questions about issues that are not clear to me at this moment:

1.    Is the parameter 'Sensitivity' used by all 5 detectors? Does it mean a different thing for each?

2.    Is the parameter 'Reset Sec' used by all 5 detectors? For example, if I move the camera, I normally get 'camera moved' for 1-5 frames and then I get other events such as 'scene change' or 'camera defocus' for a larger period. I would expect that 'camera moved' event should keep triggering for the whole 20 seconds until the scene reseted.

3.     Are there known stability issues? I seem to get a different behaviour each experiment even when I try to reproduce the same steps.

4.    What is the expected triggering behaviour of all 5 detectors? E.g. When a scene changes, is the 'scene changed' event supposed to keep triggering until 'Reset Sec' seconds pass?

Thank you,
José Lopes

  • Hi Jose,

    Regarding the user defined parameters:

    1. Sensitivity defines how responsive the application is to changes in the video. High sensitivity will catch even small/minor changes, and could result in false alarms. The converse is true when the sensitivity is low. 

    2. Reset Sec is the number of seconds after which an active tamper event is terminated, and the scene state at that moment is accepted as the 'normal' state. 

    Note that CTD does not contain individual detectors for the 5 different types of tamper event. Instead, think of it as a single function that detects when the scene is altered in some way, and then attempts at estimating the potential cause of the tamper event. 

    Answering your specific qns:

    1. The sensitivity parameter applies to the Camera Tamper Detection application as a whole

    2. The Reset Sec time limit comes into play only to terminate an active tamper notification. When the camera is moved, the application automatically estimates when the motion terminates, and the 'camera moved' message is withdrawn, and the camera resets the current scene as the 'normal'. If there is a small error in estimating this normal state, it is possible that a secondary tamper event such as 'scene changed' is detected. Typically, moving the camera does result in the scene being changed too. This 'scene changed' notification will be reported till the reset seconds duration has elapsed, and a new 'normal' scene is registered. If you are seeing 'camera defocus' being reported following a movement event, that might be a cause to dig a little deeper into this issue.

    3. This is not really a stability issue, but a reflection of the complexity of classifying these events. Remember that the primary output of CTD is the occurrence of a tamper event. The classification is only a best estimate of the cause of the event. This fuzziness is inherent in the classes. For example, 1) if the lens is covered, the scene becomes darker and the scene has changed, 2) if the camera is moved, even the scene has changed, 3) if the camera is made out of focus,  the camera could have moved, etc. So it is possible that while repeating a set of actions in front of the camera, the weight of the evidence collected for each tamper class varies. A perfectly repeatable experiment is possible only if feeding digital video directly to the processor.

    4. As explained earlier, the 'reset sec' comes into play to reset the scene any time a tamper event lasts longer than 'reset sec'. So for example, if you block the lens and then unblock it within the reset sec period, the tamper notification should be on only during the time the lens was blocked. However, if the lens is blocked for longer than 'reset sec', then after that time has elapsed, the tamper notification will be withdrawn and the blocked state will be accepted as normal.

    Hope this helps.

    Regards,

    Vinay

     

     

     

  • Hello Vinay,

     

    Thank you for the quick response. It has helped me understand the system better.

     

    Just 2 quick confirmations:

    1. From your description of the way CTP works, it seems that it is not possible to ignore the CTD alert based on what caused the tamper. For example, if I wanted to ignore the scene darkened triggers, that would not be reliable because I am not garanteed that I would see that specific cause for the tamper event. Can you confirm this?

     

    2. I understand that when the camera moves, then the 'scene changed' cause is also triggered. But, from a user perspective, I would expect both causes to be present until the reset timer ends. So, from your description, only one cause is guaranteed to be permanent until the timer end, correct?

     

    Thank you,

    José