SOLVED: Strange Aliasing issue

[chupinsky27]

So this is my first post here... check these forums MULTIPLE times a day yet first time coming across an issue that hasn't been discussed... as far as I know.

So this is an interesting problem I came across...

I am rendering .exr sequences, yet during compositing, there seems to be really bad aliasing around rounded/bright edges. This only occurs when the AE comp is set to 32-bit. 8 and 16-bit show an accurate edge with minimal aliasing. I'm pretty sure it is an issue with the super bright pixels. If in 32-bit, I apply levels and clip output white, the problem aliasing goes away.

Mind you, this is a single beauty pass, no effects or additive operations have been made.

Do you think this is just a side effect with working with 32-bit info? I have never had a problem like this with .exr sequences from C4D's standard renderer.

I am trying to attach images to illustrate the issue but I keep getting "Temporary folder could not be found. Please check your PHP installation." any help there too?

Thanks in advance

--------------------------------------------------------------------------------------------------

*SOLVED*

It's a little confusing but it boils down to which method is writing your beauty pass (Main Pass) file; either through C4D's "SAVE" tab in render settings or though octane's render pass "SAVE MAIN PASS." Each of these output methods handles saving alpha information differently, not exactly sure what is happening behind the scenes but I can guess.

If you want a Straight Alpha workflow, this is what worked for me:
C4D "SAVE" tab/ Alpha Channel (TRUE)/ Straight Alpha (FALSE)/ Octane Camera Imager Premultiply Alpha (FALSE)/ AE interpret footage Straight Alpha.

You should set on in premultiply alpha of Octane camera imager.

I don't suppose. C4D's renderer has pre-multiply alpha by default. Check it with OFF, you should see similar issues.

That alpha stuff was driving me crazy too. I don't know what is wrong here - cinema 4d or Octane implementation.
I believe there is some wrong math in plugin related to alpha calculations.
The short solution and only one is never tick "Premultiplied alpha" checkbox in Octane render settings. Or you will have your Alpha premultiplied two times.
And never tick "Straight alpha" checkbox in cinema4D render settings. Or you will have your Alpha Straightened two times.
////
Untick all checkboxes !
You will have "Straight alpha" from cinema 4d renderer
and "Premultiplied alpha" from Octane render passes if you choose "Save main pass" option. (very funny Aoktar)
C4d setup and AE project with correct interpretations in attachment.

Alphas.jpg

[aoktar]

Octane has not any aliasing problems. But it should be presentation problem about embedding alpha pixel to rgb channel.
See this thread for my answers: viewtopic.php?f=87&t=49547

Meanwhile forum is under some server changes. Problem should be related this.

[chupinsky27]

Octane has not any aliasing problems. But it should be presentation problem about embedding alpha pixel to rgb channel.
See this thread for my answers: viewtopic.php?f=87&t=49547

It looks like the other user was having the same issue I was having, yet I don't think there was a clear solution to his issue. I am also rendering render layers. The alpha channel looks clean yet the RGB channels have super bright pixels around the edges that are not fully being matted out by the alpha channel. Those pixel are not an issue when they are either clamped by AE at 8 or 16bpc or clamped by a levels "clip white output value" while in 32bpc.

I do get correct edges in 32bpc when I matte the image on top of itself either via duplicating the layer and setting the underlying layer's track matte to "ALPHA MATTE" or by using the "SET MATTE" plugin.

My AE comp is set to 32-bpc, sRGB working space, Linearized Working Space.

I am running 2.23.2 R6.2

Attached are Images demonstrating what I am seeing:

RGB Channels only

Alpha Channel... is clean!

Combined RGBA in 32bpc

Combined RGBS in 16bpc. Desired image.

I have also uploaded a stripped down version of the C4D project.

[chupinsky27]

Well I got through the project... the compositor saw the same issue and decided to not comp the project in 32bpc because of it. Guess rendering .EXRs were a waste of HDD space.

Moving forward, does anyone have some sort of suggestion to this issue? Anyone else experiencing this too?

Thanks

ps... both the studio and the client were very impressed and pleased by the quality of the renders. I have another job lined up and plan to use Octane again.

[dotcommer]

This looks similar to the issue I was having with needing precise alphas of UV passes, and somewhere between the RGB render and the Alpha pass, they weren't lining up exactly so i'd get these subtle little edge pieces sticking out or being cut. for a UV pass, this means positional data being lost, so it wasn't acceptable to choke the matte or anything. Seems this issue is still present. I haven't done any multi-pass stuff with Octane since I found this issue because I want EXACT mattes. I shouldn't have to adjust anything.

[aoktar]

There is two factor that you should check.

1- Floatbuffer can give color values than bigger 1.0. This means overexposed for some software. When you set floatbuffer+EXR, resulting pixels can be like that. This can be a problem for compositing software.
2- Premultiply Alpha: this is off by default, but on in C4D's own renderer. This makes some mixing on pixels of edges but causes wrong results for transparency in compositing software.

[chupinsky27]

There is two factor that you should check.

1- Floatbuffer can give color values than bigger 1.0. This means overexposed for some software. When you set floatbuffer+EXR, resulting pixels can be like that. This can be a problem for compositing software.
2- Premultiply Alpha: this is off by default, but on in C4D's own renderer. This makes some mixing on pixels of edges but causes wrong results for transparency in compositing software.

Thanks for the suggestions, aoktar,

I am rendering with Floatbuffer with the intention of supplying my compositor with the most data I can, including the super bright (greater than 1) RGB values. Not rendering with Floatbuffer would negate the reason for using the EXR to store floating point data. I have been rendering EXRs for the purpose of compositing and working with the floating point values for a long time while using C4D's standard render and have worked out a pretty good workflow; C4D->EXR (Straight Alpha)->AE (32bpc, linearized workflow, interpret as Straight Alpha). In octane, I have my camera imager set to Linear and display gamma to 2.2.

I will have to double check the premultiplied alpha, I believe I have it set to straight but I could be wrong.

Talking about the EXRs, it just dawned on me that the EXRs are technically "HALF" floating point. Could this be a culprit? I may try rendering a 32bpc .tiff to see if I get the same results.

Thanks for the ideas, I'll check back in with my findings.

-Craig

[aoktar]

I will have to double check the premultiplied alpha, I believe I have it set to straight but I could be wrong.
-Craig

You should set on in premultiply alpha of Octane camera imager.

C4D's standard render and have worked out a pretty good workflow; C4D->EXR (Straight Alpha)->AE (32bpc, linearized workflow, interpret as Straight Alpha).

Talking about the EXRs, it just dawned on me that the EXRs are technically "HALF" floating point. Could this be a culprit? I may try rendering a 32bpc .tiff to see if I get the same results.
-Craig

I don't suppose. C4D's renderer has pre-multiply alpha by default. Check it with OFF, you should see similar issues.

[uncia]

[quote="chupinsky27"]
That alpha stuff was driving me crazy too. I don't know what is wrong here - cinema 4d or Octane implementation.
I believe there is some wrong math in plugin related to alpha calculations.
The short solution and only one is never tick "Premultiplied alpha" checkbox in Octane render settings. Or you will have your Alpha premultiplied two times.
And never tick "Straight alpha" checkbox in cinema4D render settings. Or you will have your Alpha Straightened two times.
////
Untick all checkboxes !
You will have "Straight alpha" from cinema 4d renderer
and "Premultiplied alpha" from Octane render passes if you choose "Save main pass" option. (very funny Aoktar)
C4d setup and AE project with correct interpretations in attachment.

[chupinsky27]

You should set on in premultiply alpha of Octane camera imager.

I don't suppose. C4D's renderer has pre-multiply alpha by default. Check it with OFF, you should see similar issues.

That alpha stuff was driving me crazy too. I don't know what is wrong here - cinema 4d or Octane implementation.
I believe there is some wrong math in plugin related to alpha calculations.
The short solution and only one is never tick "Premultiplied alpha" checkbox in Octane render settings. Or you will have your Alpha premultiplied two times.
And never tick "Straight alpha" checkbox in cinema4D render settings. Or you will have your Alpha Straightened two times.
////
Untick all checkboxes !
You will have "Straight alpha" from cinema 4d renderer
and "Premultiplied alpha" from Octane render passes if you choose "Save main pass" option. (very funny Aoktar)
C4d setup and AE project with correct interpretations in attachment.

Alphas.jpg

YES!!!!

Thank you guys so much! That was very confusing but I think I grasp what is happening. Kind of explains why matting the render on top of itself corrected the alpha. I agree, funky math is happening somewhere.

Maybe this would be a good topic for the fine gentleman behind InlifeThrill to cover... if he hasn't covered it already and I skipped it thinking that rendering out a correct alpha channel would be self explanatory. He is really great at illustrating what is happening "behind the scenes" of the render engine/plugin.

Again, many thank you's to everyone who helped narrow this down!

Ill try to edit my original post to highlight the solution.

-Craig