Latest posts

Hi Milko, welcome to the community!

There isn’t a way to stabilise the plate in PFTrack, and it’s usually best not to run a stabilisation at this stage either before tracking or after solving. Doing so can cause alignment issues later, especially with STMaps or 3D data, because stabilising effectively translates the pixels, moving both the centre of projection and the lens distortion on each frame creating inconsistencies. 

So the best workflow is: track your camera and object in PFTrack, export to Fusion, and handle any plate stabilisation there. That keeps your tracking and distortion data clean and your comp flexible.

I’m pretty sure you can import 2D trackers as a .txt to lock or smooth motion in the compositing system but maybe other users familiar with Fusion will be able to help with that? 

Hello Henrique, welcome to the community!

It could be you’re running into a frame-time mismatch between PFTrack and Cinema 4D. The FBX format is time-based, meaning it relies on the frame rate to correctly convert frame numbers into time values during export and import. If PFTrack and C4D are using different frame rates, your camera keyframes might end up in the wrong place.

Here are some things you can do:

1. Check that both applications use the same frame rate. Make sure your PFTrack project and C4D scene are set to identical FPS values.

1. Inspect the scene attributes window in C4D. After importing the FBX, open the Scene Attributes and look at the Time Min/Max and Preview Min/Max fields to confirm the frame range matches your shot.

1. Set the correct frame offset before export. If you want your exported FBX to start at time = 0, set the frame offset in PFTrack to the negative of your first frame number (for example, if your shot starts at frame 1001, set the offset to -1001).

Match Camera uses a point cloud to match features of your footage, not another camera. It depends on what you want to achieve with it. You have to first solve your 360 Footage using Spherical track, and then extract a view that you want to "match" to a different camera to using Survey Solver. You have to enable "Already solved" in the second input within the Survey Solver node.

Hello Angel, welcome to the community.

There are essentially two separate problems to solve here:

1. Loading the metadata from a file and device that PFTrack doesn’t natively support.

2. Applying that data to another camera, in this case, the main (hero) camera, that’s slightly offset from the IMU.
   

The first step is to write a small Python script to parse the CSV and translate the data into something PFTrack understands. You’ll need to inspect what the CSV actually contains and determine how its information maps to PFTrack’s coordinate system. For example, there are many different conventions for pitch, yaw, roll data, different axis orders, sign conventions, and units, so you’ll have to work out how the IMU defines its rotations.

Frame synchronisation is another important consideration. You need to make sure each line in the CSV corresponds to the correct frame of the hero shot. This can get tricky when working with streaming formats like MP4, which are common for these action cameras.

The benefit of EXR is that the metadata is embedded directly in the frame exactly where it's needed.

Once the data is successfully imported, you could use it as a guide or hint to help solve the hero camera. In practice, IMU or gyro metadata often isn’t precise enough to be used directly for compositing, but it can provide a useful starting point for the camera solve.

You also mentioned an alternative workflow involving a “perfect point.” I’m not entirely sure what’s meant by that term, but it sounds similar to using a survey point. You could potentially track your 360° footage, export the resulting point cloud, and then re-import that data into PFTrack as survey points. From there, you could use the Survey Solver node to help align and solve the hero camera.

Hi Josh, welcome to the group!

Whip pans can be tricky to solve. It’s hard to give specific advice without seeing your shot, as there’s no single approach that works for every case. If you’d like more detailed help, you can share your clip here via a link or use Enterprise Support for specific assistance. After you’ve set up your camera and lens, there are some general tips for both tracking and solving:

Tracking

For whip pans, supervised tracking (User Tracks) is generally the most reliable approach because it gives you full control over feature placement. If a tracker fails on a particular frame, you can always manually adjust its position on each frame. Distribute your trackers across both the foreground and background to give the solver as much depth information as possible.

Solving

Start with a short section of your clip where the motion is less extreme, usually at the beginning or end of the shot. Make sure there’s still some parallax visible. Use these frames to generate an initial camera solution, this gives PFTrack a stable reference before you solve. After the solve, inspect your camera curves. Whip pans often produce jumpy curves due to motion blur, so smooth or tweak the curves where needed to keep the motion looking natural and consistent.

Hello,

You may have missed the notification we shared on October 9th regarding the recent updates. We were happy with how the forum was running before, but unfortunately, some background changes made by our hosting provider, which were beyond our control, required us to implement these updates.

We were also unable to migrate the last few threads from the previous forum (including yours), which is why you’re having trouble viewing them. This again was due to the changes made by the hosting provider. However, you can still find all your other threads by using the search tool at the top right of the page.