EmberFrame Latent Capture Inspector
Point it at a latent and it tells you what's actually inside
- latent
- capture_info
EmberFrame Latent Capture Inspector is a diagnostic node with one job: take any LATENT, and tell you what's inside it. It returns a single STRING (capture_info) describing the latent's shape, dtype, device, tensor statistics, and - the part that matters in a PiD workflow - any sigma that's been embedded on it.
Latents are opaque by design. You stare at a workflow and you genuinely cannot tell whether the latent on that wire is a denoised final, an intermediate at some noisy step, on the GPU or the CPU, fp16 or bf16, or carrying a pid_sigma. This node turns the black box into a string you can actually read.
How to use it
Drop it after whatever latent you're suspicious about and connect capture_info to a Show Text node (or any string viewer). The report you get back is one line covering:
- shape and dtype - catches the classic "this is fp32 on CPU and that's why everything's slow" problem
- is_nested - whether you're holding a nested tensor (batch-of-shapes, the thing that trips people up when a latent isn't a clean
B,4,H,W) - tensor stats - min/max/mean, so you can see whether your normalization actually landed in the range you expected
- embedded_pid_sigma - the sigma that was attached by the capture or Attach node
- external_sigma - an optional
sigmainput you can wire up if you want to compare the attached value against what you think it should be - the latent's keys - so you can see at a glance whether there's a
pid_sigmariding along at all
The optional sigma input exists purely for comparison. Feed it the value you expect the latent to have been captured at, and read the two side by side. If they disagree, you've found the wiring bug.
When this saves your afternoon
This is the first node to reach for when a PiD decode comes out wrong. The capture node's capture_info output already prints its own debug line, but it only describes the moment of capture - the Inspector tells you what's on the wire here, after any Normalize step or reconnect has mangled it. It's also the sanity check for the Normalize node: run Normalize, then inspect, and confirm your min/max moved to where the PiD decoder expects. That's the entire debugging loop, and it's a two-node loop.
Install
Part of the EmberFrame Nodes pack, under EmberFrame → PiD:
cd ComfyUI/custom_nodes
git clone https://github.com/emberframe/emberframe-nodes.git
Restart ComfyUI. No downloads - the pack has zero Python dependencies beyond ComfyUI's own torch.
This isn't a node you use on every run. It's the flashlight you grab when something stops making sense, and when you need one, nothing else in the pack is half as useful.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| latent | LATENT | — | |
| sigmaopt | FLOAT | 0.0000–1000 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| capture_info | STRING | — |