Which Multicamera Take Identifiers Are Shared and Which Stay Separate
A take has a one-to-many relationship with cameras: one take can contain several camera records, but belonging to the same take does not mean every camera field should be merged. Scene, shot, and take identify the shared take context, while values such as reel, clip identifier, and sound roll are stored on the individual camera records.
Multicamera records share the identity framework of one take, while each camera’s reel, clip identifier, and sound roll still need to be verified separately.
How camera letters are assigned
When a camera is added, its camera identifier is chosen from the available letters in order. The system takes the earliest currently unused letter, and once the whole letter set is occupied no new letter is assigned: the add action is refused with a short message rather than falling back to a default camera identifier. This rule assigns camera identity; it does not merge media fields from different cameras.
Several cameras inside one take can therefore share the scene, shot, and take context while retaining separate camera identifiers. Scene, Shot, and Take Numbers Explained covers those record layers; the boundary here is to keep them distinct from camera-level fields. During receiving, the take’s identity and the camera’s identity should be read together.
Which values carry forward when a camera is added
When the add-camera control in the take create and edit forms is used, the new camera carries forward reel number, clip identifier, frame rate, shutter, white balance, and sound-roll number from the previous camera. Lens, aperture, ISO, focus distance, composition fields, and VFX do not carry forward, while camera model, resolution, aspect ratio, and LUT start from empty defaults. The new-camera button in the script page’s bottom toolbar follows a different rule: reel and clip return to their starting values, while ISO, camera model and LUT carry forward. Carry-forward behavior supplies initial values for the new camera form; it does not turn two camera records into one.
Which Camera Parameters Carry Forward When You Add a Camera gives the fuller field-by-field treatment of that behavior. The identity boundary to keep here is that a value remains a field of the new camera after it is saved even if its initial value came from another camera. The receiver should not merge two cameras’ reels or clip identifiers merely because their starting values happened to match.
“Carried forward as an initial value” and “shared as one field in delivery” are different statements; multicamera handoffs still expose these values by camera record.
Why composition fields do not follow one universal carry-forward rule
Composition-related fields can enter through two paths, and the two paths do not treat them the same way. One path clears shot size, camera angle, movement and focus distance. In the other path, whether the context is still the same shot decides exactly one thing: whether focus distance carries over from the previous camera, because changing shot clears it. The accurate external boundary is that composition carry-forward depends on how the camera context was added or inherited.
It would therefore be incorrect to state a single rule saying that a new camera always keeps the previous composition or always clears it. The user should inspect the current fields after adding the camera and confirm them against the actual setup. This path difference does not change the fact that reel, clip identifier, and sound roll remain separately stored camera-level fields.
Why the three handoff views expand multicamera records differently
ALE and CSV emit rows per camera, so one multicamera take appears as separate camera rows in those machine-readable files. PDF uses one row per take and fills camera-related columns from the camera whose letter sorts earliest. These expansion differences are exactly what the article Why the Same Takes Do Not Line Up Row-for-Row Across Handoff Files is about.
There is another receiving boundary: a camera that was turned off on set is not filtered out by these selection rules. The camera whose letter sorts earliest in the PDF can therefore be a camera that is no longer active. The PDF body has no camera-number column, so camera identity there can only be read from the leading letter of the camera roll value; ALE and CSV have their own camera column. The receiver should verify identity that way rather than reading “earliest letter” as “currently active camera.”
Why deleting a camera should be kept separate from take identity
The delete-camera entry point is offered only when a take contains more than one camera, so that entry point cannot be used to reduce the take to zero cameras. That is the confirmed boundary of the control and should not be expanded into a claim that deleting one camera deletes the take record itself. A take record and a camera record remain separate layers and should be treated that way during receiving.
For final verification, first use scene, shot, and take to identify the take, then use the camera identifier to identify the camera, and then verify reel, clip identifier, and sound roll separately. Values that originated through carry-forward should not be merged merely because the cameras belong to the same take. Multicamera identity means a shared take context with preserved camera-level field boundaries.
FAQ
Should reel values from several cameras in the same take be merged?
No. Reel, clip identifier, and sound roll are stored on camera records and should be verified together with each camera identifier.
Which fields carry forward when another camera is added?
When the add-camera control in the take form is used, reel number, clip identifier, frame rate, shutter, white balance, and sound-roll number carry forward; lens, aperture, ISO, focus distance, composition fields, and VFX do not under this rule. Camera model, resolution, aspect ratio, and LUT begin from empty defaults.
Does PDF expand every camera in the same take?
No, PDF uses one row per take and fills camera-related columns from the camera whose letter sorts earliest. ALE and CSV emit rows per camera instead.
Is a camera that was turned off automatically excluded from the handoff selection?
No filtering occurs merely because the camera was turned off, so the earliest camera letter can belong to an inactive camera. The receiver should verify that row’s camera identity against the on-set record.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.