Seams between objects

[R C-R]

3 hours ago, JimmyJack said:

In reality though, by overlapping you've just shifted the problem right?

 

I think that in reality the problem is exactly what @TonyB said it was in his first reply in this topic:

Quote

All vector edges get anti-aliased so two separate edges will have a faint line between them unless they are aligned exactly on a pixel boundary.

 

Unless I am missing something, that is only possible for the very specific case of rectilinear vector shapes perfectly aligned to the horizontal & vertical axes on pixel boundaries -- any vector with a curved or diagonal edge can only be rendered with reasonable accuracy on screen using anti-aliasing. The alternative of not anti-aliasing anything isn't very desirable because of the uncertainty that introduces with where the edge actually is at any time there is not an exact integer match between screen & document pixels.

[Lionel Seidman]

@TonyB maybe you can weight in here.  I am trying to speak with somebody on the Designer engineering team about the idea of fixing the underlying problem here once and for all, so we don't need to continue using these sorts of workarounds.

 

I am quite sure that the problem can be solved, and I'd be happy to explain to somebody how to do it.

 

Do you know who I might be able to speak to about this?

 

[JimmyJack]

17 hours ago, R C-R said:

 

I think that in reality the problem is exactly what @TonyB said it was in his first reply in this topic:

 

Unless I am missing something, that is only possible for the very specific case of rectilinear vector shapes perfectly aligned to the horizontal & vertical axes on pixel boundaries -- any vector with a curved or diagonal edge can only be rendered with reasonable accuracy on screen using anti-aliasing. The alternative of not anti-aliasing anything isn't very desirable because of the uncertainty that introduces with where the edge actually is at any time there is not an exact integer match between screen & document pixels.

 

Rather than addressing your explanation, why don't we just go head to head.

 

Your file (with a curve added) in all black to really get a good look, saved as a png from AffinityD and from Illustrator.

I'll let you guess which is which.

(the difference is actually much more pronounced out of a browser (mine at least)... such as in AD itself and elsewhere like Preview)

 

 

 

16 hours ago, Lionel Seidman said:

@TonyB maybe you can weight in here.  I am trying to speak with somebody on the Designer engineering team about the idea of fixing the underlying problem here once and for all, so we don't need to continue using these sorts of workarounds.

 

I am quite sure that the problem can be solved, and I'd be happy to explain to somebody how to do it.

 

Do you know who I might be able to speak to about this?

 

 

The fact that they call this normal is the most distressing thing of all. If it's so normal why are there constantly people trying to come over from Ai saying "HEY what's up with these lines??"

It's like they've resigned themselves to this result. At one point I remember a response from the Devs that included something like.... but we're working on improving this. But I haven't seen that included in a reply for a long time. It would be nice to at least "hear" again.

Or maybe it's just not resolvable with the render engine approach they've chosen?

I'm not saying AI is perfect all the time, but come on right? Night and day.

 

 

[R C-R]

7 hours ago, JimmyJack said:

I'm not saying AI is perfect all the time, but come on right? Night and day.

But which one is more accurate; that is, true to the underlying geometry of the vectors?

[Lionel Seidman]

On 3/23/2018 at 7:15 PM, R C-R said:

But which one is more accurate; that is, true to the underlying geometry of the vectors?

 

The geometry isn't really the concern here.  The problem is the seam between one polygon and another.  Ai handles these sorts of seams quite nicely, while Designer does not, so in that sense, Ai is more accurate.

[R C-R]

20 minutes ago, Lionel Seidman said:

The geometry isn't really the concern here.

If the accuracy of the geometry of vector objects is of no concern to you, why even bother designing with vectors? Why not just rasterize everything?

[Lionel Seidman]

1 hour ago, R C-R said:

If the accuracy of the geometry of vector objects is of no concern to you, why even bother designing with vectors? Why not just rasterize everything?

 

I didn't mean to say that the geometry is of no concern to me in general, just that the geometry of the shapes looks fine, and that I am not concerned about it misbehaving.

 

The only thing I am concerned about is the seams between pieces of geometry.  If two pieces of geometry are exactly adjacent to each other, and when we rasterize the geometry we are able to see remnants of the background color showing through the seams, then I would say the program is misbehaving.

[R C-R]

6 hours ago, Lionel Seidman said:

If two pieces of geometry are exactly adjacent to each other, and when we rasterize the geometry we are able to see remnants of the background color showing through the seams, then I would say the program is misbehaving.

What we are seeing is anti-aliasing, a consequence of rasterizing vector geometry. That converts it to pixels, each of which can have only one color. It has nothing directly to do with the background color, only with the difference in the colors along the seams.

[MikeW]

And just because I'm miffed, Illy's export is correct (as well as the other vector editors and even layout applications I use) and AD's is faulty. 

 

Sooner or later this issue will be addressed by Serif. 

[Lionel Seidman]

49 minutes ago, R C-R said:

What we are seeing is anti-aliasing, a consequence of rasterizing vector geometry. That converts it to pixels, each of which can have only one color. It has nothing directly to do with the background color, only with the difference in the colors along the seams.

 

I understand that anti-aliasing is being applied as we convert vector data into raster data, but what I am saying is that the way in which the anti-aliasing is being applied is creating faulty output in which the background color is improperly bleeding through.

 

Let's suppose we have a pixel that is exactly on the seam between two objects.  One way to render that pixel would be to draw object number one using anti-aliasing (giving us a 50/50 mix of the object color and the background color) and then to draw object number two using anti-aliasing, giving us a 50/25/25 mix of objects 2, 1, and the background color.  This appears to be the way Designer is doing things right now, and as you can see this gives us the wrong result!  The final color for this pixel should be a 50/50 mix of the color in objects 1 and 2, with no weight given to the background color.

 

It is definitely possible to achieve correct looking output in this situation, and we know that other programs are already doing so, such as Ai.

 

What I am looking for is someone within the Designer team to address this concern to.  If this is the wrong channel for that, I'd appreciate if someone could point me in the right direction.

[TonyB]

5 hours ago, Lionel Seidman said:

 

I understand that anti-aliasing is being applied as we convert vector data into raster data, but what I am saying is that the way in which the anti-aliasing is being applied is creating faulty output in which the background color is improperly bleeding through.

 

Let's suppose we have a pixel that is exactly on the seam between two objects.  One way to render that pixel would be to draw object number one using anti-aliasing (giving us a 50/50 mix of the object color and the background color) and then to draw object number two using anti-aliasing, giving us a 50/25/25 mix of objects 2, 1, and the background color.  This appears to be the way Designer is doing things right now, and as you can see this gives us the wrong result!  The final color for this pixel should be a 50/50 mix of the color in objects 1 and 2, with no weight given to the background color.

 

It is definitely possible to achieve correct looking output in this situation, and we know that other programs are already doing so, such as Ai.

 

What I am looking for is someone within the Designer team to address this concern to.  If this is the wrong channel for that, I'd appreciate if someone could point me in the right direction.

 

All vector applications including Ai have traditionally produced raster data in the same way. It does look like Ai now does edge anti-aliasing differently. I'm not sure how recent the change in Ai was but I also noticed the quality of their anti-aliasing is now not as good. 

 

We can visit this again in the future but at the moment this is how we and all other vector applications render edges for off pixel boundaries.  We will have to experiment but it does look like we will lose some quality though.

 

 

[Lionel Seidman]

@TonyB Thanks for the informative reply.

 

If you do go down the multisampling route, you should be able to get pretty good quality anti-aliasing by using 8x multisampling (i.e. 64 samples per pixel) or higher.  The downside there would be potentially slower performance during image exporting, but if the user wants high-quality exports I think they'll be willing to wait a couple of seconds.  It would be nice to have that option, at least.

[WhiteX]

Exactly @Lionel Seidman, what concerns us is more the exported result, not how it looks in the editor (it would be good, that it looked nice there too, without transparent seams). Please pick up this issue, and try to come up with a solution.

[HugoAugusto]

Amazing that in 2019, this issue still happens! Yes, when I export to EPS, it's fine but if I try to copy an element with those lines from AD to PS, they are still visible. This issue forces me to export first to EPS and them import into PS. With AI, this does not happens. It's insane the amount of lines that are visible sometimes. Please FIX IT!

[WhiteX]

This is still an issue. With simple objects you can group them and duplicate the whole artwork once and looks much better.

[Neros]

Might as well update this: still a problem in 2021.

[vczf]

I had seams everywhere in the first thing I made with Affinity Designer, and I thought there was just something wrong with my technique since I am new to vector drawing. This is very frustrating and strange behavior.

There are even seams between the stroke and the shape when you set the stroke to be external to the shape geometry. This makes no sense. (Edit2: workaround)

Edit: trying out a few other vector programs. Inkscape and vectornator have antialiasing seams. Vectorstyler trial seems to avoid them on png export.

 

Edited May 14, 2022 by vczf
Add workaround note for external stroke seam

[vczf]

I believe this is a solved problem (if brute-force) with supersampling antialiasing. I took the exported SVG from AD into Inkscape, rendered it at 4x resolution with no antialiasing, then downscaled 4x to get back to the original resolution. No more seams, and nicely smoothed anti-aliased lines.

I really hope a feature of this sort can be added to fix exports. The current behavior does seem to be the norm for every vector program I've tried, including Inkscape and VectorStyler. However, it's both surprising and disappointing. From a logical standpoint, perfectly adjacent shapes should perfectly occlude what's behind them! Having to add background fills or extend the shape beyond its bounds with strokes defeats the neatness of geometrically precise shapes.

• Left: AD export at 400% magnification
• Right: 4xSSAA with Inkscape and ImageMagick at 400% magnification