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