Border around image annotations
Brought to you by:
andreasb123,
auroux
Menu
▾
▴
#215 Border around image annotations
I am trying to use xournal to embed a PNG file (with alpha channel) into a PDF document ("electronic signature" or so... kind of silly if you ask me but better than wasting paper). This seems to mostly work, except that the exported PDF document contains a "border" around the non-transparent parts of the PNG file, which looks rather odd -- I attached a screenshot (very zoomed in; the blue line is part of the PNG, but the outline around it is not).
I would expect xournal to just embed the image, not to add an extra border. No such border is shown in xournal itself, it only occurs in the generated PDF. I tried two different PDF viewers (Okular and the gnome document viewer). I tried all combinations of "legacy PDF expot" and "Layers in PDF export", to no avail.
This is with version 0.4.8.2016.
This seems to be related to the alppha channel: when Ia dd a solid white background to the image, there is no border added around that.
The screenshot I forgot to upload
Some furhter experiments seem to indicate that when there is transparency in the image, xournal draws a border around that, but it does not draw a border around the outside edges of the image. It would be great if there was a way to disable this border.
I'm afraid xournal with the default settings does NOT do anything with the image except ask the Cairo library (which is the standard one used by linux applications for this purpose) to draw the image into the PDF. The "legacy PDF export" basically reproduces by hand what Cairo does: add the image into the PDF file in what is considered the standard manner.
The issue is how alpha channel is handled in the PDF specification for images: they get separated into an RGB image + a "soft mask" that is PDF's language for the alpha channel. The PDF viewer is supposed to combine the two faithfully. In practice, the mask seems misaligned by a fraction of a pixel with the image, and so if the transparent portion was set to be "transparent gray" or "transparent black" rather than "transparent white", an artifact appears.
I can't tell if this is a bug in common PDF renderers, or in the interpretation of the specification that says an RGBA image with alpha channel should be embedded into a PDF as an RGB image + a softmask. I note that, on my system: Okular and Evince both have the issue (but they both use the Poppler backend), as does xournal when loading the PDF for annotation (again we also use Poppler), and Adobe Reader 9.5 (yes, a relic; but not using poppler); however the PDF viewer in the latest Firefox does not have this problem, and neither does the PDF-to-HTML previewer used by Dropbox.
Because the "legacy PDF export" code works on fewer and fewer use scenarios and isn't really maintained, and because I have no idea what kind of image processing one could do to work around this bug, I am just not in a position to fix this.
In practice, the only two ways I can see to avoid the artifact are to use a solid white background, or make sure that the pixel values of the transparent part of the image are set to RGB=white rather than black.
For cross-reference, this also came up here:
https://stackoverflow.com/questions/62558338/pdf-image-soft-mask-artifacts
(I think it's the same issue; the responses mostly say to make the image not jump in RGB and alpha channels at the same locations; the lack of a more helpful suggestion makes me suspect this is just slightly broken in PDF in general, and not broken enough for anyone to have cared to fix it).
I would also consider drawing the attention of the poppler developers to this issue by filing a bug there, since the poppler renderer is the de facto standard, well maintained, and should be able to align images with their soft masks properly without creating such artifacts.
Denis
Thanks for the detailed respone!
I did not know those pixels still had color values that could matter. Is there any way to control that value e.g. when using Gimp to prepare the PNG file?
I will try to reproduce what you said about the result being different in different viewers. If I can, I will go look for the right place to report that.
I did some experiments with .ps export and it seemed like the .ps file was fine but when I then turned it into a PDF, the issue reappeared... that confirms what you said about the softmap representation.
Last edit: Ralf 2020-10-29
I'm pretty much a novice with Gimp, but transparent pixels definitely have an RGB value -- especially because you could make them only partially transparent and then the color matters (each of the RGBA channels is an 8-bit value in a transparent png). I don't know how you would specifically modify the RGB values of fully transparent pixels in Gimp; I found a thread suggesting that gimp does not destroy any RGB values when adjusting the alpha values of a previously non-transparent image; and in particular that making things transparent is not a good way of redacting confidential documents unless you set the appropriate export option to lose the RGB values of transparent pixels:
https://gitlab.gnome.org/GNOME/gimp/-/issues/4487
That said, Gimp's "color to alpha" feature that turns a solid color into full transparency probably destroys the RGB color value of the affected pixels to make them just full transparent and perhaps black, because there isn't any good reason why a normal person would care about the color of fully transparent pixels -- in other terms it sounds to me like gimp isn't actively trying to make transparent pixels black, nor actively trying to make it easy to keep track of their rgb values...
So: there should be a way, but I'm not sure what it is.
By the way: your use scenario if it's really a scanned signature is actually quite funny from my perspective, because xournal started as a pen drawing program for tablet PCs, and I added the whole PDF feature so I could write by hand on top of PDF forms and sign them. So the "usual" way to sign a PDF in xournal would be with a pen or a touch screen (or by copy-pasting a signature you keep in .xoj format after having drawn it once with a pen), rather than using a png or other image. But I understand not everyone has a tablet.
Denis
Yeah, not having a touchpad is the reason why I need to resort to a pre-scanned image.^^
Regarding Gimp, for my experiments to day I had a white brackground and then used the "pencil" tool set to "erase" and the resulting transparency was still causing problems.
Also the issue https://gitlab.gnome.org/GNOME/gimp/-/issues/4487 that you linked seems to suggest they want to change the default... but so far they did not, it seems (judging from the behavior of my installation).
Last edit: Ralf 2020-10-29
According to "convert signature.png -alpha off show:", my transparent pixels are now white (and indeed have been white before), but that does not seem to help unfortunately...
Oh! I had assumed the black edge was a bit of a black pixel that failed to become completely transparent, but it must be something else going on then... strange! Really sorry to not be more helpful.
Denis
Even when I make the alpha channel pink, I see no pink in these artifacts. Looks like something further along the pipeline resets the color of transparent pixels to black, or so.
Ah btw I should link this great resource for how to manipulate alpha channel colors: https://www.imagemagick.org/discourse-server/viewtopic.php?t=13746
Another small comment: pdfimages (in the poppler-utils package on most distributions) is a good tool to export back the RGB image and the s-mask (as a grayscale image) out of the PDF, just to check what got embedded into the pdf during export (in particular, what color the transparent pixels have in the RGB image that actually gets embedded into the PDF and overlaid with the grayscale transparency mask when the PDF file is rendered). (Use: "pdfimages -png file.pdf images" to produce a bunch of files numbered images-nnnn.png) But I'm not sure this will reveal anything useful beyond what you already found out.
Denis
pdfimages extracts an image where the transparent pixels are black. So looks like something in the Xournal export pipeline is normalizing transparent pixels to black?
I reported a poppler bug at https://gitlab.freedesktop.org/poppler/poppler/-/issues/975.
I found a work-around. :D The issue stems from fully transparent pixels being normalized to black, and that black leaking through because of imprecise alignment of RGB data and the softmask.
So the fix is to not have any fully transparent pixels. The following snippet replaces all fully transparent pixels by white almost fully transparent pixels:
The resulting PNG file can be embedded into PDF fils with xournal without artifacts in poppler-based PDF viewers. :)