DA3_ParseCameraPose

This is a small plumbing node that unpacks the camera data Depth Anything 3 predicts. The main depth node hands you camera pose and lens info as extrinsics_json and intrinsics_json strings - dense, not human-readable, not something you can wire into a math node. DA3_ParseCameraPose takes those two strings and breaks them out into individual numbers you can actually use: position, rotation, and focal length as separate float outputs.

Why you'd need it

DA3 estimates where the camera was and what lens it used. That data comes out of DepthAnything_V3 (and the multi-view node) as JSON strings, which is fine for passing between 3D nodes but useless if you want to see the values, feed one into another parameter, or drive a downstream node off the predicted focal length. This node is the decoder. It's the inverse, roughly, of DA3_CreateCameraParams: that one assembles a camera from numbers, this one extracts numbers from a predicted camera.

Inputs and outputs

Two required inputs:

• extrinsics_json - the camera pose string (position + rotation) from the depth node's extrinsics output.
• intrinsics_json - the lens/intrinsics string.

One optional input:

• batch_index (default 0) - which frame to read when you've got a batch. If you ran a video or a multi-view batch, each frame has its own camera; this picks the one you want. Leave it at 0 for a single image.

The outputs are the camera broken into eight floats: cam_x, cam_y, cam_z (position), rot_x, rot_y, rot_z (rotation in degrees), and fx, fy (the focal lengths in pixels). Each is a plain FLOAT you can route into any node that takes a number.

What people actually do with it

A few genuinely useful patterns. Round-tripping a camera: parse the predicted pose, tweak one value (nudge cam_z back a bit, say), and rebuild it with DA3_CreateCameraParams to re-render depth from a slightly moved camera. Inspection: you just want to know what focal length DA3 thinks your shot used - pull fx/fy and read them off. Driving other nodes: feed the predicted position or FOV into a 3D or animation node so it matches the reconstruction.

It's not a node most workflows need. If you're doing straightforward depth-to-ControlNet or photo-to-point-cloud, the camera data flows between nodes as strings and you never have to look inside it. This is for when you specifically want the numbers out.

Common issues

If the outputs look wrong or zeroed, the usual cause is passing the wrong string into the wrong slot - extrinsics_json and intrinsics_json are not interchangeable, so make sure pose goes to the pose input and lens to the lens input. If you're working with a video or multi-view batch and the numbers seem off for the frame you care about, check batch_index - you're probably reading frame 0 when you wanted a later one. And remember these are predicted values: they're the model's best estimate, not ground truth, so treat them as a good approximation rather than surveyed measurements.