I export my files as PNG with transparency Alpha channel by using the Export Advanced method and scaling them down 50% for web. I noticed that those PNGs have a visible, darker (or lighter, depending on background) line along some of the edges, visible in all browsers. I opened them in GIMP, converted the transparency to selection and painted over, and there was a visible border in the transparency.
This happens when the image is scaled down for export, and switching between scaling algorithms did not help. Looks like a bug, or a result of using libraries that canāt scale transparency correctly.
Fortunately, there IS a workaround: the image must be first exported at 100% scale and then the resulting PNG re-open and scaled down to 50%. This is not ideal, but tolerable.
Does anyone have a different idea how to fix this problem or simplify the process (scripting, maybe?) Thanks!
I did send you a private message with links to download the files that are causing the issue, and the screenshots. Maybe you can forward them to Dmitry or whoever typically works on these parts of code.
The system doesnāt work like that. Developers only respond to formal bug reports, of which there are many, and those are dealt with according to an established process.
I appreciate that the file you sent me for download contains confidential image development.
Itās also quite complicated. If the problem youāve reported here is systematic problem with the Export Advanced process then it should be possible to replicate it with a much more simple and non-confidential .kra file.
Please try to create a .kra file that you can share in public which has the problem for you.
Using the confidential .kra file you sent me, and turning off the āPaper off whiteā layer to give a transparent background, I did File ā Export Advanced and used the settings that you showed in your screenshots (except that I set Resize to 50% since that is what you first reported).
Iām using the 5.2.6 appimage on Linux Mint 21.3.
I did not see any non-transparent pixels around the edges of the resulting .png file.
To be traced and fixed, a bug needs to be able to be replicated by other people.
Before that, it needs to be able to be replicated by you.
Assuming that I did the right things, as I described above, I canāt replicate the problem you described.
So, please try to replicate this yourself in the same size .kra file with simple artwork that you can quickly create.
Your initial post suggests that you have noticed this with other work?
If so, do you have any non-confidential work that you can share in public?
Edit:Add: Iāve edited your title to attract the attention of anyone who knows about this specific subject area.
Thank you for your response, @AhabGreybeard ! Sorry about the confusion.
I have reproduced this problem multiple times on my copy of Krita, different images.
Per your advice, I started reducing the file complexity, each time getting similar result. So finally I just created a default blank new file in Krita (not based on a template), which only has a layer at 75% opacity with a single squiggly line on it (attached to this post, along with the .png result of Advanced export at 50% scale).
Opened with GIMP, opacity-to-selection, painted black with the selection active. The vertical edges crossed by the line have different RGB values at first 2px.
Worth noting that before I drew the squiggly line edge-to-edge, the exported .png opacity was consistent edge-to-edge. Itās only when the squiggly line was added, the problem re-appeared.
In a recent thread I posted a screenshot of this dialog box in my Krita and noticed two main differences: 1) the āEmbed sRGB profileā option is enabled in mine and disabled in yours; 2) the "Store Metadata" option (I donāt know what itās for) is disabled in mine and enabled in yours.
Other than that, there are other things you can try:
Make a backup of your original kra file, just in case;
Go to Select > Select all;
Now, in Image > Trim to Selection;
Export your image as you did beforeā¦but configure your dialog box the same as mine(indicated in the link I provided above).
Interesting, thanks. So whether this option is enabled or not will not make a difference to the problem. It may also be that the āEmbed sRGB profileā option is irrelevant (just apply the tests I suggested to be sureā¦).
From my testing, Krita has a problem with creating weird values at the edge of the alpha channel when there are graphics (in my case a contrasting line) going past that specific edge of the drawing. If thereās nothing crossing the edge, alpha channel looks correct.
I was able to repeatedly confirm this behavior with images set to 1024x1024px and brushes of 10px-15px size. With smaller image size and brush size this problem wasnāt detectable.
This is what the alpha channel looks like in the exported image (zoom in to see borders at right-hand and bottom edge, but not at the left edge where line did not cross).
Nothing in the dialog boxes above (snapshots taken on Krita 5.2.6 in Kubuntu) changes that behavior.
I tried a few different scaling algorithms (not all, I admit) but that didnāt make any difference.
Maybe, just maybe ā the export filter should first flatten the image and clip layer content before scaling it. Thatās what manual scaling of an exported .png effectively does to avoid the problem (see original post).
@Guerreiro64 ā trimming the image sounds like a good option and may actually work, unfortunately I canāt do that because I frequently need the layer content that goes past the document bounds. Iām more comfortable to scale an exported png.
Hmmmā¦ it was my fault, I didnāt make this point clear enough: the idea is to make a backup of the original file (or a copy, if you prefer) and then try it on the copy of the file. This way your original will be safe.
No, no, you did make that point. I was just saying that for me, quickly post-processing the .png makes more sense, workflow-wise and disk-space-wise. On popular Linux distros, all the tools are installed by default (examples: Gwenview viewer in KDE, magick mogrify -resize 50% command etc.).
So whether this option is enabled or not will not make a difference to the problem. It may also be that the āEmbed sRGB profileā option is irrelevant (just apply the tests I suggested to be sureā¦).