Variations aren't shown for discontinuous refinement brush strokes of Generative Remove

[John R Ellis]

When trying to remove an object with visually discontinuous pieces, LR shows variations for just the first brush stroke, not for additional non-contiguous strokes. This makes it hard to follow Adobe's recommendation for removing rather than replacing objects:

"Remember that removing an object means painting over it, its shadow, its reflection, and any non-contiguous pieces. If you leave behind a shadow, a reflection, or a disconnected piece (e.g., a hand on a shoulder), the AI will attempt to create something to cast the shadow, reflect, or complete the unbrushed discontinuous item."

The workaround is to select all the discontinuous pieces with a single brush stroke and then use refining Subtracts to remove the areas you don't want replaced.

To reproduce on LR 13.4 (see the attached screen recording):

1. With Generative AI selected and Object Aware unselected, make a large selection of an object.

2. Then with Add clicked, make another large selection of an object, disconnected from the first.

3. Click Apply. Observe that both selections have been replaced.

4. Cycle through the variations, and notice only the first selected object shows new variations.  Click Refresh and again, only the first object shows new variations. (Incorrect)

6. Reset the photo.

7. With Generative Remove, select both objects.

8. Use Refine > Subtract to remove the selection in between the objects.

9. Click Apply.

10. Cycle through variations and Refresh and observe that both objects show new variations. (Correct)

See this post for a "real" instance of the issue, where the user wants to remove a railing that's visually discontinuous:

https://community.adobe.com/t5/lightroom-classic-discussions/p-new-ai-powered-generative-remove-earl...

[Rikk Flohr: Photography]

Realize that when you make discontiguous selections, separate adjustment pins are created for each area, and it is necessary to select the various pins for each area. By default, only the first stroke is selected.  If you are unable to select the other areas and view the variations, that would be an actual bug. 

Also, note that Lightroom Desktop and Lightroom Classic behave differently in this regard and that both behaviors are being evaluated while the feature is in Early Access. 

[John R Ellis]

Thanks much for that clarification.

I found the current behavior so totally unexpected and counterintuitive given the current user interface that it never occured to me that it might have been designed that way.  What's confusing:

- With the default setting of Tool Overlay: Auto, there is no visual indication that the discontiguous brush strokes constitute separate selections (pins) as you make the strokes. After you click Apply, there is still no indication unless you happen to move the mouse into the photo, when you'll see the pins.

- The title of the panel changes to Mask Refinement, and the words Add, Subtract, and Refine all imply you're modifying an existing thing, not creating a new one merely because an additional brush stroke is discontiguous.  Words matter.

- If you make a selection and then use Subtract to cleave it into two more discontiguous parts, that's still counted as a single selection (pin).

- The brush mask works differently -- multiple discontiguous strokes constitute a single brush mask component, not multiple components. The user interface calls both the brush mask and the Remove mask "masks", so it's natural to expect them to work similarly.  Words matter.

The current guidance emphasizes the need to select discontiguous parts of an object, e.g. a person and the wrist and hand draped over another person's shoulder, so that Remove won't try to match the remaining parts.  This encourages users to think of those discontiguous selections as all part of a single Remove operation, and clicking Apply once to generate the initial replacements for the multiple brush strokes encourages that belief. But then the variations only apply to one of the pieces, which is highly confusing.

[John R Ellis]

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

Another confusing behavior: If two brush strokes are close to each other but not touching, LR still considers them a single selection:

 

[John R Ellis]

See this analysis of how the LR Classic selection behavior makes it more likely people will fail to remove disconnected objects successfully:

https://www.lightroomqueen.com/community/threads/removing-disconnected-objects-select-everything-the...

[Rikk Flohr: Photography]

I expect this problem to compound in Wacom Tablet use, where casual discontinuous dabs may generate unexpected results. It would be great to get some customer feedback in that regard. 

[C.Cella]

From what I can tell upon refining if the dabs in the masks are "intersecting" or "close enough" the masks are inserted in the same spot index Masks table.
This is bit like saying that two  sentences in two paragraphs (in a text file) should be saved in two separate files while sentences separated by a period, on the same line, you should be saved the same file.  This does not

make sense.

Anyway aside for the issues @John R Ellis reported there is also another consequence of this "logic".

Steps to reproduce.

1. Paint a first "hole/stroke" (do not create the spot yet)

2. "Refine Add" another "hole/stroke" but not connected to the first one.

So the first set of dabs does not intersect with the second set and neither tis "close enough"

(Screenshot two hole/stroke")

3. Refine Subtract and "join/connect" the two holes.

Now all 3 sets are intersecting  

4. Finally create the Remove.

Result: Two differet Spots were created and they both have a copy of same "subtract" masks.

So it is NOT sufficient to paint connected, intersected,  strokes because Subtractions do not count...probably because the function in place only considers "Add Masks" (i.e masks with MasKValue = 1)

This is for me a case of over-engineering.
Very simply all masks should end up in the same spot WHEN WE REFINE.

I would remove the  "intersect" and "proximity" logic altogether,

Simpler for users, simpler code.

.