1

(1 replies, posted in General)

I'm curious where that information is coming from. Kinovea has never supported RTSP, only MJPEG.

2

(3 replies, posted in General)

The distortion grid has been replaced with the Lens calibration menus under Tools. Especially the Lens calibration mode has a more complete calibration workflow now. It needs to be run on a short checkerboard calibration video. Check here.

The color profile button has been removed because of some changes in the way the drawings properties work. Now when we change properties like color on a drawing they are immediately saved as the new default, and the next drawing of this type will use these properties. This is more natural than having to manually save it every time. If you have a specific workflow that is broken by this change let me know so we can see if it's something that can be worked around or taken into account.

Could you share one of these videos that cause the problem please? If it's small you can send it at the following: joan at kinovea dot org. If it's more than 5 MB please send it via a file transfer website like swisstransfer or put it on google drive or similar and share the link by email.

That is very strange.
What do you mean by "a continuous blue line next to the red indicator", what red indicator?

5

(1 replies, posted in General)

For now I would say just set the playback speed to 50% (use up/down arrow keys to land on exact percentages), if it's possible for your use case. And if you are sure the videos were captured at 30 fps you can set that in the time calibration dialog so the timestamps, time intervals, speed measurements, etc. take it into account. Time calibration doesn't touch the internal video frame rate used for playback.

Sometimes the file format container and the video codec disagree maybe it's one of those cases. Unless the video is interlaced in that case you would see artifacts and you would need to do Image > Deinterlace.

Not familiar with continuous x-ray images, is it imaging someone/something in motion or is it the tool that is moving and scanning at different depths/locations? Where is the 30 fps information coming from? Is it 30 or 29.97?

6

(1 replies, posted in General)

rodrigoncalves_ wrote:

the application closes automatically.

Hi,
First of all sorry for this, it sounds like a bad bug. Do you have any exception logs in the log folder, these are files starting with "Unhandled Crash" in the file name. If so please send them to me at joan at kinovea dot org. Thank you.

It's not necessarily a simple feature to implement because the magnifier tool is unlike any other tool due to how it behaves and also functionally the magnified area can take up a lot of space in the viewport so it would make it difficult to use (at least until the magnified area can be moved outside the original image area).

Maybe a different approach would be something like the Kinogram mode where the viewport is split in multiple tiles and you can manually pan around inside each tile, and there is a zoom level for all the tiles.

Oh, I forgot to update the little file that tells what's the latest version. It should be fixed now, you can try again.

Or you can get it from here: https://kinovea.org/download/

Is it a normal angle object or is it an "angle-to-vertical" or "angle-to-horizontal" object?
There was a bug with the latter that was fixed in 2025.2.

10

(2 replies, posted in General)

Is the file in the OneDrive folder by any chance? I'm getting more and more reports of people trying to open files that are synchronized to OneDrive and these files aren't really there even if Windows shows them as if they were local. I have to check how to handle this case gracefully but if that's your case you could temporarily copy the files to another folder and try again. This will force Windows to actually download the files.

Another known issue like this is specifically for the Korean locale when the file name has Hangul characters in it.

I think the discrepancy is because the ones on the video viewport don't take the smoothing filter into account for performance reason. If you disable all the smoothing in the preferences they should match again. But the smoothing is important for accuracy, to remove digitization noise. The main thing I want to avoid is recalculating the whole series on every frame during tracking and point manipulation, maybe it could update whenever the track exits editing mode.

What is the original camera frame rate?
To work around the limitation you could set the threshold to something very high, above the camera frame rate, this way it will never trigger and the final video will have the same frame rate as the capture (no replacement). I think the threshold also maxes out at 1000 fps though.

Ces fonctions ont besoin de plus de mémoire, vous pouvez aller dans Options > Préférences > Lecture > Mémoire et augmenter la mémoire allouée. Et réduire la zone de travail au plus près possible autour de l'action.

14

(1 replies, posted in Bug reports)

Did you try in version 2025.2 released last Saturday? There was a bug that was fixed in there.

15

(1 replies, posted in General)

Hi,
Just to confirm that the timestamps in the file are not hardware timestamps. This is a topic of interest but so far I haven't looked too much into how to get the timestamps when available.

On a related note I'm also interested in trying to measure the accuracy and stability of the frame rate of arbitrary cameras by independent means (like filming an array of LEDs flashing at known frequency to create a binary clock). With the goal of controlling the assumption that the frame rate is stable and that time fluctuations are extremely small or at least much smaller than other sources of error.

Aside from small frame rate fluctuations a possible source of error is when a frame is completely dropped from the output. There should be a drop counter in the info bar of the capture screen. A single frame drop will throw inter-frame arithmetic out of wack. Using recording mode "retroactive" should help if the duration of the recording fits in memory.