Motion Tracking Keyframe A & B, relative not absolute. #86456

New Issue

Richard Lyons · 2021-03-10T13:47:00+01:00

Richard Lyons commented

2021-03-10 13:47:00 +01:00

System Information
Operating system: Darwin-19.6.0-x86_64-i386-64bit 64 Bits
Graphics card: NVIDIA GeForce GT 650M OpenGL Engine NVIDIA Corporation 4.1 NVIDIA-14.0.32 355.11.11.10.10.143

Blender Version
Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: 02948a2cab
Worked: (newest version of Blender that worked as expected)

Short description of error
Not sure if this is an actual bug or more a design discussion. When setting the values of Keyframe A & B in motion tracking "solve" panel. They seem to be relative to the clip.
When working in a VFX pipeline we almost always start clips from frame 1001.... This allows to work with preroll, or fix effects on frames before the start frame without running into minus frame numbering problems.
However, when one moves the clip to 1001... and then enters for example 1010 & 1070 in Keyframe A & B respectively, I get the "At least 8 common tracks on both keyframes are needed for reconstruction" error, even tho there are 8 tracks. It works fine if I change the frames to 10 & 70 instead.

Exact steps for others to reproduce the error
[Please describe the exact steps needed to reproduce the issue]
[Based on the default startup or an attached .blend file (as simple as possible)]

**System Information** Operating system: Darwin-19.6.0-x86_64-i386-64bit 64 Bits Graphics card: NVIDIA GeForce GT 650M OpenGL Engine NVIDIA Corporation 4.1 NVIDIA-14.0.32 355.11.11.10.10.143 **Blender Version** Broken: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: `02948a2cab` Worked: (newest version of Blender that worked as expected) **Short description of error** Not sure if this is an actual bug or more a design discussion. When setting the values of Keyframe A & B in motion tracking "solve" panel. They seem to be relative to the clip. When working in a VFX pipeline we almost always start clips from frame 1001.... This allows to work with preroll, or fix effects on frames before the start frame without running into minus frame numbering problems. However, when one moves the clip to 1001... and then enters for example 1010 & 1070 in Keyframe A & B respectively, I get the "At least 8 common tracks on both keyframes are needed for reconstruction" error, even tho there are 8 tracks. It works fine if I change the frames to 10 & 70 instead. **Exact steps for others to reproduce the error** [Please describe the exact steps needed to reproduce the issue] [Based on the default startup or an attached .blend file (as simple as possible)]

Richard Lyons commented

2021-03-10 13:47:00 +01:00

Added subscriber: @RichardLyons

Falk David commented

2021-03-10 14:32:06 +01:00

Added subscriber: @filedescriptor

Falk David commented

2021-03-10 14:32:06 +01:00

I would like to reproduce this, but it would be good to know what your settings are. E.g. the "Start Frame" and "Frame Offset" in the "Footage Settings" and then your start and end frame in the scene. Ideally, you could add a .blend file to the report (with a sample clip packed File>External Data>Pack All Into .blend) to illustrate the problem.

I would like to reproduce this, but it would be good to know what your settings are. E.g. the "Start Frame" and "Frame Offset" in the "Footage Settings" and then your start and end frame in the scene. Ideally, you could add a `.blend` file to the report (with a sample clip packed *File*>*External Data*>*Pack All Into .blend*) to illustrate the problem.

Sebastian Koenig commented

2021-03-10 15:26:04 +01:00

Added subscribers: @Sergey, @sebastian_k

Sebastian Koenig commented

2021-03-10 15:26:04 +01:00

If I understand you correctly, you do not enter an offset in the footage settings, but change the start frame of the clip.
In that case, yes, you are right, this behaves a bit weird.
The little green lines down in the cache area appear in the correct spot, but the numbers in the Keyframe A, Keyframe B fields are off.
During testing I have prepared a file that demonstrates the issue.
tracking_keyframes.blend
There are two issues here:
First: the keyframe numbers do not reflect the "correct" frames, even though they work fine.
Second: Entering the numbers in the keyframe field does not trigger a viewport update, so the little green lines only change when you e.g. change the frame.

I am not quite sure if this really is a bug, but it definitely feels buggy. Maybe @Sergey can have a look?
I never noticed this because neither do I work this way, nor do I enter the numbers manually but always use the solving pie for this: Shift-S brings up the solving pie, and in the upper left and upper right corners are the Set Keyframe Operators.

Btw, I did not find the keyframe opertors in any menu. I'll write a patch for that.

If I understand you correctly, you do not enter an offset in the footage settings, but change the start frame of the clip. In that case, yes, you are right, this behaves a bit weird. The little green lines down in the cache area appear in the correct spot, but the numbers in the Keyframe A, Keyframe B fields are off. During testing I have prepared a file that demonstrates the issue. [tracking_keyframes.blend](https://archive.blender.org/developer/F9883109/tracking_keyframes.blend) There are two issues here: First: the keyframe numbers do not reflect the "correct" frames, even though they work fine. Second: Entering the numbers in the keyframe field does not trigger a viewport update, so the little green lines only change when you e.g. change the frame. I am not quite sure if this really is a bug, but it definitely feels buggy. Maybe @Sergey can have a look? I never noticed this because neither do I work this way, nor do I enter the numbers manually but always use the solving pie for this: Shift-S brings up the solving pie, and in the upper left and upper right corners are the Set Keyframe Operators. Btw, I did not find the keyframe opertors in any menu. I'll write a patch for that.

Richard Lyons commented

2021-03-10 17:30:53 +01:00

Hi guys,
Yes, the image sequence I am using is numbered from frame 1001. So I don't use offset in the footage settings, just set the start frame to 1001.
Unfortunately the footage is under NDA, so I cannot send the images. I could upload the blend without, footage if that helps. But I honestly think Sebastian has correctly interpreted the problem/feature :)

Hi guys, Yes, the image sequence I am using is numbered from frame 1001. So I don't use offset in the footage settings, just set the start frame to 1001. Unfortunately the footage is under NDA, so I cannot send the images. I could upload the blend without, footage if that helps. But I honestly think Sebastian has correctly interpreted the problem/feature :)

blender-admin commented

2021-04-13 09:22:57 +02:00

This issue was referenced by 30ee57be60

This issue was referenced by 30ee57be60b76b75b6bbf4f780aa670e26502659

Philipp Oeser commented

2021-04-13 09:35:13 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-04-13 09:35:13 +02:00

Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'

Philipp Oeser commented

2021-04-13 09:35:13 +02:00

First: the keyframe numbers do not reflect the "correct" frames, even though they work fine.
I am not quite sure if this really is a bug, but it definitely feels buggy. Maybe @Sergey Sharybin (sergey) can have a look?

I would not consider this a bug (to me it seems like having this relative to the startframe has both upsides and downsides -- and in code this is handled correctly, both for the UI indicators as well as in the solving process).
But I guess it would be good if @Sergey has a final word here.
If this is not considered a bug, it might be good to document this in https://docs.blender.org/manual/en/dev/movie_clip/tracking/clip/toolbar/solve.html

> First: the keyframe numbers do not reflect the "correct" frames, even though they work fine. > I am not quite sure if this really is a bug, but it definitely feels buggy. Maybe @Sergey Sharybin (sergey) can have a look? I would not consider this a bug (to me it seems like having this relative to the startframe has both upsides and downsides -- and in code this is handled correctly, both for the UI indicators as well as in the solving process). But I guess it would be good if @Sergey has a final word here. If this is not considered a bug, it might be good to document this in https://docs.blender.org/manual/en/dev/movie_clip/tracking/clip/toolbar/solve.html

Sergey Sharybin commented

2021-05-03 16:16:26 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Resolved'

Sergey Sharybin closed this issue

2021-05-03 16:16:26 +02:00

Sergey Sharybin self-assigned this 2021-05-03 16:16:26 +02:00

Sergey Sharybin commented

2021-05-03 16:16:26 +02:00

The relative behavior of the keyframes is how they were designed to: you can think of it as "this picture A and that picture B is what defines the keyframes". Where exactly they are mapping in time is a bit irrelevant from the solver perspective.

The lack of refresh is supposed to be fixed now after commit from Philipp.

Thanks for the report, but the remaining parts here aren't really a bug.

The relative behavior of the keyframes is how they were designed to: you can think of it as "this picture A and that picture B is what defines the keyframes". Where exactly they are mapping in time is a bit irrelevant from the solver perspective. The lack of refresh is supposed to be fixed now after commit from Philipp. Thanks for the report, but the remaining parts here aren't really a bug.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Motion Tracking Keyframe A & B, relative not absolute. #86456