Search options (Page 95 of 131)

Nice specs for 20€
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.)

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

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

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

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

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

Hi,
Sorry for the delay. Would you be able to send a small sample ?
I'd like to try to reproduce and see what happens internally.
Is it in Full HD image size ? It is possible that the file is too CPU demanding for the current version. When the images can't be decoded + displayed fast enough, the speed slider is automatically slid to the left to try to mitigate the jerkiness.
Thanks