Bad Alpha in V3.x

Sub forum for bug reports

Moderators: ChrisHekman, aoktar

Forum rules
Before posting a bug report, please check the following:
1. That the issue has not already been disclosed
2. That the issue is specific to this plugin, and not Octane in general (Try reproducing it in Standalone)
Bugs related to the Octane Engine itself should be posted into the Standalone Support sub-forum.


All bug reports should include the information below, along with a detailed description of the issue and steps to reproduce it.
A. Operating System, including version (i.e. Win 7, OSX 10.11.2, Ubuntu 14.04, etc.)
B. Graphics Card(s) model (i.e. GTX 580 - 3GB, TITAN, etc.)
C. RAM Capacity (i.e. 6 GB)
D. Nvidia driver version (i.e. 7.50, 7.5.22)
E. OctaneRender Standalone version, if installed (i.e. 2.24.2, 2.23, etc.)
F. OctaneRender plugin version (i.e. v2.25 - 2.21)
G. Host application version, including build number if available (i.e. 3ds Max 2016 Build 18.0)
H. A detailed description of the issue and steps to reproduce it (Include Screenshots or video capture), as well as an example scene if applicable.
I. Copies of the Octane Log window and Console window outputs (full text attached as a file to your post is recommended).


Please note that reports of issues inside existing threads will be ignored/removed, and reports may be closed if the reporter does not respond to subsequent queries in the thread.
Post Reply
User avatar
jayroth
Licensed Customer
Posts: 393
Joined: Fri May 28, 2010 7:29 pm
Location: Orange County, CA, USA
Contact:

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.
CaseLabs Mercury S8 / ASUS Z10PE-D8 WS / Crucial 64GB 2133 DDR4 / 2 XEON E5-2687W v3 3.1 GHz / EVGA 1600 P2 / 2 EVGA RTX 2080Ti FTW3 Hybrid/ Cinema 4D

Is it fast? Oh, yeah!
User avatar
abstrax
OctaneRender Team
Posts: 5510
Joined: Tue May 18, 2010 11:01 am
Location: Auckland, New Zealand

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
In theory there is no difference between theory and practice. In practice there is. - Yogi Berra
User avatar
jayroth
Licensed Customer
Posts: 393
Joined: Fri May 28, 2010 7:29 pm
Location: Orange County, CA, USA
Contact:

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.
CaseLabs Mercury S8 / ASUS Z10PE-D8 WS / Crucial 64GB 2133 DDR4 / 2 XEON E5-2687W v3 3.1 GHz / EVGA 1600 P2 / 2 EVGA RTX 2080Ti FTW3 Hybrid/ Cinema 4D

Is it fast? Oh, yeah!
User avatar
aoktar
Octane Plugin Developer
Posts: 16066
Joined: Tue Mar 23, 2010 8:28 pm
Location: Türkiye
Contact:

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.
Octane For Cinema 4D developer / 3d generalist

3930k / 16gb / 780ti + 1070/1080 / psu 1600w / numerous hw
User avatar
aoktar
Octane Plugin Developer
Posts: 16066
Joined: Tue Mar 23, 2010 8:28 pm
Location: Türkiye
Contact:

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.
Octane For Cinema 4D developer / 3d generalist

3930k / 16gb / 780ti + 1070/1080 / psu 1600w / numerous hw
Post Reply

Return to “Bug Reports”