Feature requests
I sent these in mail a while back, but it seems that the forum is a better place for visibility.
Improvements/Updates:
1) One of the problems I have is moving vegetation triggering motion events. I've been trying to get the masks correct, but it's a HUGE pain trying to guess where motion is coming from. It would be very useful to have a mode either in the Camera Settings or, optionally even in main views that would indicate via color blocks what pixel groups had triggered motion activity. This could be just by coloring areas bright red which were moving between frame images, and then perhaps decaying (making more transparent) the red pixels over the next successive frames if no more change was detected. This would be useful for tuning masks, and it would also be useful for security personnel so they could quickly identify where motion had occurred within a frame.
2) Another problem has been clouds where cameras are pointed at outdoor spaces. I've found that sunlight causes the whole image to change gradients, triggering motion alerts when clouds cross the sun. This seems to be a fairly easy problem to solve - when MORE than a certain number of pixels show a change, then it's not valid motion - it's a lighting shift. This might be a tune-able parameter per camera - a "damping" feature (slider?) which might be able to slim down the number of false alarms. It's not a duration issue (though I like that feature!) - it's a quantity of pixels issue. The shadows of trees going from indistinct to well-formed during a multi-second cloud change is a massive change in pixels over a reasonably long time, and it does not match the types of events that are actual "motion" in the frame. So putting in a feature that damps based on too much motion would be useful as an option.
3) Picture-in-picture views for groups and as saved streams instead of just fixed sets of images. This is useful for doors that have multiple cameras pointed at them, where one camera is less important than another, or hallways where coming/going views would be logical. Also having these "meta-cameras" would be useful to cut down on storage space if two cameras are more obviously linked together (but still retaining the ability to go to higher resolution on live views, if needed during security guard use.) The size and placement of the picture-in-picture should be specifiable (this would also allow for "split" views where the picture-in-picture was 50% of the window)
4) Click or double-click on a camera in a group view and have that camera "expand" and fill the screen for a user-configurable number of seconds (for "what's that?" views) and then retreat if clicked on again or when the timer expires.
5) Support for multiple monitors, allowing a full-screen (or multiple full-screen) images or groups to be placed on external monitors without unfocusing when other apps used (this is for security guard stations, with now-cheap USB additional display ports.)
6) All of the cameras I have contain the ability to do two-way audio. Some are SIP based, and some are proprietary. Having the ability to play sounds would be really great, though I know that gets complicated fast. Currently, my plans are to use scripts to fire off events to Asterisk and then do two-way audio that way, but it's kind of a hack. Even just having the ability to fire some of the pre-recorded audio events (like the Axis cameras support) would be useful, as a result of motion detection (in the "Actions" window) or as a right-click in the "Camera" event task menu.
7) Having an additional setting that combines both continuous capture and motion detection would be ideal. Often I am using SS for doing time-lapse of "interesting" things, like construction or daily activity. Having a single movie of the entire day of _only_ active moments in the scene with 1 frame per second would be really useful.
8) Being able to apply schedules selectively to motion and continuous parameters would be very useful. Even more fantastic would be sensitivity and/or image masking that could change based on schedule.
9) Having a schedule that understood the concept of "sunrise/sunset" based on location would be great (http://stackoverflow.com/questions/7064531/sunrise-sunset-times-in-c) and also relative offsets ("1 hour after sunrise") since lighting is terrain-specific.
10) The "light on/light off" option doesn't seem to work on my Axis M1054. However, I am very happy to see the addition of switch controls in the interface! (this was a prior request - thanks for implementing! It would be great to be able to trigger on inputs, though, as "activity" or "actions")
11) The Browser needs some significant work. It's really a huge missing piece of the software that caused my employer to abandon SecuritySpy for their main office and move to a different solution (Milestone XP). There could/should be some sort of color-coded slider that shows events over time, and the ability to show multiple cameras on the same time slider and view a set of cameras in historical time lock-step (if data is available). These guys have this feature (but few others): http://dcomplex.com/mac/ip-camera-recorder/ Many of the things I request above are actually fallout of not having a better browser - there are HUGE numbers of false alarms that I deal with, and scanning through them with the existing browser is very, very tedious. So that means either improving the scan method (the Browser) or decreasing the number of false alarms.
12) Having the ability to "slide" time back and forth for a specified cache time in each camera would be very useful. Hover the mouse on one of the view windows (full screen, or single window) and pan back and forth (either with the arrow keys, a left/right swipe, or left-right spin on a Magic Mouse or scroll wheel) for N seconds into the past would be great, so it would be possible to see (even if there was no activity) what was happening in that camera. This would be a new recording mode like "Continuous" or "Motion Capture" that would require some settings. If there's enough RAM, it would just live in RAM, but maybe this would require disk space if the timespan was long enough. Again, this is something that security desks would find really useful. Instead of going to the browser to see what just happened, they could just move to one of the live windows and scroll a little bit, with perhaps a time indicator that then appeared next to the mouse so that it was possible to see when the images were recorded plus an offset from current daytime ("13:33:14 -39 sec"). This would resolve 90% of the instances that they'd want to review.
Comments
-
Hi and thanks for your suggestions. Here are some of my comments:
1. This is a good idea, it's on the "to do" list.
2. Lighting changes such as you describe are usually very transient events and should be effectively filtered out using the "trigger time" setting set to 2 seconds. This requires continuous motion over 2s before it will trigger recording.
3. For related cameras, you can use the Browser in "multi-camera" mode to view synchronised playback of multiple cameras. Picture-in-picture is not planned.
4. Currently if you double-click on a camera view in a group window or the main "All cameras" window you will get an individual camera preview window, which can be any size you like - it can almost fill the screen if you want it to, and the size will be remembered for next time. When you are done simply close this individual camera window. I think this achieves exactly what you want.
5. SecuritySpy already support a full screen mode which is multiple-monitor aware: you can place any camera(s) on any monitor(s) to be displayed in full-screen mode.
6. Yes we are planning computer -> camera audio in the future.
7. I'm not sure exactly what you mean here. If you want a 1fps movie of motion-detection events throughout the day, the motion-detection capture feature can do this for you.
8. Yes I agree. Currently though this can be achieved using simple AppleScripts - we have some example AppleScripts that demonstrate this.
9. Good idea. I'll see if we can integrate this in the future.
10. Yes, triggering on the IO port inputs is planned for the future. I'm not sure why the light on/off switch doesn't work, we have one of these cameras here so I'll test this and check. You could check if you have entered admin username/password details for the camera in the Video Device Settings window, as the camera may require admin login (not just user login) to set the light on and off.
11. This is being developed.
12. I can see this would be a nice feature, however very difficult to implement and very resource-intensive. To achieve what you want, we could add an option in the contextual menu so that from any camera view you could select this option and jump directly to that camera in the Browser to review the footage just captured. -
hooray for potentially adding the audio recording ability. Bring it on!! I really would like to know when the dog is barking.
-
To clarify, SecuritySpy can already record audio from cameras, and can play this live audio via the computer's speakers (click the small speaker icon next to the camera in the Camera Status window to hear the live audio). It can also trigger recording when the incoming audio level exceeds a certain level.
-
Thanks for taking the time to reply to all these - I appreciate the responsiveness.
1) Great!
2) No, I've tried the 2 second delay and that doesn't quite do it. Trees waving in the wind and casting shadows on the ground is most often the culprit, though moving clouds also triggers things. Having a maximum number of interframe (or within the interval) pixel-delta as a cutoff point would possibly be interesting, but would require experimentation. There is an argument that this would cause someone walking across the yard during a windy day to be uncaptured, since they would be masked by the larger movements of shadows causing the motion detection to not trigger. However, after 8 hours of near-continuous, full-motion capture this kind of becomes a lower-priority issue. I have TL going, so to find the needle in the haystack I could look at that log. However, having 4000 events (no exaggeration) in a day on a single camera due to tree motion makes that camera mostly useless and I have to shut it down otherwise my disk and CPU are burned to ashes. I've also found that automatic light timers in a room will trigger an event (lights shutting off or turning on in a room, though turning on seems to be more often a false alarm as neon tubes sometimes take a few seconds to stutter to life and therefore cross the 2 second boundary.)
3) The multi-camera mode leaves quite a bit to be desired in many ways - I've not really found it terribly useful. I think this falls into # 11 below.
4) Yes, it's close, but a) doesn't work in full-screen mode, and b) doesn't auto-retreat - the window stays and has to be manually closed, leading to clutter and cover over the main camera window.
5) From what I've seen, the full-screen mode with multi-monitors doesn't allow work to be done on the other monitor - as soon as a click or key is pressed, the full-screen method goes away. Is this now different? (I no longer have it running on a multi-screen system due to this problem, so I can't test.)
6) Great. The SIP functionality is interesting, and kind of complex, but is really the best way to do things for those cameras that support it. The other ways I've seen rely heavily on very fiddly and probably proprietary browser extension stuff. I've got my Grandstream firmware cameras talking to Asterisk quite well, and doing tricks like putting all the cameras into a conference bridge (one-way) so the remote party (via phone or soft client) can listen to the entire area at once, and can unmute and then talk back via overhead paging system. I opted for the property-wide paging system in the other direction since getting amplifiers and speakers on each camera was a power-wiring nightmare, even with POE splitters. (yes, this is legal since I have visible disclaimers in place about audio monitoring)
7) I think it's easier if I give an example: I often create timelapses of people building things or doing some sort of project. With most projects, 99.9% of the time nothing is happening - the scene is quiescent. What I want to capture, in time-lapse form, are the moments when there is activity. So when the motion detection threshold is triggered (causing a motion detection event, so this is not new development) I'd like to _also_ take 1 frame per X seconds (or a minimum of 1 frame immediately, if the timer has elapsed) and store that to the timelapse video. As it stands today on a day-long timelapse (as an example) I have a HUGE timelapse film of nothing happening, but during the 5 minutes every hour or so that something DOES happen in front of the camera, I have to pay excruciatingly close attention during the playback to see what just changed in the scene - I can't even blink while watching the browser playback, or I'll miss it. If I knew that the timelapse frames were only "firing" when there was motion in the scene, I'd have a nearly 100% useful timelapse film. Does this make sense? This is not for capture of things that might be too small to trigger the motion detection trigger - this is for making more useful, rapid, and tightly compacted versions of an interval in time (doorway, construction project, parking lot, etc.)
8) OK, that's great - I somehow missed that one could change settings, or didn't think about doing that with AS->curl. Will try! (Though the more I think about this, why aren't all those elements exposed in AppleScript? Going from Applescript to a curl command seems a bit fragile and complex.)
9) OK. This is complex but any camera outdoors needs to know what to do when the lighting changes radically. IR filters on many cameras change the thresholds significantly (moths are apparently really REALLY interested in my cameras.) I suppose I could write this myself with Applescript, but that's probably beyond 99.9% of the userbase.
10) Triggering on IO: This is a really useful one, since it's far easier to attach a doorbell to a camera that's already there (or a gate control, or whatever) than it is to run a whole new infrastructure of control elements. Having IO events able to call Applescript with some indicator is equally important - which IO pin went high or low, as an example. Axis light: Huh... I tried it again after rebooting the device (on for +8 months) and it works. Ignore this one I guess!
11) Great! Let me know if you want a beta or alpha tester.
12) I understand it's resource intensive, but perhaps it could be turned on/off per camera. These days, RAM is fairly cheap - this is just buffer space. If there isn't enough RAM, notify the user by making their historical slider shorter or give a RAM budget in the configuration UI. To try this with a contextual menu is fairly clunky. Hover/scroll would be ideal and would encourage security staff to actually use it. Having close experience with the security personnel, I can say somewhat safely that anything that requires them to click and pull down two levels of menu is a non-starter.
-
Also, extending comment #8: I don't see a way to trigger I/O (or the light on my Axis1054) via the web interface or via AppleScript. Am I missing something? (Maybe this is really a request to extend the web interface to have an I/O control panel across the bottom of cameras that support that type of thing.)
-
The PC Software Go 1984 does a differentiation between simple color change and also has a setting that can be set to define how much movement is too much. By pixel counting, light changes, passing by car-lights and clouds can be filtered out.
On Go 1984 I was able to use the outside cameras on Securityspy I wake up and have 64 alerts and false recordings. Its false positive only.
This thread is 2 years old, please make Securityspy outside compatible considering motion detection. -
Hi @roads - SecuritySpy also does what you describe: it ignores movement that is "too much" that could indicate that the camera has changed its aperture or low-light compensation level, or switched to day/night mode. These things typically result in transient whole-frame changes.
However car headlights moving is perfectly reasonable motion to capture: a user might very well want to capture all cars that pass, so we can't set SecuritySpy to ignore this (though we could I suppose add an extra setting to define how much motion is "too much").
If you want to filter out all cars that pass, but presumably capture pedestrians (?) then increase the "trigger time" setting in SecuritySpy. Try 2-3 seconds. Anything that is more transient will be ignored. -
IMHO, motion detection is of limited usefulness out of doors. The reasons for this are well described above, and are very hard to overcome, without reducing sensitivity so far that intrusion events are not recorded. The answer is simple and very effective: use an external input on one of the cameras and connect to another sensor, such as a PIR sensor, or even better, a beam sensor. Beam sensors are very good at detecting only human, vehicle, or large animal intrusion, while ignoring rain, birds, leaves, cats, and chickens. Version 4 of the software has the ability to start recording on multiple cameras, based on the input from the sensor connected camera. In version 3 this can be achieved with a simple script.
-
I believe that having a per-camera ability to modify the "overload" movement threshold to squelch motion detection would be a useful thing.
