Send Motion-user mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Re: lightswitch (John Baker)
2. Re: lightswitch (Mike Wilson)
3. The New Motion and the New RPI (Jack Clift)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 Aug 2016 21:52:33 +0100
From: John Baker <[email protected]>
Subject: Re: [Motion-user] lightswitch
To: [email protected]
Message-ID:
<1470948753.1402923.692898977.2df7d...@webmail.messagingengine.com>
Content-Type: text/plain
Thank you for the clarification. I think we've got too much computer
science. :)
Lightswitch: More is less. How about it's inversed, so a larger figure
means ignore more light? "Keep increasing until the light changes stop
triggering motion".
Threshold: Pixels is of course more accurate, but % is more obvious.
Allow both. Think of how we could configure this via a user friendly web
interface - a slider called "motion detection" that moves between "low"
and "high" (ie a percentage).
On Thu, Aug 11, 2016, at 09:34 PM, Joerg Weber wrote:
> John,
>
> Yes, you are correct ref (3).
>
> Defining 'threshold' in percent would be much more inaccurate than
> pixels, giving less flexibility to the user.
> Defining 'lightswitch' in pixels is unnecessarily complex, as the user
> has to be aware of the total number of pixels in a frame at his specific
> resolution in order to get an idea of a good value to start with.
>
> There are a few more places, where we have different units - like frames
> vs. seconds - in pre_capture and post_capture. I know that it is
> confusing and we may change it in the future where it makes sense.
>
>
> Brgds Joerg.
>
>
> 11. August 2016 22:19 Uhr, "John Baker" <[email protected]> schrieb:
> > Right, so we have a number of issues here:
> >
> > 1. threshold is a number of pixels, not a percentage.
> > 2. lightswitch is a percentage change, not a number of pixels.
> > 3. If I read correctly, a lower lightswitch value implies "filter more",
> > ie a lightswitch figure of 95 would mean a 'motion frame' would be
> > dropped if 96+% of pixels had changed.
> >
> > Am I correct ref (3)?
> >
> > I wonder if this process can be simplified, starting with using a
> > percentage for (1), or allowing both threshold and lightswitch to be
> > specified as pixels or %?
> >
> > On Thu, Aug 11, 2016, at 08:59 PM, Joerg Weber wrote:
> >
> >> John,
> >>
> >> let me be more clear about it:
> >>
> >> Motion is detecting motion in a way, where it compares frame by frame at
> >> pixel level with an internal reference frame.
> >> If the number of changed pixels is above 'threshold', then this
> >> particular frame is declared a 'motion frame'.
> >>
> >> The lightswitch option can suppress this frame for not being a 'motion
> >> frame', when the percentage of changed pixels is above 'lightswitch'
> >> percent. Nothing more and nothing less.
> >>
> >> For a 'normal' use case, it is probably not a good idea to set
> >> 'lightswitch' to a value of 1 or 2. But we have tried to make motion as
> >> flexible as possible, so that people can use it for tasks, which we were
> >> not even able to think of. That's why it is not so easy to always
> >> recommend a typical value for certain options. But l believe that a
> >> typical range for lightswitch could be from 40 to 80 maybe.
> >>
> >> Brgds Joerg.
> >
> > ------------------------------------------------------------------------------
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. http://sdm.link/zohodev2dev
> > _______________________________________________
> > Motion-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/motion-user
> > http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
------------------------------
Message: 2
Date: Fri, 12 Aug 2016 00:16:42 +0000
From: Mike Wilson <[email protected]>
Subject: Re: [Motion-user] lightswitch
To: Motion discussion list <[email protected]>
Message-ID:
<caaveucpkvy-4k0+iuayi5rcs9s2ydjfnj7ercgzygzhvoj2...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
As an example, zoneminder allows for both pixels and percentage, but I
believe internally it just converts it all down to pixels.
This goes back to what was said earlier and how large we want to make
motion. Currently it is lean and complex to setup, but that gives it an
advantage in a reduced environment like a raspberry pi. If we add things
like an advanced configuration interface on it we would pull in more
dependencies and things, but it obviously has lots of advantages.
I think the problem is that many people use motion in many different ways.
Some want a full web server setup and some are just looking for a daemon
that looks at video for motion. Some even use it for offline detection on
video files. I think we need to be careful not to change motion into a tool
that only does what a portion of the users want, but at the same time I do
think there is much room for improvement.
Personally, I'm currently leaning toward motion only exposing a rest
interface and let a 3rd party or even a tool in a different repository on
the Motion-Project github that can be installed to optionally provide such
configuration pages. I would want this to support web sockets as well for
constant update as I would like to display a static page that doesn't have
to refresh to see new events. I know there has been talk about such a thing
recently.
On Thu, Aug 11, 2016 at 4:54 PM John Baker <[email protected]> wrote:
> Thank you for the clarification. I think we've got too much computer
> science. :)
>
> Lightswitch: More is less. How about it's inversed, so a larger figure
> means ignore more light? "Keep increasing until the light changes stop
> triggering motion".
>
> Threshold: Pixels is of course more accurate, but % is more obvious.
> Allow both. Think of how we could configure this via a user friendly web
> interface - a slider called "motion detection" that moves between "low"
> and "high" (ie a percentage).
>
>
>
>
> On Thu, Aug 11, 2016, at 09:34 PM, Joerg Weber wrote:
> > John,
> >
> > Yes, you are correct ref (3).
> >
> > Defining 'threshold' in percent would be much more inaccurate than
> > pixels, giving less flexibility to the user.
> > Defining 'lightswitch' in pixels is unnecessarily complex, as the user
> > has to be aware of the total number of pixels in a frame at his specific
> > resolution in order to get an idea of a good value to start with.
> >
> > There are a few more places, where we have different units - like frames
> > vs. seconds - in pre_capture and post_capture. I know that it is
> > confusing and we may change it in the future where it makes sense.
> >
> >
> > Brgds Joerg.
> >
> >
> > 11. August 2016 22:19 Uhr, "John Baker" <[email protected]> schrieb:
> > > Right, so we have a number of issues here:
> > >
> > > 1. threshold is a number of pixels, not a percentage.
> > > 2. lightswitch is a percentage change, not a number of pixels.
> > > 3. If I read correctly, a lower lightswitch value implies "filter
> more",
> > > ie a lightswitch figure of 95 would mean a 'motion frame' would be
> > > dropped if 96+% of pixels had changed.
> > >
> > > Am I correct ref (3)?
> > >
> > > I wonder if this process can be simplified, starting with using a
> > > percentage for (1), or allowing both threshold and lightswitch to be
> > > specified as pixels or %?
> > >
> > > On Thu, Aug 11, 2016, at 08:59 PM, Joerg Weber wrote:
> > >
> > >> John,
> > >>
> > >> let me be more clear about it:
> > >>
> > >> Motion is detecting motion in a way, where it compares frame by frame
> at
> > >> pixel level with an internal reference frame.
> > >> If the number of changed pixels is above 'threshold', then this
> > >> particular frame is declared a 'motion frame'.
> > >>
> > >> The lightswitch option can suppress this frame for not being a 'motion
> > >> frame', when the percentage of changed pixels is above 'lightswitch'
> > >> percent. Nothing more and nothing less.
> > >>
> > >> For a 'normal' use case, it is probably not a good idea to set
> > >> 'lightswitch' to a value of 1 or 2. But we have tried to make motion
> as
> > >> flexible as possible, so that people can use it for tasks, which we
> were
> > >> not even able to think of. That's why it is not so easy to always
> > >> recommend a typical value for certain options. But l believe that a
> > >> typical range for lightswitch could be from 40 to 80 maybe.
> > >>
> > >> Brgds Joerg.
> > >
> > >
> ------------------------------------------------------------------------------
> > > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> > > patterns at an interface-level. Reveals which users, apps, and
> protocols are
> > > consuming the most bandwidth. Provides multi-vendor support for
> NetFlow,
> > > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > > planning reports. http://sdm.link/zohodev2dev
> > > _______________________________________________
> > > Motion-user mailing list
> > > [email protected]
> > > https://lists.sourceforge.net/lists/listinfo/motion-user
> > > http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
> >
> >
> ------------------------------------------------------------------------------
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and
> > traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> > are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. http://sdm.link/zohodev2dev
> > _______________________________________________
> > Motion-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/motion-user
> > http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 3
Date: Fri, 12 Aug 2016 10:40:38 +1000
From: Jack Clift <[email protected]>
Subject: [Motion-user] The New Motion and the New RPI
To: motion <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hello All,
With the recent advent of new custody for the Motion initiative, and the new
version of RPI, is there a possibility to integrate native support for the RPI
camera? Presently getting to work involves installing 'mmal' 'fork' created /
maintained by dozencrows?
Regards
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
------------------------------
_______________________________________________
Motion-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/motion-user
End of Motion-user Digest, Vol 123, Issue 32
********************************************
