Pixel Grid

[Ash]

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.

[ATP]

It will be excellent for single-frame pixel art, nice addition.

[Circulus]

Nice addition,thanks.
Is it planned to address this also in the snapping manager?
 

[Frozen Death Knight]

6 minutes ago, Return said:

Nice addition,thanks.
Is it planned to address this also in the snapping manager?
 

Isn't it already possible to snap to the pixel grid?

[Circulus]

9 minutes ago, Frozen Death Knight said:

Isn't it already possible to snap to the pixel grid?

Yes but snapping takes in to account both so you may accidentally snap to a pixel grid instead of your " normal" grid.

[Ash]

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).

[Circulus]

 I meant this with snapping:

[Frozen Death Knight]

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.

[Circulus]

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.

 

 

[Sean P]

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.

[Sean P]

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.

[Sean P]

12 minutes ago, Sean P said:

I'll double check this behaviour in 2.2.1 and 1.10, but I suspect the behaviour is the same.

This behaviour is the same as 2.2.1 and 1.10.

[Circulus]

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.

 

[MEB]

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.

[Frozen Death Knight]

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:

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":

"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.

[Ash]

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.

[debraspicher]

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.

[walt.farrell]

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.

[Ash]

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.

[Affinityconfusesme]

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

Edited October 29, 2023 by tzvi20

[fde101]

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.

[len96]

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.
 

[debraspicher]

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

[Affinityconfusesme]

Likewise for masking work in photo.