The banding issue is more apparent on a black to white gradient. The human eye can see the difference between luminance levels way more than changes of the chroma -hue&saturation.
Out of that rgb model the screen uses -and as a result, which is also
hard-wired to inkscape by default- there are only 256 steps to render throughout such a smooth black to white gradient.
Theoretically that means equal lightness steps rendered in between.
(It is a matter of the rgb model used though -linearrgb vs. srgb. The human eye can differentiate between the darker shades better. So there is also an option of
gamma correction which alters the range of the lightness levels. Some screens have
gamma settings, but it can also be simulated on screen by the softwares running.)
(Side note: inkscape before the current cairo renderer -probably before 0.48- used to only render 1024 steps the max on any kind of gradient.)
So with that greyscale gradient there are areas visibly filled with the exact same colour, as 256 flat filled rectangles next to eachother would be rendered. These areas produce a visible "edge", which is referred to as
Mach banding.
How to solve the issue?
Extending the depths available for rendering. It needs a screen that can render more brightness levels -instead of using 24bit truecolor, using some
deepcolor.
-24bit means there are 8 bits stored for each rgb values, that is 2^8=256.-
For example if we were using 48bit colours, that'd mean 2^16=65536 luminance levels. We are hardly near that.
30bit seems the closest step (10bit per channel) when looking around. There are some pricy monitors that can produce such an output.
Benq claims to even produce a
look up table with 14bit channels.
However that also requires an appropriate gpu and
setting it up.
Not sure how inkscape would perform on such a high-end environment.
Or if any of that could be transferred to a printable pdf.
The other option is cheating. Tricking the eye so that the transition looks smoother.
Basically anykind of
halftoning effect can be used.
Dithering is more of a downsampling solution on raster images. There are
several types of them, you can choose some of those options like when using gimp and changing the image mode to a smaller colour depth.
By definition the dithering algorithm is applied on screen pixels so in a scalable vectorgraphic environment where you can zoom in it would be very resource heavy -and probably a mess just like the convolve matrix.
Gimp adds some "dithering" to gradients drawn. Edges are not smooth but the colour step values are spread in some hard-wired fashion.
With filtering you can simulate a similar effect by displacement in inkscape. Needless to say it's not a good solution since there is no way to control the direction based upon a gradient handle.
Some cases a dither-like filter may help a bit, but generally it's a huge burden (and resource-heavy) to be added to any gradient fill along with additional clipping just because the renderer produces a lacking result without it.
Getting myself together has hardly anything to do with those technical aspects as per se.
Apparently I've lost most of my interest in the current life I'm living. Need to make some serious changes. Getting back to abandoned projects may be one of them.
