Hi Dan,
Dan Amelang wrote:
Hi Juan,
Sorry to reply so late -- my academic quarter finished last week and
I'm now finally catching up with email, etc. I've been following your
work for a couple years now, and it is good to see progress.
That's nive to know!
On Wed, Jun 2, 2010 at 7:15 AM, Juan Vuletich <[email protected]> wrote:
Hi Folks,
I am developing a novel way to do anti aliased 2d graphics that breaks away
from pixel coverage and super sampling, while being simpler and providing
higher quality. Please take a look at http:www.jvuletich.org , especially at
the samples.
I believe this work fits nicely in the FONC project, as a Nile
implementation of it would yield better quality results than Gezira.
Could be. It's not _that_ hard to produce higher quality rendering
than Gezira. Or Cairo or AGG. And, as you note elsewhere, there are
many books and papers about very high-quality rendering. So what
gives?
In the design of a real-time renderer, one has to make trade-offs
between CPU-cycles, memory-use, complexity of implementation,
extensibility, rendering quality, etc. In the course of making a
trade-off, it might seem that the designer is ignoring "sampling
theory," or "proper software design," or "high efficiency."
Having spoken personally with Keith Packard and Carl Worth (of Cairo),
I believe that they are aware that there are even higher-quality
approaches to rendering than those used in Cairo.
Indeed. The quest is for techniques that produce better results and are
practical too.
It would be nice to know a little more about your approach, since you
haven't yet explained how it is different from existing
sampling-theory based approaches. For example, you could relate your
method to those described here:
http://graphics.stanford.edu/~mmp/chapters/pbrt_chapter7.pdf
("Sampling and Reconstruction" from the book "Physically Based
Rendering")
Thanks for the pointer. Nice reading! The Fourier and Sampling theory
part is good, and useful to help find the correct point of view. In
p.292 it introduces prefiltering. But as the whole book is focused on
building a ray tracer, in p.293 it says "The bad news is that it’s not
generally possible to prefilter f to remove the high frequencies from it
before sampling." From then on, the focus is on super sampling,
discarding prefiltering. BTW, it also disregards display physical
features. I think they are crucial to better quality, as they produce
the usual reddish and blueish shadows on black over white objects on
LCDs. (Please compare the Inkscape, Morphic3 and whole pixel AA Morphic
3 tiger on my web page, check also the photos of a typical display).
But for 2d vector graphics, prefiltering (for example as the pixel
coverage used by Cairo and Gezira) is the way to go. Only that better
filters and sampling is needed! A good reading is
http://www.cs.northwestern.edu/~jet/Publications/quadfilt95.pdf .
However my approach is much simpler (and faster), perhaps closer to
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter22.html .
Instead of solving the problem for general ideal 2d polygons, I
restricted the drawing primitives to those I found a way to do the way
to prefilter and sample inside it. A bottom-up approach instead of the
traditional top-down one. After much thinking and experimenting, I ended
with just one simple and general primitive that allows for more general
filters than the 1 pixel wide box used by pixel coverage. That primitive
is general enough to support the whole SVG standard. The samples in my
web page were done with a box filter of size 1.5, except for narrow
lines (SVG "strikes"), that use a bit larger one. This is because I
still didn't spend time tweaking the filter itself, I only played with
the support and sample position to enhance quality.
or here:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.83.9421&rep=rep1&type=pdf
("Interpolation Revisited", which you've mentioned before)
Well, this one is all about interpolation and resampling, so it has no
relation to the prefiltering techniques I'm developing.
I have read your conjectures about performance, but it would help if
we had some objective data once you've rewritten your code in a
lower-level language. Many of the high-quality rendering approaches
are not used in real-time renderers for performance reasons, so this
is a concern.
I'm pretty sure the performance of my technique won't be far from that
of Cairo. But yes, I need to write a C / asm version of it.
And it would be helpful to know, say, how many lines of code it took
you to implement your approach. The STEPS project is all about small
representations.
The basic primitives (not the whole set of SVG shapes) are about 200
lines of code in Cuis (a Squeak derivative), including great anti
aliasing and subpixel rendering, fills, translucency and blending over
translucent backgrounds. Each SVG shape primitive 20 to 30 additional
lines of code. All this includes comments. I'm sure that a Nile
implementation of it would make it much smaller.
I understand that you don't want to share too much until your three
wishes are granted, but any additional information would be
appreciated. Good luck!
Dan
Thank you.
Cheers,
Juan Vuletich
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
