Add Strict Opposite Mask
Only add where the models are *truly* opposite — the strict mask
- a (delta|param|weight)
- b (delta|param|weight)
- c (delta|param|weight)
- alpha (1.0)
- recipe
Add Strict Opposite Mask is the picky eater of the mask family. Where Add Opposite Mask gives you a smooth "how much do these disagree" weighting, this one clamps hard so that only weights which are cleanly opposite survive - everything else rounds to zero. It's the surgical instrument you reach for when you know two models took explicitly opposite stances on some weights and you want to add the delta only there, with no soft middle ground.
The stricter math
The mask is 2 * clamp((c − a)(b − c) / max(|a − c|, |b − c|)², 0), scaled by alpha (default 1.0). Read the sign first: (c − a)(b − c) is positive only when a and b sit on opposite sides of the anchor c - that's the "strictly opposite" test. If a and b are on the same side of c, the product is negative and the clamp zeroes the weight entirely. The denominator normalizes by the larger of the two distances, so the surviving values stay bounded. Compared to the symmetric Add Opposite Mask ratio, this is deliberately harsher: shades of "mostly opposite" don't count, only clear opposites do.
Inputs: a, b, c (each delta|param|weight) and alpha. Output: one recipe (MECHA_RECIPE) in param space - a mask, not a model.
When strict is the right call
The strict mask pays off when the disagreement is known-clean: you have a solid anchor c, and you want the merge to act only on the weights where the two models went head-to-head, leaving everything else untouched. The failure mode to watch for is noise: any spurious sign flip in near-zero weights gets treated as a clean opposite, which is why "strict" here also means "brittle." If your models are noisy or the anchor is approximate, the smooth Add Opposite Mask will serve you better. A quick rule of thumb - if the smooth mask looks like a salt-and-pepper mess, don't switch to strict; fix the anchor first.
Like every recipe node in this pack it streams lazily and carries the merge_checkpointing toggle to cache the branch on CPU in fp16 once the recipe is stable.
Install & gotchas
ComfyUI Manager → search mecha → "Mecha Merge Node Pack", or:
cd ComfyUI/custom_nodes
git clone https://github.com/ljleb/comfy-mecha.git
pip install -r comfy-mecha/requirements.txt
Restart after. Dependency is sd-mecha==1.1.7.
Same rules as its siblings: the output is a param recipe - feed it into a param slot, never into Mecha Merger as if it were a model. And c is the reference that defines "opposite"; without a trustworthy base model there, the strict test has nothing to be strict against.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| a (delta|param|weight) | MECHA_RECIPE | — | |
| b (delta|param|weight) | MECHA_RECIPE | — | |
| c (delta|param|weight) | MECHA_RECIPE | — | |
| alpha (1.0)opt | MECHA_RECIPE | 1 | — |
| merge_checkpointingopt | BOOLEAN | false | Speeds up an entire branch of a merge graph that does not change often in exchange of memory. - true: store the first output of this recipe node on cpu memory in fp16. On subsequent workflow executions, as long as the inputs do not change, the cached keys are returned after being cast to the original device and dtype. - false: do not store the output. The recipe and its inputs will re-execute on subsequent workflow executions. Note that the memory used to checkpoint the output is distinct from the cache feature. In general, you probably want to either use this *or* a cache unit, but not both at the same time because the memory adds up. The difference between merge checkpointing and cache is that merge checkpointing completely re-merges from scratch if any input changes. Merge checkpointing is also generally much faster than cache in the fast path. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| recipe | MECHA_RECIPE | — |