DOGMA Unshift Crop v34 — Exact Frame

Tiled restorers have a well-known habit: run the same grid twice and you can see the grid. The trick that community workflows settled on is to shift the second pass by half a stride so its seams land in the middle of the first pass's tiles - which means padding the image first and un-padding it afterwards. This node is the un-pad.

What it's the second half of

Its partner, DOGMAShiftPadV34, reflect-pads a restored master by shift_x / shift_y and outputs three things: the padded image, a DOGMA_SHIFT_META object, and an info string. The meta is a dict - pad_x, pad_y, orig_w, orig_h - i.e. a receipt of exactly what was added and what the frame used to be.

After the shifted pass (which in this pipeline is typically a 1.5x tiled refinement), you have an image that is bigger than the master by the pad on every side, times whatever scale you ran it at. DOGMAUnshiftCropV34 multiplies the recorded pad by scale, crops that rectangle off, and hands back the original frame:

crop at (pad_x * scale, pad_y * scale), sized (orig_w * scale, orig_h * scale)

If the requested rectangle runs past the edge of the image it gets clamped, and if the result comes back the wrong size the node falls back to a bicubic resize to force the exact target. That fallback is a rescue, not a feature - a bicubic stretch means you sliced wrong somewhere.

Inputs and outputs

• image - the finished shifted pass, at final resolution.
• meta - the DOGMA_SHIFT_META from the pad node. Not optional workaround-able: the output socket type is DOGMA_SHIFT_META, so you can't feed it a loose integer even if you know your pad. If you've rebuilt the shift by hand with an ImagePadForOutpaint, this node isn't for you - you'd crop manually.
• scale (default 1.5, 1.0–4.0) - the total upscale the shifted pass applied. It must match reality. Set 1.5 while you actually ran 2x and you'll crop a rectangle that's a third too small, then smooth it back up.

Outputs image and info. The info line prints the input size, the output size and the top-left corner it cropped at - that single line is the whole correctness check, so glance at it the first time you wire the pair up.

Install

ComfyUI Manager → search DOGMA Nodes, or:

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

Restart ComfyUI. Nothing to install beyond the pack: requirements.txt is a single comment - # No external dependencies. - and no model files are involved. The pack's README documents only the WAN VACE prep nodes and the DOGMA samplers, so this one is undocumented in the repo; the class body is short and readable if you want to confirm the maths yourself.

Where it bites

Reflect padding has limits. The pad node clamps shift_x/shift_y to less than the image dimension because reflect mode requires it - so an absurd shift on a small image silently becomes a smaller shift. The pad node's own info string reports the real value; read that rather than assuming your number.

Don't reorder it. Un-pad after every stage that was run on the shifted frame. Crop early and any remaining node is operating on a different frame origin than the metadata describes, at which point the numbers stop meaning anything.

It's a crop, so it's lossless only by construction. There's no resampling on the happy path - the field of view was added on purpose, and you're removing exactly what was added. The softness people report at this stage almost always traces back to a scale mismatch or a border clamp, not to the crop itself.

If you only ran one unshifted pass, you don't need either node. Shifting grids is a second-pass technique for killing visible tiling structure; on a single pass it just adds two nodes and a way to get the geometry wrong.