Welcome to Ocula from Foundry. My name is Jon and in this tutorial we're taking a look at retiming with Ocula 3.0. So, here’s the Ocula tree we’re going to take a look at. At the top, I have got a Solver calculating the stereo geometry for the plates. I am doing some plate correction, so vertical alignment and colour matching between the left and right views, then baking out the disparity and the motion vectors for use later on, and here we are using it to do a retime on the plates. So, here we are going to do an Ocula 3.0 retime, and see how that compares to retiming the left and right views separately with Kronos. At the bottom, we are going to look at a trick to help fix up retime if you are not quite satisfied with the result.

Let’s look at the plate preparation first. Here, I have got my Solver node. I am calculating disparity and occlusions so I can do a local colour correction, pulling the colour from the left onto the right view using that disparity. Then I am aligning the plates using a set of VerticalAligners, so let’s look at each of these in turn. On the Solver node, I have laid down 3 keys at the start, middle, and end of the shot. This camera rig isn’t actually changing, but I want to make sure I pick up any slight shifts in the alignment. There is a tutorial on the Solver node, which will tell you how to set up and QC (quality-check) these keys to make sure you get the best possible alignment data delivered by O_Solver. So, once I have my solve, I can calculate the disparity, and I have got this set up with the default values. From disparity, I can calculate the occlusions between left and right view, again with the defaults. There are no large changes in depth I need to worry about in this shot. Then I do my colour match, and I have this set up to match the right view to the colour of the left. So, we can take a look at that now. Here’s our input footage and here’s the correction. When I switch views on the input, you can see a shift in the reflections. I am going to look at the corrected plate. The colour now matches, but you can see the misalignment between the left and right view. Then I have my 3 VerticalAligners down here. The first I have set to Scale to take out any focal length differences. Then I have a Rotation to take out camera roll, and finally I have an Aligner set to Vertical Skew to take out any keystoning. We can look at the final corrected plates. When I switch between left and right views, now you can see they are aligned.

Once you have your plate correction, you can render it out. I am rendering it with disparity for the aligned plates, so I don’t need to re-calculate that disparity later on. Remember that you can’t use the input disparity because that won’t match the shift the image has gone through in vertical alignment. You need to re-calculate the disparity. So I am pulling that back in. Here is our corrected plate with disparity, and I am putting that into an O_VectorGenerator node. This calculates stereo motion vectors. Disparity is the vector that connects pixels between the left and right view, and motion connects pixels between frames. Forward motion connects pixels to the next frame, and backward to the previous frame, but for a particular view. On the VectorGenerator, we have an Ignore Mask. This excludes regions from the motion calculation. There is also a Foreground Mask. This let’s you cut out and calculate motion for a particular foreground layer. You also have the same parameters to tune as the DisparityGenerator. It will work in very much the same way. So, let’s have a look at the vectors we are calculating here. I am going to switch to looking at the forward motion. Turn this down a little bit, so we can see it more easily, and if I look at a pixel, the red and green channels tell me the x and y offset to the next frame. If you turn up Strength, you can force the motion vectors to match frames. Try this if you have ghosting in your retime where the frames aren’t quite aligned. The trade off here is that the result could have some artefacts, some noise in it. You can also tune Sharpness. This helps to match frames as well as lets the motion separate into different layers. Now we can see the axis starting to appear. Finally, you can smooth that out, if it’s too noisy, using the Smoothness parameter. Now this looks good, but if the layers separate too much, you can actually see tearing between the layers when you do the retime. So I’m going to switch this back to the default settings. What you can do is render out different flavours of motion vectors. You can render out with a strong setting, maybe a sharp setting, or a smooth setting, then you can select the appropriate motion for your retime, or you can even comp together the result from different settings. Now the key thing for VectorGenerator is the Alignment here. It’s calculating the motion vectors for the left and right views simultaneously. Make sure that they match the alignment data that’s been calculated for the plates. You will see I have connected my VectorGenerator to the upstream VerticalAligners to pick up the solve data, but for the aligned plates. You could actually just calculate that alignment data again if you put in a new Solver node.

OK, let’s have a look at the retime now. I have my corrected plates with disparity and the motion vectors I just calculated. I’m pulling them into an Ocula 3.0 Retimer node. The Retimer is quite simple. It allows you to either key a Speed control, or you can specify frames. You can define the warping that’s supplied to the frames to produce the retime results. So let’s have a look at the results of retiming on the left and right views. You will notice there’s some fast motion on the hand here, and that’s causing some ghosting on the retime result. You could look at using a higher Strength, or maybe Sharpness, in the motion vectors to correct this. The important thing here though is that when I switch between left and right, the retime result is the same. That’s because VectorGenerator calculates left and right motion simultaneously.

We can compare that result with Kronos retiming, which will be treating the left and right views separately. This is the result with Kronos, and you can see the retime is different. This is going to stand out when you view it in stereo 3D, so just to illustrate that, I will switch to an Anaglyph node. You can see the error jump out when we switch to see the Kronos result. So it’s fairly simple to generate a retime. If there are any errors, you can try generating multiple retimes with different motion vectors and comp together a fix. You can also fix one view and use retimed disparity to push that fix across onto the other view. So, here I’m using a NewView node set to rebuild the retimed right from the left. We can compare that rebuilt view with the original retimed right view, so you can use retimed disparity to help build perfectly matched retimed plates.

That wraps up this tutorial on retiming with Ocula 3.0. We have covered setting up and preparing the plate, rendering out, and also rendering out motion vectors using the VectorGenerator node, then pulling that in to do a retime with the Retimer node in Ocula 3.0, and how that can work better than retiming views separately, and also tricks about how to rebuild perfectly matched plates, either by comping together several retimes or by pulling fixes across from one view to the other using retimed disparity.