When exporting a PNG image is there some way to force ALL transparent pixels to be one color? I have tried the File - Document Properties - Background color, and setting it to the desired color and alpha to 0. However, in 0.91 this does not work, creating two problems: #1. the transparent pixels are almost all of them black, no matter what background color I choose, and #2. a few pixels have whitish color, that I have found only appear on some semitransparent pixels that borders solid pixels.

In 0.48 setting the background color actually work for most of the transparent/semitransparent pixels, which takes care of problem #1. However problem #2 still happens. To fix this I have to use an image program like Photoshop or GIMP, however it is an annoying process, and way to time consuming when I have to fix this everytime I export a PNG.

Now if Inkscape had a specific function to force one color upon ALL transparent and semitransparent pixels, that'd be pretty neat. Is there such a function or extension around?

The images below show screenshots from a game I am making where interpolation of colors between pixels is applied. Interpolation uses the color of transparent pixels to smooth the display of images to avoid ugly pixelation. That is where a wrong (for example black or white) color on transparent pixel creates a problem, as seen on the screenshots.

Hi.

In 0.92 the transparent black issue has been corrected as far as I could see (behave was result of the cairo update?).

By adding a component transfer filter to the image you can force all pixels to be opaque -set alpha channnel to discrete input and type 1.

Thats great Lazur, I will install 0.92 instead . I am unsure of how to add a "component transfer filter"? and set alpha channel to "discrete input"?

Okay I found "component transfer" under filter-color. However when I set "type" to "discrete" I then chose "apply", the color changes the entire objects color to another color (that looks less saturated) but the "fill and stroke" dialog shows it as the same color still. I do not get the opportunity to "type 1" at any stage here. It also did not change any of those white colored transparent pixels, so the issue remains.

Hmm can you post an example file?


Still testing.
Assumed the black transparent behave was corrected because there was a similar issue with raising alpha levels on a turbulence filter primitive.
First test didn't work as I expected.

https://youtu.be/wGN6DfE20-A

Hi Lazur, I made a completely new object(see image below) in 0.92 and tried changing the background to transparent and the same color as the object (done via File-Document Properties-Background Color). On the exported PNG-image the vast majority of the transparent pixels are still black, while a few on the semitransparent edge of the object are white. Of course this only becomes a problem when doing interpolation of colors between pixels. So it's the same thing happening. Again, the black color on transparent pixels does not happen in 0.48, but the occasional white colored transparent pixel does.

Hi.

I still cannot reproduce that issue. Can think of either you are using a specific blend mode on object/on layer, or that your version is not compiled with the same cairo version as the win 64 build.

Lazur, Im not sure if I explained it good enough, but these black line/white dot jagged edges ONLY is visible when applying interpolation of colors between pixels with the PNG image (not in Inkscape). This is not something that is shown inside inkscape, and the PNG image also displays normally when not using interpolation. But with an image editing program I can verify on the PNG image that the transparent pixels are indeed black or white. the transparent black pixels can be fixed by using 0.48 (and I have no idea why that is) but the occasional white ones are a mystery to me.

Here's a video where I use color picker om my game engines(Gamemaker) sprite editor, it may be easier to see what I mean. In the video you can see that some of the pixels are in fact black, white or grey which I find unexpected since the only color I ever used in Inkscape to create that PNG is the beige/brownish color shown.

https://www.youtube.com/watch?v=fzCSWk8qyzc

Can only repeat myself.
Either you are using a specific blend mode on object/on layer, or that your version is not compiled with the same cairo version as the win 64 build others using.

Made another screen capture here, with 0.92 win64.
Exporting a semi-transparent object on a transparent background, opening it in gimp,
adding a new layer mask from alpha channel, and copy-pasting it for a zooming in. Can't be better than that.

(Drag&drop seems faulty when the camera is rolling.)


Another thing to try is saving as cairo png instead of exporting -that doesn't have transparency as far as I know.

If you can share a small part/derivative (like two simple rectangles) of your image you are working on, we can test whether the problem is with the file or with the renderer.

Lazur, I appreciate you taking your time to help me, thank you!

I downloaded and installed the win64 0.92 inkscape, I dont know how I can install this version better? The same with 0.91. As far as I know 0.48 was only win32 (so does it have anything to do with an issue 64bit versions?).

I am not using any specific blend mode on layers. Im not even using layers, other than the default "Layer 1". The blend mode for that is always set to "Normal".

In the video you didn't try to use the color picker on the semitransparent/transparent pixels in the image along the edge. Could you try to do that? I dont understand how that what you are doing with adding new layer mask from alpha channel and copy-pasting would actually reveal the colors of those transparent/semitransparent pixels? You can also try to duplicate the layer, merge them, duplicate, merge etc for many times until all transparent pixels are near 100% opaque; then the wrong colored pixels should also become very visible, because when I do that it is evident that some of those pixels are other colors than the single color used for the object in Inkscape. For example this video on the link in the bottom, of a new transparent image, you can see how I use the color picker in GIMP to reveal wrong colors of semitransparent pixels along the edge and also duplicating the layer to reveal them. ( you can find a copy of that PNG-file and the SVG-file in my dropbox in the following links, and the video from Youtube):
PNG-image: https://www.dropbox.com/s/z8knak23vogoq ... t.zip?dl=0
SVG-file: https://www.dropbox.com/s/3tsn3tf5gpdxr ... t.svg?dl=0
VIDEO: https://www.youtube.com/watch?v=LC84qcPbrGw

Just for the purpose of thourough testing I tried installing Inkscape on my Laptop computer (also win10 64bit). The same thing happens there! If the same thing happens on two different computers, this must be a common problem, not confined to my system.

I see.

You are right, should have copy-pasted the layer content instead of the layermask.
Can confirm that results in funny colours on the anti-aliased pixels. Strange thing is when you remove the alpha channel by that option instead in gimp it doesn't show up.

Reported a bug here, let's see if a developer can chime in.

Thanks for posting that bug report. Just like to mention that the problem also exists in 0.48, so that you may want to correct that in the bug report. What I can fix in 0.48 is the color of the fully transparent pixels (the background if you will), by setting the background color of the document to same color as the object. That doesn't work for me in 0.91 or 0.92, where the fully transparent pixels are still all black, but that is another problem than what we are discussing here as far as I can understand.

A lot of what you 2 are discussing is over my head. But I have a very basic question. Why do you have transparent pixels in your exported PNG in the first place?

To me, the easiest fix would be to edit the SVG so that you don't get those transparent pixels. Since you're only having pixel-wide gaps, I might speculate that simply adding a stroke to all your paths might do the trick.

By looking at your image, I could also imagine another fairly easy way to prevent the transparent pixels. But I hesitate to explain until I understand more.

Problem persist with opaque objects due to anti-aliasing.
As far as I understand the main goal is to export every object as raster images and pull those in the game maker.

Eliminating all transparency would mean switching off anti-aliasing.

Let's say we have a small opaque square on top of a larger opaque square. There should be no transparent pixels around the small square. Are you saying that there are?

My guess is that they need to be exported one by one, like with this extension(?).

So they are exported one object at a time, and then put back together somewhere else?

Well, if they could be put back together in the right order, you could still make them in such a way to avoid gaps. It seems like the areas which are affected are part of the background. I wonder if it couldn't be exported whole? Then you could draw it to avoid the gaps, and export whole.

I'm not sure if it would help to turn off anti-aliasing. I don't think that would affect exported PNGs. I thought it would only affect the live canvas, and exporting the PNG would introduce its own anit-aliasing. But I don't know that for a fact.

Brynn, I cannot avoid having transparent pixels, transparent pixels along the edge is basically what anti-aliasing is made of. Of course perfectly vertical or horizontal edges can be made without transparency and still look smooth, but that's just because anti-aliasing is only needed on diagonal lines. So turning off anti-aliasing would only work if I were to make a retro pixel game, then even these transparent pixels with wrong colors would not be a problem because interpolation would be disabled in a pixel game anyway (thus no wrong color interpolation origination from those weird colors would happen, and it seems that the wrong colors only appear in pixels that are VERY transparent, ie having very low opacity (like <6 or something, thus basically invisible). But I'm making a game with HD graphics and absolutely need anti-aliasing and interpolation. I have to find a way to eliminate those off colors. And right now I only know to do this manually using an image programs color picker in conjunction with a tool to change only the color of a pixel, but not its opacity... very tedious.

brynn wrote:Let's say we have a small opaque square on top of a larger opaque square. There should be no transparent pixels around the small square. Are you saying that there are?

No, there is only transparent pixels on diagonal edges of objects. So exporting a document as PNG of an area where different opaque objects overlap will not create transparency along the edge where the overlap happen. Only diagonal edges of objects that borders nothing/empty space will get transparent pixels as a result of the anti-aliasing. Some of these transparent pixels in the PNG, that are with very low opacity (thus basically invisible) is with totally different color, lightness and saturation than the objects color (this can be seen in my video that I made here: https://www.youtube.com/watch?v=LC84qcPbrGw). Normally this is not a problem because these pixels are nearly invisible, but when applying interpolation, especially upon scaling an an image, the game engine uses those odd colors and this creates ugly jarred pixels along the edge.

Okay so I happen to also have Illustrator CS6 installed, which also uses vector and can export to PNG (but I hate using Illustrators vector art, Inkscape is sooo much nicer to work with imo). Anyway here there is no odd colors on the transparent pixels along the edge (link to the PNG created with CS6 in my dropbox here: https://www.dropbox.com/s/bjbdz7tfy54q0 ... 1.zip?dl=0). I think this points in the direction that the issue lies with how Inkscape creates PNG. I noticed that in the PNG from CS6 no transparent pixel above 0 opacity had opacity lower than 16, while in Inkscape they became as low as <6 down to 1. Not sure if very low opacity could contribute to create the issue....?

Brynn, I cannot avoid having transparent pixels, transparent pixels along the edge is basically what anti-aliasing is made of.

Yes, I understand that.

If you are exporting each object individually, and putting them back together in the game program, that makes sense where the transparent pixels are coming from. But if you could export the background as a whole, there is a way to draw it, that would eliminate transparent pixels.

@toxigames:
Can you try to use the 'identify' command of imagemagick and compare the two files (from Illustrator / Inkscape)?

brynn wrote:

Brynn, I cannot avoid having transparent pixels, transparent pixels along the edge is basically what anti-aliasing is made of.

Yes, I understand that.

If you are exporting each object individually, and putting them back together in the game program, that makes sense where the transparent pixels are coming from. But if you could export the background as a whole, there is a way to draw it, that would eliminate transparent pixels.

Each object is an image of a mountain/hill range that moves as parallax backgrounds, that is the largest are drawn in game in the front and moves the fastest, while the smallest are drawn in the back and moves the slowest, giving the illusion of depth. Therefore I cant have all the object exported as one whole background: each hill image needs to be separate so I can move them independently and at different speeds to achieve the parallax effect. Or is there something I misunderstand about your suggestion to export as a whole background?

The fact remains that if I were to create all my images from vector files in Illustrator CS6 this wouldn't be a problem; the wrong colored semitransparent pixels is only something that Inkscapes does when exporting as PNG; it simply doesn't happen in Illustrator (unfortunately for me I hate working with vector in Illustrator and love it in Inkscape, so I don't think I would be able to make the switch from Inkscape to Illustrator). I'm guessing that most users will never be bothered by it either, because the opaqueness of the pixels are so low that they are in effect invisible to the eye. It is only when interpolation between colors is applied that the wrong colors get used and become visible; that may explain why I can find no reports from other Inkscape users describing the issue. Why Inkscape colors these pixel wrongly I know not; I do not have the faintest idea. But it would seem that there is no solution and that only the devs can fix this in a future version. I hope they will respond well to the bug report by Lazur and at least acknowledge the problem. Until a fix might be made some day I guess I will just have to make dto with manually changing the colors of those pixels on the PNG using an image editor like GIMP. Luckily it is not always that the wrong colors lightness, hue and saturation are so markedly different than the objects main color(s) that interpolation makes them (too) visible, but it does happen often enough to be a rather large nuisance in my workflow.