Bezier smoothness and antialiassing
Hi,
First of all, although this email could be observed as a troll, I hope I can show that I want to improve stuff, not troll.
My core (daily) automatic use of Inkscape is using it as renderer for a bulletingboard system. It runs over the last years 24x7, and I choose it because of the text-flow support. That said, we are moving to HD broadcast and the analogue smoothness is removed for 1080p sharpness.
One of the core template designs uses a Bezier curve, imagine this as one side of a very tall egg. This surface, thick white border, is placed on dark blue. I am quite disappointed with the outline of the rendering of the curve. One of the topics I found today was at:
http://www.inkscapeforum.com/viewtopic.php?f=5&t=11451
The following blog entry mentions that cairo overdoes anti-aliassing, I also compared the Cairo output and rsvg's output. The curve is different, but is it really better? Not really.
http://libregraphicsworld.org/blog/entry/getting-crisper-text-out-of-inkscape
The Faq talks about 'Jagged edges'. Since my curves are insanely big, I don't believe it is impossible to get a visually better rendered curve. As example I have attached what I think the problems are with the rendering. From bottom I really get the curve that I want, its smooth and probably it is because about 3/4 pixels are used for overlap. The steeper the curve the less interpolation between step seem to happen as if the curve is defined at x=1, x=2, x=3, but the interpolation itself is only directional with the curve opposed to orthogonal with the adjacent content.
Looking at the curve in outline mode, it also gives a glipse.
One of the faq entries claimns you could work with a blur. I have tried a blur, and if you use it at 0.1 you basically achieve a very poor interpolated line. I would be interested what is possible with a border of 2,3 pixels wide converging to transparency.
I wonder: - is it possible with one extra interpolation step to get a more visually attractive curve? - the faq mentions that pixel alignment is important, does this mean that the controlpoints, in all cases, must snap to the raster? [my own results with snapping are virtually the same]
In a conversation at #cairo, some other suggestions where made such as gamma correct blending. From the rendering I saw here: http://people.freedesktop.org/~sandmann/tigers/ I personally liked jinc the most.
Stefan
On 2012-03-04 3:19, Stefan de Konink wrote:
I wonder:
- is it possible with one extra interpolation step to get a more
visually attractive curve?
We have to deal with displays that have a rather limited resolution, so to some degree artifacts like this simply cannot be helped. However, you are absolutely right that there are different ways of anti-aliasing and some might appear to give a better result in this case. What Inkscape (Cairo) does is just based on coverage of the pixel. For vector images this is one of the best "defaults" (if not the best), as it can lead to reasonable results without any blurring or ringing artifacts (not to mention it's fast). So I would not suggest changing this. (Although in the future it might make sense to have some alternatives as well, for artistic purposes, although we would need Cairo to adopt them.)
What we could try is implementing support for the linearRGB color space. The rationale behind this is that we would like a pixel that is half covered to have a color halfway between the foreground and background, in terms of the actual color shown on screen (or print or whatever). To accomplish this we need to work in a colorspace that is (roughly) linear (like linearRGB). I have attached a slightly fudged example to this mail (the technique is probably similar to the "gamma-corrected" example in the directory you linked to, except that here the colors aren't changed, only the anti-aliasing is changed). One problem with this is that you really want to work with a higher bit depth. Also, this technique is not so easy to apply to existing images, as coverage and opacity are handled in the same way (using the alpha channel).
- the faq mentions that pixel alignment is important, does this mean
that the controlpoints, in all cases, must snap to the raster? [my own results with snapping are virtually the same]
This is most visible with straight lines. Just draw a straight (horizontal or vertical) line with stroke width 1, such that its nodes lie exactly on pixel centers (0.5,0.5 is a pixel center for example). The line should then be exactly one pixel thick. If you draw it with the node on a pixel boundary (like 1,1), the line should be two pixels thick, but with lower opacity.
In short: you're running into fundamental issues that are non-trivial to solve. In the near term, just apply a slight blur to your image if you have problems with Inkscape's anti-aliasing, in the long-term there are some options available to us, but changing the (default) anti-aliasing kernel is probably the last thing we want to do.
Hi Jasper,
On 04-03-12 13:34, Jasper van de Gronde wrote:
In short: you're running into fundamental issues that are non-trivial to solve. In the near term, just apply a slight blur to your image if you have problems with Inkscape's anti-aliasing, in the long-term there are some options available to us, but changing the (default) anti-aliasing kernel is probably the last thing we want to do.
Thanks for your elaborative answer also in #cairo there was some real knowledge around on this subject. I do wonder something about your last statement. Where is the default kernel function defined? And would it be possible to have a 'fast' on screen approximation, and the option for a alternative kernel?
I have tried doing the jinc trick myself at just 2x the resolution and then scale down. (Opposed to Sandmann's 16x)
I would really like to explore things in this direction, in the short term I could obviously render a super smooth curve and stick that as bitmap in my SVG file, but as you understand this is not sustainable.
Stefan
On 2012-03-04 14:45, Stefan de Konink wrote:
Thanks for your elaborative answer also in #cairo there was some real knowledge around on this subject. I do wonder something about your last statement. Where is the default kernel function defined? And would it be possible to have a 'fast' on screen approximation, and the option for a alternative kernel?
I do not think Cairo explicitly uses a kernel, it basically just determines how much of a pixel is covered by a shape (this corresponds to the "box" kernel). Adding support for other kernels would probably not be trivial. Also, as I mentioned before, the box kernel is actually quite a sensible choice for vector graphics, virtually all other kernels will lead to visible blurring and/or ringing artifacts. That is why I would first try to use gamma correction/linearRGB, as that is more about creating a more "correct" output, rather than making a trade-off between a smooth and a crisp result.
participants (2)
-
Jasper van de Gronde -
Stefan de Konink