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.
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. 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.
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.
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.
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.
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?
Gez
The same is true for rendering gaussian blur in SVG filters and that causes very annoying steps in many cases like bevel and emboss effects.
Le 09/01/16 21:33, Gez a écrit :
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.
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. 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.
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.
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.
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.
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?
Gez
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sat, 2016-01-09 at 22:27 +0100, ivan louette wrote:
The same is true for rendering gaussian blur in SVG filters and that causes very annoying steps in many cases like bevel and emboss effects.
This is more of a problem with the SVG specification when the input/output of each filter primitive is limited to 8 bit color. Using 8 bit inputs for the bump maps used by the lighting filter primitives results in the steps seen.
I was just looking at the new CSS Filter Specification. (SVG filters were pulled out of the SVG specification and put into there own spec so that CSS could use them fo HTML.) It does not mention the bit depth anywhere. I can propose at the next CSS/SVG joint working group meetings that all internal calculations inside filters should be done with higher precision (much like transformations are required to do). This would reduce significantly the problems you see.
Tav
Le 09/01/16 21:33, Gez a écrit :
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.
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. 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.
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.
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.
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.
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?
Gez
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Thanks a lot ! That could be very nice indeed !
ivan
Le 10/01/16 11:01, Tavmjong Bah a écrit :
On Sat, 2016-01-09 at 22:27 +0100, ivan louette wrote:
The same is true for rendering gaussian blur in SVG filters and that causes very annoying steps in many cases like bevel and emboss effects.
This is more of a problem with the SVG specification when the input/output of each filter primitive is limited to 8 bit color. Using 8 bit inputs for the bump maps used by the lighting filter primitives results in the steps seen.
I was just looking at the new CSS Filter Specification. (SVG filters were pulled out of the SVG specification and put into there own spec so that CSS could use them fo HTML.) It does not mention the bit depth anywhere. I can propose at the next CSS/SVG joint working group meetings that all internal calculations inside filters should be done with higher precision (much like transformations are required to do). This would reduce significantly the problems you see.
Tav
Le 09/01/16 21:33, Gez a écrit :
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.
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. 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.
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.
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.
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.
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?
Gez
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
El dom, 10-01-2016 a las 11:01 +0100, Tavmjong Bah escribió:
On Sat, 2016-01-09 at 22:27 +0100, ivan louette wrote:
The same is true for rendering gaussian blur in SVG filters and that causes very annoying steps in many cases like bevel and emboss effects.
This is more of a problem with the SVG specification when the input/output of each filter primitive is limited to 8 bit color. Using 8 bit inputs for the bump maps used by the lighting filter primitives results in the steps seen.
I was just looking at the new CSS Filter Specification. (SVG filters were pulled out of the SVG specification and put into there own spec so that CSS could use them fo HTML.) It does not mention the bit depth anywhere. I can propose at the next CSS/SVG joint working group meetings that all internal calculations inside filters should be done with higher precision (much like transformations are required to do). This would reduce significantly the problems you see.
Even though the calculations are done in higher precision, the results will still need some dithering when sent back to an 8 bpc output, otherwise the banding will still be there (perhaps a bit mitigated in some effects like bevel and emboss, but still there for gradients and gaussian blur).
Gez.
ivan,
Can you give me some simple examples of filters that result in annoying steps? I'll present them at the meeting in a week.
Tav
On Sun, 2016-01-10 at 11:01 +0100, Tavmjong Bah wrote:
On Sat, 2016-01-09 at 22:27 +0100, ivan louette wrote:
The same is true for rendering gaussian blur in SVG filters and that causes very annoying steps in many cases like bevel and emboss effects.
This is more of a problem with the SVG specification when the input/output of each filter primitive is limited to 8 bit color. Using 8 bit inputs for the bump maps used by the lighting filter primitives results in the steps seen.
I was just looking at the new CSS Filter Specification. (SVG filters were pulled out of the SVG specification and put into there own spec so that CSS could use them fo HTML.) It does not mention the bit depth anywhere. I can propose at the next CSS/SVG joint working group meetings that all internal calculations inside filters should be done with higher precision (much like transformations are required to do). This would reduce significantly the problems you see.
Tav
Le 09/01/16 21:33, Gez a écrit :
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.
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. 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.
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.
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.
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.
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?
Gez
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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.
...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.
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 might be possible to render gradients using 10bpc for RGB and then dither down to 8bpc.
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?
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?
Kind regards,
Gez.
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.
Hi,
I presented both the gradient banding and the filter artifacts problems at the joint CSS/SVG working group meeting in Sydney.
For the gradient banding problem, I asked if we could specify a dithering algorithm. The reception to the idea seemed good. It was suggested that I propose a method and syntax to the CSS working group. I'll do that in the future.
For the filter artifact problem, I proposed that filters should be evaluated using floats internally. Dean Jackson (Apple), one of the Filter spec editors is going to look into it.
I noticed that the filter artifacts with both Firefox and Chrome are less visible that with Inkscape. It looks like they are doing some kind of blending or dithering. That is something we could investigate. I know that applying a small amount of blur at the end helps quite a bit.
Tav
Thanks a lot Tav ! That would be so nice if these problems could be addressed ! ivan
Le Dimanche 28 février 2016 10h23, Tavmjong Bah <tavmjong@...8...> a écrit :
Hi,
I presented both the gradient banding and the filter artifacts problems at the joint CSS/SVG working group meeting in Sydney.
For the gradient banding problem, I asked if we could specify a dithering algorithm. The reception to the idea seemed good. It was suggested that I propose a method and syntax to the CSS working group. I'll do that in the future.
For the filter artifact problem, I proposed that filters should be evaluated using floats internally. Dean Jackson (Apple), one of the Filter spec editors is going to look into it.
I noticed that the filter artifacts with both Firefox and Chrome are less visible that with Inkscape. It looks like they are doing some kind of blending or dithering. That is something we could investigate. I know that applying a small amount of blur at the end helps quite a bit.
Tav
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
El dom, 28-02-2016 a las 10:21 +0100, Tavmjong Bah escribió:
Hi,
I presented both the gradient banding and the filter artifacts problems at the joint CSS/SVG working group meeting in Sydney.
For the gradient banding problem, I asked if we could specify a dithering algorithm. The reception to the idea seemed good. It was suggested that I propose a method and syntax to the CSS working group. I'll do that in the future.
For the filter artifact problem, I proposed that filters should be evaluated using floats internally. Dean Jackson (Apple), one of the Filter spec editors is going to look into it.
I noticed that the filter artifacts with both Firefox and Chrome are less visible that with Inkscape. It looks like they are doing some kind of blending or dithering. That is something we could investigate. I know that applying a small amount of blur at the end helps quite a bit.
Hi Tav, Great news. Thanks!
Gez.
participants (4)
-
Gez -
ivan louette -
Ivan Louette
-
Tavmjong Bah