WolfieZero Posted July 30, 2014 Share Posted July 30, 2014 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! Quote Link to comment Share on other sites More sharing options...
Staff Ben Posted July 30, 2014 Staff Share Posted July 30, 2014 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. Quote 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 Link to comment Share on other sites More sharing options...
Staff Ash Posted July 30, 2014 Staff Share Posted July 30, 2014 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? Quote Managing Director Help make our apps better by joining our beta program! MacBook Pro (16-inch, 2021) / Apple M1 Max / 64GB / macOS 12.0.1 iPad Pro 11-inch 3rd Gen / iPadOS 16.2 Link to comment Share on other sites More sharing options...
Staff Ash Posted July 30, 2014 Staff Share Posted July 30, 2014 Also with pen tool set to straight line, if you drag to create a straight line the second point doesn't snap to pixel... Quote Managing Director Help make our apps better by joining our beta program! MacBook Pro (16-inch, 2021) / Apple M1 Max / 64GB / macOS 12.0.1 iPad Pro 11-inch 3rd Gen / iPadOS 16.2 Link to comment Share on other sites More sharing options...
Staff Ben Posted July 30, 2014 Staff Share Posted July 30, 2014 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. Quote 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 Link to comment Share on other sites More sharing options...
Staff Ben Posted July 30, 2014 Staff Share Posted July 30, 2014 I'm also currently rewriting the Pen and Node tools to do proper snapping. Quote 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 Link to comment Share on other sites More sharing options...
Staff Ash Posted July 30, 2014 Staff Share Posted July 30, 2014 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 ;) Quote Managing Director Help make our apps better by joining our beta program! MacBook Pro (16-inch, 2021) / Apple M1 Max / 64GB / macOS 12.0.1 iPad Pro 11-inch 3rd Gen / iPadOS 16.2 Link to comment Share on other sites More sharing options...
Staff Ben Posted July 30, 2014 Staff Share Posted July 30, 2014 We don't even joke about that. ;) Quote 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 Link to comment Share on other sites More sharing options...
WolfieZero Posted July 31, 2014 Author Share Posted July 31, 2014 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. :) Quote Link to comment Share on other sites More sharing options...
Staff Ben Posted July 31, 2014 Staff Share Posted July 31, 2014 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. Quote 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 Link to comment Share on other sites More sharing options...
singletonself Posted October 2, 2014 Share Posted October 2, 2014 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. Quote Link to comment Share on other sites More sharing options...
Staff Ben Posted October 2, 2014 Staff Share Posted October 2, 2014 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. Quote 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 Link to comment Share on other sites More sharing options...
DrPocter Posted February 6, 2015 Share Posted February 6, 2015 Problem solved with new Force Pixel Alignment option in beta 1.1.2.22384. :D MattP 1 Quote Link to comment Share on other sites More sharing options...
mqudsi Posted February 7, 2015 Share Posted February 7, 2015 Wow, I just Googled this right now because I had this problem. *rushes to download* Quote NeoSmart Technologies Link to comment Share on other sites More sharing options...
aleperz Posted October 7, 2016 Share Posted October 7, 2016 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/XYCotNHAm I alone on this? Quote Link to comment Share on other sites More sharing options...
Staff MEB Posted October 8, 2016 Staff Share Posted October 8, 2016 Hi aleperz, Welcome to Affinity Forums :) Are you duplicating the object holding down ⌥ (option/alt)? If so it also disables the snapping temporarily. To duplicate an object keeping the snapping active press and hold ⌘ (cmd) instead. Quote A Guide to Learning Affinity Software | Affinity Quick Reference Link to comment Share on other sites More sharing options...
R C-R Posted October 8, 2016 Share Posted October 8, 2016 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. Quote All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 Affinity Photo 1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7 Link to comment Share on other sites More sharing options...
aleperz Posted October 8, 2016 Share Posted October 8, 2016 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 Quote Link to comment Share on other sites More sharing options...
Staff MEB Posted October 8, 2016 Staff Share Posted October 8, 2016 Hi aleperz, No, there's no way to change this behaviour. Quote A Guide to Learning Affinity Software | Affinity Quick Reference Link to comment Share on other sites More sharing options...
aderkach Posted November 9, 2016 Share Posted November 9, 2016 A shortcut for "fixing" pixel aligment of a vector object's key points would help a lot. hawk 1 Quote Link to comment Share on other sites More sharing options...
Staff Ben Posted November 10, 2016 Staff Share Posted November 10, 2016 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. Quote 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 Link to comment Share on other sites More sharing options...
marsofearth Posted October 17, 2017 Share Posted October 17, 2017 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. Quote Link to comment Share on other sites More sharing options...
Ballonseide Posted February 16, 2018 Share Posted February 16, 2018 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. Patrick Connor, marsofearth and hawk 3 Quote Link to comment Share on other sites More sharing options...
R C-R Posted February 16, 2018 Share Posted February 16, 2018 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. Quote All 3 1.10.8, & all 3 V2.4.1 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 Affinity Photo 1.10.8; Affinity Designer 1.108; & all 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7 Link to comment Share on other sites More sharing options...
Ballonseide Posted February 16, 2018 Share Posted February 16, 2018 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. marsofearth 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.