DJZ Scale to Megabytes

Most upscalers ask "how big should the pixels be?" This node asks the question you actually care about half the time: "how heavy should the file be?" DJZ Scale to Megabytes resizes an image until its estimated PNG file size lands under a target you set in megabytes. If you've ever bounced an image off an API with a 5 MB upload cap, you know why that's a nice problem to hand to a node instead of playing the resize-and-pray game by hand.

Why you'd reach for it

It was purpose-built for API integrations. A lot of image APIs - image-editing endpoints, batch captioning services, Discord bots, whatever your workflow talks to - reject anything over a hard byte limit, and they don't tell you how close you got. This node takes the guessing out: set total_megabytes to 4.99 and it resizes conservatively so the PNG estimate stays under 5 MB. The default of 4.99 is literally that use case baked in.

It's also handy for predictable storage: if you're dumping thousands of generated images somewhere with a size budget, forcing each file to a target MB makes planning trivial.

How it works

The node is a cousin of DJZImageScaleToTotalPixels, but instead of targeting a pixel count it estimates file size:

1. Estimate the uncompressed PNG size: width × height × channels.
2. Apply a ~0.6 compression factor (assumes roughly 40% PNG compression).
3. Scale factor = √(target_bytes / current_bytes), applied to the dimensions.
4. Round the result so both sides are multiples of divisible_by.
5. Resize with your chosen upscale_method.

That square-root is doing real work: file size scales with pixel area, so to halve the bytes you shrink each dimension by √2, not by half.

The inputs that matter

• total_megabytes - your target. Default 4.99; the range goes 0.01 to 100.
• divisible_by - rounds dimensions to multiples of this, default 64. That's the VAE-friendly convention most models expect, so leave it unless you know why you're changing it.
• upscale_method - nearest-exact is fastest, lanczos looks best. For downscaling (which is what this usually does) area is the mathematically honest choice; bilinear and bicubic are fine too.
• batch - the one that surprises people. Off: each image gets its own 4.99 MB budget. On: the total budget is split across the batch, so 3 images get ~1.66 MB each. If you're submitting a batch to a size-limited API, you want it on.

Output is a single IMAGE you can save or pipe onward.

Installing it

It's part of DJZ-Nodes, so you're installing the whole pack:

cd ComfyUI/custom_nodes
git clone https://github.com/MushroomFleet/DJZ-Nodes
cd DJZ-Nodes
pip install -r requirements.txt

Or ComfyUI Manager → search "DJZ-Nodes" → install. The dependency list is heavy (opencv-python, librosa, numba, moderngl among others) but there are no model downloads for this node.

Troubleshooting

• It's a size estimate. The 0.6 compression factor is a middle-of-the-road guess. A photo with fine noise or heavy gradient compresses worse than flat illustration, so the actual PNG can land above or below the estimate. The node is deliberately conservative - it would rather under-shoot and keep you under the cap than surprise your API.
• The estimate assumes PNG. If you're saving JPEG or WebP afterward, the real file will be far smaller than the node budgeted for. You can often afford a bigger total_megabytes in that case.
• Minimum size clamp. It won't shrink below divisible_by × 1 pixels, so a genuinely tiny image can't be forced lower - it just returns what it can.