Setting and maintaining RGB values for zero-alpha pixels

[nnevatie]

Hi,

 

I noticed Paint.net sets the RGB values of fully transparent (A = 0) pixels to the triplet 255,255,255. Is this intentional?

 

Is there a way of explicitly setting or maintaining the RGB values at a desired value? This is useful, for example, when creating a logo with black letters on top of transparent background.

 

Currently the white-in-RGB pixels cause sub-sampling and scaling issues in my SW, as the white pixels get mixed in with the black logo pixels, causing a grey halo to appear on the area where the alpha drops to zero. I know this issue could be worked-around by weighting the sampling for zero-alpha pixels, but it seems weird such special handling would be required.

 

Ideally, the user would be able to set the RGB values of zero-alpha pixels to any value, such as 0,0,0 in the above example case.

 

[AndrewDavid]

Hi @nnevatie

Welcome to the forum. I think this answers your question. If not - get back to us.

 

Expand the Color palette by selecting more and set the color to Hex 000000

White is a combination of all colors.

Black is the absence of any color.

 

I think this is what you are looking for. All values 0

 

 

 

Edited September 27, 2017 by AndrewDavid

[nnevatie]

Thanks for the response! My original problem had more to do with the alpha channel affecting the RGB values.

 

However, I managed to get the zero-alpha pixels to the RGB values I wanted by changing the blending mode from "Normal" to "Overwrite". Case closed!

 

[MJW]

Transparent pixels are 255, 255, 255. I wish they were 0, 0, 0. Nevertheless, I don't think the color of transparent pixels should affect the color that results from antialiasing if the antialiasing is done properly. When computing the resultant color, the RGB components should be multiplied by alpha before being combined with the foreground color, so no matter what the transparent color, the result should be the same. I tried using the Text tool against transparent white and black, and the result seemed to be the same.

 

How are you producing the letters, and can you provide an example?

[MJW]

This may be helpful: Transparent to Transparent Black. (Though, as, I mentioned, I don't believe antialiasing should be affected by the RGB values of transparent pixels.)

 

[nnevatie]

14 hours ago, MJW said:

Transparent pixels are 255, 255, 255. I wish they were 0, 0, 0. Nevertheless, I don't think the color of transparent pixels should affect the color that results from antialiasing if the antialiasing is done properly. When computing the resultant color, the RGB components should be multiplied by alpha before being combined with the foreground color, so no matter what the transparent color, the result should be the same. I tried using the Text tool against transparent white and black, and the result seemed to be the same.

 

How are you producing the letters, and can you provide an example?

 

Since my post, I've rewritten the part of my SW dealing with semi-transparent pixels. I'm basically using pre-multiplied alpha, which solves the original issue, as it doesn't matter what the RGB values are when alpha gets to zero.

 

Nevertheless, it would be nice if Paint.net had a way of explicitly controlling the RGB and A channels separately - it took me a while to find the Overwrite blending mode, which essentially allows you to overwrite the destination pixels with any ARGB values, regardless of the source alpha.

[MJW]

9 hours ago, nnevatie said:

I'm basically using pre-multiplied alpha, which solves the original issue, as it doesn't matter what the RGB values are when alpha gets to zero.

 

 

You should never do anything else. Not multiplying the color components by alpha when subsampling is wrong, as your previous results showed. Specifically, the color components should be multiplied by alpha and added, then the sums should be divided by the sum of the alphas (unless, of course, the alpha sum is zero). The average alpha should be computed by dividing the alpha sum by the number of subsamples. I assume that's what you're now doing. If not, try doing it that way.

 

The problem with allowing explicit control over the RGB and alpha channels is, I think, that it adds quite a bit of complexity for something that seldom matters. I do wish the default transparent value was all zeroes, but that's somewhat a different issue.

 

It was a while before I found out about the very useful overwrite mode.