Better Scribble-to-Erase

[Encampeded]

I'm an avid scribble-to-erase user, however it seems like it erases every stroke the scribble stroke touches, rather than the area the scribble covers, often leading to tiny dots left over. Could there be an option to erase everything in a bounding box surrounding the scribble, rather than only what the stroke touches?

[Ethran]

I think that is a good point. The future was implemented by @niknal357 , so @niknal357 what do you think about it?

[niknal357]

my initial implementation had the scribble erasing all strokes being erased within a radius of the scribble. the erasing radius scaled with the bounding box of the scribble.

I haven't looked too closely at what the code does now, but I'm pretty sure something is broken there.

in terms of using a bounding box to erase? it might be ok as a temporary solution, but a bounding box is very coarse, and ideally scribble-to-erase just gets better at inferring what you want to erase.

[Encampeded]

If your initial (now broken) implementation would fix the issue, then I'd be happy with that :) I just threw the bounding box out there as an idea.

[Ethran]

@niknal357 I don't think that I changed anything on how it works, it should be as you implemented.

[niknal357]

I'll definitely have a look at the code sometime next week, but what I know for sure is this: the scribble-to-erase (STR) code introduces a couple constants that tweak the sensitivity and aggressiveness of the STR. It would likely be beneficial to either expose the constants to the user in settings directly, or create a couple presets to let the user choose from. I remember testing out the STR with different people and different languages, and everyone had their own preference for the constants.

[Ethran]

It would likely be beneficial to either expose the constants to the user in settings directly, or create a couple presets to let the user choose from.

Usual users won't known how it works, and it can be difficult to test it, as now you have to go settings, change it, go to notebook, test - a lot of clicks to see an effect.

I was thinking about adding small canvas in settings to allow easy testing. I planned it to be mostly for discovering how brushes are hadle in c hardware level library (I have to finally root the device). There are some parameters that can be changed, but I have no idea what they change about stroke style.

But, if there should be some parameters exposed to user, then it would be nice to also allow testing them.

[niknal357]

I looked through the code briefly. Here's what parameters go into scribble detection:

SCRIBBLE_TO_ERASE_GRACE_PERIOD_MS
SCRIBBLE_INTERSECTION_THRESHOLD
MINIMUM_SCRIBBLE_POINTS

along with those explicit constants, there are plenty of magic values and calculations sprinkled throughout the code:

    val scaleFactor = kotlin.math.min(1f + (aspectRatio - 1f) / 2f, 2f) // why did i decide 2 should be the upper bound?
    val strokeSizeForDetection = minDim * 0.15f * scaleFactor // 0.15???

or:

    val expandedBoundingBox = boundingBox.expandBy(strokeSizeForDetection / 2) // this 2 can probably be a tweakable value
    val deletedStrokes = filterStrokesByIntersection(candidateStrokes, expandedBoundingBox)

or:

    val minLengthForScribble = (width + height) * 3 // that 3 is also something that could be configurable

The answer to why anything is the way it is, is because I tweaked it until it felt right.
Increasing the 0.15 in val strokeSizeForDetection = minDim * 0.15f * scaleFactor should make scribbles that are detected as STR attempts will "sweep" a bigger area and reduce the feeling of "it seems like it erases every stroke the scribble stroke touches, rather than the area the scribble covers".

I don't know the best way to expose this to the users though. I am still sceptical of the current detection algorithm, and I'd really like to improve it, but I don't know of any "obvious" solutions that aren't bad for performance.

[Ethran]

I am still sceptical of the current detection algorithm, and I'd really like to improve it, but I don't know of any "obvious" solutions that aren't bad for performance.

As long as we don't try to use all the points for calculation it should be ok performance-wise. If we create a convex envelope, using for example every 10th point of scribble, then it can be good enough. Convexity isn't a good idea here, but probably there exists some algorithms that from noisy points give a polygon that contains them. Maybe cartography?