String Extract From Image (RGB)

The reverse of String Embed In Image (RGB), its companion in the same pack: feed it an image that's had a string hidden in its pixels, and it reads that string back out.

What it's doing. Same "MP3" naming confusion applies here - despite the slug, there's nothing audio-related about this node at all, which the actual display name makes clear ("String Extract From Image (RGB)"). It decodes whatever text was written into the image's RGB pixel data by the matching embed node and returns it as plain text. This is the read side of an image-steganography pair, not an audio decoder.

Inputs and outputs. One required input, image (IMAGE). One output, data_string (STRING).

Why do it this way instead of the metadata trick ComfyUI already has. ComfyUI already has a built-in, well-known way to attach text to an image - its own save routine writes the full generation workflow into the PNG's metadata, which is exactly why community "workflow included" images work at all: drag one back into ComfyUI and it reconstructs the graph. That approach is convenient but fragile in a specific way - any tool that re-encodes the image, strips metadata for privacy, or converts it to a different format wipes the payload instantly, because metadata chunks are explicitly separate from the pixel data. A pixel-embedded payload like this pair of nodes uses survives things that would kill a metadata-based one (most basic recompression aside), at the cost of being far more fragile against anything that actually touches pixel values - which is the opposite trade-off. Neither approach is strictly better; they're solving for different kinds of durability.

Installing it. Same pack as its companion - search comfyui-huyl2-nodes in ComfyUI Manager, or:

cd ComfyUI/custom_nodes
git clone https://github.com/huyl3-cpu/comfyui-sortlist

Restart ComfyUI.

Troubleshooting. An empty or garbled string coming back almost always means the image was altered somewhere between the embed step and this extraction step. Resizing, converting through a lossy format like JPEG, running an upscaler, applying color correction - anything that touches pixel values, even subtly, is enough to corrupt a payload that's living inside those exact values. If you need this round-trip to survive an actual pipeline rather than a quick test, embed the string as the very last step before saving, and extract it before anything else has a chance to touch the file. Treat any node between the two that so much as claims to "clean up" or "optimize" an image as a suspect if extraction starts failing.