Hi,
I'm exporting 3d surfaces from Mathematica. This creates a large number of polygons where neighboring polygons have two equal vertex-points.
Following problem: Although no stroke is used for the polygons and the coordinates of neighboring polygons are exactly equal, theres a teeny tiny space visible between them.
One hack around is to scale every polygon to 100.01% so that it overlaps a bit, but this is no solution.
Does anyone have hint for me?
I can of course provide a sample svg if someone wants to have a look.
Cheers Patrick
On 20-04-11 05:57, Patrick Scheibe wrote:
Hi,
I'm exporting 3d surfaces from Mathematica. This creates a large number of polygons where neighboring polygons have two equal vertex-points.
Following problem: Although no stroke is used for the polygons and the coordinates of neighboring polygons are exactly equal, theres a teeny tiny space visible between them.
One hack around is to scale every polygon to 100.01% so that it overlaps a bit, but this is no solution.
Does anyone have hint for me?
This is a very well known problem (and not limited to Inkscape btw). The problem lies in the way shapes are anti-aliased. At edges coverage information is encoded in the alpha channel, but this essentially only gives the percentage of the pixel covered, it has no directional information. When compositing Inkscape just uses the normal alpha compositing operator (which is more based on translucent objects than coverage): newAlpha = 1 - (1-fgAlpha)*(1-bgAlpha) So now suppose that two adjacent polygons both cover complementary halves of the pixel. Inkscape then essentially computes a result that still only covers 75% of the pixel, corresponding to the case that both polygons overlap a bit.
In the same vein as what you did, you can try enlarging shapes selectively, so that shapes overlap a bit, without the visible border moving (obviously this is laborious and only works when the shapes in question are opaque). Similarly, you can blur the shapes a bit, this can help mask the seams, but has obvious drawbacks.
Apart from doing what you did there are a few other ways around this. The most "elegant" solution is blending with a different mode. This is most easily done by looking at what Inkscape does for blending modes in layers and copying that, except that you should change the filter to use feComposite instead of feBlend, and I think you need to use operator="arithmetic" with k2 and k3 set to 1. This only works properly if no shapes (that need to be blended in this way) overlap. If you run into trouble with this, feel free to ask for help.
A simpler method (if you're exporting anyway) is to export at a very high resolution and then downsampling. This essentially just "averages out" the seams.
This is actually a pretty difficult problem to solve properly in a renderer. I know of some ways to solve it, but all require more storage and processing (although I could imagine some heuristics that would only require additional processing). If anyone has any suggestions, I'm all ears.
On Wed, Apr 20, 2011 at 10:33:01AM +0200, Jasper van de Gronde wrote:
On 20-04-11 05:57, Patrick Scheibe wrote:
Hi,
I'm exporting 3d surfaces from Mathematica. This creates a large number of polygons where neighboring polygons have two equal vertex-points.
Following problem: Although no stroke is used for the polygons and the coordinates of neighboring polygons are exactly equal, theres a teeny tiny space visible between them.
One hack around is to scale every polygon to 100.01% so that it overlaps a bit, but this is no solution.
Does anyone have hint for me?
This is a very well known problem (and not limited to Inkscape btw).
It's specifically mentioned in an OpenGL document I read once. There, the solution is to use the OpenGL functions to pass it an entire grid og triangles as several arrays. One is an array of vertices, and the others refer to vertices by indexes into that array. This just passes the problem on to the OpenGl renderer, which presumably deals with it somehow, given the clue about which vertices (and therefore edges) are to be considered the same.
I don't know if anything coparable is available in SVG, though.
-- hendrik
On 21-04-11 15:27, Hendrik Boom wrote:
On Wed, Apr 20, 2011 at 10:33:01AM +0200, Jasper van de Gronde wrote:
On 20-04-11 05:57, Patrick Scheibe wrote:
... Following problem: Although no stroke is used for the polygons and the coordinates of neighboring polygons are exactly equal, theres a teeny tiny space visible between them. ...
This is a very well known problem (and not limited to Inkscape btw).
It's specifically mentioned in an OpenGL document I read once. There, the solution is to use the OpenGL functions to pass it an entire grid og triangles as several arrays. One is an array of vertices, and the others refer to vertices by indexes into that array. This just passes the problem on to the OpenGl renderer, which presumably deals with it somehow, given the clue about which vertices (and therefore edges) are to be considered the same.
I don't know if anything coparable is available in SVG, though.
Not built-in. Additive blending should come close though, as long as the shapes being blended don't overlap. If they all have opaque fills you could even handle overlapping shapes pretty well with a more complicated filter, but that's starting to get a bit awkward.
Hi Jasper and Hendrik,
thank you for your answers, especially for Jaspers detailed explanation about the blending.
The whole situation is a big mess because
- The feComposite with mode "Over" works at a first glance quite nice. The setting Jasper suggested doesn't work like expected. The problem is, that I have overlapping polygons because if there is a "fold" in the "mathmatical"-surface and there are polygons which are invisible because this part of the surface is behind another, Mathematica still exports them. At these places the feComposite doesn't work like Jasper already pointed out. At those places the background polygons shine through the edges of the foreground polygons.
- Now that I found the "Filter Editor" with your help (since I'm technically an absolutely newbie) I looked around and found some other possible solutions to the problem. One would be to use a Dilation-operator. Problem here: you would need a tiny dilation of size around 0.001 (it depends of course on the data). It seems this doesn't work with such sizes; at least not on my machine [1].
- the number of polygons for a surface can easily grow to about 100000 which makes interactive working impossible; meaning Inkscape crashes when the plot is too complex. The plan would be to use the commandline only because my goal is to convert an svg into a pdf [2] and this doesn't require a running GUI.
Ok, I have a follow-up question:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas? Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
Cheers Patrick
[1] Ubuntu 9.10, Inkscape 0.47 [2] My main goal is to create "nice and small" pdf versions of my plots. Currently Mathematica creates pdf's which are around 20 MB and need several minutes to be rendered by the Adobe reader. Not acceptable if you want to use them in a LaTeX document.
On Thu, 2011-04-21 at 17:03 +0200, Jasper van de Gronde wrote:
On 21-04-11 15:27, Hendrik Boom wrote:
On Wed, Apr 20, 2011 at 10:33:01AM +0200, Jasper van de Gronde wrote:
On 20-04-11 05:57, Patrick Scheibe wrote:
... Following problem: Although no stroke is used for the polygons and the coordinates of neighboring polygons are exactly equal, theres a teeny tiny space visible between them. ...
This is a very well known problem (and not limited to Inkscape btw).
It's specifically mentioned in an OpenGL document I read once. There, the solution is to use the OpenGL functions to pass it an entire grid og triangles as several arrays. One is an array of vertices, and the others refer to vertices by indexes into that array. This just passes the problem on to the OpenGl renderer, which presumably deals with it somehow, given the clue about which vertices (and therefore edges) are to be considered the same.
I don't know if anything coparable is available in SVG, though.
Not built-in. Additive blending should come close though, as long as the shapes being blended don't overlap. If they all have opaque fills you could even handle overlapping shapes pretty well with a more complicated filter, but that's starting to get a bit awkward.
Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
Just to be sure: what will be your end product? If in the end you're making a bitmap, don't worry, just export at a really, really high resolution (and scale down if needed) and you should be fine (the seams will still be there, but they'll more or less be averaged out).
If you're exporting to PDF you can stop trying to use filters right now, because it won't work (as far as I know, and especially some of the more esoteric options are bound to be problematic). Unless you let Inkscape render any filtered objects to a bitmap, but then you're essentially back to exporting a bitmap.
So all of the discussion about using filters to solve your problems only applies to the case where in the end you want to show the SVG. Also, you should test anything you do in the renderer that will ultimately be used, as different renderers can give different results (mostly because of differences in what they support).
On 22-04-11 04:57, Patrick Scheibe wrote:
...
- The feComposite with mode "Over" works at a first glance quite nice.
The setting Jasper suggested doesn't work like expected. The problem is, that I have overlapping polygons because if there is a "fold" in the "mathmatical"-surface and there are polygons which are invisible because this part of the surface is behind another, Mathematica still exports them. At these places the feComposite doesn't work like Jasper already pointed out. At those places the background polygons shine through the edges of the foreground polygons.
If "over" appears to work quite nice, what's wrong with using it? (It is odd that it apparently works better than normal alpha blending btw, as I think it should be equivalent. So it might indicate a bug in Inkscape.)
Note that this approach can probably be improved a bit, but I doubt it is worth it (given the fact that you're exporting to pdf and that it's not that easy).
- Now that I found the "Filter Editor" with your help (since I'm
technically an absolutely newbie) I looked around and found some other possible solutions to the problem. One would be to use a Dilation-operator. Problem here: you would need a tiny dilation of size around 0.001 (it depends of course on the data). It seems this doesn't work with such sizes; at least not on my machine [1].
The dilation is done on the discrete data. It would be possible to enable support for subpixel sizes, but we haven't done so (and it's slightly dodgy). A size of 1px should work fine though. If that is too visible you could try doing a closing on the composited image. This is done by first doing a dilation and then an erosion (both with the same size), this should remove any small gaps.
- the number of polygons for a surface can easily grow to about 100000
which makes interactive working impossible; meaning Inkscape crashes when the plot is too complex. The plan would be to use the commandline only because my goal is to convert an svg into a pdf [2] and this doesn't require a running GUI.
You might want to try the Cairo branch, it's meant to be a lot faster and less memory hungry. If you are not able to compile it yourself, perhaps someone has a build they can send you? (I only have a Windows build.)
Ok, I have a follow-up question:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas? Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
Applying filters in this way could indeed be tricky. It might be easier to "hack" something. Given a file like this: <svg> <defs> ... </defs> <g> ... </g> </svg> You should change it to something like this: <svg> <defs> ... <filter id="a" ...> ... </filter> </defs> <g filter="url(#a)"> ... </g> </svg> The filter element can just be copied from a file that contains the right filter.
Cheers Patrick
[1] Ubuntu 9.10, Inkscape 0.47 [2] My main goal is to create "nice and small" pdf versions of my plots. Currently Mathematica creates pdf's which are around 20 MB and need several minutes to be rendered by the Adobe reader. Not acceptable if you want to use them in a LaTeX document.
If you want them "nice and small", this might not be the best way to go around it. From what you told you've got pretty detailed surfaces, those are not going to get any less detailed. It could be that Mathematica saves its pdfs without compression or something, but then it might be better to look for a program that can directly fix that.
Also, as I said at the start of this mail, if you're exporting to pdf, no amount of filtering will help you. In the end it's down to how adobe reader renders the polygons (unless you render everything to a bitmap).
As you apparently want to use these in a LaTeX document, I would recommend exporting as a high resolution png. Probably this alone will be enough to eliminate any visible seams, if not you can always go back to trying out some more tricks. But then it would be better to focus on other approaches than filtering, like writing a script that outsets all shapes by a certain radius (using lib2geom for example).
Hi Jasper,
my goal was to understand the behavior. I wanted to keep vector graphics for my plots and have them as pdf (for using it in say latex). Rasterizing them into nice looking images was never a problem but then all the labels which are text and the axes and axes-ticks which are perfect lines are rasterized too. I wanted to keep them as text and lines.
My current solution is the following:
Mathematica exports the svg polygon directives with stroke=none. I just fixed that to stroke=0.5px and set the line color to the line color of the corresponding polygon.
This gives really nice results. Then I use inkscape to convert this to a pdf file.
I see that using inkscape only for converting svg to pdf is a bit overkill (although I only use the commandline). Maybe it's better to take for instance the cairo lib and write a program which does the conversion.
By the way: Does Inkscape use Cairo to create the rendered views that you see on the screen or has it its own implementation?
Cheers Patrick
On Tue, 2011-04-26 at 09:49 +0200, Jasper van de Gronde wrote:
Just to be sure: what will be your end product? If in the end you're making a bitmap, don't worry, just export at a really, really high resolution (and scale down if needed) and you should be fine (the seams will still be there, but they'll more or less be averaged out).
If you're exporting to PDF you can stop trying to use filters right now, because it won't work (as far as I know, and especially some of the more esoteric options are bound to be problematic). Unless you let Inkscape render any filtered objects to a bitmap, but then you're essentially back to exporting a bitmap.
So all of the discussion about using filters to solve your problems only applies to the case where in the end you want to show the SVG. Also, you should test anything you do in the renderer that will ultimately be used, as different renderers can give different results (mostly because of differences in what they support).
On 22-04-11 04:57, Patrick Scheibe wrote:
...
- The feComposite with mode "Over" works at a first glance quite nice.
The setting Jasper suggested doesn't work like expected. The problem is, that I have overlapping polygons because if there is a "fold" in the "mathmatical"-surface and there are polygons which are invisible because this part of the surface is behind another, Mathematica still exports them. At these places the feComposite doesn't work like Jasper already pointed out. At those places the background polygons shine through the edges of the foreground polygons.
If "over" appears to work quite nice, what's wrong with using it? (It is odd that it apparently works better than normal alpha blending btw, as I think it should be equivalent. So it might indicate a bug in Inkscape.)
Note that this approach can probably be improved a bit, but I doubt it is worth it (given the fact that you're exporting to pdf and that it's not that easy).
- Now that I found the "Filter Editor" with your help (since I'm
technically an absolutely newbie) I looked around and found some other possible solutions to the problem. One would be to use a Dilation-operator. Problem here: you would need a tiny dilation of size around 0.001 (it depends of course on the data). It seems this doesn't work with such sizes; at least not on my machine [1].
The dilation is done on the discrete data. It would be possible to enable support for subpixel sizes, but we haven't done so (and it's slightly dodgy). A size of 1px should work fine though. If that is too visible you could try doing a closing on the composited image. This is done by first doing a dilation and then an erosion (both with the same size), this should remove any small gaps.
- the number of polygons for a surface can easily grow to about 100000
which makes interactive working impossible; meaning Inkscape crashes when the plot is too complex. The plan would be to use the commandline only because my goal is to convert an svg into a pdf [2] and this doesn't require a running GUI.
You might want to try the Cairo branch, it's meant to be a lot faster and less memory hungry. If you are not able to compile it yourself, perhaps someone has a build they can send you? (I only have a Windows build.)
Ok, I have a follow-up question:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas? Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
Applying filters in this way could indeed be tricky. It might be easier to "hack" something. Given a file like this:
<svg> <defs> ... </defs> <g> ... </g> </svg> You should change it to something like this: <svg> <defs> ... <filter id="a" ...> ... </filter> </defs> <g filter="url(#a)"> ... </g> </svg> The filter element can just be copied from a file that contains the right filter.
Cheers Patrick
[1] Ubuntu 9.10, Inkscape 0.47 [2] My main goal is to create "nice and small" pdf versions of my plots. Currently Mathematica creates pdf's which are around 20 MB and need several minutes to be rendered by the Adobe reader. Not acceptable if you want to use them in a LaTeX document.
If you want them "nice and small", this might not be the best way to go around it. From what you told you've got pretty detailed surfaces, those are not going to get any less detailed. It could be that Mathematica saves its pdfs without compression or something, but then it might be better to look for a program that can directly fix that.
Also, as I said at the start of this mail, if you're exporting to pdf, no amount of filtering will help you. In the end it's down to how adobe reader renders the polygons (unless you render everything to a bitmap).
As you apparently want to use these in a LaTeX document, I would recommend exporting as a high resolution png. Probably this alone will be enough to eliminate any visible seams, if not you can always go back to trying out some more tricks. But then it would be better to focus on other approaches than filtering, like writing a script that outsets all shapes by a certain radius (using lib2geom for example).
On 26-04-11 23:02, Patrick Scheibe wrote:
Hi Jasper,
my goal was to understand the behavior. I wanted to keep vector graphics for my plots and have them as pdf (for using it in say latex). Rasterizing them into nice looking images was never a problem but then all the labels which are text and the axes and axes-ticks which are perfect lines are rasterized too. I wanted to keep them as text and lines.
I understand, it is a vexing problem. I hope it won't be too long before we can get rid of it (I view it as a bug in the renderer, but it's a pretty fundamental bug, present in most renderers).
My current solution is the following:
Mathematica exports the svg polygon directives with stroke=none. I just fixed that to stroke=0.5px and set the line color to the line color of the corresponding polygon.
This gives really nice results. Then I use inkscape to convert this to a pdf file.
That's indeed a more pdf-proof way of dilating your polygons :)
I see that using inkscape only for converting svg to pdf is a bit overkill (although I only use the commandline). Maybe it's better to take for instance the cairo lib and write a program which does the conversion.
By the way: Does Inkscape use Cairo to create the rendered views that you see on the screen or has it its own implementation?
The latest release of Inkscape, as well as current trunk, does not use Cairo for rendering on screen. I think it probably does use it for pdf export, but I'm not 100% sure. And there is a Cairo based branch that is scheduled to be merged before the summer (there are a couple of nasty issues remaining, but generally it's in pretty good shape).
On 22/4/11 04:57, Patrick Scheibe wrote:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas?
Create a new doc with just a simple shape having the custom filter effect applied (copy&paste into the new doc) and save it into '~/-config/inkscape/filters'. After a restart of Inkscape the custom preset filter will be available in 'Filters > Personal'.
See also: http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Filters-Preset-Use.html
I'm not aware of any stable (released) Inkscape version having a 'Save' button in the filter editor.
Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
As far as I can tell, filters loaded from '~/.config/inkscape/filters/' are available as verbs (verb-list tested with Inkscape 0.48.1 on osx).
hth, ~suv
Hi,
yes, this works. I wouldn't have found this by myself.
I saw the "Save" button during my google search here
http://wiki.inkscape.org/wiki/index.php/SpecFilterEditorUI
and assumed I have an other version.
Thanks,
Cheers Patrick
On Wed, 2011-04-27 at 01:14 +0200, ~suv wrote:
On 22/4/11 04:57, Patrick Scheibe wrote:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas?
Create a new doc with just a simple shape having the custom filter effect applied (copy&paste into the new doc) and save it into '~/-config/inkscape/filters'. After a restart of Inkscape the custom preset filter will be available in 'Filters > Personal'.
See also: http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Filters-Preset-Use.html
I'm not aware of any stable (released) Inkscape version having a 'Save' button in the filter editor.
Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
As far as I can tell, filters loaded from '~/.config/inkscape/filters/' are available as verbs (verb-list tested with Inkscape 0.48.1 on osx).
hth, ~suv
On 27/4/11 01:32, Patrick Scheibe wrote:
On Wed, 2011-04-27 at 01:14 +0200, ~suv wrote:
On 22/4/11 04:57, Patrick Scheibe wrote:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas?
Create a new doc with just a simple shape having the custom filter effect applied (copy&paste into the new doc) and save it into '~/-config/inkscape/filters'. After a restart of Inkscape the custom preset filter will be available in 'Filters > Personal'.
See also: http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Filters-Preset-Use.html
I'm not aware of any stable (released) Inkscape version having a 'Save' button in the filter editor.
Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
As far as I can tell, filters loaded from '~/.config/inkscape/filters/' are available as verbs (verb-list tested with Inkscape 0.48.1 on osx).
yes, this works. I wouldn't have found this by myself.
I saw the "Save" button during my google search here
http://wiki.inkscape.org/wiki/index.php/SpecFilterEditorUI
and assumed I have an other version.
The wiki page is a recent blueprint (proposal) for a redesigned filter editor, not yet implemented: "This blueprint is about the change ideas to SVG filter editor. (…)". See also the related discussion on the mailing list 'inkscape-devel': http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/35446/focus=36387
~suv
Now I see it, but who reads the Summary when there are images in the document?
Thanks
On Wed, 2011-04-27 at 01:45 +0200, ~suv wrote:
On 27/4/11 01:32, Patrick Scheibe wrote:
On Wed, 2011-04-27 at 01:14 +0200, ~suv wrote:
On 22/4/11 04:57, Patrick Scheibe wrote:
In my version of Inkscape I cannot store filters directly. When I create a new filter it is stored automatically in/with a concrete svg file. For every new plot I would have to recreate the filter. Did I overlook something? I saw in a (of course Windoze) tutorial a "Save" button in the filter editor. This button does not exist in my version. Any ideas?
Create a new doc with just a simple shape having the custom filter effect applied (copy&paste into the new doc) and save it into '~/-config/inkscape/filters'. After a restart of Inkscape the custom preset filter will be available in 'Filters > Personal'.
See also: http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Filters-Preset-Use.html
I'm not aware of any stable (released) Inkscape version having a 'Save' button in the filter editor.
Because, when I want to apply a filter through the commandline, I assume it must be listet via "inkscape --verb-list".
As far as I can tell, filters loaded from '~/.config/inkscape/filters/' are available as verbs (verb-list tested with Inkscape 0.48.1 on osx).
yes, this works. I wouldn't have found this by myself.
I saw the "Save" button during my google search here
http://wiki.inkscape.org/wiki/index.php/SpecFilterEditorUI
and assumed I have an other version.
The wiki page is a recent blueprint (proposal) for a redesigned filter editor, not yet implemented: "This blueprint is about the change ideas to SVG filter editor. (…)". See also the related discussion on the mailing list 'inkscape-devel': http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/35446/focus=36387
~suv
On 20/04/2011 05:57, Patrick Scheibe wrote:
I'm exporting 3d surfaces from Mathematica. This creates a large number of polygons where neighboring polygons have two equal vertex-points.
Hi, I barely savvy your situation, but it occurs to me that perhaps another route could be via a bitmap -- and then get inkscape (or potrace) to trace it into a simpler SVG.
\d
participants (5)
-
donn -
Hendrik Boom -
Jasper van de Gronde -
Patrick Scheibe -
~suv