Search options (Page 68 of 133)

Effectivement, ça ce n'est pas possible dans l'état actuel des choses. Le suivi des outils fonctionne un peu en mode « tout ou rien » sur l'ensemble de la zone de travail…

Hmm, thanks for the report. I admit I hadn't considered the case where the only camera is a network camera. This will need to be fixed.

I meant that the problem is in Kinovea. The menu is created from names of files found in the folder, using a simple alphabetic sort, which causes this kind of issue. I have recently integrated the more natural sorting algorithm in the main file explorer. It will have to be used there as well.
(If you want to have a look, the problem is in ScreenManager/PlayerScreen/Drawings/GenericPosture/GenericPostureManager.cs, line 71. And an example correct sort in FileBrowser/UserInterface/FileBrowserUserInterface.cs, line 440. The idea would be to first get the list of files from Directory.GetFiles in a variable, then sort it properly before looping on it in the foreach.)

It could also be considered as small plug-ins. I quite like the extension mechanism in Firefox, Wordpress and others where you can browse the available extensions from within the software itself and install them with a few clicks, all without quiting the software. With some added logic, the new tools could even be loaded and added dynamically without restarting.

Hi,
Here is the tutorial : http://www.kinovea.org/en/tutorial-crea … stom-tool/

I realize that what is needed now is a reference doc on the available impacts and constraints. (They can be found by looking at the existing tools or in the sources).

Yes, I thought about this a bit yesterday and I think we don't even need to convert back to linear speed.
With a filled sector of a known angle on a rotating plate and measuring the apparent angle of the sector during video, we can directly infer the shutter speed. I came up with the following:

shutter speed = (measured angle / known angle) × angular speed

- shutter speed: in s-¹
- measured angle: in °. Angle measured on video frame.
- known angle: in °. Actual angle measured physically.
- angular speed: in °/s.

The advantage of this is that it's independent of the distance of the rotating plate to the camera, and doesn't involve any calibration of the space.
(We can even instead divide the angular speed by the "blur factor" to get the denominator of the more familiar "1/x of a second" notation).

I'll try to set up the experiment tomorrow to see if I can deduce the shutter speed of some cameras.
The same setup under various illuminations would help understand if a given camera has several shutter speed levels during video, if it adjust itself during a single shoot, how often does this adjustment occur, etc.

Thanks for all the valuable info

Another set of experiments would be to compile a list of the typical shutter speeds required for an acceptable image, for each sport.

For example, considering a golf swing rotating at x°/s, filmed at a standard distance, what is an average shutter speeds from which the blur start to vanish.

In this video of a football kick, they start to have good results as low as 1/300. But this will probably be too slow for golf or baseball swings. On bike, we could have various values depending on RPM. Even just having order of magnitudes and relative values would be interesting.

As you pointed, the object displacement during a single image is equal to the velocity of the object divided by shutter speed. If we know the typical speed of a given sport, we can start to compile some values.

Then it would be interesting to convert these values into number of pixel smeared for a typical camera distance. It would help setting up tracking.