component transfer issue

[Pétery Tamás]

The component transfer filter primitive seems to have a bit of inaccuracy at the rendering.
Using it as a base for a threshold filter, the discrete mode input doesn't chop the luminance levels at 50% when it is set to 0 1, or when linear input is chosen with 10; -5 settings.

Have a look at this simpe test file:
https://openclipart.org/detail/269661/component-transfer-compare

It shows several errors in one file.
0.91 renders the filter with a solid fill on the right.
Zooming into the top right corner of the image
-pattern fill does not render after zooming in more than 3200%
-checkerboard background does not render from 9051%
-filtered object's part intended to be transparent renders solid black at 12800%
-at any zoom level the diagonal step in the fill from the filter doesn't go straight into the square's corner as it should.

Tested on win 10 64bit Inkscape 0.92pre3 15195.

[su_v (suv-lp)]

Attaching external file to bug report (external links have a tendency to get lost at some point in time).

[su_v (suv-lp)]

On the openclipart.org page, you add the comment:
<quote>
Works as described with 0.92.
</quote>

Could you please clarify which remaining issue there is with feComponentTransfer in the tested release candidate Inkscape 0.92pre3 15195?

The issue with discrete mode failing (in Inkscape 0.91) is likely already tracked in bug #1046093 (fixed for upcoming 0.92).

[Pétery Tamás (lazur)]

The original problem which why I uploaded the file was the "red diagonal" not going through the corner.

After the upload realised that the thumbnail showed a square with a solid fill, generated with 0.91.
That issue is unrelated to the reported problem.

So to clarify it a bit more.
The filtered object is a square with a black to white linear gradient fill going from top left corner to bottom right, meaning that the diagonal from bottom left to top right should be filled with a perfect midtone, half between absolute dark and light.
The filter applied uses an fecolormatrix in luminance to alpha mode, and the component transfer is added to the alpha channel of that.
Upon the component transferring, flood fills are used and compositing to fill up the areas with the same alpha values, resulting in a red and a transparent half
-red should indicate areas where the source's luminance is less than the midtone's, and transparent where it is lighter than that.
By the discrete input set to 0 1, it is supposed to make that "cut" right at the middle, but somehow it is shifted at the rendering. Same goes with the linear input set.

The gradient bending leaves a step right through the corner so it's probably not about the low colour depth rendering of the srgb.

[su_v (suv-lp)]

So the bug description for Inkscape 0.92pre3 could be reduced to this?

«Using the feComponentTransfer filter primitive as a base for a threshold filter in discrete mode (for example with tableValues="0 1"), or linear mode (for example with slope="10" intercept="-5") lacks precision in the rendered output:

- at any zoom level the diagonal step in the fill from the filter doesn't go straight into the square's corner as it should.»

Attached is a further reduced test case.

[Pétery Tamás (lazur)]

Yes, that would be the very base.

[su_v (suv-lp)]

Based on tests with archived builds (on OS X 10.7.5):
- not reproduced with Inkscape 0.48.x r10040
(with the workaround for bug #1046093 applied, the output of either mode is geometrically precise, see e.g. attached screenshot zoomed in to the max.)
- reproduced with lp:inkscape >= 10326 (merge of the cairo-renderer branch)
- reproduced with Inkscape 0.91 r13725,
- reproduced with lp:inkscape/0.92.x r15283

Revision 14532 fixed two bugs for this filter primitive (but not the precision which was lost with the new cairo-renderer):
1. Discrete type was ignoring last value in list.
2. Change in alpha was not propogated to pre-multiplied color
values leading to "ghosting".
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14532