Aligned objects not actually aligned

[konstantnnn]

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

 

 

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

 

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

 

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

 

 

Visible Hairline Onscreen No Longer Visible When Coverage Map Setting Adjusted

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

 

 

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.

[konstantnnn]

1 minute ago, konstantnnn said:

until I can submit my work to an agency.

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

[Hangman]

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.

 

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.

 

[konstantnnn]

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.

 

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.

[konstantnnn]

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.

[konstantnnn]

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

[konstantnnn]

I just spelled it cockscrew..

[Hangman]

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.

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.

[konstantnnn]

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.

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.

 

 

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.

[konstantnnn]

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.

[konstantnnn]

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

[Hangman]

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.

 

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

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.

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.

 

 

 

 

 

 

[konstantnnn]

5 hours ago, Hangman said:

 

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

Its working wrong.

Yes that is how it works…If i have a single shape and a background. Not when I have two shapes next to one another and no logical way of the background color peeping through.

 

If two objects are one next to another taking up 30% of a pixel and 60% of a pixel, the semitransparency of one should be added to the semi transparency of the other altogether, because there's no background VISIBLE THERE to contribute to the pixel's final color output!!! Just as how there's no background visible WHEN YOU DO perfectly pixel align —because they are ALIGNED!!! one next to another! with m a g n e t s

Let me draw this in an another way, if I perfectly-force-pixel-align two shapes (and there's no gap), I then GROUP THEM, RASTERIZE THEM, and start moving them without force-pixel-alignment, NO gaps would EVER show because there isn't any space for the background to peep through because they were perfectly magnetically snapped in the first place!! This is how it should work if they werent rasterized in the first place.

I don't care! how all of it works, and I don't care about any more explanations that just explain to me how something works..that's WRONG!

I haven't checked affinity forums and was working on a project and again encountered gaps now with STROKES, the underlying color of the stroke is peeping at the edge. It took me again here. This is unbelievable! I should apply a stroke and GO. I don't care! why I can't, I should, and anyone who gives two cents about developing great software would care too.

Imagine where would the computer world be right now if all the way back people snarked suggestions of fixing technical limitations and literal bugs in how software works. I can't imagine a more depressing thought. 

[Hangman]

21 hours ago, konstantnnn said:

Not when I have two shapes next to one another and no logical way of the background color peeping through.

The background is able to peep through because the edges of both adjoining, perfectly pixel aligned graphics are rasterised and anti-aliased so they can be displayed on your screen, so the edges themselves are now semi-transparent regardless of their perfect pixel alignment.

This is how all vector graphics software works regardless of who makes it, can you think of any vector software that doesn't demonstrate this issue?

21 hours ago, konstantnnn said:

if I perfectly-force-pixel-align two shapes (and there's no gap), I then GROUP THEM, RASTERIZE THEM, and start moving them without force-pixel-alignment, NO gaps would EVER show because there isn't any space for the background to peep through because they were perfectly magnetically snapped in the first place!! This is how it should work if they werent rasterized in the first place.

Correct if you mean converting to a single object, e.g., exporting your original three iPhone images to a JPG file. That JPG file if opened in AD will no longer display the hairlines because there are no longer any rasterised, anti-aliased, adjacent edges between what used to be three adjacent images.

21 hours ago, konstantnnn said:

I don't care! how all of it works, and I don't care about any more explanations that just explain to me how something works..that's WRONG!

The point is, it's not wrong, it's a technilogical limitation of how rasterising and anti-aliasing an object-based vector graphic on a pixel based LCD screen works. If you were able to view this on a vector monitor the issue wouldn't exist.

It appears to be wrong to your way of thinking but it's not wrong from a technological point of view. I'm sure at some point in the future technology will move on and new ways of displaying vector graphics will be developed but for now, this is where we're at.

I think we can agree to disagree but the facts are the facts. I'm not a computer scientist but I'm sure there are other more eminently qualified people who can describe in far more detail how the rasterisation and anti-aliasing of vector objects works when displaying them on a pixel based display and what the techological limitations are.

Fact - the white or dark lines are be caused by anti-aliasing of an application where the two regions intersect. Turning off the anti-aliasing eliminates these lines.

If the hairlines bother you why not simply turn off the anti-aliasing as suggested in my previous post?

 

21 hours ago, konstantnnn said:

I haven't checked affinity forums and was working on a project and again encountered gaps now with STROKES, the underlying color of the stroke is peeping at the edge.

I'm unsure how you've constructed you current graphic but I would construct it like this and then there would be no visible gaps? I've made the vertical line orange just to show the three shapes...

Can you either upload just the graphic itself or explain how you've created it so we can understand why you are seeing the gap?

[konstantnnn]

Quote

The background is able to peep through because the edges of both adjoining, perfectly pixel aligned graphics are rasterised and anti-aliased so they can be displayed on your screen, so the edges themselves are now semi-transparent regardless of their perfect pixel alignment.

We are talking about images that are not rasterized now. Un rasterized images. We are talking about how does a vector program interpret and pixel-display raster objects. An outside frame of every image imported into Affinity can be looked as a vector rectangle. We're talking about adjacent OBJECTS having arbitrary GAPS.

The question is awfully simple, should there be a gap between two adjacent objects? To make it simpler for us to understand, I googled the definition of adjacent,  "next to or adjoining something else". Next to. It's next to. Should there be an arbitrary gap to something that's magnetically snapped together?

It's awfully simple.

It's so, amazingly simple.

Should there be a gap between gapless snapped objects?

I don't care if they are at Retina resolution, 20X resolution, Infinite vector resolution, on Mars, on Jupiter, on my or my sister's computer, in milimiters, inches, meters set to seventy decimal places, half pixels, quadpixels or seventy bilionth-part of a pixel. Should there be a gap between gapless snapped objects? To objects that are ending and starting on the same physical number. The same number. 

The answer is obviously no!

Quote

It appears to be wrong to your way of thinking

I think this is common sense. This isn't anything crazy, to think two supposedly gaplessly adjacent objects — implied both by the "magnet" icon of the snapping tool and the literal position numbers ending in one place and at the same place beginning the other — and implied by the "infinite zoom" paradox of the program where it's obvious that this is a rendering glitch and the logical outline - literal position information is pretty clear about this. There's no place for the background to peep through. They are adjacent. Wikidictionary again? Or?

5 hours ago, Hangman said:

The background is able to peep through

And it shouldn't. 

5 hours ago, Hangman said:

why not simply turn off the anti-aliasing as suggested in my previous post?

Because I seriously thought you were britishly sarcastic. All of my images and graphics will start to look like bad Windows 95 graphics? What kind of question is …that………….. At this point, a much more relevant question would be "why use this program" again

5 hours ago, Hangman said:

This is how all vector graphics software works regardless of who makes it, can you think of any vector software that doesn't demonstrate this issue?

Keynote comes to mind, there are no gaps with all straight-aligned images and halfpixel/.3333 pixel stuff and freehand and etc and etc. When you do a degree turn and rotate it then that's the only time it ever shows this. Which means that the problem partially or completely is solvable in the first place, like Keynote already did non-rotated objects (which my main issue is about). Keynote already solved it (look above). When you rotate it, there is an issue in Keynote, but I do know if those engineers cared enough they would fix that as well. It is solvable.

Technical limitations are meant to be broken. That's how you make better software. That's what feedback forums are all about and all for. That is the purpose of filing feedback. 

I see no point in utterly defending a technical limitation instead of saying "yup, hope they fix it". You're using it wrong is not a proper answer. 

5 hours ago, Hangman said:

I think we can agree to disagree but the facts are the facts.

I still think this is a joke. You can't possibly say that you agree that gaps should appear on perfectly adjacent objects. You're the man!

 

 

 

Shifting gears

Correct me if I'm wrong, but a part of the confusion maybe also comes from the thought "how should the dispalay engine treat snapped sub-opacity antialiased edges". Isn't it? Let's have an example. I have an object (could be a square image, or a literal square, doesn't really matter — to the "outline view", it's just a square so that's why I use the term object/square/image interchangeably throughout this post).

1) My image is mostly pixel aligned, but there's a single vertical line of pixels on the right which the image doesn't fill fully. In fact, the image covers just about 0,000002% of those pixels.

2) When I bring a second image and snap it to the first one, logically (the program, PDF engine, outline view and snapping engine) know that they are one next to another. The display engine, however, almost acts to ignore this. The display engine is looking at that single vertical line of pixels, and literally it's like it's saying "well, these pixels are filled by an image, so let me start rendering from the next line where there are no pixels filled"!

The display engine almost seems to fail to understand that, yes, these pixels are filled by an image, but there is still more room to be filled. In fact, there is 99,9999998% of room left empty, but the display engine seems to ignore that and to count this very binary — either its full or empty.

This is a flaw of the engine. And when you keep zooming in, it's almost as if you're shaking the program to wake up from a hangover; it's reducing and reducing and reducing the gap as you keep zooming in and zooming in and zooming in — but it's an infinite cat and mouse game.

My issue is with all of this, and the way I'm proposing it is to let the logical way win.

If the developers started going from that, upwards, from the core idea to the technology, they would make a superior display engine.

I don't care if it's a huge leap or (or for) a small insignificant thing. That's what I would do if I knew how to code. If I had a team. That's what Steve Jobs's core vision was when he made the first mac. That's the right thing to do. That's how I approach all of my design work.

 

Document.zip

[konstantnnn]

5 hours ago, Hangman said:

The background is able to peep through because the edges of both adjoining, perfectly pixel aligned graphics are rasterised and anti-aliased so they can be displayed on your screen, so the edges themselves are now semi-transparent regardless of their perfect pixel alignment.

This is how all vector graphics software works regardless of who makes it, can you think of any vector software that doesn't demonstrate this issue?

Correct if you mean converting to a single object, e.g., exporting your original three iPhone images to a JPG file. That JPG file if opened in AD will no longer display the hairlines because there are no longer any rasterised, anti-aliased, adjacent edges between what used to be three adjacent images.

The point is, it's not wrong, it's a technilogical limitation of how rasterising and anti-aliasing an object-based vector graphic on a pixel based LCD screen works. If you were able to view this on a vector monitor the issue wouldn't exist.

It appears to be wrong to your way of thinking but it's not wrong from a technological point of view. I'm sure at some point in the future technology will move on and new ways of displaying vector graphics will be developed but for now, this is where we're at.

I think we can agree to disagree but the facts are the facts. I'm not a computer scientist but I'm sure there are other more eminently qualified people who can describe in far more detail how the rasterisation and anti-aliasing of vector objects works when displaying them on a pixel based display and what the techological limitations are.

Fact - the white or dark lines are be caused by anti-aliasing of an application where the two regions intersect. Turning off the anti-aliasing eliminates these lines.

If the hairlines bother you why not simply turn off the anti-aliasing as suggested in my previous post?

 

I'm unsure how you've constructed you current graphic but I would construct it like this and then there would be no visible gaps? I've made the vertical line orange just to show the three shapes...

Can you either upload just the graphic itself or explain how you've created it so we can understand why you are seeing the gap?

Take a look at the jointing curve in the "Artboard 2" of the document! Enter pixel view, or even make the insides of the clock hand darker. It's pretty jarring. 

Could you provide me a solution to thatDocument.zip

[Hangman]

10 hours ago, konstantnnn said:

Take a look at the jointing curve in the "Artboard 2" of the document! Enter pixel view, or even make the insides of the clock hand darker. It's pretty jarring. 

Could you provide me a solution to thatDocument.zip

This is a known issue and relates to the stroke alignment. Stroke Inside creates the artifacts you are seeing. Supposedly setting Stoke Outside should correct the issue, which it does but I've noticed that Stroke Outside then creates a new issue with artifacts (see below middle, you may need to zoom into the image to see the problem).

The workaround in this instance is to use Stroke Centre which eliminates both issues.

The issue has been reported previously here and has been raised with the Dev team to look into...

I would be inclined to raise this as a new 'bug' or 'issue', especially in light of the additional artifacts introduced with your particular graphic when using Stoke Outside.

[Hangman]

@konstantnnn Firstly, let me preface this reply by saying, I agree with everything you are saying 110% BUT the point I've been trying to convey (perhaps very unsuccessfully) is, that it's really not that simple as I think @BofG is illuding to as well...

I'm doing my best to try and explain both the complexities, together with possible workarounds (solutions would perhaps be the wrong terminology here I think).

23 hours ago, konstantnnn said:

Should there be a gap between gapless snapped objects?

Absolutely not - but equally you have to understand the techonological limitations we are dealing with here. I appreciate (as you've eloquently stated) that you're not really interested in the technical aspects.

23 hours ago, konstantnnn said:

There's no place for the background to peep through.

I would happily post numerous OpenGL links to the complexities of rendering and anti-aliasing in terms of Multisampling, Box Filtering, Coverage and Primitave Edges but I really do understand this is perhaps not what interests you with regards to this issue (I get it, I have no problem with that). I'm absolutely not trying to defend any corner here, the point I've been trying to make is that with the limitations in current technology, implementing things like Multisampling could and likely would have a BIG detrimental impact on software performance to the extent that people would no longer be raising the issue of the visible hairlines/gaps but would instead be complaining about poor application performance.

23 hours ago, konstantnnn said:

The background is able to peep through - and it shouldn't. 

In a perfect world, again I agree 110%

23 hours ago, konstantnnn said:

Why not simply turn off the anti-aliasing as suggested in my previous post?

Because I seriously thought you were britishly sarcastic. All of my images and graphics will start to look like bad Windows 95 graphics? What kind of question is …that………….. At this point, a much more relevant question would be "why use this program" again

Glad you appreciate the nuances of British sarcasm (it's one of the few things we're good at)... 😂

This is a bit of a two-sided coin, the harline issue is a purely on-screen visual problem and a direct result of anti-aliasing rendering techniques. As such it has no impact on printed images, i.e., offset litho printing or high-resolution inkjet printing but of course it does impact raster images for online use. My suggestion to turn off anti-aliasing in AD was meant in terms of, if it annoys/frustrates you from a visual working standpoint, then turning it off would overcome that (as in the hairlines would no longer be visible) and would have no impact if your artwork was for print.

Clearly if the end use is on-screen, for web, then you wouldn't disable anti-aliasing unless you were going for an early space invaders/asteroids video game look, (I'd assumed, righly or wrongly, that was a given).

23 hours ago, konstantnnn said:

I think this is common sense. This isn't anything crazy, to think two supposedly gaplessly adjacent objects — implied both by the "magnet" icon of the snapping tool and the literal position numbers ending in one place and at the same place beginning the other — and implied by the "infinite zoom" paradox of the program where it's obvious that this is a rendering glitch and the logical outline - literal position information is pretty clear about this. There's no place for the background to peep through.

This really is where the nuances of Multisampling vs Performance potentially come into play, that's not to say that with ever improving processor performance this couldn't be addressed moving forward (though you always have to consider the lowest common demoninator where computer performance is concerned/supported). This was the initial response from Serif with regards this very issue (albeit toward the end of 2015).

Quote

You will get this hairline in any vector program to a greater or lesser extent whenever two edges are exactly the same value... It's a side-effect of the way the rasterisation routine works... There are ways to reduce the effect, but to solve it completely really needs a different approach to the rasterisation (that nobody uses because it provides worse results in other cases). The effects will change based on the exact zoom level and position of the objects on a sub-pixel, but they will always be there. The easiest way to get rid of these is simply to extend objects to overlap in ways that don't matter, and to overlap and 'Add' objects of the same colour to form one object from two that used to butt up to each other. You could also try using the advanced blending options (the cog on the Layers panel) with your objects selected and adjust the antialiasing ramp to include more of the pixels.

We will continue to try to improve this over time, but it is an inherent problem with any vector drawing program (although some do deliberately distort the values you asked for in order to reduce the appearance of this effect, so they seem to be working better - although you can make them fail if you know how...)

 

23 hours ago, konstantnnn said:

Me: Can you think of any vector software that doesn't demonstrate this issue?

You: Keynote comes to mind...

This is all well and good but as soon as you want to produce a repeating pattern using triangles, hexagons or any other shapes using angles other than 0° or 90° then you'd be facing the same problem and Keynote is not AD. I appreciate what you say about their rendering when using squares, I have no idea the rendering techniques used in Keynote, they could simply be very basic, (they are certainly not as advanced as AD) hence no visible hairlines on vertical and horizontal shapes, you'd have to ask an Apple engineer.

 

23 hours ago, konstantnnn said:

Shifting gears

Correct me if I'm wrong, but a part of the confusion maybe also comes from the thought "how should the dispalay engine treat snapped sub-opacity antialiased edges". Isn't it? Let's have an example. I have an object (could be a square image, or a literal square, doesn't really matter — to the "outline view", it's just a square so that's why I use the term object/square/image interchangeably throughout this post).

1) My image is mostly pixel aligned, but there's a single vertical line of pixels on the right which the image doesn't fill fully. In fact, the image covers just about 0,000002% of those pixels.

2) When I bring a second image and snap it to the first one, logically (the program, PDF engine, outline view and snapping engine) know that they are one next to another. The display engine, however, almost acts to ignore this. The display engine is looking at that single vertical line of pixels, and literally it's like it's saying "well, these pixels are filled by an image, so let me start rendering from the next line where there are no pixels filled"!

The display engine almost seems to fail to understand that, yes, these pixels are filled by an image, but there is still more room to be filled. In fact, there is 99,9999998% of room left empty, but the display engine seems to ignore that and to count this very binary — either its full or empty.

This is a flaw of the engine. And when you keep zooming in, it's almost as if you're shaking the program to wake up from a hangover; it's reducing and reducing and reducing the gap as you keep zooming in and zooming in and zooming in — but it's an infinite cat and mouse game.

My issue is with all of this, and the way I'm proposing it is to let the logical way win.

If the developers started going from that, upwards, from the core idea to the technology, they would make a superior display engine.

I don't care if it's a huge leap or (or for) a small insignificant thing. That's what I would do if I knew how to code. If I had a team. That's what Steve Jobs's core vision was when he made the first mac. That's the right thing to do. That's how I approach all of my design work.

Whilst I don't disagree with you, I think if you had this conversation with any software engineer they would be able to tell you, far more eloquently than I ever could, why this approach is currently likely not possible/impractical.

Who knows, maybe that will all change in v2.0 of Affinity's software. I'm not a software programmer, my knowledge is relatively limited and maybe things will change with regards rendering engines/techniques moving forward to address this issue, not only in AD but in pretty much all vector software.

Maybe you can pose the question/issue in the Affinity Support and Questions forum. I think it will elicit a minefield of opinions but the hope would be an update from Serif as to the current viability of improving this anti-aliasing issue... (just my 2 cents worth).

There are easy workarounds, though they are just that just that, workarounds, e.g., experiment with the Contour tool, it does a very good job of 'overcoming' this issue. Take for example a 700 x 700px donut shape or a 500 x 500px square (or any suitable shape using any dimensions), split the donut in half so it takes up 50% of the circle, duplicate it and flip it so you have two adjoining, perfectly pixel aligned shapes to make a complete donut or duplicate the square and snap it so it appears adjacent to the first square. In both instances you will see the hairline/gap issue. Make the shapes 2px smaller in width and height then add a 1px contour (with no stroke) to either. Result, overlapping vectors the same size as the original shapes but exhibiting no gap/hairlines on-screen or on export to any raster image format.

Is it the perfect solution, no, of course not but it's a viable option for now me thinks...

[konstantnnn]

1 hour ago, Hangman said:

@konstantnnn Firstly, let me preface this reply by saying, I agree with everything you are saying 110% BUT the point I've been trying to convey (perhaps very unsuccessfully) is, that it's really not that simple as I think @BofG is illuding to as well...

I'm doing my best to try and explain both the complexities, together with possible workarounds (solutions would perhaps be the wrong terminology here I think).

Absolutely not - but equally you have to understand the techonological limitations we are dealing with here. I appreciate (as you've eloquently stated) that you're not really interested in the technical aspects.

I would happily post numerous OpenGL links to the complexities of rendering and anti-aliasing in terms of Multisampling, Box Filtering, Coverage and Primitave Edges but I really do understand this is perhaps not what interests you with regards to this issue (I get it, I have no problem with that). I'm absolutely not trying to defend any corner here, the point I've been trying to make is that with the limitations in current technology, implementing things like Multisampling could and likely would have a BIG detrimental impact on software performance to the extent that people would no longer be raising the issue of the visible hairlines/gaps but would instead be complaining about poor application performance.

In a perfect world, again I agree 110%

Glad you appreciate the nuances of British sarcasm (it's one of the few things we're good at)... 😂

This is a bit of a two-sided coin, the harline issue is a purely on-screen visual problem and a direct result of anti-aliasing rendering techniques. As such it has no impact on printed images, i.e., offset litho printing or high-resolution inkjet printing but of course it does impact raster images for online use. My suggestion to turn off anti-aliasing in AD was meant in terms of, if it annoys/frustrates you from a visual working standpoint, then turning it off would overcome that (as in the hairlines would no longer be visible) and would have no impact if your artwork was for print.

Clearly if the end use is on-screen, for web, then you wouldn't disable anti-aliasing unless you were going for an early space invaders/asteroids video game look, (I'd assumed, righly or wrongly, that was a given).

This really is where the nuances of Multisampling vs Performance potentially come into play, that's not to say that with ever improving processor performance this couldn't be addressed moving forward (though you always have to consider the lowest common demoninator where computer performance is concerned/supported). This was the initial response from Serif with regards this very issue (albeit toward the end of 2015).

 

This is all well and good but as soon as you want to produce a repeating pattern using triangles, hexagons or any other shapes using angles other than 0° or 90° then you'd be facing the same problem and Keynote is not AD. I appreciate what you say about their rendering when using squares, I have no idea the rendering techniques used in Keynote, they could simply be very basic, (they are certainly not as advanced as AD) hence no visible hairlines on vertical and horizontal shapes, you'd have to ask an Apple engineer.

 

Whilst I don't disagree with you, I think if you had this conversation with any software engineer they would be able to tell you, far more eloquently than I ever could, why this approach is currently likely not possible/impractical.

Who knows, maybe that will all change in v2.0 of Affinity's software. I'm not a software programmer, my knowledge is relatively limited and maybe things will change with regards rendering engines/techniques moving forward to address this issue, not only in AD but in pretty much all vector software.

Maybe you can pose the question/issue in the Affinity Support and Questions forum. I think it will elicit a minefield of opinions but the hope would be an update from Serif as to the current viability of improving this anti-aliasing issue... (just my 2 cents worth).

There are easy workarounds, though they are just that just that, workarounds, e.g., experiment with the Contour tool, it does a very good job of 'overcoming' this issue. Take for example a 700 x 700px donut shape or a 500 x 500px square (or any suitable shape using any dimensions), split the donut in half so it takes up 50% of the circle, duplicate it and flip it so you have two adjoining, perfectly pixel aligned shapes to make a complete donut or duplicate the square and snap it so it appears adjacent to the first square. In both instances you will see the hairline/gap issue. Make the shapes 2px smaller in width and height then add a 2px contour (with no stroke) to either. Result, overlapping vectors the same size as the original shapes but exhibiting no gap/hairlines on-screen or on export to any raster image format.

Is it the perfect solution, no, of course not but it's a viable option for now me thinks...

Thanks for the great response!

[konstantnnn]

I mean I must admit I was using these workarounds, like increasing the size, overlapping, or in some cases multi-layered overlapped divided extracted strokes to achieve an inside-stroke-look I wanted, I was extending images, where there was a "gap" I would duplicate the original shape, and center it and put it behind the two shapes, I was constantly doing so much for years now that I just felt enough compelled to write some feedback about it. It would be really, really nice to just not think about it. I agree I may sound to a technical engineer, a bit, arrogantly blonde.

[konstantnnn]

14 hours ago, BofG said:

@konstantnnn I can see your way of thinking, and you almost had me convinced of your way of seeing things. Then I started thinking about technically how it could be implemented (many (many) years ago I was a (not very good) programmer). As I started digging into things, I realised the key point that hasn't been addressed here - the layers have a stacking order. Your rectangles are visually next to each other but they are on a different plane (aka z-index).

See the attached document. Four non-pixel aligned rectangles, the top two are on different layers and so on a different plane to each other. The bottom two rectanges have been moved onto the same plane of existance by merging the curves and hence show no AA effect and they are stilll separate objects. Use the pixel view mode to see.

I don't have time to go into all the details of the why, but if you start moving away from a simple case of two rectangles and into more complex setups it quickly becomes an intractable problem. E.g. have a shape cross that boundary below one rectangle and above the other. Maybe that shape has a blend mode, maybe it has transparancy, maybe it's a compound with a different winding mode. It's a hard problem.

AA-planes.afdesign 1.35 MB · 6 downloads

Thank you for highlighting this. This actually may be added to my list of workarounds, merging curves.