961

(22 replies, posted in General)

jonh wrote:

Thanks Joan thats great. Got the first tool completed, attached here http://db.tt/OyqvTEuy if anyone wants a horse frame tool.

Nice smile
Oh, I see there is a problem in how the files are sorted for the menu… It should use alphanumeric sorting instead of alphabetic, so that tool 10 doesn't end up between tools 1 and 2.

jonh wrote:

A suggestion, what about a central store for forum members to upload their tools to and share developements with each other?
Stage 2 I suppose is how to make the data from these custom tools exportable, but I seem to remember reading your already working on that for a future version.

Here is my wildest dream:
- An online editor where you can visually create a custom tool with ease, using dragging and dropping, buttons, etc.
- You would be able to fork an existing tool, import a background image for ref, define constraints through comboboxes, etc.
- Once done, the tool could be saved as a draft in a personal space or published in a common repository.
- Then from within Kinovea, a special module would let you browse all the published tools, and import them directly.

There are several hurdles in the way, but so far I have JavaScript code loading a tool from its XML and drawing it as SVG objects in an HTML page (using raphaël.js library for creating SVG on the fly).

Not all aspects are dependant on each other though. If there is a common repository of user contributed tools, even if its populated manually, the importing mechanics in Kinovea can be worked out even before the HTML5 editor is finalized.

962

(22 replies, posted in General)

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).

963

(22 replies, posted in General)

jonh wrote:
joan wrote:

Creating the same tools with stretchable limbs is quite easy. I'll try to finish the tutorial on how to go about creating a simple tool.

A tutorial on creating & editing tools would be fantastic. I have a few ideas for new tools but they are specific to my needs & doubt anyone else would be interested. Look forward to it. smile

Yes absolutely. I have a draft lying around, I'll publish it sometime this week.

964

(0 replies, posted in General)

Hi,

I have recoded the idea backlog in more modern technologies.
It replaces the old one, same address:

http://www.kinovea.org/ideas/

At the moment the mechanics is the same : you have unlimited votes to cast, one per idea.
The categories are replaced by tags, and you can filter the list by a tag or by a search term.

One new thing, apart the look and feel, is that you can unvote an idea that you voted on earlier. (You still cannot downvote ideas, I want to keep this in the spirit of a brainstorming).

I have reset the vote counters. (Some votes had been cast by web indexing robots). I'm sure the same stuff will bubble up in a few weeks of time. (I have the old values backed up on my machine anyway, I know the popular demands smile).

I tested quickly on Chrome, Firefox, IE9, IE8 and IE7. Please report any bug I have missed in this thread.

I seriously considered switching to a third party solution like UserVoice or GetSatisfaction. In the end I wanted simplicity and grouping by tags. Maybe next time. It also helped me sharpen my web programming before trying to write a viewer/editor for custom tools tongue

965

(2 replies, posted in General)

Hi,
For a start I should update the info on the wiki which is quite outdated by now.

The source code lives here : https://bitbucket.org/kinovea/kinovea/src
The most basic tools needed will be a mercurial client to pull the sources (ex: TortoiseHg) and a C# IDE (ex: SharpDevelop) to build.

Getting the code to build and run on your machine is the first step. Once you get that you can start exploring, test the latest additions, put a breakpoint in the code and follow what it does, etc.

966

(23 replies, posted in General)

Chas Tennis wrote:

(The video of a straight line rotating with a known rate can be used to measure the motion blur and calculate the camera's exposure time.)

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.

967

(4 replies, posted in Bug reports)

Hi,
Regarding your first message, there are some reported issues with AVCHD, but I think "twice too fast" is a first.

What is the camera brand and model that produced the files ?
Do they play back fine in VLC or other players ?
Do you use version 0.8.15 or 0.8.19 ?
Could you send a small sample (filming a clock for example) to joan at kinovea dot org. (For testing).

Thanks

Thanks for all the valuable info smile

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.

969

(23 replies, posted in General)

Chas Tennis wrote:

If the AUTO control selects faster shutter speeds for higher light levels, the motion blur might be much reduced in strong illumination.

Ha! I wonder if it's possible to somehow trick the camera into thinking there is more light than meets the eye so that it selects a faster shutter speed…

970

(23 replies, posted in General)

Yes the shape distortion makes it harder to track…

Regarding the imaging hardware, the ideal results would be obtained with

  • high frame rate - more frames means the shape will change less from frame to frame and has less chance to disappear outside the search window.

  • high shutter speed - will better stop freeze the moving object as opposed of creating the blurry shape you have in your video.

Control of shutter speed is generally the hardest to get as camcorders/cameras/webcams are built to create movies pleasing to the eye when played back, and so for the vendors the blur is actually a feature rather than a bug mad

For the markers the plain circular shape you have is good. Avoid shapes that would not look the same when rotated, like a rectangle or a triangle. Another thing to experiment with would be to have another smaller circular disk, say half the size, inside the main one, with a contrasting colour.

The size of the target is also important, for that you can switch to the regular trajectory tool (right click in an empty area on the video), the inner rectangle is the actual target being tracked. The marker should take as much of its space as possible. (The outter rectangle is the search window).

Keep us posted with the experiments smile

971

(3 replies, posted in Bug reports)

The build number shouldn't be necessary since except in some very specific cases, there is only one instance of a particular version.
Some instances with similar version number can sometimes be built for testing of a new translation, a specific bugfix or feature. They don't spread and should be deleted and replaced as soon as the actual version is released. wink

Currently the fix is only at the source level in the source code repository.

The video format shouldn't have any bearing in the color issue, that information is stored in the KVA file.

972

(3 replies, posted in Bug reports)

OK, I've found the issue with position/size.
When a generic posture / custom tool is added manually, there is some code that scales it relatively to the image size, to give it a sensible size.

Unfortunately, the same bit of code is also run when the tool comes from a KVA, even though it has already been positioned and sized manually.

This impacts all custom tools, flipped or not. Simply saving and reloading will provoke a change in position and size. The more the image size is different from 800x600 (the reference canvas size for custom tools) the more this will be apparent.
(Fixed in dev version)

The fact that you loose the color still eludes me. I can open your KVA fine and the tool is green.

973

(5 replies, posted in General)

Oh, I added the video plugin for the forum by the way. Testing it with your video right now:

[video]http://youtu.be/2xmI7utNZNw[/video]

974

(23 replies, posted in General)

Hi,
You must right click the added skeleton itself, to get to its specific context menu. There you'll get another "Track path" option, which will track the points of the tool itself.

975

(5 replies, posted in General)

Nice smile
I think using markers is still important to get best results. Otherwise even if the points seem to be locked on target, they actually make some small movements around and the angles are not top accurate.

Thanks for the bug report!