Search options (Page 43 of 133)

Hi,

First I want to say that I'm very motivated to improve this part of the application

I thought I had put a comment inside the XML to document the source but apparently I must have forgotten… Unfortunately at the moment I can't find the exact reference I used for the coefficients. It might have been from a book annex.

Please point to popular models that are used in your field and we'll build the corresponding tools. I want the user to be able to pick between several models anyway.

Yeah the profile model is a bit restrictive. I actually considered replacing it for last release. It was created based on a specific scenario where it was not used to draw over a person segments but to act as a quick reference diagram on the side. The person would move the segments a bit to make a canonical pose as a note. I don't think this scenario is in use anymore.

Yes if we have the coefficients based on the existing segments. Post them and we'll build the tool.

I started to update the format for last release, and plan to update it again to make it easier to display computed measures.

My goal would be to be able to display ratios, additions of two segments length, etc. There is a ton of these standard metrics that can be done based on anatomical landmarks and are referenced throughout the literature.

I'm still at the design phase for the framework to make these computations possible. My thinking so far is to add a concept of variables and operators and the tool would declaratively describe a resulting variable by using an algebraic expression tree. This would replace the "computed point" concept and be way more powerful.

There are also several primitives that are missing at the moment, like the possibility to get the angle between two non-intersecting segments, and get the center of a best-fit circle from a few points.

Please send how you perform the measure manually and any bibliographical references we can use. This will greatly help this design phase.

It has been a dream of mine but it would be a very big undertaking. For the initial skeleton structure it might be possible to use another application or a Kinovea key frame and convert/import the set of segments into a tool, but that won't help with variables and behavior. So it is going to be a manual process for the time being.

Cool, thanks.

Yeah, I definitely want to make the distortion correction more robust. And also provide a number of presets for popular cameras, as a middle ground between not being able to measure anything and doing the manual calibration yourself.

I tracked down the issue with the mp4 file.
The problem is when the KVA is imported in Kinovea. It's a bug in Kinovea I don't think you can work around it in the script. The mp4 file has timestamps that don't start at zero and when the track data is imported it wasn't adjusted to take that into account.

Yes that would be great. As you may have noticed the tracking for angles and other drawings is handled differently. It's using the Trackability block at the end of the KVA and each point in each drawing has its own timeline there. The "id" field on TrackableDrawing references a drawing declared earlier in a Keyframe block.

It would be super cool to convert the OpenPose json into a tracked human figure. We can create a suitable custom tool to match the number of points output from OpenPose.

It's using 25 keypoints right?
Are all the keypoint locations always filled even when part of the body is occluded? If yes that would simplify things a lot.

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.