MenTaLguY wrote:
On Sat, 2006-12-02 at 19:13 +0100, Jasper van de Gronde wrote:
When rendering gallardo.svgz using the new code cuts the total time spent in FilterGaussian::render roughly in half (on my computer it is 30-40%, so 50% should be quite attainable), compared to the SVN implementation using average(!) quality, while being virtually indistinguishable from best(!) quality rendering. I have seen some differences on certain test drawings in my test application, but for a rendering of gallardo.svgz the maximum difference was 1 and didn't occur often (and could be due to slightly different rounding, numerical errors, etc.).
Hmm. That worries me a bit -- can you try and construct SVG versions of the drawings in your test application? We really need to get a sense of what the worst case is, and how to mitigate it.
I imported the image I used earlier in Inkscape and compared the new code with and without the IIR filter and found no (significant) differences. Previously I used Corel PhotoPaint to generate the reference image, so I also tried some other applications and found it quite hard to get the same results in each application.
My guess is that the differences I found previously weren't due to errors in the IIR filter, but rather a difference in interpretation of the radius between Corel PhotoPaint and my code or some optimization of gaussian blur on their side, perhaps they quantize coefficients quite coarsely for example.
I do have a question though. I found the relation between the radius entered in the fill & stroke dialog and the actual value of sigma used quite odd (sigma=radius*400/(width+height)), so I was wondering whether there was a reason for this, because it makes it quite difficult to predict the result of the specified blur.