I don't know how common it is in fonts, but for generic 2D vector graphics, problems arise from the management of self-intersections, i.e., the pixels where they fall. With an SDF rasterizer, how do you handle the pixel where two Bezier curves intersect in a fish-shaped path?
For this reason, more conventional rasterizers with multisampling are often used, or rasterizers that calculate pixel coverage analytically, also finding intersections (sweepline, Bentley-Ottmann).
Hmm I'm not sure I quite understand your question. The renderer uses predefined textures of signed distance fields. Essentially you're building a gradient out from your source vector. You can tweak how that texture is built and it doesn't need to be strictly the true distance.
In theory you could handle it however you want. You could make an SDF texture of a figure eight where the inside of the eight is purely zero and only the outside has a gradient. If you built a texture like this then your stroke with would only ever grow out of the shape.
This is an example of how SDF is very powerful.
If instead you're asking about the precision with regards to the infinitely small point of an intersection of two vectors it's actually not an issue at all. The technique uses the usual texture sampling pipeline such that the render will be as sharp as your SDF texture and as alias free as your mitmaping allows.
I'm always interested in new 2D vector rendering algorithms, so if you make a blog post explaining your approach, with enough detail, I'd be happy to read it!
At what order of magnitude in the number of elements to be sorted (I'm thinking to the overhead of the GPU setup cost) is the break-even point reached, compared to a pure CPU sort?
No idea unfortunately. For me it's mandatory to sort on the GPU because the data already resides on GPU, and copying it to CPU (and the results back to GPU) would be too costly.
Thanks. This librarys are so full of features that they literally burry the real drawing part. I had hoped for something more basic. No anti aliasing etc.
You have to look for "stroking": there are several ways to do it, in CPU you usually first perform a piecewise linear approximation of the curve, then offset each segment along the normals, add the caps, get a polygon and draw it.
You didn't mention one of the biggest source of 2d vector graphic artifacts: mapping polygon coverage to the alpha channel, which is what virtually all engines do, and is the main reason why we at Mazatech are writing a new version of our engine, AmanithVG, based on a simple idea: draw all the paths (polygons) at once. Well, the idea is simple, the implementation... not so much ;)
I am quite convinced that if the goal is the best possible output quality, then the best approach is to analytically compute the non-overlapping areas of each polygon within each pixel. Resolving all contributions (areas) together in the same single pass for each pixel.
Why are you convinced of this, and can I help unconvince you? ;) What you describe is what’s called “Box Filtering” in the article. Box filtering is well studied, and it is known to not be the best possible output quality. The reason this is not the best approach is because a pixel is not a little square, a pixel is a sample of a signal, and it has to be approached with signal processing and human perception in mind. (See the famous paper linked in the article: A Pixel is Not a Little Square, A Pixel is Not a Little Square, A Pixel is Not a Little Square http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf)
It can be surprising at first, but when you analytically compute the area of non-overlapping parts of a pixel (i.e., use Box Filtering) you can introduce high frequencies that cause visible aliasing artifacts that will never go away. This is also true if you are using sub-sampling of a pixel, taking point samples and averaging them, no matter how many samples you take.
You can see the aliasing I’m talking about in the example at the top of the article, the 3rd one is the Box Filter - equivalent to computing the area of the polygons within each pixel. Look closely near the center of the circle where all the lines converge, and you can see little artifacts above and below, and to the left and right of the center, artifacts that are not there in the “Bilinear Filter” example on the right.
I think the story is a lot more complicated. Talking about "the best possible output quality" is a big claim, and I have no reason to believe it can be achieved by mathematically simple techniques (ie linear convolution with a kernel). Quality is ultimately a function of human perception, which is complex and poorly understood, and optimizing for that is similarly not going to be easy.
The Mitchell-Netravali paper[1] correctly describes sampling as a tradeoff space. If you optimize for frequency response (brick wall rejection of aliasing) the impulse response is sinc and you get a lot of ringing. If you optimize for total rejection of aliasing while maintaining positive support, you get something that looks like a Gaussian impulse response, which is very smooth but blurry. And if you optimize for small spatial support and lack of ringing, you get a box filter, which lets some aliasing through.
Which is best, I think, depends on what you're filtering. For natural scenes, you can make an argument that the oblique projection approach of Rocha et al[2] is the optimal point in the tradeoff space. I tried it on text, though, and there were noticeable ringing artifacts; box filtering is definitely better quality to my eyes.
I like to think about antialiasing specific test images. The Siemens star is very sensitive in showing aliasing, but it also makes sense to look at a half-plane and a thin line, as they're more accurate models of real 2D scenes that people care about. It's hard to imagine doing better than a box filter for a half-plane; either you get ringing (which has the additional negative impact of clipping when the half-planes are at the gamut boundary of the display; not something you have to worry about with natural images) or blurriness. In particular, a tent filter is going to be softer but your eye won't pick up the reduction in aliasing, though it is certainly present in the frequency domain.
A thin line is a different story. With a box filter, you get basically a non antialiased line of single pixel thickness, just less alpha, and it's clearly possible to do better; a tent filter is going to look better.
But a thin line is just a linear combination of two half-planes. So if you accept that a box filter is better visual quality than a tent filter for a half-plane, and the other way around for a thin line, then the conclusion is that linear filtering is not the correct path to truly highest quality.
With the exception of thin lines, for most 2D scenes a box filter with antialiasing done in the correct color space is very close to the best quality - maybe the midwit meme applies, and it does make sense to model a pixel as a little square in that case. But I am interested in the question of how to truly achieve the best quality, and I don't think we really know the answer yet.
In my opinion, if you break down all the polygons in your scene into non-overlapping polygons, then clip them into pixels, calculate the color of each piece of polygon (applying all paints, blend modes, etc) and sum it up, ...in the end that's the best visual quality you can get. And that's the idea i'm working on, but it involves the decomposition/clip step on the CPU, while sum of paint/blend is done by the GPU.
That isn’t true. Again, please look more closely at the first example in the article, and take the time to understand it. It demonstrates there’s a better method than what you’re suggesting, proving that clipping to pixels and summing the area is not the best visual quality you can get.
As pointed out by Raphlinus, the moire pattern in the Siemens star isn't such a significant quality indicator for the type of content usually encountered in 2D vector graphics. With the analytical coverage calculation you can have perfect font/text rendering, perfect thin lines/shapes and, by solving all the areas at once, no conflating artifacts.
Raph made an argument that Box is good enough for lots of things, which is subjective and depends entirely on what things you’re doing, and how much you actually care about quality.
You are claiming it’s the best possible. Box filter is simply not the best possible, and this fact is well understood and documented.
You can relax your claim to say it’s good enough for what you need, and I won’t disagree with you anymore. Personally, I’m sensitive to visible pixelation, and the Box Filter will always result in some visible pixelation with all 2D vector graphics, so if you really care about high quality rendering, I’m very skeptical that you really want Box filtering as the ideal target. Box filter is a compromise, it’s easier & faster to compute. But it’s not the highest quality. It would be good to understand why that’s the case.
* Edit to further clarify and respond to this:
> With the analytical coverage calculation you can have perfect font/text rendering, perfect thin lines/shapes and, by solving all the areas at once, no conflating artifacts.
You cannot get perfect font or text rendering with a Box filter, and you will get some conflating artifacts. They might be very slight, and not bothersome to most people, but they do exist with a Box filter, always. This is a mathematical property of Box filtering, not a subjective claim.
Why do conflation artifacts always exist with a box filter? AFAIK conflation artifacts are a product of the compositing process, not the filtering process.
If you have two non-overlapping shapes of the same color covering the plane and use a box filter on the first shape to sample a pixel on the boundary, and then use the same box filter on the second shape, and then composit them with alpha blending, you get a conflation artifact along the boundary where the background bleeds through.
But if you use the fact that the shapes are non-overlapping and sum their contributions instead, the artifact disappears, while still using the same box filter.
It’s because sampling artifacts never disappear with Box. The reason is the high frequency aliasing is introduced by the filtering. It’s because the Box itself has infinite frequency response that you cannot eliminate the artifacts, it’s not possible. This is why all other, better filters fade their weight smoothly to zero at the support boundary.
You can see this with a single sharp edge, it doesn’t need to involve multiple polygons, nor even vector rendering, it happens when downsampling images too.
These are sampling artifacts, but I believe yorbwa is correct in distinguishing these from conflation artifacts, as defined in Kilgard & Bolz. I think of the latter as compositing not commuting exactly with antialiasing (sampling). You only get conflation artifacts when compositing multiple shapes (or rendering a single shape using analytical area when the winding number is not everywhere 0 or 1), while you definitely see aliasing when rendering a single shape, say a Siemens star.
Okay, that’s fair. I’m misusing the term ‘conflation’ in that sense. I was trying to make the point that compositing two wrong answers yields a wrong answer, but I stand corrected that it’s not the compositing that’s introducing error, it is the sampling + box-filtering.
I don't see how you can support the claim of perfect thin line rendering, it's visibly just not very good. So box filtering logically can't possibly be the best possible quality.
Can we make a magical adaptive filter which resembles box filter for half-planes, a tent filter for thin lines, Mitchell-Netravali or oblique projection for natural images, and Gaussian when filtering images for which high frequency detail is not important? Perhaps, but that feels like advanced research, and also computationally expensive. I don't think you can claim "perfect" without backing it up with human factors data really demonstrating that the filtered images are optimum with respect to perceived quality.
I wonder if the ideas behind GIMP's new nonlinear resampling filters (NoHalo and LoHalo, and eventually more https://graphicdesign.stackexchange.com/q/138059) may translate to vector rasterization in some form (though here we're translating continuous to discrete, not discrete to continuous to a differently spaced discrete).
Backing up to your earlier comment. Pixels on some displays are in fact little squares of uniform color. The question then is how to color a pixel given geometry with detail within that square.
All of this "filtering" is variations on adding blur. In fact the article extends the technique to deliberately blur images on a larger scale. When we integrate a function (which could be a color gradient over a fully filled polygon) and then paint the little square with a solid "average" color that's also a form of blurring (more like distorting in this case) the detail.
It is notable that the examples given are moving, which means moire patterns and other artifacts will have frame-to-frame effects that may be annoying visually. Simply blurring the image takes care of that at the expense of eliminating what looks like detail but may not actually be meaningful. Some of the less blurry images seem to have radial lines that bend and go back out in another location for example, so I'd call that false detail. It may actually be better to blur such detail instead of leaving it look sharper with false contours.
Yes it’s a good point that LCD pixels are more square than the CRTs that were ubiquitous when Alvy Ray wrote his paper. I think I even made that point before on HN somewhere. I did mention in response to Raph that yes the ideal target depends on what the display is, and the filter choice does depend on whether it’s LCD, CRT, film, print, or something else. That said, LCD pixels are not perfect little squares, and they’re almost never uniform color. The ideal filter for LCDs might be kinda complicated, and you’d probably need three RGB-separated filters.
Conceptually, what we’re doing is low-pass filtering, rather than blurring, so I wouldn’t necessarily call filtering just “adding blur”, but in some sense those two ideas are very close to each other, so I wouldn’t call it wrong either. :P The render filtering is a convolution integral, and is slightly different than adding blur to an image without taking the pixel shape into account. Here the filter’s quality depends on taking the pixel shape into account.
You’re right about making note of the animated examples - this is because it’s easier to demonstrate aliasing when animated. The ‘false detail’ is also aliasing, and does arise because the filtering didn’t adequately filter out high frequencies, so they’ve been sampled incorrectly and lead to incorrect image reconstruction. I totally agree that if you get such aliasing false detail, it’s preferable to err (slightly) on the side of blurry, rather than sharp and wrong.
Would DLP projectors which distribute color over time (a color wheel) or multiple light sources combined with dichroic filters, produce uniform squares of color?
In theory if the DMD mirrors were perfect little squares, and if the lens has perfect focus, and if the mirrors switch infinitely fast and are perfectly aligned with the color wheel in time, then maybe it’d be fair to call them uniform squares of color. In reality, the mirrors look square, but aren’t perfect squares - there’s variance in the flatness, aim, edges & beveling, and also both the lens and mirror switching blurs the pixels. The mirror switching over time is not infinitely fast, so the colors change during their cycle (usually multiple times per color of the wheel!) Not to mention some newer DLPs are using LEDs that are less square than DMD mirrors to begin with.
All this comes down to the projected pixels not being nearly as square as one might think (maybe that’s on purpose), though do note that squares are not the ideal shape of a pixel in the first place, for the same reason box filtering isn’t the best filter. If your pixel has sharp edges, that causes artifacts.
Oh I agree with all of that. And nice to see you on HN Raph - was nice to meet you at HPG the other day.
It’s subjective, so box filter being ‘close’ is a somewhat accurate statement. I’m coming from the film world, and so I have a pretty hard time agreeing that it’s “very” close. Box filter breaks often and easily, especially under animation, but it’s certainly better than nearest neighbor sampling, if that’s our baseline. Box filter is pretty bad for nearly any scenario where there are frequencies higher than the pixel spacing, which includes textures, patterns, thin lines, and all kinds of things, and the real world is full of these box-filter-confounding features.
One interesting question to ask is whether you the viewer can reliably identify the size of a pixel anywhere in the image. If you can see any stepping of any kind, the pixel size is visible, and that means the filter is inadequate and cannot achieve “best possible output quality”. Most people are not sensitive to this at all, but I’ve sat through many filter evaluation sessions with film directors and lighting/vfx supervisors who are insanely sensitive to the differences between well tuned and closely matching Mitchell and Gaussian filters, for example. Personally, for various reasons based on past experience, I think it’s better to err slightly on the side of too blurry than too sharp. I’d rather use a Gaussian than bicubic, but the film people don’t necessarily agree and they think Gaussian is too blurry once you eliminate aliasing. Once you find the sharpest Gaussian you can that doesn’t alias, you will not be able to identify the size of a pixel - image features transition from sharp to blurry as you consider smaller scales, but pixel boundaries are not visible. I’ve never personally seen another filter that does this always, even under contrived scenarios.
That said, I still think it’s tautologically true that box filter is simply not the “best” quality, even if we’re talking about very minor differences. Bilinear and Bicubic are always as good or better, even when the lay person can’t see the differences (or when they don’t know what to look for).
My opinion is that there is no such thing as “best” output quality. We are in a tradeoff space, and the optimal result depends on goals that need to be stated explicitly and elaborated carefully. It depends heavily on the specific display, who/what is looking at the display, what the viewer cares about, what the surrounding environment is like, etc., etc..
* edit just to add that even though I don’t think “best” visual quality exists, I do think box filter can never get there, the contention for top spot is between the higher order filters, and box filter isn’t even in the running. I had meant to mention that even a single 2d plane that black on one side and white on the other, when rendered with box filter, yields an edge in which you can identify visible stepping. If you handle gamma & color properly, you can minimize it, but you can still see the pixels, even in this simplest of all cases. For me, that’s one reason box filter is disqualified from any discussion of high quality rendering.
If there's one thing I've learned from image processing it's that the idea of a pixel as a perfect square is somewhat overrated.
Anti-aliasing is exactly as it sounds, a low-pass filter to prevent artefacts. Convolution with a square pulse is serviceable, but is not actually that good a low-pass filter, you get all kinds of moire effects. This is why a Bicubic kernel that kind of mimics a perfect low-pass filter (which would be a sinc kernel), can perform better.
It is tempting to use a square kernel though, because it's pretty much the sharpest possible method of acceptable quality.
I've been looking into how viable this is as a performant strategy. If you have non-overlapping areas, then contributions to a single pixel can be made independently (since it is just the sum of contributions). The usual approach (computing coverage and blending into the color) is more constrained, where the operations need to be done in back-to-front order.
I've been researching this field for 20 years (I'm one of the developers of AmanithVG). Unfortunately, no matter how fast they are made, all the algorithms to analytically decompose areas involve a step to find intersections and therefore sweepline approaches that are difficult to parallelize and therefore must be done in CPU. However, we are working on it for the next AmanithVG rasterizer, so I'm keeping my eyes open for all possible alternatives.
I ran across https://dl.acm.org/doi/pdf/10.1145/72935.72950 a few weeks ago, it seems like a potential non-sweepline highly-parallel method. I've had some promising results for first doing a higher-dimensional Hilbert-sort (giving spatial locality), and then being able to prune a very large percentage of the quadratic search space. It might still be too slow on the GPU. I'm curious if you have any write-ups on things that have been explored, or if I'd be able to pick your brain some time!
No, Vello does not analytically find intersections. Compositing is (currently) done by alpha blending, which is consistent with the W3C spec but has its own tradeoffs.
> compute the non-overlapping areas of each polygon within each pixel
In the given example (periodic checkerboard), that would be impossible because the pixels that touch the horizon intersect an infinite amount of polygons.
Not that TFA solves that problem either. As far as I know the exact rendering of a periodic pattern in perspective is an open problem.
Is there technical documentation to understand the method behind the engine? because at first sight it seems like the classic "path flattening to polygon and then triangulation" that has been used for 20+ years (at Mazatech our first AmanithVG on OpenGL used that technique) but I'm sure there is more than that on Rive renderer ...to be recognized as a such powerful engine.
Do not forget: https://www.amanithvg.com (I'm one of the authors, 20+ years of active development). Full OpenVG 1.1 API, CPU only, cross-platform and analytical coverage antialiasing (rendering quality) as main feature. The rasterizer is really fast. I swear ;)
At Mazatech we are working to a new GPU backend just these days.
AmanithVG is the library on which our SVG renderer: https://www.amanithsvg.com is based. All closed source as now, but things may change in future.
I will do some benchmarks of the current (and next, when the new GPU backend will be ready) version of our libraries against other libraries. Do you know if there are any standard tests (besides the classic post script Tiger)? Maybe we can all agree on a common test set for all vector graphics libs bechmarks?
That's right! I didn't consider closed source libraries when writing the list. There would be more options in that case like Direct2D and CoreGraphics. However, my opinion is that nobody should be using closed source libraries to render 2D graphics in 2024 :)
Regarding benchmarks - I think Tiger is not enough. Tiger is a great benchmark to exercise the rasterizer and stroker, but it doesn't provide enough metrics about anything else. Tt's very important how fast a 2D renderer renders small geometries, be it rectangles or paths. Because when you look at screen most stuff is actually small. That's the main reason why Blend2D benchmarking tool scales the size of geometries from 8x8 to 256x256 pixels to make sure small geometries are rendered fast and covered by benchmarks. When you explore the results you will notice how inefficient other libraries actually are when it comes to this.
A true AI-cracy should ignore the citizens' vote (it's not a democracy) and make autonomous decisions trying to maximize their well-being. The dopamine-releasing device would skew the measurement of an individual's well-being, so it shouldn't be used.
