v1.4.3 - 1. Error in advanced mode 2. Mapping looks weird at a certain ratio

[ostap667inbox]

Bug 1 The bug appears with any number of areas, i.e. now the advanced mode doesn't work at all. Basic mode with same prompt is Ok.

*** Error running process_before_every_sampling: C:\stable-diffusion-webui-forge\extensions\sd-forge-couple\scripts\forge_couple.py
    Traceback (most recent call last):
      File "C:\stable-diffusion-webui-forge\modules\scripts.py", line 835, in process_before_every_sampling
        script.process_before_every_sampling(p, *script_args, **kwargs)
      File "C:\stable-diffusion-webui-forge\extensions\sd-forge-couple\scripts\forge_couple.py", line 193, in process_before_every_sampling
        patched_unet = forgeAttentionCouple.patch_unet(unet, base_mask, ARGs)
      File "C:\stable-diffusion-webui-forge\extensions\sd-forge-couple\scripts\attention_couple.py", line 25, in patch_unet
        assert mask.sum(dim=0).min() > 0, "Masks must not contain zeroes..."
    AssertionError: Masks must not contain zeroes...

Prompt, 3 lines:

a high definition realistic photograph of close-up view calico cat sleeping on the garden path, eyes closed, 
marble fountain in background, 
surrounded by lush greenery and blooming flowers, sunlight filtering through leaves, best quality, 4k, 8k, photorealistic, style, summer vibe, masterpiece, natural lighting, high resolution

And map with 3 areas:

Issue 2 Width: 2048, Height: 1024 and vice versa.

There is no functional error, probably it was designed that way. The black area and selected zones have correct proportions, blocks do not go beyond the black area when resizing or moving. Everything is fine. Only the rest of the area looks strange, it seems to me that it is better to adjust the height or width of the whole outer block to the size of the working area. Yes?

P.S. Because of rounding, it is often impossible to manually set the size of squares exactly on the border of the workspace. For example, I try to make a rectangle 100% wide, change its dimensions with the mouse, but I get an interval of 0.03:0.99 instead of 0.0:1.0.

So, if you plan to get rid of the manual coordinates option in the future, it's better to keep them. It doesn't cause any functionality problems, but the sight of single-pixel black indents will cause OCD attacks in some users, ha-ha :)

[ostap667inbox]

Bug with the message "Masks must not contain zeroes..." appeared just because the total marked areas did not cover all 100% of the image area. I didn't realize this was a requirement. This problem has been resolved.

This is precisely due to rounding, when drag-n-drop fails to make an area with coordinates 0 or 1. In my screenshot above, you can just see the yellow area with Y-coordinates 0.00:0.99.

So being able to control the numbers and correct them by hand is very necessary. Earlier you mentioned that you were going to remove coordinates from the table because you added drag-n-drop functionality. This is an example of why this functionality is needed. :)

[Haoming02]

Earlier you mentioned that you were going to remove coordinates from the table

No, people want them removed, but I still want to keep them 🤷

An improvement would be some sort of snapping I guess.

Glad to see there's no actual problem at least, right?