-
Key frames: mask positions track keyframes but not values???
Masking areas for the purpose adjusting shape levels, using gradient, circular, bezier or other mask shapes, is a powerful tool.
But it seems that only the position of the mask– not the adjusted values of, for example, gain– tracks the keyframe animation.
Try this: create a mask shape with an associated keyframe and then add some adjustment value, say, moving gain to 120%.
This would create a brighter area in the center of a circular shape, for instance.Create a second keyframe and move the mask to a different position in the frame and then vary the gain value again, say, to 110%. We expect that this new keyframe with its shape position and value would be recorded independently of the first position and its gain value.
Create a third keyframe and likewise vary its position and change its gain value to, say, 130%.
We expect that this keyframe with the new shape position and value would be recorded at this third keyframe independently of the first and second keyframes and their positions and gain values.So I expected that moving to each subsequent keyframe would reflect not only the different shape position but the other adjustments (different gain) values as well.
But it does not. It seems to reflect only the changes in position and uses only the most recent gain value for all the keyframes.
Gotta be missing something here.
Any suggestions???
Thanks, Mike
-
5 Replies
-
Tracking keyframes and regular Node keyframes are different. Tracking keyframes only hold shapes and positions; regular Node keyframes contain color corrections, window positions, key values, curves, the works.
There are cases where I specifically use one or the other, but you have to do a regular Node keyframe if a change in color or level is involved. Frequently I’ll track a window and make a separate node change on top of it for some reason or another. Sometimes, I just need to knock down the opacity just to fade the window out. The advantage of using the Tracker is the auto-tracking function, which you don’t have with regular keyframes.
-
Thanks, Marc; Very encouraging to hear; surely there has to be be a way.
But I confused the issue by using the work “track” with regard to matching color changes at each keyframe.
Yes, I am using manual node keyframes, not using the tracking tool to mask a moving visual element. That is, I manually create each keyframe, move the mask as needed and apply some color (or other level or hsl) change.
But the color changes then apply to all the manually created keyframes. So, while the mask itself does animate its position with corresponding keyframes, the color value does not change at each keyframe.
A simple example using just two keyframes: with a simple static visual background (and no tracking) I create a simple circle on the left side of the frame and manually create a keyframe at that position. I set some color value, say gain at 110%. As expected, the center of the circle is slightly brighter.
I move the current time indicator along the timeline, say, one minute and create a second keyframe and move the circle mask to the center of the screen. The centered mask now shows its slightly brighter gain of 110%, inherited from the first keyframed mask color setting. I raise the gain to 130% to distinguish this keyframed center mask value from the first keyframed mask color value. This second mask at the center of the frame then shows, as expected, gain and brightness at 130%.
But here is the problem: go back to the first keyframed mask circle on the left side of the frame. What do we see? Is the left side circle brightness showing at its initial value of 110% or at the 130% of the second keyframe? Answer: The first mask brightness is showing at 130% just as it is for the second mask.
In other words, any color adjustment applied to one keyframed mask is also applied to all the other keyframed masks.
Nuts. Must be missing something very simple.
Clue? I have used tracking a lot in other nodes in this clip. But I created a separate node on this same clip node tree for these keyframed tests.
Thanks,
Mike -
I have not seen this to be the case in my experience. Keyframes on the correct node will always affect the color-grading values, assuming they turned on within the selection box. Open up the disclosure triangle and see what color grading parameters are turned on and which are turned off. If Primaries are turned off, then that’s not going to happen.
-
Marc; Good news regarding this mystery. And like many good mysteries, the resolution was entirely accidental.
While cleaning up stuff I found that the cache was–based on my limited experience–huge, about 1 TB. True, I had experimented with various cache modes. And without fully researching the possible consequences, I just deleted the entire contents of the cache folder.
No only did Resolve seem to be noticeably quicker but the mask issue you helped with now seems to work as we expect!
And further, it seems that the video “defect” in the original 4K ProRes 4:2:2 recording also now seems normal on playback. This “defect” now seems gone. This was about 1 1/2 seconds where a portion of the frame area dropped in luma value, with unusual waveforms seeming to show digital comb defects dropping these pixel-wide slices of the image to zero.
Ever heard of such a thing?? That is, short defects in video, perhaps introduced during editing or color work???
And, as far as you know, Marc, does the cache normally affect the display, such that a defect could be introduced there and continue to affect subsequent playback and output until cleared???
Thanks again for all you help, Marc.
Mike -
That’s interesting — in theory, the cache mode should be updated and replaced every time you make a change. It would figure that if a glitch happened, it would be embedded in the visible clip as it played back. What puzzles me is why it didn’t update.
A 1 TB cache is pretty crazy!
Reply to this Discussion! Login or Sign Up