WanVideo Embedding Analyzer

An embedding is just a big vector - a thousand-plus numbers - and most of the time you don't need to look at it. But there are moments in this pack where the numbers are the whole point: "why does my injection measure as 12% different from my main prompt?", "why do two prompts that feel different look nearly identical after projection?", "which dimensions actually carry the signal?" That's when you reach for this node. It turns a WANVIDEOTEXTEMBEDS into a readable report about itself.

What it reports

analysis_type picks the depth:

• shape - the tensor's dimensions, element count, dtype, and device. Quick sanity check that your embeddings are where and how you expect (this is the node that tells you raw 4096 vs projected 5120, which is the pack's most common silent bug).
• statistics - mean, std dev, min, max, L2 norm, and the percentage of near-zero values. The "how is this embedding distributed" readout.
• pca_preview - a simplified dimensionality probe: ranks the top-10 dimensions by variance and estimates the effective dimensionality (how many dims carry 90% / 95% of the variance). This is the one that actually informs block-injection thinking - "my prompt's meaning mostly lives in ~a few hundred effective dims" changes how you interpret measured differences.
• all (default) - everything above in one pass.

store_in_db (default on) auto-saves the embedding to the pack's DuckDB database - the same store the WanVideoEmbeddingDatabase node manages - and the report includes the stored ID and current database stats (count + compression ratio). So this node doubles as the easiest way to populate the database for your block-mapping experiments.

Outputs: analysis_report (STRING) and text_embeds (the same embeddings passed through unchanged). It's a read-only node - the passthrough output just keeps your graph tidy.

Why you'd reach for it

Two concrete moments. First, debugging the pack's central mystery - "the projection flattened my differences" - by checking the raw embedding's stats and effective dimensionality, you can see whether your two prompts genuinely differ in the raw space before you blame the projection layer. Second, the systematic-experimentation use case the README is obsessed with: as you test blocks and strengths, log every prompt's embedding with stats, and you build a dataset of "which embeddings, which differences, which blocks did what." That's literally the pack's stated purpose (the author bundles DuckDB specifically to facilitate sharing data for open research).

Install

Same pack, WanVideoWrapper required first:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper   # required first
git clone https://github.com/fblissjr/ComfyUI-WanActivationEditor
cd ComfyUI-WanActivationEditor && pip install -r requirements.txt

Restart ComfyUI (ComfyUI Manager: search "ComfyUI-WanActivationEditor"). Deps: torch, numpy, duckdb, zstandard. The database is DuckDB at ~/ComfyUI/models/wan_embeddings/embeddings.duckdb - it auto-creates, no setup, and it's a real SQL database if you ever want to query it directly. If the report shows "Near-zero values" at 99%+, that's usually an FP8-quantized or otherwise compressed embedding talking, not an error.