Texture paint: Bad alpha fringe #34233

New Issue

WK Bong · 2013-02-14T02:57:37+01:00

WK Bong commented

2013-02-14 02:57:37 +01:00

%%%Win7-64, GTX 560 Ti
2.66 test build, r54336

Problem exist back to 2.64a (didn't check other older versions)

Bad alpha fringe in texture paint.
Easy to produce.

Attached 2 files:

Screenshot of the bug in 2.64a
Blend file from 2.66 testbuild

%%%

%%%Win7-64, GTX 560 Ti 2.66 test build, r54336 Problem exist back to 2.64a (didn't check other older versions) Bad alpha fringe in texture paint. Easy to produce. Attached 2 files: 1. Screenshot of the bug in 2.64a 2. Blend file from 2.66 testbuild %%%

WK Bong commented

2013-02-14 02:57:37 +01:00

Changed status to: 'Open'

WK Bong commented

2013-02-14 03:33:51 +01:00

%%%Also while painting in total alpha, you don't have a gauge where the canvas is, it is transparent. Selected outline still needed in texture paint mode.%%%

Sergey Sharybin commented

2013-02-14 10:15:16 +01:00

%%%Developer note:
Checked on file. That's not color management issue, it just how brushes are blending with transparent but colored background. Not sure how this shall be done actually..%%%

%%%Developer note: Checked on file. That's not color management issue, it just how brushes are blending with transparent but colored background. Not sure how this shall be done actually..%%%

Ton Roosendaal commented

2013-02-14 13:58:40 +01:00

%%%This is not a bug but a limit of using 24 bits color (and 8 byte alpha). You paint using very low blending values, and this accumulates badly when repeated many times.
Internally we should use 16 bits (or floats) or to make this behave correctly. Or code ways to merge operations in 1 pass, to prevent these rounding errors.

I will assign this to Antony for future reference, he'll be working on better painting in Blender this year. It's no bug however, but a real (important) todo item.%%%

%%%This is not a bug but a limit of using 24 bits color (and 8 byte alpha). You paint using very low blending values, and this accumulates badly when repeated many times. Internally we should use 16 bits (or floats) or to make this behave correctly. Or code ways to merge operations in 1 pass, to prevent these rounding errors. I will assign this to Antony for future reference, he'll be working on better painting in Blender this year. It's no bug however, but a real (important) todo item.%%%

Antonis Ryakiotakis commented

2013-02-14 17:02:57 +01:00

%%%It is my understanding that color blending should be done in premultiplied space. I think for byte images we use straight alpha, but for this kind of operations this is bound to give trouble.%%%

Antonis Ryakiotakis commented

2013-02-17 00:24:29 +01:00

%%%Hi, a first try for a fix is to check if the imbuf is using alpha and if it does, check if we are in premul space. If not, multiply color with alpha prior to blending. This is trivial and could possibly be done before release. My only skepticism is: Should we do this automatically for mix mode blending, or possibly have an extra "over" blend mode that does that? My understanding is: mix is just a linear combination of colors while in painting we do over operation, not mix. If mix is supposed to behave like over, then other places where mix is used will be buggy as well.

Also I'm a bit in the dark about what space other color operation modes are supposed to work in.%%%

%%%Hi, a first try for a fix is to check if the imbuf is using alpha and if it does, check if we are in premul space. If not, multiply color with alpha prior to blending. This is trivial and could possibly be done before release. My only skepticism is: Should we do this automatically for mix mode blending, or possibly have an extra "over" blend mode that does that? My understanding is: mix is just a linear combination of colors while in painting we do over operation, not mix. If mix is supposed to behave like over, then other places where mix is used will be buggy as well. Also I'm a bit in the dark about what space other color operation modes are supposed to work in.%%%

Antonis Ryakiotakis commented

2013-02-17 00:25:20 +01:00

%%%Reopening, this -is- a bug.%%%

Ton Roosendaal commented

2013-02-18 19:52:07 +01:00

%%%RGB byte images should all be straight alpha.

But many blending ops assume brushes to be premul...%%%

%%%RGB byte images should all be straight alpha. But many blending ops assume brushes to be premul...%%%

Brecht Van Lommel commented

2013-02-20 15:10:21 +01:00

%%%As far as I can tell it's only projecting painting that is wrong here, when disabling that or painting in the image editor the fringes are not there.

Further there is a more subtle (old) issue here, which is that you can also get fringes due to the OpenGL texture being in straight alpha. All OpenGL textures should actually be premultiplied for mipmapping and texture filtering to work correct. It's mostly noticeable if you have a straight alpha image with e.g. a white background that is fully transparent.%%%

%%%As far as I can tell it's only projecting painting that is wrong here, when disabling that or painting in the image editor the fringes are not there. Further there is a more subtle (old) issue here, which is that you can also get fringes due to the OpenGL texture being in straight alpha. All OpenGL textures should actually be premultiplied for mipmapping and texture filtering to work correct. It's mostly noticeable if you have a straight alpha image with e.g. a white background that is fully transparent.%%%

WK Bong commented

2013-02-20 22:24:09 +01:00

%%%Agree on the projection painting is one of the culprit here.

Projection Painting ON, Straight alpha ON, the fridge halo is most visible.
Projection Painting Off and Straight Alpha ON, the fridge is subtle
Projection Painting Off, Permultiply ON, the fridge is subtle
These are with the brush textures premultiplied and MIP Map ON

Plus one more big problem I see is the UX.
To get a brush texture to be most useable (with least problem), one needs to set so many parameters.
As far as my experience tell me, there is only but 1 brush texture setting that is acceptable for texture painting to mimic the quality of 2D painting software.
That setting is

Alpha texture, white on texture part, alpha on else (User must define)
Alpha permultiplied
MIP Map on
Image mapping clip for good preview of the brush

How about making these settings default?%%%

%%%Agree on the projection painting is one of the culprit here. 1. Projection Painting ON, Straight alpha ON, the fridge halo is most visible. 2. Projection Painting Off and Straight Alpha ON, the fridge is subtle 3. Projection Painting Off, Permultiply ON, the fridge is subtle These are with the brush textures premultiplied and MIP Map ON Plus one more big problem I see is the UX. To get a brush texture to be most useable (with least problem), one needs to set so many parameters. As far as my experience tell me, there is only but 1 brush texture setting that is acceptable for texture painting to mimic the quality of 2D painting software. That setting is 1. Alpha texture, white on texture part, alpha on else (User must define) 2. Alpha permultiplied 3. MIP Map on 4. Image mapping clip for good preview of the brush How about making these settings default?%%%

Antonis Ryakiotakis commented

2013-02-25 02:50:53 +01:00

%%%This can get complex. I'm not sure what is the correct approach either.

For byte images, we can do association during painting, however for float images, we should unassociate and modify the color also when doing alpha painting operations. Is this correct? I'm not sure but I think it's possible to have premultiplied images with colour > 0 and alpha = 0. How does that case get handled? My color fu is not good enough here.%%%

%%%This can get complex. I'm not sure what is the correct approach either. For byte images, we can do association during painting, however for float images, we should unassociate and modify the color also when doing alpha painting operations. Is this correct? I'm not sure but I think it's possible to have premultiplied images with colour > 0 and alpha = 0. How does that case get handled? My color fu is not good enough here.%%%

Tobias Oelgarte commented

2013-02-25 04:31:35 +01:00

%%%It is simply not defined. A premultiplied image can have any color if alpha = 0. Its like a random colored light with 0 intensity. You can't measure the color it has, but if you make it brighter (increase alpha) you might be surprised.

Thats why it is best to avoid premultiplication in such cases. Premultiplied colors make sense for additive operations, but for anything else you should use straight alpha together with the over operation, which essentially does not touch the color if both alpha values are zero or replaces the color if one alpha is zero with the other. %%%

%%%It is simply not defined. A premultiplied image can have any color if alpha = 0. Its like a random colored light with 0 intensity. You can't measure the color it has, but if you make it brighter (increase alpha) you might be surprised. Thats why it is best to avoid premultiplication in such cases. Premultiplied colors make sense for additive operations, but for anything else you should use straight alpha together with the over operation, which essentially does not touch the color if both alpha values are zero or replaces the color if one alpha is zero with the other. %%%

Antonis Ryakiotakis commented

2013-02-25 04:45:18 +01:00

%%%Tobias, I think you are mistaken here. Color components give the perceived intensity in premultiplied space. I am thinking two possible solutions here.

Either "paint occlusion" for add/erase alpha or disallow alpha operations for float images entirely. I'll test it out and see.%%%

%%%Tobias, I think you are mistaken here. Color components give the perceived intensity in premultiplied space. I am thinking two possible solutions here. Either "paint occlusion" for add/erase alpha or disallow alpha operations for float images entirely. I'll test it out and see.%%%

Troy Sobotka commented

2013-02-25 05:45:47 +01:00

%%%"Its like a random colored light with 0 intensity."

This is factually incorrect. Associated alpha images with RGB values contain their intensities (luminance) across all three RGB values. The alpha purely measures occlusion.

"Thats why it is best to avoid premultiplication in such cases."

This too, is factually incorrect. See Alvy Ray Smith et al. Associated / premultiplied alpha currently models reality more appropriately than unassociated / straight / unpremultiplied.

Is this a bug? If the paint stroke is honouring the transparent RGB value, we should expect a pinky tone if painting red atop of a white, no? That's part of the downside of an unassociated / straight / unpremultiplied image.

"1. Projection Painting ON, Straight alpha ON, the fridge halo is most visible."

As above. Ton's suggestion might be right here. This may not be a bug.

"2. Projection Painting Off and Straight Alpha ON, the fridge is subtle"

This is the accumulation error that Ton mentions?

"3. Projection Painting Off, Permultiply ON, the fridge is subtle"

This, while incorrectly mangling the image, is again the accumulation issue.

Is this even a bug beyond the accumulation error?%%%

%%%"Its like a random colored light with 0 intensity." This is factually incorrect. Associated alpha images with RGB values contain their intensities (luminance) across all three RGB values. The alpha purely measures occlusion. "Thats why it is best to avoid premultiplication in such cases." This too, is factually incorrect. See Alvy Ray Smith et al. Associated / premultiplied alpha currently models reality more appropriately than unassociated / straight / unpremultiplied. Is this a bug? If the paint stroke is honouring the transparent RGB value, we should expect a pinky tone if painting red atop of a white, no? That's part of the downside of an unassociated / straight / unpremultiplied image. "1. Projection Painting ON, Straight alpha ON, the fridge halo is most visible." As above. Ton's suggestion might be right here. This may not be a bug. "2. Projection Painting Off and Straight Alpha ON, the fridge is subtle" This is the accumulation error that Ton mentions? "3. Projection Painting Off, Permultiply ON, the fridge is subtle" This, while incorrectly mangling the image, is again the accumulation issue. Is this even a bug beyond the accumulation error?%%%

Tobias Oelgarte commented

2013-02-25 14:43:19 +01:00

%%%"This is factually incorrect. Associated alpha images with RGB values contain their intensities (luminance) across all three RGB values. The alpha purely measures occlusion."

This is true, but only if alpha is > 0 and not very close to 0. In case of zero alpha you loose all luminance information and if you are very close to zero alpha you loose color/luminance precession. This usually doesn't matter, but it matters in the case when you just manipulate the alpha. Lets say you have (0.6, 0.2, 0.9) as a color/luminance and associate an alpha with one ULP bigger then 0: (0.6 * ULP, 0.2 * ULP, 0.9*ULP, ULP) -> (ULP, 0, ULP, ULP). If you now set Alpha to a higher value again you definitely don't get back the initial values. They will be very quantized and in case of alpha = 0 you won't get even close.

"This too, is factually incorrect. See Alvy Ray Smith et al. Associated / premultiplied alpha currently models reality more appropriately than unassociated / straight / unpremultiplied."

I have read some of his papers. But anything related to premultiplied alpha is also related to matting, where it makes perfectly sense. But changing the alpha in a drawing operation is not the same as matting and shouldn't be done with premultiplied alpha, except you can live with the accuracy loss.

"Is this a bug? If the paint stroke is honouring the transparent RGB value, we should expect a pinky tone if painting red atop of a white, no?"

This depends on the alpha of the destination and the source, on the desired operation and which type of representation is used as well. See: http://docs.oracle.com/javase/7/docs/api/java/awt/AlphaComposite.html
%%%

%%%"This is factually incorrect. Associated alpha images with RGB values contain their intensities (luminance) across all three RGB values. The alpha purely measures occlusion." This is true, but only if alpha is > 0 and not very close to 0. In case of zero alpha you loose all luminance information and if you are very close to zero alpha you loose color/luminance precession. This usually doesn't matter, but it matters in the case when you just manipulate the alpha. Lets say you have (0.6, 0.2, 0.9) as a color/luminance and associate an alpha with one ULP bigger then 0: (0.6 * ULP, 0.2 * ULP, 0.9*ULP, ULP) -> (ULP, 0, ULP, ULP). If you now set Alpha to a higher value again you definitely don't get back the initial values. They will be very quantized and in case of alpha = 0 you won't get even close. "This too, is factually incorrect. See Alvy Ray Smith et al. Associated / premultiplied alpha currently models reality more appropriately than unassociated / straight / unpremultiplied." I have read some of his papers. But anything related to premultiplied alpha is also related to matting, where it makes perfectly sense. But changing the alpha in a drawing operation is not the same as matting and shouldn't be done with premultiplied alpha, except you can live with the accuracy loss. "Is this a bug? If the paint stroke is honouring the transparent RGB value, we should expect a pinky tone if painting red atop of a white, no?" This depends on the alpha of the destination and the source, on the desired operation and which type of representation is used as well. See: http://docs.oracle.com/javase/7/docs/api/java/awt/AlphaComposite.html %%%

Antonis Ryakiotakis commented

2013-03-04 17:46:15 +01:00

%%%As I said these operations should be done in premultiplied space. One other thing that I noticed gimp does not allow that we do, is alpha operations on the alpha channel. The reason is simple: If you tweak alpha you need to also tweak colour in premultiplied space. I would say only allow editing alpha in straight space, if at all.

@Sergey, brecht. This looks like it would be a lot easier if we had premultiplied alpha in byte images too so I am curious why it isn't so. I could of course convert on the go but it will cost in performance. Should we consider switching there for byte images too?%%%

%%%As I said these operations should be done in premultiplied space. One other thing that I noticed gimp does not allow that we do, is alpha operations on the alpha channel. The reason is simple: If you tweak alpha you need to also tweak colour in premultiplied space. I would say only allow editing alpha in straight space, if at all. @Sergey, brecht. This looks like it would be a lot easier if we had premultiplied alpha in byte images too so I am curious why it isn't so. I could of course convert on the go but it will cost in performance. Should we consider switching there for byte images too?%%%

Tobias Oelgarte commented

2013-03-04 20:20:46 +01:00

%%%Gimp allows operations on the alpha channel. You can directly manipulate the alpha or you can use masks or even both together. No problem, because it stores the color separated from the alpha. But that obviously a thing you shouldn't try with premultiplied alpha, because of the singularity at 0 opacity. %%%

Brecht Van Lommel commented

2013-04-26 17:01:19 +02:00

%%%Closed a duplicate report: http://projects.blender.org/tracker/index.php?func=detail&aid=35095&group_id=9&atid=498

I don't think premultiplied byte images can work, because of precision issues, 8 bit is not to store alpha * color and then recover the color afterwards. As far as I can tell we just have to get the math for the blending functions right, if Gimp and Photoshop can do it then we should be able to do it too?

Testing in Gimp, it seems that the colors are blended as if premultiplied, no color from zero alpha areas bleeds in. The side effect of this is that it gives hard edges in the RGB part of the image, you can see this when doing Anti-Erase to reveal the RGB colors. There is no way to avoid that though, if you paint over zero alpha areas the RGB under the brush will be lost as it can't be in the blending or otherwise you get fringing.

So as part of the blending operations we have to premultiply the color and then unpremultiply it afterwards, or some equivalent in integer math.%%%

%%%Closed a duplicate report: http://projects.blender.org/tracker/index.php?func=detail&aid=35095&group_id=9&atid=498 I don't think premultiplied byte images can work, because of precision issues, 8 bit is not to store alpha * color and then recover the color afterwards. As far as I can tell we just have to get the math for the blending functions right, if Gimp and Photoshop can do it then we should be able to do it too? Testing in Gimp, it seems that the colors are blended as if premultiplied, no color from zero alpha areas bleeds in. The side effect of this is that it gives hard edges in the RGB part of the image, you can see this when doing Anti-Erase to reveal the RGB colors. There is no way to avoid that though, if you paint over zero alpha areas the RGB under the brush will be lost as it can't be in the blending or otherwise you get fringing. So as part of the blending operations we have to premultiply the color and then unpremultiply it afterwards, or some equivalent in integer math.%%%

Brecht Van Lommel commented

2013-04-27 14:51:37 +02:00

%%%Figured out the right formulas now and fixed 2D image painting. I'll tackle projection painting next.%%%

Brecht Van Lommel commented

2013-04-28 14:24:36 +02:00

%%%Texture paint fixed as well now. Thanks for the report, closing.%%%

Brecht Van Lommel commented

2013-04-28 14:24:36 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2013-04-28 14:24:36 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Texture paint: Bad alpha fringe #34233