Implementing Magnetic Lasso for Krita

[Boudewijn Rempt]

On woensdag 20 maart 2019 05:10:45 CET Kuntal Majumder wrote:
> Hi
> 
> So, I was going through the code of the different selection tools to try
> understand how can I implement or better say re-implement the magnetic
> lasso. I found out there are a total of three ways of how the selection
> tools are implemented,
> 
> Outline, Similar and Contagious , directly inherit from KisToolSelect
> and implement the functionality inside one class.
> 
> Elliptic, Rectangular and Polygonal, create a local tool which inherits
> a base tool like ellipse, rectangle or polygon and then the local tool
> is further inherited by KisSelectToolBase, which is then used to
> implement the corresponding selection tool.
> 
> Path selection tool rather follows a different implementation, starts
> the same by creating a local tool which inherits the KoCreatePathTool,
> which is then passed down to the KisDelegatedTool with local tool as
> delgate, then there is a wrapper around the delegated tool. The wrapper
> gets inherited by KisSelectToolBase, used to implement the corresponding
> selection tool just like the previous one.

The question here is: does the magnetic selection tool create a bezier path that can be edited, or not? If there's an editable path, then it probably should be more like the path selection tool, if not, like outline/similar/contiguous. The mix-ins from the shape-based selection tools aren't too relevant.

> The third approach seems a little bit buggy or as discussed with Boud is
> kind of broken, upon changing the raw casts into dynamic_casts the tool
> fails to activate and ends up crashing the whole program.

I'm not sure I remember that :-)

> The previous attempt to restore the Magnetic Lasso followed the third
> approach, which I don't think _if_ broken should be followed. So taking
> the fact the tool will work the following way,
> 
>  1. User clicks on the canvas creating an anchor and moves the mouse
>  2. We draw a line from the anchor to the current mouse position
>  3. Add radius as the width of that line, getting the area (A) that we
> are going to search for the edge
>  4. Run our first approximation function over A to get the probable edges
>  5. Start searching for the required edge by scanning across the width
> of A, evaluating the possible edge points by the distance from the last
> found edge point and deviation from the center line.
>  6. Do the search and evaluate process until we hit the cursor or hit
> the maximum distance (frequency) between each anchor, upon which we
> place another anchor automatically and restart the process.
> 
> //Note : Need to add some mock-ups for it, I guess

Yes.

> Technically the anchors in this case wont be the same as nodes in a
> bezier/polygon curve, they will just act as a checkpoints, if the user
> wants he/she can remove the checkpoints with right click and redo the
> edge. Hence I am not sure how to go on and implement the tool, I mean
> which way should I pick up from the above mentioned 3 ways?

I am sure that this is a place where all the code we have for creating and editing paths should be reused.


> Also after a quick run around papers on edge detection algorithms based
> on fuzzy logic, I am taking a look over some papers around scan-line
> based algorithms to figure out edges. Added to that, as discussed
> here[1], the already implemented LoG along with a A* search could also
> work, though I don't know how would that fare in the long run?

I think the LoG approach would work better than scanlines, but that's just a hunch. Scanline-based approaches have a tendency to leak.

 
> Here is my proposal [WIP]
> https://docs.google.com/document/d/1AF1U1Qb8JKS6Ky8pC_daDgeMDBrzVU8C7ulK_-0kg28/edit?usp=sharing




-- 
https://www.krita.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20190322/5357b851/attachment.sig>