Hi Gez,
Thanks for your email summary of the problems with banding.
On Sat, 2016-01-09 at 17:33 -0300, Gez wrote:
A few weeks ago, Tavmjong added a comment to bug #180693, asking if the reported issue was still present with the new renderer. I'm answering here, as I'm adding some personal comments that probably don't belong to the bug report. Please tell me if it's is worth that I add some of this information to the bug report, or feel free to do it if anyone wants to.
It would be useful to have this in the bug report as the solution to the banding problem is probably not a quick fix and info in emails tends to be lost over time.
Regarding the question, As long as Inkscape renders at 8bpc, yes. It will still be a problem. It's possible that some sizes and colors hide the problem more than others, but banding will still be a problem unless images are rendered in higher precision.
As most LCD panels are still 8 bit rendering at a higher resolution won't solve the problem in the short term. Cairo is limited to 8bpc (except a 10bpc mode without alpha).
The easiest way to check this is to draw a grayscale gradient. At 8bpc, you can't paint more than 256 shades of gray. So a 256px- wide gradient will look ok, but as soon as you stretched that gradient to a larger size, banding will appear. An even more extreme example (but not less frequent) is when you also have a grayscale gradient, but instead of going from black to white you go from a middle gray to a lighter gray. If your gradient takes, say 50 levels out of those 256, stretching the gradient will result in severe banding sooner.
I don't think it's possible to address banding in 8bpc without some form of dithering, and it looks that the current renderer doesn't apply any.
We use Cairo directly for gradients. Cairo does have simple dithering for its xlib backend but I think it is only for indexed color. I wonder if Cairo would be amenable to adding dithering to the image back end which is the only place we would need it.
As I mentioned in an older comment, the best way I could find to work around this was using the "spread" filter in GIMP, which jitters the edges of each step of the gradient making it look smoother.
How do you handle shape edges? I suppose one could limit the "spread" to interior regions a certain distance for the edge.
There are existing dithering algorithms that could be used too, like floyd-steinberg, bayer, a-diher (http://pippin.gimp.org/a_dither/), etc. but I wonder how effective would they be as we don't have a smooth gradient as a starting point, but a stepped one. Those dithering algos could be useful if inkscape rendered at 16bpc, to bring down the display to 8bpc though.
It might be possible to render gradients using 10bpc for RGB and then dither down to 8bpc.
At any rate, rasterizing a vector shape and applying a filter would be prohibitively slow for large sizes so this dithering, if applied, should be probably applied only to export, making this solution unsuitable for on-screen representation. Anyway, I don't think banding is too much of a problem (it is, but it's not as severe) for screen as it is for printing. For printing it becomes a critical issue, as other commenters pointed out. Inkscape is a valuable tool for large format printing which I use daily, and time to time I have to apply some nasty workarounds because of this limitation. For my professional work, the way inkscape renders gradients is a show- stopper. The quality of my work suffers if I don't apply one of those tedious workarounds discussed in this thread.
If you save as PDF you should get a true PDF vector gradient. In this case it is up to the PDF renderer to get the gradient correct.
This bug has been reported about 8 years ago, and a lot happened since. Maybe this time, with a new renderer there's something that can be done to get it fixed?
It's not an easy bug to fix given the way we use Cairo.
Tav
Gez