In 0.91 when exporting to bitmap (PNG) Inkscape creates an antialised, thin blurry edge around objects, even on perfectly horizontal and vertical edges. This doesn't happen in 0.48.

In 0.91 it does not help turning off "Use antialiasing" in "properties for document", it still happens. Also If I turn off antialiasing ALL antialiasing is turned off (except for this strange blurry edges) and of course I still want antialiasing in the whole image on non vertical/now horizontal edges.

The blurred edge is very thin so it can be hard to see on an image unless zoomed in.

Therefore I zoomed in one the image in this screenshot (9000% zoom) so you can see what it is I am talking about:

Inkscape v.0.91. Blurry edge on PNG image:


Inkscape v.0.48. No blurry edge on PNG image (also 9000% zoom):

Hello,

I have same results here in Ubuntu 14.10 in an old P4 machine.

When I try save as cario PNG, the results are similar.

So... you are not crazy!

Maybe it's related to this

http://wiki.inkscape.org/wiki/index.php ... own_issues

The Cairo library used in the new renderer does not implement downscaling, which causes large bitmaps to be pixelated on export. [4] The issue can be fixed by upgrading to Cairo 1.14.0. [5]

Synfig studio allready uses Cairo, but it has options related to anti alias when rendering

http://wiki.synfig.org/wiki/Render_dialog

We would need to see the image as the SVG, before you exported it, to try and figure it out. Could you set up a comparison of the same object exported in bothh 0.91 and 0.48.x, and attach the 2 SVG files?

It looks like there might be a filter applied to the SVG, before you exported it -- emphasis on "looks like". I saw another image in another topic that also looked like it, but that wasn't the problem there, and it might not be the problem here either.

I haven't seen any other reports like this. And neither have I had that experience with 0.91.

And also, please tell us your operating system, and which version of 0.91 did you download/install.

Whoops, and there hulf slipped in ahead of me! Maybe it is a known issue after all. I don't exactly understand the problem of why large images are downscaled during export.

It's true that it's always needed to have a sample svg...

So I'm attaching a sample SVG... From that, Anyone can export to png, using export "page" option, at 90 ppp... Let's see what happen

Wow, yes, there is a little blur there! And I wouldn't really call that a large image.

I wonder why they didn't put the new version of Cairo with Inkscape?

Okay so I just found out that if I use the option "Blocky (optimize speed)" this blurriness edges does not happen. Also the quality of the imported image does not seem worse. I would have expected this "Blocky (optimize speed)" option to display worse quality, but in effect it seems to work opposite..?

hulf2012 wrote:It's true that it's always needed to have a sample svg...

So I'm attaching a sample SVG... From that, Anyone can export to png, using export "page" option, at 90 ppp... Let's see what happen

When I export your file I get some blurryness but it seems to stem from the fact that your document and white background square does not have rounded pixel dimensions. I corrected your document to rounded pixels and there is then no blurriness from it when exporting to png.

I am also sorry if my initial post has created some misunderstanding. To make it clear this edge blurryness only happens when importing images into inkscape. And I found out that using the option "Blocky (optimise speed)" will actually make the image display properly in inkscape. While the option "none (auto)" will create the blurry edges. In my opinion this seems unexpected behavior because I would think the "none" option should NOT make the image display differently than in any other image viewer.

Ok, but when I compare to 0.48.5, there's not much difference! This is on Win7, 64-bit.

cairo-png-0485.png is my test in 0.48.5 (obviously) and I added a circle too, for comparison. And cairo-png091.png is for 0.91, 32-bit. (installed with EXE if it matters). Probably that's a confusing kind of filename, but I'm not changing it now, since the context is fairly clear.

What I understand is that the size, and the units of the document affects the rendering when exporting to png. I have to say that this lesson is always forgot and remembered again. At least for me.

toxigames wrote: And I found out that using the option "Blocky (optimise speed)" will actually make the image display properly in inkscape. While the option "none (auto)" will create the blurry edges. In my opinion this seems unexpected behavior because I would think the "none" option should NOT make the image display differently than in any other image viewer.

... But when you re-export your drawing with the included rster images, witht the "Blocky" option, the image will seem blurred ?...

When using Inkscape for games sprites, it is important to control the anti aliasing, I think, because some game developers prefer to use gif format, which can only use transparency to 0% or 100%... I think the same is for icon design... depending of the format and size, the bluring or the aliasing may not be desirable. I say this ... as a "thought"... maybe there are "loose ends" here.

greetings

.

hulf2012 wrote:What I understand is that the size, and the units of the document affects the rendering when exporting to png. I have to say that this lesson is always forgot and remembered again. At least for me.

toxigames wrote: And I found out that using the option "Blocky (optimise speed)" will actually make the image display properly in inkscape. While the option "none (auto)" will create the blurry edges. In my opinion this seems unexpected behavior because I would think the "none" option should NOT make the image display differently than in any other image viewer.

... But when you re-export your drawing with the included rster images, witht the "Blocky" option, the image will seem blurred ?...

When using Inkscape for games sprites, it is important to control the anti aliasing, I think, because some game developers prefer to use gif format, which can only use transparency to 0% or 100%... I think the same is for icon design... depending of the format and size, the bluring or the aliasing may not be desirable. I say this ... as a "thought"... maybe there are "loose ends" here.

greetings

Yes, I agree, re-exporting raster image makes blurry. For me this is luckily not an issue in itself because I almost never need to re-export drawings with included raster images. I am creating full game scenes in Inkscape which means I am ending up with a LOT of objects that eventually slow down or even crash Inkscape. The solution for me is to take the complex objects with many grouped objects and export to PNG and replace the object with the PNG image (saving the grouped object in a separate SVG file). Importing the PNG's to my scene svg file is only for use in the progress of creating the game scene. When the game scene is complete I will be using the original PNG's exported from the original svg file.

Req: 0.48.5 or 0.91

Long story short, upgrade to 0.91 which provides import rendering mode.
Use Blocky rendering for best aliasing option on import.

I discovered this in my project as a source problem:
My specified document size is odd, 25x25 pixels.
If you center align your work, the position is a real number, a decimal.
Immediately within your work, you will notice vector aliasing on straight lines and even-sized work.
You have to position your work with whole integers, otherwise you risk this.
How stupid do I feel? I am wondering whether fractional precision is even useful, but this is a downfall I have to be aware of.

Also, remember that Stroke, Fill, and Filters are not quality vectorized properties exportable into production work.
This is why pros will tediously turn everything into vector objects, raster filters on the final render only. Yes, you turn lines and fonts into objects in order to maintain quality thickness and precision without rasterization or atrocious aliasing.

@Logicoma: Can you provide a link to a bug report (or several) that supports your generalized recommendations?

Why not copy-paste from Inkscape to Inkscape? For most people, this works. For some, it rasterizes the copied contents (e.g. on OS/X, known problem, can be fixed by changing the pasteboard settngs).

What exactly do you mean by 4.? This is so general, that it can be true or not...

Why import blocky, unless you want a pixellated image?...