Why is my program antialiasing selections when it shouldnt be?

[Zlobenia]

I'm trying to use the selection rectangular box to cut a clean, unantialiased chunk out of a bigger image and for some reason the program is cutting out a piece slightly bigger than the selection is and using it to antialias it. I don't want this, it want it to do what I ask it. The Antialias box is unchecked. How do I stop this, please.

[Gnobelix]

Hello @Zlobenia,

Just an idea, it could be that the feather of the selection tool is not set to 0 pixels.

 

Cheers

[Zlobenia]

Unfortunately it happens regardless

[thomaso]

3 hours ago, Zlobenia said:

I'm trying to use the selection rectangular box

Do you use the "Rectangular Marquee Tool (M)" (the running ants) – or the "Rectangle Tool (U)" (vector shape / layer of its own) to create the desired box?

In case of the latter (vector shape) make sure it gets created without a stroke colour or width. Otherwise its stroke will be added to the cropped image while the masking rectangle might not make its stroke really obvious as soon it gets nested as mask layer for the image.

Also pixel decimals may matter, it appears useful to create the pixel selection or the cropping object with integer pixels only, for both its position and width/height.

[Zlobenia]

I'm using the Rectangular Marquee Tool, and with Force Pixel Alignment on too, and no snapping. I've been doing some tests repeatedly in two different documents and sometimes its aliased and sometimes it's cleanly cut, even in the same document and with no differences. It seems almost random.

[walt.farrell]

2 minutes ago, Zlobenia said:

I'm using the Rectangular Marquee Tool, and with Force Pixel Alignment on too, and no snapping.

First, please check the application Settings, User Interface, and make sure the number of decimal places for Pixel units is at least 3.

Next, please make sure the document units are Pixels.

After making the Rectangular Marquee selection, you can verify its size and location (both are important, and must be integer values) using the Transform panel, before you Cut it.

[thomaso]

5 minutes ago, Zlobenia said:

sometimes its aliased and sometimes it's cleanly cut

Are the deviations (see above: x: +2 px | y: +4 px) always the same or similar, – or rather random, too? Or do they vary with the size of the selection?

When exactly does the deviation occur? For the running ants, or only for the layer selection of the cropped image?

[thomaso]

3 minutes ago, walt.farrell said:

important, and must be integer values

Decimals would cause a deviation for the total cropped layer size of max. 1-2 pixels, right? Whereas the OP's screenshot says + 4 px for the height.

[Old Bruce]

4 hours ago, Zlobenia said:

I'm trying to use the selection rectangular box to cut a clean, unantialiased chunk out of a bigger image and for some reason the program is cutting out a piece slightly bigger than the selection is and using it to antialias it. I don't want this, it want it to do what I ask it. The Antialias box is unchecked. How do I stop this, please.

 

15 minutes ago, Zlobenia said:

I'm using the Rectangular Marquee Tool, and with Force Pixel Alignment on too, and no snapping. I've been doing some tests repeatedly in two different documents and sometimes its aliased and sometimes it's cleanly cut, even in the same document and with no differences. It seems almost random.

I have bolded what I think is perhaps the problem. Is the "bigger image" at the same Pixel size (and aligned to the Pixel grid) as the document? My tests show that a difference in the dpi/ppi in what I copy results in a difference in what I paste.

[Zlobenia]

Ok. 

1. My decimal places are set to 6, and I have forced pixel alignment on. I religiously check the transform panel to ensure it's not an integer because I've struggled with Affinity and pixel work significantly before, so I hope it isn't that.
2. The document unit is in pixels, and it's the image itself that I've opened as a document which is exactly the dimensions it needs to be [its for a program that uses precise .pngs to map things out by colour. So I know it's not that. 
3. For some reason it all seems to work fine right now so I can't double check, but the degree of antialiasing/extra pixels was contingent on the side of the area I duplicated/cut out: the bigger the selection box the more extra pixels added and the more antialiased it is.
4. Deviation only occurs on the new layer: everything is as it should be in the selection box.
5. I assume that because the larger image is the document it's aligned. It's a pixel image so I guess it's already rasterised (?). I have done no resizing and it's locked.

 

I've attached the document below if you would like to try and reproduce the error. Right now for some reason it's all working ok for me so I'm doubly confused. I'm pretty sure I haven't changed anything at all except perhaps restarted my computer [which I've already tried previously with no change]. It's VERY LARGE 19800x15900 so beware opening it.

 

Map (1).afdesign

Edited July 4, 2023 by Zlobenia
Wrong file linked. Amended

[NotMyFault]

If you copy a pixel selection and paste it into another exiting document, Affinity tends to mis-place it to x.5 position, leading to 2px extra at the edges.

If you use retina pixel vie mode, this get amplified to 4 extra px.

 

To reproduce,

we would need the exact steps you made, and have all settings identical in designer (settings, grid, snapping, view mode, etc etc). Some settings will not be saved with the document.

[thomaso]

23 minutes ago, NotMyFault said:

If you copy a pixel selection and paste it into another exiting document, Affinity tends to mis-place it to x.5 position, leading to 2px extra at the edges.

If you use retina pixel vie mode, this get amplified to 4 extra px.

What are the conditions for the deviation? I can't reproduce any misplaced pixel clipboard pasting in V1, neither within APhoto nor in APub's personas or between both. (documents with no bleed, all same DPI but different page sizes)

[NotMyFault]

The issue can be reproduced if you

• make a rectangular selection of roughly 1500x1500px, but not the exact size
• use transform panel to change the size to exactly 1500x1500px
• copy / paste from your background layer

Cause:

• when adjusting the size of the selection, you effectively stretch  the selection (change DPI), instead of creating an exact (new) selection of the given size.
• Affinity has the (totally unexpected) feature allowing to stretch / rotate or even shear selections, which almost always creates unwanted and unexpected results. My best practice advice is to never scale / resize / shear / rotate an selection.

[NotMyFault]

13 minutes ago, thomaso said:

What are the conditions for the deviation? I can't reproduce any misplaced pixel clipboard pasting in V1, neither within APhoto nor in APub's personas or between both. (documents with no bleed, all same DPI but different page sizes)

I have deleted my olde post because it was not relevant for this issue. see my newer post which gives the actual cause.

[NotMyFault]

as second thought, this is probably a bug. Affinity seems to always create a 1px wide edge around selections if you adjust the selection size (increase) in transform panel after initial creation, and e.g. moving the selected pixel area with cmd+mouse drag.

[thomaso]

14 minutes ago, NotMyFault said:

Affinity has the (totally unexpected) feature allowing to stretch / rotate or even shear selections, which almost always creates unwanted and unexpected results.

Wow, good catch, I can reproduce it in V1 in APhoto & APub's personas. It appears especially nasty misleading that the unticked selection tool option "Antialias" does not to matter in a selection resizing via Transform panel.

[NotMyFault]

And as a reminder what insane brain damaging creative options you have with selections:

1. create a pixel layer with some fines detailed content, e.g. a b/w checkered board.
2. duplicate it
3. create a quadratic selection (e.g. 4x4px)
4. switch to move tool
5. rotate the layer
6. shear the layer
7. stretch x/y size
8. observe that the selection always follows these transformations
9. now move the selected area (or copy / paste) -> the selection got transformed
10. switch to the original layer (selection still active!), and copy / paste again.

 

[Zlobenia]

Great. Thanks for your responses. It's good to know why this has happened.

I'm really exhausted by affinity. I've been using the apps on and off for over a year and the amount of insane, laborious struggles to get the most basic things working has far outweighed the benefit of using it.

Why does it work this way? Why does the selection box work like that instead of just becoming 1500x1500? Instead of doing what you expect, and maybe the simplest function possible, it throws you and itself under the bus for the potential of some bizarre ultra-complex potential. I'm really tired of these apps. I hate to say it but I really would not recommend it to anybody trying to do anything pixel-related. I guess this is why photoshop remains the industry standard.

 

How am I supposed to make a selection of a particular size without completely ruining the very purpose of it? Can I even use the add or subtract tools or will that change the dpi or whatever and completely ruin the entire selection? Why is it programmed this way? I guess this is what I should have expected from an image editing program that doesn't even show you where the actual pixels are without changing a setting. All I'm doing is pixel art. Affinity has so many good features, but why on earth is it like this. Without some way to get it acting like you would expect, I don't think there's any world in which I cannot regret my purchases.

[walt.farrell]

54 minutes ago, NotMyFault said:

when adjusting the size of the selection, you effectively stretch  the selection (change DPI), instead of creating an exact (new) selection of the given size.

In my testing on Windows, I cannot reproduce that, at least if I use the Transform panel to change the size of the marquee. Or perhaps I don't understand what you mean. Can you provide more details?

 

[NotMyFault]

Hope that helps.

Maybe Mac specific bug.

[NotMyFault]

I just identified another severe issue in the video, timecode 12-19 seconds.

After moving e.g. the 3x3px part, it leaves a semi-transparent area visible. Only after switching layers or disabling/re-enabling the turquoise fill layer, the artefact vanishes.

Photo renders the area totally wrong.

[walt.farrell]

Can you provide that sample file, @NotMyFault?

Thanks.

[NotMyFault]

selection and transform bug.afphoto

[R C-R]

FWIW, I used the History panel to roll back the sample file, deleted everything except the top checker board pixel layer & to get this selection and transform simplified.afphoto V2 file. Using it, I cannot get the antialias issue you show to appear, as long as everything is set to integer pixel values.

Just curious if using this file you still see the issue....

[NotMyFault]

4 minutes ago, R C-R said:

FWIW, I used the History panel to roll back the sample file, deleted everything except the top checker board pixel layer & to get this selection and transform simplified.afphoto V2 file. Using it, I cannot get the antialias issue you show to appear, as long as everything is set to integer pixel values.

Just curious if using this file you still see the issue....

of course. The file was created from scratch, so everything you deleted was simply created during reproducing the issue and making the screen recording.

And I can reproduce the issue on iPad, too.