lquesada / ComfyUI-Inpaint-CropAndStitch

ComfyUI nodes to crop before sampling and stitch back after sampling that speed up inpainting
GNU General Public License v3.0
398 stars 23 forks source link

maybe it's me (probably) but why i can't catch the mask? #15

Closed 4lt3r3go closed 5 months ago

4lt3r3go commented 5 months ago

image whatever i mask then is picking different areas. I don't know what i'm doing wrong :(

lquesada commented 5 months ago

Hi!

Have you tried updating the node? I fixed a bug with forced size two days ago - sorry about this bug, but I ran a huge revamp over the weekend to enable ranged size and to make forced size work well and introduced this bug.

If that doesn't work, please try using ranged size with min and max width and height 512 and let me know if that works. For troubleshooting.

Cheers, Luis.

DavidSnow1 commented 5 months ago

Hey Luis, it's DaveAI. I'm sure you remember me. It was me that pointed 4lt3r3go to your nodes in this thread here:

https://www.reddit.com/r/comfyui/comments/1d8kgwv/comment/l78mqdl/

Anyway, during the discussion, I noticed that 4lt3r3go's nodes had the forced width and height options, which mine didn't have, so I just did an update. Now I am getting the same issue. We've both updated the nodes within the past couple of hours.

(Not sure if this image link will work, but it'll show the same thing.)

busted

lquesada commented 5 months ago

Got it, thanks for confirming, I'll check ASAP

lquesada commented 5 months ago

As a workaround try ranged size and set all min and max to exactly the size you desire

DavidSnow1 commented 5 months ago

Yup, that works.

lquesada commented 5 months ago

Bad news: I'm not able to reproduce it. Good news: It's fixed now :) Please try it and let me know.

Full explanation: Trying to reproduce it - I know what is likely the culprit, but while some enqueued job ends, I'll share more details for the records:

Before, "forced size" wouldn't really force the size if the selected area wouldn't allow a context area that was square within the image, e.g. if the image is landscape orientation and you selected a very wide area, there was no way to force the square shape.

Two things happened:

1. Unrelated, switched force size to force width and height per a feature request.

2. In order to fix the issue above, the node now first virtually extends the image horizontally and vertically to fit any potential square area.

Then, it forces selecting the area with the right size and shape (e.g. square) and can bleed out of the original image.

Stitching happens as usual and the extra part is discarded.

What this feature brings is more consistency - a guarantee that the area will always be the exact size you're trying to force.

So what's the issue? Why doesn't it affect ranged size?

Well, the way I calculate the target size for forced size is different than I do for ranged size (adjust to size instead of adjust_to_aspect_ratio):

def adjust_to_aspect_ratio(self, x_min, x_max, y_min, y_max, width, height, target_width, target_height):
    x_min_key, x_max_key, y_min_key, y_max_key = x_min, x_max, y_min, y_max

    # Calculate the current width and height
    current_width = x_max - x_min + 1
    current_height = y_max - y_min + 1

    # Calculate aspect ratios
    aspect_ratio = target_width / target_height
    current_aspect_ratio = current_width / current_height

    if current_aspect_ratio < aspect_ratio:
        # Adjust width to match target aspect ratio
        new_width = int(current_height * aspect_ratio)
        extend_x = (new_width - current_width)
        x_min = max(x_min - extend_x//2, 0)
        x_max = min(x_max + extend_x//2, width - 1)
    else:
        # Adjust height to match target aspect ratio
        new_height = int(current_width / aspect_ratio)
        extend_y = (new_height - current_height)
        y_min = max(y_min - extend_y//2, 0)
        y_max = min(y_max + extend_y//2, height - 1)

    return int(x_min), int(x_max), int(y_min), int(y_max)

def adjust_to_size(self, x_min, x_max, y_min, y_max, width, height, target_width, target_height):
    # Calculate the midpoint of the current x and y ranges
    x_mid = (x_min + x_max) // 2
    y_mid = (y_min + y_max) // 2

    # Calculate new x_min, x_max, y_min, y_max to match the target size
    x_min = max(x_mid - target_width // 2, 0)
    x_max = x_min + target_width - 1
    y_min = max(y_mid - target_height // 2, 0)
    y_max = y_min + target_height - 1

    return int(x_min), int(x_max), int(y_min), int(y_max)

And then I do completely different calculations for forced size vs ranged size.

While writing this down I just realized that forced size is now a subcase of ranged size, so I can remove the codepath for forced size and make it run ranged size. This will fix it (because ranged size currently works for you and forced size doesn't) and simplify the code, which is great in any case.

Done.

Please let me know if this works fine now.

DavidSnow1 commented 5 months ago

Ran the same test, this is the result now. It appears to be fixed.

As ever, you are a speed demon. Have you been snorting caffeine again Luis? :)

Cheers buddy,

fixed

lquesada commented 5 months ago

I've been running without caffeine for two weeks, hahaha. Glad that it now works. This simplified the node a lot, so less likely to hit issues.

On the other hand, I'm sorry that this went through, it's been pretty rough and that's because of 1. speed and 2. Too many feature requests.

Enjoy!

4lt3r3go commented 5 months ago

As a workaround try ranged size and set all min and max to exactly the size you desire

that was exactly the workaround i was using meanwhile you fixed this fast as speed light! thank you so much. you are amazing