Evaluate Image Candidates

Here's where the mock evaluation's blind hash-scoring gets replaced by something that actually reads the pixels. AFS_EvaluateImageCandidates sends each candidate on-model image to OpenAI's gpt-5.5 along with the product specification, and gets back a five-dimension quality verdict plus a decision. It's the "garment-fidelity QA judge" of the pack, and it is genuinely the stage where you learn whether a candidate is usable.

The mechanism is per-candidate and spec-aware. For every candidate in the candidate_set, the node base64-encodes that one frame and calls the Responses API with a strict JSON schema: garment_fidelity, anatomy_quality, model_identity, aesthetic_quality, technical_image_quality, a concrete issues list, and a decision (pass / manual_review / reject). The prompt is the important part - it hands the model the full product specification, including the must_preserve and forbidden_changes lists from analysis, and tells it to deduct for every violated item. So the judge isn't grading on vibes; it's checking "six buttons, left chest logo, do not mirror logos" against the render, point by point. That's the whole philosophy of the pack in one call: product fidelity first, everything else second.

Inputs, in order of how often you'll touch them:

• candidate_images - the batch from Virtual Try-On Candidates (Mock).
• candidate_set - its metadata. The node iterates the set's candidates and indexes into the batch per record, so these two must come from the same run.
• product_specification - required here, unlike the mock version, and it's the crux: without the spec there's nothing to judge against, and the node raises if you omit it.
• provider (COMBO, default openai) - same escape hatch as the analysis node. Flip to mock to rehearse the graph free.

Outputs: evaluations (an AFS_EVALUATION_SET) and evaluation_json. The evaluation set is the exact same type the mock produces - identical fields, including the weighted final_score (45% fidelity / 20% anatomy / 15% identity / 10% aesthetic / 10% technical) - so downstream ranking and export don't care which judge you used. The JSON adds evaluator: "openai:gpt-5.5" and an estimated_cost_usd for the whole batch.

Now the honest parts. First, cost: this is per-candidate, so four candidates means four gpt-5.5 calls, and each charges against the per-run ceiling (AIFS_MAX_RUN_COST_USD, default $10.00). The README's live slice pairs this node with mock candidate generation, which is a slightly odd combination - you're paying a real judge to critique collage-placeholder images. It's fine for testing the QA path end to end, but don't read the scores as predictions about how a real try-on will fare. Second, trust: this is an API-wrapper node - it uploads each candidate image to a server you don't control. The pack reads its key from the process environment and never writes it into workflows, which is the right pattern; just keep that boundary in mind on a brand-new pack with no community track record.

To run it you need the pack installed (pip install -r requirements.txt in the ComfyUI Python environment), OPENAI_API_KEY in the ComfyUI launch environment, and a restart. Missing key → a ConfigurationError at execution, not a confusing mid-call failure.

Where people get burned: wiring the spec from the wrong upstream (the mock spec from AFS_AnalyzeProductMock will work, but it's keyword-derived, so the judge will be grading against what your text said, not what the garment looks like). And don't swap the candidate set mid-graph - mismatched run IDs surface as errors in the ranker right after this node. Keep the plumbing honest and the judge will do its job.