Building on the internal Camera Library introduced in our last major release, we are excited to introduce a powerful new capability: we are opening up our Sensor Preset Database to third parties. This feature extends our existing library architecture, allowing third-party experts to integrate their own precision sensor data directly into PFTrack. To launch this, we are proud to feature Matchmove Machines CamDB as the first available integration. Why add Matchmove Machines to your library? Enhanced Precision: Sensor sizes are meticulously recalculated from original manufacturer data to eliminate rounding errors. Workflow Efficiency: Instantly access a vast, verified catalog of modern camera bodies and modes without leaving PFTrack. Seamless Extension: Instantly expands your native PFTrack library with specialized third-party data. Upgrade your sensor accuracy today. Learn more about Matchmove Machines CamDB Happy Tracking, The PFTrack Team #sensor

What does it do? We have added a new export scripts for Autodesk Maya that improved compatibility by automatically parenting the camera image plane to the moving camera. Just unzip them into: Documents/The Pixel Farm/PFTrack/exports Contents: mayaASCII-2026-zxy.py mayaASCII-2026.py Once installed, choose “Maya 2026” as the export format. These scripts should work with earlier versions of Maya as well. Downloads: Links: Head back to PFTrack Resources. Or check out our Learning Articles for a deeper look at camera tracking and matchmoving concepts. Or visit our PFTrack Tutorials for step-by-step video guides covering the fundamentals of camera tracking and matchmoving in PFTrack. #scripts

What does it do? This is an example PySide2 script. It allows you to select any node in your project from the popup window. Note: This script will only work with PFTrack Enterprise 24.08.22 and onwards Downloads: Script: import pfpym import PySide2 from PySide2 import QtWidgets, QtCore from PySide2.QtWidgets import QApplication, QDialog, QPushButton, QGridLayout, QVBoxLayout, QLabel from PySide2.QtCore import QSignalMapper def pfMacroName(): return 'PySide2 Dialog' class Form(QDialog): def __init__(self, tree, parent = None): super(Form, self).__init__(parent) self.setWindowTitle("PySide2 Example") self.tree = tree vl = QVBoxLayout() vl.addWidget(QLabel("Jump to a node by clicking on a button")) gl = QGridLayout() vl.addLayout(gl) mapper = QSignalMapper(self) mapper.mapped[str].connect(self.button_clicked) # create a button for each node in the tree row = 0 col = 0 for i in range(self.tree.getNumNodes()): name = tree.getNode(i).getName() # create the button and store its name with the signal mapper b = QPushButton(name) b.clicked.connect(mapper.map) mapper.setMapping(b, name) # add to the grid layout gl.addWidget(b, row, col) col += 1 if col == 4 : col = 0 row += 1 if row == 0 and col == 0 : l = QLabel("Error: No nodes in the tree. Create some nodes and try again") gl.addWidget(l, 1, 0) self.setLayout(vl) @QtCore.Slot(str) def button_clicked(self, name): # find the node in the tree for i in range(self.tree.getNumNodes()): if self.tree.getNode(i).getName() == name : print("Activating node " + name) n = self.tree.getNode(i) # fetch the node position pos = n.getPosition() # move to the centre of the viewport self.tree.setPosition(pos[0], pos[1]) # select the node and activate the editor self.tree.activateEditor(n) # uncomment to close the dialog as soon as the editor is activated #self.accept(); break; def main(tree): # QApplication is already built, so just exec the dialog and # wait for it to run inside the application's event loop form = Form(tree) form.exec() # cleanp form.deleteLater() Links: Head back to PFTrack Resources. Or check out our Learning Articles for a deeper look at camera tracking and matchmoving concepts. Or visit our PFTrack Tutorials for step-by-step video guides covering the fundamentals of camera tracking and matchmoving in PFTrack. #scripts

In high-stakes matchmoving, the conflict between speed and sub-pixel accuracy is constant. Manually inputting camera data is a notorious drain on production time, it requires searching disparate sources for specs, cross-referencing active sensor areas and shooting modes, and then hoping the information found online is reliable. The PFTrack Camera Sensor Database fundamentally changes this workflow. It translates repetitive, error-prone technical setups into a professional standard in just a few clicks, enabling you to dedicate your focus to achieving the highest-quality camera solve, not tedious data entry. This article details why the Database is indispensable for your pipeline, how to leverage its functionality, and the methods for extending it to accommodate proprietary or custom camera assets. Why Accuracy Matters: The Foundation of Your Solve Field of View (FOV) is governed by two core parameters: the camera's sensor size and its focal length. For example, a 50 mm lens on a full-frame (36×24 mm) sensor gives about a 39.6° horizontal FOV; change the sensor to APS-C (24×16 mm), and the same lens yields a narrower FOV of only ≈27° (the “crop factor” effect). These values determine how 2D image data is projected into 3D space, directly influencing perceived scale, perspective, and depth. While PFTrack is highly capable of estimating FOV, and even lens distortion, when explicit sensor or focal length data is unknown, PFTrack performs best when supplied with accurate physical measurements. Providing real-world camera metrics ensures the strongest foundation for precise, repeatable results. This level of accuracy becomes especially critical in multi-shot sequences, where consistent focal length interpretation across shots is essential. Without defined physical parameters, slight variations in estimated FOV can lead to inconsistencies in scene scale, misaligned assets, or solve drift across edits. Even small discrepancies in sensor dimensions, on the order of tenths of a millimeter, can introduce meaningful errors in FOV calculations, which in turn degrade 3D track quality and overall solve fidelity. The bottom line is that supplying accurate, real-world camera metrics removes ambiguity: the solver has one less unknown to estimate, which yields more stable and precise production-grade tracking. While manually entering sensor details can be error prone, especially when relying on ambiguous manufacturer specifications, PFTrack provides the perfect solution: the Camera Sensor Database. The Workflow Advantage: Why Presets Matter When you need to enter the camera sensor size manually switching to the camera sensor database provides four immediate benefits: Eliminating Ambiguity: Manufacturer specifications can be vague, often listing "total" vs. "effective" pixels or using very generalised terminology to approximate size such as ‘Super 35’. Preventing Calculation Errors: Calculating the physical size of a sensor based on pixel pitch or unverified online info is prone to error. A single millimetre of discrepancy can degrade the quality of a 3D solve. Managing Shoot Modes: Modern cameras frequently use specific shoot modes (cropping or windowing the sensor). Manually calculating these deviations is complex; the database provides accurate presets from major manufacturers for these modes in seconds. Team-Wide Consistency: On large features with multiple artists, the database ensures every user is working with identical, verified camera parameters, preventing drift between different shots. For a deeper look on sensor modes and terminology we have a camera sensor size guide available here. Using the Fuji X-H2 as an example: switching to 4K 16:9 significantly reduces the active sensor area compared to the full sensor, causing a noticeable change in field of view (FOV) when using the same lens. Presuming the manufacturer’s full sensor specifications apply to all shoot modes can lead to inaccurate tracking results. The camera sensor database addresses this by providing accurate shoot mode data matched to your clip’s resolution. How to Use the Sensor Database The sensor database is integrated into the areas where camera data is defined. You can access it in two primary locations, the Clip Input node and the Camera Lens Distortion Presets panel. It’s designed to be a seamless part of your workflow and can be launched using the following button . It is broken down into three sections: Database selection and information. Camera make and model selection. Sensor information and shoot mode selection. Camera Sensor Database in action Quickly select verified sensor presets and ensure physically accurate FOV across your shots in PFTrack. Find Your Camera: Type in your manufacturer or camera model in or browse the list (e.g. "RED Komodo" or "Sony Venice"). Select the ‘Shoot Mode’: Pick the sensor shoot mode used in the clip. Modes that don’t match resolution will be greyed out. Click ‘Use Sensor’ to automatically fill in the sensor measurements in both Clip Input Node & camera lens distortion presets. You can filter the list further by checking for proxies 2x & 4x as well as matching resolution and aspect ratio. Pro Tip: Need more flexibility The database allows users to switch between The Pixel Farm’s internal database and the Matchmove Machines database. This provides unparalleled flexibility, if a specific or niche camera body isn't found in one, a quick toggle often finds it in the other. Expanding the Database: Custom XML Data For proprietary camera rigs, prototypes, or bespoke setups, PFTrack allows you to expand the database with your own metrics. By creating a custom sensor xml file, you can define custom sensor sizes for your projects that can be selected directly within the camera sensor database. File structure: To simplify the process, PFTrack ships with an example-sensors.xml file. This file serves as a template for defining your own , , and . You can find the template in the installation folder on your system /media/example-sensors.xml. The custom .xml file you create can be named whatever you want. Where to put your custom file? Once you have created your custom xml file you will need to place it in the directory listed below, once in place relaunch PFTrack and you will have access to the updated file via the camera sensor database dropdown. MacOS: /Users/USERNAME/Documents/The Pixel Farm/PFTrack/presets/sensors Windows: C:\Users\USERNAME\Documents\The Pixel Farm\PFTrack\presets\sensors Linux: /home/USERNAME/Documents/The Pixel Farm/PFTrack/presets/sensors For a deep dive into the XML schema and specific formatting rules, please refer to our User Defined File Formats Documentation. Pro Tip: Centralised Management - for Multi-User Pipelines For studios managing multiple PFTrack seats, maintaining a "single source of truth" for camera data is essential for pipeline integrity. Rather than managing local files on every machine, you can centralise your custom presets: Place your custom.xml file in a centralised network location accessible by all workstations. In the PFTrack software settings, navigate to ‘Additional file locations’ and point the ‘Sensor presets’ path to your network directory. Once configured, any update made to the central XML file is propagated across the entire facility and available in PFTrack on relaunch. This centralised approach allows Pipeline TDs to deploy updated camera information for a specific feature or production once, ensuring every artist, regardless of their workstation, is working with identical, verified technical specifications. You can use multiple xml files as well with each defining the cameras used for a specific production, this can be further customised with a project or company logo. Conclusion The Camera Sensor Database isn't just a convenience; it is a precision tool. By moving away from manual entry and unverified data, you safeguard your solves and streamline your pipeline. Ready to upgrade your tracking? Ensure you are running the latest version of PFTrack to access the most recent camera sensor database updates. Want to add a camera model to our database, or discuss a camera system you're using for tracking with other professional matchmovers? Join our support community here. Try PFTrack Solo Free Try PFTrack Solo free for 7 days, with full export functionality, enough time to try out The Camera Sensor database for yourself. #sensor #calibration

What’s the difference between automatic and manual tracking? Which is better? When should I use one instead of the other? And how do the differences affect the camera solver? In this article we’ll take a look at some of the more technical details of how trackers are used in PFTrack, and suggest some ways of getting the most out of PFTrack’s advanced feature tracking tools. What is a tracker? A tracker defines the location of a single point in 3D space, as viewed by a camera in multiple frames. In PFTrack, trackers are generally created using two nodes: Auto Track and User Track. The Auto Track node is able to generate a large number of estimated trackers automatically, and the User Track node provides manual tracking tools for precise control over exactly where each tracker is placed in each frame. Trackers form the backbone of any camera solve, and they are used to work out how the camera is moving along with its focal length and lens distortion if they are unknown. But how many trackers do you need, and what is the best way of generating them? How are trackers used to solve the camera? When solving for the camera motion in a fixed scene under normal circumstances, PFTrack needs a minimum of 6 trackers to estimate the motion from one frame to the next. This is the bare minimum, however, and we generally recommend using at least 8 or 10, especially if you’re not sure of the focal length, sensor size, or lens distortion of your camera. Using a few more than the minimum can also help smooth out transitions in the camera path from one frame to the next, where one tracker might vanish and another one appears in the next frame. Trackers should be placed at points that are static in the real world (i.e. do not move in 3D space), such as the corner of a window frame or a distinguishable mark in an area of brickwork. This allows the 3D coordinates of the point to be estimated, which in turn helps to locate where the camera is in each frame. To help with estimating camera motion, trackers also need to be placed in both the foreground and background of your shot, especially when trying to estimate focal length, as this provides essential parallax information to help the solve. It’s also important to have trackers placed in as many parts of the frame as possible, rather than just bunching them together in a single area. Think of your camera’s grid display as dividing your frame into a 3x3 grid of boxes - try to have at least one tracker in each box in every frame, and you’ll have good overall coverage. Not every tracker is equal We’ll get into the details of how to generate trackers shortly, but before we do it’s important to understand that not every tracker is considered equally when solving the camera. The most significant distinction is whether a tracker is defined as being a soft or hard constraint on the camera motion. Hard constraints mean the placement of the tracker in every frame is assumed to be exact. If you’ve generated trackers manually using a User Track then these will be set as hard constraints by default. The solver will try to adjust the camera position and orientation to make the tracker’s 3D position line up with its 2D position exactly in every frame when viewed through the camera lens. On the other hand, trackers that are generated automatically with the Auto Track node are marked as soft constraints and don’t have to be placed exactly in every frame. The camera solver is able to recognise that some errors in the 2D positions exist and ignore them. These are often referred to as “outliers” and might correspond to a temporary jump in the tracker position for a couple of frames or the subtle motion of a background tree in the wind, resulting in the 3D location of the tracking point changing from frame to frame. So now that we’ve explained some of the details about how the camera solver uses trackers, what is the best way of generating them? Auto-Track? User-Track? Or both? Ultimately, the answer to this comes down to experience with the type of shot you’re tracking, how much time you have to spend on it, and the final level of accuracy you need to complete your composite. To get started, here are some guidelines that should help you quickly get the most out of PFTrack’s tools. Automatic feature tracking If you have all the time in the world to track your shot, then of course, manually placing each tracker in every frame is the way to go, as this ensures each one is placed exactly where it should be. Alternatively, automatic feature tracking is a way of generating a large number of trackers very quickly, but because the tracking algorithm is attempting to quickly analyse the image data and work out the best locations to place them, not every tracker is going to be perfect. The Auto Track node picks out a large number of "interesting" points and corners in each image, and tracks those points bi-directionally between each pair of frames (i.e. from frame 1 to 2 and then from 2 back to 1). It compensates for any differences in exposure or lighting whilst doing this, and also tries to ensure that jumps and inconsistencies in the motion of each point between frames are avoided wherever possible. After all the points are tracked, it filters them down to select around 40 trackers in each frame (using the default settings). The trackers are chosen in a way that tries to distribute them evenly over the image area whilst also ensuring tracks with the longest length are used wherever possible, so each tracker is visible in many frames of the clip to help out the camera solver. However, these trackers may end up being placed on objects that are moving independently from the camera, or at other locations that cannot be resolved to a single point in 3D space. For example, so-called “false corners” that result from the intersection of two lines at different distances from the camera can often be indistinguishable from real corners when looking at a single image. Whilst the camera solver will ignore these outliers to a certain extent, having too many trackers falling into these categories can adversely affect the solve, so how should you deal with them? Identifying errors Whilst PFTrack will attempt to detect when tracking fails, not every glitch can be easily detected, especially when your shot contains motion blur or fast camera movement. It’s always worth reviewing automatic tracking results to check whether there are any obvious errors. For example, the motion graphs in the Auto Track node can be used to quickly identify trackers that are moving differently from the others. Trackers can be selected for adjustment or deletion The “Centre View” tool can also be used to lock the viewport onto a single tracker. Scrubbing forwards and backwards through the shot will often expose motion that is subtly different from the background scene, which may indicate a false corner or other gradual object movement. Adjusting trackers So now you’ve identified some trackers that need some attention. What’s next? If you just need to make a few quick adjustments, such as adjusting tracker visibility or re-positioning it in a couple of frames, the Auto Track node provides some Tracker Adjustment tools directly in the Cinema window you can use to get the job done: Tracker adjustment tools You can use these tools to make any minor adjustments to your tracking points before passing them downstream to the camera solver. If you want finer-grain control over your adjustments you can also use the Fetch tool in the User Track node to convert an automatic tracker into a manual one, and all the tools of the User Track node are available to you to adjust the tracker as needed. To adjust or disable? You can manually correct every single one of your automatic trackers if you wish, but as we mentioned earlier, the Auto Track node generates many more trackers than are actually needed to solve the camera motion. This means you may well be spending a lot of time unnecessarily correcting trackers if you have a particularly tricky shot. It can often be just as effective to quickly disable the bad trackers, especially if time is short. This is certainly the case if you’ve only got a few outliers, and also have other trackers nearby that don't need fixing. You could also use the masking tools in PFTrack to mask out any moving objects before automatic tracking, although it’s important to weigh the time it will take you to draw the mask against the time it takes to identify and disable a handful of trackers afterwards. Remember that trackers should be distributed over as much of the frame as possible, and we recommend a minimum of around 10 in each frame, so keep this in mind when disabling. If you end up having to disable a lot and are approaching single-figures, then maybe a different strategy is going to be necessary: supervised tracking. Supervised feature tracking Ultimately, a lot of shots will need some level of manual, or 'supervised', tracking using the User Track node. This is especially important if you’re tracking an action shot with actors temporarily obscuring the background scene. One limitation of automatic feature tracking is that it can’t connect features from widely different parts of the shot together if something is blocking their view or the feature point moves out of frame for a significant length of time. In these cases, human intervention is often necessary, and this is where the User Track node comes into play, allowing you to create trackers from scratch to perform specific tasks. For example, you may have a shot where the camera pans away from an important area for a few seconds and then pans back. Or an actor may walk in front of an important point before moving out of frame. In these cases, you want to make sure the 3D coordinates of points at the beginning are the same as at the end. Creating a single tracker and manually tracking over frames where it is visible (whilst hiding the tracker in frames where it is not visible) will achieve this goal. The same guidelines apply when creating tracking points manually - try to distribute them over your entire frame, and make sure that you’ve got a good number of trackers in each frame. Also, try not to have many trackers stop or start on the same frame (especially when they are treated as hard constraints), as this can sometimes cause jumps in your camera path during the solve that will require smoothing out. If you do, adding a couple of “bridging” trackers elsewhere in the image that are well tracked before and after the frame in question can often help out. Wrap Up Hopefully, this article has shed some light on things to consider when tracking your points. In the end, this all comes down to experience, and as you track more shots, you’ll get a better feel for when to use specific tools, and whether to start with supervised tracking straight away or give the Auto Track node a go first of all. If you are using automatic tracking, you can easily place an empty user track node between the Auto Track and Camera Solver to hold any user tracks that you may want to create manually as you solve your camera. Also, don’t worry about getting every tracker perfect before you first attempt a camera solve. It’s often possible to try auto tracking first and see where that gets you, then consider how to address any problems and add a few user tracks to help the solver out. PFTrack lets you adjust and change your trackers however you want. If you’ve almost got a solve but can see a bit of drift in a few frames, try creating a single manual tracker over those frames in a sparsely populated area of the image, then solve for the 3D position of that tracker alone, fix your focal length and refine your solution - you don’t have to solve from scratch every time. #tracking #guide

A substantial release. New Hero Cloud node, direct export to Postshot for Gaussian splat training, USD export with dense point clouds, Photo Mesh integration with Hero Cloud, 7-day full-export trial mode, and a number of fixes. Available now from your PFTrack account. You can find the full release notes in the PFTrack development record. Overview PFTrack 26.05.19 is one of the more substantial releases we’ve shipped in some time. The headline addition is Hero Cloud, a new node that generates a measured 3D point cloud directly from a single tracked plate. The release also extends PFTrack’s export pipeline with a direct export to Postshot in COLMAP format for Gaussian splat training, USD export with dense point clouds plus per-point normals and colour, and Photo Mesh integration with the new Hero Cloud node (Studio and Enterprise editions). The trial mode has been extended too: new users on the Solo trial now get full export functionality for seven days, which means a trial user can take a real plate from track all the way through Hero Cloud and into Postshot or USD. Full changelog below. All changes are in 26.05.19 unless otherwise noted. New Features Hero Cloud node (all editions) A new node in the Geometry category. Hero Cloud builds a dense 3D point cloud from a solved camera. Run it on any plate that’s been tracked and solved — the node will reconstruct depth from the camera’s movement through the scene and produce a measured point cloud ready for downstream use. Hero Cloud works with any footage PFTrack can track: cinema cameras, drones, body-cams, dash-cams, action cameras, mirrorless and DSLR, CCTV, archival film. The shot needs parallax in the camera move — most production footage has enough. Available in every PFTrack edition (Solo, Studio, Enterprise). Full documentation and a hands-on tutorial are linked at the end of this article. Postshot export node (all editions) A new export option in the Scene Export node. Writes Hero Cloud point clouds and the associated tracked cameras out in COLMAP format — the standard input for Postshot and the wider Gaussian splat training ecosystem. Track the plate, run Hero Cloud, export to Postshot, train your splat. The whole flow stays inside artist-friendly tools. USD export with dense point clouds (all editions) USD export now supports dense point clouds with per-point normal and colour data. Cleaner integration with Unreal Engine, Maya, Houdini, and the rest of the USD-aware ecosystem. The point cloud carries directional and visual information into downstream tools rather than just spatial coordinates. Active Camera viewport (all editions) Viewer windows now have an Active Camera viewport with an option to snap the camera pose to the active clip. Useful for verifying Hero Cloud reconstruction visually against the source plate, but it has wider workflow value too — anywhere you want a quick “see what the tracked camera saw” view. Trial mode now full export for 7 days (Solo trial) New users on the Solo trial can now export at full functionality for seven days, rather than only being able to evaluate the toolset. A trial user can now take a real plate all the way from track through Hero Cloud and out to Postshot, USD, FBX, or any of PFTrack’s supported formats. Updates and Improvements Photo Mesh integration with Hero Cloud (Studio and Enterprise) Photo Mesh has been updated to consume Hero Cloud point clouds as input. For Studio and Enterprise users who need a finished textured mesh from a single shot, the path now exists inside PFTrack — Hero Cloud feeds the cloud, Photo Mesh surfaces it. No external tools required. FBX export for large dense point clouds (all editions) FBX export now handles very large dense point clouds more reliably. If you’ve hit issues exporting big clouds via FBX in earlier builds, this build should resolve them. Fixes Spherical tracking node connection issues (Studio and Enterprise) Several node connection issues in the spherical tracking toolset have been resolved. If you’ve hit unexpected behaviour wiring up Spherical Track or Spherical Orient, this build should clean things up. Multi-sample motion blur on retimed footage (all editions) Some rendering issues when applying multi-sample motion blur through the Retime node have been fixed. Results should now be more predictable on retimed plates. Point Cloud node keyboard shortcuts (Studio and Enterprise) Some missing keyboard shortcuts in the Point Cloud node have been restored. Other UI updates and fixes (all editions) Various smaller fixes and UI updates across the application. If you’ve had a specific niggle that’s been bothering you, there’s a fair chance it’s addressed here. How to Get It Existing customers can download PFTrack 26.05.19 directly from your PFTrack account. Sign in, navigate to your downloads, grab the latest build. New users can try PFTrack Solo free for seven days with the new full-export trial — enough time to take a real plate from track all the way through Hero Cloud and into your pipeline. Studio is available on rent-to-buy for 5 or 30 days, or as a perpetual purchase. Learn More Hero Cloud announcement Hero Cloud hands-on tutorial PFTrack documentation PFTrack development record Feedback Hero Cloud is the first piece of a wider through-the-lens reconstruction toolset. We’re curious how it works in real production use — where it succeeds, where it doesn’t, and what edge cases we haven’t yet seen. The reconstruction techniques behind it have considerable headroom, and your feedback shapes what we ship next. Reply via the community forum, or by getting in touch directly. All routes get back to us. Try PFTrack Solo Free Try PFTrack Solo free for 7 days, with full export functionality, enough time to take a real plate from track through Hero Cloud and into Postshot, USD, or your DCC of choice.

Build 26.08.04 is now live for Solo, Studio and Enterprise. This update sharpens the moment your solve leaves PFTrack, because a solve proves itself in the final image, and at today's resolutions, the screen forgives nothing, alongside faster Hero Cloud processing and a set of workflow refinements driven by our global user community. Pixel-Perfect Interchange Internal 2D imaging coordinate systems have been updated to match pixel data precisely with third-party applications, so the camera you deliver holds up wherever the shot is finished. OpenEXR import now selects full or half-float bit depth more intelligently, and export issues when transcoding 59.94 fps MPEG sources to alternative frame rates have been resolved. Faster Hero Cloud Hero Cloud processing time is reduced when working with portrait-oriented clips — dense, through-the-lens spatial capture, quicker on the formats today's productions actually shoot. Smarter Everyday Workflow New relink buttons for Mask and ST-Map in the Clip Input node, a recent-projects list that keeps offline projects in place until you remove them, and a tracker group selection menu on the Camera-to-Object node for finer control over moving-object conversion. Refined Tracking and Depth Auto Track now distributes spatial features more effectively when using smaller tracker counts, and a Z-Depth Solver issue that could reduce depth accuracy when using optical flow hints has been fixed (Studio/Enterprise). One to note Newly imported Windows Media Foundation files now start at frame 1 rather than frame 0 — configurable in preferences if your pipeline expects the previous behaviour. Community-Driven Refinements As ever, this build closes out a series of user-reported issues, from ST-map error reporting and export preferences to node connection logic, OpenGL rendering and the Python API. PFTrack 26.08.04 is available for download now. Read the full release notes — and ten years of them — in the

A decade ago, a feature shoot meant ARRI or RED. The matchmove team got two or three camera systems, a known set of lenses, and metadata that, if it arrived at all, arrived in a single format you could plan around. That's not what production looks like now. Today, a streaming feature mixes ARRI principal photography with DJI drone aerials, second-unit on RED Komodo, witness cameras on GoPro Hero, and reference photogrammetry on a high-resolution mirrorless DSLR. Five capture sources. Five metadata vocabularies. One location, one set of VFX work, one scene that has to reconstruct cleanly across all of them. This article walks through how PFTrack's metadata pipeline is built to handle that reality, why metadata is the foundation of a precise solve, and how PFTrack's multi-shot scene architecture combines heterogeneous capture into a single coherent reconstruction. It's a longer read than most of our learning articles, because the topic spans both the what of metadata and the why of architectural decisions that affect every shot you'll matchmove this year. If you'd rather start with the underlying mechanics, our PFTrack Camera Sensor Database and Sensor Size: A Practical Guide for Camera Tracking articles are good companion pieces. What Metadata Means in 2026 Before going further, it's worth being precise about the term. Metadata, in matchmoving and scene reconstruction, doesn't mean ID3 tags or file timestamps. It means the spatial, optical and motion information a capture device records alongside the image, information that describes the physical reality of how that image was made. In a modern shot, you might find: Optical parameters — focal length, focus distance, T-stop, zoom position, entrance pupil, hyperfocal distance, lens distortion model. Sensor parameters — sensor size, active area, resolution, pixel pitch, recording mode, crop factor. Motion parameters — orientation, GPS position, accelerometer and gyroscope data, gimbal state, time-coded movement curves. Identification parameters — camera body model, lens model, lens serial number, recording timestamp. Different capture devices record different subsets of this list, in different formats, with different precision. A Cooke S7/i full-frame prime with /i Cubed Technology records a rich superset that includes frame-by-frame distortion mapping. A GoPro Hero records GPMF, a smaller subset, but with high-frequency telemetry. A phone records EXIF, basic but ubiquitous. A drone records flight logs at one cadence and per-frame metadata at another. Each capture tier has its own metadata vocabulary. The post-production challenge, and the unsolved problem in most matchmove pipelines, is making all of those vocabularies structurally compatible inside a single solver. For a deeper look at how sensor data specifically affects your solve, see our guide to sensor size a practical guide for camera tracking. Why Metadata Matters: The Foundation of Your Solve The temptation, especially on simpler shots, is to treat metadata as nice-to-have. PFTrack can estimate Field of View, focal length and even lens distortion when explicit data is missing, and it does so well. So why bother? Three reasons that matter on every production: 1. Accuracy compounds. Even small discrepancies in sensor dimensions, on the order of tenths of a millimetre, introduce meaningful errors in FOV calculations, which in turn degrade 3D track quality. On a single shot, the error might be acceptable. Across a sequence of fifteen shots that need to share coordinate space, the same error accumulates into noticeable drift. 2. The solver has fewer unknowns to estimate. Every piece of verified physical data you supply — sensor size, focal length, distortion model — removes one variable from what the Camera Solver has to figure out from image data alone. The fewer unknowns, the more stable the solve. 3. Consistency across shots becomes possible. This is the one that bites in multi-shot work. If shot one's camera parameters were estimated and shot two's were verified, the two solves don't sit cleanly in the same coordinate space, which means CG elements placed on shot one's plate won't sit correctly when the camera cuts to shot two's. The whole multi-shot reconstruction depends on consistent, verified inputs. This is why metadata is foundational, not optional. It's also why PFTrack treats metadata as a first-class architectural concept, not a sidecar to the solver. For a complementary read on why physical parameters matter, see our article on distortion calibration. What PFTrack Reads: The Practical Breakdown PFTrack reads metadata across the major capture sources in modern moving-image production. Native, automatic ingest where the format supports it; structured XML and EXIF parsing where required; federated sensor database lookup for everything else. Here's the practical breakdown by capture tier. Cinema lens metadata protocols Cooke /i Technology — the cinema industry's standard lens metadata protocol, supported across all three protocol generations through the Clip Input node. /i Squared adds inertial tracking and shading data; /i Cubed adds per-lens distortion mapping. Per-frame focal length, focus distance, T-stop, entrance pupil, hyperfocal distance and inertial data all feed the solver directly. ZEISS eXtended Data — included within the /i Technology ecosystem, handled through the same pipeline. ZEISS Horizon Anamorphic lenses stream precise, frame-by-frame focal length metadata, giving PFTrack the exact optical data needed for a flawless camera solve. Discover the tech platform at ZEISS. (Image rights: ZEISS) Cinema and broadcast camera metadata RED R3D — camera and lens metadata read automatically from native R3D files. Focal length, sensor identification and recording parameters all populate without manual entry. ARRI ALEXA family — camera and lens metadata read from native ARRI sources, with support for ARRI metadata embedded in DPX, OpenEXR and Quicktime ProRes containers. Sony Venice and Venice 2 — OpenEXR files containing MXF metadata generated by the Sony RAW Viewer application are parsed for camera and lens parameters. Custom metadata mapping — PFTrack can be configured to read camera, lens and body parameters from non-standard or custom metadata tags using a metatags.xml definition. Rather than requiring metadata to arrive in a fixed format, an artist or pipeline TD can map PFTrack’s parameters (focal length, sensor make and model, frame rate, position and orientation) to whatever tag names a given production’s files actually use, including custom tags embedded in EXRs by a bespoke on-set or virtual production system. See the metadata tags documentation for the full schema. An example of RED metadata correctly displaying the camera make, model, and shooting mode, along with IMU rotation data. PFTrack allows users not only to choose which metadata fields to use, but also to determine how that metadata is applied within the tracking workflow. Photographic metadata EXIF — the universal stills camera metadata standard. PFTrack reads EXIF from any digital stills camera that writes it, including DSLRs, mirrorless cameras, smartphones and tablets. Focal length, sensor identification and lens information are all surfaced through the Photo Input node. XMP — the extended metadata standard used alongside EXIF, including GPS coordinates and orientation data where available. Particularly relevant for photogrammetry workflows where geotagged source images need to be aligned with real-world coordinate systems. In this example, a DJI drone has surveyed an area by capturing a series of still photographs. PFTrack can automatically extract the correct sensor size and focal length from the images' EXIF metadata. It can also read GPS coordinates for positioning, along with orientation and altitude data recorded by the drone's IMU, providing a strong starting point for virtual scene reconstruction. Action and consumer capture Mobile cinematography — iPhone Pro, iPad Pro and Android equivalents writing EXIF and XMP through their native capture pipelines are handled through the standard photographic metadata pathway. Action cameras and drones — GoPro, DJI and similar devices writing EXIF and standard metadata are supported through the photographic metadata pathway. (Format-specific handling for GPMF telemetry and DJI flight logs is on the active development roadmap; the architectural foundation for that ingest is already in place.) Federated sensor data Where source files don't carry sensor metadata, or carry only partial information, PFTrack supplements with the Camera Sensor Database. The 2025 release added support for external sensor databases, beginning with Matchmove Machine's CamDB integration. For full detail on how to use it, see the dedicated PFTrack Camera Sensor Database article. PFTrack's Camera Sensor Database combines the power of metadata with a large database of known cameras and their respective shoot modes. The Active Metadata Window: One Interface, Every Source When a clip or photograph is loaded into PFTrack, the metadata embedded in or accompanying that media is parsed and displayed in the Metadata Parameters Window, in the Metadata tab in the Clip Input/Photo Input interface. The window is structured the same way regardless of source: Camera Body — sensor size, sensor area, camera make and model, recording mode information. Camera Lens — focal length, focus distance, T-stop, zoom position, lens make, model and serial number where available. Photo Metadata (for stills inputs) — full EXIF and XMP payload including GPS and orientation data. Source-specific extensions — additional sections appear when relevant, such as inertial data from /i Squared lenses or telemetry from drone footage. This consistent structure is itself an architectural decision worth noting. An artist working with a shot from a Sony Venice sees their metadata in the same shape and position as an artist working with a shot from a smartphone. The interface teaches one mental model; the underlying parsers do the work of normalising across formats. For complete reference, see the Clip Input node documentation and the Photo Input node documentation. When Metadata Doesn't Arrive How You Expect Real productions rarely deliver metadata in a tidy, predictable form. Tags get embedded inconsistently, custom on-set systems write to non-standard fields, and EXRs arrive carrying camera and lens data under names no two facilities agree on. This is where a lot of pipelines stall. PFTrack’s customisable metadata mapping is built for exactly this. Using a metatags.xml definition, you can tell PFTrack where to find camera and lens data even when it arrives in a non-standard format or is embedded inconsistently within a file. Map focal length, sensor make and model, frame rate, or position and orientation to whatever tag names your production actually uses, and PFTrack reads them as if they were native. Rather than being limited by rigid metadata requirements, PFTrack adapts to the way your production delivers data, so critical camera information can still drive accurate tracking, solving and pipeline integration instead of being lost because it arrived in the wrong shape. It’s the kind of flexibility that keeps a project moving when other tools would simply fail to read the file. For the full schema and worked examples, including reading position and orientation metadata from drones, and frame rate from movie clips, see the metadata tags documentation. The Connect Toggle: How Artists Control Trust Every metadata value displayed in the Metadata Parameters Window has a Connect toggle next to it. Disconnected (default). The metadata value is parsed and visible, but not used by the virtual camera model. The artist can see what the file claims about itself without committing to it. Hint. The metadata value is used as a guide rather than a hard input. For example, a sensor identifier might be used as a hint to narrow the Camera Sensor Database lookup, rather than treated as the definitive sensor specification. Connected. The metadata value is used directly as an input to the virtual camera model. A Connected focal length value populates the virtual camera's focal length parameter; a Connected sensor size populates its sensor parameter; a Connected /i distortion payload feeds the distortion pipeline. Each metadata field includes a Connect toggle with three modes: Disconnected (visible only), Hint (used as guidance), and Connected (used directly by the virtual camera model). This three-state system is the practical answer to the trust problem. Not all metadata deserves equal weight: A focal length from a high-end cinema lens with /i Technology can be Connected with confidence, the protocol records the data accurately, the lens is calibrated, the trust is earned. A focal length from a phone with unclear post-processing history is better set to Hint, visible to the solver as guidance, but not treated as gospel. A metadata field of dubious provenance (uncertain sensor mode, unverified lens identification) can stay Disconnected entirely. The artist makes the call, shot by shot, value by value. A pipeline that auto-applies all metadata equally is a pipeline that breaks under real production conditions; the Connect toggle is the practical mechanism that prevents that. Pro Tip: Phone metadata is more useful than you think Modern phones increasingly write spatial metadata that, until recently, would have been considered semi-professional. iPhone Pro and Android equivalents writing EXIF data through their native capture pipelines often produce surprisingly reliable focal length values. Set them to Hint rather than ignoring them outright, the solver benefits from the guidance even when the data isn't precise enough to Connect directly. Time-Varying Metadata: The Dynamic Metadata Viewer For time-varying metadata, values that change across the duration of a shot, PFTrack provides the Dynamic Metadata Viewer, accessible from any clip with such data present and parsed in the Metadata tab. Dynamic metadata greatly improves workflows involving zoom lenses, where accurate tracking can be notoriously challenging, especially when on-screen tracking features are constrained. The viewer displays metadata as curves: Zoom moves become focal-length curves. GPS data becomes per-frame position data. IMU data becomes orientation and motion history. The viewer presents this metadata in a user-friendly way, letting the artist quickly assess its quality, checking for noise, dropouts, or discontinuities that might make a section unreliable, and decide how each source should be used in the solve. Zoom data, for instance, can be connected and used directly, or treated as a hint depending on how much confidence the artist has in it. GPS and IMU data, which are often noisy and prone to drift, can instead be fed into the solver as hints, helping resolve ambiguities and significantly reduce search times even when the raw values aren't accurate enough to use outright. PFTrack’s Metadata Parameters Window with Connected values for sensor, recording mode, lens type and focal position. Below, the Dynamic Metadata Viewer plots the zoom lens's focal length curve over time, critical data for shots involving crash zooms or other complex optical movements. For shots where the on-set metadata recording was imperfect, a common reality on long days with multiple operators, the viewer makes these imperfections visible rather than baking them invisibly into the solve. This matters more in 2026 than it did in 2016. Modern productions routinely include time-varying metadata from heterogeneous sources in the same sequence: a focus pull from a /i Cubed cinema lens, GPS and IMU data from a drone, a stabilisation log from an action camera. The Dynamic Metadata Viewer is the surface where those different sources become legible to the artist as comparable curves. The Multi-Shot Scene: Where Metadata Becomes Spatial Intelligence Reading metadata cleanly from any single shot is the first half of the problem. Combining metadata from many shots, captured on different cameras, from different vantage points, into a single coherent scene is the second. This is where PFTrack's architecture differs structurally from most matchmove tools. In PFTrack, shots aren't independent units of work. They're members of a scene. A PFTrack project can hold many shots, each with its own metadata payload, its own solver state, its own tracked features and survey points, but all of those shots share a single underlying scene: one coordinate system, one set of geometry, one survey of common features, one reconstruction. One Scene. Endless Data Types. PFTrack brings together footage from every camera system, cinema rigs, drones, action cameras, and more, within a single 3D workspace. By simultaneously ingesting the unique metadata generated by each system, such as the examples above, PFTrack applies advanced spatial intelligence to cross-reference and correlate this information, delivering exceptional reconstruction accuracy. That’s the PFTrack advantage: completely different metadata sources, working together seamlessly to build the most accurate representation of your scene. When you solve shot one, the resulting camera position and scene geometry exist in a coordinate space that shot two will join when it's solved. When shot two contributes new survey points or geometry, those become available to shot three. Cross-shot constraints, shared markers, shared geometry, shared photogrammetric reconstructions, refine the solves of every shot they touch, not just the one currently active. The practical consequences compound across a production: Shared geometry across shots. A photogrammetric reconstruction built from a single shot is automatically available to every other shot in the scene as solving reference. An ARRI principal-photography solve can use geometry derived from drone aerial passes; a witness-camera solve can use geometry derived from cinema photography. Shared survey points across shots. A surveyed feature visible in multiple shots constrains the solve of every shot it appears in, simultaneously. Solver convergence improves as the scene accumulates more shots, not despite them. Coordinate consistency across capture sources. A drone pass solved with DJI metadata, a cinema shot solved with ARRI metadata, and a witness shot solved with GoPro metadata all end up in the same coordinate space, without manual alignment, without after-the-fact transforms, without precision degradation across capture sources. Scene-level photogrammetry. Photogrammetric reconstruction in PFTrack isn't a separate process from matchmoving — it's an output of the same scene that the matchmove solves contribute to. See the Photo Cloud and Photo Mesh node documentation for the dense reconstruction workflow, and Align Cameras and Merge Cameras for the multi-shot consolidation utilities. This is the architectural commitment that makes the metadata breadth operationally meaningful. Reading the major metadata formats is necessary, but it isn’t sufficient. Combining the resulting solves into a single coherent scene is what turns metadata into spatial intelligence. Pro Tip: Build your scene incrementally When working a multi-shot production with mixed capture sources, start with the shot that has the strongest metadata, usually the principal photography on a cinema camera with /i data. Solve it cleanly, establish the scene's coordinate space, then bring in shots with weaker metadata (consumer cameras, drones) and let the established scene constrain their solves. The metadata-rich shots act as anchors; the metadata-poor shots benefit from the geometry the anchors have established. This is the most reliable way to get coordinate consistency across heterogeneous capture in a single PFTrack project. The Architectural Position The pieces above, the Metadata Parameters Window, the Connect toggle system, the Dynamic Metadata Viewer, the federated Camera Sensor Database, the multi-shot scene architecture, aren't a list of features. They're a single architectural commitment, refined across more than two decades, that metadata belongs at the centre of the pipeline and shots belong inside scenes. The practical result of that commitment is straightforward, and worth saying plainly: PFTrack is the only commercially available 3D camera tracking and scene reconstruction application built around a unified metadata pipeline, ingesting cinema lens protocols, cinema and broadcast camera metadata, consumer capture data and stills photogrammetry sources, and combining them across multiple shots into a single coherent scene. Other matchmove tools handle a subset of cinema metadata formats well. Compositing plugins like the recent Cooke Lens Distortion plugin for Nuke handle specific cinema metadata tasks within a compositing pipeline. Dedicated photogrammetry applications handle EXIF metadata thoroughly within a stills-only workflow. Each does excellent work within its scope. But the position PFTrack occupies, the cross-tier, heterogeneous, artist-controlled metadata pipeline feeding a unified multi-shot scene, is, as far as we can evidence, structurally unique within the 3D camera tracking and scene reconstruction category. It was built deliberately, and it matters because the production landscape that needs it now is broader than the cinema VFX world that originally shaped it. That's the architectural position. It's also the practical reason why mixed-capture productions, cinema plus drone plus mobile plus witness, work in PFTrack the way they're now expected to work. FAQ Does PFTrack support Cooke /i Technology lens metadata? Yes. PFTrack supports all three generations of Cooke /i Technology — /i, /i Squared and /i Cubed, through the Clip Input node. Per-frame focal length, focus distance, T-stop, entrance pupil, hyperfocal distance and inertial data feed directly into the solver, with /i Cubed adding per-lens distortion mapping. Does PFTrack read metadata from RED R3D files automatically? Yes. PFTrack reads camera and lens metadata automatically from native RED R3D files, including focal length, focus distance, sensor identification and recording parameters, with no manual entry required. Does PFTrack support ARRI ALEXA camera metadata? Yes. PFTrack reads camera and lens metadata from native ARRI ALEXA sources, including ARRI metadata embedded in DPX, OpenEXR and Quicktime ProRes containers. Does PFTrack support Sony Venice and Venice 2 metadata? Yes. PFTrack parses OpenEXR files containing MXF metadata generated by Sony's RAW Viewer application to extract camera and lens parameters from Venice and Venice 2 footage. Does PFTrack support ZEISS eXtended Data? Yes. ZEISS eXtended Data is handled within PFTrack's Cooke /i Technology ecosystem through the same Clip Input pipeline. What is the Active Metadata Parameters Window in PFTrack? The Active Metadata Parameters Window is a permanent panel in the PFTrack interface that displays all metadata parsed from a loaded clip or photograph in a consistent layout, covering camera body, camera lens, photo metadata (EXIF/XMP), and source-specific extensions such as inertial or drone telemetry data, regardless of the original capture source. What is the Connect toggle and what do its three states mean? The Connect toggle controls how each metadata value is used by PFTrack's virtual camera model. Disconnected means the value is visible but unused; Hint means it guides the solver without being treated as definitive; Connected means it's applied directly, populating parameters such as focal length, sensor size or the distortion model. What is the Dynamic Metadata Viewer used for? The Dynamic Metadata Viewer displays time-varying metadata, such as zoom moves, IMU data and GPS data, as curves across the frame range, letting artists identify noise or discontinuities before deciding which sections feed the solve. What is PFTrack's Camera Sensor Database? The Camera Sensor Database is a federated lookup PFTrack uses to supply sensor information when a source file's metadata is missing or incomplete. The 2025 release added support for external sensor databases, beginning with Matchmove Machine's CamDB integration. What happens if PFTrack receives metadata in a non-standard or inconsistently embedded format? PFTrack's customisable metadata mapping lets users define, via a metatags.xml file, where camera and lens data is located even when it arrives under non-standard tag names or is embedded inconsistently. Focal length, sensor make and model, frame rate, and position and orientation can be mapped to whatever tag names a production actually uses, and PFTrack reads them as if they were native, including position and orientation from drones and frame rate from movie clips. Does PFTrack read EXIF and XMP metadata from smartphones and DSLRs? Yes. PFTrack reads EXIF metadata from any digital stills camera that writes it, including DSLRs, mirrorless cameras, smartphones and tablets, through the Photo Input node. XMP data, including GPS coordinates and orientation, is also read, particularly useful for photogrammetry workflows where geotagged images need to align with real-world coordinates. Conclusion If you take one thing from this article, take this: in a production landscape where every camera writes metadata and every shoot mixes capture sources, the matchmove tool's architectural treatment of metadata is no longer a secondary consideration. It's the foundation that determines whether your multi-shot reconstruction holds up. PFTrack's metadata pipeline was designed for that reality, and refined across the years that the reality was emerging. The Metadata Parameters Window, the Connect toggle, the Dynamic Metadata Viewer and the federated sensor database are the surfaces an artist works with. The multi-shot scene architecture is the structural reason those surfaces produce coherent results across mixed sources. For more on specific topics raised in this article, see: Sensor Size: A Practical Guide for Camera Tracking Precision in a Click: PFTrack Camera Sensor Database Why You Need to Know About Distortion Calibration Understanding Lenses & Camera Tracking The How and Why of Feature Tracking in PFTrack For complete reference on the underlying nodes, the Clip Input and Photo Input documentation is the place to start, with the Camera Solver and Customizing PFTrack sections for deeper detail on the solver pipeline and custom XML formats. Want to test PFTrack's metadata workflow against your own footage, or discuss multi-source production pipelines with other working matchmovers? Join our support community. Try PFTrack Solo Free Try PFTrack Solo free for 7 days, with full export functionality, enough time to load your own multi-source footage and see the Metadata Parameters Window, Connect toggle and multi-shot scene workflow in your own pipeline. About the Author Adam Hawkes is a PFTrack Product Specialist with over 20 years of hands-on experience in the visual effects industry. Trained in film handling and camera operation, Adam has spent his career working inside professional VFX pipelines, with IMDb credits spanning more than 60 productions in compositing, digital artistry, and visual effects, including work on landmark titles such as Avatar, Sherlock Holmes, Casino Royale, and V for Vendetta during his time at Framestore. That production experience gives him a practical understanding of how camera tracking, matchmoving, and 3D scene reconstruction fit into real VFX workflows, knowledge he now brings to PFTrack's tools for camera tracking, matchmove, and photogrammetry.

Overview The new Hero Cloud node in PFTrack Version 26.05.19 generates high-quality dense point clouds from a single tracked camera move, with no LiDAR or additional capture hardware required. Build rich 3D environments directly from your existing camera solves, then export to your 3D package of choice or train Gaussian Splats in Postshot. Get Started Follow along with these tutorials using either your own footage or our example plate. Already using PFTrack? Hero Cloud ships in the latest PFTrack build, download from your account and the new node will appear in the Geometry category. New to PFTrack? Try PFTrack Solo free for 7 days, with full export functionality, enough time to take a real plate from track through Hero Cloud and into Postshot, USD, or your DCC of choice. Start Free Trial Want to follow along with the exact tutorial workflow? Download the example footage used in these tutorials and try the same workflow shown in the videos. Download Example Footage Using Hero Cloud What You’ll Learn Generate dense point clouds from any solved camera Control depth range and frame sampling Optimise cloud density for your workflow Clean up and refine your point cloud data Workflow Summary Start with your solved camera — Hero Cloud works with any camera track and solve in PFTrack. Complete your camera tracking workflow as normal before adding the Hero Cloud node to your tree. Add the Hero Cloud node — Simply add the Hero Cloud node to your node tree. Define your depth range — Use the frustum visualisation in the Cinema view to set your near and far clipping planes. Focus on your area of interest by adjusting the far clipping plane, distant points often lack the detail needed for accurate depth reconstruction. Tightening the frustum to your hero elements ensures computational resources are focused where they matter most. The frustum can be animated throughout your shot for dynamic depth control as your subject or camera moves. Adjust frame density — Control how many frames are used to generate depth maps using the Frame Density slider. The Shot Coverage graph updates in real-time, providing a dynamic estimate of depth map coverage for your chosen frame count. Set cloud density — Balance detail against performance by adjusting the Hero Cloud density. Complex scenes may benefit from lower point counts to maintain viewport responsiveness in your pipeline later on. Build your Hero Cloud — Click Build to automatically generate your dense point cloud. Once processing completes, the actual coverage line appears in the Shot Coverage graph, showing real-world depth data distribution. Refine with point cloud editing tools — Edit your dense point cloud using PFTrack’s comprehensive toolkit: Paint Tool: directly paint to remove unwanted points in the Cinema or 3D Viewer Selection Tools: use lasso or box selection for precise control Select Colours: key specific colour ranges to isolate and delete points by hue Direct Manipulation: work in either Cinema or 3D Viewer for maximum flexibility Exporting to USD for 3D Packages What You’ll Learn Export Hero Cloud data via USD Import point clouds into Blender Assign colours for render-ready assets Export Workflow Add a Scene Export node — Connect a Scene Export node to your Hero Cloud node in the tree. Configure USD export — Select USD as your export format. USD (Universal Scene Description) provides compatibility with all major 3D packages including Maya, Houdini, Blender, and Unreal Engine. Export your scene — Set your export path and click Export. Your solved camera, track points, and dense Hero Cloud will be packaged together in a single USD file. Importing to Blender Import USD file — In Blender, use File > Import > Universal Scene Description (.usd/.usdc) to bring in your PFTrack scene. Locate your point cloud — The Hero Cloud will import as a point cloud object in your scene hierarchy, maintaining world-space positioning relative to your camera. Assign vertex colours — The point cloud retains colour information from your original footage. In Blender’s Shading workspace, connect the Color Attribute node to your material to display photorealistic vertex colours from your capture. Use Cases Pre-light your shot against the actual scene geometry, rather than blocking against approximations Environmental blocking for set extensions and CG integration Spatial reference for matte painting and final composition Collision geometry generation for simulation and animation passes Exporting to Postshot for Gaussian Splats What You’ll Learn Export optimised data for Gaussian Splat training Import into Jawset Postshot Train production-ready Gaussian Splats Postshot Export Workflow Select Postshot export — In your Scene Export node, choose the Jawset Postshot export option. This format is optimised specifically for Gaussian Splat training workflows. Configure export settings — Set your export path and any additional parameters. The export includes your solved camera, Hero Cloud point data, and frame metadata required for training. Export your data — Click Export to generate your Postshot-compatible dataset. Training in Postshot Import to Postshot — Launch Postshot and import your PFTrack export. The software will automatically recognise the camera solve and point cloud data. Configure training parameters — Set your Gaussian Splat training parameters based on scene complexity and desired output quality. The dense Hero Cloud provides strong initialisation data, helping training converge faster than from sparse point sets alone. Train your Gaussian Splat — Begin training. The rich point cloud data from Hero Cloud improves convergence speed compared to training from sparse initialisations alone. Render and export — Once training completes, render your Gaussian Splat for real-time playback, interactive viewing, or export to game engines and real-time platforms. Why Hero Cloud for Gaussian Splats? Most Gaussian Splat workflows today require either dedicated photo sets or LiDAR scans to initialise. Hero Cloud generates that initialisation data from production footage you’ve already shot. The dense point cloud provides: Strong initialisation data, helping training converge faster than from sparse point sets alone Improved spatial accuracy in areas with limited visual features Consistent coverage across your entire frustum No additional capture requirements beyond your existing footage Key Benefits Through-the-lens generation Hero Cloud generates dense 3D data from your camera’s viewpoint — the same perspective you’re already working with. No additional hardware, multi-camera rigs, or LiDAR scanning required. Real-time feedback The Shot Coverage graph updates dynamically as you adjust parameters, giving you instant feedback on depth map distribution and frame sampling efficiency. Flexible export pipeline Whether you’re building CG layouts in traditional 3D packages or training Gaussian Splats, Hero Cloud integrates seamlessly into your existing pipeline. Production-ready results From blocking and layout to final Gaussian Splat renders, Hero Cloud delivers professional-quality point clouds optimised for real-world production workflows. Try PFTrack Solo Free Try PFTrack Solo free for 7 days, with full export functionality, enough time to take a real plate from track through Hero Cloud and into Postshot, USD, or your DCC of choice.

In this tutorial, I will guide you through the process of creating a project, importing a clip, performing tracking, solving and orienting your camera, and exporting your 3D scene. Link to the footage: The rock of dunamase by Jay's Photography Step 01 - Create a Project To begin, click on 'Create New Project'. Enter a project name and set a project path. Once done, click 'Create'. Step 02 - Importing Your Clip Next, double-click the 'Clip Input' and click the media import button. Browse to your clip and click open. Click on the Undistort tab and set the mode to Automatic. Step 03 - Track Your Clip The node tree is a unique feature of PFTrack in matchmoving. It sets PFTrack apart as an industry leader. To create a tree quickly, double-click on the nodes you want to use. For this step, click on the 'Tracking' tab and double-click the 'Auto Track' node. With the Auto Track parameters open at the bottom, click 'Start Tracking'. Step 04 - Solve Your Camera Enter the node panel and click on the 'Solving' tab. Double-click the camera solver and then select 'Solve All'. Press play to review the result. Step 05 - Orient the Camera Enter the node panel and click the 'Utilities' tab. Select a point on the ground near the castle door and click 'Set Origin'. Use the 'Edit Mode' and the 'Rotation' controls to align the virtual horizon with the real horizon. Click and drag the scrub bar for a better view. Using the size of the doorway as a reference, scale the ground plane to the correct size. Each ground plane square represents 1m². The approximate width of the doorway is 1m. Controls - Cinema Pan viewer: 2nd mouse button Zoom viewer: middle mouse button Now press play to view the results. Use the maximise option on the viewer to see your 3D scene clearly. Adjust the controls for a better perspective. Controls - 3D Viewer Rotate viewer: 1st mouse button Pan viewer: 2nd mouse button Zoom viewer: middle mouse button Step 06 - Exporting Your Scene Finally, add a 'Scene Export' node. Choose a format from the available options, set your export path and file name, and click export to deliver your 3D scene. If you are a discovery mode user, you will not be able to complete this step until you subscribe. Additional Resources For further learning, head back to PFTrack Tutorials. You can also explore our Learning Articles for a deeper understanding of camera tracking and matchmoving concepts. Alternatively, check out our extensive Resources for valuable presets, Python scripts, and macros. In conclusion, mastering 3D camera tracking with PFTrack opens up new possibilities in visual effects and forensic analysis. With practice, you will enhance your skills and create stunning visualizations.

Learn how to refine your solved camera using these essential techniques. Learn how to manage moving objects using masks, calibrate the camera and resolve tracking errors in the camera solver. Tracking and solving issues video overview 0:00 - Brief overview of what we will be covering in this video 0:28 - Analysing the clip and learning the camera motion 1:07 - Performing the initial track & solve of the clip 1:42 - Checking the results and discussing the issues 4:03 - Using masking to occlude moving objects from the camera solver 7:29 - Calibrating the virtual camera and re-solving the clip 11:04 - Using the tools in the camera solver to remove errors in the solve 17:00 - Re-fining the camera solve with all the fixes made so far 17:31 - A look at the updated solve and video conclusion Before you begin, download the latest version of PFTrack and the media files linked below. Downloads Download the assets used in this video Links: Head back to PFTrack Tutorials. Or check out our Learning Articles for a deeper look at camera tracking and matchmoving concepts. Alternatively, explore our extensive Resources for valuable presets, Python scripts, and macros.

In this video, we'll cover how to reorient your virtual camera, correctly scale your 3D scene, and export your completed 3D scene. Video Overview 0:00 - Overview of what is covered in the video 0:38 - Adding the Orient Camera node 1:24 - The Orient Camera node 1:49 - Setting the ground height 2:19 - Rotating the axis 3:42 - Playing the aligned clip 3:55 - Setting the scene scale 5:06 - Using the ground plane 5:32 - Adding the Scene Export node 6:40 - Scene Export brief overview 7:20 - Adjusting the export 7:50 - Export destination 8:48 - Exporting your 3D scene 8:58 - Outro Before you begin, download the latest version of PFTrack and the media files linked below. Downloads Download the assets used in this video Links: Head back to PFTrack Tutorials. Or check out our Learning Articles for a deeper look at camera tracking and matchmoving concepts. Alternatively, explore our extensive Resources for valuable presets, Python scripts, and macros.