Motioneye: Inconsistent units

[ltjessem]

Why is Frame Change Threshold in percent and Maximum Change Threshold in pixels? Show Frame Changes displays pixels as well, but it's not helpful for adjusting parameters when you need an additional conversion to percentage.

Also, Motion Gap is in seconds while Captured Before, Captured After and Minimum Motion Frames are in frames, again requiring a calculation, albeit a simpler one.

In my opinion the first group should all be in pixels to match up with the Show Frame Changes output. The second groups should all be seconds.

[brunetton]

Indeed. I came across this "problem" today, while fine-tuning threshold.
Workaroud used: manually edit camera's settings conf file (/data/etc/camera-x.conf).

Solution proposed

• the UI could show the Frame Change Threshold % in pixels (current value written in conf file) to allow user to have an idea of this value compared to values reported by motion when activating Show Frame Changes option
• the UI could let user enter specific value, in pixels and store it as it to conf file:
  
  (changing the value in % dynamically changes the value in pixels, and vice versa)

[AlquistArj]

I agree, when fine tuning it is a little irritating having to manually convert the percentage into a pixel threshold (as that clearly depends on the resolution of the camera setting). Perhaps in addition to showing the number of pixels changed at the top right of each frame you could add the corresponding percentage (to 1 dp)? That'd surely be an easy change?

[zagrim]

@AlquistArj Unfortunately that is not an easy change for MotionEye, or actually it is quite impossible for MotionEye, since it is Motion which is overlaying the number of changed pixels in the video frames when the camera is configured with text_changes on (set by MotionEye when the UI option "Show Frame Changes" is enabled).

For Motion project that change should be easy to implement, though, and if you want you can request it here: https://github.com/Motion-Project/motion/issues

[ltjessem]

It's perfectly fine for Motion to be showing pixels in the overlay. Motion uses pixels for Frame Change Threshold so it makes sense that their overlay also uses pixels, this is consistency. On the other hand, MotionEye is converting this to a percentage in the UI here for whatever reason, which causes issues trying to tune using pixels vs %.

It's very much a MotionEye issue.

[AlquistArj]

@ltjessem ok, that makes sense. I hadn't appreciated that the pixel count is added by motion rather than motionEye. In which case converting the percentage to pixels based on the selected camera resolution in the UI would be a great help.