DiffusionGemma Advertisement Reference Asset Prep & Hash

DiffusionGemmaAdvertisementReferenceAssetPrep is the node that turns three ordinary image loads into the hashed, budgeted reference authorities the whole advertisement stack swears by. You plug in a performer hero shot, a same-performer contact sheet, and an independent product shot; it downscales them to fit a governed pixel budget, computes deterministic SHA-256 hashes for each, and hands the stack clean, verifiable references plus a padded batch for the DiffusionGemma Director's visual analysis. The key design choice is that you never type a hash - the images are the input, and the hashes are derived from them, which is what makes the lock genuinely unforgeable.

Here's how the pixel budgeting works, because it's the part people find unintuitive. The stack uses governed reference sizes relative to a generation frame (generation_width 480 × generation_height 864 by default, matching the 9:16 ad master). performer_area_ratio (default 1.0) is the combined pixel-area budget for Pictures 1 and 2 measured against one generation frame, and performer_hero_share (default 0.6) splits that pool: the hero gets 60%, the contact sheet gets the rest. product_area_ratio (default 0.5) is a separate budget for the product picture that is never borrowed by performer assets. It's all downscale-only - nothing upscales, so small reference images stay small rather than getting smoothed into mush.

The role discipline matters more than the numbers. Picture 1 is the performer identity hero: face, hair, body, wardrobe, composition. Picture 2 is the same-performer supplemental sheet - more angles of the same person, never product authority. Picture 3 is the independent product/package authority. The outputs mirror that split: performer_hero_image, performer_sheet_image, product_sheet_image, their three *_sha256 hashes, plus director_reference_batch (the padded batch the LLM Director analyzes) and asset_manifest_json. Wire the prepared images to H3's native reference sockets in this same order - the reference contract downstream expects exactly this Picture 1/2/3 layout, and a fourth "relay" picture is supplied separately by the retained-tail system, not here.

The output hashes feed DiffusionGemmaAdvertisementMasterContract, which cross-checks them against the project manifest, so every later stage can verify it's looking at the same three immutable references you approved. That hash chain is what makes "the product changed between lane one and lane three" impossible without it being caught.

Where beginners slip: feeding a product image into a performer slot because it looks good, or a single combined performer+product sheet into one input. The pack is explicit - performer and product references must stay separate, or identity bleed starts and downstream role validation may fail closed. Also, tooltips make the roles obvious: Picture 2 "never carries product authority," Picture 3 is "independent product/package." Respect them.

Install is the pack install (ComfyUI Manager search "DiffusionGemma Prompt Builder", or clone into custom_nodes). This node is image math, not model loading - cheap to run. The ad workflow it feeds, though, is the heavy MiniMax H3 + Music 3 stack on ComfyUI 0.33.1+, and the actual GPU cost happens downstream. Start by getting this node's hashes and prepared images right; everything after depends on them.