Page 1 of 1

Bad Alpha in V3.x

Posted: Tue Jun 14, 2016 10:00 pm
by jayroth
The Alpha channel created by Octane is not correct. Edge anti-aliasing should exist only on the alpha channel layer - never on the RGB layer. When viewed as straight, the RGB layer would have jaggie edges, typically the color of the neighboring pixels. The alpha channel edges should always have smooth, proper anti-aliasing (reflecting the AA settings the user has enabled for the renderer). There should never be any edge AA on the RGB layer, as this causes contamination of the image.

Unfortunately, with Octane V3.x (up to the current build) when "disable partial alpha" is active, we are getting horrible un-anti-aliased edges on the alpha mask. The alpha mask should NEVER change regardless of settings (except for the type of AA applied, again as specified by the user.)

Also, when "disable partial" alpha is deactivated, the mask is better, though still contaminated. Again, this should never happen. The mask should always be clean regardless of the setting. Sadly, at this time, we cannot get a pure, clean alpha mask no matter what we do.

Re: Bad Alpha in V3.x

Posted: Tue Jun 14, 2016 10:37 pm
by abstrax
jayroth wrote:The Alpha channel created by Octane is not correct. Edge anti-aliasing should exist only on the alpha channel layer - never on the RGB layer. When viewed as straight, the RGB layer would have jaggie edges, typically the color of the neighboring pixels. The alpha channel edges should always have smooth, proper anti-aliasing (reflecting the AA settings the user has enabled for the renderer). There should never be any edge AA on the RGB layer, as this causes contamination of the image.

Unfortunately, with Octane V3.x (up to the current build) when "disable partial alpha" is active, we are getting horrible un-anti-aliased edges on the alpha mask. The alpha mask should NEVER change regardless of settings (except for the type of AA applied, again as specified by the user.)

Also, when "disable partial" alpha is deactivated, the mask is better, though still contaminated. Again, this should never happen. The mask should always be clean regardless of the setting. Sadly, at this time, we cannot get a pure, clean alpha mask no matter what we do.
I think you are setting stuff up incorrectly. There are multiple options which all affect the RGB and alpha channels, depending on what you need. What exactly do you want to do and which applications do you use? I also need your setup:

- Is "keep environment" enabled/disabled in the kernel settings?
- Is "pre-multiplied alpha" enabled/disabled in the imager settings?
- Is "disable partial alpha" enabled/disabled in the imager settings?
- Are you rendering passes or just the main (beauty) pass?

Btw, the "disable partial alpha" option in the imager settings is to work around this problem: viewtopic.php?p=269484#p269484

Re: Bad Alpha in V3.x

Posted: Wed Jun 15, 2016 6:44 pm
by jayroth
Hi Abstrax, thanks for replying. It could be that I am mistaken about settings, however, I suspect that, should that be the case, I am not alone in that regard. There are only three states of an acceptable alpha outcome: None, Straight and Premultiplied. No other state is valid. And bear in mind, I come from a media software development background (Electric Image, Inc, and EIAS).

I am rendering a beauty pass and a post pass. All of these settings are disabled, including disable partial alpha. In my case, I am rendering spaceships, planets, asteroids and so on for a television pilot here in the US. Octane has been smashing it, with the exception of this alpha issue.

My setup is a bit odd, as Octane does not have a native infinite light per se (that I am aware of), so per the suggestion of several on this forum, including Aoktar: I am using an infinite light from Cinema 4D with an Octane Daylight Tag, targeted to a null. I also have an OctaneSky object, and the Environment Tag has an RGBSpectrum set to black in the Texture Slot, as I do not want any color from that item, just the parallel shadows (and apparently this is a requirement for the shadows). Overall, this kludge actually seems to work, and it is not that cumbersome (though a true infinite light would be nice, and physically accurate I should think, but that is a discussion for another time.)

In no case should we ever see any non-alpha contamination in an alpha channel, regardless of settings, yet I am getting some dark fringing on the alpha. I suspect that Octane is splitting some edge anti-aliasing with the RGB channel, hence this contamination. I have seen this before in other renderers (LightWave used to do this before we fixed it), and the roots of this stem from the original Renderman specification by Pixar in 1988. They got it wrong then, in spite of the fact that they created the alpha channel concept, though whether or not Renderman still does this I am not aware of, one way or the other. The reason that this was originally done was the image display programs of that era did not consider alpha when displaying, and thus did not premultiply on the fly, but today, that is easy and commonplace (and correct) to do. Photoshop's funky alpha implementation didn't help, and I remember having quite the discussion with John Knoll about this back in the day. Sorry about the history lesson, and I'm sure you're aware of all of this, but given that other readers of this post may not know, I felt it prudent to include.

Getting back to it, though, as your post would seem to reinforce, there are too many areas in Octane currently that deal with Alpha (from a user experience POV), and setting the proper state in one area many not result in getting that result in the final render. There is a menu item in the live viewer for Cinema that lets you transfer the settings to the final render settings, but if you weren't aware of that, you would never know of it. Even so, my original argument still stands, that there is simply no case to EVER see any contamination of this type in an alpha channel. It is utterly useless for compositing, and adds quite of bit of work for a compositor to clean up (assuming that they can) and why I posted in the bug report section in the first place.

Thanks for your time.

Re: Bad Alpha in V3.x

Posted: Wed Jun 15, 2016 7:21 pm
by aoktar
off topic but have to say, omni, spot or direct lights are not available in our universe. Thanks to old days of pc's and low math power.

Re: Bad Alpha in V3.x

Posted: Wed Jun 15, 2016 8:28 pm
by aoktar
I think you're messing that due lack of alpha presentation of passes due picture viewer. From my POV you shouldn't make a post like that. It's big time loss until estimate what we're talking. It's completely dark for me where we are on. Thought that we wrote all rules of bug reports. Best thing you can do is to post some images and scene or full setup to figure the case better.