Search options (Page 14 of 131)

Updated calibration dialog.

- New: flipping and rotating axes, pixel size hint, coordinates offset.
- Improved: using numeric box instead of text box to support mouse scroll to change the numbers.
- Plus: added a menu in the coordinate system drawing to re-align it with the grid.

Pixel size can be thought of as the error bar at the center of the grid. If the digitization is off by one pixel this is how much it is off in real world units. (in pixels of the original video, not screen pixels, always good to zoom in).

No special treatment for tracking. The offset is just added at the end so it should work as before. I don't think tracking both the coordinate system and the calibration grid is a realistic scenario so until someone comes with a real use-case it will just keep giving precedence to the grid. We'll see later how that works with camera motion compensation.

Known limitation: The scatter plot diagram is showing the axes un-flipped.

Which version of Kinovea? Is this Windows 11 on a desktop/laptop or on a tablet computer? Do you have NVidia Broadcast virtual webcam enabled?

To be clear, you can track the grid, but you can also track the coordinate system origin, independently. If you first move the coordinate system out of the grid corner, then you can right click > Tracking > Start tracking. If both the coordinate system origin and the calibration grid are tracked, then the priority is given to the grid.

To be honest I think the only real use-case of tracking the calibration grid itself is when the camera is moving. I've been working on camera motion compensation for a while and it should be in the next version, although I'm not yet sure if the first version will interact correctly with measurements (it's working for placing drawings that "stick" on world objects despite camera motion, this is already useful for visualizing trajectories and drawing in world space).

Tracking the system's origin has a use case outside camera motion, it's for example when you want to measure something relatively to something else (moving coordinate system). It's not very common in my experience though.

Yeah I think having a configurable "offset" to the coordinate system would be nice. The two options aren't mutually exclusive. This might be useful in the context of camera tracking actually. To set up your calibration in the middle of the sequence but still get meaningful values. Although I'm not sure if camera tracking will be precise enough for making measurements.

OK but it needs to interact nicely with changing the origin manually from dragging the Coordinate system object around by the axes or the origin. If we change manually on screen and we come back in this dialog it needs to show a correct value.

And we can also activate tracking on the coordinate system. In this case the value we would show here would be a bit tricky, maybe in this case it should be grayed out.

There are two ways to think about this I think. Option 1: this defines where the origin of the coordinate system is in relation to the calibration grid, this is what you wrote. When we activate the display of the coordinate system it will be moved to this new origin. If the origin is far enough it could be outside the image.

Option 2: it could define the coordinate at the origin, that is, a fixed offset applied to the coordinate system such that the intersection of the axes is not {0, 0} but something else.

This is sort of what I do in the new "Distance grid" object (on horizontal axis only though, but it could be done on two axes). In the calibration of this grid you set two distances, for example 6m and 10m, and then even a coordinate on the main axis is already at 6m. This was designed as an experiment for long jump measurements. The important advantage of doing it this way is when the true origin of your coordinate system is way outside the image. So we have a camera looking at the end of the long jump pit with markers at known distance. The coordinate system is still aligned with the grid but the values are pre-transformed. (edit: it doesn't really work fully with the coordinate system at the moment though, only for the distance line inside the grid).

Can you tell if your use case is more amenable to one way or the other? I wonder if people that want to change the origin numerically are actually looking for option 2.

A follow up on this, the culprit was apparently Nvidia Broadcast and its virtual webcam. Will try to get this fixed but in the meantime if you have a similar problem try to deactivate Nvidia Broadcast to see if it fixes the issue.

Regarding the label, I've been wondering if this should be extended to all options in all tools. Like if you change the color of a line the next created line starts with this color. And then hide the whole color profile thing. I also want to have the style options of the current object directly available in the new right-side panel at some point.

Right now the way to prevent the shortcuts to be applied to a particular stopwatch is to use the menu Options > Locked on that stopwatch. It's the only thing this menu does (you can still start/stop/split manually). I admit it's still not perfect though, it has already happened to me a few times to forget to set it and mess up the times. If you show the label above the stopwatch, it also has a little square icon which represent the "locked" state.

edit: Maybe another idea would be to check if the stopwatch already has data points in the future and in that case ignore the shortcuts. I think in most cases it should be the right thing to do. If we really want to accept shortcuts in the middle of the existing times maybe *this* can be the explicit option to activate. The only issue with this approach is that it will still potentially add unwanted time points at the end.