GRADIENTS: Banding still extremely visible.

[Troy James Sobotka]

Summary: Gradients still have unacceptable banding.

Platforms: All.

Frequency: Always (5/5 tries for manifestation).

Reproduction: Create a gradient. Examine banding.

Comments: Inkscape is an amazing tool, and yet it is still suffering from banding in many forms. Gaussian blurs, gradients, and other instances where feathered edges overlap results in unacceptable banding. Unfortunately, in order to use this tool in a production environment, banding such as this needs to be eradicated. It is a highly visible and unfortunate issue. Anything - external renderer, optimized PNG option, _anything_ would be sufficient to crutch this along until the rendering subsystem gets overhauled.

[Ryan Lerch (ryanlerch)]

Can you provide some source SVG files, screenshots and PNG exports of this issue, I have never had any banding issues with inkscape, so im thinking it was be a hardware issue...

[MenTaLguY (mental-deactivatedaccount)]

The core issue is that, regardless of the scale at which the gradient is drawn, Inkscape always divides the gradient into exactly 1024 colors for rendering. At large magnifications/scales, this is not enough. I believe this is actually a dup of an existing bug, but I can't find it at the moment.

[Troy James Sobotka (troy-sobotka)]

Hey guys, I can't help but think this is an _extremely_ important bug, and as such, I'll ask if there has been any progress made on this?

I would hope that we can somehow get to a point that we can have seamless blurs in Inkscape. It has been neglected since it's inception with regards to the rather terrible banding. It is extremely noticeable when we get into the lower value numbers for tones -- such as any colour where there are very few RGB values.

I don't know what the answer is, but it should definitely be a rendering option to provide the smoothest gradients possible for printable materials.

I realize that this probably flies in the face with the manifesto to keep Inkscape WYSIWYG. I'd suggest that perhaps that cornerstone might need to be re-evaluated in this matter for the following reasons:
 1) A full pixel perfect blur will consume vast quantities of CPU resources and Inkscape suffers from cripplingly poor performance already.
 2) Pixel perfect blurs are mandatory for print, larger works, photo realistic work, and a vast number of other critical areas. WYSIWYG demands extremely rapid response times, and as such, the two cannot coexist happily.

I beg you my dearest developers, please zoom in on this issue and get the overall performance and performance with blurring onto the table as a critical area that needs attention desperately.

Thanks for all of your hard work.

[Lorenzo (lsutton)]

Unfortunatelly I bumped into this working on a 1600x1200 file for a big screen... The banding is very visible, so as screen resolutions go up each week I gues this is not just a printing domain problem (same applies to having something projected)

[Guillermo Espertino (Gez) (gespertino-gmail)]

Gradients in vector graphics software has always been a problem.
For years the workaround (even in expensive proprietary software) was to export the gradient as bitmap and appy a noise filter to create a dithering effect on the gradient.
I guess a quick workaround would be to create a bitmap copy of the object and apply a noise filter from gimp. Another solution would be (and it would be nice) to have a filter for that in inkscape

[Alexandre Prokoudine (alexandre-prokoudine)]

@gez

This is exactly where having raster effects based on IM and not on GEGL comes biting our legs off :)

http://www.flickr.com/photos/jakubsteiner/2821205243/
http://www.flickr.com/photos/jakubsteiner/3008435393/

[Troy James Sobotka (troy-sobotka)]

Is there any progress on this guys?

It is a pretty serious issue. Is there anyone that can go in and put in a variable for the number of steps as Mentalguy points out (https://bugs.launchpad.net/inkscape/+bug/180693/comments/2)? Is there a more useful panacea we could implement?

[Guillermo Espertino (Gez) (gespertino-gmail)]

Hmmm. I think the problem is more complex. When you export a gradient to bitmap using only 8bpc you'll get banding unless some kind of dithering is applied.
It's not just about raising the amount of subdivisions.

An ugly and dirty workaround is to create the gradients in GIMP, since it implements dithering, then import the bitmap into inkscape. Unfortunately, it seems to be the only way at the moment.

[Troy James Sobotka (troy-sobotka)]

There are a few problems here of course, but the bulk aren't entirely 24bit's fault.

Hardware aside (TN LCD panels for example) I believe that way way way back when, computer graphics were evolved at SGI around 24bit as 'true colour' due to some of the median estimates of 17.3 million colours. Some estimates are as low as 10 million ( http://www.amazon.com/Business-Science-Industry-Applied-Optics/dp/0471452122 ).

The bigger problem is related to the fact that those tones are showing up next to each other and the human eye's ability to 'adapt' to spot the differences. This can result in some people being able to differentiate between certain tones with a little over 1000 values. The matter only gets more complicated when we consider that the human eye doesn't react to colour in a linear fashion - being more sensitive to the red end of the spectrum versus the blue. This makes it extremely difficult to concretely define a concrete 'how many colours' value.

Ultimately whatever hack / panacea will require some degree of dithering, regardless of bit depth.

[Pierre Bongen (pierre-bongen-spam)]

I just stumbled over this issue. I am using the following filter as a workaround. It adds a minimum of noise to the object the filter is applied to:

    <filter
       id="filter5312"
       inkscape:label="Noisy"
       inkscape:menu="ABCs"
       inkscape:menu-tooltip="Basic noise fill texture; adjust color in Flood"
       color-interpolation-filters="sRGB"
       x="-0"
       y="0"
       width="1"
       height="1">
      <feTurbulence
         id="feTurbulence5340"
         result="result4" />
      <feTurbulence
         id="feTurbulence5314"
         numOctaves="1"
         baseFrequency="0.39800000000000002"
         type="fractalNoise"
         seed="10"
         result="result3"
         in="SourceGraphic" />
      <feComposite
         id="feComposite5334"
         result="result2"
         in2="result3"
         operator="arithmetic"
         k1="0.074999999999999997"
         in="result4"
         k2="0"
         k4="0" />
      <feBlend
         blend="normal"
         id="feBlend5326"
         in2="SourceGraphic"
         mode="multiply"
         result="result1" />
    </filter>

[Pablo Trabajos (pajarico)]

Thanks for your filter, Pierre. This aliviates the problem somewhat, although there doesn't seem to be a lot of difference since this adds a turbulence overlaid on the object. What I'm looking for is something like what it's done in pixel art: http://www.rjanes.co.uk/images/tutorials/introduction/Tutorial1-Dithering1x4.png.

I'm not a filter guru, could your filter be a bit more like the example?

[Alexei Averchenko (lex-aver)]

I think that 1024 bands are more than enough for a brightness-only gradient such as yours; to improve the look further, you would have to either use slight chroma shifts (e.g. #000000 — #000001 — #000101 — #010101) or apply dithering, which is more realistic solution for the moment, IMO.

[Craig Marshall (craig9-deactivatedaccount)]

I found that the worst looking banding came when I applied a 3-stop gradient using complete opposites on the colour wheel. e.g. green, magenta, green.

One tried to work aroud the problem using the turbulence based filter above, and had no luck. Here is an alternative method which helped Quartz on #inkscape:

A simple filter made up of a gaussian blur (in the x-axis only, for a left-to-right gradient), followed by a composite filter, using the output of the blur as one input, and the source image as another, and the compositing operator set to "In":

    <filter
       id="filter2995"
       inkscape:label="Remove Banding">
      <feGaussianBlur
         stdDeviation="10 0.01"
         id="feGaussianBlur2997"
         result="result1" />
      <feComposite
         id="feComposite2999"
         in2="SourceGraphic"
         operator="in" />
    </filter>

Craig

[Craig Marshall (craig9-deactivatedaccount)]

s/One tried to work aroud/I tried to work around/

[Guillermo Espertino (Gez) (gespertino-gmail)]

I just found that the "spread" filter in GIMP is very effective dithering gradient banding.
I wonder if it would be possible to reproduce that effect using inkscape's filters (I'll try, but I'm pretty clueless in that area).
Maybe this triggers some ideas...

[Tavmjong Bah (tavmjong-free)]

Is this still a problem with the Cairo based renderer? I see some banding but I have to really look for it. Others might be more sensitive. (Could depend on display and operating system too. I'm using LInux)

I tried making gradients in Gimp with and without the dithering option. If I look very carefully I see banding in both cases at about the same level.

If it is still a problem I see two ways of dealing with it:

1. Add a dithering filter to Inkscape as already proposed.

2. Add code to optionally dither gradients when either rendering on screen or generating a PNG. We rely on Cairo to generate the gradient so the approach I would take is to blend in a small amount of noise.

I've tried both methods and while I can see a small difference it's hard see that it is really helping the bandingay

[Guillermo Espertino (Gez) (gespertino-gmail)]

I think that adding code to dither gradients on export and optionally on-screen would be a good solution.
with a "high-quality gradients" option in the PNG exporter alone I'd be a happy camper, but maybe there are others who would value having better gradients while working in inkscape. It seems like a challenge to do it with a reasonable performance, specially for larger sizes).

[Jaspervdg (jaspervdg)]

I actually experimented with adding dithering years back. It does work, but you should realize that it tends to have a pretty large impact on file sizes, and that it can be annoying if you want to use the result for further processing. I also seem to remember there were some issues with error accumulation if you applied any dithering before blending and/or filtering. In the end I concluded that it would be way better to "simply" support 16 bit (although it looked like this increased file size even more). Still, an option never hurt anyone of course.

I am not sure blending in noise after the fact is necessarily a good idea though. If someone really wants this they can always do this after the fact, and exporting intentionally noisy images might reflect badly on Inkscape. It is also not entirely clear it would actually help as much as true dithering, as the point with dithering is that the truncated part gets translated into the local distribution (which you cannot do if you already truncated the values). However, it might not be terribly difficult to implement dithering in pixman (if I had to guess I would say that this would be a good starting place: http://cgit.freedesktop.org/pixman/tree/pixman/pixman-gradient-walker.c).

[Guillermo Espertino (Gez) (gespertino-gmail)]

Blending in noise won't work as it won't smooth the transition areas between bands.
I suggested using a spread filter as it jitters pixels randomly within a threshold, creating a similar effect than true dithering (i.e.: creating the optical illusion of a continuous tone by mixing dots of two different colors).

The ideal solution would be to render the gradients in higher precision, then dither them down to 8bpc (as you mention, keeping 16bit would be also useful).

After some e-mail exchange at the mailing list with Tavmjong Bah, I could collect the following information. Please feel free to expand or correct it if something isn't right:

- Cairo has a 10 bit pixel format without alpha that could be useful for adding extra steps to a gradient (1024 levels vs. 256 per channel), but even with 10bpc, pixman creates the gradient at 8 bpc precision.
- Cairo does have simple dithering for it's xlib backend, but apparently it's only for indexed color. It would be interesting to evaluate if Cairo can be extended to add dithering to the image backend.
- Saving as PDF should produce a true PDF vector gradient, it's up to the PDF renderer to render it correctly (in my exprience, the libre PDF renderers out there don't).
- The way cairo is used by Inkscape might make it difficult to produce an effect like the aforementioned "spread" filter or applying any other possible solutions easily.

As it was mentioned on the mailing list too, the cause of banding is mainly rendering the gradients at 8bpc precision, which leaves only 256 levels per channel for work, an insuficient amount of levels for gradients that need to be represented in large sizes. The problem is more evident with grayscale gradients and blending gradients together with transparency.
Dithering seems unavoidable for 8bpc, even in the case of the gradients are produced in higher bit depths. If it has to be displayed as 8bpc, some form of dithering is required to avoid banding.

[mairin (mairin)]

Hi everybody,

We ran into this issue when creating the Fedora 25 background / wallpaper. An example SVG that clearly reproduces it on a variety of screens is here:

https://duffy.fedorapeople.org/temp/f25/banding-example.svg

Transparency in gradients appears to exacerbate it, but it's still present in gradients with 100% opaque values. The example file uses only linear and radial gradients - no mesh.

[mairin (mairin)]

Oh I also forgot to note ^^ this example has the banding in Inkscape 0.92pre1

[Martin Owens (doctormo)]

Marin, could you attach the svg here in launchpad? The link gives a 403 permission denied.

[mairin (mairin)]

Hi Martin! Sorry about that - I actually screwed up the permissions and I fixed that, but attaching as well.

[mairin (mairin)]

Example file showing the banding effects.

[Martin Owens (doctormo)]

Thanks Máirín, I see a different design in Firefox to Inkscape, but both have slight banding at regular intervals.

[Steven Warwick (sdwarwick)]

I am seeing the following severe banding on inkscape 0.92 pre3 15195
windows 10

Please forgive me if this is a settings issue and is not part of this problem.

I have set rendering at the highest level. This is simply a sans-serif font at 144 pt. with the filter "bevel->dark-glass applied.

All of the gradients seem to produce excessive distortion. Is this a similar issue?

[Hachmann (marenhachmann)]

@Steven: This issue is filter-related, not gradient related, if you mean the 'height map'-like structure.

[Steven Warwick (sdwarwick)]

@Hachmann Thanks so much for your response. I'm sorry, I thought that the kind of artifacts I'm seeing in the test.svg file would have been similar to what you folks were talking about. Are the bevel filter issues I am seeing "normal"? Or is there something that I can set to eliminate the artifacts, or is this indeed a bug that needs to be reported, or has been?

thanks

[Jaspervdg (jaspervdg)]

@Steven: I just had a quick look, and Inkscape's rendering is indeed pretty bad (arguably worse than Firefox's), so you may indeed want to file a separate bug report. Having said that, the feSpecularLighting effect relies on the precise (local) angle of the gradient w.r.t. the light source, so it is inherently sensitive to all sorts of inaccuracies that might creep in here and there. (Although this does not quite explain why it at least looks a bit better in Firefox.)

[Hachmann (marenhachmann)]

@Steven: the filter quality can be set in Inkscape's preferences (but the options do not take effect in Inkscape 0.91, due to a bug - they work again in the prerelease versions, though).
Note that if you raise the filter quality, render time goes up (one difference with Firefox is that you don't edit the file, only want to look at it). I seem to remember that the banding in some filters was caused by some kind of hard limit, but I wasn't able to find the discussion where this was said, so I may be wrong.

[Steven Warwick (sdwarwick)]

Thanks for your response.. I can't believe that the following is considered acceptable for the high quality preferences setting. regardless of rendering in a browser or in inkscape, it is not usable..

[Jaspervdg (jaspervdg)]

@Steven: as mentioned, the general problem here is most likely simply the sensitivity of the filter effect you are using to quantization issues and other causes of numerical inaccuracy. In theory, the output of the Gaussian blur should be completely smooth, but given that we operate with only 8 bit precision (per channel), it most definitely will not be. In fact, it will have a kind of staircase structure to it. Under normal circumstances the "steps" are small enough that they are not too obvious to our eyes (most of the time). Now, the first thing the filter does, is make the steps more obvious by computing a derivative. Especially in areas where the slope is fairly flat, you will either get some finite non-zero slope, or you will get a zero slope (this causes the contours!). Next, these differences are amplified even more because while small differences in slope cause reasonably small differences in angle to the light source, small differences in angle to the light source can make a huge difference in the color (this is determined by the "specularExponent" attribute).

It would be possible to improve results a bit by combining various steps to avoid some rounding steps, but this would require some pretty intense changes to Inkscape's filter rendering (and risks going against some of the more obscure aspects of the SVG spec). Ultimately, the only thing that would really help is a higher bit depth for at least the intermediate results. However, this would at the very least require more memory, may slow down filter rendering, and might again require some fairly involved changes to Inkscape.

Still, this issue is somewhat different from the banding exhibited by gradients (although ultimately the solution may be the same), so I suggest opening a new bug report. Note that compared to gradients, there is a slight possibility this will be easier to fix (although likely still not easy), as Inkscape does all of its own filter rendering.

[Steven Warwick (sdwarwick)]

@Jaspervdg Thanks for your response. I did actually create a separate problem report, and included the file I've also attached below. I'm actually thinking now that the underlying problem has to do with a fundamental limitation of SVG 1.1 - the lack of the ability to create a "gradient mesh." SVG 1.1 only allows doing linear or radial across an object. Without the mesh capability, the ability to do smooth rendering of subtle color regions is very tricky.

It is also clear that the filters in Inkscape are not finding good compromises, as you can see cases where terrible "open" areas are being generated that I think could be addressed.

SVG 2 seems like a long way off, which is a terrible pity since almost all rendering engines - including the one used in inkscape have the ability to define gradient mesh.

[Hachmann (marenhachmann)]

@Jasper: thank you for that explanation!
Steven already created a separate report here:
https://bugs.launchpad.net/inkscape/+bug/1647791

[Steven Warwick (sdwarwick)]

As an aside, after submitting the bug, I noticed that there are over 1300 "new" bug reports outstanding, likely have not been even looked at. Is it at all realistic to get a response on a bug in any reasonable time? or is the development team so overloaded that submitting a bug is more of a symbolic gesture?

[Hachmann (marenhachmann)]

<offtopic>
@Steven: Depends if someone is interested in working on the part of the code the bug touches. Filters appear to be more a part where there are fewer people interested, especially if it touches the core code of those. It's probably very hard to work on (I'm not a developer, so treat this as an educated guess). Most new bugs get at least categorized. Often, people don't respond to developers' questions; sometimes, just someone forgot to set the category.

But yes, Inkscape needs all the help it can get, of course :) Volunteers are hard to get by, and every bit helps.

Bug testing is a good way to get involved for people who are starting out.
If you'd like to help out by making that pile you mentioned smaller, you can first take a look here https://inkscape.org/en/develop/bug-management/ , then contact the devs in the #inkscape-devel IRC channel on freenode.
</offtopic>