On Mon, 2016-01-11 at 00:35 -0300, Gez wrote:
El dom, 10-01-2016 a las 22:09 +0100, Tavmjong Bah escribió:
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.
Ok, I'll add a summary of the things discussed here to the report.
Thanks!
...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).
Yes, dithering seems unavoidable, at least for the display. If the internal representation was done in higher precision, it might be interesting to add the option to export for instance 16 bpc PNGs, which could useful to produce high quality renderings. However, as you said, 8bpc will still be needed for most of the displays, the web and general imaging. And that means dithering.
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.
What I do is duplicating the gradient and masking it with a selection. That makes that the pixels don't spread out of the selection, and the outside pixels spreading inside the selection are transparent, so the original gradient is visible.
Ugh... that's a lot of work.
Now I have no idea of how Cairo works, but it doesn't seem like a very difficult thing to achieve. It's just matter of replacing pixels that spread inside form outside with the original pixel.
Put in simple terms, when I do it in GIMP that means that: a) spread pixels with alpha == 0 will reveal the original, un- dithered gradient b) opaque pixels will be spread but masked by the original alpha channel.
It's not very easy to grab the right pixels given the way the code is structured...
It might be possible to render gradients using 10bpc for RGB and then dither down to 8bpc.
I've checked, even with 10bbc, pixman creates the gradient with 8bbc. (We rely on Cairo to generate the gradient which in turn relies on pixman to create the gradient with the right transformations applied. The relevant code is ins pixman-gradient-walker.c, function _pixman_gradient_walker_pixel().)
From what I read a couple of days ago in old threads, it was mentioned that inkscape already renders gradients with 1024 steps. Is it possible that inkscape is already using the 10bpc format already?
No. That was before we switched to Cairo.
It would be interesting to see whether 1024 levels dithered down to 256 with cairo's dithering is enough to provide a smoother gradient than spreading the 256 levels.
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.
From what I could see, libre PDF viewers kept the banding. I should test more thoroughly, but that was the case the last time I tried (it was Inkscape 0.92, so it was Cairo)
It's not an easy bug to fix given the way we use Cairo.
I've read a couple of times that things had to be done this or that way, which isn't always the ideal, because of Cairo. And I'm not talking only about inkscape. Cairo seems to be too tied to 8bpc and sRGB, which can be very limiting for modern imaging (where linear gamma and higher bit depths make more sense). Is it possible that using Cairo for anything else that just displaying the output of a graphics program and some widgets isn't a very good choice after all? It's a honest question. Not trying to start any debate or flamewar, I'm interested to know the arguments for (or against) cairo as a renderer. Isn't Cairo holding back some progress on certain fields like PDF export or more advanced compositing and color management?
The real advantage of Cairo is that the same code can be used for rendering pixel images as PostScript and PDF. It is also actively being maintained and integrates well with Pango.
Tav
Kind regards,
Gez.