RUM Round Image For Save

RUMRoundImageForSave is the smallest node in the pack and possibly the most honest about what it's for. It takes an image, clamps it to 0-1, multiplies by 255, rounds to integers, and divides back - reproducing the exact quantization PIL applies when it saves a PNG. That's it. One op, zero knobs.

Why does a quantization shim exist? Because the RUM pack's whole second act is matching the upstream diffusers reference to the pixel. The reference pipeline converts float tensors to PNG through PIL, and PIL rounds. If your save path quantizes slightly differently - truncation instead of rounding, or a float that's 0.4 of a level off - your saved PNG is not pixel-identical to the reference even when the latent and decode math were perfect. This node closes that last gap. In both shipped workflows it sits between RUMFlux2NativeMatchVAEDecode and SaveImage, precisely because the author cared about that final rounding.

Inputs and output

• images - any IMAGE tensor.
• Output: images, with pixels quantized to 8-bit levels.

The honest take

This is the node you genuinely don't need for everyday use. If you're generating RUM images to look at, hang out with, and save - stock SaveImage quantizes perfectly fine, and the difference between rounding and whatever SaveImage does is invisible. RUMRoundImageForSave exists for pixel-level validation: reproducing pixel_equal=true against the upstream reference dumps, where the last 0-1 value shift can flip a comparison from pass to fail. It's validation apparatus wearing a workflow-node costume, and the author clearly knows it - it ships in the example workflows but the README describes the whole strict-pixel-equality story as a separate, optional pursuit.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Rinne414/ComfyUI-RUM
cd ComfyUI-RUM
pip install -r requirements.txt

Restart ComfyUI. No models needed for this node alone - the dependencies are the pack's standard minimal set (safetensors, huggingface_hub, numpy, pillow - pillow being the reference whose rounding behavior it mimics).

Where people get tripped up: none, really. The one "gotcha" is expectation-setting. If you add this node expecting visible quality improvement, you'll be disappointed. Add it because you're comparing your output to a reference dump byte-for-byte, and let it quietly do its job - then wire its output into SaveImage and move on.