Cairo renderer adds garbage pixels to transparency

[Nick]

I'm using Inkscape 0.92.2 (5c3e80d, 2017-08-06) on Windows. I am assuming that this is a Cairo issue, as I tested against 0.48, and saw that this issue did not occur there.

When exporting images with a transparent background, Inkscape will put save garbage color data into transparent pixels around the edges of your artwork (Eg: In a solid purple triangle, certain transparent pixels around the edge of the artwork will be colored yellow or black, with 0% alpha). This is not an issue if you are using the images for display only, but if you are using the images in any situation where colors may be interpolated, this can lead to very poor looking graphics, as the interpolation will use the garbage data in these transparent pixels to color neighboring pixels.

The easiest minimal reproduction is to simply create a triangle, click on it, and export your selection as a PNG. Open the newly created PNG in Photoshop/GIMP, convert the alpha channel to an image mask, and then delete the mask, so that all pixels are now fully opaque, with their original color information. Zoom in on the edges of your object and pixels will not all be the same color, despite the fact that there was only one color being used in the drawing.

I've attached an image to demonstrate the issue - I've done this process on a flat-filled purple path, with no stroke. You can clearly see off-colored pixels along the edge of the image (circled in red).

This issue currently makes Inkscape 0.92.2 unusable in the creation of game art, without manual post-processing of the rendered images, and is a major workflow impediment. I have reverted back to using 0.48 for now, but I would prefer to stay on the latest version for the improvements made there.

[Patrick Storz (ede123)]

Likely related (if not a duplicate of) bug #170356.

The current development version (0.92+devel) allows exporting to PNG without anti-aliasing (which might or might not be acceptable for your application). You could check if this solves the issue you're describing.

[Nick (inconvenienced-inker)]

I don't think that this is the same issue as #170356. That bug seems to be related to how Cairo handles antialiasing of shapes which are flush against eachother (Each division is anti-aliased separately, leading to a thin line of transparency running between them when rasterized).

This issue is that a single path being rasterized out to a PNG contains incorrect color information in the transparency. When looking at the image in an image viewer, you would not see anything wrong with it, but when you try to sample it for upscaling/downscaling, you will sample these incorrectly colored pixels.

This article briefly talks about some of the effects of incorrect color data in transparent pixels, when doing texture filtering. http://www.adriancourreges.com/blog/2017/05/09/beware-of-transparent-pixels/

Hopefully I've done a slightly better job explaining the issue this time, let me know if anything else needs clarification!

[Patrick Storz (ede123)]

There's nothing that needs clarification but maybe I should've been clearer:
Test a nightly build an check if disabling anti-aliasing solves / works around your issue. (If you don't want to test that's fine, too, but don't expect your issue becoming any more likely to be solved then...)

While this test won't prove this is the same issue as the other bug it allows us to determine if anti-aliasing causes the wrong color values (which I suspect).

[Nick (inconvenienced-inker)]

Is there a nightly Windows build available? I checked on Ubuntu, and it seems like the issue does not appear there.

[Patrick Storz (ede123)]

CI builds for Windows are at
https://ci.appveyor.com/project/inkscape/inkscape/history

- select a build (you should download a build of "master" branch)
- choose MINGW32/64 (aka 32/64-bit build)
- click on "Artifacts" and download the .7z archive
  (extract to any empty folder on your disk and run it from there)

[Nick (inconvenienced-inker)]

Sorry for the delay in responding. Finally had a chance to check if the issue is still occurring in the nightly build.

For sake of completeness, I tested with all four antialiasing options.

CAIRO_ANTIALIAS_NONE: As you suspected, turning off antialiasing removed these artifacts.

CAIRO_ANTIALIAS_GOOD/CAIRO_ANTIALIAS_BEST: There was no perceptible difference between the artifacts introduced between the Good and Best antialiasing, with both options creating identical images when post-processed to remove transparency and compared via diff tool.

CAIRO_ANTIALIAS_FAST: Fast produced significantly fewer artifacts than GOOD/BEST, which would be expected if antialiasing is the culprit, as fast is presumably doing less antialiasing to produce a faster result.