Hi at all,
I have a problem with cycles render alpha channel.
When I import PNG image on GIMP (or other software) and I insert a white background, I see a troublesome black border (as show on attached images. You notice little on a blue background).
Depends on what? Antialiasing? Premultiplied image?
Can it be eliminated in any way?
Thanks!
Seems like a (AO) shadow. Can you provide a .blend?
On my screen, I’m just seeing the physically correct coloration (I assume matching the world background color) of the edge of a reflective object as the incident light rays approach being perpendicular to the surface normal. If you want to eliminate it, you could make your object less reflective. That would (at least within the shader) simulate a rougher surface where more of the incident rays return to the camera. Possibly making your world color brighter would do the trick. It is harder to notice on a blue background because blue is a darker color than white. It would be even more difficult to notice if the background were black.
Could you tell us more about why you are trying to eliminate it or more about the overall look you are going for? Maybe that could help us in coming up with a solution that meets your needs.
Hi,
I try to eliminate it because for the customer who has to print the image for a catalog it seems like a masking error:smirk:
This is how it is seen on the customer’s software
Hi!
Any idea?
Thanks…
It appears to be an associated (aka premultiplied) vs unassociated (aka straight or key) alpha. Specifically, it has to do with nonlinearities if it is the issue I suspect it is.
PNG stores unassociated alpha, which makes for many problems. I am guessing this is for a web based configuration?
@aliasguru ping. Seems suspiciously similar to a nightmare we had to deal with via PNGs, no?
Similar but not the same. Currently running a few tests trying to replicate the issue. So far, I only get what I’d expect in Gimp. From what the OP says this is a problem that goes down to the print stage, so this time it’s not a browser compositing havoc. Might be worth bringing Gez into the loop as well?
@andrasbort Trying to composite against a white background will only work consistently if during the shader and light definition stage you were already looking at your scene with a white background. This way, you’ll tune the environment as well as the shaders and lights in a “correct” manner. It’s the background image that causes your trouble as far as I can tell.
You can easily verify this when using a setup like this in the world during a viewport render:
What this does is (if you set the Film to non-transparent) to set a different background color than what the world is feeding the shaders with while rendering. Now you can tune the background color freely as you like without changing the shading of the model itself. The effect of a dark rim around the model is noticeable even though we are still in the rendering context, are not dealing with any Alpha channel at all, not use PNG etc. It’s entirely natural.
I know it’s painful to change setups. See this more as a recommendation for the future. You could give the image a shot by adding a lightwrap in the compositor before the PNG is written, this sometimes can help a lot in blending objects into bright environments. But it’s more an act of despair than a correct solution.
What worries me more is the “Screenshot” from the client machine you provided. There are artifacts that look like strong aliasing, and this should definitely not happen. Is this only because the screen was photographed with a mobile phone camera, or is this what you really see on the client machine? Being too dark in those areas would make sense, but jagged edges should not appear there. If so, can you rule out the file format as the culprit by providing the client with TIF images? With the way PNGs are handling alphas, as well as the rather loose interpretation of such specs by various software packages, this could really become an unnecessary opponent to fight with.
Indeed, @Gez is usually pretty swift at peeling apart broken alpha issues…
Also note that Blender’s horrific alpha handling has led to broken TIFF output as well. They aren’t encoded using the conventional format and are essentially worthless, and indeed encoded incorrectly.
Why am I not shocked at reading this… Have to admit I never used the TIF implementation of Blender in the past five years, since for Web we were forced to use PNGs, and for anything else we go with OpenEXR. TIF exports then happen from Nuke.
Because you too are aware as to how smashed up Blender’s internal pipeline is to support… wait for it… the most CGI / visual effects / rendering unfriendly format known to humankind?
[quote=“troy_s, post:7, topic:1148224”]
It appears to be an associated (aka premultiplied) vs unassociated (aka straight or key) alpha.[/quote]
That is an accurate description of 95% of all PNG related bugs I’ve ever seen. Some software implements PNG alpha as specified, some software treats PNG alpha just like TIFF, and the users are caught in between.
In truth, anyone who has pushed pixels for a while comes to understand that there is exactly one alpha format. That is, unassociated alpha isn’t a format, it should rather be considered a state of an image buffer at the start of a pipeline if you happen to have accidentally made a horrible accident and encoded your image incorrectly. That, or you are the unfortunate person who needs transparency information on the web at the tail end.
It is the most hostile format on the planet, and should be banished from any pixel manipulation programs. Blender has completely fscked up their entire pipeline essentially to support an unworking model of alpha encoding, including destroying the one viable format TIFF along the way; that’s right, TIFF encodes from Blender are totally broken junk!
The folks pushing the pixels need to uniformly educate themselves just how awful unassociated alpha is. It can start with a simple beach ball and a blur. Poof, see how broken it is? Then try a rotate. More brokenness. In fact, any spatial pixel manipulation simply doesn’t work without the associated alpha state. The more educated pixel pushers, the more proper pixel pipelines and errors can be spotted. That puts pressure on software to do the right thing.
Associated alpha also makes it plausible to streamline the pixel pipeline. For example, if the entire pipeline is encoded to support associated alpha and assume such throughout, including associate broken formats like PNG, you an disassociate the alpha correctly and skip zero as well as reassociate skipping zero.
Anyways, rant over, and the dumb decisions have spread into Eevee, as it is even more mangled up now because of the historical decisions in Blender that go back literally over a decade…
The alpha team re-unites!
(ok that sounded like a Power Rangers episode).
Let’s see. First things first I’d try to figure out whether it’s a compositing problem outside Blender, or a problem of expectations.
I downloaded the example Blend file, and (apart from missing the environment image) rendering it with a light gray environment revealed some slightly dark edges around the right edge of the model.
That could mean that the dark edge is either a shading issue or just a material interaction with the environment (a fresnel reflection, a contact shadow?).
If that’s the case, it’s quite likely that those edges that aren’t quite noticeable on the checkers background show up when compositing over a light background.
So first thing to try is to alpha-over the render over white. If the darker edges are there (even if they are less noticeable than in the screenshot) then it’s a problem in the source, and some measures have to be taken to compensate and avoid it.
Also, if that’s the case, it wouldn’t be surprising that blending the PNG nonlinearly outside of Blender boosts those darker edges. We have to keep in mind that non-linear alpha compositing is not physically correct.
Now, if the rendered image looks right on white inside Blender’s compositor, then yes, it’s some issue with alpha.
Dark edges usually point to a double multiplication. Blender’s PNG output is a proper unassociated alpha if you saved the image straight away without doing anything funny in the compositor, so that would point to a bug in the software rendering the image.
Photoshop and GIMP shouldn’t be doing that kind of stuff. They both do simple alpha compositing right (despite doing it non-linearly, which is bad).
So, before we continue trying to figure out what’s going on, I’d like to here from the OP and how the image looks when composited on white using Blender’s compositor.
In a wooooorld where Display Referred Compositing is messing with the users, there is only one hope left… the Alpha Benders ©…
May 4
in a forum next to you…
Or The Expendables
(you know, a bunch of grumpy old farts with a bad attitude, fighting for something nobody cares about)
Thank you all for the answers!
Meanwhile, proceed by testing your suggestions:
Blockquote
So first thing to try is to alpha-over the render over white. If the darker edges are there (even if they are less noticeable than in the screenshot) then it’s a problem in the source, and some measures have to be taken to compensate and avoid it.
Also, if that’s the case, it wouldn’t be surprising that blending the PNG nonlinearly outside of Blender boosts those darker edges. We have to keep in mind that non-linear alpha compositing is not physically correct…
Blockquote
Blockquote
Trying to composite against a white background will only work consistently if during the shader and light definition stage you were already looking at your scene with a white background…
Blockquote
Thanks!
Hi!
could it depend on the Fresnel?
Eliminating it from the shader seems to disappear …
Nooo…
Black edge really depends on the alpha channel …
I tried to save in TIFF and TGA but it’s still the same.
As a solution in gimp I select the alpha channel and reduce it by one pixel … but I do not think it’s normal!
Definitely an “anti-aliasing” problem.
It could be!
But it’s not normal…for an animation what happen?
