Return to main page.
Click on the buttons below to select between different
inputs and rendering modes.
You can also use the keyboard to quickly change between modes.
When looking at these files, there are a few things to
notice:
- In antialiased rendering, the color of each pixel is
produced by a weighted integral of the colors in the
illustration near the pixel center. This integration
is usually approximated by a weighted sum of the colors of
the illustration at many sample positions near the pixel
center, in what is called supersampling. The
highest the number of samples, the closer the result of
supersampling is to the actual value of the intended
integral. Using too few samples can lead to noisy images and
to thin features that look broken up. Our pipeline was
designed to use many samples per pixel;
- The color of a point in the
illustration is usually obtained with gamma correction
applied to it. Most renderers add these colors together
without first removing the gamma correction. This is incorrect.
The result is dark regions that appear thicker than
they should, or average colors that papear darker
than they should. Our pipeline was designed to perform this
integration correctly. Since many people have grown to the
incorrect approach, we also support it;
- The weights and the size of the neighborhood used in
the integral are given by an antialiasing filter.
Virtually all pipelines use the Box filter for its
simplicity (constant value, all positive, and narrow
support). Antialiasing filters used in production have wider
support (to suppress aliasing), and may or may not include
negative lobes (to improve sharpness). Our pipeline supports
state-of-the-art antialiasing filters;
- Most pipelines render paths independently with
supersampling. Pixels that are partially covered by a path are
considered semi-transparent and their alpha channel is
modified accordingly. The independently rendered paths
are then blended on top of an output image. This conflation between
coverage and transparency leads to rendering errors where
regions are precisely abutting. Our renderer does not
perform this conflation;
- Some pipelines change the input before rendering. For
example, thin strokes may be made wider, horizontal and
vertical strokes may be aligned to pixel boundaries. This
practice can substantially change the intended appearance of
the illustration. Our pipeline renders what was passed to it.
The modes are:
- Ours 1×32: Single-pass rendering by our pipeline
using 32 samples per pixel and box filtering;
- Ours 1×32 γ: Same, but integrating in gamma
space (i.e., incorrectly but very common);
- Ours 4×4×32: Single-pass rendering by our pipeline
using 32 samples per unit area (512 samples per pixel) and cardinal cubic B-spline filtering;
- Ours 4×4×32 γ: Same, but integrating in gamma
space (i.e., incorrectly but very common);
- NH 1D: Nehab & Hoppe [2008] prefilter approximation
with 1 sample per pixel;
- NVPR 1×8: Single-pass rendering by NVPR using
multisampling mode 8×CS;
- NVPR 1×32: Four-pass accumulation of NVPR using
multisampling mode 8×CS;
- NVPR 32× (8×MS, 24×CS): Single-pass
rendering by NVPR using multisampling mode 32×
(8×MS, 24×CS);
- Batik: Rendering by Batik 1.7 (batik-rasterizer.jar);
- Qt: Rendering by Qt 5.3.1 (QGraphicsSvgItem, QPainter::HighQualityAntialiasing);
- Inkscape: Rendering by Inkscape 0.48.2 r9819;
- Cairo: Rendering by Cairo 1.12.16 via libRSVG 2.40.4 (rsvg-convert);
- MuPDF: Rendering by MuPDF 1.6 with 8 bits of antialiasing (mudraw);
- GhostScript: Rendering by GhostScript 9.10;
- Quartz: Rendering by Quartz via Cocoa (pdf2png-mac);
- Adobe Reader: Rendering by Adobe Reader 11.0.09 (screen grab);
- Adobe Illustrator: Rendering by Adobe Illustrator CS9 (AppleScript);
- Splash: Rendering by Splash in Poppler 0.26.5 (pdftoppm);
- Windows 8: Rendering by Modern Reader on Windows 8;
- Webkit: Rendering by Webkit 9537.85.10.17.1 (webkit2png).