Imprint - Label Image

Here's the problem ImprintAI is solving: Imprint - Log Provenance gives you a blockchain transaction id, but a txid on its own does nothing for the image sitting on your disk. Anyone who gets a copy of that PNG needs the reference to travel with the file - invisibly, so it doesn't ruin the picture. Imprint - Label Image is the node that embeds the confirmed txid straight into the image tensor as a steganographic label. It's the fully local path through the pack: no API key required, no image leaves your machine, and its output is a normal IMAGE you can save with ComfyUI's native Save Image node.

How it works

Wire the txid and anchor_ready outputs from ImprintLog into this node's matching inputs, and connect your image. The label only embeds if anchor_ready is true - the node refuses to stamp anything that isn't a real, confirmed blockchain anchor, which is a deliberate design choice so you can't accidentally label an image with a job id or a failed anchor. If the gate is off, you get your original image back unchanged and labelled=false.

Two embedding methods, and the choice is the whole article:

• imprint-stego-v1 (default) is RGB least-significant-bit steganography. It writes a small PROV header plus the 64-hex txid into the low bits of pixel channels, repeated a few times based on the redundancy dropdown (low/medium/high). Invisible and lossless for a PNG saved without re-encoding - but that's the ceiling. Anything that re-encodes the image, which is basically every social platform download, strips it. This is an "exact-file authenticity" label, nothing more.
• imprint-stego-v3 is the robust one: a transform-domain watermark (the source calls it IMV3) spread across a 64×64 grid with redundant voting and CRC validation. It's built to survive common JPEG/WebP recompression and moderate resizing - the thing that kills v1 - at the cost of needing at least 512×512 pixels. Two honest caveats baked in: the redundancy dropdown is ignored for v3 (its redundancy is fixed), and a v3-labelled copy can't claim exact pixel equality with the on-chain icph1 hash the way a v1 file can. It proves the reference survived transformation, not that the pixels are byte-identical.

The outputs are labelled_image (the IMAGE with the label baked in) and labelled (a boolean telling you whether the embed actually happened - always check it, because it quietly passes the image through untouched on any failure). Save labelled_image with a normal Save Image node and you're done. The README explicitly blesses this for stego-only work: the label lives in pixels, so nothing about native Save Image hurts it.

The honest catch

A stego label has no manifest to read - to verify a labelled image you need software that knows the Imprint format and the on-chain record. And because v1 is destroyed by re-encoding, the "share it on social media" use case really wants v3. Where people get burned is picking the default v1, uploading to Instagram or Twitter, and then wondering why verification comes back empty. If your image is going anywhere that recompresses, switch to imprint-stego-v3 before you save. If you need a manifest that a C2PA-aware verifier can read rather than a pixel label, that's the other export node's job - ImprintLabel can't carry a C2PA manifest through native Save Image anyway.

Installing

The pack isn't on the ComfyUI Registry yet (publication is waiting on an immutable publisher identity), so Manager search may not find it. Manual install:

cd ComfyUI/custom_nodes
git clone https://github.com/svcBSV/imprintai-comfyui.git
cd imprintai-comfyui
python -m pip install -r requirements.txt

Restart ComfyUI completely. Dependencies are just requests and Pillow, both already bundled. You need an ImprintAI account and key for the upstream Log node, but this label step itself needs no key - it's pure local math on pixels.