PNG exporter removes colour channels if alpha is zero.

[Bram Stolk]

I have a document with a *white* background and alpha 0. (fully transparent.)

During the PNG export, inkscape even reports these background pixel values correctly:

Exporting only object with id="mous_1"; all other objects hidden
DPI: 45
Background RRGGBBAA: e6e6e600
Area 0:0:320:320 exported to 160 x 160 pixels (45 dpi)
Bitmap saved as: mous_1.png

Yet, the resulting PNG image has all the background pixels set to 0,0,0,0 and not e6,e6,e6,0.
(Verified with imagemagick seperate.)

Why are the RG and B channels reset to 0 if the alpha is zero?
The background colour information should be preserved in the PNG, not thrown away for alpha 0 pixels.

[Bram Stolk (b-stolk)]

Forgot to mention, this is on Ubuntu: Inkscape 0.91 r13725

[Bram Stolk (b-stolk)]

inkscape exports PNG correctly for background with alpha between 0x0a and 0xff.

For alphas 0x09 to 0x00 the colour values get progressively more mangled towards 0,0,0

What's so special about alpha 0x09 and below, that it starts mangling the R/G/B channels?

[Bram Stolk (b-stolk)]

Same happens on:
Inkscape 0.92.2 (unknown)

Now trying to build inkscape from source, but failing.

I did:
$ sudo add-apt-repository ppa:inkscape.dev/trunk
$ sudo apt-get update
$ sudo apt-get build-dep inkscape-trunk
Reading package lists... Done
E: Unable to find a source package for inkscape-trunk

[Bram Stolk (b-stolk)]

Ok, got the source to build, and I see that it is an inkscape issue, not a libpng one, as inkscape is feeding the zeroed RGB into libpng in the func:

sp_png_write_rgba_striped()

from src/helper/png-write.c

Still trying to find out why inkscape (or is it cairo?) generated those zeroed RGB values.

Debugging inkscape is hampered by the fact that gdb will not show me source code, as the png writer code is dynamically loaded.

[Bram Stolk (b-stolk)]

For alpha 0x01, I've been able to trace this to an issue with cairo.
Using python-cairo:
  a 0xff ff ff 00 background is incorrectly mapped to a 0,0,0,0 pixel.
  a 0xff ff ff 01 background is correctly mapped to a ff,ff,ff,01 pixel.

Note that somehow, inkscape makes it worse by incorrectly handling alpha 01 .. 09 as well.
I will file an issue with cairo, but please leave this bug open, as I think the alpha issue in inkscape exceeds this.

[su_v (suv-lp)]

Reported earlier as bug #1430716.