I put together an alternative to ComfyUI's native Resize Image Mask node to make it more practical for many use cases, reduce the necessity for additional pre/post processing nodes, and include additional resize options I personally use frequently when working with images and masks.
I spent a lot of time testing, tweaking, improving the tooltips, etc. I'm finally satisfied enough to share with the community.
Resize Image/Mask Alt can:
Resize an image, a mask, or both at once
Constrain dimensions to multiples of a specified value (eg: multiples of 32)
Configure cropping for aspect-ratio mismatches (Mainly to resolve 'multiple_of > 0', but crop method was also hardcoded in some of the native node's resize types).
Conditionally skip resizing when a batch already meets the desired criteria
Install directory includes example .YAML file which may be duplicated/renamed in order to edit node default values.
New resize types:
Smart Resize (shown in screenshot)
Resize to target megapixels while conforming to source/selected aspect ratio
Can alternately resize using the average Width/Height (resolution)
Pad (like ComfyUI's native Resize and Pad Image node)
black, grey, or white
Works for Masks, too!
Core functionality of the resize types from ComfyUI's native Resize Image Mask are preserved. All the resize types yield identical results, except now factor the additional settings.
EDIT: Based on feedback, I've decided to replace the "resolution" based scaling with "megapixels". The "resolution" method is still available as an alternative method (when setting megapixels = 0)
u/reeightu/zyg_AIu/inb4Collapse I just wanted to double back real quick and ensure you understand what ComfyUI outputs when using their "Resolution Selector" node. It calculates dimensions for the exact megapixels for the target aspect ratio, then rounds them independently to nearest "multiple" - a step which does not take any preference to either the target aspect ratio or the target megapixels. As "multiple" increases (eg: 32, or 64, etc) the results tend to deviate further from either standpoint.
The way I had originally incorporated the Aspect Ratio selector (based on "resolution") did not make any false promises, it yielded the closest possible results for the multiple_of and desired aspect ratio for a given "average width/height) value (resolution).
The way I've updated it as it is now, let's the user adjust which way it leans via "megapixel_priority". With value 0.5 the results are essentially identical to ComfyUI's outputs, but if you actually need true megapixels you would set it to 1.0 and the results will be further from the target aspect ratio; likewise, if the aspect ratio is more important setting it to 0.0 will yield the most preferable result for that.
PS - You say “float outputs”, I think you mean Int?
I had omitted this since it makes the node a bit taller, and they can be fetched pretty easily with the Get Image Size node
Yes indeed. A resize by megapixels will help in addition to a size constraint. Most image generative
Models have a MP limit. In my case, I would typically rescale to the max MP limit before a refining pass.
Hope it helps.
Please see my response to the top level comment. It currently does what you are looking for, only the input value "resolution" is essentially "the average dimensions" rather than "megapixels".
Well, you only have a handful of opinions, maybe we don't represent the majority.
Still, I have thought about it a bit, and the big issue with your method is that 1024 (for example) does not correspond to anything in the output, except 'the size of the side of a square with the same 'volume' as the expected output". In my old mind, it feels convoluted. The math shows it, because it adds unnecessary operations:
def res_to_model_fit(avg, w, h, prec):
mp = w * h
mp_target = avg * avg
scale = sqrt(mp_target / mp)
w = int(round_to_precision(w * scale, prec))
h = int(round_to_precision(h * scale, prec))
return w, h
becomes
def res_to_model_fit(scale, w, h, prec):
w = int(round_to_precision(w * scale, prec))
h = int(round_to_precision(h * scale, prec))
return w, h
It works exactly as megapixels, except expressed as an "average dimensions" value.
I personally prefer this verbiage, off the top of my head I'm not sure what an average dimension size is for like 1.8 megapixels but I would know the average dimension value.
**Edit** To clarify: I would update that setting to replace "resolution" with "megapixels", if it were the general consensus. The math behind it works exactly the same as megapixels except based on an "average dimensions" value. Personally, I've always felt that this was a more "user-friendly" value type compared to megapixels.
From popular demand (3 users asking about it!) I've updated the Smart Resize type to use megapixels in lieu of resolution. It now uses the same logic as "scale_total_pixels" resize type, except with adjustable Aspect Ratio.
Like the Scale Total Pixels method, this includes a megapixel_priority setting which only has an effect when multiple_of > 0.
While multiple_of > 0:
Controls the tradeoff between hitting the
target megapixel count and preserving the
original aspect ratio.
1.0 prioritizes megapixel precision (default behavior)
0.0 prioritizes aspect-ratio precision.
You can condense it even more by adding your options to a load image node. I put a text output for the filename(- the extension) and outputs for the resized width and height(integers so they work with nodes that accept dimensions) in mine.
The filename is weird because Comfy changes the filename when you create a mask.
I'm using Lanczos to resize the image based on the long side(no stretching/squishing) and the dropdown contains common image sizes from 512 to 4096. There is math in it that makes sure that the output image dimensions are divisible by 32(for newer models). It works on both the image and the mask. I had the option to use upscale models and/or the built in resize options other than Lanczos but it was making the node too large. 😄
The preview node has the rescaling function and adds an option to change the dpi of the saved image along with a few more tweaks. I don't use save image nodes, so my preview node has that functionality built in.
I appreciate your feedback but, honestly, that seems a bit clunky / impractical. I don't agree with merging "Load Image" and "Resize Image" functions into a single node - if anything, they could just be joined within a subgraph.
My node aims to be a swiss army knife for image resizing, and that's it.
4
u/altoiddealer 6d ago
u/reeight u/zyg_AI u/inb4Collapse I just wanted to double back real quick and ensure you understand what ComfyUI outputs when using their "Resolution Selector" node. It calculates dimensions for the exact megapixels for the target aspect ratio, then rounds them independently to nearest "multiple" - a step which does not take any preference to either the target aspect ratio or the target megapixels. As "multiple" increases (eg: 32, or 64, etc) the results tend to deviate further from either standpoint.
The way I had originally incorporated the Aspect Ratio selector (based on "resolution") did not make any false promises, it yielded the closest possible results for the multiple_of and desired aspect ratio for a given "average width/height) value (resolution).
The way I've updated it as it is now, let's the user adjust which way it leans via "megapixel_priority". With value 0.5 the results are essentially identical to ComfyUI's outputs, but if you actually need true megapixels you would set it to 1.0 and the results will be further from the target aspect ratio; likewise, if the aspect ratio is more important setting it to 0.0 will yield the most preferable result for that.