Doublonmousse
commented
5 days ago What's your pen hardware ? I reckon this does affect smoothing somewhat (in particular higher refresh rates may increase jitter and maybe the curved mode is actually less good at higher pen input rates).
I guess you've done a round of different solution you could try. If you have found one in particular that feels nice for some reason I'm interested to know which one.
After looking at what you listed, I have a few notes and a few ideas, but nothing definitive I want to do.
-
What is done in lorien seems similar to the second mode for path modelling (curved in the path modelling options) where we use the positions from the current event + 2-3 before and interpolate a curve. One thing that's also added in lorien here is to lessen the number of events if they're too close to one another. That's a basic way to compress a little filesizes and maybe jitter a little bit.
-
There are a few other approaches that I don't think are applicable as is (the string pull method for example or moving average without some catchup)
As thing currently stand, the settings for the pen modeler are not tunable (mass and spring constants cannot be changed) so maybe that could be a first step.
I have a few other ideas I want to try
- catch up + prediction : the pen modeler always has a part of the stroke that's final and another that's temporary and is used to play catch up to the pen position. But it's only catchup (and you could also extend it by a little bit as the last event will be ever slightly behind the real pen position). Not really helping with smoothing though.
- Kalman smoother : try to fit the pen input to a dynamical system that's more or less smooth and use error estimate to consider the start of the stroke up to a point to be final (and the rest is not, waits for the next input event, recompute the best estimate
- Maybe some other method ? (doing ML to find a good model ?)
In any case I need to collect some raw data + experiment a little and prototype/test it before deciding what's the best way to improve the model.
I still want the end model not to force the user to write slowly (that's kinda the case on average method without catch up), and I also want to check where the end stroke ends up compared to the raw input data stream. There's other objectives that can end up here as well (like doing some compression on the fly to reduce file sizes).
I'm pretty sure the modeler + app characteristics (input delay, fps) make it so that it's possible to deduce what app is used only from how the handwriting looks.
Swexti
Please submit only one feature request in one issue!
If it is UI/UX related, don't post how a single aspect of the UI should be changed, rather in which use-case you felt the UI is lacking or should be improved.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
The current path modeling is very good, but nonetheless, it picks up on my shaky hands and my handwriting gets unreadable. A way to stabilize or smooth the pen strokes as you are writing or drawing would be helpful to create cleaner handwriting.
Describe the solution you'd like
A clear and concise description of what you want to happen.
That strokes get smoothed as you are drawing, and that there are controls to change how much smoothing is applied.
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Lazy Nezumi Pro, external application, costs money. Haven't been able to get it working. Silky Shark, free alternative. Also have not been able to get it working.
Additional context
Add any other context or screenshots about the feature request here.
See opentoonz #81 for examples of pen stabilization and potential ways to implement. This was implemented as cubic Bezier curves in Lorien (lorien #89).
Not related to #531 as I'm looking for stabilization while writing, not after the fact.