DOGMA - Protezione colore tile

DOGMAColorProtectionV124 gives you four named strengths but no math - the correction happens inside a render node. This one is the same idea with the actual operation exposed as a node: you hand it a generated image and the reference it should look like, and it returns the generated image with its broad color and brightness pulled back toward the reference. Detail is untouched.

This is the fix for the classic tile problem. Any tiled pipeline - tiled VAE decode, tiled upscale, a masked inpaint pass - produces patches that are individually fine and collectively slightly off. One tile runs a bit warmer, the next a bit brighter, and the grid becomes visible in flat areas like sky, walls, and haze. Per-pixel correction is the wrong tool; you want to fix only the broad, low-frequency difference and leave the texture alone.

How it works

The node computes the pixel delta between generated and reference, downsamples that delta to roughly a quarter scale with area interpolation, blurs it with a Gaussian whose sigma is sized in that reduced space (so a fixed spatial scale in render pixels, held constant even on smaller edge tiles), interpolates the result back up to full resolution, and subtracts it from the generated image:

output = generated - (1 - strength) * low_frequency_delta

So strength is the fraction of the generated tile's low-frequency content you keep. At strength = 0 the broad tone becomes the reference's; at strength = 1 the node returns the generated image untouched (it short-circuits before doing any work at all). The default is 0.15, which is a firm correction - the same value the phase-3 render nodes use as their default.

Two design decisions worth naming. The broad-difference mask is fixed in render pixels rather than scaled with tile size, so a small tile at the edge of the image gets the same physical correction scale as a full one. And the node explicitly does not normalize or histogram-match the tile - no auto-levels, no white balance guess, just the low-frequency delta. That keeps it predictable: you can run it and know exactly what changed.

Inputs and outputs

• generated (IMAGE) - the tile or patch you just rendered.
• reference (IMAGE) - the source it should match. Order matters; they are not interchangeable.
• strength (FLOAT, default 0.15, 0–1) - keep-amount, as above.

One output: IMAGE.

The validation is strict and it fails loudly rather than guessing: the two tensors must have identical shape and the generated image must be RGB. If you are feeding it tiles from a pipeline that pads to a multiple of 32, run both branches through the same pad node first, or the shapes will not match.

Install

Part of the pack:

cd ComfyUI/custom_nodes
git clone https://github.com/axior/ComfyUI-DOGMA-Nodes

Or ComfyUI Manager → search DOGMA Nodes. The only declared dependency is scipy>=1.10 (requirements.txt) - that is what supplies the Gaussian filter - plus torch, which ComfyUI already has. Restart afterwards.

Where it fits

Put it after the generation, before the composite. In a DOGMA graph the render nodes already do a similar correction internally with low_frequency_strength, so stacking both is how you end up with a washed-out patch - pick one. This node is the one to reach for when you are running a tiled upscale of your own that is not part of the DOGMA render chain, which is the more common case for anyone who found this node through the pack rather than through the workflow.

If the result looks flat or plasticky, your strength is too low - you are stripping the tile's own lighting response, not just its cast. 0.2 to 0.3 is the sane range for a workflow that did not need the correction in the first place; 0.15 is for a patch you know has drifted.

And keep expectations honest: this fixes tone, not seams. A visible tile edge is a feathering and overlap problem, and no amount of low-frequency correction will hide it.