When using a brush with low hardness, the soft edge extends way beyond the brush preview

[HuniSenpai]

Here's a video exemplifying what i'm experiencing, and it's super frustrating when I need to do a shadow by hand, for example:

I'm okay if it extends slightly beyond the brush circle, but this is way too much. I have to hold my brush a couple hundred pixels away from the edge just so it'll land where I want it to.

 

This doesn't happen if I use a 100% hardness. In fact, the preview circle changes size as I change hardness! The only time where the preview circle size is correct is when the hardness is 100%.

 

Moreover, the actual size of the circle changes significantly when changing hardness, which I guess is why you're trying to compensate by changing the preview circle (but the preview circle is actually still not quite right). Both of these are at 1817 px size brush, but the one on the left has 0% hardness, and the one on the right has 100%. Look at the size difference (the guides represent the extreme outermost bounds of the layers -- I used Affinity Photo's transform controls to get the actual size, instead of eyeballing it):

I'm guessing this is because i'm just using 8 bits per channel, and, as such, the the steps cut off early? 

In short, I want the preview to show the absolute outermost bounds of the brushstroke, not just where its most intense or something strange like that. Is the preview drawing the circle where the brush is 50% alpha or something?  I'm not sure.

 

[Chris B]

Hey HuniSenpai,

I think this is pretty normal if you have 100% Accumulation and/or Flow. If you turn down the Flow on the context toolbar, you should be able to find the balance you need.

[HuniSenpai]

2 hours ago, Chris B said:

Hey HuniSenpai,

I think this is pretty normal if you have 100% Accumulation and/or Flow. If you turn down the Flow on the context toolbar, you should be able to find the balance you need.

Got it.

One question, what if you define the outer boundary as being the absolute limit if you jitter the brush slightly in the canvas, roughly in place? Because it seems to require some movement to start flowing.

Also, I did some testing, and the preview circle is in fact incorrect. I did a brush size of 1381px, and the preview circle was actually about 1110px in diameter (dunno why they're different lol).

Moving on, I decided to test the actual size depending on the flow. The results suggest that flow increases logarithmically, in a somewhat predictable manner. What I did for my very non-scientific testing is jiggle my mouse very slightly to get the ink to flow, and I did that for a while until the very outer edge stopped growing. About 30 seconds for each circle. I then measured the size using guides and noting down x coordinates and by using the transform tool to find the very edge of each circle. I did this test for 1% flow, 25%, 50%, 75%, and 100%. Here is a graph of actual size plotted against flow %. The horizontal red line represents the actual size of the preview circle that I measured. You'll see that, as the flow approaches 1%, the preview circle becomes accurate. Here's the graph: 

 

The actual brush size, according to Affinity Photo, was 1381px. I'm not certain where the program gets this number from, but I have a guess that it's just doing a simple average of the maximum brush size and the minimum brush size, which corresponds with 100% and 1% flow rates, respectively.

So the size at 100% flow was 1680px, and the size at 1% flow was 1112px. The average of those two ([1680 + 1112] / 2) is 1395px, which is pretty close to Affinity Photo's size of 1381px.

However, this is not a good way to do things. Because the graph is logarithmic, not linear, the size hangs around the 1600s and high 1500s most of the time, and this 1381px size is only accurate at about flow 14.23% (in this case). Not at around 50% flow, like you'd intuitively think. You can't just take the average of the two range extremes on a logarithmic graph in order to get the average value. You can do that with linear functions, but not with other types.

The appropriate way is to take the integral of this function from 1% to 100% (area under curve), and then multiply that by 1 / (100 - 1). That will give you the true average value of the function -- it's called the Mean Value Theorem.  Since I don't have access to the function (i'm sure it's written somewhere in the code, though, and if it's not, you can take a lot of data points by hand and interpolate), I will do an approximation. I used the trapezoidal rule in tandem with the mean value theorem to find the approximate average of this function. The actual average size across all of these different flow rate samples is about 1598px, and not 1381px. 

All of this is pointless though. All of this feels like a work around to the problem.

The real solution is to have an outer circle, outside of the current preview one, that shows the very farthest that the brush stroke can land if you were to theoretically keep wiggling the brush back and forth forever. The size of this outermost circle would be dictated by the above graph, brush size, and by the hardness. You'd need to come up with a multivariable function that includes hardness, brush size, and flow, but it can absolutely be done. If you can't (it's understandably difficult to do) you can just do some sample points and interpolate, it'll be accurate enough. And, at the very least, something is better than nothing. Might be hard to interpolate a multi-variable function though. 

P.S I try not to use very low flow because of what seems to be an oversight; a very low flow only seems to use a few different value levels, and it results in a posterized effect when I do enough painting with that brush. I understand why you did this-- it's because these steps should be hard to notice if you're doing subtle brush strokes, as I imagine is intended with a low flow brush. However, if you go slowly with the brush and do a lot of brush strokes, you begin to see these steps. So, as of now, I have to do 100% flow for the best image quality.

So, maybe we can fix this problem if we can't fix the flow-preview issue? This would improve the usability of lower flow rates.