feComposite arithmetic is broken with neg values

Bug #1044989 reported by v1nce
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
Undecided
Unassigned

Bug Description

I try to make the following filter

|a - b|

so I use
max(a,b) <=> lighter(a,b) <= ok
min(a,b) <=> darker(a,b) <= ok

|a,b| should be equal to max - min

So i joined max and min using a composite|arithmetic with k2=1 and k3=-1
I used a black to white gradient over grey
I expected to get a grey/black/grey gradient and I only get a full grey

I tried some other combination to see if I get what I'd expected
(x >0)
x 0 0 0 = ok
0 x 0 0 = ok
0 0 x 0 = ok
0 0 0 x = ok

eveytime a negative value comes into the game then things go wrong
0 1 -1 0 = ko
0 0 -1 1 = ko
0 -1 0 1 = ko

Inkscape 0.48.3.1 r 9886
Ubuntu 12.04

Tags: filters-svg
Revision history for this message
v1nce (vincent-pennec) wrote :
su_v (suv-lp)
tags: added: filters-svg
su_v (suv-lp)
summary: - blendmode composite arithmetic is broken with neg values
+ feComposite arithmetic is broken with neg values
Revision history for this message
su_v (suv-lp) wrote :

Reproduced with Inkscape 0.48.3.1 on OS X 10.7.4
Not fully reproduced with 0.48+devel r11643 (see attached bitmap export)

I have yet to find an SVG renderer which would render the filter effect ("Max(a,b) - Min(a,b)") as shown in the "What's expected" sample in the file:
- Firefox 14, Chromium 23, Safari 6 fail completely to render any of the used filter effects.
- Opera 12 does better, but also fails to render the bottom one ("Max(a,b) - Min(a,b)").
- Squiggle (Batik 1.7, 1.8pre) does better, but differs from the claimed expected result, and from what Inkscape trunk renders.

-> needs further investigation as to what the correct rendering of the custom filter effect in SVG would look like.

Revision history for this message
su_v (suv-lp) wrote :

SVG rasterized with Batik 1.8pre+r1374667

Revision history for this message
v1nce (vincent-pennec) wrote :

I explain what I'd expected

for left value:
 max(0,0.5) = 0.5 (ok)
 min(0,0.5) = 0 (ok)
 k2* max + k3 * min = 1 * max + (-1) * min = max - min = 0.5 - 0 = 0.5 = grey

for middle value:
 max(0.5 , 0.5) = 0.5 (ok)
 min(0.5 , 0.5) = 0.5 (ok)
 k2* max + k3 * min = 1 * max + (-1) * min = max - min = 0.5 - 0.5 = 0 = black

for right value:
 max(1 , 0.5) = 1 (ok)
 min(1 , 0.5) = 0.5 (ok)
 k2* max + k3 * min = 1 * max + (-1) * min = max - min = 1 - 0.5 = 0.5 = grey

If I didn't miss something about premul or clamping, I think this is right

Revision history for this message
Jaspervdg (jaspervdg) wrote :

Both images have the same alpha channel. So max-min = 0 for the alpha channel, making the result completely transparent. I recommend using feComponentTransfer to invert the "min" image (which is effectively 1-min), as it can be applied per-channel, and then using something like k2=1, k3=1, k4=-1 (max + (1-min) -1). The alpha channel then remains 1 (1+1-1).

Changed in inkscape:
status: New → Invalid
Revision history for this message
v1nce (vincent-pennec) wrote :

This worked with adding the following FeColorMatrix before feComposite
-1 0 0 0 1
0 -1 0 0 1
0 0 -1 0 1
0 0 0 0 1

what I don't understand is why this doesn't work when I keep the feComposite and add the following FeColorMatrix after
1 0 0 0 0
0 1 0 0 0
0 0 1 0 0
0 0 0 0 1

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.