EA Trim Window
Frame-perfect windows for training data, by the numbers
- images
- images
- first_frame
- last_frame
- frame_count
- start_frame
- end_frame
- total_frames
When you're curating training data, "roughly this part of the video" isn't good enough. You need frame 120 through frame 175, exactly - a fixed-size window at an exact start, because your dataloader expects consistent clip lengths and your captions reference specific moments. EA Trim Window is that surgical tool: give it a start frame and a frame count, and it extracts precisely that window, reporting back the exact bounds it used.
It's the pack's "precise" trim, aimed squarely at dataset curation - the source docstring says as much - and it sits next to the simpler EA Trim Frames (head/tail removal) and EA Auto Trim (automatic detection) as the manual, deterministic option.
What you set
start_frame- where the window begins (0-indexed).frame_count- how many frames the window spans. Default is 56, which is no accident: that's a common short-video training clip length, and it's the number you'll keep for many Wan 2.2 training setups.clamp_to_bounds(default on) - the behavior switch. On, the node quietly clamps your request to what's available (start within bounds, frame count limited by what remains). Off, it raises aValueErrorinstead - strict mode, for when you'd rather fail loudly than silently get a shorter clip than your dataloader expects.
The outputs
The window itself as images, plus the metadata to trust it:
first_frame/last_frame- previews of the window's endpoints, so you can confirm the cut lands where you meant.frame_count- the actual number of frames extracted (may differ from your request if clamping kicked in).start_frame,end_frame(inclusive), andtotal_frames- the exact bounds used and the input's full length. Wire these to a text display and you've got a self-documenting data-prep step: no guessing what the node actually did.
Why the exact-bounds outputs matter
This is the node where the reporting is the feature. Training runs are only reproducible if every clip is accounted for, and having start_frame/end_frame/total_frames as data lets you log exactly what went into the dataset - including the cases where clamping trimmed your window shorter than requested, which is precisely the silent failure that wrecks a training run's clip-length expectations.
Install
Part of comfyui-ea-nodes: ComfyUI Manager → search comfyui-ea-nodes, or git clone https://github.com/ExoticArts/comfyui-ea-nodes into custom_nodes/, restart, hard-refresh. No extra Python dependencies. Feed it frames from EA Video Load, and save the window with EA Video Save (Idempotent) for a tidy data-prep loop.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| images | IMAGE | — | |
| start_frame | INT | 00–10000 | — |
| frame_count | INT | 561–1000 | — |
| clamp_to_boundsopt | BOOLEAN | true | — |
Outputs (7)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| first_frame | IMAGE | — |
| last_frame | IMAGE | — |
| frame_count | INT | — |
| start_frame | INT | — |
| end_frame | INT | — |
| total_frames | INT | — |