Search options (Page 40 of 129)

Yes kinetics computations would be nice, but we must be careful at not giving a false sense of accuracy… Any prior art showing how accurately this can be measured from video alone compared to a ground truth would be nice.

For example the acceleration is usually very approximate. We tested against the gravity ground truth by tracking a falling ball, and you have to have a very controlled environment to get correct results.

At the moment you cannot export speed and acceleration simultaneously on the same graph. I don't think having two different paths would help, you'll see the two trajectories in one graph, but still only one graph for each kinematic value. This would probably require a dedicated exporter with some options because some people will want the data sources in columns and others will want the type of data in columns.

So if you put a line somewhere it's in centimeters according to calibration but the speed measurement on the trajectory is in pixels/s?
Is it on a brand new file or re-opening a file that you already calibrated in the previous version?
Are you calibrating using a line or a grid?
What if you go to menu Tools > Linear kinematics, is the speed in px/s there too?

OK, I'll be adding a slider for pixel clock as soon as possible, sorry for the oversight. The default value is not the max possible and thus it restricts the selectable framerates. I'm not sure how that default value is computed.

It also looks like they have the dependency between framerate and exposure in the other way compared to other manufacturers, and I think their way is better. You set the framerate and the exposure is automatically constrained and capped to the reciprocal of the framerate. Other vendors do it the other way around and it confuses a lot of people that the framerate they set is not respected.

Hi,

There is currently no tool for measuring an area in Kinovea.
I was also thinking about this recently while updating the tools for the next version.

I was thinking about a drawing tool where you "paint" an area and then you can right click that shape and make it show the measured cm² or whatever based on calibration. This way you could draw exactly the silhouette of the person.

I think what you are mentioning is to discard all pixels that are similar enough to a given hue and count the rest. That might be simpler to use if the room can be set up this way. I'm not sure how accurate that will be though, there will always be missed pixels in the background and false positive in the foreground.

The advantage of the green screen method is that it could be dynamic for free, whereas the painted area would only work for a single frame and you would have to edit it after each change of posture. The drawback of the green screen method though is that it doesn't readily fit in the tool framework and the player pipeline so it will complicate the architecture.

So far there is no clear path. Are you or anyone aware of other software that provide that type of area measurement feature (and that are not using a depth camera to do so)? Can the green screen approach be mocked up in Photoshop or something to see how accurate it would be and what is influencing the results precision?

I agree it would be interesting and useful to have this feature with negative time.

Right now I'm not satisfied with how the stopwatch works and at some point I'll attempt to improve it.

To better understand the way it works internally consider that it has a "visibility start" and "visibility stop" and it has a "counting start" and "counting stop". The "counting" segment is always nested inside the "visibility" segment. The countdown mode is simply "inverting" the value of the counting.

The shortcomings at the moment is that you can't move the "visibility start" point, so once you put a stopwatch on the video it can never be moved back to an earlier point. And you can only move the "visibility end" point backwards in time with the "hide" menu.

I am trying to think of a way to make it more flexible.

The system you describe with the countdown going on in the negative makes me think that this would be better suited for a new tool that would let you set a single point in time, rather than a segment in time.

There is also another time tool that is missing, one that allow the measuring of several segments in a row, with or without gaps between them.

Another interesting one would be a "cyclic timer" tool that counts to a given time and auto-resets and starts counting again.

Hi,

I have addressed the following points for the next release:

1. Position of the text for angles

There is now a "textDistance" attribute on the angle node.

<Angle origin="1" leg1="2" leg2="3" signed="true" ccw="true" supplementary="false" radius="0" textDistance="40" tenth="true"/>

2. Double constraint fixed length + rotation steps.

The rotation steps constraint now has an attribute "keepDistance" that will force the point to stay at the same distance from the origin. I think it still didn't make sense to have a full multi-constraints system, as this was the only meaningful combination of two constraints.

<Constraint type="RotationSteps">
        <RotationSteps origin="1" leg1="0" step="5" keepDistance="true" />
</Constraint>

Note that the existing "DistanceToPoint" constraint supports the SHIFT modifier that forces segments to lock onto 45° steps. This is supported out of the box and doesn't need any specifics in the tool file.

3. Completely locked points.

There is now a "LockedInPlace" constraint that will simply ignore the applied motion.

<Constraint type="LockedInPlace" />

In addition to that, there is now a debug mode for the custom tools. It will be available from menu Options > Preferences > Drawings > General, check box "Custom tools debug mode". It will show the points ids, the segments ids and names, and angles ids and parameters. Counting starts at 0.