Jump to content

Recommended Posts

Really loving Affinity Designer at the moment and it's pretty perfect without all the bloat of a certain other package, very tempted to throw my money down for it now. One thing that's bugging me at the moment is the pixel snapping isn't working as expected and I'm getting values of "320.3 px" rather than a whole integer ("320 px").

 

I've attached my snapping settings as an image to show how I got it all setup so maybe I'm doing something wrong or I'm mis-understanding it? But as a web developer, I work in integer values, so a point-something of a pixel doesn't work for me and is a bit of pain when dealing with tight layouts.

 

Aside from that Affinity is perfect and such a nice, clean and easy to use tool!

post-254-0-81954100-1406724903_thumb.png

Share this post


Link to post
Share on other sites

Hi,

 

Snapping is still very much a work in progress.  It's a fine balance getting all the snapping combinations to work together in a common yet complimentary way.

 

Snap to pixel is currently done as snapping to an arbitrary grid.  You'll see that you can chose any unit size - this effectively sets the grid size.  Pixel snapping is also a special case in that you can snap to pixel mid-points.  This is to allow for objects with 1-pixel lines to appear on-pixel rather than half way across two pixels when rasterised.

 

When you move a selected object, its bounding box is used as the thing that gets snapped.  If you snap to another object, you will see that you can snap the outer edges and the midline of the bounding box.  When it comes to pixel snapping, what is probably happening is that you are snapping the midline or the right/bottom edge of your objects bounding box to a pixel line or mid-pixel line.  Look carefully at the centre of your object - it may well have snapped to a pixel.

 

Also, if your object is not a precise pixel height and width, when you snap your object with the mid or bottom/right edge, the top/left edge won't be on a pixel line.  If the Transform panel is set to show the top/left position of your object, then it will display a value like what you are seeing.

 

We will look at the possibility of not snapping to midpoints when snapping to pixel - this will alleviate some of the problem you see. But, there is a good argument for still allowing snapping to bottom/right edges, so if your object is not an even pixel size you will notice some jitter as the object snaps to which ever edge is closest to the pixel grid.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

Is there an argument for it to snap based on what corner/edge you have set in the transform panel - thus meaning the X/Y position of a snapped object will always be an integer value in the transform panel?

 

Incidentally I've noticed that if you move an object under shift constraint snapping is ignored, which I guess is a bug?


Macbook Pro Retina

 

Share this post


Link to post
Share on other sites

Also with pen tool set to straight line, if you drag to create a straight line the second point doesn't snap to pixel... 


Macbook Pro Retina

 

Share this post


Link to post
Share on other sites

There's always an argument.  ;)

 

I was thinking about responding to the selected edge/corner in the transform tab as an option, but is that the most common case? If I were snapping to other objects rather than pixel positions I might not want that behaviour - I might even be snapping to different targets in the two axis.  Thing is - we could offer a multitude of options for how snapping behaves - but that might become more cumbersome than helpful.  There's already a number of options in the back end which are not exposed for good reason.  That's always been the fine balance.  Its probably better to play to the majority case and not offer too many further options.  Ultimately, we just need to try it to see what works best in most cases.

 

Snapping under constrain was working - I'll have a look at it.  I'm going to give the snapping code a bit of a clean up anyway as a result of the Node tool work I'm doing.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

I'm also currently rewriting the Pen and Node tools to do proper snapping.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

Wolfie is probably better to comment on this than me, but I actually think for pixel snapping the major use case is web graphics, and in most cases always want to snap top left to a 0.5px grid, and re sizing snapping to 0.5px too.  Snapping to other objects is likely to get in the way more than it helps (there's always alignment tools).  0.5px snapping I think is useful (rather than a full pixel) to account for when you have an odd number pixel width line border to your shape and want the line to perfectly align to pixels.

 

Think occasions when you want a non integer pixel size shape, or want to align things differently you have alignment tools and alt over-ride of snapping anyway...

 

Oh, and God knows what should happen when you rotate something ;)


Macbook Pro Retina

 

Share this post


Link to post
Share on other sites

We don't even joke about that.  ;)


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

Hmm, somewhat confused now, my fault as I'm not used to design tools

 

The way I see it working as a web developer is any object or position should be snapping to a integer value and not to any floating point; so if I create a circle or square then it needs to snap to that whole pixel value. This should levitate any issues when it comes to snapping two objects against each other.

 

Hope that makes sense. :)

Share this post


Link to post
Share on other sites

It does make sense, but the difficult answer is that we are trying to serve many different types of user - and some people will want finer grain control than always snapping all edges of an object to a pixel boundary.  You can achieve the sort of snapping you want by using pixel snapping mode and increasing you snapping tolerance so that it will always snap.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

I'm really confused by the dev answers here. A pixel is an *indivisible* unit. "Snap to pixel" should only ever snap to a whole number. Even Sketch hasn't gotten this right yet, and it's the *only* thing I ask of a screen design app.

Share this post


Link to post
Share on other sites

That's not true when dealing with vector objects. A vector line can contribute to sub pixel values. Also, we allow you to scale and position raster layers so that they can contribute to sub pixel values.

 

If you create a rectangle that overlaps pixels, you will see it antialiased when viewed in pixel preview mode. So, it is perfectly acceptable to not snap everything to pixel edges if you want to create smoothed images.

 

The reason for snapping to half pixels is for when you create an object, such as a rectangle, with a one pixel line. The line for vector objects is centred on the vector object. For that one pixel line to be rendered on-pixel, the vector object has to be positioned mid-pixel.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

Hey guys, is this issue really solved? I found that when duplicating objects by alt-dragging the duplicated object never snap to integer pixels, instead you get decimals.

I have tried nearly all the snapping feature, including the new "Candidates list" feature in version 1.5 but none of these seems to work.

As an example, try by duplicating an Artboard. You'll soon notice that it doesn't matter what snapping settings you have turned on, you always get half pixels numbers.

This is a screen recording that demonstrates the issue: http://jmp.sh/XYCotNH

Am I alone on this?

Share this post


Link to post
Share on other sites
To duplicate an object keeping the snapping active press and hold ⌘ (cmd) instead.

 

It also seems to work if you start with an option drag but release the option key after you start the drag. This is how I normally do it because I keep forgetting to use the Command key instead.


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites

OMG How come I didn't notice that.

Any way to change the default behaviour? I believe that duplicating with ALT it is almost the standard in most design apps, including 3d editors. It would be great if by default the snapping functionality is present by ALT dragging instead of CMD.

Thanks for your answers. Glad to know there is way to do it! Well, actually two ways :D

Share this post


Link to post
Share on other sites

A shortcut for "fixing" pixel aligment of a vector object's key points would help a lot.

 

I've got it on my list of things to look into for 1.6.


SerifLabs team - Affinity Developer
  • Software engineer  -  Photographer  -  Guitarist  -  Philosopher
  • iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395
  • MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300
  • iPad Pro 10.5", 256GB

Share this post


Link to post
Share on other sites

I also would like to throw a vote in for "force Pixel snapping"

 

I recognize all the hats that need to be worn, I am a designer and heavy equipment operator, but the pixel snapping truly appears arbitrary, unless you constantly keep your eyes on the transform panel and constantly make adjustments there.

 

I just want a giant check box button that truly "forces" pixel snapping, pixel transformation. Sure would make web work a lot easier when slicing assets.

Share this post


Link to post
Share on other sites
On 10/17/2017 at 10:59 PM, marsofearth said:

I recognize all the hats that need to be worn, I am a designer and heavy equipment operator, but the pixel snapping truly appears arbitrary, unless you constantly keep your eyes on the transform panel and constantly make adjustments there.

 

This is a big problem for me as well—currently, there is simply no way to work with "whole pixels only" if this is desired/required.

 

I also second the idea of one global check box that takes care of this. Or at least an option that can be set for individual files, if the former is too much to ask given the complex nature of the problem.

 

I also think it is important to recognize that this not just a problem of snapping. That alone has its issues. But for example, a simple drag-resize operation on a pixel or image layer with "Move by whole pixels" snapping enabled will yield a perfectly located boundary box—and yet the content of the box can still get resized with sub-pixel precision, namely if you use one of the diagonal handles, which by default cause aspect-ratio-correct resizing of the content, usually producing non-integer pixels. (Ignoring aspect ratio by holding Shift does work around this problem—but then you effectively lose control over your aspect ratio entirely, which is even worse.)

 

I also do not agree, as it has been suggested alsewhere, that aspect ratio-correct resizing should always use floating-point precision because otherwise the aspect ratio would not be perfectly preserved. Such precision can be required in some cases, and it's good that it's possibe to work this way; but other use cases do not require this last bit of precision and rather suffer from it. A proposed "whole pixels only" option could simply cause all pixel values in transform operations to be rounded. With anything but very small image sizes, the remaining precision will still be more than sufficient for many use cases, and the need for the whole "watching the Transform panel and correcting the undesired sub-pixel values" part would disappear completely.

 

I really hope this will be solved in some future update, for right now it is the single biggest workflow obstacle in Affinity Photo for me—a big headache, to be honest.

Share this post


Link to post
Share on other sites

Fundamentally, it all comes down to allowing aliased output or not. If you can live with the "jaggies" that produces then you could have a single-button option to snap everything to whole pixel values, but I doubt most users would be very happy with that.


Affinity Photo 1.6.7 & Affinity Designer 1.6.1; macOS High Sierra 10.13.6 iMac (27-inch, Late 2012); 2.9GHz i5 CPU; NVIDIA GeForce GTX 660M; 8GB RAM
Affinity Photo 1.6.11.85 & Affinity Designer 1.6..4.45 for iPad; 6th Generation iPad 32 GB; Apple Pencil; iOS 12.1.1

Share this post


Link to post
Share on other sites

PS to my above: Another aspect to this complex that in my opinion speaks for the need of a "whole pixels only" option is the contradiction inherent in having rasterized layers with sub-pixel values but showing them on the image not as half pixels, but as dimmed color over the whole pixel that the bounding box cuts through. (And of course, this is what is exported to pixel-based file formats as well.) Simply said, a pixel layer with size 2.5 x 2.5 pixels will in actuality be a 3.0 x 3.0 pixel layer, only the bounding box will be shown as 2.5 x 2.5 pixels (at the correct location). What this layer does to the image is display the innermost 2.0 x 2.0 pixels as one would expect, but the remaining 0.5 pixels (in each dimension) will go beyond the bounding box; to my eye, they appear like a partly transparent full-pixel addition next to the inner "normal" pixel layer. This is certainly not proper behavior, and in any case not what anyone manipulating pixels would expect. (If anything, one would expect Affinity Photo to actually work this a finer grid and display the non-whole pixels up to the boundary box, at full opacity (or whatever) and no further.)

 

And from simply inspecting the boundary sections of sub-pixel layers one can also easily tell that this has an effect on the scaling result. A 13 x 8 layer scaled down to 10.8 x 6.6 layer looks different than the one that results from manually setting this layer to 11.0 x 7.0 pixels. (I know, aspect ratio gets changed.) I can't claim this to be objective, but visually, I greatly prefer the look of the latter, and I'd presume many other users do, too. The semi-transparent pixels at the boundary of the 10.8 x 6.6 layer just don't look like what is meant to happen when a whole-pixel layer is scaled down.

 

Of course, all this, in the end, is simply a consequence of the fact that pixels (in any practical sense) are indivisible, as others have stressed already. Displaying non-whole pixels is inherently problematic and, to some extent, physically impossible. The current implementation in Affinity Photo is merely a workaround, not a solution to this fundamental problem.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×