46

(18 replies, posted in General)

That's quite strange, it should be completely uncorrelated as the frames are generated one by one and the frame rate is stored as metadata. Does it do it with all image sizes? Is the resulting file playing slowly compared to its nominal frame rate or the stored frame rate itself is slower than expected? Like if you open the file in another player what does it say the frame rate is?

47

(18 replies, posted in General)

Release of version 2025.1.1. The original post has been updated.

This is a minor update with mainly translation updates and a couple of fixes. Special shout out to user ntnam that translated the entire thing to Vietnamese in the interval since the original release!

Full changelog:

    Added - Vietnamese locale.
    Improved - Chinese (Simplified), Croatian, German, Indonesian, Japanese, Russian, Slovenian, Thai, Turkish, Ukrainian.
    Fixed - Removed the filtering of The Imaging Source cameras Directshow driver until the GenICam version works correctly.
    Fixed - Updating the tracking search window from the track configuration window was broken.
    Fixed - Camera configuration latest changes could be lost if another camera was updated in another window afterwards.

Yes there is a way but not directly inside the program, in order to capture key presses when it doesn't have focus it needs to be something else.

You can use AutoHotkey (AHK) to capture the key presses, then a command to find the right Kinovea window and send it a Windows Message. People have posted the code in the forum I think, sorry I can't be of much help right now I'll come back later with more info if no one else has done so. The documentation is light but might get you started: https://www.kinovea.org/help/en/misc/copydata.html

Yes the pattern should cover about a quarter of the frame. This is just a rough guideline, it will work even if it's not exactly that. You can have other things visible in the frame.

It should be moved around to cover the sides and corners of the frame, but not go partially outside, all the inner corners between the squares should be visible at all time. It can be tilted / seen in perspective.

The code internally uses OpenCV for this so you might find other guides online searching for OpenCV camera calibration.

50

(3 replies, posted in General)

You can read a bit more about the coordinates filtering in the about page of the Linear kinematics dialog. Usually you want to keep it on because it removes the high frequency noise that is artificially introduced by the digitization process, especially if the points are placed manually.

So it looks like the issue is that the angle value displayed in the viewport is not taking coordinates filtering into account, I will note it down somewhere, thanks.

51

(3 replies, posted in General)

Re: Kinogram mode. Yeah unfortunately at the moment this mode is still bound by the aspect ratio of the original footage. The initial values for the number of rows and columns and the crop rectangles default to the last ones used so it sometimes looks wonky or super small with empty space both at the top/bottom and on the sides. The export will crop out the empty space and can be larger. I tried to auto-rotate the canvas by 90° at some point but it caused other issues.

For now if the original footage is in portrait mode you might find it better to change the grid to something more appropriate, like 3x4 or something. Apart from that it should work the same.

52

(3 replies, posted in General)

Regarding the first point it's not normal, the values should be the same, could you share the kva file with me please?

What do you have as options in Preferences > Drawings > General > "Enable coordinates filtering", and "Enable smoothing of derivatives for high speed footage"?

Do you have other calibrations in place like lens distortion calibration or camera motion estimation?

Assuming it's a tracked angle, are you using version 2024.1 or earlier or are you using version 2025.1? Tracking of objects changed completely.

For the second aspect, I think it's normal that when calibrating with the line tool it doesn't change the angle. It rotates, translates or scale the coordinate system but it's still on a parallel plane as the uncalibrated one so the angle shouldn't change. If you use the grid calibration to calibrate a plane that is not parallel it will change the measure.

Yes this behavior is intriguing I'm very interested in understanding exactly what is going on. You can send it by email: joan at kinovea dot org.
Thanks.

Loading a KVA created for one video into another video should work, could you share with me one or more files that cause a crash? (joan at kinovea dot org). A crash is always a bug. Even if the videos have different sizes or frame rate there is code that works it out and adapt everything so if it doesn't work in some cases please help me reproduce the context so I can fix it. It may also have generated a number of "Unhandled Exception" files in the application data folder, if you can share those as well it will be helpful, thanks.

Are you loading them manually or via the "default annotations file" option (shouldn't make much difference but will help reproduce)?

I agree, yeah this difference is a long standing issue, but not easy to fix. Attempted the refactoring a few times.

The other aspect where this is limiting is that you can't have drawings go outside the video rectangle in the player, whereas in the capture screen you can, for example a corner of a perspective grid may be out of view.

Thanks. Yes this sounds like a bug. I'll look into it.

Oh I see, you are using a single instance of Kinovea and alternating between a capture screen and a playback screen, correct?

It does save the capture folder, even between sessions, but when you open a new capture screen in the instance it starts from the default state (actually even this should work but I think it's because of opening a player screen in between that it lose the capture screen info).

The new workflow is that you would use a dedicated window for capture, and a different one for replay. Doing this it will remember everything, the camera, the capture folder, the position of the window, etc. It will be ready to go as soon as you start.

Same for the replay, the window will remember the observed folder, the playback speed, etc. Typically if you have two cameras and two replay you would have 3 windows, two capture and one dual replay. It's better to save to different directories otherwise the automatic replay can't tell which file to load. The replay window will also automatically bring itself to the foreground when it loads a new file.

This seems very difficult. If it's around the world vertical axis you might attach a camera to the ceiling, if it's the player vertical axis, aka the longitudinal axis then I don't really see how you can measure this from 2D video, the camera would need to be somewhere along this axis.

If you are using version 2025.1 you now need to manually enable the debug logs from the help menu in order for it to produce all the logs.

Apart from that I don't know. The fact that it can get the thumbnail sounds encouraging, it means it managed to connect to the camera and grab a frame. When it opens the capture screen it does more stuff to get the current values of the properties like stream format, image size, etc. maybe something happens there that causes the failure, but that should be caught by exception handlers. 

One issue I have seen with GigE cameras is when a VPN is installed on the computer, sometimes that trips the driver when it enumerates the interfaces.

60

(3 replies, posted in General)

Some spambot posted an answer to this which made me realize I hadn't responsed. Is it still a problem in 2025.1? If yes can you identify which version is working and which version is not working? Which output format are you using?