Brush Speed Sensor Issues

Develop Artists Feedback & Testing
1

So the speed sensor is unusable for the most part. I saw another post about it and finally got around to investigating why this was hoping maybe I could fix it, but it’s complicated…

There’s two issues with it. One, this bug 421098 – Speed control of brush properties has an impractically large ‘Fast’ value., though I couldn’t tell the difference with zoom levels like it mentions.

But it’s easy to fix, the max speed is just too high in the code. I don’t really think it needs to be configurable if most people (we would need people to confirm), can’t get past 50% speed as described by creating a curve like this: https://bugsfiles.kde.org/attachment.cgi?id=130775

Brushes might function a bit different, but they would because of the next issue anyways.

The other issue is the one I stumbled upon here: Trying to recreate a brush in Krita - #6 by AlansArtLog

Here are the Clip Studio strokes for reference:
image

And the same strokes in Krita (with a steep curve to 5%):
Krita Speed 1

For both, I’m using a simple pixel brush, flow disabled, only speed set to opacity, no stabilizers/smoothing. In Clip, min velocity is set to 0. In Krita, opacity to speed curve looks like this in krita (end “curve” % varies):
image

After some investigation, it seems there’s some aggressive smoothing happening in libs\ui\tool\kis_speed_smoother.cpp . It was recently implemented (everything here was tested on nightly/master) that one could set the tablet to use timestamps for speed in the settings (which is not the default, probably due to the warning it carries) and with a really steep slope things are slightly better, but nowhere near Clip.

Clip:

image
image405×353 21.4 KB

Krita (with timestamps, using windows ink just to be sure, though wintab looks the same for me). I can only get the a bit of the correct effect going unreasonably slow. This is with a curve that ends at 10%.
image

I tried fiddling with MAX_TRACKING_TIME and MAX_TRACKING_GAP and decreasing MAX_TRACKING_TIME to 30 seems to help but still feels off:
Krita Speed 3

Now with timestamps off I did get much closer.
This is with alpha = 1 basically negating the smoothing to the previous value and:

#define MAX_TIME_DIFF 300
#define MAX_TRACKING_DISTANCE 30

This also happens to give you more space on the curve, the slope doesn’t have to be as steep, here it’s to 20%. It’s not exactly like Clip (the change feels smoother in clip) but it’s like 95% there. Maybe tinkering with the alpha I might get it closer.

image
image389×410 25.4 KB

So yeah, I will keep investigating (I’ve only mostly fiddled with the parameters available), but was wondering if anyone more familiar with the code had any suggestions. At one point I considered suggesting that the variables for the smoother be exposed, but they’re hardly intuitive even to me and differ depending on the method. Also I feel if some smoothing adjustment slider is made, it makes more sense for it to be a part of some brush smoothing method.

PS: I would like to mention I don’t use Clip, so this is not like I’m used to their brushes or anything. The way the speed is handled just feels really nice. It was also the easiest to test this with. MyPaint supports a speed control but I couldn’t figure out how to disable flow and I couldn’t recreate the brush I had in MyPaint in Krita. But it does have what I would consider to be the correct behavior with the ends darkening where one changes direction / slows down.

2 Likes
2

The configuarablity idea was to maintain compatibility with any brush presets that had previously been created.
Personally, I’d be very surprised if anyone had made a brush preset that used the Speed input because it’s generally unusable in its current form and I’d be happy with a ‘simple’ change to the scaling.

However, it would be a good idea to ask people if they do use Speed in their existing brush presets.

3

Well I did a brush using speed and it works proper up until now. It is my favourite brush current that one.

The scaling does not worry me much more range is better than to less range. What worries me.afyer reading this is the initial detection.

4

@AhabGreybeard I will do a poll re configuration once I get to the bottom of the second issue since fixing it affects the first.

@EyeOdin How does your curve look? Are you able to reach past 50%? If it is physically impossible a large range gives you no benefit and makes it very hard to shape the curve in such a limited area. And what do you mean about the initial detection?

Also although it might change people’s brushes, I would of course not do anything that would not make it possible to fix a brush back. Although I still need to check what the behavior was like before that commit I mentioned.

5

I did a very very light change to the brush like this. But I feel it becomes quite natural for me.

brush_speed
brush_speed718×586 120 KB

The things is in my view is that the graphics chart is so small that any little change can have a big impact, many times I cant even replicate the same brush knowing the values.

6

That’s because no matter how fast you move it in ‘normal circuimstances’, you’re unlikely to get beyond about 20% of maximum speed, even with very fast strokes so you’re limited to the first short part of the curve.
If you ‘go wild’ with strokes, you can get to 50% of maximum speed.

7

having more values to calibrate is better, but having a small space to set the points reduces the space to make a given behavior. As in my hands are too big for this controller kind of thing.

8

I think the physical size of the graph could be about 50% larger so you may want to start a new feature request topic for that.

9

I have. No luck though.

10

@EyeOdin have you tried making a graph like https://bugsfiles.kde.org/attachment.cgi?id=130775 and reaching it?

Is it only the speed graph you find hard to adjust or others too?

I don’t want to get too off topic, but feel free to link me to your request, I can look into making the graph bigger (currently it’s 200px I believe, I think 300px would be nice and better fill the area). I was already working on some commits to make the handles easier to grab/distinguish and possibly add arrow key shortcuts to move the points. Size looks simple enough to change, possibly make configurable.

11

That curve seems really bad for speed. my brush does not paint like that.

Speed is the hardest one I guess. the rotation is also kinda hard because of loops and offsets.
But I have issues even with pressure. I have 3 brushes that are virtually similar in curves but with very different results.

12

That curve seems really bad for speed. my brush does not paint like that.

I’m not suggesting it as a curve to use. Maybe I should have explained better.

It’s a test curve to see if you can reach the speed the line is drawn at to test the max speed you can physically reach. Going as fast as you can, can you make a mark with that curve? If yes, move it to the right until you can’t, if no, move it left until you can. That % is the max speed you can reach. Everything to the right of that on the graph has no effect on your brush. For most people it’s around 50%. For example, on your graph, actually the green bit is likely to be the only part affecting the brush, the red is just limiting your space.

image

I do not need to know the % now, I will do a poll later. It’s just to illustrate the point about why more values are not good in this case.

Does that make more sense?

13

25% comfortable fast stroke
75% barely any result but you need to move fast like throwing a ball. over expends the stylus nib.

I was only able to use it up to 75%.

1 Like
14

I’m sorry for derailing your thread a bit :sweat_smile: but if you’re open to suggestions for making improvements to the curve graphs, I made a feature request thread a few months ago about adding improvements to the softness curve graph.

And a additional button to make the graph a straight line like this example

image
image1119×967 38.6 KB

15

@fizzyflower I think dragging the graph vertices to the very top and adjusting the “strength” slider should get the same result as a purely horizontal graph.

1 Like
16

Hi, @all!

As far as I can tell from your discussion, the problem is that the speed scale is hardcoded in the code. Therefore, depending on your tablet size and screen size you need to fiddle with the curve in a non-intuitive way. That also explains why different users suggest different curves (their tablets have different physical size).

So, the formula of the brush speed configuration involves the following variables:

  1. The physical size of the tablet. The bigger your tablet is, the faster you need to move your stylus to get the same “brush speed” value.

  2. The pixel resolution of your display (and HiDPI scaling, if applicable). The less pixels you have in your screen, the faster you need to move your stylus to get the same “brush speed” value.

  3. The speed is calculated in the “view” coordinates, not in the “image” coordinates. Therefore, the speed of your cursor on the physical display screen doesn’t depend on on the zoom level of the image. I might lead to a bit non-intuitive effects sometimes when you do multiple sequential strokes on different zoom levels.

Possible solutions:

  1. [what I wanted to implement one day] Make auto-calculated formula that takes all the three variables into account and guarantees that the speed sensor is “portable” between different PCs.

  2. [workaround approach] Just add a user option in the settings dialog that lets the user to configure the speed scaling value to his particular hardware. This approach has an obvious drawback: the brush presets will not be “portable”. That is, the user will have to tweak brush settings to adapt them to his/her hardware.

3 Likes
17

@AlansArtLog @dkazakov

Would it be possible (or desirable) to make a test build, probably based on 4.4.7, with the drawn/input speed scaled up by a factor of 4?

(I suggest 4 because even 25% of the current maximum speed is difficult to achieve with comfort and control. I realise that’s my personal limitation/opinion but it would be an improvement on how it is right now.)

That way, more people could experiment with speed control of brushes to see if they can make brush strokes that look useful and feel comfortable.
That would give wider ranging feedback of what changes and improvements would be needed to make it generally useful.

18

Hi, all!

Here is a testing package for Windows:

There is a special slider for max stylus speed in the tablet settings. You don’t need to restart Krita, its effect is instanteous.

2 Likes
19

Hi @dkazakov , Thank you for this :slight_smile:

I made a brush preset that had a very simple Size vs Speed characteristic where Size started at maximum and went in a straight line down to zero at the ‘Fast’ end.

I was able to adjust the Max Stylus Speed to give me ‘reasonably useful’ speed response.
Using the Tablet driver timestamps has a significant effect on scaling and I’m using Wintab.

Here are some test strokes with timestamps off and speed set to 5 px/ms:

First
First2048×2048 119 KB

As you can see above, I was able to produce the entire speed response range and I didn’t have to try very hard to do that.

With Tablet driver timestamps on, I had to increase the speed setting to 10 px/ms to get behaviour that felt the same as in the previous example:

Second
Second2048×2048 122 KB

Sometimes, there was a blob at the start of the stroke and sometimes at the end (not shown in the example above).
Once it didn’t want to draw and gave just a blob, as seen above.

After the end of the stroke, the cursor size did not go back up to maximum until I brought the stylus close to the tablet and then it changed to maximum slowly.
Because of this, I couldn’t do repeated strokes quickly, one after another. I had to wait for the cursor size to be restored to minimum speed.

It’s a very good start and it lets me use the full speed range in a way that’s practical and comfortable :slight_smile:

However, what feels comfortable and reasonable for me may not be something that suits other people.

20

I’ve been playing around with the settings a bit and it seems that now what I’m looking for can be achieved.

image
image1113×732 60.5 KB

image
image869×739 89.7 KB