Need help with user testing: brush rotation changed to work with pressure in range -180...180

Both the appimage and the zip (portable version for Windows) are here:

The patchset changes the way how Brush Rotation option works, when the user activates any “pressure-like” sensor, that is “Pressure”, “Distance”, “Tilt Elevation” and so on. Bascially, it is a fix for bug 412111.

Now, when the user connects Pressure sensor to Rotation option, Pressure, instead of rotating the brush in range [0, 360] degrees, rotates the brush around its current angle in range [-180, 180].

Test Plan

  1. Create an asymmetrical brush, e.g. use predefined “spike_eroded” tip (with angle set to 270 deg).
  2. Activate Rotation and try the following modes:
  • Pressure
  • Tilt Direction
  • Rotation (needs Artpen)
  • Drawing Angle
  • Drawing Angle + Pressure (set strength to 30% to see the effect better)
  1. For every brush mode, try activate the following canvas transformations:
  • Rotate canvas (keys ‘4’, ‘5’ and ‘6’)
  • Mirror canvas (key ‘M’)
  1. The brush behavior should look “sane” and “expected” :slight_smile: Rotation, Tilt Direction and Drawing Angle should rotate the brush absolutely, not linked to the canvas transformations. Pressure should offset the rotation relative to its “base angle”.
  2. Repeat (at least some of) the steps for Hue option. It should behave like Rotation.

I’ve just downloaded the appimage and noticed something strange.
There is either a basic error or I have a basic misunderstanding of what is supposed to happen:

In the canvas image below here, the top row is a line of ‘pointers’ that were painted with no rotation enabled.
The middle row is pointers with rotation enabled and only Fuzzy Dab turned on with a flat line curve at the zero degrees level. The bottom row is the same as the middle row but with the Fuzzy Dab transfer being a flat line from about -40 degrees to + 40 degrees.

This is the brush editor for the bottom row as described above:

The top row is as I expect, with zero rotation of the brush tip file image.
I expected the middle row to be the same since Rotation is set to Fuzzy Dab but with a flat transfer characteristic giving 0 degrees variation. There is an addition of 180 degrees.

The bottom row does have the 40 degree random variation but it’s about an additional offset of 180 degrees.

It’s as if the right side angle scale actually runs from 0 to 360 and not -180 to +180 as shown. This is the same behaviour as 4.2.8.

It’s the same for pressure variation.

EDIT: Additional: In 4.2.8, pressure increase gives more clockwise rotation of the brush tip image. In the Appimage provided, increasing pressure gives more anticlockwise rotation.
There may be a good argument for this in terms of ‘standard’ direction for measuring angles of rotation.

Hi, @AhabGreybeard!

Yes, the second row is expected to be flipped relative to the default position. That is a bug that I feel a bit hesitant about fixing it, because quite a lot of existing user brushes will break because of it (unless we’ll invent something complicated). It was the default behavior for ages.

The third row works as expected. It rotates the brush to the left and to the right relative to the second row. The implementation in 4.9 would just rotate it into clockwise direction relative to the second row. This one rotates into both directions.

You’re quite right about breaking customary use of existing brushes - that always annoys people for good reason. I suppose the thing is that it does what it does and you can use what it does to get more or less any effect you want.
I’ll keep looking at it and let you know if I notice anything apart from what I’ve mentioned.
What do you think of my edited additional observation about direction of rotation with increasing pressure, above?

Hi, @AhabGreybeard!

Yes, I reversed direction of the pressure-based rotation to be more conformant with the way how “Brush->Angle” option works. Is it a problem?

No, it’s not a problem. I just wondered about it and as far as I remember then an increasing positive angle corresponds to increasing anticlockwise rotation in geometry anyway.

I’ve had a look at Hue control and it’s fine (as far as I can test) except for when Drawing Angle is used as a control input. Using the same transfer curve/line as I did in the first post, I made Hue vary according to Fuzzy Dab then Drawing Angle then Distance. As you can see from the image there is something wrong with the control by Drawing Angle:

A 180 degree offset has been added when Drawing Angle is used as a control input.
Also, note the discontinuity at the bottom of the ‘circle’ where there is a sudden hue shift. I’m not sure if this is unavoidable or not depending on where exactly it happens.

This 180 degreee offset is also present in 4.2.8 so it’s been there a long time.

Looking at Drawing Angle used to control the Rotation parameter with the testing appimage, I see similar anomalies due to this and also there is an apparent discontinuity in the transfer characteristics.

If you draw a horizontal line from left to right, what is the Drawing Angle of that line? What about a vertical line from top to bottom?

I can prepare some illustrative images eventually if you need more information about this.

My tablet only provides Pressure output, not Tilt or Rotation output so you’ll need someone else to help with testing for those control inputs.
I haven’t tried looking at canvas rotation/mirror yet.

Hi, @AhabGreybeard!

Could you please test Hue+Drawing Angle sensor on this package? I have fixed the problem you found:

1 Like

Hi @dkazakov ,

The Hue controlled by Drawing Angle now works properly with no offset :slight_smile:

I can see that a horizontal line drawn from left to right has a drawing angle of 0 degrees and a vertical line drawn from top to bottom has a drawing angle of 90 degrees - and so on around the circle.
This is actually the opposite convention to ‘increasing positive angle leads to increasing anticlockwise rotation’ as far as i can tell from a quick geometric diagram I just did.

Either way, the most important thing would be to not break any existing presets that rely on whatver is already done.

Ok, I see what’s happening: Direction of drawing angle leads to correct rotation direction of the brush tip because of the output scaling on the transfer graph:

However, Pressure control of Rotation does not correspond to the transfer graph with the default positive straight line characteristic:

“Zero” rotation is actually what you call 180deg on your graph. You can get it by disabling “Enable Pen Settings” checkbox. This rotation is 180deg rotated against what you see on the brush preview (that is an “unfixable” bug we discussed above). Default straight curve maps pressure range 0…1 to rotations -180…+180. Therefore, at the endpoints of you image you see “zero” rotation flipped to 180deg, which is exactly what it is supposed to do.

So, the problem is in non-obvious “zero” rotation, but I cannot fix it without breaking existing presets.

Yes, it’s a ‘cosmetic anomaly’ and compatibility with existing presets is important.

Bumping this thread for more visibility

Here are the latest testing packages:

1 Like

Using the latest testing package krita-4.3.0-prealpha-9a24cf0-x86_64.appimage, this self reports as (git 2b7fb7d).

For canvas rotation and canvas mirror, the brush rotation is not affected by canvas rotation and is unchanged relative to the screen.

For brush rotation controlled by pressure and brush rotation controlled by drawing angle, the results are as expected.
For brush rotation controlled by pressure and drawing angle, the results are puzzling/confusing (for me they are but I may be overthinking it).
Here is an image showing those three conditions for a straight line (0,0 to 1,1) transfer curve on both pressure and drawing angle:

For the green one (pressure= 100% and drawing angle variation) I expected it to be the same as the red one (drawing angle only) since pressure = 100% maps to a rotation of 0 (or 360) alone.
They are different for both multiplication and addition combining modes.
(I didn’t look at any other combining modes.)
.-.-.-.-.-.-.-.-.-.-.-.-.

For hue controlled by pressure and/or drawing angle then pressure alone or drawing angle alone gives expected results with a straight line transfer between -90 degrees hue shift and +90 degrees hue shift with green as the selected colour, giving an orange to blue range.

When both pressure = 100% and drawing angle variable control are combined, with multiplication or addition, the result has an initial 180 degree offset and a range of about -180 to +180 degrees.**
I can’t figure out why this is but maybe I need to examine it gradually, piece by piece at different input levels.
(There are start stroke and end stroke glitches as might be expected.)
.-.-.-.-.-.-.-.-.-.-.-.-

As a minor note, there is a discontinuity about the ends of the transfer curve when drawing angle = 0 because any minor stroke variations will cause the detected angle to suddenly jump to slightly less than 360 degrees. This is illustrated below:

Any other parameter controlled by drawing angle (and probably pen rotation) would show the same discontinuity.
This is unavoidable unless the transfer curve is adjusted to have the same output value at both extremes of the input control range.

Hi, @AhabGreybeard!

That is exactly what the patch fixes: now pressure maps rotation to the range -180…+180deg. It means that when you draw with 100% pressure, the brush will be rotated by 180 deg. This range (-180…180) is drawn in the curve’s Y axis. Afair, that was the main problem of bug https://bugs.kde.org/show_bug.cgi?id=412111

I think it is the same. When you are at 0 pressure, your Hue is offset by -180 deg. When your pressure is 100%, then Hue is +180 deg. That is what we promise in the GUI

A good point. I don’t really know if we can fix that, though I’ll think about it.

Hi, @AhabGreybeard!

The only solution I see for the discontinuity is to make the curve like that:

We can technically implement some easy switch for that, but the effect will be like this curve anyway.

Hi @dkazakov
I intended that discontinuity observation as a minor thing in case anyone wondered about it and I think it’s up to people to make their own curve adjustments if the discontinuity bothers them.

The rest of it, the 180 degree offset is to maintain compatibility with existing brush presets which would behave differently (and annoy and confuse people) if changes were made to it.

Is it safe to merge these fixes to master, how do you think? I don’t think we have any regressions left, right?