1,531

(6 replies, posted in Bug reports)

litch09 wrote:

Another option that might work is that if the mouse button is held down for a period and dragged out then this would allow the size of the box to be set from the outset.

Hmm, this may interfere with the manual moving of the box ? (when manually adjusting the tracked point)

1,532

(6 replies, posted in Bug reports)

litch09 wrote:

Is there a way of adjusting the bounds that tracking algorithm searches in to prevent this from happening?

Currently this is not possible without changing the source code.
The feature window is computed to be 5% of the image size and the search window is 20%. I agree that the ability to tweak this is desirable.

As often the hard part will be to introduce this possibility without disrupting the general flow of using the default values.
One way might be to have a "hot" lower right corner on the outter search window that would be draggable (maybe with a little hint as for the magnifier window).
(This would increase or decrease both the feature window and the search window though, keeping the ×4 factor between the two. I have tried software where both rectangles can be sized (i.e: Adobe After Effects), and I find it rather hard to manage…)
Or maybe it would make more sense that this dragging would only change the outter window (?)

In any cases, I'm thinking that this possibility should have to be enabled explicitely from the configuration window. This way the default behavior is untouched and the user doesn't risk changing the size of the window when he just want to move it around. (which is very annoying when it happens).

litch09 wrote:

Also, would it be possible to add a feature which calculates the angle between three points. This might be embedded in the angle tool, so that the three points which define the angle can all be tracked at once. Just a thought.

Yes that would be great. It is on the to-do list, but nothing have been done yet.

I just stumbled upon this page:
MoFrames, making movement complexity visible. (Martin Hilpoltsteiner)

If I understood correctly, he is taking the individual images of the person and put them one after the other in a 3D space, then render the view from various angles.

It gives pretty interesting results to grasp volumes used during the action !

Here is a person jumping on a trampoline.
(There are plenty more on the site)

http://www.moframes.net/pictures/moframes_trampoline_02.jpg

daww wrote:

I recieved today a casio exilim fh100 (high speed camera), I haven't been able to use the capture feature with it?
Are you aware of a way to use it? by forcing the directshow?

I don't think these cameras can do direct streaming can they ? Do they have a "webcam" mode ?

If you find a way (any way) to display on the PC screen what the camera is currently imaging, please share program/method used. (I honestly don't know if it's feasible or not).
Thanks

Yes, I agree the magnifier should better integrate with the drawing tools.

I would like to use this thread to gather ideas about what could be done in this area.
If I understand correctly, what you suggest for a start is:
- when drawing on top of the magnifier glass, the drawing should not register to the global image underneath, but should relate to the magnified area.
- the mouse cursor should change to reflect this and to give a more precise pointing tool.

CAR_UARD wrote:

I go to Set original speed and write 29,97 fps.

In this dialog, you should set the frame rate at which the video was captured.
It is common for example that a video is captured at 300fps and the resulting video file plays at 30fps. In this case, you would set "original speed" to 300, and it will say "video is 10x slower than original."

Ah, yes, I get it. This had no effect at some point and has been fixed after the version 0.8.7 was released. So you'll need to use the experimental version.
It was discussed in this thread : Ball velocity calculation with non 29.97 fps video

1,537

(4 replies, posted in Bug reports)

Hmm, I just tried again and it didn't crash this time, a lovely not systematic bug tongue
Anyway, I've added it in the bug tracker (m220).

Please try to save to MP4 or AVI first, make several tests, and report if it makes any difference, thanks.

1,538

(4 replies, posted in Bug reports)

wildrobo wrote:

It then should the correct duration and things played fine. However the back arrow key would not work.  The forward arrow would.  Any thoughts?

That happens with some encoding profiles, I'm interested in knowing more about which output options you used.

1,539

(4 replies, posted in Bug reports)

Oh, are you using the dual export, while the overlay is activated ?

Ah, yes, I got the crash too. I thought I had checked that but apparently I didn't. Thanks for the report.

1,540

(1 replies, posted in General)

Currently it is either maxed at 60 frames or visible for the whole video.
However that max value was set arbitrarily and could be changed if it makes more sense.
The max could be 180 for example. (6 seconds at 30fps)

Some have expressed interest in having the fading only "after" the event.
Some would like labels that can stay 100% visible for a given period of time.
It's primarily an issue of not crowding the interface for everybody with options that only a handful use. So if anyone have ideas about how to integrate these cleanly in the interface (new control for example), they are welcome smile

CAR_UARD wrote:

Once the video is calibrated, speed measurement is exactly the same rather the video is at 25 fps or 300 fps

I'm not reproducing this issue… If I have a tracking path configured to display speed, and a calibration line somewhere, each time I change the framerate through "High-speed camera" menu, the speed displayed on the track reflects the change. Is it the right context ?

You do need to have a calibration line somewhere, otherwise the speed is in pixels/frame and that doesn't change with the framerate.

TeamTermin wrote:

Just wondering if there are any updates on the capture feature?

I more or less went into "vacation mode" regarding Kinovea for july and august smile
I'll try to deliver a new experimental version in the next few weeks. The priority will be fixing the issues with capture screen and the Windows 7 UI glitches.

daww wrote:

had to highlight the numbers already in, then right click to hit delete then I could write down my file name.

Well, there is one thing that could explain that. When you have the text highlighted, if the mouse goes away and enter some other part of the user interface like the file explorer or the main screen, then the focus is transferred to this area and lost on the textbox. You have to keep the cursor within the bottom area of the interface. This was done to enable other things like keyboard navigation and mousescrolling depending on the area where the mouse is.

daww wrote:

After capturing a video in a specified folder the explorer doesn't show it

Hmm, I don't think it is the responsibility of the recording program to refresh the file explorer. Probably just hit F5 to refresh it and you'll see the file appear.

daww wrote:

Would it be possible for Kinovea to support a remote, at least for recording a video away from the keyboard.?

One prerequitise to this is that I need a remote to test. By coincidence, a friend gave me a remote he's not using today. I haven't tried and I don't know if I can install it on my PC though.
Anyway, I'll see how this stuff works and see if something can be done.

1,543

(2 replies, posted in Ideas and feature requests)

Hi,
That is not currently possible.
However you can make a single drawing visible for the whole video and not the others. You would do that by right-clicking the drawing, go into "Persistence" menu, uncheck "Use default value" and check "Always visible".

1,544

(2 replies, posted in Ideas and feature requests)

Hi,
Basically two types of shapes are being considered.
1. basic geometric drawings (rectangles and ellipses). This is not implemented yet.
2. Complex shapes that the user can modify or even create himself in an SVG editor. This is known as "Observational References" and can be as complex as you want. They were introduced in experimental version 0.8.8 (maybe not fully polished), there is a screenshot in this thread.

1,545

(4 replies, posted in Bug reports)

Probably some people will only want the actual values as it is now, which means a configuration window needs to be added somewhere. Also, you may want to set the "granularity" of the target timescale (hundredth, thousandth…)

The continuous timeline has to be rebuilt from code. The internal time representation doesn't align with hundredth of seconds or anything. To build it, it will be possible to loop over all the positions of the target representation and figure out how far we are of the two adjacent actual positions.
Interpolating the spatial position to subpixel will be straightforward, but some people may prefer integer values… (Also I think we can get subpixel accuracy from the automatic tracking.) So another option or checkbox somewhere.

All in all, to do things properly, a new page in the preferences is probably needed. (and it could host the "coordinate system origin" button).

Or… Or this could be the standard behavior and no options to change it need to be added. Currently the export is dependent on the framerate because it's the fundamental unit of time of the video…
Ah…