While looking at the SVG version of Hillary's logo found here, I noticed there were notches in the two vertical bars of the H. The arrow crossbar covers up the notches so they are not seen when viewing the logo. But I'm very curious why the designer might have put in these notches. Does anybody know?

Technically this is a bug circumvention scheme. Its a bit surprising and unsettling to think that all the universities and mainstream vendors of 2D rendering engines do the same mistake over and over again, even though we know the cause, we know how to fix it abd its not that big of a performance hit on a modern computer. And no 3D graphics people rarely make this mistake and have known about it for 30+ years.
– joojaaJun 19 '16 at 10:22

5

@NickT Its not a z fighting issue its a issue of mixing together opacity and coverage but 3D is much more than games. In 3D we have for ages used multisampling to solve the aa issue. Multisampling (usually, even if it would the results would not be so pronounced) does not calculate coverage and thus does not make the mistake of thinking that 50% coverage is 25% visible trough another 50% coverage. While this may be true the answe can also be 50% is visible or none is visible. In this case to avoid confusion the other 50% is manually removed we can fix 3cases but not all. Should not be needed.
– joojaaJun 20 '16 at 22:23

4

It is sad that I clearly recognized it as to avoid a rendering bug of overlapping borders. But SVG still is 14 years old so I hope this gets fixed some day.
– Francisco PresenciaJun 21 '16 at 1:10

4

@FranciscoPresencia its not a problem with SVG its just a problem with the way we choose to erroneously implement the renders. Different SVG renderers have different severity of this problem
– joojaaJun 21 '16 at 8:36

11

@DA01 no the naive fix is incredibly simple, its less code than the current algorithm. Instead of doing coverage based calculation just render as if you did not antialias at all on a higher resolution then filter the image down to real resolution. This will never spill from bottom up since it can not make a mistake the front most element obscures it entirely. Graphics cards do this all the time that what the x4 x8 x16 aa settings are about in the gfx card settings.
– joojaaJun 22 '16 at 15:26

This can actually be just as big of a problem with printing. In digital printing at least the svg will typically be rasterized before being sent to the printer, and the same types of artifacts may appear. (last project at my last employer (big commercial printer) involved writing software to help identify these sorts of things before the expensive work of putting ink on paper was done.)
– Mr.MindorJun 22 '16 at 19:29

1

Since we're talking about US politics, you mean "artifacts"?
– Andrew RasmussenJun 24 '16 at 0:06

One way of rendering vector graphics (graphics defined by polygons, instead of pixels) to pixels is to rasterize the polygons while running the painter's algorithm.

The painter's algorithm is a bottom-up process where you first put down the background, then draw on top of that background with each layer of color until you reach the top layer.

When you deposit a layer, you pay attention to its coverage (usually stored in an extra channel, the alpha channel), and use it to mix the added color with what is already there.

If your new layer covers a pixel by 50%, and it is blue, you average the current color of that pixel with blue and draw that there instead.

Things get a bit more complex if you are creating an image with transparency, but not fundamentally.

Rasterization is the process of turning a polygon into pixels. Here, we work out how much the polygon covers a given pixel using some algebra, then calculate a coverage amount.

If you have two edges of a polygon that are coincident -- exactly on top of each other -- but both half-cover a given pixel, what happens is a problem.

Suppose the bottom polygon is red and the top blue and the background is white.

First we paint the red. This mixes with the white, leading to 50% white 50% red.

We then paint the blue. This mixes with the 50% white 50% red and we get 25% white 25% red 50% blue. The same thing happens if red and blue meet in the middle, or if blue covers red completely.

But "in reality" the blue polygon completely covered the red one, so why are we seeing it? Because the algorithm forgets sub-pixel positioning details.

So long as there is 100% coverage of one polygon, this isn't a problem.

Now, this problem is not fundamental. You can do polygon rendering with a ray-tracing like approach (where you over-render by a factor of N^2 at points), or even a pure-vector like approach (where you subtract blocking shapes from the geometry of the shapes under them, cutting them out). In neither case do "hidden" colors leak through to the output image.

The painter's algorithm isn't the only case where "hidden" geometry can leak through. If you are printing with opaque media, sometimes the color layers are not perfectly aligned. So under-layers leak through when the top layer should be covering it completely.

As you don't know how your vector image will be output, notches like that let you make images that are more robust against imperfect printing/display techniques.

Your description applies in the case of graphics containing alpha channels, or in the case of subpixel drawing when anti-aliasing. The OPs example will show the notch artifacts for blended layers contrary to what is intended. I'd suggest the issue is more related to registration errors in printing.
– PekkaJun 20 '16 at 18:01

If the top layer has any transparency, then the notch will result in gradual drawing back of the lower layer from the edge impacting on both the anti-aliasing and the top level color. A more appropriate response would be to have a rectangular rebate (of a size difficult to estimate) in the area where the mixing is not desired. How do you quantify this?
– PekkaJun 20 '16 at 19:20

@pekka If the top layer has medium amounts of transparency, this problem is far less problematic (as you can see the red under the blue anyhow). As transparency of the top approaches opacity, approach the above solution. As it goes away from opacity, approach pre-compositing it. The general problem is tricky given registration errors, build-up problems (too many layers!), anti-aliasing, and everything else: at some point, you want to write custom vectors for each output format, or munge the vectors somehow. I simply tried to answer the exact technical cause of the problem the notch solves.
– YakkJun 20 '16 at 19:34

1

@Pekka a rectangular is harder to draw and then you end with teh opposite problem of the same issue in that the background shows trough. Notch is sort of a compromise between one bug over a number of others (the notch is for on screen rendering wile not having a square cavity is so that overprinting plates can be made if needed with minimal errors). But there really is no reason for there to be a need to do this, its just that our renderers work wrong thats all there is to it. We could all the 3 problems easily by switching the way we rasterize.
– joojaaJun 21 '16 at 8:28

The reason this happens is that it's an SVG. Unlike a raster image where you control each rendered pixel, the rasterization of the SVG happens in the browser...so the browser makes these decisions.

One of the decisions the browser has to make is when to do anti-aliasing. It will typically do this when a point along a line falls on a pixel. It will then anti alias that pixel. Since it will render all layers of the SVG, it will do this to each layer and that's where you can start to get the edge artifacting. This is especially true when you play with the zoom of the SVG as that will cause it to overlap different screen pixels.

Here's a screen shot of a green box overlapping a red box in Chrome. The top is at 100% page zoom, the bottom is zoomed in. Notice the difference in rendering that edge:

If I screen shot that and zoom in to show the rasterization, you can a clearer picture of what's going on:

The ideal fix here would be for the SVG rasterizer in the browser to be 'smarter' and not render things that are stacked, but given that SVG elements can be manipulated externally and live (as it's just an XML file) it's not a practical solution for the browser.

So, instead, the designer makes that decision by using the notches you see.

Printing in multiple colours requires accurate registration to avoid unsightly gaps and is a concern when artifacts are composed from multiple sources. Similar concerns can occur even in digital products where limited precision arithmetic necessarily introduces error.

The problem being avoided is one of inverse trapping - where deviation from the intended graphic can result in a thin line of the background colour showing on the left of the vertical coincident edges. As the colours are highly contrasting, the impact will be noticeable (try moving the broken line even 1 pixel to the left of vertical.

The approach is not intended to impact on mixing of inks. On-screen consistent coordinates avoids the problem, while half-toning is used to manage colour.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).