Load Latent from Base64

This is the receiving half of NetDist_Plus's latent-transport pair. LatentToBase64-Nux flattens a LATENT tensor into a string on whichever instance produced it; this node takes that string and turns it back into a real LATENT you can feed into a VAE Decode or a second sampling pass, on whichever instance actually needs it.

Read this before you build around it

The pack's own README says it plainly in the author's Issues list: "Remote Latents: I didn't get a chance to test it." This node exists and does what its name says, but the author never fully validated the round trip end to end. If it works cleanly for your setup, great - but go in knowing you're the one doing the testing the author didn't get to. The conditioning side of this pack (ConditioningToBase64-Nux / ConditioningFromBase64-Nux) is the far more proven path, built around a demonstrated remote text-encoding workflow; latent transport is the newer, less-verified addition.

Inputs and outputs

One input: base64_latent, a multiline string field that defaults to empty. Wire it from LatentToBase64-Nux directly, from FetchRemoteWithExtras-Nux's latent_base64 output if you're using the automatic remote-fetch flow, or from ExtractBase64FromImage(Upload)-Nux if you're pulling it back out of a saved file.

One output: LATENT, ready to plug into a VAE Decode or a downstream KSampler.

Installing it

ComfyUI Manager: search ComfyUI_NetDist_Plus. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/nux1111/ComfyUI_NetDist_Plus
pip install requests

Restart ComfyUI. No model weights are downloaded by this node.

Where people get burned

The default value for base64_latent is an empty string, not a clear "nothing connected" error. If you forget to wire something in here, you won't get a loud failure at this node - you'll get an empty or invalid latent that only shows up as a problem once it hits VAE Decode downstream and produces nonsense or crashes outright. If decoding fails, trace back to this node's input first before assuming the VAE is at fault.

The other real trap is a mismatch this node can't see: a latent's shape and scale depend entirely on the model and VAE that produced it. This node just deserializes bytes into the LATENT structure - it has no idea whether what's inside is compatible with whatever you're about to decode it with. Keep the model family consistent (SD1.5, SDXL, Flux, etc.) on both ends of the trip, or expect garbage output.

Given the author's own untested-caveat, treat any weirdness here - shape errors, visual garbage after decode, silent failures - as genuinely unexplored territory rather than user error. If latent transport doesn't pan out for your setup, falling back to just fetching the finished image with FetchRemoteWithExtras-Nux is the safer, better-worn path.