Hi,
If I understood:
- You have several videos in a folder on your computer.
- When you browse to this folder from within Kinovea, you don't only see some of the videos files.

Is this correct ?

1,532

(2 replies, posted in Français)

Bonjour,
Non, il n'existe pas pour l'instant de version compatible.
Plus d'infos:
- Autre fil sur le même sujet.
- Et un autre fil sur le même sujet.
- Autre fil dans le forum anglais.

So, I was downloading some YouTube video when I thought about this… This will probably never turn into a feature but I need to write it down before it's lost forever big_smile

It has to do with the ability to retain the metadata in a usable form between loads (comments, drawings, paths, etc.).
Currently, there is a saving option in Kinovea that let you combine the metadata and the video in a single file (or you can save the metadata in their own file somewhere else).

But if you want to upload it to YouTube or something, obviously you need to burn the drawings on the images, and you'll loose the comments.

This is because YouTube will change the format of your video and re-encode it, so even if you download it back, you only get raw images.

But how do you transmit metadata so they survive to format change and re-encoding, and stay editable when you open the video on the other side?

The idea would be to add a special image as the first frame of the video, containing a 2D bar code:
http://upload.wikimedia.org/wikipedia/en/thumb/4/42/Wikipedia_mobile_en.png/150px-Wikipedia_mobile_en.png

This kind of matrix code can contain several Kilobytes of data, and that might be enough to transport the drawings and path stuff, or maybe the comments.
When you redownload the video from YouTube, (using a firefox plug-in for example) and open it in the software, it would detect the bar code on the first frame, translate it back to the metadata, and display the comments.
If the website encoding doesn't completely kill this specially crafted image, it could work.

Or it could also be used to transport metadata in files that don't support it initially. (Currently the only option is to use the MKV container).

/end of thoughts dump

1,534

(24 replies, posted in General)

Great smile
Please check the wiki page to get started.

There hasn't be any language with non-roman alphabet yet. I think it would be best if you can send a first draft with just a few strings as soon as you get started. This way I can try to import the draft, see if there are any general compatibility issues, and eventually get them fixed.
Thanks

1,535

(1 replies, posted in General)

Hi,

No the source code is now only available from the svn repository.
You need a SVN client like TortoiseSVN to grab it, but it's fairly easy : once the SVN client is installed, you create a new folder, right click it and do "SVN Checkout".
You then give it the source tree url, for example http://svn.codingteam.net/kinovea/trunk/

Note that you then get the very current code, it should compile but it might not be ultra stable. Older releases have been archived in /tags/

1,536

(8 replies, posted in General)

I'm seeing more and more videos of weightlifting paths done in Kinovea popping up on internet here and there. That is great ! big_smile

I guess the next step (apart from displaying more infos on the path) would be to have an easy way to visually compare two or more bar paths together. And that would certainly be useful for other sports and activities.

So let's throw some ideas and have them incubate until this can turn into a nice handy feature smile
(We can save the data as .kva and reload in another video, but I think we could have something more dedicated/powerful)

Bonjour,
Non, ce n'est pas possible pour l'instant. sad
Cela fait partie des suggestions qui ont été soumises, mais pour être honnête, ce ne sera pas pour tout de suite. (cela passera certainement après la gestion du son en entrée, car il faut que la vidéo intégrant les commentaires audio puisse au moins être relue correctement par le programme lui même).

1,538

(2 replies, posted in Ideas and feature requests)

Hi, thanks.
Some quick comments

Saf wrote:

The line tool becomes inactive if you move forward or backwards through a frame, would be useful to have it remained active.

Well… As you can see there are 3 possibilities here :
1 - instantly fall back to the "hand" tool after any use of the tool. (Angle tool, Text tool) This is because it seems more logical that the user will want to move the new drawing around or use another tool right away.
2 - keep the same tool while in the image, but fall back when changing frame. (Line tool)
It seemed to make more sense. The person is putting a bunch of lines on a specific image, possibly to highlight alignments, but when he moves out, he might aswell use another tool or move an existing drawing around. We really don't know so we fall back to the default behavior which is the "hand" tool.
3 - keep the same tool even when changing frame. This specific case is only for the cross marker (scenario: spotting a moving person or object over several frames) and the pencil (scenario: animation commenting)

This is not set in stone. It will be easy to make the change for the line tool to stay active when changing frames, but I'm not sure it is the right thing to do…

Saf wrote:

Persistence over a single frame would be good. At the moment its lowest number is 2 frames (unless you do it manually for every line shape, for every frame)

In Kinovea terms, persistence is staying on screen for more than one frame. To have the drawing visible only on the key image, you'd have to actually turn persistence off in the general preferences. (In this case the drawings won't be visible at all while playing, but they will be visible when manually browsing the frames.)
Does that match your expectations ?

Saf wrote:

Using a Wacom tablet can be infuriating at times, as Kineova is too sensitive at interpreting a single tap, as a double, opening the configure drawing window.  Is there a way we can reduce its sensitivity (using the Wacom setup tool does not affect Kineova).

Sorry about that ! It's been reported as m170 also. It should be fixed in the next version.

1,539

(24 replies, posted in General)

Hi all.
I'm back home, if you have any localisation file please send them so I can merge into the current code line.
I have merged the new Finnish locale and updated Spanish and Italian, thanks ! big_smile

Regarding German locale, I think peusi is already working on it. Since it is an update (as opposed to a complete translation from scratch) I think should be fine.

1,540

(2 replies, posted in General)

Hi,
Awesome !

0. Coding : Yes, you are very welcome. I'm not sure about the most appropriate place to discuss design and implementation issues though.
I'll try to add more details about current implementation in the wiki pages and also expose the plans for features that are currently at design stage.
See wiki - dev docs if you haven't already.

1. Live Capture : I started implementation a few months ago and paused it lately to try to gather up for a formal release.
I have a fairly well defined idea of what I think should be in feature-wise, at least for a first version of the tool.
I will write it down in the wiki as soon as I can.

To enable the current code, go to ScreenManager.cs, and look for the following comment (around line 340)
"Disabling all capture menus during dev."
Comment the next few lines to enable the menus.
Remember this almost hasn't been tested, the interface is ugly and it's probably broken in several places too smile.

The low level capture code is done by third party open source component AForge.net. (considered using either AForge.net or DirectShowNet for the devices interface.)

2. Using deinterlace mode directly : By directly you mean to turn it on by default for all videos ? If so you can do that in the Preferences. (added in 0.8.4 I think).

3. Drawings tools : I am most definitely intersted in them. The initial plan was to combine the simple shapes (ellipses, rectangles etc.) and the custom shapes by using the SVG format to define all of the next tools. I've found an open source SVG library that would help with this.

This would open up the software even more, as anyone could design it's own shapes (in one of the existing visual SVG editor like Inkscape), put them in a special folder and have them detected and usable in the software. (and also share them easily with other users, etc.)

I'll look at the patch tomorow.
Thanks.

So, to sum up options… Don't know what will end up in the software but if you have other ideas they are welcome:

- Having a simple visual clue of the speed, without the exact measurements. (ex: circles at each frames (closer=slower), circles with varying size, color coding of the speed, changes in width of the track (thiner=faster), etc.

- Having a small dynamic label with the total distance from begining to current image, and/or current speed, the label would only be visible for the current frame.
Also being able to view the last segment distance at any time.

- Being able to choose among various informations to show for key images. Key image title, total distance from the begining, distance from last point, speed, others ?


Ideally the number of options available would fit in a single configuration page without too much clutter.
(This could be done by identifying group of options that go together and make them available as bundles instead of giving 100% control over the display, wich can cause confusion if not necessary.)

Also, some more thoughts regarding coordinate axis :
- Having a new menu "Coordinate Axis" under "Image" : By defaut it would add a coordinate axis directly on the image, plus an horizontal and a vertical ruler on the sides.
Plus a way to display a complete overlaying grid based on the current coordinate system.
- Being able to change the coordinate axis by direct manipulation somehow. (and dropping the current extra window of the trajectory tool).
- Having the mouse pointer coordinates (in this system) displayed in the status bar.

For speed measurements, the units should be configurable… The distance calibration might be in centimeters or in feet, it may still make more sense to have a speed in Kilometers per hour or in meters per seconds (or even maybe in Knots, or other speed specific unit).
That should probably end up in the general preferences…

1,542

(1 replies, posted in General)

Hi, yes it would be a great feature to have (although without a real 3D context, the actual usefulness have to be assessed).

As you wrote this should be an extension of the trajectory tool, so right now there are things more critical to it. (improving the automatic tracking, tracking multiple points.)
When tracking multiple points will be in place having a wire frame buddy as the tracked point collection should be straightforward.

It's already on the suggestion list, but there are a significant ammount of things to fix/improve first.

1,543

(24 replies, posted in General)

Hi everyone and happy 2010 smile

Sorry for the lack of comments lately, internet is scarce (actually for the past few days I was in a place where electricity wasn't delivered smile)

Yes please send back the file to joan at kinovea dot org.

Concerning seal/calibrate measure vs measured dimension, I think the menu should correspond to the action that the user will be able to do when he clicks the menu, so I would rather keep it as a verb...

For the manual, I thinks it's best to wait a bit because it might change significantly and it will be harder to merge afterwards.

Thank you all for the efforts !

Hi, thanks for the message.

1 and 2 sounds like you are trying to follow point(s), is this right ? In this case I guess the best thing would be to implement speed calculations within the trajectory tool (?).
Currently one may do this by exporting the trajectory data to a spreadsheet application and make the computations there.

Point 3 sounds like an interesting challenge smile

4 and 5. Yes, this also came up in feedback for trajectory tool and was implemented recently (but only for trajectory for now).
I guess when the data export is available for points, lines and angles, the coordinate system setup will have to be moved in a more accessible location…

I'll consolidate all this in the suggestion list when time permits.
"Human model tool" to adjust on the actual person will probably only be implemented during a later phase, with other "complex" drawings though.

1,545

(8 replies, posted in General)

Hi,
Thanks a lot for the feedback and the example video.

About coordinates, currently you can export them to spreadsheet documents. (A dialog window that would sum them up was considered but this is currently on hold.)

There are two things you may want to do before exporting,
1. Set the scale; place a line on a object of known length, then right click + "Seal measure" and input the length.
2. Set the coordinates origin; by default the origin point {0;0} is equal to the first point of the trajectory.
To set it to another point, right click on the trajectory + configure + "Coordinates system origin".

This will not really compute the distance between two points, but you may do that, and more, in the spreadsheet app.

Let me know if this work for you or how it could be made more straightforward etc…