ZoneMinder Forums

Interesting discussion.
I am not sure if using this approach is particularly robust because it also depends on fps of capture at ZM. ZoneMinder always checks for preclusive zones first and then the rest, for a particular frame. (ref code)
I'm not sure it will always be the case that you can rely on one zone always being triggered before the other in different frames (which is what I think you are relying on)

If you are a coder, another approach is to use ZM to detect a 'train' (which really is just a rectangular zone, long enough in the frame to catch only trains) and then write your own script to process that frame, and say another frame 0.5 seconds later. You take those two frames, and use OpenCV's optical flow API to get a relative direction. I haven't done this myself, you'll need to explore, but its likely a more deterministic path.

Thanks. OpenCV is a good idea. I've heard of it and, before I discovered ZoneMinder, I thought I'd need to go down some sort of comparative image analysis to do what I want to do. I'm not a coder, at least not with modern technologies. I used to write amateur code (C, Fortran) many years ago. I've played a little with python. Although I'm not a coder I'm willing to jump in with both feet and not let that stop me if I need to go that route.

I'm hopeful that if I 1/ keep the detection areas quite small and 2/ space them far enough apart that a given train will hit the appropriate active area and preclusive area at basically the same time - but for the two different sensors, that I can have something that will work. I feel very fortunate in that, given it's a train, where the motion will occur is EXCEEDINGLY predictable and reliable. If this doesn't prove robust enough my next idea is to get a second camera. Total line of sight from my house is probably 1/10th of a mi of track. So I could train a camera on each end and then just look at time stamps of motion events (forget the preclusive approach) to determine direction (and even speed). When one detects motion the other will not so I'll know where it's coming from.

Here is a short blog article I wrote this morning about why I'm doing this. I'm very much using an iterative/baby steps approach to this. I have no qualms letting people use (when it gets to that point) a solution that might have all sorts of warts and issues. But i'll keep iterating and trying to improve it.

http://jimhconsulting.com/blog/trainalert

A deviation but since we are on trains.
https://svds.com/tensorflow-image-recog ... pberry-pi/ and this post on how they detect motin direction https://www.svds.com/streaming-video-analysis-python/

I read the blog, I see the goals you have set. I have done some work with zoneminder and the neural network Darknet/YOLO . Did manage to get some results. here is some discussion on this viewtopic.php?f=36&t=26222&hilit=YOLO

I will look into using OpenCV and the Optical Flow API...see if I can get something to work.

I built opencv and have it running smoothly and testing the opt_flow.py PYTHON example program and it looks promising. Some deft coding will be required to mate ZM stream to be utilized but there looks to be some PHP bindings that may make it easier. The CPU loads will be a challenge apparently......Also working on a modified version of zm-alarm.pl to determine train direction, which maybe a much much lighter solution. If the logic can be sorted out.
Debian 9 "Stretch"
ZM 1.30.4
OpenCV 3.2.0