Jump to content
You must now use your email address to sign in [click for more info] ×

Recommended Posts

  • Staff

Apps: All
Platforms: macOS, Windows and iPad

A new pixel grid option is available in all apps under the View menu. When set to on this will expose a pixel grid (as per the dpi of your current document) when zoomed in beyond a certain threshold.

By default the grid is set to grey, but you can customise the colour and opacity of the pixel grid, along with the colour of standard grid lines, within Grid and Axis settings.

image.png

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

  • Staff

To be honest we were little unsure whether to add "snap to pixel grid" as an additional entity in snapping manager as it felt it was effectively achieving the same thing "force pixel alignment"?

The intended behaviour is that "Snap to grid" option in snapping is purely to snap to your normal grid (so shouldn't snap to pixel grid whether or not that is on), and "force pixel alignment" should snap to pixels (again whether or not your pixel grid is turned on).

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

25 minutes ago, Ash said:

To be honest we were little unsure whether to add "snap to pixel grid" as an additional entity in snapping manager as it felt it was effectively achieving the same thing "force pixel alignment"?

The intended behaviour is that "Snap to grid" option in snapping is purely to snap to your normal grid (so shouldn't snap to pixel grid whether or not that is on), and "force pixel alignment" should snap to pixels (again whether or not your pixel grid is turned on).

From my own point of view I think that "Force pixel alignment" should be renamed to "Snap to pixel grid" and then de-couple that from "Move by whole pixels", which should be renamed to "Snap to whole pixel grid". The renaming would help with connecting the relation between snapping and "Show pixel grid" that was added in this patch. As for separating the two snapping options, the reason why is that it is unintuitive to have to activate two buttons just to be able to fully snap to the pixel grid. I know I'm not the only one who've had this experience.

Link to comment
Share on other sites

It will show more problems when people are using other units like inch or mm.
It will snap to grid and it will snap to pixelgrid but if they are not overlapping it will snap to the first available snapping option and this would cause issues.

 

 

Win11Pro/64gbRam/RTX3060Ti  +  Win10Home/32gbRam/GTX1050Ti + Win11Home/16gbRam/RTX3050


 

Link to comment
Share on other sites

  • Staff
1 hour ago, Return said:

It will show more problems when people are using other units like inch or mm.
It will snap to grid and it will snap to pixelgrid but if they are not overlapping it will snap to the first available snapping option and this would cause issues.

That is not snapping by a pixel grid - look at your zoom level it is a 850 million, I think what is happening is the object is moving the minimal distance that is physically possible.

Look at my attached video.

You can see the two grids separated by colour. Observe that with Snap To Grid enabled, and Force Pixel Alignment off it does not snap to the pixel grid.

Link to comment
Share on other sites

  • Staff
1 hour ago, Return said:

It will show more problems when people are using other units like inch or mm.
It will snap to grid and it will snap to pixelgrid but if they are not overlapping it will snap to the first available snapping option and this would cause issues.

 

 

I believe this is because you're using a pixel document with an Automatic grid, so it will always align to the pixels. If you changed your grid to a Basic one and defined the spacing and divisions, you will find its not automatically snapping to every pixel/half pixel. I'll double check this behaviour in 2.2.1 and 1.10, but I suspect the behaviour is the same.

Link to comment
Share on other sites

Yes I had a grid setup in pixels and used mm as unit so that made me think it was snapping to the pixelgrid.
So only the force pixel alignment setting will snap to the pixelgrid.
Perhaps like @Frozen Death Knight suggested it should be renamed in the snapping manager to " snap to pixelgrid"
Because if you use the FPA setting and snap to grid it will snap to both.

 

Win11Pro/64gbRam/RTX3060Ti  +  Win10Home/32gbRam/GTX1050Ti + Win11Home/16gbRam/RTX3050


 

Link to comment
Share on other sites

  • Staff
On 10/25/2023 at 1:20 PM, Frozen Death Knight said:

From my own point of view I think that "Force pixel alignment" should be renamed to "Snap to pixel grid" and then de-couple that from "Move by whole pixels", which should be renamed to "Snap to whole pixel grid". The renaming would help with connecting the relation between snapping and "Show pixel grid" that was added in this patch. As for separating the two snapping options, the reason why is that it is unintuitive to have to activate two buttons just to be able to fully snap to the pixel grid. I know I'm not the only one who've had this experience.

Maybe "Force Pixel Alignment" label/name could be changed to "Snap to pixel grid" if this make things more clear for users and helps them make the connection between the two things since that's effectively what's it's doing but the suggestions made for "Move by whole pixels" make no sense. What's the difference between "Snap to pixel grid" and "Snap to whole pixel grid"? What does the "whole" adds there? This is not accurate because "Move by whole pixels" does NOT ensure the object/whatever will be "fully" aligned with the pixel grid. It just ensures that when you move/transform these objects the movements/transformations will be made using full pixel units which is a different thing. If the objects are not fully pixel aligned from the beginning (that is, if they have fractional values) those fractional values will be kept even with this setting turned on - thus the object still remains non-pixel aligned and thus doesn't make sense to change the name of this to "Snap to whole pixel grid" because that's not what is supposed to do.

"Move by whole pixels" is also dependent of Force Pixel Alignment because it only makes sense to be used in the context of a pixel aligned project for the cases where you absolutely need to control the antialiasing of certain nodes/curves. Not all elements on a pixel aligned project are lines or fit exactly in a pixel grid (think small letters, curved paths, logos etc). Sometimes you have to adjust nodes individually and keep them non-pixel aligned purposely to get a better/smother visual appearance (antialising). This setting ensures they will be kept when you need to move or transform the object or part of it while working in the project. If it didn't exist and all was snapped automatically to integer pixel values/pixel grid you would have to re-adjust the carefully placed nodes again every time you moved or transformed that object/part of the object.

If you want everything fully pixel aligned (the "snap to whole pixel grid" suggestion/idea you are talking about) then Force Pixel Alignment (or "Snap to pixel grid" as you are suggesting it being called) is all you need to have enabled.

Link to comment
Share on other sites

32 minutes ago, MEB said:

Maybe "Force Pixel Alignment" label/name could be changed to "Snap to pixel grid" if this make things more clear for users and helps them make the connection between the two things since that's effectively what's it's doing but the suggestions made for "Move by whole pixels" make no sense. What's the difference between "Snap to pixel grid" and "Snap to whole pixel grid"? What does the "whole" adds there? This is wrong because "Move by whole pixels" does NOT ensure the object/whatever will be "fully" aligned with the pixel grid. It just ensures that when you move/transform these objects the movements/transformations will be made using full pixel units which is a different thing. If the objects are not fully pixel aligned from the beginning (that is, if they have fractional values) those fractional values will be kept even with this setting turned on - thus the object still remains non-pixel aligned and thus doesn't make sense to change the name of this to "Snap to whole pixel grid" because that's not what is supposed to do.

"Move by whole pixels" is also dependent of Force Pixel Alignment because it only makes sense to be used in the context of a pixel aligned project for the cases where you absolutely need to control the antialiasing of certain nodes/curves. Not all elements on a pixel aligned project are lines or fit exactly in a pixel grid (think small letters, curved paths, logos etc). Sometimes you have to adjust nodes individually and keep them non-pixel aligned purposely to get a better/smother visual appearance (antialising). This setting ensures they will be kept when you need to move or transform the object or part of it while working in the project. If it didn't exist and all was snapped automatically to integer pixel values/pixel grid you would have to re-adjust the carefully placed nodes again every time you moved or transformed that object/part of the object.

If you want everything fully pixel aligned (the "snap to whole pixel grid" suggestion/idea you are talking about) then Force Pixel Alignment (or "Snap to pixel grid" as you are suggesting it being called) is all you need to have enabled.

I just used "whole" as an example, since the word was already in use previously. Might not be the best wording, but here's another suggestion, based on 3D software I use: "Snap to absolute pixel grid" or "Absolute pixel grid snap".

In Maya there are two options for snapping; Relative and Absolute:

image.png.31240c11a13354bb6a03f6bc21189cfe.png

Could be an alternative by having a single "Snap to pixel grid" button with a toggle options called "Relative" and "Absolute". Or name the current two buttons to "Snap to relative pixel grid" and "Snap to absolute pixel grid". Just some ideas for the devs to consider if they decide to change the functionality.

In Blender it is also referred to as "absolute":

image.png.fc9ffc94826d58ddf186502a550bba7e.png

"Move by whole pixels" is only dependent because the buttons are assigned to be as such. In my previous examples from Blender and Maya you choose to activate them by picking different snapping methods, where moving by whole units tends to override any relative snapping options there are (see Blender). There is only one single button that activates snapping, but then there are options for how you wish for the snapping to behave. Snapping to relative or absolute pixels in Affinity simply behave differently. I can't even change the setting for "Move by whole pixels" unless I activate "Force pixel alignment", which just adds another button press that tends to be more often than not confusing.

Link to comment
Share on other sites

  • Staff

Hi All,

Thanks for these comments. I think for this release we are just focused on making sure the pixel grid works as expected. Discussion around wording / function of snapping options is something we'd have to come back to another time if we feel it important.

I think the main thing is that our intention is the pixel grid is purely a visual cue / help, when editing images in Affinity Photo when you are zoomed into areas which have little colour variance so you can easily see where the pixels are - but of course also has some use cases when working in Designer and Publisher which is why we have included the option in those apps too. It was not designed to be a grid which is snappable, as we have have existing options for that (whether or not they need improving is separate to this feature), and also fundamentally that pixel snapping is something you should be able to do without having the pixel grid turned on.

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

Maybe in lieu of modifying snapping options, a small feature could be added that highlights specific nodes (like a color change or something) that depicts that those nodes are not pixel-aligned. Since I think most people looking for the pixel grid more specifically are often checking for precise-alignment and working on items such as icons.

This would make troubleshooting easier. It would make the pixel grid/move by pixel behavior clearer to the user as they're working on alignment/hinting issues for their graphics. It's a small (hopefully?) modification that could speed up workflow exponentially for some.

Microsoft Windows 10 Home (Build 19045)
AMD Ryzen 7 5800X @ 3.8Ghz (-30 all core +200mhz PBO); Mobo: Asus X470 Prime Pro
32GB DDR4 (3600Mhz); EVGA NVIDIA GeForce GTX 3080 X3C Ultra 12GB
Monitor 1 4K @ 125% due to a bug
Monitor 2 4K @ 150%
Monitor 3 (as needed) 1080p @ 100%

WACOM Intuos4 Large; X-rite i1Display Pro; NIKON D5600 DSLR

Link to comment
Share on other sites

On 10/24/2023 at 9:39 AM, Ash said:

A new pixel grid option is available in all apps under the View menu. When set to on this will expose a pixel grid (as per the dpi of your current document) when zoomed in beyond a certain threshold.

I think this is a useful addition.

It would be more useful, I think, and please a lot of users more, if it was coupled in Photo with restoring the old behavior of the Automatic Grid. Now, with this new function, Photo has two ways of showing a Pixel Grid: View Grid and the Automatic Grid that gives you, and View Pixel Grid from the View menu.

Designer and Publisher have a much more visible and user-friendly grid when View Grid is chosen (with the default Automatic setting), but Photo has shown the Pixel Grid by default for Automatic since V2 started. As long as you're working on Grid options, please consider fixing that discrepancy, so Photo matches Designer and Publisher again.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.3, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.3

Link to comment
Share on other sites

  • Staff
28 minutes ago, walt.farrell said:

It would be more useful, I think, and please a lot of users more, if it was coupled in Photo with restoring the old behavior of the Automatic Grid.

Yes, absolutely - apologies that was in fact one of the intentions when implementing this but wasn't in the first beta build. It will be like this in the beta update next week.

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

what is the maximum number of boxes allowed? My camera is 24MP so MANY would be needed to be useful?  canon 80d.

Edited by tzvi20

Lenovo IdeaPad 5 Ryzen 7 5700U Rx Vega 8 graphics 

16GB RAM (15.3 usable) 

Affinity Photo 1.10.6

Affinity photo 2 2.3.1 Affinity Designer 2 2.3.1 Affinity Publisher 2 2.3.1 on Windows 11 Pro version 23H2

Beta builds as they come out.

canon 80d| sigma 18-200mm F3.5-6.3 DC MACRO OS HSM | Tamron SP AF 28-75mm f/2.8 XR Di LD | Canon EF-S 10-18mm f/4.5-5.6 IS STM Autofocus APS-C Lens, Black

 

Link to comment
Share on other sites

8 hours ago, tzvi20 said:

what is the maximum number of boxes allowed? My camera is 24MP so MANY would be needed to be useful?  canon 80d.

The more relevant factor is how many of them will fit on your display when you are zoomed in far enough to see them.  Boxes scrolled out of view won't matter much.

Link to comment
Share on other sites

  • 3 weeks later...

The changes to the ‘Grid and Snapping Axis with the restoration of a 64px default grid are very welcome.     However, it is still not possible to set a user grid pre-set as a default.   Furthermore, in a session a user change to the grid settings only applies to ONE image.   This is frustrating and adds much to the workflow.   

The current default grid is ‘busy’ and not ideal for all users.  For example, I use a 200px zero divisions for transformations on 7000px wide raws.

Suggest:
 
1). (Ideally) Allow user to nominate a grid pre-set as a global default that operates on all images and across sessions.
2). (less ideal) Allow user to nominate a grid pre-set that operates on ALL images in use on current session.
 

Link to comment
Share on other sites

  • 3 weeks later...

Thank you again for making this addition/change. I'm using it a lot more in Designer for pixel level work.

Microsoft Windows 10 Home (Build 19045)
AMD Ryzen 7 5800X @ 3.8Ghz (-30 all core +200mhz PBO); Mobo: Asus X470 Prime Pro
32GB DDR4 (3600Mhz); EVGA NVIDIA GeForce GTX 3080 X3C Ultra 12GB
Monitor 1 4K @ 125% due to a bug
Monitor 2 4K @ 150%
Monitor 3 (as needed) 1080p @ 100%

WACOM Intuos4 Large; X-rite i1Display Pro; NIKON D5600 DSLR

Link to comment
Share on other sites

  • 3 weeks later...

Likewise for masking work in photo.

Lenovo IdeaPad 5 Ryzen 7 5700U Rx Vega 8 graphics 

16GB RAM (15.3 usable) 

Affinity Photo 1.10.6

Affinity photo 2 2.3.1 Affinity Designer 2 2.3.1 Affinity Publisher 2 2.3.1 on Windows 11 Pro version 23H2

Beta builds as they come out.

canon 80d| sigma 18-200mm F3.5-6.3 DC MACRO OS HSM | Tamron SP AF 28-75mm f/2.8 XR Di LD | Canon EF-S 10-18mm f/4.5-5.6 IS STM Autofocus APS-C Lens, Black

 

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.