Image Review Filter

Everyone who generates a hundred character shots ends up doing the same thing: scrolling a folder at 2am, squinting at hands. Image Review Filter [Eclipse] automates the sorting half of that. It takes an image batch and one JSON verdict per image, and splits them into a kept list and a rejected list. The judgement comes from a vision model - this node does no inference. It's a dispatcher with opinions about what counts as a valid verdict.

The report format

One JSON object per image, as a string, in the same order as the images:

{"verdict":"reject","reasons":["A clearly visible third arm extends from the left shoulder."]}

Verdicts are exact lowercase pass, review or reject. pass keeps the image and an empty reasons list is fine. review also keeps it, flagged for your eyes. reject only rejects when the whole report is valid and at least one reason is non-blank.

Everything else degrades safely: invalid JSON, unknown verdicts, duplicate fields, missing fields, incomplete reasons - all become review with an explanation of what went wrong. Prose wrapped around the JSON is rejected; an enclosing code fence is tolerated. That's a deliberate design choice, and the right one: the failure mode of this node is "a human looks at it", never "a good image got deleted".

Alignment is strict. Eight images need eight report strings, not one string containing an array. Counts that don't match raise an error instead of guessing, because a guessed alignment would silently mislabel your rejects.

Wiring it

Both inputs are required: images (a batch or list, in report order) and reports. In practice images comes from the image output of SmartLLM or another reporting node and reports from that same node's text output - use the outputs from the same execution, or the pairing is meaningless.

Three outputs:

• kept - Python list of images, pass and review together.
• rejected - only the valid rejects.
• report - a numbered human-readable summary: totals, each original one-based input number, verdict, reasons, and which preview slot it landed in. Send it to Show Any.

The image outputs are lists of single-frame [1,H,W,C] tensors. Order, pixels, dtype and device are preserved; there's no resizing, no overlay, no saving, no placeholder. Feed them to Preview Image (DOM), which handles empty lists gracefully. If you want them on disk, that's a separate save node downstream.

One caveat about the numbering in report: numbers refer to images entering the filter, in flattened order. If an upstream selector already trimmed the batch, they're selected-image numbers, not folder indices or filenames.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/r-vage/ComfyUI_Eclipse
pip install -r ComfyUI_Eclipse/requirements.txt

Or ComfyUI Manager, search ComfyUI_Eclipse, restart. It appears under 🌒 Eclipse/ Image/Batch Operations.

You also need the judging side: ComfyUI_SmartLLM and an Ollama vision model registered there. Eclipse explicitly doesn't manage that runtime. The bundled example workflow runs a Qwen3-class abliterated vision model in Direct Chat with an editable system prompt and a 1024-token output cap, asking for one short JSON object per image.

Honest limits

Vision models are mediocre at exactly the task you're giving them. Multi-subject attribution is the documented weak spot for every VLM in this class - they mix up who's wearing what, and they hallucinate defects on unusual poses, heavy occlusion or anything outside their training distribution. So the sane configuration is a system prompt that checks specific things (extra heads, duplicate bodies, fused or disconnected limbs, malformed hands) explicitly says cropping, occlusion and unusual poses are not defects, and a node config that keeps review in the kept pile where you can see it. Model judgement is not a correctness guarantee, and the workflow ships no deletion, no saving and no regeneration - it exists so you can inspect the judgements, not so you can skip looking.