[RFC] Mask resizing by insetting/offsetting

Dear darktablers,

Whenever I draw a mask using a path, I generally draw the mask inside the subject, and then use path and mask feathering to extend the mask outwards to achieve a smooth transition.

Now, thanks to @anry’s work we have a great tool to streamline path drawing. However, AI masks sit at the boundary of the object. In order to use feathering effectively, the masks need to be shrunk a bit so that they sit inside the subject area. Unfortunately, the current resizing algorithm for paths resizes them towards the centroid of the shape, which for non trivial masks causes the mask to lose alignment with the features of the subject.

In a couple of discussions, including this one it has been suggested that mask resizing should rather work by inwards offsetting (i.e., insetting), i.e., like feathering works, only the other direction.

After spending some time iterating on the algorithm, I have a prototype that does exactly that and that is quite stable, and I would appreciate some feedback on how to best move forward before preparing a PR (for 5.8, as 5.6 is already in feature freeze).

See below for a comparison between resizing in master (left) vs. the experimental branch (right).

The current implementation replaces the resize behavior, however since darktable is all about flexibility I think that it would be better to offer both behaviours, and let users decide on a case-by-case basis.

So, my questions for the community are:

  1. Is there a general agreement (at least among AI mask users) that this is a desirable thing to have?

  2. Does it make sense to keep both resizing methods?

  3. If the answer to (2) is yes, how should one choose which algorithm to use?

    1. With an option in preferences - applies to all paths drawn
    2. With a control on the bottom panel - to easily toggle on/off while editing
    3. With a modifier combination while resizing the mask (applies on a per-resize operation basis)
    4. Something else?

Thanks in advance for your feedback and comments.

@Pascal_Obry @hannoschwalm any thoughts?

8 Likes

Thanks for your post, but I struggle to see any advantage towards the centroid of the shape. That may be my bad, but an implementation using offset seems the only option I can imagine using. I am happy to be corrected if I have missed understanding an advantage of the centroid method.

1 Like

Check the video, the resizing behavior is completely different. On the right, the resized shape is just being offset towards the inside.

This is using an offset, which you control by scrolling. You mean, one should be able to specify the absolute value of the offset instead of scrolling? That can certainly be added.

When I use the select by color tool in GIMP to select a blue sky or green screen I have found reducing selection by one or two pixels very useful. Typing in a specific pixel number would be good if it is practical, but scrolling is still fine if not.

BTW, thanks for the great contributions you are making to DT.

4 Likes

Agreed! How do you envision the UI?

You are the man of vision, but I wonder if just a slider like the feathering slider but called offset would work. Then offset could default to zero but offer both negative and positive numbers.

2 Likes

For manually drawn paths that’s most likely the case. I might have missed the part where it is explained if this proposal would be implemented for all kind of masks. If this is the case, I am not sure if the insetting preserves the proportion of geometric shapes (e.g. ellipses or compositions of other regular shapes). I am not sure that’s the opposite is true either, just to be clear. Is this “insetting” a shrinkage along the orthogonal direction to the boundary of the mask, at each point?

2 Likes

Easentially yes, plus loop removal, node merging and some more gritty details.

And yes, it is only relevant for paths. Shapes re not affected.

3 Likes

I just checked and drew a mask with the path tool and the scroll wheel results in the desired behavior of just making the mask bigger or smaller, but this is not the case with AI masks and I feel it needs to be.

Thanks @Masterpiga for your work on this.

Nitpick. AI masks are just normal paths. The difference is between paths with protrusions vs. paths without protrusions. In the latter case, centroid resizing generally works well. In the former case it does not produce the expected behaviour. The protrusions of the mask easily lose alignment with those in the subject, making the mask by and large useless after resizing.

This is shown in the video in the OP, on the left. See how the part of the mask tracing the legs of the elephant is no longer aligned with the legs after resizing.

As it happens, most real world subjects do have protrusions (e.g., limbs), and hence the resizing algorithm is especially relevant for AI masks, which are commonly used to trace such subjects.

3 Likes

@Masterpiga … yes looks quite nice for the start .

Hi Daniele,
This is a feature I have been wanting since well before AI masking came along. I’m very happy to see it being worked on.
So for your questions:

  1. Yes, I would love to see this.
  2. Yes. I sometimes reuse masks over a series of images where the masked subject changes in size (different distance or focal length). In this case the old method makes more sense.
  3. I would prefer a modifier.

I also sometimes would like to be able to rotate a path, and I think this might be a good opportunity to suggest it. I have sometimes had highly irregullar shapes that I have copied from a landscape oriented image to a portrait oriented one. Then the rotation of the shape is 90 degrees off and I have to move all the points or redraw the shape. Currently only ellipses and gradients can be rotated.

4 Likes

Ah, yes, totally! Not related to this, but certainly something that I miss too. Eapecially in the retouch module, sometimes I wish I could rotate the source or target shape independently.

3 Likes

When I made this suggestion recently, I totally failed to think about the question, which direction is “in?” Now that I see you have solved this problem, I’m amazed.

Can it be as simple as taking adjacent nodes and extending a perpendicular? Probably not. But I’m no mathematician: quite the dumbo at such things.

Thank you very much for picking up this idea of shape-based resizing!

Yes!!! :smiley:

Required for backward compatibility? It’s nice to have the choice?

Apply to selected/active shape. .

Yes.

2 Likes

This is a very nice concept and would help enormously. Can this be implemented with an ability to move a single path node, eg. hover over a node and then apply an offset?

It would also be great to do that with feathering as well.

  1. Even as a someone who cant be bothered with AI masking, this would be a very welcome addition.

  2. If the overhead wrt to code upkeep isnt an issue, I say keep both methods. Also, there may be situations where you do not want this new version depending on implementation details.

  3. If we cannot have a per-mask choice, then putting the toggle in preferences/settings seems the most logical. If we do have the ability to change on a per-mask basis, I would place the toggle in either the Mask Manager or the Mask Refinement areas. Another toggle in the bottom panel would be the last place I would put it given how often newer uses have issues there.

Out of curiosity: If resizing smaller, is there something in place to keep edges from overlapping? IE an hour-glass shape with narrow center gets made smaller…do the innermost points jump sides to create a bulge? Or do they get removed, leaving us with too unconnected triangles? Or do they just get infinitely closer?

1 Like

To me the current mask-path behavior is a bug and implemented this way because it was faster. But if you take into account the circle and ellipse it already resize by insetting. That being said.

  1. Yes
  2. No, I’ll keep the new one, I don’t have a scenario for current behavior that has annoyed me many times since years of using dt.
  3. The answer is no to me :slight_smile:
1 Like

You can type a % of the current size, but in pixel it will be difficult.

I second that. A big step in the right direction.