Stand-In Trimmer & Cropper
Trim and crop your driving video before Stand-In touches it
- images
- processed_images
- width
- height
- frame_count
Don't let the category fool you - this one has nothing to do with faces or identity. Its display name gives it away better than its class name: "Stand-In Trimmer & Cropper." It's plain video-frame housekeeping, bundled into this pack because Stand-In's video path needs it done consistently before anything identity-related happens.
How it works
Hand it your video frames (from a video loader node) and it trims and crops them down to sane dimensions, handing back the adjusted frames plus three numbers describing what it just did: width, height, and frame count. That's it - no face detection, no YOLO model, nothing else going on.
The reason those three numbers matter more than they look: Wan's video pipeline is picky about frame counts and resolutions matching what you actually feed the sampler. Typing dimensions in by hand and hoping they match your real, post-crop frames is a common way a Wan generation comes back mismatched or malformed. Wiring this node's width, height, and frame_count outputs straight into your Empty Latent / sampler setup means you're always sampling at the dimensions your actual frames are in, not the dimensions you assumed they'd still be after cropping.
The inputs and outputs that matter
There's exactly one input - images, your raw video frames - and four outputs: processed_images (the trimmed/cropped frames, which carry on into the rest of the Stand-In chain, e.g. VideoInputPreprocessor), and width / height / frame_count, which you route into whatever downstream node needs to know the actual dimensions it's working with.
How to install it
cd ComfyUI/custom_nodes
git clone https://github.com/WeChatCV/Stand-In_Preprocessor_ComfyUI.git
cd Stand-In_Preprocessor_ComfyUI
pip install -r requirements.txt
Restart ComfyUI afterward, or search "Stand-In Official Preprocessor ComfyUI Nodes" in ComfyUI Manager.
Common issues & troubleshooting
There are no exposed parameters here, which cuts down on what can actually go wrong at this node specifically. If the numbers it hands back look wrong, the cause is almost always somewhere else:
Output dimensions look off. Check your source video's own resolution and aspect ratio first - this node crops what it's given, it doesn't reframe or upscale.
Your sampler still errors on dimension mismatch even though this node ran fine. Make sure you actually wired width, height, and frame_count into the sampler or empty-latent node rather than leaving stale manually-typed values in place. It's an easy thing to add this node to an existing graph and forget to reconnect the numbers it now provides.
You're only using this for the numbers, not the frames. That's a legitimate way to use it - run your original frames through for the width/height/frame_count outputs, then feed your own frames (not processed_images) into the rest of the pipeline if you don't actually want the trim/crop applied. Just be aware the numbers describe the processed output, so if you skip using processed_images downstream, double-check your untouched frames still match those dimensions.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| processed_images | IMAGE | — |
| width | INT | — |
| height | INT | — |
| frame_count | INT | — |