1,381 Reply by joan

(6 replies, posted in General)

Hello,
Yes the ability to display the coordinates for a specifc cross marker would be nice. I'll add it to the suggestion list or maybe implement it if I can do so quickly.

Regarding export to spreadsheet, I'm not sure what would be the best way to display these data…

Currently we just group objects by type and list their various values over time. When there are several object of the same type on the same image, we can't differenciate them. (for Tracks and Stopwatches, there is a title to help, but for lines, angles and soon single points, there is nothing).
If you have many points on the same image, I don't know you will be able to set them appart for further calculations…

Go to forum: General

1,382 Reply by joan

(4 replies, posted in Bug reports)

I think I have found the root cause, and apparently the bug has always been there, although it might have been hidden.

The underlying cause is a bit complex (see bug note), but it worked before because the default codepage on your machine contained the cyrillic characters, and apparently it doesn't anymore on your new system.

This means that non Unicode programs will have issues with these filenames (Which is the case of the low level decoding library when used with default options).

Here are some instructions to change the default codepage in Windows 7, this may help with the problem until a more general solution is implemented.


edit:
To confirm the workaround, I switched the settings for non-unicode programs to use the Russian codepage on my machine, and now I can open the files with cyrillic characters. (but files with roman special chars like éêà do not work anymore)

Go to forum: Bug reports

1,383 Reply by joan

(4 replies, posted in Bug reports)

Yes, you're right. I reproduce this right away with cyrillic characters in the filename.
I added bug231, I'll try to look at this as soon as possible, fairly critical.

I'll try with older versions to see when this started to fail and what may have changed…

Go to forum: Bug reports

1,384 Reply by joan

(4 replies, posted in Bug reports)

Hmm… Maybe you were previously using one of the experimental version?
They have a more recent version of the file decoding library, so if it's an option, you may want to try that anyway.

The error is strange though. It's not saying it cannot decode the file (there is another error for that), it's saying it can't find it in the first place…

Go to forum: Bug reports

1,385 Reply by joan

(11 replies, posted in General)

kinoveafan wrote:

The camera is really great (320*240 @125fps / 640*480 @75fps) and cheap ( 20€).

Nice specs for 20€ smile
Settings change should be in the next experimental version. We'll see if it works...

About the camera, what about depth of field? Is the image quality decent when the subject is at a distance of more than a few feets? Also, does it work well outdoors? (Sometimes the cheap captors are tailored for indoor / close range video since the main application is video chat.)

Go to forum: General

1,386 Reply by joan

(45 replies, posted in Ideas and feature requests)

About framerate / size configuration.

I have just looked at this today, it should be available in the next experimental version.

What happened before is that we took the first item in the list of the camera capabilities.
Now the biggest frame size will be selected by default, but you should also be able to change to another setting in the source configuration dialog.

Tested ok with a webcam (snapshot below). For the DV camcorder, the frame size change did not translate down to the device… to be investigated later (DV should always be 720x576 anyway, I was surprised to find an other option).

http://www.kinovea.org/screencaps/0.8.x/captureconf.png

Go to forum: Ideas and feature requests

1,387 Reply by joan

(14 replies, posted in Bug reports)

I would like to study this issue but I can't reproduce it.
Could someone attach a log file to the bug 227 please.
(remember to collect the log right after the issue, before you reopen Kinovea, because logs are rotating. Check the log in notepad, it should have the exception text at the end.)

Thanks

Go to forum: Bug reports

1,388 Reply by joan

(2 replies, posted in Bug reports)

Hello,
From what I can read these .PGI files are not actual videos but rather meta data about timestamps, duration, and other info.
The actual files would be the .MOD ones.

Go to forum: Bug reports

1,389 Reply by joan

(1 replies, posted in General)

Hi,

First of all, when the selection is short enough to fit in RAM memory (12 seconds / 1024MB by default), it will be fully extracted and then the codec will be irrelevant. Frame by frame should be good, both ways.

For longer clips, when reading directly from the file, the best results are generally achieved with codecs / profiles that use so-called "intraframe" coding, that is, each frame is compressed independently from the others. For example DV, MJPEG, or any codec if you configure the encoder to use I-Frames only (IIRC, similar to setting the GOP size to 1 in the encoder).
(These files will take more space).

In any case, forward frame-by-frame should rarely be an issue, it's more backward frame-by-frame that can be a problem.

There are also specific codecs with other issues, depending on the encoding profile and the encoder. (.wmv / .asf files have caused issues in the past.)

Go to forum: General

1,390 Reply by joan

(1 replies, posted in Français)

Bonjour,
De quel type de vidéos s'agit-il ?
Il y a un soucis connu (bug 142, toujours en investigation) avec certains fichiers VOB de DVD, notamment au niveau de la durée annoncée…

Go to forum: Français

1,391 Reply by joan

(1 replies, posted in General)

Hello,
Currently there is no way to work around this kind of perspective issues.

Maybe later, when line tracking is in place, we could define a calibration segment and programmatically force it to keep the same size in pixels over the course of the video, by resizing the whole image around it… The range of applications of this would need to be assessed though. If someone can think of other scenario where this may be of interest ?
Thanks

Go to forum: General

1,392 Reply by joan

(9 replies, posted in General)

Interesting…
An addition on this would be the ability to drag the image around even when it's at normal view (zoom 100%).
With the combination of these two, one could directly adjust/align one image over the other in a very simple way.

Go to forum: General

1,393 Reply by joan

(1 replies, posted in Français)

Bonjour,
Deux tests possible pour avancer dans le diagnostic:
- Tester la détection de la caméra par le logiciel sur un Windows 7 classique (hors bootcamp).
- Tester la détection des périphériques FireWire sur le Windows7+Bootcamp en dehors de Kinovea. (Autre logiciel de capture, disque dur connecté en FW, etc.)
Un logiciel tout simple pour tester le lien entre la caméra et le système : WinDV

Go to forum: Français

1,394 Reply by joan

(3 replies, posted in General)

dduck13 wrote:

ok...I have another question...I have tried to use this program to time guys release times and the timer seems to do by incraments of .03 sec.  Is there a reason for this?

That would point to a 30 fps file which is quite common. (1/30 = 0.033).

dduck13 wrote:

I have used another program before and it didn't do this and had up to the 1/10000 of a second.  Thanks

Unless the video really has 10000 images per second, it is an artifact of the program. We can add as many digit after the decimal point as we want, the precision will not be better than 1 / fps.
Please re-check and see that when you move from one frame to another, you don't have 1/10000 increments (you may have 4 digits after the decimal point, but it is not really relevant).

Go to forum: General

1,395 Reply by joan

(3 replies, posted in General)

Hi,
Unless you have very high speed camera with more than 1000 frames per second, I think the limiting factor is the framerate of the video file (or the capabilities of the capture device).
When you shoot with a regular camera at, say 50 fps, the time resolution is 20ms. Each image is separated from the next one by this ammount, and you cannot get more accurate than that. Every timing you do can only be a multiple of this fundamental unit.

In that regard, displaying hundredth of seconds is already sometimes misleading, as the time measurements are really only as accurate as the frame rate. (In an early version, the last unit of the timecode display was the number of frames, which is more right, but less useful).
We could display microseconds, nanoseconds, but it will not be more accurate, just more misleading in my opinion.

There are cameras with more than 1000 fps though, I don't remember if this is nicely supported (up to 999fps should definitely be ok). I don't think 10000 fps capable device can be used for timing people (outside photofinish hardware that is).

Go to forum: General