Max Resolution Filter

You've got a pile of images on one wire and you only care about the biggest one. That's the whole job of Max Resolution Filter: it eats a list of images and spits out the single image with the most pixels. It exists because batch workflows are the one place ComfyUI's "everything is a tensor, just ignore the batch dimension" story quietly falls apart - load ten images from a folder, and now you have ten images on a socket that most nodes expect to be one.

The classic case: you batch-generate variations, or you load a directory of frames, and downstream you have a single-image consumer - a face detailer, an upscaler, a save node - that you want pointed at the sharpest candidate. Instead of eyeballing which frame is biggest and rewiring, this node decides for you at runtime. It's also handy right before a hi-res pass where the whole point is "take the largest, refine it." One light aside: it compares by raw pixel count (width × height), not by "how good the image looks," so it's a bouncer, not a critic.

How it works

Under the hood it's dead simple, which is why it's reliable. It walks the list, multiplies height by width for each entry, and keeps the one with the biggest product. Two details in the source make it more forgiving than most list nodes: it unwraps one level of nested lists (some upstream nodes hand you [[img]] instead of [img]), and if a single entry actually carries a batch of several images (B > 1), it splits them and compares each one individually. Ties in pixel count go to whichever came first in the list.

One structural thing worth knowing: this node declares INPUT_IS_LIST, so the image_list socket genuinely expects a list of images on one wire. You cannot drop a normal single-IMAGE output into it and expect it to work. Feed it from a list-producing node - a folder loader that outputs a list, wcx_ImageListToImageBatch's inverse, or any batch-to-list utility in your toolkit. The wildcard input type means it'll accept whatever list you throw at it.

The inputs and outputs that matter

Honestly, there's one input and one output, and you'll set neither by hand:

• image_list - the only input. Wildcard type with forceInput, so it has to come from a wire. The comment in the source says it deliberately uses * so it connects to anything upstream without type errors.
• IMAGE - the output. A single image (batch of 1), normal uppercase IMAGE, so it plugs straight into anything that takes one image.

How to install it

This ships in ComfyUI-Practical-Tools by wenchengxiang. Easiest route: ComfyUI Manager → "Install Custom Nodes" → search ComfyUI-Practical-Tools, install, restart. Or the manual way:

cd ComfyUI/custom_nodes
git clone https://github.com/wenchengxiang/ComfyUI-Practical-Tools

Then restart ComfyUI. The pack has no requirements.txt and downloads nothing - it's torch, Pillow, and the standard library, all of which ComfyUI already has.

Where people get burned

• Feeding it a single image instead of a list. The forceInput wildcard will happily accept a plain IMAGE wire, but since the node processes what arrives as a list, you'll get a confusing error about an empty list or a mismatched shape. Make sure the upstream is genuinely list-typed.
• "Biggest" isn't always "best." At equal resolutions the first entry wins, and a 1024×1024 will always beat a 1536×512 even if the wide one is the one you wanted. If you need a rule smarter than pixel count, you're looking for an image-quality gate instead.
• It collapses your batch. The output is one image, not a batch. If the node after this needs a batch of one shape or another, you'll be re-batching downstream - that's expected, not a bug.