AnyAnglePoseReadT8

Here's the thing that confuses everyone who stumbles onto this node in the list: it has an input, no outputs, and it's flagged as an output node. It is not a broken node. AnyAnglePoseReadT8 is a readout - you hand it a POSE_KEYPOINT and it tells you what's in it, as a rendered skeleton preview plus structured data about each detected person.

That's genuinely useful in 2026, because posing stopped being a ControlNet job. The pose-and-camera slice of the old stack moved to reference-driven LoRAs and edit-model conditioning, and the skeleton is now something you feed an encoder rather than something you schedule strength on. Which means when the pose half of your scene looks wrong, you no longer have a checkpoint to blame - you have to know what the detector actually handed over.

How it works

Give it keypoints and it reads the first frame only (trailing frames in the batch are ignored - the pack's own audit confirms this was tested deliberately). It then renders every person in that frame onto one shared black canvas sized to the frame's own canvas_width / canvas_height, using standard OpenPose-style limb colouring, and computes per-person metadata: bounding box, minimum joint confidence, which joints cleared the visibility threshold, and flags for partial detection, whether the body is complete enough to attempt 3D, and normalised coordinates alongside the pixel ones. The frame is also hashed into a signature, which is what the studio compares later to decide whether your keypoints are still the ones it applied. The PNG lands in the pack's asset store under ComfyUI/input/anyangle_studio/.

Where you'll actually meet it: mostly not by dragging it onto the canvas. When you wire a POSE_KEYPOINT output into the studio's pose_keypoints input and click the studio's read-upstream action, the frontend quietly queues your upstream chain plus an AnyAnglePoseReadT8 node as a throwaway API prompt, then reads the result back to populate its person picker. Same code path, same numbers. If the upstream didn't produce usable pose data you'll get "上游没有输出可用的 POSE_KEYPOINT 数据" - which is the answer to the classic "why does my group photo show zero people" question, minus the guesswork.

The one input, and its contract

keypoints is the only input, type POSE_KEYPOINT. What it will and won't accept, from the shipped code:

• A frame is a dict with a people list plus integer canvas_width and canvas_height. Missing dimensions are an error here - the studio's OpenPose JSON import can fall back to the image size, this node can't.
• Each person's pose_keypoints_2d must be 18 or 25 joints of finite (x, y, score) triples. Anything else is rejected.
• Joints below 0.3 confidence aren't drawn or exported as visible. Nothing is invented: no detected people produces a valid black image rather than a fake skeleton.
• Coordinates normalised to 0–1 are detected and scaled to the canvas for you, so a detector that emits [0,1] values won't silently pile every joint into the top-left corner.

Outputs: there aren't any

Not a typo - it exists to be executed, not wired. The skeleton preview and the person metadata come back as node UI data, and the node is marked dev-only, so you won't find it cluttering normal node search. If you're scripting, that's the point: post a minimal prompt with your detector plus this node and read anyangle_pose_people out of the history entry. If you were expecting a downstream pose image to feed something else, use the studio node's guide output instead - that's the port that actually produces an IMAGE.

Install

Same pack as everything else here - ComfyUI Manager search for Comfyui-Qwen-Image-2.1-MultiAngle-T8, or:

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/Comfyui-Qwen-Image-2.1-MultiAngle-T8.git ComfyUI-AnyAngle-Studio-T8
cd ComfyUI-AnyAngle-Studio-T8
python -m pip install -r requirements.txt
python install_assets.py

Nothing model-side is needed for this node specifically: it renders from keypoints and runs no inference, so no DWPose ONNX weights, no LoRA, no reconstruction pack. Those downloads belong to the studio's own extract-from-photo actions.

When it fights you

"Choose OpenPose JSON or POSE_KEYPOINT frames" means whatever you wired isn't a pose frame - most often a converted-widget string or an image, not a detector output. "Invalid OpenPose canvas dimensions" means the frames arrived without usable canvas_width / canvas_height. And if you're feeding a multi-frame batch expecting one readout per frame: you get frame one. That's the contract, not a bug, and knowing it saves you a long afternoon of blaming your pose detector.