Jump to content

Aligned objects not actually aligned


Recommended Posts

16 minutes ago, konstantnnn said:

I even now rounded the sizes up to a nice whole number

The sizes are already whole pixels as it's raster images. What I am referring to is the artboard/image positions in the document. The screenshot I showed before of the UI preferences is the important part - I think by default it doesn't show decimal places for pixels, so if your artboard/image is say a x/y: 0.02px your transform panel shows 0px and you are none the wiser.

I'm afraid your version of Designer is newer than mine so I cannot open your file.

Link to comment
Share on other sites

7 minutes ago, BofG said:

The sizes are already whole pixels as it's raster images. What I am referring to is the artboard/image positions in the document. The screenshot I showed before of the UI preferences is the important part - I think by default it doesn't show decimal places for pixels, so if your artboard/image is say a x/y: 0.02px your transform panel shows 0px and you are none the wiser.

I'm afraid your version of Designer is newer than mine so I cannot open your file.

Just open the file It's just artboards and images and nothing else that's in newer versions. It's pretty much backwards compatible with versions from 2017.

I changed that decimal setting when you told me, there are four decimal places visible and I saw that the width was "1331,5" or some not complete number like that so I squished and transformed the images to all be an even whole number and I aligned them and the "X", and "Y", and "Width" and "Height" positions are whole numbers now. The issue is still happening. Aldo be it, it's not anymore when exporting.

But still, let's say we started at the left side, and the image width was 254,543 pixels. And lets say I aligned a next image, SNAPPED it, and the next image STARTS at the coordinates 254,543PX and ends at 354,543PX. The program should have no gaps between the two, yet it has.

And the snapping tool should automatically snap objects together to literally the same position, like the magnet icon implies. This is so wonderful! This is a combination of a faulty magnet tool, faulty snapping, faulty number rounding, faulty decimal display, faulty antialiasing, they all sing in harmony!

Check the file if you can.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

Just now, konstantnnn said:

It's pretty much backwards compatible with versions from 2017.

I mean funny thing, from all the issues I already encountered, it would be just so brilliantly funny if somebody at Affinity even decided files shouldn't be backwards compatible now so there's an another voice to this harmonious choir

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

I imported the two images into APPLE KEYNOTE and aligned them within 2 seconds with their guides. No gap.

Exported into PDF.

No gap.

I really didn't want to bring my opinions on why Apple develops superior software and why I desperately want them to design a desktop publishing app, but here we come. 

This is so easy. Import images. Align them. No gap.

That should be it! 

Seriously.

Is this that hard to grasp somehow?

So an end user has to worry about decimal places now?

This is just faulty engineering and lazy bandaid patches to cover up a flawed architecture beneath.

 

Screenshot 2021-08-11 at 16.33.36.png

Screenshot 2021-08-11 at 16.33.57.png

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

8 minutes ago, konstantnnn said:

The issue is still happening.

I wish I could help, maybe there is a difference as I'm on Windows.

8 minutes ago, konstantnnn said:

Aldo be it, it's not anymore when exporting.

That's at least one good thing.

8 minutes ago, konstantnnn said:

Check the file if you can.

I did try to, it states it's from a newer version and cannot be opened.

Link to comment
Share on other sites

Just now, BofG said:

I did try to, it states it's from a newer version and cannot be opened.

Hahahahahah, I cant believe it! Its just artboards and images, been there since the beginning. Thanks much mate anyways!! I can always jump hoops and get around this but, you know, why not just have them fix it

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

2 hours ago, konstantnnn said:

I changed that decimal setting when you told me, there are four decimal places visible and I saw that the width was "1331,5" or some not complete number like that so I squished and transformed the images to all be an even whole number and I aligned them and the "X", and "Y", and "Width" and "Height" positions are whole numbers now. The issue is still happening. Aldo be it, it's not anymore when exporting.

This is key and the reason you are seeing the hairline, sizes need to be whole pixels, otherwise you are seeing the result of antialiasing on a non-whole pixel which is a side-effect of the way the rasterisation routine works... as you've now seen when the elements are both placed at whole pixel values and are using whole pixel dimensions there is no hairline on raster exports.

2 hours ago, konstantnnn said:

But still, let's say we started at the left side, and the image width was 254,543 pixels. And lets say I aligned a next image, SNAPPED it, and the next image STARTS at the coordinates 254,543PX and ends at 354,543PX. The program should have no gaps between the two, yet it has.

It will have a gap/hairline for the reason cited above...

2 hours ago, konstantnnn said:

And the snapping tool should automatically snap objects together to literally the same position, like the magnet icon implies. This is so wonderful! This is a combination of a faulty magnet tool, faulty snapping, faulty number rounding, faulty decimal display, faulty antialiasing, they all sing in harmony!

It does, there are no issues with the magnet/snapping tool in this respect...

 

Image on the left showing pixel aligned images - image on the right showing the subsequent JPG export with no visible hairline

 

605173114_PixelAligned.thumb.jpg.d5f0156c76d70884e0b79d80b0cfc2b3.jpg

 

Image on the left showing non-pixel aligned images - image on the right showing the subsequent JPG export which still has the visible hairline

1139354015_NonPixelAligned.thumb.jpg.15357e2ac5b9af9512e67a2b282d7312.jpg

 

Where there is an issue however, one which has still not been fixed despite being highlighted several times with support, is PDF export. PDFs are not exprting at the exact size of the source file...

If you take a look at the widths for each of your three source elements and then compare this to the widths of the same three elements once exported to PDF then you can see the issue...

They should be 1,330 px, 1,440 px and 1,330 px respectively however, the widths on PDF export are 1330.999668 px, 1439.999946 px and 1330.000419 px. All three images are correctly positioned but at the same time they no longer butt up with each other but overlap each other and because they are no longer whole pixel widths, the hairline is visible for the same reason.

The issue is even worse with SVG exports in that both the image width and image positions are incorrect on export, resulting in non whole pixel values for both.

PDF Exported Image Widths

728450459_PDFExportSizes.thumb.jpg.e292f42100b936381f994a7f10a7b6c0.jpg

 

It is possible to remove the visible hairline onscreen by adjusting the Coverage Map in the Blend Options, however, this is not necessary for raster export assuming everything is perfectly whole pixel aligned and it is ignored on vector export but at least it helps from a purely visual standpoint when creating artwork.

 

Visible Hairline Onscreen Using Default Coverage Map

 

349591339_AALineVisible.thumb.jpg.4ae4cf9a37eedae168e7b60cfe34499e.jpg

 

Visible Hairline Onscreen No Longer Visible When Coverage Map Setting Adjusted1281934640_AALineNonVisible.thumb.jpg.262d504f4a0f0317c2204bc899934a54.jpg

One thing I was going to point out with the file you uploaded is that the three elements are not perfectly aligned between themselves so you can effectively see the joins so to speak. I don't mean they are not pixel aligned, they are but you can see the small issue below...

 

misalignment.thumb.jpg.3545002bd9efa828e1b277227c376962.jpg

 

Affinity Designer 1.7.3, Affinity Photo 1.7.3, Affinity Publisher 1.10.1 | Affinity Designer Beta 1.10.3.1, Affinity Photo Beta 1.10.2.266 | MacBook Pro 16GB, macOS Monterey 12.5

Link to comment
Share on other sites

The example you posted relating to Clipping Paths is a different 'issue', although it's not really an issue as such because it has a remedy as mentioned previously. Use Precise Clipping is purely used to improve the on-screen appearance by eliminating the red bleed you are seeing with your clipped circle.

Exporting with or without this checked makes no difference, the exported file will not show the bleed.

Affinity Designer 1.7.3, Affinity Photo 1.7.3, Affinity Publisher 1.10.1 | Affinity Designer Beta 1.10.3.1, Affinity Photo Beta 1.10.2.266 | MacBook Pro 16GB, macOS Monterey 12.5

Link to comment
Share on other sites

4 hours ago, Hangman said:

Use Precise Clipping is purely used to improve the on-screen appearance by eliminating the red bleed you are seeing with your clipped circle

Do you happen to know why this isnt on by default?

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

I don’t, I can only assume that because it doesn’t influence the exported file that it’s not considered an issue. Like most things I guess it’s optional and either you decide to have it on by default or you don’t. I see no obvious reason for it not to be on by default but equally you can make that the default setting...

Affinity Designer 1.7.3, Affinity Photo 1.7.3, Affinity Publisher 1.10.1 | Affinity Designer Beta 1.10.3.1, Affinity Photo Beta 1.10.2.266 | MacBook Pro 16GB, macOS Monterey 12.5

Link to comment
Share on other sites

4 hours ago, Hangman said:

This is key and the reason you are seeing the hairline, sizes need to be whole pixels, otherwise you are seeing the result of antialiasing on a non-whole pixel which is a side-effect of the way the rasterisation routine works... as you've now seen when the elements are both placed at whole pixel values and are using whole pixel dimensions there is no hairline on raster exports.

It will have a gap/hairline for the reason cited above...

It does, there are no issues with the magnet/snapping tool in this respect...

 

Image on the left showing pixel aligned images - image on the right showing the subsequent JPG export with no visible hairline

 

605173114_PixelAligned.thumb.jpg.d5f0156c76d70884e0b79d80b0cfc2b3.jpg

 

Image on the left showing non-pixel aligned images - image on the right showing the subsequent JPG export which still has the visible hairline

1139354015_NonPixelAligned.thumb.jpg.15357e2ac5b9af9512e67a2b282d7312.jpg

 

Where there is an issue however, one which has still not been fixed despite being highlighted several times with support, is PDF export. PDFs are not exprting at the exact size of the source file...

If you take a look at the widths for each of your three source elements and then compare this to the widths of the same three elements once exported to PDF then you can see the issue...

They should be 1,330 px, 1,440 px and 1,330 px respectively however, the widths on PDF export are 1330.999668 px, 1439.999946 px and 1330.000419 px. All three images are correctly positioned but at the same time they no longer butt up with each other but overlap each other and because they are no longer whole pixel widths, the hairline is visible for the same reason.

The issue is even worse with SVG exports in that both the image width and image positions are incorrect on export, resulting in non whole pixel values for both.

PDF Exported Image Widths

728450459_PDFExportSizes.thumb.jpg.e292f42100b936381f994a7f10a7b6c0.jpg

 

It is possible to remove the visible hairline onscreen by adjusting the Coverage Map in the Blend Options, however, this is not necessary for raster export assuming everything is perfectly whole pixel aligned and it is ignored on vector export but at least it helps from a purely visual standpoint when creating artwork.

 

Visible Hairline Onscreen Using Default Coverage Map

 

349591339_AALineVisible.thumb.jpg.4ae4cf9a37eedae168e7b60cfe34499e.jpg

 

Visible Hairline Onscreen No Longer Visible When Coverage Map Setting Adjusted1281934640_AALineNonVisible.thumb.jpg.262d504f4a0f0317c2204bc899934a54.jpg

One thing I was going to point out with the file you uploaded is that the three elements are not perfectly aligned between themselves so you can effectively see the joins so to speak. I don't mean they are not pixel aligned, they are but you can see the small issue below...

 

misalignment.thumb.jpg.3545002bd9efa828e1b277227c376962.jpg

 

Yeah the images are a bit off, something's up with Wayback machine and their cropping, but that's off topic, like, like…I think this is my two cents on this... my head is almost hurting now. As I continue to point out, I can put any arbitrary halfpixel, quarter or 1/1000000th of a pixel size into Apple Keynote, Pages, Numbers, and align them both, and they render and export correctly in all possible formats at all possible resolutions. This is what Affinity should do. Sizes dont need to be whole pixels. What if I didnt want them to be whole pixels? I do, but what if I didnt? And its irrelevant, users shouldnt have to conform to a technical problem and limitation of a program, at least if the developers care for the program to be good-ly designed..Turns out, it's going to really surprise all of us how many people use FREEFORM transforming and no transform panels and guides and calculators. Including me. I resize it until it feels right. Just like it's expected to be done, why would we have handles and the option to turn off "pixel" snapping altogether if it's not expected of us?

If I duplicate an object, no matter, no matter what it's size, I should, I should be able to snap it next to it's identical instance with no gaps. I should. I don't really care anymore about the technical issues of this and that and the seventy five thousand pages workarounds, I should just do it the expected way, the fast way, the logical way and the right way. This is not expected behaviour for aligning images. If I can't because of antialiasing-issues-or-anything-else, change it.

I mean, I just want to apply and align different layers. I'm almost becoming a molecular scientist and computer engineer now! I cant and dont have enough time to worry about are there, why, how, and why are gaps appearing in my document! when there's a 3 hour limit until I can submit my work to an agency.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

1 minute ago, konstantnnn said:

until I can submit my work to an agency.

And for the record, they don't want gaps.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

13 hours ago, konstantnnn said:

As I continue to point out, I can put any arbitrary halfpixel, quarter or 1/1000000th of a pixel size into Apple Keynote, Pages, Numbers, and align them both, and they render and export correctly in all possible formats at all possible resolutions.

This is because Apple Keynote, Pages and Numbers all work at 72dpi. All three can only display units in either Points, Centimetres or Inches (not pixels).

If you take the document you uploaded which is 4,100px x 621px at 72dpi with the three individual images at 1,330px x 621px, 1,440px x 621px and 1,330px x 621px respectively and convert it to points you'll see the numeric values are the same only in points rather than pixels, i.e., 1px = 1pt.

If you set up a Keynote document at 4,100pt x 621pt (since you can specify pixels), drag your three images onto the Keynote page/slide and position them manually or mathematically you'll notice that you can only position elements in whole points, i.e., whilst you can type in a 0.25pt or 0.5pt value, Keynote (and likewise Pages and Numbers) rounds the values to whole points, e.g., anything below 0.5pt is rounded down to the nearest whole point and 0.5pt and above is rounded up to the nearst whole point.

This effectively means you can only position elements in any of these programs at whole point values, therfore by definition, whole pixel values which is why when exporting to pdf (which is the only relevant export file format available) the file renders correctly, i.e., because the elements making up the file are positioned at whole rather than fractional pixel values.

 

14 hours ago, konstantnnn said:

What if I didnt want them to be whole pixels? I do, but what if I didnt?

The smallest unit available when rendering graphics is a pixel so fractional pixels will automatically be anti-aliased (rendered using lighter colours), so anything that is offset, i.e., not using whole pixel values will have visible anti-aliasing applied hence the faint line you see when items are not pixel aligned using whole pixel values...

A black line with a width of 1px will be rendered as a series of black pixels, but if you make its width 0.5px then it will be rendered as a series of lighter gray pixels creating the illusion of a thinner line.

Anti-aliasing.thumb.jpg.be9ce93799e7426c589b7c46a72dd467.jpg

 

I'm sure you have a very good reason but my question with regards the iPhone graphic is why is the image split into three in the first place, why not just 'assemble' it as a single image, then you wouldn't have the anti-aliasing issue you're seeing between the three images even if the images were not pixel aligned. You would technically still need to position and size your image using whole pixel values to avoid anti-aliasing at the edges but you would eliminate the vertical hairlines you are currently seeing where the three images currently meet...

This issue isn't unique to Affinity software, the same 'issue' exists in Illustrator and Photoshop.

 

Affinity Designer 1.7.3, Affinity Photo 1.7.3, Affinity Publisher 1.10.1 | Affinity Designer Beta 1.10.3.1, Affinity Photo Beta 1.10.2.266 | MacBook Pro 16GB, macOS Monterey 12.5

Link to comment
Share on other sites

16 hours ago, konstantnnn said:

why would we have handles and the option to turn off "pixel" snapping altogether if it's not expected of us?

The thing to bear in mind is that Designer is like a Swiss army knife - it can do lots of things for lots of different use cases. If you are working towards a raster output then pull out the correct tools - use the pixel view mode, force pixel alignment and set up snapping as appropriate. Using it in the 'vector' type setup is like pulling out the corkscrew and complaining it's hard to peel your potatos with :)

There's very little to gain from fighting against it / the underlying technology. There are constraints, they exist. Work within them and have a less stressful existance :)

Link to comment
Share on other sites

1 hour ago, Hangman said:

This is because Apple Keynote, Pages and Numbers all work at 72dpi. All three can only display units in either Points, Centimetres or Inches (not pixels).

If you take the document you uploaded which is 4,100px x 621px at 72dpi with the three individual images at 1,330px x 621px, 1,440px x 621px and 1,330px x 621px respectively and convert it to points you'll see the numeric values are the same only in points rather than pixels, i.e., 1px = 1pt.

If you set up a Keynote document at 4,100pt x 621pt (since you can specify pixels), drag your three images onto the Keynote page/slide and position them manually or mathematically you'll notice that you can only position elements in whole points, i.e., whilst you can type in a 0.25pt or 0.5pt value, Keynote (and likewise Pages and Numbers) rounds the values to whole points, e.g., anything below 0.5pt is rounded down to the nearest whole point and 0.5pt and above is rounded up to the nearst whole point.

This effectively means you can only position elements in any of these programs at whole point values, therfore by definition, whole pixel values which is why when exporting to pdf (which is the only relevant export file format available) the file renders correctly, i.e., because the elements making up the file are positioned at whole rather than fractional pixel values.

 

The smallest unit available when rendering graphics is a pixel so fractional pixels will automatically be anti-aliased (rendered using lighter colours), so anything that is offset, i.e., not using whole pixel values will have visible anti-aliasing applied hence the faint line you see when items are not pixel aligned using whole pixel values...

A black line with a width of 1px will be rendered as a series of black pixels, but if you make its width 0.5px then it will be rendered as a series of lighter gray pixels creating the illusion of a thinner line.

Anti-aliasing.thumb.jpg.be9ce93799e7426c589b7c46a72dd467.jpg

 

I'm sure you have a very good reason but my question with regards the iPhone graphic is why is the image split into three in the first place, why not just 'assemble' it as a single image, then you wouldn't have the anti-aliasing issue you're seeing between the three images even if the images were not pixel aligned. You would technically still need to position and size your image using whole pixel values to avoid anti-aliasing at the edges but you would eliminate the vertical hairlines you are currently seeing where the three images currently meet...

This issue isn't unique to Affinity software, the same 'issue' exists in Illustrator and Photoshop.

 

I’m quite shocked, I didnt know Apple snaps to whole pixels. I could have a 1000px document and bring three images and snap them and align them so each one seems like it takes up 333,333 pixels and no gaps would be found, furthermore I can put a decimal number in the “Properties” tab of each project. And while zoomed in to 10000000%, I can freeformly transform and it doesnt seem like it’s snapping to any points or pixels at all. Thanks for the insight.

The original image is split up because it has been designed as a carousell for a website and instagram.

I see now how antialiasing works, but still, why if there are two objects aligned at any halfpixel size, why would there be a gap? Let me “draw” this to you in an another way. Let’s say I literally created geometrically perfect documents, a 100px square and a 100px square next to it in a “200px*100px” document”. Pixel perfect, no gaps. I exported this as PDF.

Now I bring this new PDF into my new raster document with an arbitrary size. I free-transform the shape. Let’s say, I free-transform the shape to 56,67px height. It’s not whole pixels now. What are your expectations, should an arbitrary gap appear all of a sudden?? If your literal import shape had no gap in the beginning, if its perfectly aligned?

My two cents on this is even if your square had dimensions 245,3222215132142314132px. The software should interprate that “Hey, if user snapped an object next to me, lets start another image at 245,3222215132142314132px and continiue to the right. You see, right there, there is virtually no space left for an air gap.

And if the software continiues to think that 0,0000000000000000001 pixel is still enough to count as a “gap” and an error in antialiasing, then the software should at least use its anti aliasing alghorithm and that thing of ‘changing opacity based on thickness” that you pointed out to realize that the gap is so thin that it’s opacity should be 0,00000000000000001%, virtually rendering the gap invisible, unlike now where it’s pretty visible.

This is how it should work.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

58 minutes ago, BofG said:

The thing to bear in mind is that Designer is like a Swiss army knife - it can do lots of things for lots of different use cases. If you are working towards a raster output then pull out the correct tools - use the pixel view mode, force pixel alignment and set up snapping as appropriate. Using it in the 'vector' type setup is like pulling out the corkscrew and complaining it's hard to peel your potatos with :)

There's very little to gain from fighting against it / the underlying technology. There are constraints, they exist. Work within them and have a less stressful existance :)

I was certainly under an impression I’m working in a vector program :) Aligning shapes and images :) and having :) The program :) make :) random :) gaps :) everywhere :) I :) looked :) even if it said :) that the objects were perfectly aligned :) next to one another :) with no air gap present.

Having a set in stone mentality is the quickest way to develop poor software. I’m just giving feedback.

I don’t know, for me it’s so simple how it should work. You see, if I snap two objects together, “snap” kinda implies they are magnetically sticked to one another, and magnets kinda imply they are so close together there’s no air inbetween them. Any air gap, at ANY pixel size or rendering technology

 s h o u l d n ‘ t

be there because snapped objects imply snapped objects, airgap-less objects!

While your analogy is pretty               , I’m actually using a vector type workflow in a vector based program with vector shapes and vector tools to align vectors for my vector project — pretty logical to me. Furthermore, the issue arizes even in vector based viewing and in vector based outline viewing in an again, a vector based program — it even occurs in vector based output formats such as PDF. And even now, just because a raster view has a limitation (or frankly an rendering error), doesn’t mean users are using it wrong. Push the limitation forward and make better software, in my mind.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

10 minutes ago, BofG said:

@konstantnnn I was only here trying to help. I wasn't trying to antagonise anyone. All the best.

Me neither. I just want Affinity to build great software. That’s the only reason I’m here.

I don’t think I’m wrong in thinking that, a great cockscrew that is at the same time is a great potato peeler is actually amazing? And if Affinity is letting you have a pixel view and pixel options in their vector-based-vector-priority application, they’re already choosing to play a game of a cockscrew and a potato peeler… Just, they’re leaving ting bits and gaps unpeeled :)

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

2 hours ago, konstantnnn said:

I could have a 1000px document and bring three images and snap them and align them so each one seems like it takes up 333,333 pixels and no gaps would be found

By default if each of your three images were 333,333 pixels in width, the edges would already be anti-aliased so regardless of snapping them together you will still see the issue because you will have transparent pixels on the image edges but more than happy if you want to upload a Keynote file that demonstrates what you are seeing...

2 hours ago, konstantnnn said:

furthermore I can put a decimal number in the “Properties” tab of each project. And while zoomed in to 10000000%, I can freeformly transform and it doesnt seem like it’s snapping to any points or pixels at all.

I was unsure if you were referring Keynote/Pages/Numbers here since each limits you to a 400% zoom and whilst you can enter decimal places, they automatically round to the nearest whole point. I think you also have to bear in mind that Keynote, Pages and Numbers are not designed for this purpose in the first place, being presentation, word processing and spreadsheet software.

2 hours ago, konstantnnn said:

The original image is split up because it has been designed as a carousell for a website and instagram.

That makes sense, thanks for letting me know...

2 hours ago, konstantnnn said:

I see now how antialiasing works, but still, why if there are two objects aligned at any halfpixel size, why would there be a gap?

Thinking about this as a gap is perhaps misleading, it's not an actual, physical gap, it is transparent pixels. If you take a look at this image and note how the two grey squares are positioned and how they both use fractional pixels. Even though they are snapped together and perfectly aligned, because they don't use whole pixel values the edges of the squares are anti-aliased, i.e., rendered using semi-transparent pixels. You can see this by looking at the vertical gradated line on the left which appears muted because the gradated background beneath the grey squares is showing through semi-transparent pixels. The vertical line to the right shows how the actual background looks without the transparent pixels, i.e., without any anti-aliasing.

So the hairline/gap that this conversation has all been about is simply the result of unavoidable anti-aliasing, it is the way software renders fractional pixels when the smallest unit available is one pixel.

Using whole pixel dimensions and positioning at whole pixel values removes the need for any anti-aliasing and hence you won't see any hairline/gap.

Anti-aliasing.thumb.jpg.84ce6b78f1cc7cbfdd5e2a71efc3adab.jpg

2 hours ago, konstantnnn said:

Let me “draw” this to you in an another way. Let’s say I literally created geometrically perfect documents, a 100px square and a 100px square next to it in a “200px*100px” document”. Pixel perfect, no gaps. I exported this as PDF.

Now I bring this new PDF into my new raster document with an arbitrary size. I free-transform the shape. Let’s say, I free-transform the shape to 56,67px height. It’s not whole pixels now. What are your expectations, should an arbitrary gap appear all of a sudden?

In this instance your original exported PDF would have no hairline/gaps if all created in a single document and exported. Bringing it into Photoshop or Affinity Photo and transforming it so it now has a height of 56.67px and exporting it to say a JPG file would now result in the file having an anti-aliased outer edge so depending on what you did with this file next you would potentially see this, e.g., if part of a triptych of images assembled in a similar fashion to your three iPhone images.

There is no way around this (apart from turning anti-aliasing off altogether but that would cause no end of issues with your images), that is just the nature of how this works.

Affinity Designer 1.7.3, Affinity Photo 1.7.3, Affinity Publisher 1.10.1 | Affinity Designer Beta 1.10.3.1, Affinity Photo Beta 1.10.2.266 | MacBook Pro 16GB, macOS Monterey 12.5

Link to comment
Share on other sites

10 hours ago, Hangman said:

By default if each of your three images were 333,333 pixels in width, the edges would already be anti-aliased so regardless of snapping them together you will still see the issue because you will have transparent pixels on the image edges but more than happy if you want to upload a Keynote file that demonstrates what you are seeing...

I was unsure if you were referring Keynote/Pages/Numbers here since each limits you to a 400% zoom and whilst you can enter decimal places, they automatically round to the nearest whole point. I think you also have to bear in mind that Keynote, Pages and Numbers are not designed for this purpose in the first place, being presentation, word processing and spreadsheet software.

That makes sense, thanks for letting me know...

Thinking about this as a gap is perhaps misleading, it's not an actual, physical gap, it is transparent pixels. If you take a look at this image and note how the two grey squares are positioned and how they both use fractional pixels. Even though they are snapped together and perfectly aligned, because they don't use whole pixel values the edges of the squares are anti-aliased, i.e., rendered using semi-transparent pixels. You can see this by looking at the vertical gradated line on the left which appears muted because the gradated background beneath the grey squares is showing through semi-transparent pixels. The vertical line to the right shows how the actual background looks without the transparent pixels, i.e., without any anti-aliasing.

So the hairline/gap that this conversation has all been about is simply the result of unavoidable anti-aliasing, it is the way software renders fractional pixels when the smallest unit available is one pixel.

Using whole pixel dimensions and positioning at whole pixel values removes the need for any anti-aliasing and hence you won't see any hairline/gap.

Anti-aliasing.thumb.jpg.84ce6b78f1cc7cbfdd5e2a71efc3adab.jpg

In this instance your original exported PDF would have no hairline/gaps if all created in a single document and exported. Bringing it into Photoshop or Affinity Photo and transforming it so it now has a height of 56.67px and exporting it to say a JPG file would now result in the file having an anti-aliased outer edge so depending on what you did with this file next you would potentially see this, e.g., if part of a triptych of images assembled in a similar fashion to your three iPhone images.

There is no way around this (apart from turning anti-aliasing off altogether but that would cause no end of issues with your images), that is just the nature of how this works.

1068246721_Screenshot2021-08-13at04_29_52.png.c994d619354b7e6df199a1be5b4dc032.png

 

1781356586_Screenshot2021-08-13at04_33_03.png.2b5aaf0cad92b0378dc604973a160492.png

 

There's no background color peeping through. There's no PLACE for it to peep through. The objects are one next to another. Their colors are the only colors a pixel should ever be allowed to see and the only colors a pixel should be allowed to display.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

10 hours ago, Hangman said:

There is no way around this (apart from turning anti-aliasing off altogether but that would cause no end of issues with your images), that is just the nature of how this works.

Then change it.

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

33.3333333333333% size shape in Keynote — no gaps.

The same exported PDF with identical dimensions when viewed in Affinity — welcome gaps!

Do I seriously need to go on… #gapGate #endTheGap2024

Screenshot 2021-08-13 at 04.45.40.png

Screenshot 2021-08-13 at 04.45.48.png

Hackintosh running Big Sur 11.2.3, Coffe Lake i3 with UHD630 graphics

MacBook (Early 2015) running macOS Mojave

iPad Pro 11-inch (1st generation) running iPadOS 13.5

Vista PC in the attic 

Link to comment
Share on other sites

8 hours ago, konstantnnn said:

The objects are one next to another. Their colors are the only colors a pixel should ever be allowed to see and the only colors a pixel should be allowed to display.

From as far as I can tell, Designer does the AA on a per-object basis. Hence the background affects each object. Doing as you suggest whilst I guess technically possible would likely be significantly slower to calculate.

The pan/zoom, object moving, colour changes, everything requires the canvas display to be recalculated on the fly (we are talking milliseconds for each full redraw). I imagine the AA approach is done the way it is to keep a nice smooth frame rate.

Link to comment
Share on other sites

On 8/13/2021 at 3:37 AM, konstantnnn said:

1068246721_Screenshot2021-08-13at04_29_52.png.c994d619354b7e6df199a1be5b4dc032.png

 

1781356586_Screenshot2021-08-13at04_33_03.png.2b5aaf0cad92b0378dc604973a160492.png

 

There's no background color peeping through. There's no PLACE for it to peep through. The objects are one next to another. Their colors are the only colors a pixel should ever be allowed to see and the only colors a pixel should be allowed to display.

 

On 8/13/2021 at 3:37 AM, konstantnnn said:

There's no background color peeping through. There's no PLACE for it to peep through. The objects are one next to another. Their colors are the only colors a pixel should ever be allowed to see and the only colors a pixel should be allowed to display.

That's not how anti-aliasing works... Anti-aliasing uses semi-transparent pixels to simulate smoothing, so by the very nature of having semi-transparent pixels you will see a change in colour peeping through which is a blend between the top and the underlying colours... The balance between the two colours can be controlled by adjusting the Blend Gamma values for specific layers.

Hopefully these videos will demonstrate how a single pixel appears when rasterised using your example. Both show a 6px x 1px document, the first showing the two background colours/shapes pixel aligned, the second (as per your example), non-pixel aligned. I've then simply dragged a 1px x 1px teal coloured square across the background so you can see how the anti-aliasing blends both the background and pixel colours.

Pixel Aligned Background

 

Non Pixel Aligned Background

The graphic below shows a breakdown of the above process, with the background pink and yellow elements pixel aligned on the top row and non-pixel aligned (as per your graphic) on the bottom row of each graphic...

1705730248_Anti-aliasingComp.thumb.jpg.0926342ce20eb13878e535ac38b1b4d6.jpg

Bear in mind that vector graphics still have to be rasterised so they can be displayed on a screen that uses pixels, to achieve this vector software applies (to differing degrees) anti-aliasing to the vector elements. Since the effect of anti-aliasing is to blend the colour of the top most layer with the underlying colour this means when placing e.g., four squares adjacent to each other, even when perfectly pixel aligned you will see the hairline appear at the intersection of the squares because this is where the anti-aliasing is visible.

The hairline is a screen rendering issue only, if items are pixel aligned for screen then the hairlines don't appear on raster export and likewise the hairlines don't appear on final print resolution PDF artwork once printed either.

This issue is inherent in all vector based software, AD, Illustrator, Inkscape and so on. I believe in more recent versions of illustrator they have addressed the issue to some degree, possibly by changing the way vector graphics are anti-aliased, but from what I've seen (I don't use Illustrator so I can't test this) this results in the vector graphics having a soft appearance on-screen so they've almost cut off their nose to spite their face.

On 8/13/2021 at 3:38 AM, konstantnnn said:

Then change it.

It's really not as simple as that, if it were we wouldn't be seeing this issue...

 

On 8/13/2021 at 3:47 AM, konstantnnn said:

33.3333333333333% size shape in Keynote — no gaps.

This isn't the case, it just happens not to be noticeable in your Keynote example. Take the same shapes (add one additional square) using the same dimensions and rotate them 45 degrees then the hairlines are visible (they're faint in my screengrab, but they are still visible). I don't know how Apple applies it's anti-aliasing, it may differ from AD, Illustrator, Inkscape and so on but regardless the same hairlines appear. You will likely see this more clearly if you do the same thing with your Keynote example.

1664561077_KeynoteExport.thumb.jpg.77b8e14f9a774199b970e11767064447.jpg

You will also likely have seen that the visibility of these hairlines is dependent on the level of zoom you are viewing the graphic at, with some zoom levels the hairlines seemingly vanish but then reappear if zooming in or out further.

Because this is fundamentally a screen rendering issue, if the hairlines are a distraction you can remove/hide them altogether simply by disabling anti-aliasing. This can be done on a layer by layer basis or you can put any or all your graphics inside a Group and set the anti-aliasing state for the group. By default the elements contained within the group are set to Inherit so changing the rendering intent of the parent will automatically affect all the contained layers.

Equally you can overide the anti-aliasing for individual layers within the group by setting the layer's value to either Force On or Force Off.

 

 

 

 

 

 

Affinity Designer 1.7.3, Affinity Photo 1.7.3, Affinity Publisher 1.10.1 | Affinity Designer Beta 1.10.3.1, Affinity Photo Beta 1.10.2.266 | MacBook Pro 16GB, macOS Monterey 12.5

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

×
×
  • Create New...

Important Information

Please note there is currently a delay in replying to some post. See pinned thread in the Questions forum. These are the Terms of Use you will be asked to agree to if you join the forum. | 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.