RFC: SVG filter transformations
Well, it looks like Inkscape's behavior is non-compliant at the moment, but only under certain combinations of transformations (generally, rotation + non-uniform scaling). bulia and I have been discussing this, and since reworking filters will take a while, we think we have two options for this release:
1. leave the behavior as it is
2. disable filter rendering when the output would be non-compliant
#1 has the advantage that the bug would be less noticeable (fewer user complaints until the next release when it's fixed), and it has the disadvantage that the bug would be less noticeable (people getting bitten when the rendering behavior changes in the next release).
#2 has the advantage that it actively discourages people from using filters in situations where Inkscape can't currently render them properly. It has the disadvantage that it might actively discourage them from using filters.
Which one should we go with? Other suggestions?
-mental
On Thu, Dec 28, 2006 at 03:51:29PM -0500, MenTaLguY wrote:
Well, it looks like Inkscape's behavior is non-compliant at the moment, but only under certain combinations of transformations (generally, rotation + non-uniform scaling). bulia and I have been discussing this, and since reworking filters will take a while, we think we have two options for this release:
leave the behavior as it is
disable filter rendering when the output would be non-compliant
#1 has the advantage that the bug would be less noticeable (fewer user complaints until the next release when it's fixed), and it has the disadvantage that the bug would be less noticeable (people getting bitten when the rendering behavior changes in the next release).
#2 has the advantage that it actively discourages people from using filters in situations where Inkscape can't currently render them properly. It has the disadvantage that it might actively discourage them from using filters.
Which one should we go with? Other suggestions?
Since the filters are a new feature, option #2 sounds like it doesn't remove functionality, but simply adds less then it potentially could. Since the part that it wouldn't be adding isn't correct anyway, it doesn't sound like the user is losing too much.
Perhaps a configuration option in the .inkscape/preferences.xml could be provided to turn on the non-compliant behavior if we suspect some people will want to have the capability? Then we protect the vast bulk of our audience from producing non-compliant SVG, but allow it for anyone who really, really needs that effect?
Bryce
On Thu, 2006-12-28 at 19:16 -0800, Bryce Harrington wrote:
Perhaps a configuration option in the .inkscape/preferences.xml could be provided to turn on the non-compliant behavior if we suspect some people will want to have the capability? Then we protect the vast bulk of our audience from producing non-compliant SVG, but allow it for anyone who really, really needs that effect?
I don't think it's worth the effort to add a pref, since we'll be taking the behavior away in the next version anyway.
-mental
MenTaLguY wrote:
Well, it looks like Inkscape's behavior is non-compliant at the moment, but only under certain combinations of transformations (generally, rotation + non-uniform scaling). bulia and I have been discussing this, and since reworking filters will take a while, we think we have two options for this release:
leave the behavior as it is
disable filter rendering when the output would be non-compliant
Which one should we go with? Other suggestions?
They both sound pretty dreadful and each could be problematic to a different subset of users.
There are a few other options I can suggest:
3. Block on this, delaying release until it's fixed (how much work is a fix?)
4. Keep users informed. Brand release specifically as alpha to suggest that blur filters applied with this version could still change in future versions and suggest that 0.44 may be more 'stable' with respect to the SVG spec. This is not much different to 3, in fact, as the webpage already differentiates between development versions and releases.
5. Leave behavior as is but add special code in future to correct SVG files in which inkscape:version implies that the filter was originally wrong. Would allow for backward compatibility in 0.46 on but doesn't fix compliance for 0.45. Would also specifically have to deal with flagged objects in future.
6. Disable blur controls unless an option in Inkscape preferences is checked. The options page could explain the compatibility/conformance issue and let users take responsibility for enabling it.
I prefer 3, 4 or (to a lesser extent 6) to 1 and I don't care much for 5 or 2. 2 would be more acceptable if there was some feedback for users every time a filter is prevented from rendering.
Dan
On 12/28/06, Daniel Pope <mauve@...1559...> wrote:
leave the behavior as it is
disable filter rendering when the output would be non-compliant
Which one should we go with? Other suggestions?
They both sound pretty dreadful and each could be problematic to a different subset of users.
There are a few other options I can suggest:
- Block on this, delaying release until it's fixed (how much work is a
fix?)
Hard to say until one tries. Of course 3 would be the best option if someone would step forward and make a commitment to fix this within some reasonable time frame (say a couple weeks). Unfortunately this can't be me because I'm rather swamped with other work and it's not my domain of expertise anyway. And without such a commitment from someone, I don't think we can really delay 0.45 any longer.
- Keep users informed. Brand release specifically as alpha to suggest
that blur filters applied with this version could still change in future versions and suggest that 0.44 may be more 'stable' with respect to the SVG spec. This is not much different to 3, in fact, as the webpage already differentiates between development versions and releases.
The 4 is kinda implied; of course we will add a prominent note to Release Notes. Giving any special moniker to the release is not necessary, because we are officially under 1.0 anyway.
- Leave behavior as is but add special code in future to correct SVG
files in which inkscape:version implies that the filter was originally wrong. Would allow for backward compatibility in 0.46 on but doesn't fix compliance for 0.45. Would also specifically have to deal with flagged objects in future.
That may be possible but it should not affect our decision of what to do now.
- Disable blur controls unless an option in Inkscape preferences is
checked. The options page could explain the compatibility/conformance issue and let users take responsibility for enabling it.
No, that is not an option. Blur is a big part of the reason for releasing 0.45 at all. Lots of people look forward to it. Most users will never have problems from this incompatibility, especially if we implement 2 (which should be relatively easy). However personally I'm against 2, because it will look too much like a bug for those who run into it. I think the change in rendering after we fix rendering will in most cases be slight and therefore less of a problem than 2.
Fri, 29 Dec 2006 03:58:45 +0000 Daniel Pope <mauve@...1559...> kirjoitti:
- Block on this, delaying release until it's fixed (how much work is
a fix?)
Depends how good a fix is needed...
Here attached is a simple solution. 1) It transforms rendered object to a coordinate system, that is paraller with screen pixels. 2) It renders the filter. 3) It transforms filtered object back to original coordinate system.
This includes two bitmap transformations -> not good for image quality. Especially, as these are implemented with nearest neighbour sampling.
Still, this should not affect images that were rendered correctly with original method.
Attached: * diff against svn trunk * new files src/display/pixblock-transform.cpp and src/display/pixblock-transform.h
As this issue is under discussion here, I haven't commited this patch to svn yet.
On 12/29/06, Niko Kiirala <niko@...1267...> wrote:
Here attached is a simple solution.
- It transforms rendered object to a coordinate system, that is
paraller with screen pixels. 2) It renders the filter. 3) It transforms filtered object back to original coordinate system.
Thanks! That was fast. However, th patch does not work for me - with the same sequence of actions (cirsle, blur, squeeze, rotate) I see a grid of strange lines, all inclined at a larger angle than the object is supposed to be. Looks like your code doubles the rotation angle. I also get a bunch of
** (inkscape:6876): WARNING **: Location 23684 out of bounds (0 ... 23688) at line 72
** (inkscape:6876): WARNING **: Location 249884 out of bounds (0 ... 249888) at line 79
** (inkscape:6876): WARNING **: Location 23684 out of bounds (0 ... 23688) at line 79
** (inkscape:6876): WARNING **: Location 23684 out of bounds (0 ... 23688) at line 72
** (inkscape:6876): WARNING **: Location 249884 out of bounds (0 ... 249888) at line 79
** (inkscape:6876): WARNING **: Location 23684 out of bounds (0 ... 23688) at line 79
etc. on the console.
Fri, 29 Dec 2006 19:49:28 -0400 "bulia byak" <buliabyak@...400...> kirjoitti:
Thanks! That was fast. However, th patch does not work for me - with the same sequence of actions (cirsle, blur, squeeze, rotate) I see a grid of strange lines, all inclined at a larger angle than the object is supposed to be. Looks like your code doubles the rotation angle.
Uh... Seems so. I'm guessing that those lines are an interference pattern created from bitmap transform. Also, it seems that if you squeeze the circle to, say, half of it's height, the result is quite good. If you squeeze the circle to one tenth of initial height, all you see is those lines.
To fix this, I think the scaling factor should be calculated in some other way in nr-filter.cpp and transformer should use bilinear or bicubic resampling.
I also get a bunch of
** (inkscape:6876): WARNING **: Location 23684 out of bounds (0 ... 23688) at line 72
Odd, wonder why I'm not seeing those messages. It seems though, that those are not caused by a real problem, but by an off by one error in debugging routine: pixblock-transform.cpp:36 should have (location + 4) > max_loc instead of (location + 4) >= max_loc
Sat, 30 Dec 2006 09:35:06 +0200 Niko Kiirala <niko@...1267...> kirjoitti:
To fix this, I think the scaling factor should be calculated in some other way in nr-filter.cpp and transformer should use bilinear or bicubic resampling.
Uh, and already forgot... I think I can look into these problems after New Year.
There seems to be a bigger problem lurking, though: filter effects region and it's clipping. As for now, that region is calculated in screen coordinates, which leads to wrong filter effects region with skewed and/or rotated objects: the region and thus the filter effects clipping area should also be skewed and/or rotated.
This would require some method to determine object bounding box in it's own coordinate system and some way to determine, where corners of this bounding box are located in screen coordinates. (all four of those, as the bounding box may not be paraller to screen axis)
On Fri, 2006-12-29 at 19:32 +0200, Niko Kiirala wrote:
Depends how good a fix is needed...
Here attached is a simple solution.
- It transforms rendered object to a coordinate system, that is
paraller with screen pixels. 2) It renders the filter. 3) It transforms filtered object back to original coordinate system.
That is roughly what we will need to do in order to implement filters compliantly in general, so it seems like a good approach.
-mental
Sat, 30 Dec 2006 15:50:01 -0500 MenTaLguY <mental@...3...> kirjoitti:
That is roughly what we will need to do in order to implement filters compliantly in general, so it seems like a good approach.
OK, I have now commited the patch in SVN, with some minor modifications to make rendering artifacts much less visible.
There is another oddity, though. As I compared blurred image produced from batik and inkscape, the one from batik seemed much lighter. It seems as though batik renders objects against transparent white background while inkscape renders against transparent black background.
SVG standard specifies transparent black background in many places, so I don't belive this is a problem in Inkscape.
On 1/3/07, Niko Kiirala <niko@...1267...> wrote:
OK, I have now commited the patch in SVN, with some minor modifications to make rendering artifacts much less visible.
Thanks, now it works perfect! A bit slowish, but this is to be expected, and even SVG specification recommends against using filters on rotated objects because of potential performance problems. But if anyone needs it, now it works properly. I'm closing bug 1617112.
There is another oddity, though. As I compared blurred image produced from batik and inkscape, the one from batik seemed much lighter. It seems as though batik renders objects against transparent white background while inkscape renders against transparent black background.
I haven't noticed any difference myself - can you give an example?
Thu, 4 Jan 2007 06:38:59 -0500 "bulia byak" <buliabyak@...400...> kirjoitti:
There is another oddity, though. As I compared blurred image produced from batik and inkscape, the one from batik seemed much lighter. It seems as though batik renders objects against transparent white background while inkscape renders against transparent black background.
I haven't noticed any difference myself - can you give an example?
Well, here's a really simple svg and renderings I got from both Inkscape and Batik.
Examining those two bitmap images, you can notice, how the colors in batik rendering range from semi-opaque gray to transparent white, but colors in inkscape rendering range from semi-opaque black to transparent black.
However, it can as well be, that I just don't know how to use batik to produce those images.
On 1/4/07, Niko Kiirala <niko@...1267...> wrote:
Examining those two bitmap images, you can notice, how the colors in batik rendering range from semi-opaque gray to transparent white, but colors in inkscape rendering range from semi-opaque black to transparent black.
I really can't see any difference in brightness between Inkscape SVN and Batik 1.5.1 rendering.
On Sat, 2007-01-06 at 17:50 -0400, bulia byak wrote:
I really can't see any difference in brightness between Inkscape SVN and Batik 1.5.1 rendering.
I can, in fact it's really obvious for me. I wonder if it is a difference in gamma information in the PNG or something?
-mental
On 1/7/07, MenTaLguY <mental@...3...> wrote:
On Sat, 2007-01-06 at 17:50 -0400, bulia byak wrote:
I really can't see any difference in brightness between Inkscape SVN and Batik 1.5.1 rendering.
I can, in fact it's really obvious for me. I wonder if it is a difference in gamma information in the PNG or something?
To clarify: of course I see the difference between the two PNG files that Nico attached. But when I render the circle.svg in Inkscape SVN and Batik 1.5.1 on the same system, they both render the same as in Nico's circle-inkscape.png.
participants (5)
-
Bryce Harrington -
bulia byak -
Daniel Pope -
MenTaLguY -
Niko Kiirala