Resize with [ or ] how is it controlled?

[uncle808us]

Pick a brush size 4 px tap  ]  larger three times the brush is now 6.1 px why not 7? 

Tap  [   smaller three times size now 3.7 px.

WTF?

Why would it not be 4 px where it started?

How is this controlled? Can it be controlled?

[- S -]

I thought I was the only one that this annoyed.   :)

 

Even going to Edit > Preferences > User Interface > 'Decimal Places for Unit Types', and setting it to 0 decimal places for pixels, the bracket keys still don't change brush size by 1 px every key press, therefore I have been unable to find a work-a-round so far.

 

So I too would be interested in knowing as well.

[uncle808us]

Oh yea it's annoying.  

[HVDB Photography]

Works correct in 1.5.2.66 (Beta)

But, from 9, adding will increase by more than an integer !!!

[uncle808us]

I'm using Ver 1.5.2 Affinity Photo.

[HVDB Photography]

I'm a Windows guy ...

[Alfred]

 

Works correct in 1.5.2.66 (Beta)

But, from 9, adding will increase by more than an integer !!!

 

 

In Affinity Designer 1.5.3.66 beta on Windows, starting with a 4px brush and going up by four steps and then back down again gives me this sequence of pixel sizes: 4.6, 5.3, 6.1, 7, 5.9, 5, 4.3, 3.6.

[LilleG]

If you start with a one-pixel brush, it's easy to see the sequence used, harder to figure out the reasoning behind it.

1 - 1.2 - 1.3 - 1.5 - 1.7 - 2  gives you a sequence of adding .1 - .2 - .3 - .4 but then it reverts to .3 to even out at 2 pixels. 

From 2 pixels to 4 changes the pattern a bit.  2 - 2.3 - 2.7 - 3.1 - 3.5 - 4 adds .3 - .4. - .4 - .4 then goes to .5 for an even 4 pixels.

 

Math was never my strong suit so I may be overlooking something obvious.

[dutchshader]

Looks like every step is + or - 15%

[Alfred]

Looks like every step is + or - 15%

 

That's what I thought when I saw the sequence 4, 4.6, 5.3, 6.1, 7, which is +15% each time. At first it didn't seem to explain the bigger steps on the way back down, but I can now see that 85% (i.e. 100% -15%) gives me the descending sequence 7, 5.9, 5, 4.3, 3.6 that I observed earlier.

[dutchshader]

on the way down it is also 15%. 

[Alfred]

On the way up, the size is increased by a factor of 115%, or 1.15. On the way down, a factor of 87% (i.e. 0.87, which is the inverse of 1.15) should be applied, but the factor actually applied is only 85%, so the sizes get too small.

[dutchshader]

on the way down, starting at 7, i get 5.95. 7-15%=5.95.  

[Alfred]

on the way down, starting at 7, i get 5.95. 7-15%=5.95.  

 

That's correct, but my point is that -15% is too much. Having gone up from 6.1 to 7 (i.e. +15%) you should come down from 7 to 6.1 (i.e. -13%).

[dutchshader]

That's correct, but my point is that -15% is too much. Having gone up from 6.1 to 7 (i.e. +15%) you should come down from 7 to 6.1 (i.e. -13%).

Good point ☺, guess i misread your other post.

[R C-R]

My calculator says the inverse of 1.15 is approximately 0.8695652174, so depending on the internal precision of the app & the number of steps applied, it is possible stepping up & then down may not ever return the size to exactly its original value.  

[JimmyJack]

Affinity uses 20 decimal places internally (as referenced here. Sorry for the out of context quote MEB, but its seems like a straightforward

fact wherever it's placed).

 

It should be perfect going up and down. They're just using the wrong formula!

 

I love numbers... This reminds me of the very simple investing adage. If you lose 50% value in something what return do you need to get back to where you started? Most people quickly answer "50%!!", when, of course, the answer is 100%. 

[R C-R]

It should be perfect going up and down.

I am not sure there really is any practical reason it should be "perfect" in this way, but if that is what users want, what formula or algorithm do you think would do that?

[LilleG]

I have no idea what algorithm would be needed but the practical use for it being "perfect" would be to accurately return to a line that you wanted to only briefly enlarge.

[R C-R]

I have no idea what algorithm would be needed but the practical use for it being "perfect" would be to accurately return to a line that you wanted to only briefly enlarge.

I thought about that but I am not sure how practical it would be if you have tapped the increment/decrement key more than a few times, have to remember how many times you have done that, & be careful to tap the decrement/increment key exactly that same number of times to go back to the original value.

 

It seems to me it would usually be simpler to just remember the one initial value & reenter it in the field, or use a saved brush to choose among various commonly used brush sizes.

[LilleG]

I agree that it would only be useful for small changes of a few taps.  And I'm not sure that it would be needed that often anyway.  It does seem rather sloppy though that going back down the same number of steps won't return you to your starting place.

[R C-R]

It is pretty much a non-issue for me since I almost always use the keys held down in repeat mode & just gauge the brush's effective size visually, taking into consideration how the hardness & other brush settings will contribute to that. That is inherently a rather sloppy, inexact process but it works for me.

 

When I care about accuracy (which is not that often) I usually set at least the size & hardness values directly in the Context toolbar. That way, I don't have to think about rounding errors like if my "12.7 px" brush is really 12.6777 px or some other value.

[- S -]

It does seem rather sloppy though that going back down the same number of steps won't return you to your starting place.

 

Yeah, and I see no point having the brush size to a fraction of a pixel either.  It reminds me of FOSS Linux software where they do things like make DPI to two decimal places just because they can.  Not sure why, but it drives me nuts.

[R C-R]

Yeah, and I see no point having the brush size to a fraction of a pixel either.

Not even if you consider hardness or any other brush setting that might cause brush size to work on other than whole pixel boundaries?

[- S -]

Not even if you consider hardness or any other brush setting that might cause brush size to work on other than whole pixel boundaries?

 

It can do what it wants behind the scenes.  I would just rather select a 5px brush.  Then pressing the bracket key moves it to a 6px brush, then the other bracket key moves it back down to a 5px brush again.  I don't see the use of it showing a 5.3px brush.