Fernando Perez wrote: > It's probably worth mentioning that one of the reasons John chose Agg > is because of image *quality* concerns. If I'm not mistaken (John and > A. Straw will correct me as needed), the OpenGL anti-aliasing quality > is positively horrible when you compare it to the quality of Agg. > Keep in mind that OpenGL is typically focused on keeping high > frame-rates for moving images, so pixel-perfect antialiasing is much > less of a concern for them, since your eye is a lot less likely to > notice such fine details (as long as there is *some* antialiasing). > For a static image, you tend to be a lot pickier, and Agg goes to > great lengths to ensure the best possible antialiasing quality. This > is part of the reason why normal television, at abysmally low > resolutions is still acceptable for viewing, while nobody would > consider a 400-line-image an acceptable photograph for most uses. You > 'stare' at the moving image only for 1/30 s or so, while you look at > the static one for much longer. Excellent summary, Fernando -- are looking to burnish your visual neuroscientist credentials? ;) The only thing I'd add is that the spatio-temporal nature of video means that, despite course spatial quantization on any single image, we perceive something with a much higher resolution essentially because we have many samples where the source is moving against the sampling array and we "fill in". Not only do we do this, so do our electronic devices these days -- upsampling (spatially and temporally) DVD players make use of algorithms to fill in pixels that weren't directly specified. And video compression codecs essentially remove information that's perceptually less significant to this filling in process. (Stop me here...)
> I've never seen any opengl-based antialiasing be of that quality. But > there may be ways of achieving the same thing in OpenGL, I don't know > (and to do so efficiently and portably, without requiring specific > video cards). > > The other issue I recall is that the quality of openGL antialiasing is > highly dependent on the video card and/or driver. While that may be > OK for gamers, it's completely unacceptable IMO for scientific > publication. Granted, this page is getting a little dated, but here's what you get with OpenGL: http://homepage.mac.com/arekkusu/bugs/invariance/HWAA.html FWIW, one cheap trick to get better anti-aliasing with OpenGL is to render the image much bigger than you need and then downsample it appropriately. As OpenGL implementations have maximum rendering sizes, this often means tiling the image. This probably wouldn't work for realtime rendering, but for saving bitmaps it would produce decent results. In general, I think we should explore collaboration (and I'm very excited about the sympy project). Yet, it's difficult for me to see how MPL could be turned into a pure-Python project with acceptable speed and retaining the backends that we support with the quality we support. All the more so with the new transforms branch. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
