1,681

(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,682

(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,683

(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,685

(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,686

(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,688

(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…

1,689

(1 replies, posted in Bug reports)

Hi,
That is strange. I just tried and it worked for me.
What is the version of OpenOffice or Excel that you are using ? I could only test with Office 2003 and OpenOffice 3.0 and 3.1.

Also, you can try to open the .xml (Excel) file in notepad and try to see if the coords are there.
The data will look mangled, but try to look for something like :
<Cell ss:StyleID="s24"><Data ss:Type="Number">-38.00</Data></Cell>

(bold is a coordinate)
If they are all zero here, then the issue is somewhere else…

1,690

(1 replies, posted in Bug reports)

Hi,

No codec should be needed, they won't be used anyway.
If the file is small enough, you could open a bug in the bug tracker and upload it along the bug report.

Also, to start the analysis, you (or other users if you upload the file) can try to read the file in VLC Media Player and/or MPlayer.
It helps figure out if the issue is in the FFMpeg library (shared among these softwares and Kinovea) or somewhere else.

Thank you

1,691

(3 replies, posted in Français)

Bonjour,
Malheureusement pour l'instant pas de version Mac ou Linux à l'horizon.
Développeurs C# / Mono bienvenus smile

Ancien topic sur le même sujet avec d'autres infos.
Autre sujet dans le forum anglais.

1,692

(3 replies, posted in Français)

Bonjour,
Non pour l'instant il n'est possible que d'enregistrer les deux vidéos indépendamment l'une de l'autre…

1,693

(3 replies, posted in General)

Hi, thanks for the feedback.

As you noted the stopwatch is currently a simple one. There has been suggestions to make it more powerful with the ability to record multiple times with the same stopwatch, but that would complexify the current tool too much I think. (Because such a basic tool should be as simple as possible…)

I guess changing the options to "start", "pause", "continue", may be considered… would that be explicit enough for every use ?

I think it would be good to have input from others users on this. Should the simple stopwatch stay as simple as it can be and a more powerful stopwatch made into a new tool, or should the enhanced stopwatch become the basic tool ?

1,694

(2 replies, posted in General)

Hi,

I'm not sure it's what you are looking for, but you can get the coordinates of the points of a trajectory by using the export to spreadsheet function, from the file menu.
Currently there is no way to get them directly from within the software, you have to export them.

I would also ideally like to be able to programatically plot points on images or on overlays of the images.

You could try to programmatically generate a .kva file and then import it. ("Load Key Images data…" menu)
.kva is the XML description of the key images and drawings. There is currently no shema or DTD, but you could set a few points and export them to see how the format works.

I am interested in knowing more about your workflow and what you are doing, picked my curiosity smile

Update on 2009 December 08th.

Removed from list because included in latest experimental release (0.8.4)
http://www.kinovea.org/images/accept.png - Being able to enforce 16:9 or 4:3 aspect ratio.
http://www.kinovea.org/images/accept.png - [Paths] - A mode where only a few points around the current image are visibles.
http://www.kinovea.org/images/accept.png - [Paths] - Ability to specify the origin of the coordinate system when exporting path.
http://www.kinovea.org/images/accept.png - Being able to launch the program from command line with swiches.
http://www.kinovea.org/images/accept.png - Superposing the images of one video on the other during synchronization.

Added:
http://www.kinovea.org/images/weather_cloudy.png - [Paths] - Display distance between start and current image.
http://www.kinovea.org/images/weather_cloudy.png - [Files] - Possibility to load an image sequence as a video.
http://www.kinovea.org/images/weather_cloudy.png - [Files] - Possibility to launch a file by drag and drop on the Kinovea program icon or shortcut.
http://www.kinovea.org/images/weather_cloudy.png - [Files] - Possibility to launch a file by right click + Open with…
http://www.kinovea.org/images/weather_clouds.png - [Drawings] - Possibility to have drawings showing from a given image until the end of the video.
http://www.kinovea.org/images/weather_clouds.png - [Synchronization] - Possibility to move the superposed image to align it on the other.
http://www.kinovea.org/images/weather_rain.png - [Saving] - Being able to export the video including the superposed images of the other video.