interpolation issue in Inkscape
Hi Inkscape community,
I have an issue with unwanted / inferior looking interpolation in scaled Inkscape PNG exports.
In the case at hand I have a pixel art image that has been converted to SVG using 40px x 40px vector squares for each pixel (whether or not Inkscape is the right tool for playing with pixel art is *not* the question here ;-) ).
When such an image is scaled down a little and exported as PNG, it shows some poor interpolation artefacts. These artefacts are less obvious or not present in the actual Inkscape display, but very visible after export.
Here is an illustriation of the problem:
http://img594.imageshack.us/img594/769/inkscapeinterpolation.png
(Please view at original size first to prevent additional interpolation.)
Please note that some of these interpolations do not seem to make sense, e.g. using bright grey in the brown / dark red hair of the character.
I am very aware that Inkscape may not be the weapon of choice for this kind of operation. Still, my questions:
- Is there any way to prevent Inkscape from interpolation / anti-aliasing upon exporting such an image?
- If this is an interpolation issue: why does Inkscape use such inappropriate colors?
- Shall I file a bug? :)
Any hint will be appreciated.
Thanks, Florian
On 2/10/11 00:14, Florian Berger wrote:
Please note that some of these interpolations do not seem to make sense, e.g. using bright grey in the brown / dark red hair of the character.
I am very aware that Inkscape may not be the weapon of choice for this kind of operation. Still, my questions:
Is there any way to prevent Inkscape from interpolation / anti-aliasing upon exporting such an image?
If this is an interpolation issue: why does Inkscape use such inappropriate colors?
Shall I file a bug? :)
Any hint will be appreciated.
Could you first attach the original SVG file used for the screenshot here in the mailing list?
Additionally, which version of Inkscape version did you use? (See menu 'Help > About Inkscape')
~suv
Hi,
~suv <suv-sf@...16...>:
Could you first attach the original SVG file used for the screenshot here in the mailing list?
Attached to this message.
Additionally, which version of Inkscape version did you use? (See menu 'Help > About Inkscape')
Running Inkscape 0.48.0 r9654.
Regards, Florian
On Oct 1, 2011, at 3:14 PM, Florian Berger wrote:
When such an image is scaled down a little and exported as PNG, it shows some poor interpolation artefacts. These artefacts are less obvious or not present in the actual Inkscape display, but very visible after export.
Yes, interactive display vs. export do hit different code paths.
Here is an illustriation of the problem:
http://img594.imageshack.us/img594/769/inkscapeinterpolation.png
(Please view at original size first to prevent additional interpolation.)
Thanks, that is very helpful.
Please note that some of these interpolations do not seem to make sense, e.g. using bright grey in the brown / dark red hair of the character.
Tricky code paths. Not sure if it's GTK, pixbuf, cairo or which. But is something we can track down.
I am very aware that Inkscape may not be the weapon of choice for this kind of operation. Still, my questions:
- Is there any way to prevent Inkscape from interpolation /
anti-aliasing upon exporting such an image?
There's not a good way at the moment. However, I think this is basically the same issue people hit with regards to blurry text.
- If this is an interpolation issue: why does Inkscape use such
inappropriate colors?
It's definitely due to one or more of the libraries we use. It definitely looks like a generic algorithm that is probably tuned to give good results for common photos, etc.
- Shall I file a bug? :)
Yes. Though you might see if there is an existing bug about text rendering, sharp edges, interpolation, etc. Getting this working well for you would definitely benefit a large number of people.
On 2/10/11 00:14, Florian Berger wrote:
I have an issue with unwanted / inferior looking interpolation in scaled Inkscape PNG exports.
In the case at hand I have a pixel art image that has been converted to SVG using 40px x 40px vector squares for each pixel (whether or not Inkscape is the right tool for playing with pixel art is *not* the question here ;-) ).
When such an image is scaled down a little and exported as PNG, it
Please clarify: do you actually scale the vector objects and then export at 90 dpi (Inkscape's internal resolution), or do you refer to exporting to bitmap with various bitmap sizes, while keeping the SVG at the original size (rectangular paths with integer pixel values for all nodes / rectangle coords and dimensions)?
shows some poor interpolation artefacts. These artefacts are less obvious or not present in the actual Inkscape display, but very visible after export.
Here is an illustriation of the problem:
http://img594.imageshack.us/img594/769/inkscapeinterpolation.png
I don't see any interpolation artifacts - I do see antialiasing where the "vector pixels" (40x40px) do not fall on pixel grid lines in the exported PNG.
Comments below are based on the assumption that you "scaled" the drawing when exporting to bitmap (not the vector squares themselves on-canvas):
Recreating the drawing based on the screenshot, and testing with 0.48.2 and a current build from trunk gives the same (expected) results if exported at arbitrary bitmap sizes (or resolutions) without considering the pixel grid in the exported bitmap.
It would be interesting though to have a closer look at the SVG file used for your screenshots/export: I'm surprised that the screenshot doesn't show the same antialiasing artifacts where the vector squares touch: did you draw them slightly overlapping (e.g. with an additional stroke (colored like the fill)?
If the vector pixel are placed precisely to touch at the edges (without overlapping strokes, even the new renderer (trunk) does show the "light grey" edges (see attached screenshot) between them at most zoom levels.
(Please view at original size first to prevent additional interpolation.)
Please note that some of these interpolations do not seem to make sense, e.g. using bright grey in the brown / dark red hair of the character.
AFAIU the "bright grey" (lines) are antialiased edges of the vector squares (against the transparent background), not interpolation errors.
I am very aware that Inkscape may not be the weapon of choice for this kind of operation. Still, my questions:
- Is there any way to prevent Inkscape from interpolation / anti-aliasing upon exporting such an image?
Yes: export at bitmap sizes (or resolutions) where you know that the downscaled "vector pixels" fall precisely on pixel grid lines in the exported PNG.
Assuming 40x40px for each "vector pixel", and a total of 33 columns and 17 rows (-> page size of 1320x680 px), do export e.g. at 4.5dpi, 9dpi, 18dpi, 22.5dpi, ... and the exported PNG will _not_ have any noticeable anti-aliasing effects.
Alternatively, use dimensions which are dividable by the number of rows and columns of "vector pixels" in the drawing: assuming the page size has a width of 33 x 40 px = 1320 px a height of 17 x 40 px = 680 px export to bitmap sizes of e.g. 66x34, 132x68, 264x136, 330x170 ...
- If this is an interpolation issue: why does Inkscape use such inappropriate colors?
In my understanding it is not an interpolation issue - it is about antialiasing (against a transparent background). Inkscape does not have an option to turn off antialiasing when exporting to bitmap (nor when rendering on-canvas) - and yes, this feature has been requested various times in the bug tracker. But if you want "pixelized" art, you have to make sure yourself that all edges of the "vector pixels" in your drawing will match a pixel grid line in the exported bitmap (else your squares might not be squares any more (if inkscape had an option to turn off antialiasing), or get antialiased (blurry)).
hth, ~suv
Attached: - SVG file with pixel art redrawn based on the screenshot (vector squares 40x40 px, page size 1320x680 px): visible layer: adjacent squares have been unioned hidden layer: all individual squares (no unions) - exported to bitmap with 4.5, 9, 18 and 22.5 dpi (corresponds to bitmap sizes 66x34, 132x68, 264x156, 330x170 ...) - screenshot of the SVG file in Inkscape 0.48.2
Hi ~suv,
my apologies if my report was somewhat imprecise. Here is an update.
~suv <suv-sf@...16...>:
Please clarify: do you actually scale the vector objects and then export at 90 dpi [...], or do you refer to exporting to bitmap with various bitmap sizes, while keeping the SVG at the original size [...]?
The problem hit me first when doing a website logo in Inkscape which involves the pixelated character. Please see the header of
- I created an 1024x768px image
- *scaled* the character and the logo as I thought best
- and exported at 90dpi
This procedure of course made in no way sure that the "vector pixels" fell precisely on pixel grid lines in the exported PNG.
I don't see any interpolation artifacts - I do see antialiasing where the "vector pixels" (40x40px) do not fall on pixel grid lines in the exported PNG. [...] AFAIU the "bright grey" (lines) are antialiased edges of the vector squares (against the transparent background), not interpolation errors.
Ok, so it's antialiasing artefacts then. That's what I meant. Anyway, Inkscape could do a better job here. Naively spoken, the renderer should ignore the background if two rectangular shapes are touching.
Yes: export at bitmap sizes (or resolutions) where you know that the downscaled "vector pixels" fall precisely on pixel grid lines in the exported PNG. [...] Alternatively, use dimensions which are dividable by the number of rows and columns of "vector pixels" in the drawing
I did some testing, and you are right: once one does some math and adheres to the grid, it works. Still, this does not solve the aesthetic issues of exports of these kind of images at arbitrary scales.
Inkscape does not have an option to turn off antialiasing when exporting to bitmap (nor when rendering on-canvas) - and yes, this feature has been requested various times in the bug tracker.
I see. Thanks.
Bug #166252 "Cannot align boxes properly." https://bugs.launchpad.net/inkscape/+bug/166252
Bug #170356" Suppress antialiasing artefact at the object boundary" https://bugs.launchpad.net/inkscape/+bug/170356
Thanks for the pointer. I will follow these.
Regards, Florian
On 2/10/11 23:49, Florian Berger wrote:
Bug #166252 "Cannot align boxes properly." https://bugs.launchpad.net/inkscape/+bug/166252
Bug #170356" Suppress antialiasing artefact at the object boundary" https://bugs.launchpad.net/inkscape/+bug/170356
Thanks for the pointer. I will follow these.
I followed your hint there to
http://florian-berger.de/en/software/pixel2svg/
Nice tool :)
<off-topic> Any plans to support partially transparent pixels in pixel2svg? Right now, they appear to be converted to fully opaque fills (no fill opacity value added), which e.g. draws heavy black borders when an icon has a black outline which was antialiased against a transparent background, or can turn a faint drop shadow into a black blob ;) </off-topic>
~suv
On 02-10-11 23:49, Florian Berger wrote:
...
I don't see any interpolation artifacts - I do see antialiasing where the "vector pixels" (40x40px) do not fall on pixel grid lines in the exported PNG. [...] AFAIU the "bright grey" (lines) are antialiased edges of the vector squares (against the transparent background), not interpolation errors.
Ok, so it's antialiasing artefacts then. That's what I meant. Anyway, Inkscape could do a better job here. Naively spoken, the renderer should ignore the background if two rectangular shapes are touching.
You are right that Inkscape could do better, but it is not that easy. Basically there are four ways to deal with this issue:
1. Draw shapes as overlapping.
2. Blend using additive blending (currently only possible through filters, but this will change).
3. Create an option to turn off antialiasing.
4. Make Inkscape recognize such "corner" (or rather edge) cases.
The first can obviously be done, but can lead to additional artifacts (although usually much less noticeable). The second should work just fine for cases like this where all shapes are disjoint, but does not produce the desired result in other cases (and at the moment you can only do it through filters, or indirectly through using layers, both not ideal).
The third option is much requested and has its merits. A few weeks ago I started on a patch to implement this (it looks to be quite simple using the new Cairo-based code), but I ran into some issues with properly supporting the required attributes and it needs to be updated. But this will come, eventually. Unfortunately this is obviously just a partial fix for this particular problem.
The fourth option is clearly the best, but this probably isn't coming for quite some time. It is a problem with practically all vector graphics implementations, and although there are some solutions they basically all come down to requiring more memory/cpu, although especially for export this probably would be quite acceptable.
So, you are right that this needs fixing, and it is on the radar, it will just take some time. But feel free to chime in with ideas and/or requests, examples of software that does "do it right", etc.
Sent from my iPhone
On 3 Oct 2011, at 08:48, Jasper van de Gronde <th.v.d.gronde@...226...> wrote:
On 02-10-11 23:49, Florian Berger wrote:
...
I don't see any interpolation artifacts - I do see antialiasing where the "vector pixels" (40x40px) do not fall on pixel grid lines in the exported PNG. [...] AFAIU the "bright grey" (lines) are antialiased edges of the vector squares (against the transparent background), not interpolation errors.
Ok, so it's antialiasing artefacts then. That's what I meant. Anyway, Inkscape could do a better job here. Naively spoken, the renderer should ignore the background if two rectangular shapes are touching.
You are right that Inkscape could do better, but it is not that easy. Basically there are four ways to deal with this issue:
Draw shapes as overlapping.
Blend using additive blending (currently only possible through
filters, but this will change).
Create an option to turn off antialiasing.
Make Inkscape recognize such "corner" (or rather edge) cases.
The first can obviously be done, but can lead to additional artifacts (although usually much less noticeable). The second should work just fine for cases like this where all shapes are disjoint, but does not produce the desired result in other cases (and at the moment you can only do it through filters, or indirectly through using layers, both not ideal).
The third option is much requested and has its merits. A few weeks ago I started on a patch to implement this (it looks to be quite simple using the new Cairo-based code), but I ran into some issues with properly supporting the required attributes and it needs to be updated. But this will come, eventually. Unfortunately this is obviously just a partial fix for this particular problem.
There's already code in there that probably does this. I wrote a function that uses the gtk image calls to save acouple of releases ago, (can save jpgs too) I just never got round to hooking it up to a ui. It creates an image that's as inkscape renders rather than via the different code path. Will try find it in the code when i get home this eve.
The fourth option is clearly the best, but this probably isn't coming for quite some time. It is a problem with practically all vector graphics implementations, and although there are some solutions they basically all come down to requiring more memory/cpu, although especially for export this probably would be quite acceptable.
So, you are right that this needs fixing, and it is on the radar, it will just take some time. But feel free to chime in with ideas and/or requests, examples of software that does "do it right", etc.
All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Inkscape-user mailing list Inkscape-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-user
On 2/10/11 00:14, Florian Berger wrote:
I have an issue with unwanted / inferior looking interpolation in scaled Inkscape PNG exports.
(...)
- Shall I file a bug? :)
AFAIU the basic issue is explained well in the comments by Bulia Byak in Bug #166252 "Cannot align boxes properly." https://bugs.launchpad.net/inkscape/+bug/166252 and affects rendering on-canvas as well as exporting to bitmap.
" Imagine that the boundary of two 100% black rectangles falls exactly in the middle of a screen pixel (or export pixel). This means that this pixel is 50% covered by one rect and 50% by the next one. Antialiasing, therefore, paints that pixel 50% transparent black for one rect and 50% transparent black for the other. However if you add two 50% transparencies, you don't get 100% (fully opaque). Instead you get a 75% transparency. You can try that with transparent shapes in Inkscape - that's how transparencies add up. As a result, you get a row of 75% transparent pixels which are clearly visible between two fully opaque rects. That's the artefact you are getting. The exact level of transparency of that row of pixels will depend on where the exact boundary falls within the pixel grid, and therefore will change seemingly randomly as you change zoom or export dpi. Snapping all boundaries to the exact pixel grid, as I explained in the previous comment, is a way to avoid this." bug #166252, comment #5
The problem is tracked in Bug #170356" Suppress antialiasing artefact at the object boundary" https://bugs.launchpad.net/inkscape/+bug/170356 (including several duplicates)
~suv
participants (5)
-
Florian Berger -
Jasper van de Gronde -
John Cliff -
Jon Cruz -
~suv