Hi, I wonder why gradients in inkscape doesn't look smooth. When I look on them I see that they compose from regular lines. Can't gradients look so smooth like in photoshop or gimp ?
--- Kind regards. Kobi.
Tomasz Kobiela wrote:
Hi, I wonder why gradients in inkscape doesn't look smooth. When I look on them I see that they compose from regular lines. Can't gradients look so smooth like in photoshop or gimp ?
I'm curious about this as well, any hints or tips to fix it or stop it from happening?
A couple of examples:
* Round banding radiating from the lower left: http://fedoraproject.org/wiki/Artwork/F8Themes/Infinity/Round3Scratch?action...
* Vertical bands from left to right: http://fc02.deviantart.com/fs11/i/2006/225/4/0/Fedora_Core_6_Wallpaper_by_po...
~m
On Mon, 20 Aug 2007 17:11:44 -0400, Máirín Duffy <duffy@...43...> wrote:
Tomasz Kobiela wrote:
Hi, I wonder why gradients in inkscape doesn't look smooth. When I look on them I see that they compose from regular lines. Can't gradients look so smooth like in photoshop or gimp ?
I'm curious about this as well, any hints or tips to fix it or stop it from happening?
I think this may be a regression -- I'm fairly sure that at one point we had added code to dither gradients to reduce the appearance of banding.
(Does anyone have some older Inkscape versions around to try? I think the patch I'm thinking of was around the 0.42 or 0.43 timeframe.)
-mental
On Mon, 20 Aug 2007 15:09:16 -0700, MenTaLguY <mental@...3...> wrote:
I think this may be a regression -- I'm fairly sure that at one point we had added code to dither gradients to reduce the appearance of banding.
It seems I was thinking of this patch:
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/libnr...
...which did help gradient rendering a little bit, but simply my using cleaner math rather than dithering.
Any remaining improvement is going to have to be done in the renderer, computing the gradients in higher precision, then dithering down to 32-bit RGBA.
-mental
MenTaLguY wrote:
On Mon, 20 Aug 2007 15:09:16 -0700, MenTaLguY <mental@...3...> wrote:
I think this may be a regression -- I'm fairly sure that at one point we had added code to dither gradients to reduce the appearance of banding.
It seems I was thinking of this patch:
http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/libnr...
...which did help gradient rendering a little bit, but simply my using cleaner math rather than dithering.
Any remaining improvement is going to have to be done in the renderer, computing the gradients in higher precision, then dithering down to 32-bit RGBA.
I think I've seen the greatest appearance of banding when layering multiple semitransparent gradients on top of each other. Is there something that can be done about this? Otherwise I think the banding I've experienced has been working on displays set to a lower color depth.
Aaron Spike
On Mon, 20 Aug 2007 17:36:45 -0500, Aaron Spike <aaron@...749...> wrote:
I think I've seen the greatest appearance of banding when layering multiple semitransparent gradients on top of each other. Is there something that can be done about this?
That's due to rounding error since we are only working with limited precision (8 bits per component). If we wanted to reduce banding in the case where a lot of gradients are being stacked, it'd be necessary to do the entire rendering at a higher precision (say, 16 bits per component, or even using single or double-precision floating point), and then only reduce to 8-bit precision for display/output.
Adding random noise to the gradients may help reduce the visibility of artifacts to the human eye, however. Gradients are rendered by selecting colors from a precomputed 1024-color vector, so adding a very small amount of noise to that index calculation should be sufficient.
-mental
On Mon, 2007-08-20 at 15:49 -0700, MenTaLguY wrote:
Adding random noise to the gradients may help reduce the visibility of artifacts to the human eye, however. Gradients are rendered by selecting colors from a precomputed 1024-color vector, so adding a very small amount of noise to that index calculation should be sufficient.
Ok, as of r15880 I've added a little bit of noise to gradients using a linear feedback shift register. I would consider this pretty experimental and it might get reverted later.
I'm mainly curious to see how much this helps perceptually; the real source of the banding (besides buffer precision issues) is the precomputed vector, but changing that means a pretty significant change architecturally.
-mental
On 8/21/07, MenTaLguY <mental@...3...> wrote:
Ok, as of r15880 I've added a little bit of noise to gradients using a linear feedback shift register. I would consider this pretty experimental and it might get reverted later.
I dunno about the visual effect of this, but it slows down rendering a bit. Not too much but noticeable - a file with 1600 radial gradients renders in 38.8 seconds with this and 37.4 without. So I'd like a switch to control this to be added in prefs.
On Tue, 2007-08-21 at 02:16 -0300, bulia byak wrote:
I dunno about the visual effect of this, but it slows down rendering a bit. Not too much but noticeable - a file with 1600 radial gradients renders in 38.8 seconds with this and 37.4 without. So I'd like a switch to control this to be added in prefs.
Another disadvantage is that the rendered PNGs don't compress as well (though realistically any approach which reduced the banding would have that problem to some extent).
I'll see what I can do for the pref (it'd also be helpful for before/after comparisons to assess the effect it's having); it'll require some refactoring so that the test for the prefs value doesn't have to happen in an inner loop, though, since a conditional branch in an inner loop would be likely to hurt performance more.
It's also possible we could gain back some of the lost speed through refactoring -- right now all of the gradient routines except one test for the spread type in the innermost loop, where it's least efficient to do so. Lifting that test out of the loops may also help things.
-mental
On Tue, 2007-08-21 at 02:16 -0300, bulia byak wrote:
a file with 1600 radial gradients renders in 38.8 seconds with this and 37.4 without.
Could you rerun this test to see what additional cost r15881 had, so we have a baseline before I make any other major changes? There is a definite visual improvement with it, but there is still quite visible banding, so I'm still on the fence about whether adding the noise is worth it or not.
-mental
39.9 as of 15883
On 8/21/07, MenTaLguY <mental@...3...> wrote:
On Tue, 2007-08-21 at 02:16 -0300, bulia byak wrote:
a file with 1600 radial gradients renders in 38.8 seconds with this and 37.4 without.
Could you rerun this test to see what additional cost r15881 had, so we have a baseline before I make any other major changes? There is a definite visual improvement with it, but there is still quite visible banding, so I'm still on the fence about whether adding the noise is worth it or not.
-mental
On Tue, 21 Aug 2007 13:08:34 -0300, "bulia byak" <buliabyak@...400...> wrote:
39.9 as of 15883
Hm, ok. I guess that's not too surprising since I added a floating point multiplication. _If_ we end up keeping the noise, I'll need to redo that bit using integer math instead.
-mental
As of 15923, it renders the same file in just 26.1 seconds. It's a very noticeable speedup compared to 0.45, thanks! Now please don't lose it in your further refactoring :)
On 8/21/07, bulia byak <buliabyak@...400...> wrote:
39.9 as of 15883
On 8/21/07, MenTaLguY <mental@...3...> wrote:
On Tue, 2007-08-21 at 02:16 -0300, bulia byak wrote:
a file with 1600 radial gradients renders in 38.8 seconds with this and 37.4 without.
Could you rerun this test to see what additional cost r15881 had, so we have a baseline before I make any other major changes? There is a definite visual improvement with it, but there is still quite visible banding, so I'm still on the fence about whether adding the noise is worth it or not.
-mental
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On Wed, 29 Aug 2007 02:56:02 -0300, "bulia byak" <buliabyak@...400...> wrote:
As of 15923, it renders the same file in just 26.1 seconds. It's a very noticeable speedup compared to 0.45, thanks! Now please don't lose it in your further refactoring :)
!!! That's a pleasant surprise; I was trying carefully to preserve the same code, only rearranging it so there was less duplication and changes were easier to make without needing to change multiple places in sync.
To be honest, I was expecting a performance hit, since the refactored version is broken into more (potentially non-inlined) function calls, and I actually got rid of one small optimization because I thought it was ugly.
I guess this just goes to show that cleaner code is sometimes faster code.
The one thing this hasn't done is changed the rendering artifacts due to the nearest-neighbor interpolation of the gradient vector. If we were to fix that in the "fast" renderer then we'd probably sacrifice some speed. At the moment, though, rather than making major changes to the current gradient code I'm going to focus my thought on implementing a separate high-quality rendering path for use with PNG export. I suppose we could then make it a preference for interactive use, like blur quality.
-mental
On 8/29/07, MenTaLguY <mental@...3...> wrote:
!!! That's a pleasant surprise; I was trying carefully to preserve the same code, only rearranging it so there was less duplication and changes were easier to make without needing to change multiple places in sync.
Hey, I'm a little jealous :) For the last few versions I've been fighting hard to gain each single % of speed, and now you come and make it so much faster without even suspecting it :)
I noticed you replaced address assignments with memcpy in compose function, and I think it's where the speedup comes from, even if the memcpy only copies 4 bytes in each run. Perhaps it's getting replaced with some optimized single-tick operation.
I think if you're working on gradients, you should make a similar file with thousands of gradients for yourself and run it after each recompile:
time file.svg --verb=FileClose
to notice early if your changes are making things better or worse.
As for further refinements, I'm all for creating separate modes for screen display (fast) and for export (correct). We already do it for blur. Let's make the screen gradients even faster and export gradients more correct :)
On Wed, 2007-08-29 at 22:15 -0300, bulia byak wrote:
Hey, I'm a little jealous :) For the last few versions I've been fighting hard to gain each single % of speed, and now you come and make it so much faster without even suspecting it :)
Cleaning up old code pays. :)
I noticed you replaced address assignments with memcpy in compose function, and I think it's where the speedup comes from, even if the memcpy only copies 4 bytes in each run. Perhaps it's getting replaced with some optimized single-tick operation.
Unfortunately I realized that memcpy isn't correct for the premultiplied case, which is probably the most common. I've just committed a fix for that issue which does the required premultiplication when the target is supposed to be premultiplied.
I've not had a chance to create a good test file, but I suspect we'll still come out a little bit ahead even with the fix: the big wins are likely due to inlining and the reduction of branches in the inner loop, rather than optimization of memcpy. I guess we'll find out, though.
-mental
Hi, I think issue with bad looks of gradients stops many people from using Inkscape in proffessional works. I would like to use this greate application for my webpage or for making cool pic, but this crappy looking gradients stops me. As mental has wrotten , in Inkscape 0.41 gradients looked so smooth as in photoshop.
On Tue, 21 Aug 2007 21:19:31 +0200, Tomasz Kobiela <kobi.tk@...400...> wrote:
I think issue with bad looks of gradients stops many people from using Inkscape in proffessional works. I would like to use this greate application for my webpage or for making cool pic, but this crappy looking gradients stops me. As mental has wrotten , in Inkscape 0.41 gradients looked so smooth as in photoshop.
Interesting; the big difference between 0.41 and trunk are the functions used for composing the gradient pixels with the accumulation buffer. So that gives us something to focus on.
-mental
On Mon, 2007-08-20 at 17:11 -0400, Máirín Duffy wrote:
- Round banding radiating from the lower left:
http://fedoraproject.org/wiki/Artwork/F8Themes/Infinity/Round3Scratch?action...
Could you send me the SVG for this, please?
Thanks,
-mental
MenTaLguY wrote:
On Mon, 2007-08-20 at 17:11 -0400, Máirín Duffy wrote:
- Round banding radiating from the lower left:
http://fedoraproject.org/wiki/Artwork/F8Themes/Infinity/Round3Scratch?action...
Could you send me the SVG for this, please?
Sure, it's here:
http://fedoraproject.org/wiki/Artwork/F8Themes/Infinity/Round3Scratch?action...
~m
participants (6)
-
Aaron Spike -
bulia byak -
MenTaLguY -
Máirín Duffy -
Máirín Duffy -
Tomasz Kobiela